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

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

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

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

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

Але це ще не все. Давайте тепер погля­не­мо без­по­се­ре­дньо на копії стану, які ми ство­рю­ва­ли. З чого скла­дає­ться стан реда­кто­ра? Наві­ть най­при­мі­ти­вні­ший реда­ктор пови­нен мати декі­лька полів для збе­рі­га­ння пото­чно­го текс­ту, пози­ції курсо­ра та про­кру­чу­ва­ння екра­ну. Щоб зро­би­ти копію стану, вам потрі­бно дода­ти зна­че­ння всіх цих полів до деяко­го «конте­йне­ра».

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

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

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

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

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

Зні­мок повні­стю від­кри­тий для тво­рця, але лише частко­во від­кри­тий для опікунів.

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

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

Кла­си­чна реа­лі­за­ція пате­рна покла­дає­ться на меха­ні­зм вкла­де­них кла­сів, який досту­пний тільки в деяких мовах про­гра­му­ва­ння (C++, C#, Java).

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

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

Опі­кун пови­нен знати, коли роби­ти зні­мок тво­рця та коли його потрі­бно відновлювати.

Опі­кун може збе­рі­га­ти істо­рію мину­лих ста­нів тво­рця у вигля­ді стека знім­ків. Коли треба буде ска­су­ва­ти оста­нню опе­ра­цію, він візьме «верх­ній» зні­мок зі стеку та пере­да­сть його тво­рце­ві для відновлення.

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

Під­хо­ди­ть для мов, що не мають меха­ні­зму вкла­де­них кла­сів (напри­клад, PHP).

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

Завдя­ки цьому дося­гає­ться той самий ефект, що і в кла­си­чній реа­лі­за­ції. Тво­ре­ць має повний доступ до знім­ка, а опі­кун — ні.

Якщо потрі­бно повні­стю виклю­чи­ти можли­ві­сть досту­пу до стану тво­рців та знімків.

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

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

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

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