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

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

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

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

Запит про­хо­ди­ть ряд пере­ві­рок перед досту­пом до систе­ми замовлень.

Про­тя­гом насту­пних кількох міся­ців вам дове­ло­ся дода­ти ще декі­лька таких послі­до­вних перевірок.

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

Хтось запро­по­ну­вав бло­ку­ва­ти масо­ві надси­ла­ння форми з одним і тим самим логі­ном, щоб запо­бі­гти під­бо­ру паро­лів ботами.

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

З часом код пере­ві­рок стає все більш заплутаним.

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

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

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

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

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

І оста­нній штрих. Обро­бник не обов’язко­во пови­нен пере­да­ва­ти запит далі. При­чо­му ця осо­бли­ві­сть може бути вико­ри­ста­на різни­ми шляхами.

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

Обро­бни­ки слі­дую­ть в ланцю­жку один за іншим.

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

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

Ланцю­жок можна виді­ли­ти наві­ть із дере­ва об’єктів.

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

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

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

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

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

Опе­ра­тор пере­ки­дає