Почему некоторые API предоставляют в основном интерфейсы, а не классы?

Question

Некоторые API Java предоставляют большое количество интерфейсов и несколько классов. Например, API Stellent / Oracle UCM состоит примерно из 80% интерфейсов / 20% классов, и многие из этих классов являются лишь исключениями.

Какова техническая причина предпочтения интерфейсов классам? Это просто попытка минимизировать сцепление? Чтобы улучшить инкапсуляцию / сокрытие информации? Что-то еще?

Answer 1

Было бы максимально увеличить их гибкость в изменении базовых классов за кулисами.

Пока интерфейсы / контракты остаются прежними, они могут изменять классы реализации сколько угодно, не беспокоясь о влиянии на людей, использующих их библиотеку.

Answer 2

Они предназначены для третьих лиц, чтобы обеспечить реализацию.

Классическим и успешным примером является JDBC (22 интерфейса 7 конкретных классов)

Идея состоит в том, чтобы предоставить… хорошо… интерфейс программиста (API), чтобы клиенты (использующие код) могли свободно передавать функции, предоставляемые этим API, не беспокоясь о базовой реализации.

Другая причина в том, что, возможно, существует существующий провайдер (т. Е. FutureSQL), который все еще не существует, но он может реализовать эти интерфейсы, и вы сможете его использовать.

Answer 3

Один из лучших примеров - пакет java.sql.

Причина: когда разработчик имеет четкое представление о том, что необходимо сделать и как структурировано все приложение [еще не разработано], он предоставляет эту идею через API в виде набора интерфейсов.

Например: когда SUN (теперь oracle :-() публикует API для JDBC, весь пакет SQL (ну и большая часть его) - это просто интерфейсы с очень хорошо определенной совместимостью, но фактический поставщик DB / RDBMS знает, что делать, чтобы достичь результатов, как ожидается в API.

Следовательно, вы можете записывать ваши java и взаимодействие с БД отдельно, в то время как поставщик БД записывает базу данных отдельно. Поставщик просто должен написать драйвер, который соответствует стандарту API (интерфейсы), не сообщая вам, как он это сделал.

Тем не менее, ваше приложение и БД взаимодействуют без каких-либо проблем [в большинстве случаев; -)]

это длинный ответ, но надеюсь, что это поможет. Спасибо,

Ayusman

Answer 4

Количество интерфейсов относительно числа классов не так уж важно, если каждый класс реализует большое количество интерфейсов.

Answer 5

Вполне вероятно, что фреймворк / API был разработан с Dependency Injection , расширяемостью, низкой связью и высокой когезией с учетом