2.1 Адаптер
Адаптер (адаптер) е структурен модел на проектиране, предназначен да организира използването на функциите на обект, който не е достъпен за модификация чрез специално създаден интерфейс.
Официалното определение е малко сложно, но ако го опишете със собствените си думи, адаптерът е модел на проектиране, който позволява на обекти с несъвместими интерфейси да работят заедно .
Използва се за организиране на използването на функциите на обект, който не е достъпен за модификация чрез специално създаден интерфейс. Създава се допълнителен клас, който има необходимия интерфейс, а този клас от своя страна извиква методите на желания обект (който няма необходимия интерфейс).
важно! Ако в codeа срещнете суфикса Adapter за клас, тогава имате пълното право да считате, че този клас действа като адаптер и е свързан с група класове, които работят по схемата, описана по-горе.
Използва се в случаите , когато системата поддържа необходимите данни и поведение, но има неподходящ интерфейс. Най-честата употреба на модела на адаптера е, когато искате да създадете клас, който наследява нов or съществуващ абстрактен клас.
Силни страни:
- Преходът към използване на други външни класове не изисква преработка на самата система, достатъчно е да се внедри още един клас адаптер.
- Независимост от внедряване на външни класове (класове от библиотеки, чийто code не можем да променяме). Вашата програма става независима от интерфейса на външни класове.
2.2 Декоратори
Декораторът е структурен модел за проектиране за динамично прикачване на допълнително поведение към обект. Моделът Decorator предоставя добра и гъвкава алтернатива на практиката на подкласове за разширяване на функционалността.
Използва се за динамично свързване на допълнителни задължения към обект.
Много от вас ще попитат: How можете динамично (докато програмата работи) да добавите ново поведение към обект? Един обект може да бъде сглобен от части, тоест малки предмети. Помните ли филтърните вериги в сървлетите? Или Stream API, когато сте написали заявка, използвайки filter(), map(), list()?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);Силни страни на модела Decorator:
- Няма нужда да създавате подкласове, за да разширите функционалността на даден обект.
- Възможността за динамично свързване на нова функционалност навсякъде: преди or след основната функционалност на обекта ConcreteComponent.
2.3 Пълномощници
Прокси е структурен модел на проектиране, който предоставя обект, който контролира достъпа до друг обект, прихващайки и преминавайки през всички негови повиквания.
Прокси моделът предоставя заместващ обект на мястото на истинския обект. Този обект контролира достъпа до оригиналния обект. Използва се много често.
Помните ли How използвахме рамката Mockito и прихванахме повикване към реален обект, използвайки метода Mockito.spy() or анотацията @Spy? Тогава беше създаден специален Proxy обект, през който преминаваха всички повиквания към оригиналния обект.
И тогава бихме могли да управляваме тези повиквания чрез добавяне на правила към обекта. Точно така - оригиналният обект не се променя и работата с него става много по-гъвкава. Особено полезно е, когато не извикваме прокси обекта от нашия code, а го предаваме някъде. По този начин контролираме комуникацията на два независими от нас обекта.
Видове проксита по преднаmeaning:
- Прокси за регистриране : регистрира всички обаждания към „Тема“ с техните параметри.
- Отдалечен прокси (отдалечени прокси): осигурява комуникация с „Субект“, който е в различно addressно пространство or на отдалечена машина. Може също така да отговаря за codeирането на заявката и нейните аргументи и изпращането на codeираната заявка до истинския „Тема“.
- Виртуален прокси (виртуални прокси): гарантира, че истинският „Тема“ се създава само когато наистина е необходим. Може също така да кешира част от информацията за истинския „Субект“, за да забави създаването му.
- Копиране при запис : Предоставя копие на „субекта“, когато клиентът извършва определени действия (специален случай на „виртуалния прокси“).
- Прокси сървъри за защита : Може да проверява дали повикващият има необходимите разрешения, за да направи заявката.
- Прокси за кеширане : Осигурява временно съхранение на резултатите от изчисленията, преди да ги сервира на множество клиенти, които могат да споделят резултатите.
- Проверка на прокси: Защитава "Субекта" от опасни клиенти (or обратното).
- Прокси за синхронизиране : извършва синхронизиран контрол на достъпа до „Тема“ в асинхронна многонишкова среда.
- „Интелигентна“ връзка (интелигентен референтен прокси): извършва допълнителни действия, когато е създадена връзка към „Тема“, например изчислява броя на активните връзки към „Тема“.
2.4 Мост
Моделът Bridge е структурен дизайн, използван за „разделяне на абстракцията и изпълнението, така че да могат да се променят независимо“.
Мостовият модел използва капсулиране, агрегиране и може да използва наследяване за споделяне на отговорността между класовете.
Когато абстракцията и изпълнението са разделени, те могат да се променят независимо. С други думи, когато се изпълнява чрез модела на моста, промяната на структурата на интерфейса не пречи на промяната на структурата на изпълнението.
Помислете за такава абстракция като фигура. Има много видове форми, всяка със свои собствени свойства и методи. Има обаче нещо, което обединява всички фигури. Например всяка фигура трябва да може да рисува сама себе си, да мащабира и т.н.
В същото време графиките за рисуване може да се различават в зависимост от типа на операционната система or графичната библиотека. Формите трябва да могат да рисуват сами в различни графични среди. Но е непрактично да се прилагат всички методи за рисуване във всяка форма or да се променя формата всеки път, когато методът за рисуване се промени.
В този случай мостовият шаблон помага, позволявайки ви да създавате нови класове, които ще реализират рисуване в различни графични среди. Използвайки този подход, е много лесно да добавяте Howто нови форми, така и начини за тяхното рисуване.
Връзката, представена със стрелката в диаграмите, може да има 2 значения: а) „вид“, в съответствие с принципа на заместване на Лисков, и б) едно от възможните изпълнения на абстракцията. Езиците обикновено използват наследяване, за да реализират Howто а), така и б), което има тенденция да раздува йерархиите на класовете.
Мостът служи точно за решаването на този проблем: обектите се създават по двойки от обект от клас от йерархия A и йерархия B, наследяването в йерархията A има meaningто на „разнообразие“ според Лисков, а за концепцията за „изпълнение на абстракция” се използва връзка от обект A към неговия сдвоен обект B.
2.5 Фасада
Фасадният шаблон е структурен дизайн, който скрива сложността на системата, като намалява всички възможни външни извиквания до един обект, който ги делегира на подходящите обекти в системата.
Как да осигурим унифициран интерфейс с набор от различни реализации or интерфейси, например към подсистема, ако силното свързване с тази подсистема е нежелателно or внедряването на подсистемата може да се промени?
Определете една точка на взаимодействие с подсистемата - фасаден обект, който осигурява общ интерфейс с подсистемата, и му възложете отговорността за взаимодействие с неговите компоненти. Фасадата е външен обект, който осигурява единна входна точка за подсистемни услуги.
Внедряването на други компоненти на подсистемата е лично и невидимо за външни компоненти. Фасадният обект осигурява изпълнение на модела GRASP Устойчив на промени по отношение на защита срещу промени в изпълнението на подсистемата.
важно! Този шаблон се използва, когато искаме напълно да скрием няHowва група обекти и да прекараме цялата комуникация с тях през нашия обект. Ако просто искате да осигурите известен контрол върху комуникационния процес на обектите и не е задължително да ги скриете, тогава е по-добре да използвате прокси шаблона.