Курс «Шаблоны проектирования»


Оглавление (нажмите, чтобы открыть):

Курс «Шаблоны проектирования»

Паттерн проектирования – подход к решению какой-то типовой задачи. Ранее мы уже рассмотрели некоторые из них, начиная от разных видов диспетчеризации, заканчивая Стратегией и Фабрикой. Этих паттернов очень много, каждый день придумываются новые, и даже каждый программист имеет какие-то свои паттерны для своих задач.

Паттерны, в общем, не связаны с понятием ООП, но именно в ООП их любят структурировать и описывать. Поэтому эта тема особенно распространена в языках с классовой структурой, например Java, C# или PHP. И большинство этих паттернов сводится к тому, как правильно применять полиморфизм подтипов в разных ситуациях. Вот только некоторые из широко известных, которые опираются на полиморфизм:

  • Адаптер
  • Стратегия
  • Абстрактная фабрика
  • Мост
  • Композит
  • Декоратор
  • Посредник
  • Цепочка ответственности
  • Наблюдатель
  • Состояние
  • Шаблонный метод
  • Посетитель

Шаблоны проектирования для PHP

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

Все шаблоны я писал сам, но, естественно, ориентировался на существующий код и описания (почти всё с википедии и книг по Java). В основном, конечно это Java и C#, поскольку паттерны были придуманы для «больших» языков, а реализации в PHP лишь пытаются повторить их код. Это одна из проблем, поскольку PHP сам по себе уже имеет ряд готовых решений где использование шаблона просто не имеет смысла. Например шаблон Prototype (Прототип) реализуется через clone и ничего придумывать не нужно. Или шаблон Iterator (Итератор) по сути сводится к перебору массива, поскольку массив в PHP — универсальная структура и может содержать не только простые данные, вроде строк и чисел, но и сложные — объекты. Конечно, можно перевести код этих шаблонов с Java на PHP, но большого смысла это иметь не будет, разве что для теоретического изучения.

Шаблонов проектирования много (в моей коллекции сейчас 17 штук) и разобраться в них сходу не получится. Мои варианты шаблонов имеют пару особенностей. Первая — это реальный исполняемый код. То есть вы можете запустить на сервере index.php и получите результат в браузер. Сам шаблон и вся его работа размещена в одном файле для удобства (чтобы не прыгать по нескольким файлам).

Вторая особенность — я постарался убрать всю абстракцию и оставить только тот код, который имеет непосредственное отношение к алгоритму шаблона. К сожалению, почти все существующие примеры и описания паттернов проектирования описывают какую-то жуткую абстракцию реального мира: то уточки, то пиццерии, то мебельные фабрики, то мастера-строители. Это всё интересно читать, но когда дело доходит до программирования, то возникают сложности перенести эту абстракцию на свою реальную задачу: просто неясно как именно эти уточки могут помочь в написании, например роутинга или логирования?

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

Еще часто приводится излишне усложненный код, например типы входных параметров, или лишние интерфейсы, потому что так сделано в примерах на Java. В данном случае — это излишний код, который усложняет понимание сути паттерна.

Ну и самое неприятное, это то, что в Сети порой встречаются авторы, которые приводят ошибочные описания и примеры паттернов. Ну например на одном известном сайте есть утверждение, что Facade (Фасад) не должен сам инстанцировать классы, а должен их принимать как параметры. Это не просто ложное утверждение, а просто противоречит самой сути Фасада.

Я, конечно, не могу утверждать, что мои варианты идеально правильны, но насколько было возможно, то я постарался сделать так, чтобы они отражали основную суть паттерна, которую можно понять сразу при чтении кода. Вместо абстракций, я использую более технические термины: Method, Class, Unit и т.п.

Какие бывают паттерны

Первое, что нужно понять — это типы паттернов. Они делятся на

  • Основные (Fundamental)
  • Порождающие (Creational)
  • Структурные (Structural)
  • Поведенческие (Behavioral)

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

Здесь, опять же, стоит упомянуть, что шаблоны писались не для PHP (его тогда вообще не существовало), поэтому паттерны часто решают проблему, которой просто нет в PHP. Например использование интерфейсов применяется в первую очередь для того, чтобы у разных классов оказался совместимый тип данных (Интерфейс — это один из группы Основных шаблонов). В PHP, где развитая динамическая типизация — основа основ, интерфейсы уже не играют такую существенную роль.

Порождающие шаблоны

Эта группа шаблонов решает задачу инстанцирования (создания) других объектов. Например есть множество мелких классов, которые будут использоваться в одном большом. Или какой-то класс может использовать методы либо одного, либо другого класса: при создании это указывается в виде параметра.

Или, например класс, который имеет определенное поведение при создании: это Singleton (Одиночка) или Multiton (Пул одиночек).

Структурные шаблоны

Эти паттерны создают связи между классами. Например Facade (Фасад) объединяет в себе несколько классов, и предоставляя свой более простой метод обращения.

Поведенческие шаблоны

Самые сложные шаблоны, которые определяют алгоритмы и взаимодействие между классами. Например Strategy (Стратегия) и Template method (Шаблонный метод) задают алгоритмы работы. А Observer (Наблюдатель) создает взаимосвязь между несколькими классами.

Где и как использовать паттерны

На самом деле мы их и так постоянно используем, только многие не знают как они называются. 🙂 Это напоминает игру Бендера из «12 стульев»:

На третьем ходу выяснилось, что гроссмейстер играет восемнадцать испанских партий. В остальных двенадцати черные применили хотя и устаревшую, но довольно верную защиту Филидора. Если б Остап узнал, что он играет такие мудреные партии и сталкивается с такой испытанной защитой, он крайне бы удивился. Дело в том, что великий комбинатор играл в шахматы второй раз в жизни.

Сами по себе паттерны не сделают ваш код лучше, но в некоторых случаях помогут решить стоящие задачи. Всё дело в алгоритмах. Я рекомендую начинать изучение паттернов с их демо-примера (он в конце каждого файла), чтобы понять как именно «запускается» паттерн.

Например многие паттерны «выполняются» очень просто:

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

Здесь сложнее, поскольку мы видим, что один класс принимает другой в виде аргумента.

Здесь мы видим статический класс, который инстанцирует другой просто по имени.

То есть шаблоны используют какой-то вариант инстанцирования других классов: либо где-то внутри себя, либо принимают заранее подготовленный объект. Когда вы будете решать какой шаблон применить в своей работе, то в первую очередь подумайте как именно нужно инстанцировать классы. Потому что в одном случае вы получаете большую гибкость (за счет замены классов), а во втором можете инкапсулировать всю логику и спрятать весь сложный код, предоставив какие-то простые публичные методы.

Шаблоны проектирования в JavaScript

Design Patterns in JavaScript

Откройте для себя современную реализацию шаблонов проектирования в JavaScript.

Этот курс предоставляет исчерпывающий обзор шаблонов проектирования в JavaScript с практической точки зрения. Этот курс, в частности, охватывает шаблоны с использованием:

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

Этот курс предоставляет обзор всех шаблонов проектирования Gang of Four (GoF), как они изложены в их оригинальной книге, вместе с современными вариациями, корректировками, обсуждениями внутреннего использования шаблонов в языке.


Что такое Шаблоны проектирования?

Шаблоны проектирования — это повторно используемые решения общих проблем программирования. Они были популяризированы с помощью книги 1994 года «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения» Эриха Гаммы, Джона Влиссидеса, Ральфа Джонсона и Ричарда Хелма (которые обычно известны как «Банда четырех», отсюда и аббревиатура GoF).

Оригинальная книга GoF book использовала C ++ и Smalltalk для своих примеров, но с тех пор шаблоны проектирования были адаптированы для всех мыслимых языков программирования: C #, Java, Swift, Python и теперь — JavaScript!

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

Курс Шаблоны проектирования

Форма обучения

Целевая аудитория

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

Предварительные требования

• Знания и уверенное использование основных библиотек .NET Framework.
• Опыт программирования на C#.
• Знание ООП.
• Опыт работы с Visual Studio последней версии.

Описание курса
Шаблоны проектирования

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

Наш курс «Шаблоны проектирования» поможет Вам в кратчайшие сроки освоить этот универсальный язык. Вы сможете четко классифицировать задачи проектирования и однозначно описывать наиболее подходящие способы их решения. Каждый шаблон представляет собой инструмент, который Вы будете неоднократно использовать в своей практике, получая при этом все преимущества, которые дают надежные, проверенные временем решения.

Мастер Йода рекомендует:  Ещё о защите e-mail адресов на веб-страницах PHP

Шаблоны проектирования приложений масштаба предприятия

Учебный курс по разработке корпоративных приложений. Содержит подробные описания конкретных типовых решений. Каждое решение содержит сведения о сфере использования и основных аспектах реализации.
Рассматриваются примеры исходного кода на Java и C#.

Цели:

После завершения обучения слушатели смогут:

  • Разделять корпоративные приложения на слои
  • Знать основные подходы к организации бизнес-логики
  • Детально знать механизм объектно-реляционного отображения
  • Организовывать представление данных в Web с использованием системы MCV (модель-представление-контроллер)
  • Понимать принцип параллельной обработки заданий, охватывающих несколько системных транзакций
  • Проектировать интерфейс распределённого доступа к объектам

Целевая аудитория:

разработчики, старшие разработчики

Сертификат:

По итогам обучения каждому слушателю выдается сертификат о прохождении курсов Luxoft Training. Слушатели онлайн курсов получают электронную версию сертификата (на указанный email) по запросу.

Предварительная подготовка – общее:

  • Знание принципов объектно-ориентированного программирования
  • Опыт работы с объектно-ориентированными языками от 1 года
  • Знание UML

Связанные курсы:

Рекомендуемые дополнительные материалы, источники:

1) Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (Gang of Four, GoF)
2) Patterns of Enterprise Application Architecture By Martin Fowler (Addison Wesley, 2002)

Примечание:

Возможны варианты по длительности проведения: 16 и 24 часа.
Материалы курса на английском языке.

Шаблоны проектирования «банды четырёх (GoF)»

Что такое паттерны проектирования?

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

Концепцию паттернов впервые описал Кристофер Александер в книге «Язык шаблонов. Города. Здания. Строительство».

Идея показалась привлекательной авторам Эриху Гамму, Ричарду Хелму, Ральфу Джонсону и Джону Влиссидесу, их принято называть «бандой четырёх» (Gang of Four). В 1995 году они написали книгу «Design Patterns: Elements of Reusable Object-Oriented Software», в которой применили концепцию типовых паттернов в программировании. В книгу вошли 23 паттерна, решающие различные проблемы объектно-ориентированного дизайна.

Зачем знать паттерны?

Самое главная причина — паттерны упрощают проектирование и поддержку программ.

Проверенные решения.

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

Стандартизация кода.

Вы делаете меньше ошибок, так как используете типовые унифицированные решения, в которых давно найдены все скрытые проблемы.


Общий язык.

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

Каталог шаблонов проектирования

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

Порождающие паттерны — это паттерны, которые абстрагируют процесс инстанцирования или, иными словами, процесс порождения классов и объектов. Среди них выделяются следующие:

Абстрактная фабрика (Abstract Factory)

Строитель (Builder)

Фабричный метод (Factory Method)

Прототип (Prototype)

Одиночка (Singleton)

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

Структурные паттерны — рассматривает, как классы и объекты образуют более крупные структуры — более сложные по характеру классы и объекты. К таким шаблонам относятся:

Адаптер (Adapter)

Мост (Bridge)

Компоновщик (Composite)

Декоратор (Decorator)

Фасад (Facade)

Приспособленец (Flyweight)

Заместитель (Proxy)

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

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

H Запоминаем шаблоны проектирования (design pattern) для собеседования и работы. Часть 1 в черновиках

.collapse»>Содержание

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

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

Осторожно: пятничный пост (да — в понедельник, но вот такая вот у меня пятницо 🙂 ), под катом смешные и нелепые картинки.

Паттерны проектирования (они же, Design pattern, они же, шаблоны проектирования, они же Жора, они же Гоша… ) — это набор «рецептов» по построению приложения. Причем «рецептов» достаточно общих.

Давайте рассмотрим их подробнее на аналогах из реального мира (чтобы упростить запоминания для ответов).

I. Порождающие шаблоны

Шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту. (с) Википедия

Проще говоря, это шаблоны для создания других классов.

1) Абстрактная фабрика (Abstract factory).

Аналог — различные вендинговые машины

Представим, что нам требуется разработать сеть разных аппаратов по продаже шоколадок, кофе, печенек. Мы создаем проект некоторого абстрактного аппарата (который может выдавать шоколадок, кофе и печенки). Это будет абстрактная фабрика и абстрактные продукты.

На основе его делаем проекты большого количества реальных аппаратов, которые выдают конкретные виды продуктов. Это реальные фабрики унаследованные от абстрактной.

Они могут выглядеть так:

Но созданы на основе одного и того же проекта абстрактного аппарата.

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

Плюсы:

  1. изолирует конкретные классы;
  2. упрощает замену семейств продуктов;
  3. гарантирует сочетаемость продуктов.

Минусы:

  1. Добавить новый вид продукта достаточно сложно


public interface IButton <
void paint();
>

public interface IGUIFactory <
public IButton createButton();
>

public class WinFactory implements IGUIFactory <
Override
public IButton createButton() <
return new WinButton();
>
>

public class OSXFactory implements IGUIFactory <
Override
public IButton createButton() <
return new OSXButton();
>
>

public class WinButton implements IButton <
Override
public void paint() <
System.out.println(«WinButton»);
>
>

public class OSXButton implements IButton <
Override
public void paint() <
System.out.println(«OSXButton»);
>
>

public class Main <

2) Строитель (Builder).

Класс, который представляет собой интерфейс для создания сложного объекта. (с) вики

Аналог:

… заказ в пиццерии с возможностью выбора компонентов. Вы сами выбираете как создать вашу пиццу из заданных компонент. Сам билдер это повар, а результат его работы — полученный продукт (объект)

А если серьезнее:

3) Прототип (Prototype).

Определяет интерфейс создания объекта через клонирование другого объекта вместо создания через конструктор. (с) вики

Аналог:

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

4) Одиночка (Singleton)

Класс, который может иметь только один экземпляр. (с) вики

Аналоги:

… должность президента страны, должность генерального директора фирмы и т.п.

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

II. Структурные шаблоны

1) Адаптер (Adapter / Wrapper)

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

Аналог:

… синхронный переводчик. Позволяет понимать друг друга самым разным людям (и классам)

2) Компоновщик (Composite pattern)

Объект, который объединяет в себе объекты, подобные ему самому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково. © Вики

Аналог в реальном мире:

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

3) Шаблон фасад (Facade)

Структурный шаблон проектирования, позволяющий скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. © Вики

Аналог:

… прораб на строительстве. Заказчику не обязательно пытаться управлять каждым рабочим на стройке, достаточно объяснить что именно нужно сделать прорабу.

4) Заместитель (Proxy)

Proxy — структурный шаблон проектирования, который предоставляет объект, который контролирует доступ к другому объекту, перехватывая все вызовы (выполняет функцию контейнера) © Вики

Аналог в реальном мире:

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

6) Приспособленец (Flyweight)

Приспособленец — структурный шаблон проектирования, при котором объект, представляющий себя как уникальный экземпляр в разных местах программы, по факту не является таковым. © Вики

Аналог в реальном мире:


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

7) Декоратор (Decorator)

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

Аналог в реальном мире:

Шпион… то есть разведчик, например такой:

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

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

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

Данной статьей мы начинаем серию статей, посвященных паттернам проектирования.

Статьи рассчитаны на тех, кто уже хорошо знает ООП.

Что такое паттерны в программировании

Ну, что ж, давайте сначала разберемся что такое паттерн. А затем плавно перейдем к такому понятию как «паттерны в программировании».

Паттерн — это повторяющийся элемент в различных сферах жизни.

Пример 1: окрас тигра — это паттерн.

Пример 2: Коробка передач — это паттерн.

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

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

Шаблон проектирования / шаблон программирования / паттерн — это типичные способы решения часто возникающих задач в сфере разработки ПО.

ВАЖНО:

Паттерн — это не готовое решение, которое можно откуда-то скопировать и вставить в Вашу программу. Это только общие принципы, которые надо уметь правильно применить.

Мне надо знать паттерны?

  • Паттерны очень часто применяются на практике. Конечно, для начинающих программистов понимание паттернов не всегда заходит легко. Так что наберитесь терпения и учим, учим, учим.
  • Паттерны часто спрашивают на собеседованиях.
  • И самое главное — паттерны предлагают Вам готовые решения. Они помогут Вам сохранить время и усилия, а качество программы повысится.

Откуда они взялись

Хотя сама идея паттернов далеко не новая, популярной она стала после выхода книги «Приёмы объектно-ориентированного проектирования. Паттерны проектирования«. Это произошло в 1994 году. С тех пор мир захватила «шаблономания» ��

Какие они бывают

Есть основные три категории паттернов:

  • Порождающие (Creational Design Patterns)

Эти шаблоны что-то создают. Например, «как создать объект, который нельзя изменить»? «Как создать класс, который будет создавать новые объекты других классов?»?

  • Структурные (Structural Design Patterns)

Отвечают за иерархию классов и интерфейсов. Например, «как заставить объекты с несовместимыми интерфейсами работа вместе»?

  • Поведенческие (Behavioral Design Patterns)
Мастер Йода рекомендует:  Идеология HTML

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

Из чего состоит паттерн?

  • Имя
  • Задача, которую решает паттерн
  • Решение:
    • Структуры классов, составляющих решение;
    • Примера на одном из языков программирования;
  • Связь с другими паттернами

А конкретнее?

Существует 23 классических шаблона проектирования, с которых все и началось. В настоящий момент паттернов намного больше — минимум в 2-3 раза больше.

Здесь о каждом из них мы, конечно, говорить не будем — это много �� Но мы расскажем об основных паттернах в будущих статьях.

Самыми-самыми «базовыми» шаблонами проектирования можно назвать следующие:

  • Singleton («Одиночка»)
  • Builder («Строитель»)
  • Factory («Фабрика»)
  • Wrapper («Обертка»)
  • Proxy («Прокси»)

С них можно начинать изучение паттернов. Ниже в этой статье Вы найдете ссылочки на статьи по этим паттернам.

Что следует знать

Одинаковые ли шаблоны для всех языков программирования?

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

  • 23 паттерна и все? Больше нет?

Паттернов очень много. Более того, кроме трех основных категорий, которые мы описали выше, есть и другие — шаблоны параллельного программирования, архитектурные шаблоны проектирования, и даже антипаттерны!

  • А я могу создать паттерн?

Да, конечно. Останется только всем о нем рассказать ��

Это все, что мы хотели Вам рассказать в данной статье.

Статьи, посвященные конкретным паттернам, Вы найдете по этим ссылочкам:

Надеемся, наша статья была Вам полезна. Также есть возможность записаться на наши курсы. Детальнее у на сайте.

Урок 17. Курс по ООП PHP. Шаблоны проектирования

Дата публикации: 01-06-2020

От автора: продолжаем изучение объектно-ориентированного программирования (ООП) в PHP. При разработке веб-приложений часто приходится решать одни и те же задачи. Для многих из них были найдены универсальные решения, которые и принято называть шаблонами проектирования. Использование шаблонов проектирования в PHP может существенно сэкономить время, помочь выработать общую стратегию построения веб-приложений и упростит процесс создания документации для ваших скриптов. В этом уроке мы с вами рассмотрим тему шаблонов проектирования и познакомимся с одним из них.

Шаблоны игрового программирования. Оглавление и введение

Примерно неделю назад я писал, что заинтересовался этой online-книжкой http://gameprogrammingpatterns.com/ и решил сделать ее перевод. Сам я мог бы ограничиться и английским вариантом, но думаю многим перевод пригодится.

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

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

Замечания и комментарии конечно приветствуются. Картинка только для привлечения внимания, хотя и имеет прямое отношение к предмету разговора.

Теперь насчет самого перевода. У многих терминов в программировании есть перевод устоявшийся. У других общепринятыми считаются сразу несколько вариантов. Кроме этого многие используют англоязычные термины напрямую или их вольную адаптацию на русский. Когда перевод книги готовится к печати, каждое издательство требует чтобы перевод отвечал их стандартам перевода. Все термины переводятся единообразно, даже если это не всегда удобно или понятно читателю. Так как на меня никто не давит, я могу поступать как считаю нужным. Поэтому я буду использовать по возможности устоявшиеся варианты перевода терминов. И в большинстве случаев писать в скобках оригинальное название. Все-таки многие пользуются оригинальными названиями терминов и в найти дополнительную информацию в Google так проще. Так что не обижайтесь. Бумагу мне всетаки экономить не нужно.

Насчет перевода Design Patterns. Мне больше нравится вариант перевода Шаблоны проектирования. Я знаю что оригинальная книга, на которую ссылается автор была у нас переведена как Паттерны программирования. Когда в тексте будет упоминаться книга, я так и буду писать. В остальных случаях я буду писать шаблоны. Кто-то может сказать что в таком случае может возникнуть путаница с другим шаблонами (templates) в C++. Автор книги тоже делает различие между этими двумя понятиями. Но мождете не волноваться. В целях упрощения примеров как вы скоро увидите, автор книги специально не стал использовать templates и другие возможности стандартной библиотеки C++. Чтобы код примеров был понятен даже тем кто программирует на других языках. Так что путаницы не возникнет. Ну а если вы приверженец перевода паттерны проектирования — можете читать вместо шаблоны паттерны.
Еще один часто используемый в книге термин — use case. Я перевожу его как вариант использования. Насколько я знаю переводов существует несколько. Например Прецедент http://ru.wikipedia.org/wiki/Прецедент_(UML) или Сценарий использования. Не знаю какой вариант нравится лично вам, но означают они одно и то же. Я просто предупреждаю что буду использовать «вариант использования», потому что он мне больше нравится.

Сама книга отформатирована в две колонки (основной текст и комментарии). Поэтому я сначала хотел отформатировать отформатировать перевод с помощью таблицы. Но потом посмотрел код на сайте автора и увидел что он использует тег aside из HTML 5. ЖЖ насколько я понимаю его не поддерживает. Поэтому сноски я оформлю с помощью тега ol.

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

За помощь в ловле описок в переводе спасибо Vadim Ashikhman, который вызвался помочь через форум gamedev.ru, а также malan_x

Введение

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

10 PRINT «BOBBY IS RADICAL. «
20 GOTO 10

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

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

В самом конце брошюры с кодами программ находился настоящий монстр — программа, которая занимала несколько полных страниц мелкого кода. Нам потребовалось немало времени прежде чем даже осмелиться за нее взяться. Но это все равно было неизбежно, потому что листинг был озаглавлен как Тоннели и тролли. Мы не имели не малейшего представления что она делает, но название явно намекало на то что это игра. А что может быть интереснее чем собственноручно запрограммированная игра?
Нам так и не удалось ее запустить, а через год нам пришлось освободить этот класс (Только гораздо позже когда я уже постиг основы BASIC я понял что это была всего лишь программа-генератор персонажей для настольной игры, а не сама игра). Тем не менее жребий был брошен — с тех пор я решил для себя что буду игровым программистом.

Когда я еще был подростком у нас дома был Macintosh с QuickBASIC и немного позже с THINK C. Я проводил попытками написания игровых программ все свои летние каникулы. Учиться самому было сложно и даже мучительно. Начинать писать игру всегда было довольно легко — скажем экран с картой или небольшой паззл. Но по мере добавления новых возможностей программировать становилось все сложнее и сложнее. Как только у меня переставало получаться держать всю игру в голове целиком, все рушилось.

Сначала я ставил перед собой задачу вывести на экран хоть что-то. Дальше я начала понимать как писать программы, которые не осмыслишь в голове целиком. Вместо того чтобы просто читать книги наподобие «Как программировать на C++», я начал искать книги о том как организовывать программный код.


    Не одно свое лето я провел за ловлей змеек и черепашек в болотах южной Луизианы. И если бы там не было так жарко, вполне возможно я бы занимался серпентологией и писал бы другие книги.

Через несколько лет друг дал мне книгу Паттерны проектирования: Приемы объектно-ориентированного проектирования (http://oz.by/books/more101783.html). Наконец то! Это была книга, о которой я мечтал еще с подросткового возраста. Я прочел ее от корки до корки за один присест. У меня все еще был и проблемы со своими программами, но мне было приятно видеть что не только у меня одного возникают подобные сложности и есть люди которые нашли способ их преодолеть. Наконец-то у меня появилось ощущение что я работаю не просто голыми руками, а у меня появились инструменты.

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

В 2001-м году я получил работу своей мечты: должность инженера-программиста в Electronic Arts. Я стал настоящим игровым программистом! Я не мог дождаться момента, когда смогу увидеть как выглядят настоящие игры и как профессионалы собирают их целиком. Как им удается создавать такие громадные игры как Madden Football, которые ни у одного человека точно не поместятся в голове? На что похожа их архитектура? Как отделены друг от друга физика и рендеринг? Или как код AI взаимодействует с анимацией? Каким образом абстрагируется работы со звуком для поддержки мультиплатформенности?

Разбираться в исходном коде было одновременно унизительно и удивительно. В графической части, AI, анимации, визуальных эффекта было так много прекрасного кода. У нас были люди, умеющие выжать последние такты из CPU и высвободить их для более нужных вещей. Еще до обеда эти люди успевали делать такие вещи, про возможность которых я даже не подозревал.

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

Конечно не все было настолько плохо. Я ведь представлял себе игровых программистов как сидящих в башне из слоновой кости мудрецов, неделями дискутирующих о каждой мелочи в архитектуре игры. Реальность заключалась в том что я видел код, написанный в условиях жесткого дедлайна для платформы, на которой каждый такт CPU был на вес золота. Люди потрудились на славу и как я понял впоследствии они действительно во многом выбрали лучшее решение. Чем дальше я тратил времени на работу с этим кодом, тем больше я понимал сколько брильянтов он в себе таит.

К сожалению тут уместен именно термин «таит». Это были зарытые в коде алмазы, а прямо по ним топталось еще множество людей. Я наблюдал как люди в мучениях переизобретали решения, прекрасные примеры которых уже находились в коде с которым они работали.

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

Что есть в магазинах?

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

Большинство книг по программированию игр которые я видел делятся на две категории:

  • Узко-специализированные книги. Эти книги концентрируются на чем-то одном и глубоко описывают только этот конкретный аспект игрового программирования. Они учат вас 3D графике, рендерингу в реальном времени, симуляции физики, искусственному интеллекту или работе со звуком. Многие игровые программисты вообще специализируются только в определенной области.
  • Книги обо всем. В противоположность первым, эти книги пытаются охватить все части игрового движка. Они объединяют их вместе и показывают как собрать законченный движок, обычно для 3D FPS.

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

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

В отличие от других моя книга построена по принципу à la carte. Каждая из глав в этой книге представляет собой законченную идею, которую вы можете использовать в своем коде. Таким образом вы получаете возможность смешивать их и использовать только то что лучше всего подходит именно для вашей игры.

    Есть еще один хороший пример принципа à la carte. — хорошо известная серия Жемчужины игрового программирования (Game Programming Gems).

Как все это связано с шаблонами проектирования

Каждая книга, имеющая в заголовке слово «шаблоны» так и ли иначе связана с классической книгой Паттерны проектирования: Приемы объектно-ориентированного проектирования, написанной Эрихом Гаммой, Ричардом Хелмом, Ральфом Джонсоном и Джоном Вличидесом (их еще часто называют «Банда четырех»).

Называя свою книгу «Шаблоны игрового программирования» я вовсе не имею в виду, что книга банды четырех неприменима в играх. Совсем наоборот: вторая часть этой книги как раз обозревает многие из шаблонов, впервые описанных в Паттернах проектирования, но с той точки зрения как они могут быть применены в игровом программировании.

Более того, я считаю что эта книга будет полезна и для тех кто не занимается разработкой игр. Использование описанных шаблонов будет уместным во многих не игровых приложениях. Я вообще мог бы назвать книгу Еще больше шаблонов проектирования, но на мой взгляд игровые примеры выглядят выразительнее. Или вам интереснее в очередной раз читать книгу о списках сотрудников и банковских счетах?

    Паттерны проектирования сами по себе также были написаны под впечатлением от другой книги. Идея создания языка шаблонов, описывающих ничем не ограниченные решения проблем пришла из книги Язык шаблонов ( A Pattern Language) Кристофера Александера (и его соавторов Сары Ишикавы и Мюррея Силверстейна).
    Их книга была посвящена архитектуре (в духе настоящей архитектуры, которая помогает строить дома, стены и т.д.), но они надеялись что и другие смогут использовать подобную структуру для описания решений в других областях. Паттерны проектирования банды четырех стараются применить тот же подход в программировании.

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

  • Время и последовательность действий зачастую являются ключевой частью игровой архитектуры. События должны происходить в правильной последовательности и в нужное время.
  • Цикл разработки предельно сжат и множеству разработчиков необходимо иметь возможность быстро внедрять итерационно менять широкий набор поведения, не наступая друг другу на ноги и не оставляя после себя следов по всей кодовой базе.
  • После того как поведение определено, начинается взаимодействие. Монстры кусают героя, зелья смешиваются, а бомбы взрывают врагов и друзей. Все эти взаимодействия должны реализовываться без превращения кодовой базы в спутанный клубок шерсти.
  • И наконец для игр критична производительность. Игровые разработчики постоянно участвуют в гонке за первенство по максимально эффективному использования своей платформы. Небольшой трюк по сбережению нескольких тактов может отделять игру с наивысшим рейтингом и миллионными продажами от проблем с падением fps и злыми рецензиями.

Как читать эту книгу

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

Вторая часть — Обзор шаблонов проектирования рассматривает несколько шаблонов из книги банды четырех. Относительно каждого я высказываю собственно мнение и описываю его применимость в игровом программировании.

И наконец последняя часть — это сама соль данной книги. В ней описаны тринадцать новых шаблонов, которые я видел в играх. Она делится еще на четыре части: Последовательные шаблоны, Поведенческие шаблоны, Шаблоны уменьшения связности (decoupling) и Оптимизационные шаблоны.

Каждый шаблон внутри раздела описывается в виде стандартизирвоанной структуры так чтобы вам было проще использовать эту книгу для поиска того что вам нужно:

  • Секция Задача представляет собой краткое описание шаблона в терминах задачи, для решения которой он предназначен. Это первое на что вы будете обращать внимание, когда будете искать в книге решение возникших у вас трудностей.
  • Секция Мотивация описывает пример проблемы, которую позволяет решить шаблон. В отличие от алгоритма, без приложения к конкретной проблеме шаблон сам по себе не имеет формы. Изучать шаблоны без примеров — это как учиться печь хлеб не упоминая того как месить тесто. Этот раздел — тесто, которое мы будем печь дальше.
  • Секция Шаблон описывает сущность шаблона из предшествующего примера. Если вам нужно формализованное описание шаблона — вы найдете его здесь. Также вам будет полезно сюда заглянуть, если вы уже знакомы с шаблоном, но подзабыли детали.
  • Итак, шаблон у нас уже описан на конкретном примере. Но как теперь понять что шаблон подходит именно для той проблемы, решением которой вы сейчас заняты? Секция Когда использовать содержит рекомендацию когда шаблон стоит использовать, а когда его лучше избегать. Секция Имейте в виду посвящена последствиям, которые вы получите применив шаблон в своем коде.
  • Если вам как и мне нужен конкретный пример как конкретно чего либо добиться, тогда секция Пример кода для вас. Здесь подробно разбирается реализация шаблона чтобы вы точно смогли понять как он работает.
  • Шаблон — это собственно шаблон решения. Каждый раз когда вы его используете, вы реализовываете его немного по другому. Следующая секция — Архитектурные решения, раскрывает некоторые варианты применения шаблона.
  • И наконец в конце находится еще одна коротенькая секция Смотрите также, в которой описывается связь шаблона с другими и с первоисточниками из Паттернов проектирования. Здесь вы получите более ясную картину какое место занимает шаблон в экосистеме остальных шаблонов.

О примерах кода

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

C++ я выбрал по нескольким причинам. Самая главная из которых заключается в том что на сегодняшний день это самый популярный для написания коммерческих игр язык. Для индустрии это lingua franca. Более того синтаксис C, на который опирается C++ является также основой для Java, C# и многих других языков. Поэтому приведенный в книге код будет понятен без приложения особых усилий и программистам, использующим любой из этих языков.

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

В частности код не использует «модернистские» решения из С++11 или более новых реализаций. В нем не используются стандартные библиотеки и довольно редко используются шаблоны. В результате C++ код получился «плохим», но я не считаю это недостатком потому что таким образом он стал проще и его будет легче понять людям, использующим C, Objective C, Java и другие языки.

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

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

bool update()
<
// Do work.
return isDone();
>

Куда двигаться дальше

Шаблоны — это постоянно обновляющаяся и расширяющаяся часть программирования. Эта книга продолжает начинание банды четырех в области документирования и демонстрации найденных шаблонов и этот процесс не будет остановлен когда высохнут чернила на этих страницах.

Именно вы ключевая часть этого процесса. По мере того как вы будете изобретать новые шаблоны, улучшать (или опровергать!) уже существующие, вы будете приносить пользу всему сообществу разработчиков. Так что если у вас есть свои суждения, дополнения и другие комментарии касательно написанного, прошу выходить на связь.

Мастер Йода рекомендует:  NoSQL — всё по этой теме для программистов
Добавить комментарий