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

інте­рфе­йс не від­по­від­ає решті кодів програми.

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

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

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

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

Кроки реа­лі­за­ції

Пере­ко­найте­ся, що у вас є два класи з незру­чни­ми інтерфейсами:

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

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

Ство­рі­ть клас ада­пте­ра, реа­лі­зу­ва­вши цей інтерфейс.

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

Реа­лі­зу­йте всі мето­ди кліє­нтсько­го інте­рфе­йсу в ада­пте­рі. Ада­птер пови­нен деле­гу­ва­ти осно­вну робо­ту сервісу.

Про­гра­ма пови­нна вико­ри­сто­ву­ва­ти ада­птер тільки через кліє­нтський інте­рфе­йс. Це дозво­ли­ть легко змі­ню­ва­ти та дода­ва­ти ада­пте­ри в майбутньому.

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

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

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

Ада­птер надає класу аль­те­рна­ти­вний інте­рфе­йс. Деко­ра­тор надає роз­ши­ре­ний інте­рфе­йс. Замі­сник надає той самий інтерфейс.

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

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

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

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

Про­бле­ма

Абстра­кція? Реа­лі­за­ція?! Зву­чи­ть стра­хі­тли­во! Роз­гля­ньмо про­сте­нький при­клад, щоб зро­зу­мі­ти про що йде мова.

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

Кількі­сть під­кла­сів зро­стає в гео­ме­три­чній прогресії.

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

Ріше­ння

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

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

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

Таким чином, ми може­мо зро­би­ти Колір окре­мим кла­сом з під­кла­са­ми Червоний та Синій. Клас Фігур отри­має поси­ла­ння на об’єкт Кольору і зможе деле­гу­ва­ти йому робо­ту, якщо вини­кне така нео­бхі­дні­сть. Такий зв’язок і стане мостом між Фігурами та Кольором. При дода­ва­нні нових кла­сів кольо­рів не потрі­бно буде зве­рта­ти­сь до кла­сів фігур і навпаки.

Абстра­кція і Реа­лі­за­ція

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