/head-first-design-pattern

Primary LanguagePHP

Head first. Design Pattern

Принципи проектирования

  1. Выделите аспекты приложения, которые могут изменяться, и отделите их от тех, которые всегда остаються постоянными.
    • Выделите то, что изменяеться, и "инкапсулируйте" эти аспекти, чтобы они не влияли на роботу остального кода.
    • Результат? Меньше непревиденных последствий от изменения кода, большая гибкость ваших систем!
  2. Програмируйте на уровне интерфейсов, а не на уровне реализации.
  3. Отдавайте предпочтение композиции перед наследованием.
  4. Слабосвязаные обьекты.
    • Если два обьекта могут взаимодествовать, не обладая практически никакой информацие друг о друге, такие обьекты называються слабосвязанными.
  5. Open/Closed
    • Классы должны быть открыты для расширения, но закрыты для изменения.
  6. Принцип инверсии зависимости
    • Код должен зависить от абстракци, а не от конкретных классов.
    • Высокоуровневые компоненты не должны зависить от низкоуровневых компонентов, вместо этого и те и другие должны зависить от абстракций
  7. Принцип минимальной информированости: общайтесь только с близкими друьями. (in facade pattern)
  8. Не вызывайте нас - мы вас сами вызовем (in template method)
  9. Клас должен иметь только одну причину для изменения (iterator)

Strategy

Паттерн Стратегия определят семейство алгоритмов, инкапсулирует каждый из них и обеспечивает их взаимозаменяемость. Он позволяет модифицировать алгоритмы независимо от их использования на стороне клиента.

Принципи проектирования

  1. Выделите аспекты приложения, которые могут изменяться, и отделите их от тех, которые всегда остаються постоянными.
    • Выделите то, что изменяеться, и "инкапсулируйте" эти аспекти, чтобы они не влияли на роботу остального кода.
    • Результат? Меньше непревиденных последствий от изменения кода, большая гибкость ваших систем!
  2. Програмируйте на уровне интерфейсов, а не на уровне реализации.
  3. Отдавайте предпочтение композиции перед наследованием.

Links:

https://www.youtube.com/watch?v=v9ejT8FO-7I&t=0s&list=PLrhzvIcii6GNjpARdnO4ueTUAVR9eMBpc&index=2

UML

Ducks

Code example

Observer

Паттер Наблюдатель определяет отношение "один-ко-многим" между обьектами таким образом, что при изменении стостояния одного обьекта происходит автоматическое оповещение и обновление всех зависимых обьектов.

Observer

В архитектуре паттерна Наблюдатель между судьектами и наблюдателями существует слабая связь:

  • Единственнок, что знает субьект о наблюдателе, - то, что тот реализует некоторый интерфейс (Observer). Ему не нужно знать никонкретный класс наблюдателя, ни его функциональность... ничего.
  • Новый наблюдатели могут добавляться в любой момент. Так как субьект зависит только от списка обьектов, реализуещих интерфейс Observer, вы можете добавлять новых наблюдателей по своему усмотрению. Любого наблюдателя во время выполнения можно заменить другим наблюдателем или исключить его из списка - субьект этого не заметит.
  • Добавление новых типов наблюдателей не требует модификации субьекта. Допустим, у нас появился новый класс, который должен стать наблюдателем. Вносить изменения в субьект не потребуеться - достаточно реализировать интрфейс Observer в новом классе и зарегестрировать его в качестве наблюдателя. Субьект будет доставлять оповещения любому обьекту, реализуещему интерфейс Observer.
  • Субьекты и наблюдатели могут повторно использоваться независимо друг от друга. Между ними не существует сильных связей, что позволяет повторно использовать их для других целей.
  • Изменения в субьекте или наблюдателе не влияют на другую сторону. Благодаря слабым связям мы можем вносить любые изменения на любой из двух сторон - при условии, что обьект реализует необходимиый интерфейс субьекта или наблюдателя.

Принципи проектирования

  1. Слабосвязаные обьекты.
    • Если два обьекта могут взаимодествовать, не обладая практически никакой информацие друг о друге, такие обьекты называються слабосвязанными.

Examples:

WeatherData - также можна добавить метод setChanged - и оповесчать наблюдателей, только когда changed - true. Observer

Decorator

Паттер Декоратор динамечески наделяет обьекты новыми возможностями и являеться гибкой альтернативой субклассированию в области расширения функцональности.

Decorator

Принципи проектирования

  1. Open/Closed
    • Классы должны быть открыты для расширения, но закрыты для изменения.

Example

Factory Simple

Factory Simple

Example

Pizza

Factory Method

Фабричный метод - определяет интерфейс создания обьекта, но позволяет субклассам выбрать класс создаваемого екземпляра. Таким образом, Фабричный метод делегирует операцию создания экземпляра субклассам.

Фабричный метод отвечает за создание обьектов и инкапсулирует эту операцию в субклассе. Таким образом клиентский код в суперклассе отделяеться от кода создания обьекта в субклассе.

Factory Method

Example

Pizza

Abstract Factory

Паттерн Абстрактная Фабрика предоставлет интерфейс создания семесйства взаимосвязанных или взаимосвязаных обьектов без указания их конкретных классов.

Example

Pizza

TODO

TODO:

  • add relation names for the UML;
  • Add notice about Singleton pattern
  • Last question from the 167 page
  • Read from the proxy pattern