Factory Method (Фабричный метод) немного похож на Абстрактную фабрику. Он также позволяет спрятать конкретную реализацию и предоставить несколько типовых методов для использования.
Но, о отличие от абстрактной фабрики, фабричный метод даёт возможность задать какой именно класс «реализации» использовать в конкретной фабрике.
Паттерн «Абстрактная фабрика» довольно распространён, особенно часто приходится слышать выражение «использовать фабрику» среди программистов, которые делают вид, что разбираются в шаблонах проектирования. :)
Строго говоря, «фабрик» две: абстрактная фабрика и фабричный метод. Основная суть у них похожа, но разнится реализация. Поэтому желательно уточнять какая именно фабрика используется. Сейчас поговорим про Abstract Factory.
Строго говоря, «Текучий интерфейс» даже не сколько паттерн, сколько методика организации кода, направленная на то, чтобы упростить его чтение. Вместо последовательных вызовов функций в каждой строчке, организуется цепочка методов. Наверняка вы с таким встречались:
$fullName = (new MyName())->setFirstName('Don')->setLastName('Joe')->getResult();Реализуется такой подход очень просто. Каждый метотод, который может участвовать в цепочке, должен возвращать ссылку на свой объект $this.
Начну небольшой цикл статей посвященных шаблонам проектирования с реализацией на PHP. Постепенно эту запись буду редактировать, чтобы собрать все ссылки скопом.
Все шаблоны я писал сам, но, естественно, ориентировался на существующий код и описания (почти всё с википедии и книг по Java). В основном, конечно это Java и C#, поскольку паттерны были придуманы для «больших» языков, а реализации в PHP лишь пытаются повторить их код. Это одна из проблем, поскольку PHP сам по себе уже имеет ряд готовых решений где использование шаблона просто не имеет смысла. Например шаблон Prototype (Прототип) реализуется через cloneи ничего придумывать не нужно. Или шаблон Iterator (Итератор) по сути сводится к перебору массива, поскольку массив в PHP — универсальная структура и может содержать не только простые данные, вроде строк и чисел, но и сложные — объекты. Конечно, можно перевести код этих шаблонов с Java на PHP, но большого смысла это иметь не будет, разве что для теоретического изучения.
Шаблонов проектирования много (в моей коллекции сейчас 17 штук) и разобраться в них сходу не получится. Мои варианты шаблонов имеют пару особенностей. Первая — это реальный исполняемый код. То есть вы можете запустить на сервере index.php и получите результат в браузер. Сам шаблон и вся его работа размещена в одном файле для удобства (чтобы не прыгать по нескольким файлам).
Базовым принципом ООП (объектно-ориентированное программирование) является наследование. С помощью наследования можно построить сложную иерархию классов, где потомки наследуют функциональность своих родителей. В теории это всё выглядит замечательно, но на практике часто оказывается так, что наследование ухудшает код и делает архитектуру приложения негибкой и сложной.
PHP универсальный язык, где ООП занимает незначительную часть. Но в других языках, где программирование происходит исключительно на на классах, ограничения оказываются довольно существенны, поэтому были разработаны алгоритмы, которые по сути вылились в известные шаблоны проектирования. Одним из методов проектирования классов является агрегация и композиция, которые очень часто противопоставляются наследованию.
Есть даже такое выражение «Композиция лучше наследования», которое хорошо известно программистам Java или С++. Попробуем посмотреть на эти вопросы с точки зрения PHP.
Следует учитывать, что в PHP несколько упрощенная реализация ООП (объектно-ориентированное программирование). Поэтому, когда речь идёт об ООП как абстрактной парадигме, то следует использовать какой-то более серьёзный язык, вроде Java, С++ или Object Pascal. Потому что на этих языкам можно посмотреть практическую реализацию принципов ООП. В PHP программисты пытаются подражать другим ЯП, что в итоге приводит к излишней сложности и путанице, поскольку язык сам по себе не позволяет сделать «как в теории».
Главная проблема такого (спагетти) кода в том, что у него низкая читабельность и слишком большая запутанность. Там где нужно выполнить какой-то один метод, подтягивается еще десяток классов. При этом каждый класс в отдельном файле, что может окончательно свести с ума даже опытных программистов.
Смысл ООП как раз и заключается в том, чтобы упростить разработку. Если программа после использования принципов ООП стала более запутанной, то это говорит либо о том, что ООП никуда не годится (что навряд ли), либо о том, что программист что-то неверно понял в этом самом ООП (скорее всего).
Попробуем разобраться. Кратенько без «воды».
Любое веб-приложение начинается с идеи. Скорее даже абстрактной идеи, которая в двух словах рассказывает какую проблему клиента нужно решить. После этого идея начинает уточняться: как решить, каким способом, что для этого требуется? Таким образом формируется начальное техническое задание, где не затрагивая непосредственную реализацию, уточняется круг основных задач. На следующем этапе начинают отрабатываться базовые элементы взаимодействия, например регистрация пользователей или ключевые элементы интерфейса.
Таким образом ТЗ постоянно усложняется до тех пор, пока не станет казаться что все нюансы оговорены и можно приступать к реализации проекта.
От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.
Читать дальше...| Результаты |
Идет загрузка…