Читати книгу - "Занурення в патерни проектування, Олександр Швець"

як про­сті, так і скла­до­ві компо­не­нти, тому пере­ко­найте­ся, що його ого­ло­ше­но з типом інте­рфе­йсу компонентів.

Реа­лі­зу­йте в конте­йне­рі мето­ди інте­рфе­йсу компо­не­нтів, пам’ятаю­чи про те, що конте­йне­ри пови­нні деле­гу­ва­ти осно­вну робо­ту своїм дочі­рнім компонентам.

Додайте опе­ра­ції дода­ва­ння й вида­ле­ння дочі­рніх компо­не­нтів до класу контейнерів.

Майте на увазі, що мето­ди дода­ва­ння/вида­ле­ння дочі­рніх компо­не­нтів можна ого­ло­си­ти також і в інте­рфе­йсі компо­не­нтів. Так, це пору­ши­ть принцип роз­ді­ле­ння інте­рфе­йсу, тому що реа­лі­за­ції мето­дів буду­ть поро­жні­ми в компо­не­нтах-листях. Проте усі компо­не­нти дере­ва ста­ну­ть дійсно одна­ко­ви­ми для клієнта.

Пере­ва­ги та недо­лі­ки Спро­щує архі­те­кту­ру кліє­нта при робо­ті зі скла­дним дере­вом компонентів. Поле­гшує дода­ва­ння нових видів компонентів. Ство­рює зана­дто зага­льний дизайн класів. Від­но­си­ни з інши­ми пате­рна­ми

Буді­ве­льник дозво­ляє покро­ко­во конструю­ва­ти дере­во Компо­ну­ва­льни­ка.

Ланцю­жок обов’язків часто вико­ри­сто­вую­ть разом з Компо­ну­ва­льни­ком. У цьому випа­дку запит пере­дає­ться від дочі­рніх компо­не­нтів до їхніх батьків.

Ви може­те обхо­ди­ти дере­во Компо­ну­ва­льни­ка, вико­ри­сто­вую­чи Іте­ра­тор.

Ви може­те вико­на­ти якусь дію над усім дере­вом Компо­ну­ва­льни­ка за допо­мо­гою Від­ві­ду­ва­ча.

Компо­ну­ва­льник часто поєд­ную­ть з Легко­ва­го­ви­ком, щоб реа­лі­зу­ва­ти спі­льні гілки дере­ва та заоща­ди­ти при цьому пам’ять.

Компо­ну­ва­льник та Деко­ра­тор мають схожі стру­кту­ри кла­сів, бо оби­два побу­до­ва­ні на реку­рси­вній вкла­де­но­сті. Вона дозво­ляє зв’язати в одну стру­кту­ру нескі­нче­нну кількі­сть об’єктів.

Деко­ра­тор обго­ртає тільки один об’єкт, а вузол Компо­ну­ва­льни­ка може мати бага­то дітей. Деко­ра­тор додає вкла­де­но­му об’єкту нової функціо­на­льно­сті, а Компо­ну­ва­льник не додає нічо­го ново­го, але «під­су­мо­вує» резуль­та­ти всіх своїх дітей.

Але вони можу­ть і спів­пра­цю­ва­ти: Компо­ну­ва­льник може вико­ри­сто­ву­ва­ти Деко­ра­тор, щоб пере­ви­зна­чи­ти функції окре­мих частин дере­ва компонентів.

Архі­те­кту­ра, побу­до­ва­на на Компо­ну­ва­льни­ках та Деко­ра­то­рах, часто може полі­пшу­ва­ти­ся за раху­нок впро­ва­дже­ння Про­то­ти­пу. Він дозво­ляє кло­ну­ва­ти скла­дні стру­кту­ри об’єктів, а не зби­ра­ти їх заново.

Також відомий як: Wrapper, Обгортка, Decorator

Деко­ра­тор — це стру­кту­рний пате­рн прое­кту­ва­ння, що дає змогу дина­мі­чно дода­ва­ти об’єктам нову функціо­на­льні­сть, заго­ртаю­чи їх у кори­сні «обго­ртки».

Про­бле­ма

Ви пра­цює­те над бібліо­те­кою спо­ві­ще­нь, яку можна під­клю­ча­ти до різно­ма­ні­тних про­грам, щоб отри­му­ва­ти спо­ві­ще­ння про важли­ві події.

Осно­вою бібліо­те­ки є клас Notifier з мето­дом send, який при­ймає на вхід рядок-пові­до­мле­ння і надси­лає його всім адмі­ні­стра­то­рам еле­ктро­нною поштою. Сто­ро­ння про­гра­ма пови­нна ство­ри­ти й нала­шту­ва­ти цей об’єкт, вка­за­вши, кому надси­ла­ти спо­ві­ще­ння, та вико­ри­сто­ву­ва­ти його щора­зу, коли щось відбувається.

Сто­ро­нні про­гра­ми вико­ри­сто­вую­ть голо­вний клас сповіщень.

В яки­йсь моме­нт стало зро­зумі­ло, що кори­сту­ва­чам не виста­чає одних тільки email-спо­ві­ще­нь. Деякі з них хоті­ли б отри­му­ва­ти спо­ві­ще­ння про кри­ти­чні про­бле­ми через SMS. Інші хоті­ли б отри­му­ва­ти їх у вигля­ді Facebook-пові­до­мле­нь. Кор­по­ра­ти­вні кори­сту­ва­чі хоті­ли би бачи­ти пові­до­мле­ння у Slack.

Кожен тип спо­ві­ще­ння живе у вла­сно­му підкласі.

Спе­ршу ви дода­ли кожен з типів спо­ві­ще­нь до про­гра­ми, успа­дку­ва­вши їх від базо­во­го класу Notifier. Тепер кори­сту­ва­чі могли вибра­ти один з типів спо­ві­ще­нь, який і вико­ри­сто­ву­ва­вся надалі.

Але потім хтось резо­нно запи­тав, чому не можна уві­мкну­ти кілька типів спо­ві­ще­нь одно­ча­сно? Адже, якщо у вашо­му буди­нку раптом поча­ла­ся поже­жа, ви б хоті­ли отри­ма­ти спо­ві­ще­ння по всіх кана­лах, чи не так?

Ви зро­би­ли спро­бу реа­лі­зу­ва­ти всі можли­ві комбі­на­ції під­кла­сів спо­ві­ще­нь, але після того, як дода­ли перший деся­ток кла­сів, стало зро­зумі­ло, що такий під­хід неймо­ві­рно роз­ду­ває код програми.

Комбі­на­то­рний вибух під­кла­сів при поєд­на­нні типів сповіщень.

Отже, потрі­бен інший спо­сіб комбі­ну­ва­ння пове­ді­нки об’єктів, який не при­зво­ди­ть до збі­льше­ння кілько­сті підкласів.

Ріше­ння

Спа­дку­ва­ння — це перше, що при­хо­ди­ть в голо­ву бага­тьом про­гра­мі­стам, коли потрі­бно роз­ши­ри­ти яку-небу­дь чинну пове­ді­нку. Проте меха­ні­зм спа­дку­ва­ння має кілька при­крих проблем.

Він ста­ти­чний. Ви не може­те змі­ни­ти пове­ді­нку об’єкта, який вже існує. Для цього нео­бхі­дно ство­ри­ти новий об’єкт, вибра­вши інший підклас. Він не дозво­ляє наслі­ду­ва­ти пове­ді­нку декі­лькох кла­сів одно­ча­сно. Тому дове­де­ться ство­рю­ва­ти без­ліч під­кла­сів-комбі­на­цій, щоб дося­гти поєд­на­ння поведінки.

Одним зі спосо­бів, що дозво­ляє обі­йти ці про­бле­ми, є замі­на спа­дку­ва­ння агре­га­цією або компо­зи­цією 9. Це той випа­док, коли один об’єкт утри­мує інший і деле­гує йому робо­ту, замі­сть того, щоб само­му успа­дку­ва­ти його пове­ді­нку. Саме на цьому принци­пі побу­до­ва­но пате­рн Декоратор.

Спа­дку­ва­ння проти Агре­га­ції

Деко­ра­тор має аль­те­рна­ти­вну назву — обго­ртка. Вона більш вдало опи­сує суть пате­рна: ви роз­мі­щує­те цільо­вий об’єкт у іншо­му об’єкті-обго­ртці, який запу­скає базо­ву пове­ді­нку об’єкта, а потім додає до резуль­та­ту щось своє.

Оби­два об’єкти мають зага­льний інте­рфе­йс, тому для кори­сту­ва­ча немає жодної різни­ці, з чим пра­цю­ва­ти — з чистим чи заго­рну­тим об’єктом. Ви може­те вико­ри­сто­ву­ва­ти кілька різних обго­рток одно­ча­сно — резуль­тат буде мати об’єдна­ну пове­ді­нку всіх обгорток.

В нашо­му при­кла­ді зі спо­ві­ще­ння­ми зали­ши­мо в базо­во­му класі про­сте надси­ла­ння спо­ві­ще­нь еле­ктро­нною поштою, а роз­ши­ре­ні спосо­би зро­би­мо декораторами.