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

Без­ліч під­кла­сів кнопок.

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

Кілька кла­сів дублюю­ть одну і ту саму функціо­на­льні­сть.

Проте, найгі­рше ще попе­ре­ду, адже деякі опе­ра­ції, на кшта­лт «збе­ре­гти», можна викли­ка­ти з декі­лькох місць: нати­сну­вши кно­пку на пане­лі керу­ва­ння, викли­ка­вши конте­кс­тне меню або нати­сну­вши кла­ві­ші Ctrl+S. Коли в про­гра­мі були тільки кно­пки, код збе­ре­же­ння був тільки у під­кла­сі SaveButton. Але тепер його дове­де­ться про­ду­блю­ва­ти ще в два класи.

Хоро­ші про­гра­ми зазви­чай стру­кту­рую­ть у вигля­ді шарів. Найпо­ши­ре­ні­ший при­клад — це шари кори­сту­ва­цько­го інте­рфе­йсу та бізнес-логі­ки. Перший лише малює гарне зобра­же­ння для кори­сту­ва­ча, але коли потрі­бно зро­би­ти щось важли­ве, інте­рфе­йс кори­сту­ва­ча «про­си­ть» шар бізнес-логі­ки зайня­ти­ся цим.

У дійсно­сті це вигля­дає так: один з об’єктів інте­рфе­йсу кори­сту­ва­ча викли­кає метод одно­го з об’єктів бізнес-логі­ки, пере­даю­чи до нього якісь параметри.

Пря­мий доступ з UI до бізнес-логі­ки.

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

До об’єкта інте­рфе­йсу можна буде прив’язати об’єкт кома­нди, який знає, кому і в якому вигля­ді слід від­прав­ля­ти запи­ти. Коли об’єкт інте­рфе­йсу буде гото­вий пере­да­ти запит, він викли­че метод кома­нди, а та — подбає про все інше.

Доступ з UI до бізнес-логі­ки через команду.

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

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

Класи UI деле­гую­ть робо­ту командам.

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

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

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

Таким чином, кома­нди ста­ну­ть гну­чким про­ша­рком між кори­сту­ва­цьким інте­рфе­йсом та бізнес-логі­кою. І це лише неве­ли­ка части­на тієї кори­сті, яку може при­не­сти пате­рн Команда!

При­клад замов­ле­ння в ресторані.

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

Закі­нчи­вши, він поспі­шає на кухню, вири­ває аркуш з бло­кно­та та клеї­ть його на стіну. Далі лист опи­няє­ться в руках куха­ря, який читає замов­ле­ння і готує опи­са­ну страву.

У цьому при­кла­ді ви є від­пра­вни­ком, офі­ціа­нт з бло­кно­том — кома­ндою, а кухар — отри­му­ва­чем. Як і в само­му пате­рні, ви не сти­кає­те­сь з куха­рем без­по­се­ре­дньо. Замі­сть цього ви від­прав­ляє­те замов­ле­ння офі­ціа­нтом, який само­сті­йно «нала­што­вує» куха­ря на робо­ту. З іншо­го боку, кухар не знає, хто конкре­тно наді­слав йому замов­ле­ння. Але йому це байду­же, бо вся нео­бхі­дна інфо­рма­ція є в листі замовлення.

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

Кома­нда опи­сує інте­рфе­йс, спі­льний для всіх конкре­тних кома­нд. Зазви­чай тут опи­сує­ться лише один метод запу­ску команди.

Конкре­тні кома­нди реа­лі­зую­ть різні запи­ти, дотри­мую­чи­сь зага­льно­го інте­рфе­йсу кома­нд. Як пра­ви­ло, кома­нда не роби­ть всю робо­ту само­сті­йно, а лише пере­дає виклик оде­ржу­ва­чу, яким висту­пає один з об’єктів бізнес-логі­ки.

Пара­ме­три, з якими кома­нда зве­ртає­ться до оде­ржу­ва­ча, нео­бхі­дно збе­рі­га­ти у вигля­ді полів. У більшо­сті випа­дків об’єкти кома­нд можна зро­би­ти незмі­нни­ми, пере­даю­чи у них всі нео­бхі­дні пара­ме­три тільки через конструктор.

Оде­ржу­вач місти­ть бізнес-логі­ку про­гра­ми. У цій ролі може висту­па­ти пра­кти­чно будь-який об’єкт. Зазви­чай, кома­нди пере­на­прав­ляю­ть викли­ки оде­ржу­ва­чам, але іноді, щоб спро­сти­ти про­гра­му, ви може­те позбу­ти­ся від оде­ржу­ва­чів, «зли­вши» їхній код у класи команд.

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

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

При­клад реа­лі­за­ції ска­су­ва­ння у текс­то­во­му редакторі.

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

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