Еще одна книга по паттернам? Дайте две!

Привет, читатель! Я хочу поговорить с тобой о паттернах проектирования. Знаешь, это такая старая штука, о которой модно было писать в конце прошлого века, и некоторые изверги о них еще иногда спрашивают на собеседованиях. У меня возникла мысль, что пришла пора снова вспомнить о них, но на этот раз рассмотреть их в современных реалиях. А разве есть более подходящий способ это сделать, кроме как взять ... и написать об этом книгу?

Паттерн Итератор

Пред. паттерн: Паттерн Посредник

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

Подробнее – Iterator on Wiki

Мотивация

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

О книге Джошуа Кериевски «Рефакторинг с использованием шаблонов»

Если посмотреть на опыт использования паттернов проектирования, то он разнится от «это самая ценная штука в арсенале разработчика», до «любителям паттернов проектирования нужен особое место в аду, в котором их ждет синглтонная фабрика со стратегией кипячения в абстрактном котле систем с унаследованным кодом». Если говорить проще, то паттерны – это такой инструмент, который в умелых руках будет помогать, а в неумелых – серьезно осложнит сопровождение полученной системы. (Что, на самом деле, характерно для любого инструмента, а не только для паттернов проектирования, см. Культ Карго в программировании.)

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

Паттерн Посредник

Пред. запись: RAII в C#. Локальный Метод Шаблона vs. IDisposable

Назначение: Определяет объект, инкапсулирующий способ взаимодействия множества объектов.

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

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

Подробнее – Mediator on Wiki

Мотивация

В качестве примера, давайте отойдем от темы анализа паттернов проектирования и посмотрим на пример, приведенный Робертом Мартином в своей статье "Принцип инверсии зависимостей" (Robert Martin – Dependency Inversion Principle) и в своей книге "Принципы, паттерны и методики гибкой разработки на языке C#".

RAII в C#. Локальный Метод Шаблона vs. IDisposable

Пред. запись: Шаблонный Метод
След. запись: Паттерн Посредник

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

Одной из ключевой идиом языка С++ является идиома RAII – Resource Acquisition Is Initialization. Главная ее идея заключается в том, что некоторый ресурс, например, память, дескриптор, сокет и т.п. захватывается в конструкторе и освобождается в деструкторе. А поскольку деструкторы локальных объектов вызываются обязательно, независимо от того, по какой причине управление покидает текущую область видимости, мы получаем полуавтоматическое управление ресурсами.

При этом «автоматическое управление» применяется не только для ресурсов – памяти, дескрипторов, файлов или сокетов, но и для других целей. Так например, автоматический вызов деструктора используется в многопоточных приложениях для реализации критических секций в коде. Для этого используются классы std::mutex, а также класс std::unique_lock, который захватывает блокировку в конструкторе и освобождает в деструкторе:

Паттерн Шаблонный Метод

Пред. запись: Паттерн Стратегия
След. запись: RAII в C#. Локальный Метод Шаблона vs. IDisposable

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

Другими словами: шаблонный метод – это каркас, в который наследники могут подставить свои реализации.

Подробнее – Template Method Pattern on Wiki

Общие сведения

На заре своего становления, наследование считалось ключевой концепцией ООП для расширения и повторного использования кода. Однако со временем, многим разработчикам стало очевидно, что наследование не такой уж и простой инструмент, использование которого приводит к сильной связности (tight coupling) между базовым классом и его наследником. Эта связность приводит к сложности понимания иерархии классов, а отсутствие формализации отношений между базовым классом и наследниками не позволяет четко понять, как именно разделены обязанности между классами Base и Derived, что можно делать наследнику, а что – нет.

Паттерн Стратегия

Пред. запись: GoF паттерны на платформе .NET
След. запись: Паттерн Шаблонный Метод

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

Другими словами: стратегия инкапсулирует некоторое поведение с возможностью его подмены.

Подробнее – Strategy Pattern on Wiki

Мотивация

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

GoF паттерны на платформе .NET

След. запись: Паттерн Стратегия

Посты серии:

• Паттерн Стратегия
• Паттерн Шаблонный Метод
• RAII в C#. Локальный Метод Шаблона vs. IDisposable
• Паттерн Посредник

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

Так, когда в начале 90-х на арене программного мира появились паттерны проектирования, многие начали мечтать о том, что благодаря им даже бизнес-пользователи и 1С программисты смогут собирать приложение из готовых кирпичиков. Довольно быстро стало ясно, что этого не случится и начали искать другие подходы, включая программирование через конфигурацию, пламенно воспетую Хантом и Томасом в их «Программисте-прагматике». Затем появились IoC (или DI) контейнеры и начался новый этап создания «слабосвязанных приложений», разбираться с которыми стало еще сложнее, чем прежде благодаря замене «физической» (прямой) связи между компонентами на «логическую» (косвенную).

Критика книги Боба Мартина "Принципы, паттерны и методики гибкой разработки на языке C#"

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

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

Критический взгляд на принцип инверсии зависимостей

DISCLAIMER: У автора этой статьи нет цели подорвать авторитет или каким-то образом обидеть столь уважаемого камрада, как «дядюшка» Боб Мартин. Речь здесь идет скорее о более тщательном обдумывании принципа инверсии зависимостей и анализ примеров, использованных при его описании.

Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) был впервые описан Бобом Мартином в одноименной статье, опубликованной в журнале C++ Report в 1996 году. Затем, практически в неизменном виде он был опубликован в книгах Боба Мартина «Принципы, паттерны и методики гибкой разработки» [Mattin2006].

По ходу статьи я буду приводить все необходимые цитаты и примеры из вышеупомянутых источников. Но чтобы не было «спойлеров» и ваше мнение оставалось объективным, я бы рекомендовал потратить 10-15 минут и ознакомиться с оригинальным описанием этого принципа в статье [Martin96] или книге [Martin96].

Инверсия зависимостей на практике

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

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

DI Паттерны. Property Injection

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

Еще одним достаточно популярным паттерном внедрения зависимостей является Property Injection, который заключается в передаче нужных зависимостей через “setter” свойства. Все современные DI-контейнеры в той или иной мере поддерживают этот паттерн, что делает его использование достаточно простым. Я рекомендую быть осторожным с этим паттерном, поскольку с точки дизайна передача зависимостей через свойства усложняет использование, понимание и поддержку.

Но давайте обо всем по порядку.

DI Паттерны. Constructor Injection

Когда речь заходит о внедрении зависимостей (Dependency Injection), то у большинства разработчиков в голове возникает образ конструктора, через который эта зависимость передается в виде интерфейса или абстрактного класса. Именно об этом виде управления зависимостей писал Боб Мартин в своей статье Dependency Inversion Principle, поэтому не удивительно, что он является самым известным.

Описание

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

Кэширующий декоратор на деревьях выражений

Совсем недавно возникла такая задача. Предположим у нас есть класс, предоставляющий доступ к некоторым удаленным ресурсам. Поскольку эти ресурсы расположены достаточно далеко, то результатами методов провайдера являются задачи (объектами класса Task или Task<T>).

public interface ICustomProvider

{

    Task<int> GetNextId();

    Task<string> GetCustomerName(int id);

    Task<Order> GetOrder(int orderId, string customerName);

}

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

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

DISCLAIMER: не проматывайте этот пост только из-за того, что обзор книг – это неинтересно. Здесь будет пяток интересных цитат и ряд других полезных мыслей!

Если спросить у десяти разработчиков о паттернах проектирования и о том, какая книга является лучшим источником информации по этой теме, то 9 из 10 назовут знаменитую книгу банды четырех и будут правы. GoF – является классическим каталогом паттернов в том виде, в котором он был описан Кристофером Александером 35 лет назад и все еще остается бесценным справочником для любого программиста.

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

Dispose pattern

“Не стоит следовать некоторой идиоме только потому, что так делают все или так где-то написано”
Мысли автора статьи во время чтения и рефакторинга чужого кода

Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь головняк по работе с такими ресурсами ложится на плечи разработчика.

А как же финализаторы? – спросите вы. Ну, да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.

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

Эта статья опубликована в 3-м номере журнала RSDN Magazine за 2009 год.

Введение

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

История зарождения

Труды архитектора и философа Кристофера Александера (Christopher Alexander), такие как “The Pattern Language” (1977), “The Timeless Way of Building” (1979), “Notes On The Synthesis Of Form” (1964) упоминаются в компьютерной литературе не реже, чем труды Дейкстры, Хоара или Кнута. Практически в каждой книге о шаблонах проектирования говорится о серьезном влиянии трудов Александера на область разработки программного обеспечения и в частности на идею создания шаблонов проектирования. Однако шаблоны проектирования – это не единственная область, на которую оказали влияние труды этого замечательного человека. Еще в 1979 году в своей книге “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design” Эд Йордон (Ed Yourdon) и Ларри Константайн (Larry L. Constantine),одни из первых определили фундаментальные понятия модульности ПО, такие как сцепление (cohesion) и связность (coupling), основываясь на понятиях, приведенных в книге Алексендера “Notes On The Synthesis Of Form”.

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

• максимизация связей внутри компонентов (высокое сцепление, high cohesion) и
• минимизация связей между компонентами (низкая связанность, low coupling).

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

Следующим упоминанием трудов Александера, на этот раз книг “The Timeless Way of Building” и “The Pattern Language” стали Том ДеМарко (Tom DeMarco) и Тим Листер (Tim Lister) в своей знаменитой книге “Peopleware: Productive Projects and Teams”, вышедшей в свет в 1987 году. Авторы считают, что окружение является существенным фактором, влияющим на продуктивность человека, занятого интеллектуальным трудом, и в попытке определить идеальное рабочее место ДеМарко и Листер обратили свои взоры на труды знаменитого архитектора. Анализируя удачные рабочие места различных организаций, авторы создали четыре шаблона, которые, по их мнению, существенно повышают комфорт сотрудника и позволяют выполнять свою работу максимально продуктивно.

Идея шаблонов проектирования в области разработки ПО появилась в умах сторонников объектно-ориентированного программирования во второй половине 80-х годов прошлого века. Как и многие другие хорошие идеи, идея повторного использования не только кода, но и архитектурных и проектных решений, пришла в голову одновременно разным экспертам в области разработки программного обеспечения.

Одним из таких экспертов был Кент Бек. Вот что он пишет:

«Впервые я услышал о шаблонах будучи студентом Университета Орегона. Многие студенты, с которыми я жил в общежитии на первом курсе, были из Школы Архитектуры. И поскольку я рисовал планы домов с шести или семи лет, они указали мне на труды Кристофера Александера. Я прочитал его книгу “The Timeless Way of Building” от корки до корки в течение семи месяцев.

Я работал на Tektronix в течение полутора лет, когда я снова столкнулся с трудами Александера. Я нашел потертую старую книгу “Notes on the Synthesis of Form”. Объяснение методологии Александера во вступлении ко второму изданию нашло отражение с моей точкой зрения, что снова меня привело к книге “The Timeless Way of Building”. Мне показалось, что все, что он не любит в архитекторах, я не люблю в разработчиках ПО. Я убедил Варда Каннингема, что мы нашли что-то важное».

В 1987 году Вард Каннингем (Ward Cunningham) и Кент Бек (Kent Beck) поделились своим первым опытом применения языка шаблонов на практике на конференции OOPSLA-87. В то время они оба работали над одним проектом и столкнулись со сложностью проектирования пользовательского интерфейса. Тогда они решили воспользоваться идеей языка шаблонов Кристофера Александера. Александер считал, что наиболее оптимальным является проектирования жилища теми, кто будет в них проживать, т.к. именно они наиболее точно осознают собственные потребности. Кент Бек и Вард Каннингем посчитали эту идею весьма заманчивой и разработали язык шаблонов для проектирования пользовательских интерфейсов пользователями.

«Мы предлагаем радикальное изменение проектирования и реализации, используя концепцию адаптированную из работы Кристофера Александера, архитектора и основателя Центра по изучению структуры окружающей среды (Center for Environmental Structure). Александер предлагает, чтобы дома и офисы проектировались и строились их жителями. Он считает, что эти люди лучше всего знают свои потребности в определенной структуре. Мы согласны с этим мнением и считаем, что тоже самое относится и к компьютерным программам. Пользователь сам должен писать свои программы. Идея выглядит глупой, если взглянуть на размер и сложность зданий и программ, а также множество лет обучения профессии проектировщика. Однако Александер предлагает убедительный сценарий, который основывается на концепции «языка шаблонов».

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

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

В это же время, начиная с 1988 года Эриx Гамма (Erich Gamma), Андре Веинанд (Andre Weinand) и Рудольф Марти (Rudolf Marty) начали работу над объектно-ориентированной библиотекой на С++ под названием “ET++”. В этом же году на конференции OOPSLA’88 они выступают с докладом об этой библиотеке. Эрих также задумался о важности повторного использования проектных решений (или шаблонов) своей библиотеки. В 1991 году Эриху приходит идея написании диссертации на тему шаблонов проектирования и он начинает сотрудничать с другими членами «Банды четырех» для дополнительного изучения этой темы. Именно в 1991 году перед конференцией European Conference of Object-Oriented Programming (ECOOP) Ерих Гамма и Ричард Хелм собрались вместе для создания первого каталога шаблонов проектирования, которые, в конечном счете, стали основой знаменитой книгой “Design Patterns”. Они определили множество шаблонов, включая следующие:

1. Composite
2. Decider
3. Observer
4. Constrainer

Многие из этих шаблонов попали в книгу “Design Patterns”, в то время, как многие другие так и остались неизвестными.

В конце 1988 года Джеймс Коплиен (James Coplien) начал каталогизировать специфичные для С++ низкоуровневые шаблоны, которые он называл идиомами. Ранние черновики этой работы использовались для обучения объектно-ориентированному программированию и С++ в AT&T с начала 1989 года. В 1991 года вышла книга Джеймса Комплиена “Advanced C++ Programming Styles and Idioms”, которую можно считать первой книгой по С++ для продолжающих программистов и первой книгой по шаблонам проектирования.

Питер Код (Peter Coad) также параллельно исследовал вопрос шаблонов проектирования, в результате чего на свет появилась статья в Communications of the ACM в 1992 году.

К этому времени (начало 1990-х годов) интерес к шаблонам проектирования вырос достаточно, чтобы ключевые специалисты в этом вопросе взялись за объединение опыта каждого из них. В 1993 году проводится множество конференций и семинаров, на которых основное внимание уделяется шаблонам проектирования. Поворотным событием в истории шаблонов проектирования становится знаменитая книга Банды четырех, которая впервые была представлена на конференции OOPSLA’94, где было продано 750 копий этой книги, что более чем в семь раз превосходит количество любых технических книг, когда-либо проданных на этой конференции.

История успеха

Книга Design Patterns является одной из самых популярных технических книг за всю историю, о ней вот уже пятнадцать лет пишут статьи, ссылаются в других книгах, обсуждают, критикуют, хвалят. По некоторым сведениям эта книга является самой продаваемой компьютерной книгой за всю историю (на начало 2009 года продано более 350 000 экземпляров и ежемесячно продается более 1000).

После выхода книги банды четырех тема шаблонов проектирования стала доступна не только в академических кругах, но и стала активно обсуждаться и применяться простыми разработчиками. Тема шаблонов проектирования активно затрагивается на различных коференциях и семинарах, включая OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) и PLoP (Pattern Languages of Programs). О шаблонах проектирования вышло множество книг. Часть из них продолжают исследование классических шаблонов проектирования, поднятых бандой четырех в своей книге, но помимо этого, шаблоны стали заполнять все большее и большее количество смежных областей. Сегодня шаблоны практически повсюду: существуют шаблоны кодирования, шаблоны рефакторинга, шаблоны реализации корпоративных приложений, шаблоны работы с базами данных, шаблоны распределенных приложений, шаблоны работы с многопоточностью и множество других.

Шаблоны проектирования получили весьма широкое распространение, но несмотря на это они в течение длительного времени оставались прерогативой архитектора и разработчика, а не менеджера. Но за последние несколько лет эта картина начала меняться. Вслед за книгой  Джеймса Коплиена и Нила Харрисона “Organizational Patterns of Agile Software Development” вышла книга Тома ДеМарко, Тима Листера и др. “Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior”, посвященная шаблонам поведения программных проектов.

Рассматривая историю возникновения шаблонов проектирования и их непосредственную близость к языку шаблонов Кристофера Александера нельзя не отметить существенные различия. Несмотря на распространения идеи шаблонов, язык шаблонов в понимании Александера так и не был создан. Существуют шаблоны, предназначенные для решения различных задач, шаблоны для различных уровней абстракции и различных уровней иерархии системы. Эти шаблоны каким-то образом связаны с другими шаблонами более высокого и более низкого уровней, но при этом эта связь не является жесткой и формальной, в результате даже опытный разработчик не может описать всю систему с помощью какого-либо языка шаблонов. О шаблонах проектирования знают многие разработчики, проектировщики, архитекторы, но об этом явлении совершенно ничего не известно пользователям, хотя именно эта идея лежит в основе языка шаблонов Александера. Александер считал, что пользователь лучше всего знает свои нужды и если им дать формальный инструмент, то с его помощью они сами смогут построить лучшие прототипы, которые впоследствии будут реализованы командой разработчиков. Эту идею пытались развить Кент Бек и Вард Каннингем в самом начале своей работы с шаблонами, и даже получили положительные результаты, но идея шаблонов пошла по другому пути, который привел к повторному использованию идей командой разработчиков, но без участия в этом процессе конечного пользователя. На сегодняшний день основная роль шаблонов – это повторное использование опыта в различных областях разработки ПО, устранение коммуникационного барьера внутри команды разработчиков и между ними, повышение качества создаваемого продукта, за счет использования проверенных годами решений. Шаблоны не стали «серебряной пулей», но они сделали достаточно для компьютерного сообщества, чтобы к этому явлению относились с уважением и знали не только, что из себя представляют шаблоны проектирования, но и знали историю этого феномена.

Литература

1. Christopher Alexander, Notes On The Synthesis Of Form, 1964
2. Christopher Alexander, The Pattern Language, 1977
3. Christopher Alexander, The Timeless Way of Building, 1979
4. Edward Yourdon, Larry L. Constantine, Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, 1979
5. Tom DeMarco, Timothy Lister, Peopleware: Productive Projects and Teams, 1999
6. Kent Beck, Ward Cunningham, Using Pattern Languages for Object-Oriented Programs, OOPSLA-87
7. James Coplien, Software Patterns, 1996
8. Jonathan Erickson, Dr. Dobb's Journal, March 1998
9. James Coplien, Advanced C++ Programming Styles and Idioms, 1991
10. Erich Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software, 1994