Еще одним подходом к оригинальности является шаблон моно состояния. Это решение использует трюк, который предлагают объектно-ориентированные языки программирования. У него есть динамические публичные методы, которые устанавливают или возвращают значения статических приватных переменных. Что в свою очередь приводит к тому, что все инстансы (экземпляр, случай, этап) таких классов в итоге имеют доступ к одним и тем же значениям.
Когда: Прозрачность и полиморфизм вместе предпочтительнее чем оригинальность.
Зачем: чтобы спрятать от пользователей/клиентов факт, что объект предоставляет оригинальность.
Обращайте на оригинальность особое внимание. Она подрывает глобальное пространство имен и в большинстве случаев может быть заменена с более лучшим решением, которые подходит для этой конкретной ситуации.
Контроль различных объектов
Шаблон репозиторий является весьма полезной реализацией для методов поиска...
Итак, у вас есть и переключатель и свет. Переключатель может включать и выключать свет, но теперь вы приобрели еще и вентилятор, и желаете использовать старый переключатель вместе с ним. Это легко сделать в физическом мире. Возьмите переключатель, подключите провода и готово.
К сожалению, это нелегко в мире программирования. У вас есть классы Switch и Light. Если Switch использует Light, то каким же образом заставить его использовать Fan?
Легко! Скопировать и вставить класс Switch, а затем поменять его на использование класса Fan. Но это является дублированием кода, что соответствует покупке другого переключателя для вентилятора в реальном мире. Можно расширить Switch до FanSwitch, и вместо него использовать этот объект. Но, что если вам понадобится использовать Button или RemoteControll, вместо Switch?
Шаблон абстрактный сервер
Это самый просто шаблон из всех, когда-либо изобретенных. Он использует только интерфейс. И все, однако существует несколько разных реализаций.
Когда: нужно связать объекты и сохранить гибкость.
Зачем: потому что это наиболее простой способ получить гибкость, при этом соблюдая принцип инверсии зависимостей и открытости-закрытости.
PHP является языком с динамической типизацией. Это означает, что можно опустить интерфейсы и использовать различные объекты в том же контексте - рискуя столкнуться с отказом от наследования. Хотя PHP так же и предоставляет возможность определять интерфейс и я рекомендую вам использовать этот замечательный функционал для более наглядного выражения ваших действий в коде.
Но у вас уже есть куча классов, с которыми вы собираетесь взаимодействовать? Да, конечно же. Есть множество библиотек и сторонних API, а так же других разных модулей, с которыми нам приходится взаимодействовать, но это не означает, что наша бизнес логика должна знать детали работы с ними.
Включаем адаптер
Шаблон адаптер просто обеспечивает взамодействие между бизнес логикой и чем-то другим. Мы уже видели этот шаблон в действии: шаблон шлюз.
Когда: нужно создать взять между уже сущесвтующим и потенциально изменчивым модулями, библиотеками или API.
Зачем: чтобы позволить вашей бизнес логике полагаться на публичные методы адаптера, и легко справляться с изменениями на другой стороне адаптера.
Если любой из выше перечисленных шаблонов не соответствуют вашей ситуации, то можно использовать...
Шаблон мост
Это довольно сложный шаблон. Лично мне он не нравится, так как обычно можно выбрать более простое решение. Но для тех особых случаев, когда другие решения не подходят, можно рассмотреть этот шаблон.
Когда: шаблона адаптер не достаточно и мы вносим изменения в классы со обоих сторон цепочки.
Зачем: чтобы предоставить большую гибкость ценой увеличения сложности.
Шаблон композиция
Рассмотрим скрипт, в котором есть похожие команды, и нам нужно одним вызовом запустить их все. Погодите! Разве мы до этого не рассматривали что-то похожее? Шаблон активный объект?
Да, конечно. Но этот немного отличается. Это шаблон композиция, и так же как шаблон активный объект, он содержит список объектов. Но вызов метода объекта композиции, вызывает этот же метод у всех его объектов, при этом не удаляя их из списка. Клиенты, вызывая метод, думаю, что они общаются с одним единственным объектом определенного типа, хотя в действительности эти действия применяются ко многим объектам композиции.
Когда: нужно применить действие к нескольким схожим объектам.
Зачем: чтобы снизить дублирование и упростить вызов нескольких объектов.
Вот пример: у вас есть приложение, которое может создавать и размещать Orders. Предположим, у вас есть три заказа: $order1, $order2 и $order3. Можно вызывать метод place() у каждого из них, или можно собрать эти заказы в объекте $compositeOrder, и вызвать метод place() у него. Что в свою очередь вызовет метод place() у всех внутренних объектов Order.
Шаблон состояние
Шлюзы только получают и сохраняют сырые данные.
Конечный автомат (FSM) представляет собой модель, которая имеет конечное число определенных состояний. Реализация FSM может быть сложной, и самый простой способ сделать это - использовать оператор switch. Каждое выражение case представляет собой текущее состояние автомата и знает, как активировать следующее состояние.
Но мы уже знаем, что switch...case выражений следует избегать, потому что они создают нежелательные разветвления в наших объектах. Так что забудьте выражение switch... case, и вместо него обратите внимание на шаблон состояние. Шаблон сосотяние складывается из нескольких частей: объект, который координирует работу, интерфейс, представляющий собой абстрактное состояние и несколько реализаций каждого отдельного состояния. Каждое состояние знает, знает, какое состояние будет следующим после него, и само состояние может уведомить координирующий объект, чтобы он установил следующее состояние.
Когда: нужно реализовать логику конечного автомата.
Зачем: чтобы снизить проблемы, возникающие от использования выражения switch...case, и лучше инкапсулировать логику и значение каждого отдельного состояния.
Распределитель питания может иметь класс main, который содержит ссылку на класс state. А возможные классы состояний могут быть следующими: WaitingForCoin, InsertedCoin, SelectedProduct, WaitingForConfirmation, DeliveringProduct, ReturningChange. Каждое состояние выполняет свою работу и создает объект следующего состояния, чтобы передать его классу координатору.