exam14 4
Реферат к лекции 14-4. Шаблоны проектирования программ и баз данных.
Выполнил: Вальков Михаил (ИДБ-19-06)
Проверила: Алейник Александр (ИДБ-19-07)
Инкапсуляция — свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента (то, что у него внутри), а взаимодействовать с ним посредством предоставляемого интерфейса (публичных членов — методов, данных etc.), а также объединить и защитить жизненно важные для компонента данные. При этом пользователю предоставляется только интерфейс — спецификация объекта.
Вместо того чтобы заставлять разработчиков самостоятельно писать команды SQL, предоставьте интерфейс к этим командам. Это одна из самых важных причин для построения пакетов. При таком подходе разработчики PL/SQL вместо команд SQL обычно включают в свои приложения заранее определенный, протестированный и оптимизированный код, который выполняет всю работу за них; например, процедуру add (перегруженную для поддержки записей), которая выдает команду INSERT и следует стандартным правилам обработки ошибок, функцию для выборки одной записи по первичному ключу и разнообразные курсоры для обработки стандартных запросов к структуре данных (которой может быть одна таблица или «бизнес-сущность» из нескольких таблиц).
Вероятно, самое серьезное преимущество такого подхода заключается в том, что при изменении структуры данных проблемы с обновлением кода приложения сводятся к минимуму и централизуются. Человек, хорошо знающий таблицу или объектный тип, вносит необходимые изменения в одном пакете, а эти изменения затем более или менее автоматически распространяются на всех программы, зависящие от этого пакета. Однако многие преимущества инкапсуляции данных могут использоваться и без полной переработки стиля программирования.
Рекомендации при использовании инкапсуляции:
- Скрыть все однострочные запросы за функциональным интерфейсом. Тем самым вы обеспечите гарантированную обработку ошибок и сможете выбрать оптимальную реализацию (например, неявные или явные курсоры).
- Определить, с какими таблицами разработчики чаще всего взаимодействуют напрямую, и построить для них прослойку программного кода.
- Создать пакетные программы для сложных транзакций. Если операция «добавление нового заказа» включает вставку двух строк, обновление шести строк и т. д., обязательно встройте эту логику в процедуру, которая скрывает все сложности.
| Название | Оригинальное название | Описание | Описан в Design Patterns |
|---|---|---|---|
| Основные шаблоны (Fundamental) | |||
| Шаблон делегирования | Delegation pattern | Объект внешне выражает некоторое поведение, но в реальности передаёт ответственность за выполнение этого поведения связанному объекту. | н/д |
| Шаблон функционального дизайна | Functional design | Гарантирует, что каждый модуль компьютерной программы имеет только одну обязанность и исполняет её с минимумом побочных эффектов на другие части программы. | н/д |
| Неизменяемый интерфейс | Immutable interface | Создание неизменяемого объекта. | н/д |
| Интерфейс | Interface | Общий метод для структурирования компьютерных программ для того, чтобы их было проще понять. | н/д |
| Интерфейс-маркер | Marker interface | В качестве атрибута (как пометки объектной сущности) применяется наличие или отсутствие реализации интерфейса-маркера. В современных языках программирования вместо этого могут применяться атрибуты или аннотации. | н/д |
| Контейнер свойств | Property container | Позволяет добавлять дополнительные свойства для класса в контейнер (внутри класса), вместо расширения класса новыми свойствами. | н/д |
| Канал событий | Event channel | Расширяет шаблон Publish/Subscribe, создавая централизованный канал для событий. Использует объект-представитель для подписки и объект-представитель для публикации события в канале. Представитель существует отдельно от реального издателя или подписчика. Подписчик может получать опубликованные события от более чем одного объекта, даже если он зарегистрирован только на одном канале. | н/д |
| Порождающие шаблоны (Creational) — шаблоны проектирования, которые абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту. | |||
| Абстрактная фабрика | Abstract factory | Класс, который представляет собой интерфейс для создания компонентов системы. | Да |
| Строитель | Builder | Класс, который представляет собой интерфейс для создания сложного объекта. | Да |
| Фабричный метод | Factory method | Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. | Да |
| Отложенная инициализация | Lazy initialization | Объект, инициализируемый во время первого обращения к нему. | Нет |
| Мультитон | Multiton | Гарантирует, что класс имеет поименованные экземпляры объекта и обеспечивает глобальную точку доступа к ним. | Нет |
| Объектный пул | Object pool | Класс, который представляет собой интерфейс для работы с набором инициализированных и готовых к использованию объектов. | Нет |
| Прототип | Prototype | Определяет интерфейс создания объекта через клонирование другого объекта вместо создания через конструктор. | Да |
| Получение ресурса есть инициализация | Resource acquisition is initialization (RAII) | Получение некоторого ресурса совмещается с инициализацией, а освобождение — с уничтожением объекта. | Нет |
| Одиночка | Singleton | Класс, который может иметь только один экземпляр. | Да |
| Структурные шаблоны (Structural) определяют различные сложные структуры, которые изменяют интерфейс уже существующих объектов или его реализацию, позволяя облегчить разработку и оптимизировать программу. | |||
| Адаптер | Adapter / Wrapper | Объект, обеспечивающий взаимодействие двух других объектов, один из которых использует, а другой предоставляет несовместимый с первым интерфейс. | Да |
| Мост | Bridge | Структура, позволяющая изменять интерфейс обращения и интерфейс реализации класса независимо. | Да |
| Компоновщик | Composite | Объект, который объединяет в себе объекты, подобные ему самому. | Да |
| Декоратор или Wrapper/Обёртка | Decorator | Класс, расширяющий функциональность другого класса без использования наследования. | Да |
| Фасад | Facade | Объект, который абстрагирует работу с несколькими классами, объединяя их в единое целое. | Да |
| Единая точка входа | Front controller | Обеспечивает унифицированный интерфейс для интерфейсов в подсистеме. Front Controller определяет высокоуровневый интерфейс, упрощающий использование подсистемы. | Нет |
| Приспособленец | Flyweight | Это объект, представляющий себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым. | Да |
| Заместитель | Proxy | Объект, который является посредником между двумя другими объектами, и который реализует/ограничивает доступ к объекту, к которому обращаются через него. | Да |
| Поведенческие шаблоны (Behavioral) определяют взаимодействие между объектами, увеличивая таким образом его гибкость. | |||
| Цепочка обязанностей | Chain of responsibility | Предназначен для организации в системе уровней ответственности. | Да |
| Команда, Action, Transaction | Command | Представляет действие. Объект команды заключает в себе само действие и его параметры. | Да |
| Интерпретатор | Interpreter | Решает часто встречающуюся, но подверженную изменениям, задачу. | Да |
| Итератор, Cursor | Iterator | Представляет собой объект, позволяющий получить последовательный доступ к элементам объекта-агрегата без использования описаний каждого из объектов, входящих в состав агрегации. | Да |
| Посредник | Mediator | Обеспечивает взаимодействие множества объектов, формируя при этом слабую связанность и избавляя объекты от необходимости явно ссылаться друг на друга. | Да |
| Хранитель | Memento | Позволяет не нарушая инкапсуляцию зафиксировать и сохранить внутренние состояния объекта так, чтобы позднее восстановить его в этих состояниях. | Да |
| Null Object | Null Object | Предотвращает нулевые указатели, предоставляя объект «по умолчанию». | Нет |
| Наблюдатель или Издатель-подписчик | Observer | Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии. | Да |
| Слуга[en] | Servant | Используется для обеспечения общей функциональности группе классов. | Нет |
| Спецификация | Specification | Служит для связывания бизнес-логики. | Нет |
| Состояние | State | Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния. | Да |
| Стратегия | Strategy | Предназначен для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. | Да |
| Шаблонный метод | Template method | Определяет основу алгоритма и позволяет наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом. | Да |
| Посетитель | Visitor | Описывает операцию, которая выполняется над объектами других классов. При изменении класса Visitor нет необходимости изменять обслуживаемые классы. | Да |
| Простая политика | Simple Policy | Нет | |
| Event listener | Event listener | Нет | |
| Одноразовый посетитель[en] | Single-serving visitor | Оптимизирует реализацию шаблона посетитель, который инициализируется, единожды используется, и затем удаляется. | Нет |
| Иерархический посетитель[en] | Hierarchical visitor | Предоставляет способ обхода всех вершин иерархической структуры данных (напр. древовидной). | Нет |
Паттерны проектирования предназначены для:
- эффективного решения характерных задач проектирования;
- обобщенного описания решения задачи, которое можно использовать в различных ситуациях;
- указания отношения и взаимодействия между классами и объектами.
Паттерны проектирования являются инструментами, призванными помочь в решении широкого круга задач стандартными методами.
Преимущества:
- Каждый паттерн описывает решение целого класса проблем.
- Каждый паттерн имеет известное имя.
- Имена паттернов позволяют абстрагироваться от конкретного алгоритма, а решать задачу на уровне общего подхода. Это позволяет облегчить взаимодействие программистов работающих даже на разных языках программирования.
- Правильно сформулированный паттерн проектирования позволяет, отыскав удачное решение, пользоваться им снова и снова.
- Шаблоны проектирования не зависят от языка программирования (объектно-ориентированного), в отличие от идиом
Абстрагируют процесс инстанцирования. Они позволяют сделать систему независимой от способа создания, композиции и представления объектов. Шаблон, порождающий классы, использует наследование, чтобы изменять инстанцируемый класс, а шаблон, порождающий объекты, делегирует инстанцирование другому объекту.
Эти шаблоны оказываются важны, когда система больше зависит от композиции объектов, чем от наследования классов. Основной упор делается не на жестком кодировании фиксированного набора поведений, а на определении небольшого набора фундаментальных поведений, с помощью композиции которых можно получать любое число более сложных. Таким образом, для создания объектов с конкретным поведением требуется нечто большее, чем простое инстанцирование класса.
Порождающие шаблоны инкапсулируют знания о конкретных классах, которые применяются в системе. Они скрывают детали того, как эти классы создаются и стыкуются. Единственная информация об объектах, известная системе, — это их интерфейсы, определенные с помощью абстрактных классов. Следовательно, порождающие шаблоны обеспечивают большую гибкость при решении вопроса о том, что создается, кто это создает, как и когда.
Иногда допустимо выбирать между тем или иным порождающим шаблоном. Например, есть случаи, когда с пользой для дела можно использовать как прототип, так и абстрактную фабрику. В других ситуациях порождающие шаблоны дополняют друг друга. Так, применяя строитель, можно использовать другие шаблоны для решения вопроса о том, какие компоненты нужно строить, а прототип часто реализуется вместе с одиночкой. Порождающие шаблоны тесно связаны друг с другом, их рассмотрение лучше проводить совместно, чтобы лучше были видны их сходства и различия..
Перечень порождающих паттернов
К порождающим паттернам проектирования относятся следующие:
- абстрактная фабрика (abstract factory);
- строитель (builder);
- фабричный метод (factory method);
- прототип (prototype);
- одиночка (singleton)
Абстрактная фабрика — паттерн позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы. Он позволяет создавать целые группы взаимосвязанных объектов (продуктов), которые, будучи созданными одной фабрикой, реализуют общее поведение. Паттерн реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна, кнопки и т.д.). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс. Иначе говоря, продукт это тот объект, который должен быть произведен, а фабрика предоставляет механизм для его создания.
Достоинства
- изолирует конкретные классы;
- упрощает замену семейств продуктов;
- гарантирует сочетаемость продуктов.
Недостатки
- сложно добавить поддержку нового вида продуктов.
Применение
- Система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты.
- Входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения.
- Система должна конфигурироваться одним из семейств составляющих ее объектов.
- Требуется предоставить библиотеку объектов, раскрывая только их интерфейсы, но не реализацию
Строитель отделяет конструирование сложного объекта от его представления, так что в результате одного и того же процесса конструирования могут получаться разные представления.
Недостатки
- позволяет изменять внутреннее представление продукта;
- изолирует код, реализующий конструирование и представление;
- дает более тонкий контроль над процессом конструирования.
Применение
- алгоритм создания сложного объекта не должен зависеть от того, из каких частей состоит объект и как они стыкуются между собой;
- процесс конструирования должен обеспечивать различные представления конструируемого объекта.
Фабричный метод — порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой класс инстанциировать. Иными словами, Фабрика делегирует создание объектов наследникам родительского класса. Это позволяет использовать в коде программы не специфические классы, а манипулировать абстрактными объектами на более высоком уровне. Также известен под названием виртуальный конструктор.
Назначение
Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанциировать. Фабричный метод позволяет классу делегировать создание подклассам. Используется, когда:
- классу заранее неизвестно, объекты каких подклассов ему нужно создавать.
- класс спроектирован так, чтобы объекты, которые он создаёт, специфицировались подклассами.
- класс делегирует свои обязанности одному из нескольких вспомогательных подклассов, и планируется локализовать знание о том, какой класс принимает эти обязанности на себя.
Структура
- Product определяет интерфейс объектов, создаваемых абстрактным методом;
- ConcreteProduct реализует интерфейс Product;
- Creator объявляет фабричный метод, который возвращает объект типа Product. Может также содержать реализацию этого метода «по умолчанию»; может вызывать фабричный метод для создания объекта типа Product;
- ConcreteCreator переопределяет фабричный метод таким образом, чтобы он создавал и возвращал объект класса ConcreteProduct.
Достоинства
- позволяет сделать код создания объектов более универсальным, не привязываясь к конкретным классам, а оперируя лишь общим интерфейсом;
- позволяет установить связь между параллельными иерархиями классов.
Недостатки
- необходимость создавать наследника Creator для каждого нового типа продукта.
Прототип задаёт виды создаваемых объектов с помощью экземпляра-прототипа и создаёт новые объекты путём копирования этого прототипа. Он позволяет уйти от реализации и позволяет следовать принципу «программирование через интерфейсы». В качестве возвращающего типа указывается интерфейс/абстрактный класс на вершине иерархии, а классы-наследники могут подставить туда наследника, реализующего этот тип. Проще говоря, это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.
Паттерн используется чтобы:
- избежать дополнительных усилий по созданию объекта стандартным путём (имеется в виду использование конструктора, так как в этом случае также будут вызваны конструкторы всей иерархии предков объекта), когда это непозволительно дорого для приложения.
- избежать наследования создателя объекта (object creator) в клиентском приложении, как это делает паттерн abstract factory. Используйте этот шаблон проектирования, когда системe безразлично как именно в ней создаются, компонуются и представляются продукты:
- инстанцируемые классы определяются во время выполнения, например с помощью динамической загрузки;
- избежать построения иерархий классов или фабрик, параллельных иерархии классов продуктов;
- экземпляры класса могут находиться в одном из нескольких различных состояний. Может оказаться удобнее установить соответствующее число прототипов и клонировать их, а не инстанцировать каждый раз класс вручную в подходящем состоянии.
Одиночка гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Существенно то, что можно пользоваться именно экземпляром класса, так как при этом во многих случаях становится доступной более широкая функциональность. Например, к описанным компонентам класса можно обращаться через интерфейс, если такая возможность поддерживается языком.
Достоинства
- контролируемый доступ к единственному экземпляру;
- уменьшение числа имён;
- допускает уточнение операций и представления;
- допускает переменное число экземпляров;
- большая гибкость, чем у операций класса.
Недостатки
- Глобальные объекты могут быть вредны для объектного программирования, в некоторых случаях приводя к созданию немасштабируемого проекта.
Применение
- должен быть ровно один экземпляр некоторого класса, легко доступный всем клиентам;
- единственный экземпляр должен расширяться путем порождения подклассов, и клиентам нужно иметь возможность работать с расширенным экземпляром без модификации своего кода.
Структурные шаблоны — шаблоны проектирования, в которых рассматривается вопрос о том, как из классов и объектов образуются более крупные структуры.
Структурные шаблоны уровня класса используют наследование для составления композиций из интерфейсов и реализаций. Простой пример — использование множественного наследования для объединения нескольких классов в один. В результате получается класс, обладающий свойствами всех своих родителей. Особенно полезен этот шаблон, когда нужно организовать совместную работу нескольких независимо разработанных библиотек.
- Адаптер (Adapter)
- Мост (Bridge)
- Компоновщик (Composite)
- Декоратор (Decorator)
- Фасад (Facade)
- Единая точка входа (Front controller)
- Приспособленец (Flyweight)
- Заместитель (Proxy)
Адаптер — структурный шаблон проектирования, предназначенный для организации использования функций объекта, недоступного для модификации, через специально созданный интерфейс
Шаблон Адаптер позволяет в процессе проектирования не принимать во внимание возможные различия в интерфейсах уже существующих классов. Если есть класс, обладающий требуемыми методами и свойствами (по крайней мере, концептуально), то при необходимости всегда можно воспользоваться шаблоном Адаптер для приведения его интерфейса к нужному виду.
Близким Адаптеру является шаблон Фасад, не всегда можно отличить один от другого.
Мост — шаблон проектирования, используемый в проектировании программного обеспечения чтобы «разделять абстракцию и реализацию так, чтобы они могли изменяться независимо». Шаблон bridge (от англ. — мост) использует инкапсуляцию, агрегирование и может использовать наследование для того, чтобы разделить ответственность между классами.
При частом изменении класса, преимущества объектно-ориентированного подхода становятся очень полезными, позволяя делать изменения в программе, обладая минимальными сведениями о реализации программы. Шаблон bridge является полезным там, где не только сам класс часто меняется, но и то, что класс делает.
Компоновщик — шаблон проектирования, объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково.
Паттерн определяет иерархию классов, которые состоят из примитивных и сложных объектов, упрощает архитектуру клиента, делает процесс добавления новых видов объекта более простым.
Декоратор — структурный шаблон проектирования, предназначенный для динамического подключения дополнительного поведения к объекту. Шаблон Декоратор предоставляет гибкую альтернативу практике создания подклассов с целью расширения функциональности.
Известен также под менее распространённым названием Обёртка (Wrapper), которое во многом раскрывает суть реализации шаблона — декоратор предусматривает расширение функциональности объекта без определения подклассов.