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

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

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

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

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

Най­про­сті­ший — зали­ши­ти пове­ді­нку все­ре­ди­ні конте­кс­ту, викли­каю­чи його з об’єкта стану. З іншо­го боку, ви може­те зро­би­ти класи ста­нів вкла­де­ни­ми до класу конте­кс­ту, і тоді вони отри­маю­ть доступ до всіх при­ва­тних частин конте­кс­ту. Оста­нній спо­сіб, щопра­вда, досту­пний лише в деяких мовах про­гра­му­ва­ння (напри­клад, Java, C#).

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

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

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

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

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

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

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

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

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

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

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

Код наві­га­то­ра стає зана­дто роздутим.

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

Будь-яка зміна алго­ри­тмів пошу­ку, чи то виправ­ле­ння багів, чи дода­ва­ння ново­го алго­ри­тму, зачі­па­ла осно­вний клас. Це під­ви­щу­ва­ло ризик ство­ре­ння поми­лки шля­хом випа­дко­во­го вне­се­ння змін до робо­чо­го коду.

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

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

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

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

Стра­те­гії побу­до­ви шляху.

У нашо­му при­кла­ді кожен алго­ри­тм пошу­ку шляху пере­їде до свого вла­сно­го класу.