При чем здесь скрытие реализации и фрабричный метод?
Для того чтобы система оставалась независимой от различных типов объектов паттерн Factory Method использует механизм полиморфизма — классы всех конечных типов наследуют от одного абстрактного базового класса, предназначенного для полиморфного использования. В этом базовом классе определяется единый интерфейс, через который пользователь будет оперировать объектами конечных типов.
При чем здесь API? Графическим представлением архитектуры системы будет UML модель, на которой отражены компоненты, классы и взаимодействие между ними. О конкретной реализации классов архитектура ничего не говорит.
В первом комментарии я немного погорячился. Точнее будет сказать, что рефакторинг существенно не влияет на архитектуру. Он модифицирует реализацию классов / компонентов, обычно незначительно затрагивая интерфейс.
Service Locator (или Registry) работают по pull принципу, т.е. классы сами вытягивают зависимости и имеют статическую зависимость от, собственно, Service Locator. В случае IoC контейнера внедрение происходит по push принципу, т.е. с точки зрения классов инъекция происходит через конструктор / сеттер.
Профит:
— отсутствие статической зависимости;
— упрощение модульных тестов.
все старые вызовы DBConnection::getInstance() заменяются на DIManager::getDbConnection( $modelName )
И что изменилось? Была статическая зависимость на DBConnection, стала на DIManager. При этом DIManager к внедрению зависимостей имеет отношение только двумя буквами в названии.
Для решения задачи используется либо регистр, который делается синглтоном, либо более продвинутая реализация — сервис локатор.
Подскажите мне название книги по теории программирования, в которой дублирование кода не считается проблемой. А еще лучше книги (ну или хотя бы статьи уважаемого автора), в которой дублирование приветствуется и под это подводится теоретическая база. Без этого продолжать дискуссию не вижу смысла ;)
Тщательно разрабатывать интерфейс с расчетом на реюз в другом проекте я не рекомендовал бы, так как это как минимум противоречит YAGNI и KISS-у. С другой стороны, соблюдение SOLID принципов позволяет сходу получать классы, очень пригодные для повторного использования. Так что я за третий вариант :)
«Design Patterns Explained» как раз доступным языком описывает наиболее важные шаблоны из GoF. По ней можно знакомиться с паттернами, параллельно заглядывая в GoF.
Касательно «Patterns of enterprise application architecture» — это скорее не новаторские идеи, а попытка систематизировать существующие на тот момент лучшие практики. Многие паттерны до Фаулера были описаны в «Core J2EE Patterns» и других публикациях. Хотя тот же Active Record, который так удачно реализовали парни из RoR, и который является наиболее популярной реализацией ORM впервые детально описал именно Фаулер в упомянутой книге.
Я категорически не согласен с утверждением, что от дублирования кода может быть польза и продолжаю утверждать, что с какой стороны не посмотри — это зло. Но соглашусь с тем, что бывают случаи, когда из двух зол дублирование является меньшим. Например, часто в тестах копипаста позволяет сделать код более читабельным и понятным.
Вы верно описали распространенную проблему. В качестве решения упомянутый выше Роберт Мартин предлагает использовать принцип открытости / закрытости: класс открыт для расширения, но закрыт для изменения.
Насчет компромисса — с этим сложно спорить. Более того, в случае если требуется небольшой функционал некого монстроподобного модуля разумнее его реализовать самостоятельно / скопировать. Но эта проблема связна как раз тем, что многие сипановские разработчики ничего не знают о хорошей архитектуре и пренебрегают лучшими практиками.С другой стороны, есть паттерны (фасад, адаптер) которые позволяют частично решить и эти проблемы.
Вообще дублирование — это зло, с которым лучшие умы от программирования воюют уже пол века :) Если вы докажите обратное, быть вам по меньшей мере новым Фаулером :)
Для того чтобы система оставалась независимой от различных типов объектов паттерн Factory Method использует механизм полиморфизма — классы всех конечных типов наследуют от одного абстрактного базового класса, предназначенного для полиморфного использования. В этом базовом классе определяется единый интерфейс, через который пользователь будет оперировать объектами конечных типов.
В первом комментарии я немного погорячился. Точнее будет сказать, что рефакторинг существенно не влияет на архитектуру. Он модифицирует реализацию классов / компонентов, обычно незначительно затрагивая интерфейс.
Профит:
— отсутствие статической зависимости;
— упрощение модульных тестов.
И что изменилось? Была статическая зависимость на DBConnection, стала на DIManager. При этом DIManager к внедрению зависимостей имеет отношение только двумя буквами в названии.
Для решения задачи используется либо регистр, который делается синглтоном, либо более продвинутая реализация — сервис локатор.
Касательно «Patterns of enterprise application architecture» — это скорее не новаторские идеи, а попытка систематизировать существующие на тот момент лучшие практики. Многие паттерны до Фаулера были описаны в «Core J2EE Patterns» и других публикациях. Хотя тот же Active Record, который так удачно реализовали парни из RoR, и который является наиболее популярной реализацией ORM впервые детально описал именно Фаулер в упомянутой книге.
Насчет компромисса — с этим сложно спорить. Более того, в случае если требуется небольшой функционал некого монстроподобного модуля разумнее его реализовать самостоятельно / скопировать. Но эта проблема связна как раз тем, что многие сипановские разработчики ничего не знают о хорошей архитектуре и пренебрегают лучшими практиками.С другой стороны, есть паттерны (фасад, адаптер) которые позволяют частично решить и эти проблемы.