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

Фабри­чний метод нері­дко буває части­ною вели­ко­го класу з Шабло­нни­ми мето­да­ми.

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

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

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

Про­бле­ма

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

Екс­по­рт гео-вузлів до XML.

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

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

Код XML-екс­по­рту дове­де­ться дода­ти до всіх кла­сів вузлів, а це дуже невигідно.

До того ж він сумні­ва­вся в тому, що екс­по­рт до XML вза­га­лі є доре­чним в рам­ках цих кла­сів. Їхнє осно­вне зав­да­ння пов’язане з гео­да­ни­ми, а екс­по­рт вигля­дає в межах цих кла­сів, як біла ворона.

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

Ріше­ння

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

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

class ExportVisitor implements Visitor is
  method doForCity(City c) { ... }
  method doForIndustry(Industry f) { ... }
  method doForSightSeeing(SightSeeing ss) { ... }
  // ...

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

foreach (Node node : graph)
  if (node instanceof City)
    exportVisitor.doForCity((City) node);
  if (node instanceof Industry)
    exportVisitor.doForIndustry((Industry) node);
  // ...

Тут не допо­мо­же наві­ть меха­ні­зм пере­ва­нта­же­ння мето­дів (досту­пний у Java і C#). Якщо назва­ти всі мето­ди одна­ко­во, то неви­зна­че­ні­сть реа­льно­го типу вузла все одно не дасть викли­ка­ти пра­ви­льний метод. Меха­ні­зм пере­ва­нта­же­ння весь час викли­ка­ти­ме метод від­ві­ду­ва­ча, від­по­від­ний типу Node, а не реа­льно­го класу пода­но­го вузла.

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

// Client code
foreach (Node node : graph)
  node.accept(exportVisitor);

// City
class City is
  method accept(Visitor v) is
    v.doForCity(this);
  // ...

// Industry
class Industry is
  method accept(Visitor v) is
    v.doForIndustry(this);
  // ...

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

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

У стра­хо­во­го аге­нта при­го­то­ва­ні полі­си для різних видів організацій.

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

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