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

знати патерни?"> Навіщо знати патерни?

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

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

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

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

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

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

Повто­рне вико­ри­ста­ння коду

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

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

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

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

Наве­ду цита­ту Еріха Гамми 5, одно­го з першо­від­кри­ва­чів пате­рнів, про повто­рне вико­ри­ста­ння коду та ролі пате­рнів у ньому.

Існує три рівні повто­рно­го вико­ри­ста­ння коду. На само­му нижньо­му рівні зна­хо­дя­ться класи: кори­сні бібліо­те­ки кла­сів, конте­йне­ри, а також «кома­нди» кла­сів типу конте­йне­рів/іте­ра­то­рів.

Фре­ймво­рки стоя­ть на найви­що­му рівні. В них важли­вою є тільки архі­те­кту­ра. Вони визна­чаю­ть клю­чо­ві абстра­кції для вирі­ше­ння деяких бізнес-зав­да­нь, пре­д­став­ле­ні у вигля­ді кла­сів і від­но­син між ними. Візьмі­ть JUnit, це дуже мале­нький фре­ймво­рк. Він місти­ть усьо­го декі­лька пов’яза­них між собою кла­сів: Test, TestCase та TestSuite. Зазви­чай фре­ймво­рк має наба­га­то більший обсяг, ніж один клас. Ви вкли­нює­те­сь у фре­ймво­рк, роз­ши­ряю­чи деко­трі його класи. Все пра­цює за так зва­ним гол­лі­ву­дським принци­пом: «не теле­фо­ну­йте нам, ми самі вам зате­ле­фо­нує­мо». Фре­ймво­рк дозво­ляє вам зада­ти якусь свою пове­ді­нку, а потім, коли при­хо­ди­ть черга щось роби­ти, сам викли­кає її. Те ж саме від­бу­ває­ться і в JUnit. Він зве­ртає­ться до вашо­го класу, коли потрі­бно вико­на­ти тест, але все інше від­бу­ває­ться все­ре­ди­ні фреймворка.

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

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

Роз­ши­рю­ва­ні­сть

Зміни часто нази­ваю­ть голо­вним воро­гом програміста.

Ви при­ду­ма­ли ідеа­льну архі­те­кту­ру інте­рнет-мага­зи­ну, але через міся­ць дове­ло­ся дода­ти інте­рфе­йс для замов­ле­нь телефоном. Ви випу­сти­ли відео­гру під Windows, але потім зна­до­би­ла­ся під­трим­ка macOS. Ви зро­би­ли інте­рфе­йсний фре­ймво­рк з ква­дра­тни­ми кно­пка­ми, але кліє­нти поча­ли про­си­ти круглі.

У кожно­го про­гра­мі­ста кілька­на­дця­ть поді­бних істо­рій. Є кілька при­чин, чому так відбувається.

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

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

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

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