Шаблоны проектирования
 | Возможно, эту статью необходимо реорганизовать, чтобы она соответствовала рекомендациям Википедии по оформлению . ( Июль 2013 г. ) |
 | |
| Автор | |
|---|---|
| Предмет | Шаблоны проектирования , разработка программного обеспечения , объектно-ориентированное программирование. |
| Издатель | Аддисон-Уэсли |
Дата публикации | 1994 |
| Место публикации | Соединенные Штаты |
| Страницы | 395 |
| ISBN | 0-201-63361-2 |
| ОКЛК | 31171684 |
| 005.1/2 20 | |
| Класс ЛК | QA76.64 .D47 1995 г. |
Шаблоны проектирования: элементы объектно-ориентированного программного обеспечения многократного использования (1994) — книга по разработке программного обеспечения, описывающая шаблоны проектирования программного обеспечения . Книга была написана Эрихом Гаммой , Ричардом Хелмом , Ральфом Джонсоном и Джоном Влиссидесом , с предисловием Грэди Буча . Книга разделена на две части: в первых двух главах рассматриваются возможности и подводные камни объектно-ориентированного программирования, а в остальных главах описываются 23 классических шаблона проектирования программного обеспечения . В книгу включены примеры на C++ и Smalltalk .
Он оказал влияние на область разработки программного обеспечения и считается важным источником теории и практики объектно-ориентированного проектирования. Было продано более 500 000 копий на английском и 13 других языках. [1] Авторов часто называют « Бандой четырёх» ( GoF ). [2] [3] [4] [5]
История разработки и публикаций [ править ]
Книга началась на встрече OOPSLA 1990 года «На пути к справочнику по архитектуре», где Эрих Гамма и Ричард Хелм встретились и обнаружили у них общий интерес. Позже к ним присоединились Ральф Джонсон и Джон Влиссайдс. [6] Книга была первоначально опубликована 21 октября 1994 года под авторскими правами 1995 года и стала доступна публике на заседании OOPSLA 1994 года.
Введение [ править ]
 | Этот раздел может содержать чрезмерное количество сложных деталей, которые могут заинтересовать только определенную аудиторию . ( Октябрь 2020 г. ) |
В главе 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 конструирует сложные объекты, разделяя конструкцию и представление.
- Фабричный метод создает объекты без указания точного класса, который нужно создать.
- Прототип создает объекты путем клонирования существующего объекта.
- Синглтон ограничивает создание объектов для класса только одним экземпляром.
Структурный [ править ]
Структурные шаблоны касаются композиции классов и объектов. Они используют наследование для создания интерфейсов и определяют способы объединения объектов для получения новых функций.
- Адаптер позволяет классам с несовместимыми интерфейсами работать вместе, оборачивая свой собственный интерфейс вокруг интерфейса уже существующего класса.
- Bridge отделяет абстракцию от ее реализации, так что они могут изменяться независимо.
- Компоновка объединяет ноль или более похожих объектов, чтобы ими можно было манипулировать как одним объектом.
- Декоратор динамически добавляет/переопределяет поведение существующего метода объекта.
- Фасад предоставляет упрощенный интерфейс для большого объема кода.
- Flyweight снижает затраты на создание и манипулирование большим количеством однотипных объектов.
- Прокси предоставляет заполнитель для другого объекта для управления доступом, снижения затрат и упрощения.
Поведенческий [ править ]
Большинство шаблонов поведенческого проектирования конкретно связаны с общением между объектами.
- Цепочка ответственности делегирует команды цепочке объектов обработки.
- Команда создает объекты, инкапсулирующие действия и параметры.
- Интерпретатор реализует специализированный язык.
- Итератор последовательно обращается к элементам объекта, не раскрывая его базовое представление.
- Посредник допускает слабую связь между классами, поскольку является единственным классом, который имеет подробные сведения об их методах.
- Memento предоставляет возможность восстановить объект в предыдущее состояние (отменить).
- Observer — это шаблон публикации/подписки, который позволяет нескольким объектам-наблюдателям видеть событие.
- Состояние позволяет объекту изменять свое поведение при изменении его внутреннего состояния.
- Стратегия позволяет выбирать один из семейства алгоритмов «на лету» во время выполнения.
- Метод шаблона определяет скелет алгоритма как абстрактный класс, позволяя его подклассам обеспечивать конкретное поведение.
- Посетитель отделяет алгоритм от структуры объекта, перемещая иерархию методов в один объект.
Прием [ править ]
В 2005 году ACM SIGPLAN вручил авторам Премию за достижения в области языков программирования в знак признания влияния их работы «на практику программирования и дизайн языков программирования». [7]
Критика была направлена на концепцию шаблонов проектирования программного обеспечения в целом и на шаблоны проектирования в частности. Основная критика шаблонов проектирования заключается в том, что их шаблоны являются просто обходными путями недостающих функций в C++, заменяя элегантные абстрактные функции длинными конкретными шаблонами, по сути превращаясь в «человеческий компилятор». Пол Грэм писал: [8]
Когда я вижу закономерности в своих программах, я считаю это признаком проблемы. Форма программы должна отражать только ту проблему, которую она должна решить. Любая другая закономерность в коде является признаком, по крайней мере для меня, того, что я использую недостаточно мощные абстракции — часто я генерирую вручную расширения какого-то макроса, который мне нужно написать.
Питер Норвиг демонстрирует, что 16 из 23 шаблонов проектирования упрощены или устранены языковыми функциями Lisp или Dylan . [9] Соответствующие наблюдения были сделаны Ханнеманом и Кичалесом, которые реализовали несколько из 23 шаблонов проектирования с использованием аспектно-ориентированного языка программирования ( AspectJ ) и показали, что зависимости на уровне кода были удалены из реализаций 17 из 23 шаблонов проектирования и что аспектно-ориентированные программирование может упростить реализацию шаблонов проектирования. [10]
Более беззаботная критика включала показательный суд на заседании OOPSLA 1999 года. [11] и пародия на формат Джима Коплиена под названием «Кондиционер Канзас-Сити».
В интервью InformIT в 2009 году Эрих Гамма заявил, что в 2005 году авторы книги обсуждали, как бы они реорганизовали книгу, и пришли к выводу, что они бы переклассифицировали некоторые шаблоны и добавили несколько дополнительных, таких как объект расширения/интерфейс. , внедрение зависимостей, объект типа и нулевой объект. Гамма хотела удалить паттерн Синглтон, но среди авторов не было единого мнения по этому поводу. [12]
См. также [ править ]
- Шаблон проектирования программного обеспечения
- Шаблоны корпоративной интеграции
- GRASP (объектно-ориентированное проектирование)
- Педагогические шаблоны
Ссылки [ править ]
- ^ Зеху, Эдмунд (26 января 2010 г.). Зеху, Эдмунд (ред.). Pro ODP .NET для базы данных Oracle 11g . Апресс. стр. 351–371. doi : 10.1007/978-1-4302-2821-9_13 – через Springer Link.
- ^ Хусейн, Шахид; Кеунг, Джеки; Хан, Ариф Али (2017). «Влияние использования шаблонов проектирования «банда четырех» на атрибуты качества дизайна» . Международная конференция IEEE по качеству, надежности и безопасности программного обеспечения (QRS) 2017 г. стр. 263–273. дои : 10.1109/QRS.2017.37 . ISBN 978-1-5386-0592-9 . S2CID 21343926 .
- ^ Хант, Джон (26 января 2013 г.). Хант, Джон (ред.). Шаблоны проектирования Scala: шаблоны для практического повторного использования и проектирования . Международное издательство Спрингер. стр. 135–136. doi : 10.1007/978-3-319-02192-8_16 – через Springer Link.
- ^ Алмади, Сара Х.С.; Хушьяр, Даниал; Ахмад, Родина Бинти (26 января 2021 г.). «Неприятные запахи банды четырех шаблонов проектирования: десятилетний систематический обзор литературы» . Устойчивость . 13 (18): 10256. дои : 10.3390/su131810256 .
- ^ Монтейро, Мигель Пессоа; Фернандес, Жоау М. (26 января 2004 г.). Подводные камни реализации аспекта некоторых шаблонов проектирования «банда четырех» . Университет Эстремадуры. ISBN 978-84-688-8889-7 – через repositorium.uminho.pt.
- ^ Ричард Хелм
- ^ «Годовой отчет SIGPLAN за 2005 финансовый год» (PDF) .
- ^ Грэм, Пол (2002). Месть ботаников . Проверено 11 августа 2012 г.
- ^ Норвиг, Питер (1998). Шаблоны проектирования в динамических языках .
- ^ Ханнеманн, Ян (2002). Реализация шаблонов проектирования в Java и AspectJ .
- ↑ Показательный процесс над «бандой четырёх» , Брайан Фут
- ^ Гамма, Эрих; Хелм, Ричард; Джонсон, Ральф (22 октября 2009 г.). «Шаблоны проектирования 15 лет спустя: интервью с Эрихом Гаммой, Ричардом Хелмом и Ральфом Джонсоном» . ИнформИТ (Интервью). Беседовал Ларри О'Брайен. Архивировано из оригинала 20 февраля 2019 года . Проверено 1 сентября 2019 г.