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

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

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

ДО: класи жорстко пов’язані.

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

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

КРАЩЕ: полі­мо­рфі­зм допо­міг спро­сти­ти код, але осно­вний код компа­нії все ще зале­жи­ть від конкре­тних кла­сів спів­ро­бі­тни­ків.

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

Ми може­мо зро­би­ти метод отри­ма­ння пра­ці­вни­ків у базо­во­му класі компа­нії абстра­ктним. Конкре­тні компа­нії пови­нні самі подба­ти про ство­ре­ння об’єктів спів­ро­бі­тни­ків. Отже, кожен тип компа­ній зможе мати вла­сний набір спів­ро­бі­тни­ків.

ПІСЛЯ: осно­вний код класу компа­нії став неза­ле­жним від кла­сів спів­ро­бі­тни­ків. Конкре­тних спів­ро­бі­тни­ків ство­рюю­ть конкре­тні класи компаній.

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

До речі, ви тільки що поба­чи­ли при­клад одно­го з пате­рнів, а саме — Фабри­чно­го мето­ду. Нада­лі ми ще пове­рне­мо­ся до нього.

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

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

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

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

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

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

Повто­рне вико­ри­ста­ння коду через наслі­ду­ва­ння може при­зве­сти до роз­ро­ста­ння ієра­рхії кла­сів.

У наслі­ду­ва­ння є аль­те­рна­ти­ва, яка нази­ває­ться компо­зи­цією. Якщо спа­дку­ва­ння можна вира­зи­ти сло­вом «є» (авто­мо­бі­ль є тра­нс­по­ртом), то компо­зи­цію — сло­вом «місти­ть» (авто­мо­бі­ль місти­ть двигун).

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

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

СПА­ДКУ­ВА­ННЯ: роз­ви­ток кла­сів у кількох пло­щи­нах (тип ванта­жу × тип дви­гу­на × тип наві­га­ції) при­зво­ди­ть до комбі­на­то­рно­го вибуху.

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

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

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

КОМПО­ЗИ­ЦІЯ: різні види функціо­на­льно­сті виді­ле­ні у вла­сні ієра­рхії класів.

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

Роз­гля­не­мо ще п’ять принци­пів прое­кту­ва­ння, які відо­мі як SOLID. Впе­рше ці принци­пи були опи­са­ні Робе­ртом Марті­ном у книзі Agile Software Development, Principles, Patterns, and Practices 6.

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

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

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