Шаблоны проектирования -Design Patterns

Паттерны проектирования:
элементы объектно-ориентированного программного обеспечения многократного использования
Шаблоны дизайна cover.jpg
Автор «Банда четырех»:
Страна Соединенные Штаты
Тема Паттерны проектирования , программная инженерия , объектно-ориентированное программирование
Издатель Эддисон-Уэсли
Дата публикации
1994 г.
Страницы 395
ISBN 0-201-63361-2
OCLC 31171684
005.1 / 2 20
Класс LC QA76.64 .D47 1995 г.

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

Он оказал влияние на область разработки программного обеспечения и считается важным источником теории и практики объектно-ориентированного проектирования. Было продано более 500 000 копий на английском и 13 других языках. Авторов часто называют Бандой четырех ( GoF ).

История

Книга началась на сессии « Птицы пера» (BoF) на OOPSLA '90, «К руководству по архитектуре», проводимой Брюсом Андерсоном, где Эрих Гамма и Ричард Хелм встретились и обнаружили их общий интерес. Позже к ним присоединились Ральф Джонсон и Джон Влиссидес. Первоначальной датой публикации книги было 21 октября 1994 года с авторским правом 1995 года, поэтому она часто цитируется с 1995 годом, несмотря на то, что была опубликована в 1994 году. Книга была впервые представлена ​​публике на встрече OOPSLA, состоявшейся в Портленде. , Орегон, в октябре 1994 года. В 2005 году ACM SIGPLAN присудил авторам Премию за достижения в области языков программирования в знак признания влияния их работы «на практику программирования и проектирование языков программирования». По состоянию на март 2012 года книга выходила в 40-й тираж.

Вступление

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

В качестве преимуществ интерфейсов над реализацией авторы заявляют :

  • клиенты остаются в неведении о конкретных типах объектов, которые они используют, пока объект придерживается интерфейса
  • клиенты остаются в неведении о классах, реализующих эти объекты; клиенты знают только об абстрактных классах, определяющих интерфейс

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

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

Авторы подробно обсуждают противоречие между наследованием и инкапсуляцией и заявляют, что, по их опыту, дизайнеры злоупотребляют наследованием (Gang of Four 1995: 20). Опасность констатируется следующим образом:

«Поскольку наследование предоставляет подклассу сведения о реализации его родителя, часто говорят, что« наследование нарушает инкапсуляцию »». (Банда четырех 1995: 19)

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

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

Для авторов «делегирование» - это крайняя форма композиции объектов, которую всегда можно использовать для замены наследования. Делегирование включает два объекта: «отправитель» передает себя «делегату», чтобы позволить делегату ссылаться на отправителя. Таким образом, связь между двумя частями системы устанавливается только во время выполнения, а не во время компиляции. В статье Обратный вызов есть дополнительная информация о делегировании.

Авторы также обсуждают так называемые параметризованные типы, которые также известны как обобщенные (Ada, Eiffel, Java , C #, VB.NET и Delphi) или шаблоны (C ++). Они позволяют определять любой тип без указания всех других типов, которые он использует - неуказанные типы предоставляются как «параметры» в точке использования.

Авторы признают, что делегирование и параметризация очень эффективны, но добавляют предупреждение:

«Динамическое программное обеспечение с высокой степенью параметризации труднее понять и создать, чем более статичное». (Банда четырех 1995: 21)

Авторы также различают « агрегирование », когда один объект «имеет» или «является частью» другого объекта (подразумевая, что совокупный объект и его владелец имеют идентичные сроки жизни), и знакомство, когда один объект просто «знает» другой объект. Иногда знакомство называют отношениями «ассоциации» или «использования». Объекты знакомств могут запрашивать операции друг у друга, но они не несут ответственности друг за друга. Знакомство - это более слабая связь, чем агрегирование, и предполагает гораздо более слабую связь между объектами, что часто может быть желательно для максимальной ремонтопригодности проекта.

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

Выкройки по типу

Творческий

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

  • Абстрактная фабрика группирует фабрики объектов, имеющих общую тему.
  • Builder создает сложные объекты, разделяя конструкцию и представление.
  • Фабричный метод создает объекты без указания точного класса для создания.
  • Prototype создает объекты путем клонирования существующего объекта.
  • Синглтон ограничивает создание объекта для класса только одним экземпляром.

Структурные

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

  • Адаптер позволяет классам с несовместимыми интерфейсами работать вместе, оборачивая свой собственный интерфейс вокруг интерфейса уже существующего класса.
  • Мост отделяет абстракцию от ее реализации, так что они могут различаться независимо.
  • Composite объединяет ноль или более похожих объектов, так что ими можно управлять как одним объектом.
  • Декоратор динамически добавляет / переопределяет поведение в существующем методе объекта.
  • Фасад предоставляет упрощенный интерфейс для большого объема кода.
  • Легковес снижает стоимость создания и манипулирования большим количеством похожих объектов.
  • Прокси-сервер предоставляет заполнитель для другого объекта для управления доступом, снижения затрат и упрощения.

Поведенческий

Большинство этих шаблонов проектирования специально связаны с коммуникацией между объектами.

  • Цепочка ответственности делегирует команды цепочке обрабатывающих объектов.
  • Команда создает объекты, которые инкапсулируют действия и параметры.
  • Интерпретатор реализует специализированный язык.
  • Итератор последовательно обращается к элементам объекта, не раскрывая его базовое представление.
  • Посредник допускает слабую связь между классами, будучи единственным классом, который подробно знает свои методы.
  • Memento предоставляет возможность восстановить объект в его предыдущее состояние (отменить).
  • Наблюдатель - это шаблон публикации / подписки, который позволяет нескольким объектам-наблюдателям видеть событие.
  • Состояние позволяет объекту изменять свое поведение при изменении его внутреннего состояния.
  • Стратегия позволяет выбирать один из семейств алгоритмов на лету во время выполнения.
  • Шаблонный метод определяет каркас алгоритма как абстрактный класс, позволяя его подклассам обеспечивать конкретное поведение.
  • Посетитель отделяет алгоритм от структуры объекта, перемещая иерархию методов в один объект.

Критика

Критика была направлена ​​на концепцию шаблонов проектирования программного обеспечения в целом и в отношении шаблонов проектирования в частности. Основная критика шаблонов проектирования заключается в том, что их шаблоны - это просто обходные пути для отсутствующих функций в C ++, заменяющие элегантные абстрактные функции длинными конкретными шаблонами, по сути становясь «человеческим компилятором» или «генерируя вручную расширения некоторых макросов». Пол Грэм писал:

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

Питер Норвиг демонстрирует, что 16 из 23 шаблонов в Design Patterns упрощены или устранены языковыми функциями в Lisp или Dylan . Связанные с этим наблюдения были сделаны Ханнеманом и Кицалесом, которые реализовали несколько из 23 шаблонов проектирования с использованием аспектно-ориентированного языка программирования ( AspectJ ) и показали, что зависимости на уровне кода были удалены из реализаций 17 из 23 шаблонов проектирования и этого аспектно-ориентированного программирование может упростить реализацию шаблонов проектирования.

Также была юмористическая критика, такая как показательный процесс на OOPSLA '99 3 ноября 1999 года и пародия Джима Коплиена на формат под названием « Кондиционер Канзас-Сити ».

В интервью InformIT в 2009 году Эрих Гамма заявил, что в 2005 году авторы книги обсуждали, как они реорганизовали бы книгу, и пришли к выводу, что они бы перекатегоризировали некоторые шаблоны и добавили несколько дополнительных. Гамма хотела удалить паттерн Синглтон, но авторы не пришли к согласию относительно этого.

Смотрите также

Примечания

использованная литература