Шаблоны проектирования -Design Patterns
Автор | «Банда четырех»: |
---|---|
Страна | Соединенные Штаты |
Тема | Паттерны проектирования , программная инженерия , объектно-ориентированное программирование |
Издатель | Эддисон-Уэсли |
Дата публикации |
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 обсуждаются методы объектно-ориентированного проектирования, основанные на опыте авторов, которые, по их мнению, приведут к хорошему объектно-ориентированному дизайну программного обеспечения, включая:
- «Программа для интерфейса, а не реализация». (Банда четырех 1995: 18)
- Композиция перед наследованием : «Предпочитайте« композицию объекта »над« наследованием классов ». (Банда четырех 1995: 20)
В качестве преимуществ интерфейсов над реализацией авторы заявляют :
- клиенты остаются в неведении о конкретных типах объектов, которые они используют, пока объект придерживается интерфейса
- клиенты остаются в неведении о классах, реализующих эти объекты; клиенты знают только об абстрактных классах, определяющих интерфейс
Использование интерфейса также приводит к динамическому связыванию и полиморфизму , которые являются центральными особенностями объектно-ориентированного программирования.
Авторы ссылаются на наследование в качестве белого ящика повторного использования , с белым ящиком со ссылкой на видимость, потому что Внутренности родительских классов часто видны на подклассы . Напротив, авторы ссылаются на композицию объектов (в которой объекты с четко определенными интерфейсами динамически используются во время выполнения объектами, получающими ссылки на другие объекты) как повторное использование черного ящика, потому что внутренние детали составных объектов не должны быть видны в коде с использованием их.
Авторы подробно обсуждают противоречие между наследованием и инкапсуляцией и заявляют, что, по их опыту, дизайнеры злоупотребляют наследованием (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 году авторы книги обсуждали, как они реорганизовали бы книгу, и пришли к выводу, что они бы перекатегоризировали некоторые шаблоны и добавили несколько дополнительных. Гамма хотела удалить паттерн Синглтон, но авторы не пришли к согласию относительно этого.
Смотрите также
- Шаблон проектирования программного обеспечения
- Шаблоны корпоративной интеграции
- GRASP (объектно-ориентированный дизайн)
- Педагогические образцы