Шаблон "абстрактная фабрика" сверху МОК?
Я решил использовать принципы МОК на большем проекте. Однако я хотел бы получить что-то прямо, что это беспокоило меня в течение долгого времени. Заключение, что я придумал, состоит в том, что контейнер МОК является архитектурным шаблоном, не шаблоном разработки. Другими словами, никакой класс не должен знать о своем присутствии, и сам контейнер должен использоваться на прикладном уровне для сшивания всех компонентов. По существу это становится опцией сверху хорошо разработанной объектно-ориентированной модели. Однако как возможно получить доступ к разрешенным типам, не опрыскивая контейнеры МОК повсеместно (независимо от того, абстрагированы ли они или не)? Единственная опция, которую я вижу здесь, состоит в том, чтобы использовать абстрактные фабрики, которые используют контейнер МОК для разрешения конкретных типов. Это должно быть достаточно легко выгрузить для ряда стандартных фабрик. Действительно ли это - хороший подход? Кто-либо имеет на здесь используемом это и как хорошо это работало на Вас? Действительно ли там что-либо еще доступно?
Спасибо!
2 ответа
Давайте посмотрим на один из функций с открытым исходным кодом. Если вы хотите узнать, как он развернут, загрузите пару аналогичных проектов с открытым исходным кодом и учиться у них. Итак, найдите тот, который сделан как твой и изучите его источники.
Почему это должно помочь? Дело в том, что проекты с открытым исходным кодом приходится к , можно легко построить на машинах пользователей . В противном случае никто не сможет внести свой вклад в них. Поэтому вся необходимая информация о том, как они должны быть развертываемыми, обычно включаются в Установить или README файлы witihhn Источники, которые вы загрузили. Они обычно состоят из нескольких простых шагов. Для той же цели проверка наличия и версии предварительных условий автоматизированы (в Configure скрипты), а иногда и такие сценарии даже помогают в установке их.
Что обычно ожидается, является чем-то вроде
# Download sources (this line is read from your website)
wget http://myapp.org/myapp-source-2.15.tgz
tar -xzf myapp-source-2.15.tgz
cd myapp-2.15
less INSTALL
# read INSTALL file, where instructions about installing prerequisites are
./configure --help
# Read help, learn about possible options
./configure --prefix=/install/here --without-sound
make
make install
в настоящее время некоторые приложения используют Cmake вместо AutoTools (The Thingf с Configure Script).
Я сомневаюсь, что проекты Linux на самом деле требуют NetBeans в качестве системы сборки - это был бы излишек. Но эта IDE, кажется, генерирует Makefiles, поэтому отправляйте их. Вы также можете совершить для удобства для удобства, вы также можете совершить специфические IDE, но это не должно быть основным способом построения вашего мягкого.
Есть еще несколько вещей, которые пользователи ожидают найти в вашей упаковке:
- информация о лицензировании (обычно в файле
- Ссылка на домашнюю страницу проекта (где сообщать об ошибках)
- Руководящие принципы кодирования (в виде текста FLie)
- информация для сопровождающих (как вытащить версию, как добавить модуль и т. Д.)
Как вы уже выясняли, сам зависимость впрыск (ди) сама является лишь коллекцией шаблонов и методов.
В корне приложения мы проводят все необходимые объектные графики. Это место называется корень композиции , и мы можем использовать диконкурс DI для выполнения этой проводки для нас, или мы можем сделать это вручную ( Pure Di ).
Точка заключается в том, что в вашем приложении есть только одно место, где существует сильная ссылка на определенный кусок технологии (ваш ди-контейнер). Остальная часть приложения блаженно не знает о . Как было подключено . График объекта был подключен - все, что имеет значение, заключается в том, что все необходимые зависимости были правильно введены (и вы можете использовать впрыска конструктора с Нулевые гвардии , чтобы гарантировать, что это так).
Абстрактный фабрик - это очень полезный рисунок , когда дело доходит до ди. По сути, используйте абстрактную фабрику, когда:
- необходимо поставить один или несколько параметров, известных только во время выполнения, прежде чем вы сможете разрешить зависимость.
- Срок службы зависимости концептуально короче, чем срок службы потребителя.
Примеры и дополнительная информация доступна здесь:
Ну а в верхней части вашего приложения вам понадобится класс Bootstrap, загружающий контекст IOC. Этот контекст затем предоставит фактически инстанцированные объекты и, следовательно, будет действовать как фабрика.
Но это должно происходить только с очень небольшим количеством объектов, и пользователь класса Bootstrap/Factory должен знать как можно меньше об архитектуре, лежащей в основе. Например, если вы полностью сконфигурировали объект HTTP-сервера через IOC и хотите запустить его, то ваш класс Bootstrap должен только предоставить метод getHttpServer(). Тогда вашему основному методу программы достаточно вызвать Bootstrap.getHttpServer().start(), чтобы он запустился.
Проводка других ваших объектов уже была выполнена в контексте приложения, например, вы настраиваете Object A через IOC, который является частью Object B, поэтому вы настраиваете Object B со ссылкой на Object A. Обычно никому из них не нужно знать ни о контейнере, ни о заводе-изготовителе.
.