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

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

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

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

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

Також відомий як: State

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

Про­бле­ма

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

Cкі­нче­нний автомат.

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

Такий під­хід можна засто­су­ва­ти і до окре­мих об’єктів. Напри­клад, об’єкт Документ може при­йма­ти три стани: Чернетка, Модерація або Опублікований. У кожно­му з цих ста­нів метод опублікувати пра­цю­ва­ти­ме по-різно­му:

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

Можли­ві стани доку­ме­нту та пере­хо­ди між ними.

Маши­ну ста­нів найча­сті­ше реа­лі­зую­ть за допо­мо­гою мно­жи­ни умо­вних опе­ра­то­рів, if або switch, які пере­ві­ряю­ть пото­чний стан об’єкта та вико­ную­ть від­по­від­ну пове­ді­нку. Ймо­ві­рні­ше за все, ви вже реа­лі­зу­ва­ли у своє­му житті хоча б одну маши­ну ста­нів, наві­ть не знаю­чи про це. Не віри­те? Як щодо тако­го коду, вигля­дає знайо­мо?

class Document is
  field state: string
  // ...
  method publish() is
    switch (state)
      "draft":
        state = "moderation"
        break
      "moderation":
        if (currentUser.role == "admin")
          state = "published"
        break
      "published":
        // Do nothing.
        break
  // ...

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

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

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

Ріше­ння

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

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

Сто­рі­нка деле­гує вико­на­ння своє­му акти­вно­му стану.

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

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

Ана­ло­гія з життя

Ваш сма­ртфон пово­ди­ться по-різно­му в зале­жно­сті від пото­чно­го стану:

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

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

Стан опи­сує спі­льний для всіх конкре­тних ста­нів інтерфейс.

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

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