- •Оглавление
- •Вопросы к экзамену по дисциплине «дги. Шаблоны проектирования»
- •1 Adapter
- •3 Bridge
- •4 Decorator
- •5 Proxy, Composite Proxy
- •Composite
- •6. Lazy Initialization, Singleton lazy Initialization
- •Singleton
- •7 Object Pool
- •8 Prototype
- •9 Builder
- •10 Factory Method
- •11 Abstract Factory
- •12 Command
- •13 Strategy
- •14 Observer
- •15 Iterator
- •16 Chain of responsibility
- •17 Mediator
- •18 Template Method
- •19 Active Record
- •20 Unit of Work
- •21 Lazy load
- •22 Identity Map
- •23 Data Access Objects
Оглавление
Вопросы к экзамену по дисциплине «ДГИ. Шаблоны проектирования» 2
1 Adapter 3
2 façade 4
3 Bridge 5
4 Decorator 6
5 Proxy, Composite 7
Proxy 7
Composite 8
6. lazy Initialization, Singleton 9
lazy Initialization 9
Singleton 9
7 Object Pool 11
8 Prototype 13
9 Builder 14
10 Factory Method 15
11 Abstract Factory 16
12 Command 17
13 Strategy 18
14 Observer 19
15 Iterator 20
16 Chain of responsibility 21
17 Mediator 22
18 Template Method 23
19 Active Record 24
20 Unit of Work 25
21 lazy load 26
22 Identity Map 27
23 Data Access Objects 28
Вопросы к экзамену по дисциплине «дги. Шаблоны проектирования»
Структурные шаблоны. Adapter
Структурные шаблоны. Facade
Структурные шаблоны. Bridge
Структурные шаблоны. Decorator
Структурные шаблоны. Proxy, Composite
Порождающие шаблоны. Lazy Initialization, Singleton
Порождающие шаблоны. Object Pool
Порождающие шаблоны. Prototype
Порождающие шаблоны. Builder
Порождающие шаблоны. Factory Method
Порождающие шаблоны. Abstract Factory
Поведенческие шаблоны. Command
Поведенческие шаблоны. Strategy
Поведенческие шаблоны. Observer
Поведенческие шаблоны. Iterator
Поведенческие шаблоны. Chain of Responsibility
Поведенческие шаблоны. Mediator
Поведенческие шаблоны. Template Method
Архитектурные шаблоны. Active Record
Архитектурные шаблоны. Unit of Work
Архитектурные шаблоны. Lazy Load
Архитектурные шаблоны. Identity Map
Архитектурные шаблоны. Data Access Object
1 Adapter
Проблема - Необходимо обеспечить взаимодействие несовместимых интерфейсов или как создать единый устойчивый интерфейс для нескольких компонентов с разными интерфейсами.
Решение - Конвертировать исходный интерфейс компонента к другому виду с помощью промежуточного объекта - адаптера, то есть, добавить специальный объект с общим интерфейсом в рамках данного приложения и перенаправить связи от внешних обьектов к этому объекту - адаптеру.
Пример
Интеграция разрабатываемой системы с различными внешними системами учета налогов. Используются локальные программные объекты, обеспечивающие адаптацию (Адаптеры), при отправке сообщения к такому объекту выполняется обращение к внешней системе с использованием ее собственного программного интерфейса.
Использование полиморфизма оправдано для адаптации к различным внешним системам.
2 façade
Проблема - Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться?
Решение - Определить одну точку взаимодействия с подсистемой - фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад - это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам.
Пример - Фасадный объект обеспечивает реализацию паттерна "Устойчивый к изменениям" с точки зрения защиты от изменений в реализации подсистемы.. Паттерн проектирования "Полиморфизм", является хорошей иллюстрацией данного метода. В данном случае точкой вариации или неустойчивости являются интерфейсы внешних систем. При добавлении интерфейса "НалоговаяСистемаАдаптер" на основе принципа полиморфизма получается, что внутренние объекты смогут взаимодействовать с устойчивым интерфейсом, а детали взаимодействия с внешними системами будут скрыты в конкретных реализациях адаптеров.