Что такое паттерн в программировании
Перейти к содержимому

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

  • автор:

Что такое Паттерн?

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

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

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

Если привести аналогии, то алгоритм — это кулинарный рецепт с чёткими шагами, а паттерн — инженерный чертёж, на котором нарисовано решение, но не конкретные шаги его реализации.

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

Описания паттернов обычно очень формальны и чаще всего состоят из таких пунктов:

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

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

Refactoring.Guru

  • Премиум контент
    • Книга о паттернах
    • Курс по рефакторингу
    • Введение в рефакторинг
      • Чистый код
      • Технический долг
      • Когда рефакторить
      • Как рефакторить
      • Раздувальщики
        • Длинный метод
        • Большой класс
        • Одержимость элементарными типами
        • Длинный список параметров
        • Группы данных
        • Операторы switch
        • Временное поле
        • Отказ от наследства
        • Альтернативные классы с разными интерфейсами
        • Расходящиеся модификации
        • Стрельба дробью
        • Параллельные иерархии наследования
        • Комментарии
        • Дублирование кода
        • Ленивый класс
        • Класс данных
        • Мёртвый код
        • Теоретическая общность
        • Завистливые функции
        • Неуместная близость
        • Цепочка вызовов
        • Посредник
        • Неполнота библиотечного класса
        • Составление методов
          • Извлечение метода
          • Встраивание метода
          • Извлечение переменной
          • Встраивание переменной
          • Замена переменной вызовом метода
          • Расщепление переменной
          • Удаление присваиваний параметрам
          • Замена метода объектом методов
          • Замена алгоритма
          • Перемещение метода
          • Перемещение поля
          • Извлечение класса
          • Встраивание класса
          • Сокрытие делегирования
          • Удаление посредника
          • Введение внешнего метода
          • Введение локального расширения
          • Самоинкапсуляция поля
          • Замена простого поля объектом
          • Замена значения ссылкой
          • Замена ссылки значением
          • Замена поля-массива объектом
          • Дублирование видимых данных
          • Замена однонаправленной связи двунаправленной
          • Замена двунаправленной связи однонаправленной
          • Замена магического числа символьной константой
          • Инкапсуляция поля
          • Инкапсуляция коллекции
          • Замена кодирования типа классом
          • Замена кодирования типа подклассами
          • Замена кодирования типа состоянием/стратегией
          • Замена подкласса полями
          • Разбиение условного оператора
          • Объединение условных операторов
          • Объединение дублирующихся фрагментов в условных операторах
          • Удаление управляющего флага
          • Замена вложенных условных операторов граничным оператором
          • Замена условного оператора полиморфизмом
          • Введение Null-объекта
          • Введение проверки утверждения
          • Переименование метода
          • Добавление параметра
          • Удаление параметра
          • Разделение запроса и модификатора
          • Параметризация метода
          • Замена параметра набором специализированных методов
          • Передача всего объекта
          • Замена параметра вызовом метода
          • Замена параметров объектом
          • Удаление сеттера
          • Сокрытие метода
          • Замена конструктора фабричным методом
          • Замена кода ошибки исключением
          • Замена исключения проверкой условия
          • Подъём поля
          • Подъём метода
          • Подъём тела конструктора
          • Спуск метода
          • Спуск поля
          • Извлечение подкласса
          • Извлечение суперкласса
          • Извлечение интерфейса
          • Свёртывание иерархии
          • Создание шаблонного метода
          • Замена наследования делегированием
          • Замена делегирования наследованием
          • Введение в паттерны
            • Что такое Паттерн?
            • История паттернов
            • Зачем знать паттерны?
            • Критика паттернов
            • Классификация паттернов
            • Фабричный метод
            • Абстрактная фабрика
            • Строитель
            • Прототип
            • Одиночка
            • Адаптер
            • Мост
            • Компоновщик
            • Декоратор
            • Фасад
            • Легковес
            • Заместитель
            • Цепочка обязанностей
            • Команда
            • Итератор
            • Посредник
            • Снимок
            • Наблюдатель
            • Состояние
            • Стратегия
            • Шаблонный метод
            • Посетитель
            • C#
            • C++
            • Go
            • Java
            • PHP
            • Python
            • Ruby
            • Rust
            • Swift
            • TypeScript

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

            Паттерны (или шаблоны) проектирования описывают типичные способы решения часто встречающихся проблем при проектировании программ.

            Каталог паттернов

            Каталог паттернов

            Список из 22-х классических паттернов, сгруппированых по предназначению.

            Польза паттернов

            Польза паттернов

            Вы можете вполне успешно работать, не зная ни одного паттерна. Но зная паттерны, вы получаете ещё один инструмент в свой личный набор профессионала.

            Классификация

            Классификация паттернов

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

            История паттернов

            История паттернов

            Кто и когда придумал паттерны? Можно ли использовать язык паттернов вне разработки программного обеспечения?

            Критика паттернов

            Критика паттернов

            Так ли паттерны хороши на самом деле? Всегда ли можно их использовать? Почему, иногда, паттерны бывают вредными?

            Погружение в Паттерны

            Книга о паттернах: Погружение в Паттерны Проектирования

            Электронная книга о паттернах и принципах проектирования. Доступна в PDF/EPUB/MOBI. Включает в себя архив с примерами на 9 языках программирования.

            Refactoring.Guru

            • Премиум контент
              • Книга о паттернах
              • Курс по рефакторингу
              • Введение в рефакторинг
                • Чистый код
                • Технический долг
                • Когда рефакторить
                • Как рефакторить
                • Раздувальщики
                  • Длинный метод
                  • Большой класс
                  • Одержимость элементарными типами
                  • Длинный список параметров
                  • Группы данных
                  • Операторы switch
                  • Временное поле
                  • Отказ от наследства
                  • Альтернативные классы с разными интерфейсами
                  • Расходящиеся модификации
                  • Стрельба дробью
                  • Параллельные иерархии наследования
                  • Комментарии
                  • Дублирование кода
                  • Ленивый класс
                  • Класс данных
                  • Мёртвый код
                  • Теоретическая общность
                  • Завистливые функции
                  • Неуместная близость
                  • Цепочка вызовов
                  • Посредник
                  • Неполнота библиотечного класса
                  • Составление методов
                    • Извлечение метода
                    • Встраивание метода
                    • Извлечение переменной
                    • Встраивание переменной
                    • Замена переменной вызовом метода
                    • Расщепление переменной
                    • Удаление присваиваний параметрам
                    • Замена метода объектом методов
                    • Замена алгоритма
                    • Перемещение метода
                    • Перемещение поля
                    • Извлечение класса
                    • Встраивание класса
                    • Сокрытие делегирования
                    • Удаление посредника
                    • Введение внешнего метода
                    • Введение локального расширения
                    • Самоинкапсуляция поля
                    • Замена простого поля объектом
                    • Замена значения ссылкой
                    • Замена ссылки значением
                    • Замена поля-массива объектом
                    • Дублирование видимых данных
                    • Замена однонаправленной связи двунаправленной
                    • Замена двунаправленной связи однонаправленной
                    • Замена магического числа символьной константой
                    • Инкапсуляция поля
                    • Инкапсуляция коллекции
                    • Замена кодирования типа классом
                    • Замена кодирования типа подклассами
                    • Замена кодирования типа состоянием/стратегией
                    • Замена подкласса полями
                    • Разбиение условного оператора
                    • Объединение условных операторов
                    • Объединение дублирующихся фрагментов в условных операторах
                    • Удаление управляющего флага
                    • Замена вложенных условных операторов граничным оператором
                    • Замена условного оператора полиморфизмом
                    • Введение Null-объекта
                    • Введение проверки утверждения
                    • Переименование метода
                    • Добавление параметра
                    • Удаление параметра
                    • Разделение запроса и модификатора
                    • Параметризация метода
                    • Замена параметра набором специализированных методов
                    • Передача всего объекта
                    • Замена параметра вызовом метода
                    • Замена параметров объектом
                    • Удаление сеттера
                    • Сокрытие метода
                    • Замена конструктора фабричным методом
                    • Замена кода ошибки исключением
                    • Замена исключения проверкой условия
                    • Подъём поля
                    • Подъём метода
                    • Подъём тела конструктора
                    • Спуск метода
                    • Спуск поля
                    • Извлечение подкласса
                    • Извлечение суперкласса
                    • Извлечение интерфейса
                    • Свёртывание иерархии
                    • Создание шаблонного метода
                    • Замена наследования делегированием
                    • Замена делегирования наследованием
                    • Введение в паттерны
                      • Что такое Паттерн?
                      • История паттернов
                      • Зачем знать паттерны?
                      • Критика паттернов
                      • Классификация паттернов
                      • Фабричный метод
                      • Абстрактная фабрика
                      • Строитель
                      • Прототип
                      • Одиночка
                      • Адаптер
                      • Мост
                      • Компоновщик
                      • Декоратор
                      • Фасад
                      • Легковес
                      • Заместитель
                      • Цепочка обязанностей
                      • Команда
                      • Итератор
                      • Посредник
                      • Снимок
                      • Наблюдатель
                      • Состояние
                      • Стратегия
                      • Шаблонный метод
                      • Посетитель
                      • C#
                      • C++
                      • Go
                      • Java
                      • PHP
                      • Python
                      • Ruby
                      • Rust
                      • Swift
                      • TypeScript

                      Паттерн (шаблон)

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

                      «IT-специалист с нуля» наш лучший курс для старта в IT

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

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

                      Кроме паттернов, существуют антипаттерны проектирования — это плохие решения, неэффективные. Применять их считается дурным тоном.

                      Профессия / 8 месяцев
                      IT-специалист с нуля

                      Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

                      vsrat_7 1 (1)

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

                      Паттерны используют программисты на разных языках, в первую очередь те, которые занимаются объектно-ориентированным программированием. Само понятие паттерна тесно связано с ООП: этот подход позволяет разбить структуру программы на формализованные классы и объекты. Решение строится из них, как из кирпичиков. Такой вид разработки хорошо сочетается с паттернами.

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

                      Для чего нужны паттерны

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

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

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

                      Кроме того, использование паттернов еще и улучшает читаемость кода. Другой программист, знакомый с нужным паттерном, сможет увидеть его в коде и понять, как все реализовано. А ведь в разработке обычно задействовано несколько специалистов – коммуникация между ними упрощается.

                      Как устроены паттерны

                      Типичный паттерн — это формализованное решение какой-либо проблемы. Оно может быть представлено как алгоритм или как схема, блоки которой означают части программы.

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

                      Отличия паттернов проектирования от архитектурных

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

                      Если упростить, архитектурный паттерн отвечает на вопрос «как будет устроен продукт». Например, модель MVC — архитектурный паттерн.

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

                      Еще есть идиомы — это тоже формализованные способы решения проблем, но зависящие от языка программирования. Они реализуются на еще более мелком уровне для решения конкретных задач – например, утечки памяти.

                      Курс для новичков «IT-специалист
                      с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить

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

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

                      • «Фабрика» (Factory) — для создания новых объектов придумывают отдельный класс. Он создает объекты как копии некоего эталона;
                      • «Прототип» (Prototype) — объект сам создает свои копии;
                      • «Строитель» (Builder) — похож на фабрику, но новые объекты можно модифицировать. Они создаются по сложной логике, а не копируют эталонный;
                      • «Одиночка» (Singleton) — подразумевает наличие одного большого объекта, который имеет глобальный доступ ко всему;
                      • «Ленивая инициализация» (Lazy Initialization) — метод, при котором объект инициализируется не сразу, а по мере необходимости.

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

                      Структурные. Если порождающие паттерны отвечают за создание и взаимодействие объектов, то структурные — за то, как эти объекты структурированы в коде. Они описывают, каким образом простые классы и объекты «собираются» в более сложные.

                      • «Декоратор» (Decorator) — шаблон для подключения дополнительного поведения к объекту;
                      • «Компоновщик» (Composite) — паттерн, который объединяет несколько объектов в древовидную структуру;
                      • «Мост» (Bridge) — принцип разделения сущности на абстракцию и реализацию, чтобы теоретическая структура и конкретный объект могли изменяться независимо;
                      • «Фасад» (Facade) — метод для сведения внешних вызовов к одному объекту;
                      • «Заместитель» (Proxy) — паттерн, похожий на «Фасад», но со специальным объектом-заместителем, который контролирует доступ к основному.

                      Это только некоторые примеры. Реальных паттернов намного больше.

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

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

                      • «Итератор» (Iterator) — один объект последовательно дает доступ к разным другим, при этом не использует их сложные описания;
                      • «Наблюдатель» (Observer) – шаблон, при котором объекты узнают об изменениях в других;
                      • «Хранитель» (Memento) — помогает сохранить объект в каком-то состоянии с возможностью вернуться к нему в будущем;
                      • «Цепочка ответственности» (Chain of Responsibility) — распределяет ответственность за те или иные задачи на разные объекты;
                      • «Посредник» (Mediator) — организует слабые связи между объектами, чтобы снизить их зависимость друг от друга.

                      Как понять, какой паттерн применить

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

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

                      Это выглядит сложно, но со временем придет привычка. Опытные разработчики уже «набили руку», поэтому проблемы с выбором паттерна у них возникают намного реже. Когда сформируется понимание и наберется практика, будет проще.

                      Преимущества паттернов проектирования

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

                      Недостатки паттернов проектирования

                      • Использование паттернов ради паттернов, наоборот, усложняет код и запутывает разработчиков.
                      • Неправильное применение того или иного шаблона способно сделать программу менее эффективной.
                      • Паттерны неуниверсальны: в одной задаче конкретный паттерн подойдет, в другой нет.
                      • На ранних этапах изучения бывает сложно выбрать подходящий для конкретной проблемы паттерн.
                      • Из-за сильной связи с объектно-ориентированным программированием использование паттернов в других парадигмах ограничено. Хотя, например, в функциональном программировании они могут применяться — просто реализуются иначе.

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

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

                      Более того: на собеседованиях уровня Middle и выше почти всегда спрашивают, знаком ли соискатель с паттернами проектирования. То есть их знание и умение ими пользоваться — практически обязательное условие для программиста уровня выше начального. И неважно, на чем вы пишете: Python, Java, JavaScript или что-нибудь еще.

                      Как начать работать с паттернами

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

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

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

                      IT-специалист с нуля

                      Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.

                      картинка (75)

                      Статьи по теме:
                      Разбор профессии и подборка востребованных специальностей

                      Рассказ о профессии дата-инженера: автоматизация, организация хранилища данных и лайфхаки по борьбе с рутиной

                      Казалось бы, простой вопрос: что такое паттерны проектирования?

                      image

                      В индустрии разработки ПО есть ряд тем, о которых ведутся споры почти в каждой компании. Я считаю, что история паттернов проектирования — одна из них. Можно найти сколько угодно постов, статей и ответов на Quora/Stackoverflow в пользу и не в пользу паттернов проектирования. Например, на днях я наткнулся на этот старый вопрос на Quora:

                      «Почему сейчас программисты меньше говорят о паттернах проектирования? Какие паттерны (если они есть) все еще представляют ценность?»

                      Автор имел в виду паттерны объектно-ориентированного проектирования или 23 паттерна, представленные в книге «Банды четырех», и большинство людей, отвечавших на вопрос, предположили, что так оно и есть. Однако «паттерн проектирования» — это термин, который зачастую приравнивается к«паттернам объектно-ориентированного проектирования» — так что не удивляйтесь, когда встретите странное заявление: «паттерны проектирования мертвы».

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

                      Что значат паттерны проектирования для вас?

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

                      Для меня это как внутренний голос, подсказывающий: «не изобретай велосипед!». Возможно, вы испытывали желание начать процесс проектирования/сборки сразу после того, как вам была поставлена задача, и создали свое собственное решение — если так, добро пожаловать в клуб. Но в этом случае, если решение уже существует, разработка нового решения просто отнимает лишнее время и силы. Хотя желание сразу же приступить к разработке собственного решения может со временем притупиться, я считаю, что одним из важнейших инструментов, помогающих преодолеть это желание, является концепция паттерна проектирования.
                      Паттерны проектирования напоминают мне о том, что многие программисты уже сталкивались с той же задачей ранее и решили ее определенным образом по ряду причин. Вероятно, на то есть причины, и это дает нам возможность увидеть задачу в новом ракурсе, даже если мы не собираемся следовать этому паттерну.

                      Давайте обсудим абзац из первой главы к знаменитой книге GoF:

                      «Все мы знаем о ценности опыта. Сколько раз при проектировании вы испытывали дежавю, чувствуя, что уже когда-то решали такую же задачу, только никак не сообразить, когда и где? Если бы удалось вспомнить детали старой задачи и ее решения, то не пришлось бы придумывать все заново. Увы, у нас нет привычки записывать свой опыт на благо другим людям, да и себе тоже. »

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

                      Теперь давайте подробно разберём некоторые фундаментальные понятия и определения.

                      Что понимается под паттернами?

                      Что такое паттерн? Концепция паттерна не является чем-то специфическим для нашей отрасли. Другие дисциплины и отрасли, такие как архитектура, экономика и т.д., также применяют эту концепцию. Давайте посмотрим на определение паттерна, данное Кристофером Александером, ведущим специалистом в области архитектуры:

                      «Каждый паттерн – это трехчастное правило, которое выражает связь между определенным контекстом, проблемой и решением.» (Alexander, 1979)

                      «Любой паттерн описывает задачу, которая снова и снова возникает в нашей работе, а также принцип ее решения, причем, таким образом, что это решение можно потом использовать миллион раз, и при этом никакие две реализации не будут полностью одинаковыми.» (Alexander, 1977)

                      Теперь давайте посмотрим, что означают паттерны в индустрии разработки ПО:

                      «Архитектурный паттерн при разработке программного обеспечения описывает конкретную повторяющуюся проблему проектирования, возникающую в определенных практических ситуациях, и представляет хорошо проверенную общую схему ее решения. Схема решения определяется путем описания составляющих ее компонентов, их обязанностей и отношений, а также способов их взаимодействия.» (BMRSS, 96)

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

                      Различные категории паттернов

                      • Архитектурные паттерны
                      • Паттерны проектирования
                      • Идиомы

                      image

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

                      «Архитектурный паттерн выражает фундаментальную схему структурной организации программных систем. Он предоставляет набор предопределенных подсистем, определяет их обязанности и включает правила и рекомендации по организации отношений между ними.» (BMRSS, 96)

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

                      «Идиома — это низкоуровневый паттерн, характерный для конкретного языка программирования. Идиома описывает, как реализовать определенные аспекты компонентов или отношений между ними, используя особенности данного языка.» (BMRSS, 96)

                      Однако между вышеупомянутыми паттернами есть еще некоторые другие, касающиеся масштаба и уровня абстракции, и именно здесь принято говорить о паттернах проектирования.

                      Подробнее о паттернах проектирования

                      Итак, давайте рассмотрим определение оставшейся категории паттернов:

                      «Паттерн проектирования предоставляет схему для уточнения подсистем или компонентов программной системы, или отношений между ними. Он описывает часто повторяющуюся структуру взаимодействующих компонентов, которая решает общую проблему проектирования в определенном контексте.» (BMRSS, 96)

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

                      «Они, как правило, не зависят от конкретного языка программирования или парадигмы программирования.» (BMRSS, 96)

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

                      «Они не зависят от конкретного языка программирования, но часто (могут) зависеть от парадигмы программирования.»

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

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

                      image

                      Анализ известного высказывания

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

                      Функциональные языки не нуждаются в паттернах проектирования.

                      Вы можете найти пример здесь. Это утверждение неверно, поскольку подразумевает, что паттерны проектирования относятся только к объектно-ориентированной парадигме. Однако паттерны проектирования — это концепция, которая может присутствовать как в парадигме функционального программирования, так и в объектно-ориентированной парадигме. Просто паттерны проектирования могут быть специфичны для проблем и требований целевой парадигмы. Например, парадигма функционального программирования включает паттерны проектирования, специфичные для ее контекста.

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

                      Краткое резюме

                      • Они не зависят от языка программирования, но в основном связаны с парадигмой.
                      • Будучи среднемасштабными, они не столь абстрактны, как архитектурные паттерны.
                      • Их применение не влияет на фундаментальную архитектуру программной системы, но влияет на архитектуру подсистем.
                      • И последнее, но не менее важное: они (все типы паттернов) помогают нам не изобретать велосипед.

                      P.S.
                      На сайте издательства продолжается весенняя распродажа.

                      • ООП
                      • совершенный код
                      • программирование
                      • функциональное программирование

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *