ST2 Test 1

23.10.2023 - Лекции 1-8

Лекция 1 - Въведение

DESING PATTERNS (ШАБЛОНИ ЗА ДИЗАЙН)

Дефиниции:

… описва проблем, появяващ се отново и отново в нашата среда, и след това описва същината на решението на този проблем по такъв начин, че решението може да се използва милион пъти, без някога да се повтори начина на изпълнение [Alexander].

… концепция, предназначена за разрешаване на често срещани проблеми в обектно-ориентираното програмиране. Тази концепция предлага стандартни решения за архитектурни и концептуални проблеми в компютърното програмиране [Wikipedia].

… черпене от конкретна форма, която запазва повтарящи се специфични контексти [Riehle]

… и двете неща - проблем и инструкции за решаване на проблема [Coplien, Software Design Patterns: Common questions and Answers]

… литературен формат за улавяне на мъдростта и опита на експерти в дизайна, и представянето им на новаците.

Свойства:

  • Шаблоните за дизайн предоставят общ речник
  • Предоставят "стенография" за ефективна комуникация по сложни въпроси
  • Подпомагат документирането на софтуерни архитектури
  • Представят съществените части на дизайна в компактна форма
  • Показват повече от едно решение
  • Описват софтуерни абстракции

Шаблоните за дизайн НЕ:

  • Осигуряват конкретни решения
  • Решават всички проблеми на дизайна
  • Се прилагат само за обектно-ориентиран дизайн

ВИДОВЕ СОФТУЕРНИ ШАБЛОНИ (SOFTWARE PATTERNS)

  • Design patterns (софтуерен дизайн) - Architectural (дизайн на системи), Design (микро-архитектури), Idioms (ниско ниво)
  • Analysis patterns (повтарящи се и преизползваеми аналитични модели)
  • Organization patterns (структура на организации/проекти)
  • Process patterns (дизайн на софтуерен процес)
  • Domain-specific patterns и др.

PATTERN CATALOG AND SYSTEM

  • pattern catalog (каталог на шаблони за дизайн) - колекция от свързани шаблони, които са групирани в категории
  • pattern system (система, изпозлваща шаблони за дизайн) - единен набор от свързани модели, които работят заедно, за да поддържат изграждането и развитието на цели архитектури

OBJECT ORIENTED DESIGN PATTERN

Шаблон за дизайн е описание на комуникиращи обекти и класове, които са персонализирани с цел решаване на общ проблем на дизайна, в конкретен контекст.

Един шаблон включва четири компонента:

  • Име
  • Проблем
  • Решение
  • Следствия

GOF ФОРМАТ ЗА ОПИСАНИЕ НА ШАБЛОНИ ЗА ДИЗАЙН

  • Pattern name and classification - име и класификация на шаблона
  • Intent – цел, какво прави шаблона / кога върши работа
  • Also known as – други известни имена на шаблона (ако има)
  • Motivation - проблемът на дизайна / как структури от класове и обекти решават проблема
  • Applicability – приложимост, ситуации, в които може да бъде използван шаблона
  • Structure - графично представяне на класовете в шаблона
  • Participants – описание на класовете и обектите на шаблона и техните отговорности
  • Collaborations – взимодействия между участниците при изпълнение на техните отговорности
  • Consequences – следствия, предимства и недостатъци
  • Implementation – имплементация, съвети, техники
  • Sample code – примерен код, показващ възможна имплементация
  • Known uses – шаблони, открити в реални системи
  • Related patterns – тясно свързани шаблони

ШАБЛОНИ ЗА ДИЗАЙН - КАТЕГОРИЗАЦИЯ

  • Създаващи шаблони (Creational patterns) са тези, които създават обекти. Това дава на програмата по-голяма гъвкавост при вземането на решения какви обекти трябва да бъдат създадени за всеки отделен случай.
  • Структурните шаблони (Structural patterns) помагат да се композират групи от обекти в по-големи и сложни структури, като например сложни потребителски интерфейси.
  • Поведенческите шаблони (Behavioral patterns) помагат да се определи комуникацията между обектите и контрола на потока в една комплексна система.

Лекция 2 - Abstract Factory, Builder

CREATIONAL PATTERNS (ГРАДИВНИ ШАБЛОНИ)

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

Abstract Factory (АБСТРАКТНА ФАБРИКА)

Цел:

Доставя интерфейс за създаване на семейства от свързани или зависими обекти, без да се специфицират техните конкретни класове.

УПОТРЕБА:

  • една система трябва да бъде независима от това, как се създават, композират и представят нейните продукти
  • една система трябва да бъде конфигурирана с една от няколко групи продукти
  • проектирано е група от свързани продукти да бъдат използвани заедно, и това ограничение трябва да се наложи стриктно
  • искате да предоставите библиотеки от класове за продукти, като разкриете само техните интерфейси, без имплементацията им

СТРУКТУРА НА ШАБЛОНА:

  • AbstractFactory - декларира интерфейс с методи за създаване на абстрактни продукти
  • ConcreteFactory - имплементира операциите за създаване на конкретни продукти
  • AbstractProduct - декларира интерфейс за клас продукти
  • ConcreteProduct - дефинира продукт, който да бъде създаден от конкретна фабрика; имплементира интерфейса AbstractProduct
  • Client - използва само интерфейси, декларирани чрез AbstractFactory и AbstractProduct класове

ВЗАИМОДЕЙСТВИЯ:

  • Обикновено в рънтайма се създава една единствена инстанция на класа ConcreteFactory. Тази конкретна фабрика създава продукти, които имат специфична имплементация.
  • AbstractFactory отлага създаването на продукти, то се извършва от подкласа ConcreteFactory.

ПРЕДИМСТВА И НЕДОСТАТЪЦИ:

  • Изолира конкретните класове
  • Лесна замяна на групи продукти
  • Добавянето на нови видове продукти не е лесно
  • Налага съгласуваност между продукти

ВРЪЗКА С ДРУГИ ШАБЛОНИ:

  • AbstractFactory класовете често се имплементират с Factory Method, може да се използва и Prototype
  • Конкретна фабрика често е удачно да се реализира с шаблона Singleton

BUILDER (СТРОИТЕЛ)

Цел:

  • Разделя процеса на създаването на сложен продукт от неговото представяне
  • Един и същи процес за създаване на продукт може да създаде продукт с различни представяния

УПОТРЕБА:

  • алгоритъмът за създаване на сложен обект трябва да бъде независим от частите, от които е съставен обекта и начина, по който е асемблиран
  • процесът на конструиране трябва да позволи различни представяния на обекта

СТРУКТУРА НА ШАБЛОНА:

  • Builder - абстрактен интерфейс за създаване на части от продукт
  • ConcreteBuilder - конструира и асемблира части на продукта чрез имплементиране на интерфейса Builder
  • Director - конструира обект, като използва интерфейса Builder
  • Product - представлява сложния обект, който се изгражда

ВРЪЗКА С ДРУГИ ШАБЛОНИ:

  • Abstract Factory прилича на Builder по това, че също може да изгради сложни обекти
  • Често обекта, изграден от Builder е Composite

Лекция 3 - Factory Method, Prototype, Singleton

CREATIONAL PATTERNS (ГРАДИВНИ ШАБЛОНИ)

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

FACTORY METHOD (МЕТОД ФАБРИКА)

Цел:

Дефинира интерфейс за създаване на обект, но позволява на подкласовете да решат кой клас да инстанцират. Factory Method позволява на един клас да отложи инстанцирането за подкласовете.

Известен и като:

Virtual Constructor (Виртуален конструктор)

УПОТРЕБА:

  • един клас не може да предвиди класа на обектите, които трябва да създаде
  • един клас иска неговите подкласове да определят обектите, които той създава
  • класове делегират отговорност на един от няколко помощни подкласа

PROTOTYPE (ПРОТОТИП)

Цел:

Специфицира вида на обектите, които създава, с помощта на прототипна инстанция, и създава нови обекти чрез копиране на този прототип.

УПОТРЕБА:

  • когато класовете, които трябва да се инстанцират, се специфицират в рън-тайма
  • за да избегнете изграждането на йерархия от класове фабрики
  • когато инстанциите на един клас може да имат едно от няколко различни състояния

SINGLETON (СЕК)

Цел:

Осигурява клас, който е проектиран да има само една инстанция, и предоставя глобална точка за достъп до нея.

УПОТРЕБА:

  • трябва да има точно една инстанция на клас, и тя трябва да е достъпна за клиентите чрез известна точка за достъп
  • когато единствената инстанция трябва да бъде разширяема чрез създаване на подкласове

Лекция 4 - Adapter, Bridge, Composite

STRUCTURAL PATTERNS (СТРУКТУРНИ ШАБЛОНИ)

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

ADAPTER (АДАПТЕР)

Цел:

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

Известен и като:

Wrapper (Обвивка)

BRIDGE (МОСТ)

Цел:

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

COMPOSITE (КОМПОЗИЦИЯ)

Цел:

Композира обекти в дървовидни структури, за да представи йерархия "част-цяло". Composite позволява на клиентите да третират индивидуални обекти и композиции от обекти по един и същ начин.

Лекция 5 - Decorator, Facade, Flyweight, Proxy

DECORATOR (ДЕКОРАТОР)

Цел:

Прикача допълнителни отговорности към обект динамично. Decorator предлага алтернатива на наследяването за разширяване на функционалността.

FACADE (ФАСАДА)

Цел:

Осигурява унифициран интерфейс към множество интерфейси в дадена подсистема. Facade дефинира интерфейс на по-високо ниво, който улеснява използването на подсистемата.

FLYWEIGHT (ЛЕКОТЕГЛО)

Цел:

Използва споделяне за поддържането на голям брой дребнозърнести обекти ефективно.

PROXY (ПРОКСИ)

Цел:

Осигурява заместник или place-holder за друг обект, за да контролира достъпа до него.

Лекция 6 - Behavioral Patterns

BEHAVIORAL PATTERNS (ПОВЕДЕНЧЕСКИ ШАБЛОНИ)

  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

CHAIN OF RESPONSIBILITY (ВЕРИГА ОТ ОТГОВОРНОСТИ)

Цел:

Избягва свързването на подателя на заявка до нейния получател, като дава на повече от един обект шанс да обработи заявката.

COMMAND (КОМАНДА)

Цел:

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

INTERPRETER (ИНТЕРПРЕТАТОР)

Цел:

Дадена емезировка за език, дефинира представянето на неговата граматика, както и интерпретатор, който използва това представяне, за да интерпретира изречения в езика.

ITERATOR (ИТЕРАТОР)

Цел:

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

MEDIATOR (ПОСРЕДНИК)

Цел:

Дефинира обект, който капсулира начина, по който взаимодействат група от обекти. Mediator насърчава слабото свързване, като предотвратява директните референции между обектите.

MEMENTO (СПОМЕН)

Цел:

Без нарушаване на капсулацията, Capture and externalize на вътрешното състояние на обекта, така че обектът да може да бъде възстановен в това състояние по-късно.

OBSERVER (НАБЛЮДАТЕЛ)

Цел:

Дефинира едно-към-много зависимост между обекти, така че когато един обект промени състоянието си, всички негови зависими обекти да бъдат уведомени и актуализирани автоматично.

STATE (СЪСТОЯНИЕ)

Цел:

Позволява на обект да промени поведението си, когато неговото вътрешно състояние се промени. Обектът ще изглежда, че е променил своя клас.

STRATEGY (СТРАТЕГИЯ)

Цел:

Дефинира семейство от алгоритми, капсулира всеки един от тях и ги направи взаимнозаменяеми. Strategy позволява на алгоритъма да варира независимо от клиентите, които го използват.

TEMPLATE METHOD (ШАБЛОНЕН МЕТОД)

Цел:

Дефинира скелета на алгоритъм в операция, отлага дефиницията на някои стъпки на подкласове. Template Method позволява на подкласовете да дефинират определени стъпки на алгоритъм, без да променят структурата на алгоритъма.

VISITOR (ПОСЕТИТЕЛ)

Цел:

Представя операция, която трябва да се изпълни върху елементите на структура от обекти. Visitor позволява да се дефинира нова операция, без да се променят класовете на елементите, върху които тя оперира.

Лекция 7 - Архитектурни шаблони

АРХИТЕКТУРНИ ШАБЛОНИ

  • Model-View-Controller (MVC)
  • Model-View-Presenter (MVP)
  • Model-View-ViewModel (MVVM)
  • Three-tier architecture
  • Microkernel
  • Pipes and Filters
  • Event-Driven Architecture

Лекция 8 - Контекст и приложимост

ИЗБОР НА ШАБЛОН

При избора на шаблон за дизайн трябва да се вземат предвид:

  • Контекстът на проблема
  • Приложимостта на шаблона
  • Предимствата и недостатъците
  • Сложността на имплементацията
  • Съвместимостта с други шаблони в системата