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

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

Компо­зи­ція в UML-діа­гра­мах. Уні­ве­рси­тет скла­дає­ться з кафедр.

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

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

Зага­льна карти­на

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

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

Зв’язки між об’єкта­ми та кла­са­ми — від найслаб­ших до найсильніших.

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

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

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

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

З чого скла­дає­ться пате­рн?

Описи пате­рнів зазви­чай дуже форма­льні й найча­сті­ше скла­даю­ться з таких пунктів:

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

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

Кла­си­фі­ка­ція пате­рнів

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

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

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

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

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

Стру­кту­рні пате­рни пока­зую­ть різні спосо­би побу­до­ви зв’язків між об’єкта­ми.

Пове­ді­нко­ві пате­рни піклую­ться про ефе­кти­вну кому­ні­ка­цію між об’єкта­ми.

Хто вига­дав пате­рни?

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

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

Ідея вида­ла­ся при­ва­бли­вою четві­рці авто­рів: Еріху Гаммі, Річа­рду Хелму, Ральфу Джо­нсо­ну, Джону Влі­ссі­де­су. У 1994 році вони напи­са­ли книгу Пате­рни прое­кту­ва­ння: повто­рно вико­ри­сто­ву­ва­ні еле­ме­нти архі­те­кту­ри об’єктно-оріє­нто­ва­но­го про­гра­мно­го забе­зпе­че­ння 4, до якої уві­йшли 23 пате­рни, що вирі­шую­ть різні про­бле­ми об’єктно-оріє­нто­ва­но­го дизайну. Назва книги була зана­дто довгою, щоб хтось зміг її запам’ятати. Тому неза­ба­ром усі стали нази­ва­ти її “book by the gang of four”, тобто «книга від банди чоти­рьох», а потім і зовсім “GoF book”.

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