Почему фреймворки Java не навязывают использование интерфейсов?

Question

Мне просто интересно, почему нет интерфейса для Spring Bean или для EJB Bean (или для службы OSGi)?Я знаю, что в этом нет необходимости, потому что фреймворки могут использовать API отражения для вызова методов, но не будет ли ошибкой, если вместо них будут использоваться интерфейсы?

Например, почему нет интерфейса для компонента OSGi, которыйбудет выглядеть так:

interface OSGIComponent {
  void activate(BundleContext context);
  ... 
}

Answer 1

В случае с Spring вам не нужно реализовывать специфичный для Spring интерфейс, чтобы иметь возможность использовать Spring с вашим кодом. На самом деле это рассматривается как преимущество: он предотвращает привязку вашего кода к Spring, что делает его более переносимым.

Это не значит, что вы не можете реализовать специфичные для Spring интерфейсы. Один пример, который приходит на ум (не каламбур): InitializingBean; это определяет метод afterPropertiesSet(), который вызывается (как следует из названия) после того, как Spring создаст экземпляр вашего бина и установит все его свойства.

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

Вы привели пример компонента OSGi, который может реализовывать интерфейс OSGIComponent. Spring действительно имеет интерфейс, который ваш класс может реализовать, чтобы передать ссылку на содержащий контекст Spring: ApplicationContextAware. Однако, как правило, вам не нужно использовать эти специфичные для фреймворка интерфейсы. Ваш код, как правило, легче понять, если он сосредоточен только на реальной бизнес-логике, а не на деталях того, как инфраструктура создает объекты, соединяет их вместе и т. Д.

Answer 2

Мне было просто интересно, почему нет интерфейса для Spring Bean или для EJB Bean (или для службы OSGi)?

До третьей версии стандарт EJB сделал"принудительное использование интерфейсов".Фактически, для каждого компонента должно быть не менее двух, часто трех интерфейсов (Home, Remote и Local).За исключением того, что классы реализации не реализовывали эти интерфейсы, и у вас должен был быть дескриптор развертывания XML, который соединял бы все вместе, и, если что-то не подходило (например, из-за опечатки), вы получили совершенно загадочную ошибку времени выполнения.Это был абсолютный кошмар, и у EJB до сих пор ужасная репутация, хотя эта ошибка была исправлена ​​много лет назад.

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

Это не имеет никакого смысла вообще.

но разве не было бы ошибкой, если бы вместо этого использовались интерфейсы?Интерфейсы - это не волшебная волшебная пыль, которая делает код «менее ошибочным».Если у вас есть API, который может иметь несколько реализаций, вы создаете интерфейс.В противном случае вы не.Вот и все.

Answer 3

Если бинам нужно реализовать интерфейс, этот интерфейс должен присутствовать в пути к классам, что заставляет бин зависеть от используемой среды внедрения зависимостей (по крайней мере, до стандартизации аннотаций внедрения зависимостей в JSR-330, и теперь мы хотим обратной совместимости).

Однако в Spring bean-компоненты могут реализовывать интерфейсы для взаимодействия с контейнером, например InitializingBean и DisposableBean. ( источник )