В продолжение предыдущей статьи «Dependency injection (внедрение зависимости)» решил добавить ещё несколько примеров. К этому вопросу я вернулся из-за того, что в Albireo потребовалось сделать небольшой сервис-контейнер и я опять окунулся в эту тему.
В продолжении предыдущей темы, что база программирования важнее самого языка, покажу на примере Turbo Pascal 7.0, что такое объекты в объектно-ориентированном программировании. (Чтобы было понятно, ООП в Паскале появился в 1989 году в версии TP 5.5.)
Если начинать изучать объекты, например с PHP, то не будет понимания, что это вообще такое. Зачем, например оператор new, что такое поля или методы? Такие вещи воспринимаются как часть языка, а всё что внутри — чёрный ящик, где происходят какие-то скрытые процессы. Вообще ООП — это парадигма, то есть описывает вроде как только общие принципы, а конкретная реализация зависит от языка. Но, на самом деле ООП в итоге всё равно превращается в обычный исполняемый код. На мой взгляд важно понимать откуда он берётся.
Тут ещё проблема в том, что изучение ООП обычно начинают с размусоливания про иерархию объектов на примере уточек, птичек и прочей живности. В итоге вместо технического описания, получается невероятная абстракция, которую нужно ещё как-то перенести в реальный код.
Dependency injection (внедрение зависимости) — одна из самых загадочных и запутанных тем для программистов. С одной стороны DI можно описать конкретным php-кодом, но потом выяснится, что он повторяет существующий паттерн программирования. И тогда мы начинаем пускаться в абстракцию, пытаясь хоть как-то объяснить принципиальные различия.
Ситуацию усложняет тот момент, что в разных php-фреймворках подход к этому вопросу сильно разнится: как реализация, так и терминология. Здесь опять же играет тот факт, что PHP заимствует все эти идеи из других языков, но из-за концептуальных различий (например с Java), в итоге приводит к этой самой путанице.
Основное назначение Template method — выделить из основного класса какие-то операции, которые могут быть выполнены классами-наследниками.
Пример кода я разместил на гитхабе.
Смысл шаблона достаточно простой: есть некий абстрактный класс, который реализует всю необходимую логику. Для тех операций, которые могут меняться, создаются абстрактные методы. Также в классе могут быть базовые и «пустые» методы, которые предполагается переопределять в наследниках.
Метод run() содержит алгоритм выполнения. Понятно, что таких методов может быть несколько. Дальше просто: создаются наследники, которые а) реализуют абстрактные методы и б) переопределяют, если нужно, другие.
Если другими словами, то Шаблонный метод не что иное, как наследование, а не композиция. Такой алгоритм очень часто используется в PHP, например во фреймворках (например при создании контролёра или модели).
Шаблон Proxy достаточно точно отражает назначение в своём названии — заменять обращения к реальному классу через посредника. Proxy-класс ещё иногда называют контейнером.
Суть этого шаблона в том, чтобы полностью скрыть реализацию реального класса: то есть мы работаем с Proxy, который уже передаёт обращения к «реальному» классу.
Исходный код на гитхабе.
В той или иной мере этот паттерн используется постоянно, поскольку это ещё один «типовой» вариант композиции.
Приспособленец — структурный шаблон проектирования, который позволяет получать доступ к объектам предотвращая их повторное инстанцирование. Flyweight имеет смысл при работе с множеством мелких однотипных классов, к которым удобно обращаться через единую точку входа.
Исходный код я разместил на гитхабе.
Итак. Пусть у нас есть несколько однотипных классов (ClassA, ClassB, ClassC), которые выполняют какую-то свою работу. При желании можно реализовать их от общего интерфейса.
Когда классов много, то каждый из них не совсем удобно инстанцировать отдельно. Вместо этого создается класс FlyweightFactory: он сам создает объект, но делает это только один раз. При повторном вызове возвращается уже готовый объект. Такой алгоритм позволяет оптимизировать расход памяти программы.
Шаблон Decorator используется там, где нужно расширить функциональность существующего класса. Например вы делаете сайт, где используется какой-то компонент (блок, виджет и т.д.). За это отвечает класс компонента. Потом выясняется, что нужно сделать ещё один компонент для другого вывода. Поскольку все компоненты основаны на одном интерфейсе (или абстрактном классе), то проблем нет. И в какой-то момент, вдруг выясняется, что все компоненты должны поддерживать какую-то новую функциональность, например вывод блока оформления до и после самого компонента.
Очевидно, что переписывать все существующие классы не самая лучшая идея, поэтому здесь на помощь и приходит паттерн Декоратор.