Рецензия: Паттерны объектно-ориентированного проектирования

• О чем книга?
• Зачем нужны паттерны?
• Как излагаются паттерны?
• Фундаментальные понятия
• Виды паттернов проектирования
  • Порождающие паттерны
  • Структурные паттерны
  • Поведенческие паттерны
• Итог

Много раз слышал про эту книгу, ранее был знаком с паттернами из статей в интернете, а теперь решил более углубленно познакомиться с паттернами проектирования "банды четырех".

Материал не простой, но достаточно полезный и местами даже интересный. За один подход не осилить, только практическое применение :)

Вакансии разработчиков очень часто содержат требование "знание паттернов проектирования", мне предстояла смена работы. Кроме того, иногда при общении с коллегами возникали трудности понимания.

Прикрепляю сборник цитат из книги и краткую шпаргалку по паттернам проектирования.

#О чем книга?

Прежде всего, опытный разработчик понимает, что не нужно решать каждую новую задачу с нуля. Вместо этого он старается повторно воспользоваться теми решениями, которые оказались удачными в прошлом.

Именно о таких повторно используемых решениях данная книга. Эти повторные решения называются - паттерны проектирования.

В этой книге под паттернами проектирования понимается описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте.

Однако:

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

#Зачем нужны паттерны?

Эти паттерны проектирования нужны для проектирования архитектуры приложения. Прежде чем начать писать код необходимо представить систему:

Самая трудная задача в объектно-ориентированном проектировании — разложить систему на объекты.

Эти представления выражаются в:

Абстракции, возникающие в ходе проектирования, — ключ к гибкому дизайну.

Системы состоят не только из абстракций, но и из связей между ними:

Общая цель всякого проектирования — свести к минимуму зависимость подсистем друг от друга и обмен информацией между ними.

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

Авторы по этому поводу говорят:

Эти объекты редко возникают во время анализа и даже на ранних стадиях проектирования. Они появляются позднее, при попытках сделать дизайн более гибким и пригодным для повторного использования.

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

Это утвреждение пересеакется с суждением Роберта Мартина в книге Идеальный "программист".

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

#Как излагаются паттерны?

Каждый паттерн описывается подробно по следующим пунктам:

• название
• назначение - что делает, почему и для чего
• список других названий
• мотивация - ситуация, которая может быть решена при помощи рассматриваемого паттерна
• применимость - основные условия для применения, ситуациии в которых можно применить
• структура - схема Object Modeling Technique (OMT)
• участники - классы/объекты/типы участвующие в реализации паттерна
• отношения между участниками
• результаты при использовании данного паттерна
• реализация - о каких сложностях и подводных камнях следует помнить при реализации паттерна
• пример кода на C++/Smalltalk
• известные применения - примеры применения в некоторых известных продуктах
• родственные паттерны

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

#Фундаментальные понятия

Кроме самих паттернов и примеров, авторы объясняют такие фундаментальные понятия, которые заложены в паттерны, как часть архитектуры ПО. Например:

Ассоциирование запроса с объектом и одной из его операций во время выполнения называется динамическим связыванием.

Примесью (mixin class) называется класс, назначение которого — предоставить дополнительный интерфейс или функциональность другим классам. Он отчасти похож на абстрактные классы в том смысле, что не предполагает непосредственного создания экземпляров.

Для любой операции, объявляемой объектом, должны быть заданы: имя операции, объекты, передаваемые в качестве параметров, и значение, возвращаемое операцией. Эту триаду называют сигнатурой операции. Множество сигнатур всех определенных для объекта операций называется интерфейсом этого объекта. Интерфейс описывает все множество запросов, которые можно отправить объекту.

Класс объекта определяет реализацию объекта, то есть внутреннее состояние и реализацию операций объекта. Тип относится только к интерфейсу объекта — множеству запросов, на которые объект способен ответить. У объекта может быть много типов, и объекты разных классов могут иметь один и тот же тип.

В случае наследования класса реализация объекта определяется в терминах реализации другого объекта. Проще говоря, это механизм разделения кода и представления. Напротив, наследование интерфейса (порождение подтипов) описывает, когда один объект можно использовать вместо другого.

Авторы не бросают читателя под шквал неизвестных терминов, наоборот - они постепенно вводят читателя в тему, позволяя проникнуться проблемами разработки без паттернов проектирования и наталкивают на мысли об альтернативах.

#Виды паттернов проектирования

Паттерны делятся на:

• порождающие - связаны с процессом создания объектов
• структурные - имеют отношение к композиции объектов и классов
• паттерны поведения - характеризуют то, как классы или объекты взаимодействуют

#Порождающие паттерны

Использование порождающих паттернов гарантирует, что система написана в категориях интерфейсов, а не реализации.

Список порождающих паттернов (5):

• Abstract Factory (Абстрактная фабрика)
• Builder (Строитель)
• Factory Method (Фабричный метод)
• Protorype (Прототип)
• Singleton (Одиночка)

#Структурные паттерны

В структурных паттернах рассматривается вопрос о том, как из классов и объектов образуются более крупные структуры.

Список структурных паттернов проектирования (7):

• Adapter (Адаптер)
• Bridge (Мост)
• Composite (Компоновщик)
• Decorator (Декоратор)
• Facade (Фасад)
• Flyweight (Приспособленец)
• Proxy (Заместитель)

#Поведенческие паттерны

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

Список поведенческих паттернов проектирования (11):

• Chain Of Responsibility (Цепочка обязанностей)
• Command (Команда)
• Interpreter (Интерпретатор)
• Iterator (Итератор)
• Mediator (Посредник)
• Memento (Хранитель)
• Observer (Наблюдатель)
• State (Состояние)
• Strategy (Стратегия)
• Template Method (Шаблонный метод)
• Visitor (Посетитель)

#Итог

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

Книга понравилась, чувствуется качество и большой опыт авторов. Буду возвращаться к ней неоднократно, так как весь материал объять за раз не получилось, практическое применение позволит закрепить полученные занания. Рекомендую к прочтению.