Недавно я прочитал книгу Gof “Паттерны проектирования” и хотел бы поделиться своими мыслями на ее счет.
Книга является классикой и предлагает варианты решения проблемы написания кода, который бы был минимально связан и хорошо расширяемый.
В качестве примера приводится создание текстового редактора с GUI. Так как для объектно-ориентированного подхода графические приложения являются лучшей демонстрацией.
Порождающие паттерны
- абстрактная фабрика - интерфейс для создания семейства связанных объектов, как правило реализуется помощью абстрактных методов (см. ниже).
- строитель - все конструкторы объекта вынесены в отдельные классы в соответствии с представлениями, а главный класс строителя управляет ими.
- абстрактный метод - определяет у класса пустой метод (интерфейс), и позволяет потомкам задать его обработку.
- прототип - создает новые объекты путём копирования класса-прототипа.
- одиночка - гарнтирует что у класса один экземпляр, с глобальной точкой доступа.
Структурные паттерны
- адаптер - строит интерфейс работы одного класса с другим (wrapper). Его цель устранить несовместимость между двумя интерфейсами.
- мост - отделяет абстракцию от реализации, чтобы их можно было изменять независимо. В отличии от адаптера он помогает сделать стабильный интерфейс, не зависящий от классов которые его реализуют.
- компановщик - служит для предоставления иерархий часть-целое. В свою очередь клиент не понимает с каким объектом он работает с простым или составным (иерархией), для него все это один объект.
- декоратор - добавляет динамическую функциональность в объект, что может являться альтернативой наследования.
- фасад - интерфейс работы с подсистемой, используется для обеспечения низкой связанности подсистем. Все запросы клиента приходят в класс “фасад” а он их уже перенаправляет нужному классу подсистемы.
- приспособлец - объект, который может существовать в нескольких контекстах одновременно. Данный объект имеет 2 состояния: внутреннее и внешнее, причём внутреннее состояние не должно зависить от контекста, внешнее - наоборот зависит от контекста.
- заместитель - контролирует и защищае доступ к другому объекту.
Паттерны поведения
- цепочка обязанностей - служит для уменьшения связанности и передает обработку какого-либо события по цепочке выполнения.
- команда - скрывает запрос к объекту, позволяя задовать параметры к запросу.
- интерпритатор - определяет грамматику простого языка интерпретирует приложения на нем.
- итератор - предоставляет последовательный доступик элементам составного объекта, не зная о их содержании
- посредник - служит для обеспечения низкой связанности при коммуникации классов.
- хранитель - сохраняет в себе внутреннее состояние другого объекта.
- наблюдатель - суть его в том, что при изменении какого-либо объекта, зависящие от него объекты автоматически обновляются.
- состояние - позволяет объекту варьировать своё поведение взависммости от внутреннего состояния.
- стратегия - определяет семейство алгоритмов и делает таким образом алгоритмы легко заменяемыми. Каждый алгоритм выбирается исходя из обстоятельств.
- шаблонный метод - создаёт скилет алгоритма, и позволяет менять его части не изменяя структуру в целом.
- посититель - описывает операцию выполняемую каждым объектом из некторой структуры. Посетитель может добавить новую операцию не изменяя класс объекта.
Выводы
В целом большинство паттернов интуитивно понятны, и их можно применять даже не зная, что они где-то описаны. У моём случае это так и происходило. В последнее время на сабеседованиях часто задают вопросы о паттернах, но смысл этого для меня не ясен. Так как я уже написал их знание никак не коррелирует с качеством кода.
Так же надо заметить, что эти же паттерны, могут использоваться и в системах, нет где нет ООП в стандартном его понимании, например написанных на современном Go.
Кроме этого после прочтения книги у меня сложилось впечатление, что многие паттерны привносят в реализацию симтемы излишнюю сложность и большой оверхед, хотя авторы и сами это признают.
Однако если рассматривать данные паттерны не с точки зрения ООП, а, допустим, как отдельные компоненты системы (сервисы), то их применение просит большую ясность именно с архитектурной точки зрения. Я думаю, если бы авторы приводили примеры именно с этой позиции книга бы принесла больше пользы и смотрелась бы более универсально.
Поэтому книгу бы я рекомендовал читать, когда у вас уже есть опыт практической работы с разработкой разного уровня систем, чтобы вы смогли наложить описанные паттерны на свой опыт.
comments powered by Disqus