Гранулярность компонентно-ориентированных архитектур - PullRequest
Новая
       33

Гранулярность компонентно-ориентированных архитектур

1 голос
/ 03 октября 2011

Хотя я и являюсь разработчиком на Java, и этот вопрос касается OSGi и модульности в соответствии с Java, этот вопрос действительно применим для любого объектно-ориентированного 3GL.

Я начинаю понимать концепции по-настоящему «модульной» разработки и начинаю по-настоящему любить OSGi. Впервые в жизни я начинаю думать о развертывании банок в очень гранулированных, многоразовых, специализированных развертываниях. Однако этот новый способ мышления вызвал несколько вопросов.

В чисто компонентно-ориентированных архитектурах каждый класс встревожен? Если нет, насколько гранулированными должны быть компоненты? Можно ли сделать каждый компонент многоразового использования?

Какие «практические правила» следует использовать при определении степени гранулярности модульного компонента? Заранее спасибо!

1 Ответ

5 голосов
/ 03 октября 2011

Я собираюсь ответить на это в основном с точки зрения OSGi.

ИМХО важно различать компоненты и модули . Компонент - это программный артефакт: он имеет поведение и может предлагать услуги другим компонентам. В терминах реализации вы программируете компонент с использованием одной из моделей компонентов OSGi , таких как декларативные службы. Смотри http://wiki.osgi.org/wiki/Component_Models_Overview

Модуль - это артефакт развертывания: это упаковка компонентов и / или API-интерфейсов в артефакт, который можно скопировать и установить в различные среды выполнения. Поэтому неявно вы можете упаковать несколько компонентов в один модуль, ИЛИ создать один модуль для каждого компонента.

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

  1. Компоненты, упакованные вместе в одном модуле, (повторно) развернуты вместе. Если один из этих компонентов выпускается чаще, чем другие, то вы, возможно, создаете больше работы, чем необходимо (например, тестирование нижестоящими потребителями), многократно выпуская неизмененные компоненты, просто потому, что они находятся в том же модуле, что и изменяющийся компонент .
  2. Нельзя развернуть половину модуля. Поэтому все компоненты в модуле должны быть тесно связаны между собой, поэтому вы не должны желать, чтобы пользователи «если бы я только мог развернуть только некоторые компонентов в этом модуле» ...
  3. API меняются очень медленно и осторожно, тогда как компоненты меняются часто. По этой и другим причинам API лучше всего развертывать в своих собственных пакетах API. См http://wiki.osgi.org/wiki/Separate_API_from_Implementation
  4. Для обеспечения возможности рефакторинга содержимого модуля, не нарушая пользователей, всегда выражайте свои зависимости в терминах Import-Package, а не Require-Bundle. См http://wiki.osgi.org/wiki/Use_Import-Package_instead_of_Require-Bundle
...