Поведенческие паттерны: Iterator, Observer, State, Strategy, Visitor, Template method

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

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

Состояние — это поведенческий паттерн проектирования, который позволяет объектам менять поведение в зависимости от своего состояния. Извне создаётся впечатление, что изменился класс объекта.

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

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

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

---

Поведенческие паттерны: Chain of Responsibility, Memento, Command, Mediator

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

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

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

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

---

вызовет метод команды, а та — позаботится обо всём остальном.
Тема 9 Конструирование ПО

Рефакторинг. Определение, причины и цели. Приемы рефакторинга

Рефакторинг — это контролируемый процесс улучшения кода, без написания новой функциональности. Результат рефакторинга — это чистый код и простой дизайн.

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

Чистый код — это код, который просто читать, понимать и поддерживать. Чистый код улучшает предсказуемость разработки и повышает качество продукта.

Приёмы рефакторинга

• 
  Составление методов
  

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

• 
  Перемещение функций между объектами
  

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

• 
  Организация данных
  

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

• 
  Упрощение условных выражений
  

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

Упрощение вызовов методов

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

• 
  Решение задач обобщения
  

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

Составление методов.

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

• 
  Извлечение метода
  

Проблема: У вас есть фрагмент кода, который можно сгруппировать.

---

Решение: Выделите участок кода в новый метод (или функцию) и вызовите этот метод вместо старого кода.

• 
  Встраивание метода
  

Проблема: Стоит использовать в том случае, когда тело метода очевиднее самого метода.

Решение: Замените вызовы метода его содержимым и удалите сам метод.

• 
  Извлечение переменной
  

Проблема: У вас есть сложное для понимания выражение.

Решение: Поместите результат выражения или его части в отдельные переменные, поясняющие суть выражения.

• 
  Встраивание переменной
  

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

Решение: Замените обращения к переменной этим выражением.

• 
  Замена переменной вызовом метода
  

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

Решение: Выделите все выражение в отдельный метод и возвращайте результат из него. Замените использование вашей переменной вызовом метода. Новый метод может быть использован и в других методах.

• 
  Расщепление переменной
  

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

Решение: Используйте разные переменные для разных значений. Каждая переменная должна отвечать только за одну определённую вещь.

• 
  Удаление присваиваний параметрам
  

Проблема: Параметру метода присваивается какое-то значение.

Решение: Вместо параметра воспользуйтесь новой локальной переменной.

• 
  Замена метода объектом методов
  

Проблема: У вас есть длинный метод, в котором локальные переменные так сильно переплетены, что это делает невозможным применение «извлечения метода».

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

• 
  Замена алгоритма
  

Проблема: Вы хотите заменить существующий алгоритм другим?

Решение: Замените тело метода, реализующего старый алгоритм, новым алгоритмом.
Перемещение функций между объектами

Если вы разместили функциональность по классам не самым удачным образом — это еще не повод отчаиваться.

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

---

• 
  Перемещение метода
  

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

Решение: Создайте новый метод в классе, который использует его больше других, и перенесите туда код из старого метода. Код оригинального метода превратите в обращение к новому методу в другом классе либо уберите его вообще.

• 
  Перемещение поля
  

Проблема: Поле используется в другом классе больше, чем в собственном.

Решение: Создайте поле в новом классе и перенаправьте к нему всех пользователей старого поля.

• 
  Извлечение класса
  

Проблема: Один класс работает за двоих.

Решение: Создайте новый класс, переместите в него поля и методы, отвечающие за определённую функциональность.

• 
  Встраивание класса
  

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

Решение: Переместите все фичи из описанного класса в другой.

• 
  Сокрытие делегирования
  

Проблема: Клиент получает объект B из поля или метода объекта А. Затем клиент вызывает какой-то метод объекта B.

Решение: Создайте новый метод в классе А, который бы делегировал вызов объекту B. Таким образом, клиент перестанет знать о классе В и зависеть от него.

• 
  Удаление посредника
  

Проблема: Класс имеет слишком много методов, которые просто делегируют работу другим объектам.

Решение: Удалите эти методы и заставьте клиента вызывать конечные методы напрямую.

• 
  Введение внешнего метода
  

Проблема: Служебный класс не содержит метода, который вам нужен, при этом у вас нет возможности добавить метод в этот класс.

Решение: Добавьте метод в клиентский класс и передавайте в него объект служебного класса в качестве аргумента.

• 
  Введение локального расширения
  

Проблема: В служебном классе отсутствуют некоторые методы, которые вам нужны. При этом добавить их в этот класс вы не можете.

Решение: Создайте новый класс, который бы содержал эти методы, и сделайте его наследником служебного класса, либо его обёрткой.
Организация данных.

Рефакторинги этой группы призваны облегчить работу с данными, заменив работу с примитивными типами богатыми функциональностью классами.

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

---

Смотрите также файлы

• Генеральный директор ооо Альтернатива.doc

• Рабочая программа по предмету Информатика для 8 А класса срок реализации 20212022 уч год.pdf

• Программа применения методов увеличения добычи нефти на проектный период.docx

• Образовательное учреждение высшего образования воронежский государственный технический университет.docx

• Антропова надежда александровна.rtf