Возможно ли (рекомендуется) иметь чистый api-проект, который отделен от фактической реализации?

Question

Меня попросили создать макет проекта для нашего будущего приложения с использованием Maven. Первым артефактом, над которым мы будем работать, будет архитектура. Чтобы максимально упростить работу разработчиков, у меня появилась идея отделить фактическую реализацию от API (как вы это сделали бы в среде OSGi).

Зависимости будут перечислять API-проект как зависимость для области компиляции, а реализация предоставляется только во время выполнения.

При таком подходе я надеюсь уменьшить сложность для разработчиков, а также ограничить их использование внутренних классов, которые часто подвергаются изменениям. Кроме того, можно скрыть транзитивные зависимости (например, я не хочу, чтобы разработчики вызывали DAO-уровень из внешнего интерфейса ... это должно быть видно только из сервисного уровня).

Кто-то применил это на практике и как это прошло? Что ты вообще об этом думаешь?

Answer 1

Я много видел, и у этого подхода есть свои преимущества и недостатки:

• Преимущества
  • Четкое разделение API и реализации
• Недостатки
  • Более сложный для понимания, потому что нет реального контекста, например, модульных тестов, чтобы посмотреть, чтобы понять API.
  • Сложнее провести рефакторинг и понять последствия определения и изменений API. Я плохо представляю, что может быть хорошим API, пока я его не использую (и не вижу, что он плохо работает).
  • Если за вашим API есть (работающая) реализация, которая недоступна людям, трудно или даже невозможно реализовать реальный тест для реального приложения.

Так что я думаю, что было бы неплохо опубликовать API только как API, но трудно разработать API без реального исходного кода, а иногда реализовать его на реальном API без запуска кода, который показывает, как он работает.

Различные подходы могут быть:

• Разработка с API реализации по умолчанию в качестве демонстрации.
• Разработка с API пример реализации, которая показывает, как использовать API.
• Разработка набора модульных тестов и макетов объектов, чтобы показать, как использовать ваш API в модульных тестах.

Answer 2

Это звуковой дизайн для разделения интерфейса (контракта) и реализации. Но как и во всем, используйте с модерацией. Вы не хотите ограничивать и усложнять дизайн до такой степени, что он стоит больше, чем обеспечивает. Помните, это должно добавить выгоду (или снизить риск), это не самоцель. Спросите себя, почему вы делаете эти вещи, каковы стоимость и выгода и каков будет связанный с этим риск и / или стоимость НЕ делать этого.

Answer 3

Я думаю, что это хороший подход и постоянно им пользуюсь. Я не испытывал никаких реальных недостатков, если бы делал это таким образом.

Примером моего использования является что-то вроде скребковой библиотеки.

У меня был бы проект Maven:

data-source-api

Имеет такой сервис, как:

package my.datasource.api;

public interface DataSource {
    public GetDataResponse getData(GetDataRequest request);
}

Где GetDataRequest и GetDataResponse (и другие классы API) также находятся в проекте API.

А также есть проекты Maven под названием:

data-source-urlfetch-impl // for appengine
data-source-http-client-impl // for Apache HTTP client
data-source-urlconnection-impl // for appengine/vanilla Java

Для каждой из моих реализаций. E.g.:

package my.datasource.urlfetch;

public class UrlFetchDataSource implements DataSource {
    ...
}

Answer 4

UML позволяет вам моделировать таким образом, и некоторые инструменты UML будут генерировать код на основе модели, что в теории поможет преодолеть разрыв от UML до кода, когда придет время.

Enterprise Architect является одним из таких инструментов. Но для этого требуется, чтобы ваша команда была знакома с UML, а также с каким-либо инструментом UML.