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

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

Напри­клад, ви ство­ри­ли інте­рфе­йс ЛітаючийТранспорт з мето­дом летіти(звідки, куди, пасажири), а потім опи­са­ли мето­ди класу Аеропорт так, щоб вони при­йма­ли будь-які об’єкти з цим інте­рфе­йсом. Тепер ви може­те бути впе­вне­ні в тому, що будь-який об’єкт, який реа­лі­зує інте­рфе­йс чи то Літак, Вертоліт чи ДресированийГрифон, зможе пра­цю­ва­ти з Аеропортом.

UML-діа­гра­ма реа­лі­за­ції та вико­ри­ста­ння інтерфейсу.

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

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

UML-діа­гра­ма оди­ни­чно­го спа­дку­ва­ння проти реа­лі­за­ції без­лі­чі інтерфейсів.

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

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

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

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

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

Для кра­що­го розу­мі­ння полі­мо­рфі­зм можна роз­гля­да­ти як зда­тні­сть об’єктів «при­ки­да­ти­ся» чимо­сь іншим. У вище­на­ве­де­но­му при­кла­ді соба­ки й коти при­ки­да­ли­ся абстра­ктни­ми тваринами.

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

Зале­жні­сть в UML-діа­гра­мах. Про­фе­сор зале­жи­ть від навча­льно­го курсу.

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

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

Асо­ціа­ція в UML-діа­гра­мах. Про­фе­сор взає­мо­діє зі студентом.

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

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

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

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

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

Агре­га­ція в UML-діа­гра­мах. Кафе­дра місти­ть професорів.

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

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

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

Пам’ятайте, що хоча ми