Каковы лучшие практики для API промежуточного программного обеспечения?
Мы разрабатываем SDK промежуточного программного обеспечения как на C++, так и на Java, который будет использоваться в качестве библиотеки / DLL, например, разработчиками игр, разработчиками программного обеспечения для анимации, разработчиками Avatar для улучшения своих продуктов.
Я хотел бы знать следующее: существуют ли стандартные «лучшие практики» для разработки этих типов API?
Я думаю об удобстве использования, удобочитаемости, эффективности и т. д.
Ответы 5
Есть много способов разработать API, в зависимости от того, что вы решаете. Я думаю, что полный ответ на этот вопрос стоил бы целой книги, такой как банда четырех выкроек. В частности, для Java, а также для объектно-ориентированного программирования в целом, я бы порекомендовал Эффективное Java 2-е издание. Первый - это общие и множество популярных шаблонов программирования, когда они применяются и их преимущества. Эффективная Java ориентирована на Java, но ее части достаточно общие, чтобы их можно было применить к любому языку программирования.
Взгляните на Рекомендации по проектированию каркаса. Я знаю, что он специфичен для .NET, но вы, вероятно, тоже сможете почерпнуть из него много общей информации.
Два моих любимых ресурса по этой теме: http://mollyrocket.com/873 и http://video.google.com/videoplay?docid=-3733345136856180693
Видео от Джоша Блоха, упомянутое yrp, является классическим - я поддерживаю эту рекомендацию.
Некоторые общие рекомендации:
- ОБЯЗАТЕЛЬНО определяйте свой API в первую очередь с точки зрения интерфейсов, фабрик и разработчиков.
- НЕОБХОДИМО четко указать, какие именно пакеты и классы являются частью API.
- НЕОБХОДИМО предоставить банку, специально используемую для компиляции с API.
- НЕ полагайтесь в большой степени на наследование или шаблон метода шаблона - со временем он станет хрупким и сломанным.
- НЕ используйте одноэлементный шаблон или, по крайней мере, используйте его с особой осторожностью.
- ОБЯЗАТЕЛЬНО создайте javadoc уровня пакета и класса, объясняющий использование и концепции.
Используя сторонние библиотеки в Windows, я узнал следующие две вещи:
Попробуйте распространять вашу библиотеку как DLL, а не как статическую библиотеку. Это дает лучшую совместимость между различными компиляторами c и компоновщиками. Другая проблема со статическими библиотеками в Visual C++ заключается в том, что выбор библиотеки времени выполнения может сделать библиотеки несовместимыми с кодом, использующим другую библиотеку времени выполнения, и вам может потребоваться распространять одну версию библиотеки для каждой библиотеки времени выполнения.
По возможности избегайте C++. Изменение имени C++ сильно различается между разными компиляторами, и маловероятно, что библиотеку, созданную для Visual C++, можно будет связать из другой среды сборки в Windows. Когда дело доходит до C, дела обстоят намного лучше, особенно если вы используете dll.
Если вы действительно хотите получить хорошие части C++ (например, управление ресурсами с помощью конструкторов и деструкторов), создайте в C++ удобный слой, который вы распространяете как исходный код, скрывающий ваши c-функции. Поскольку у пользователя есть исходный код и он компилируется локально, у него не будет проблем с изменением имени или abi в локальной среде.
Не зная слишком много о вызове кода c / C++ из Java, я ожидаю, что работать с кодом c будет намного проще, чем с кодом C++, из-за проблем с искажением имени.
В книге «Несовершенный C++» есть некоторые обсуждения совместимости библиотек, которые мне показались очень полезными.