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

ускла­дне­нням коду про­гра­ми. У реа­льно­му житті немає, мабу­ть, тако­го коду, в якому дотри­му­ва­ли­ся б усі ці принци­пи від­ра­зу. Тому пам’ятайте про бала­нс і не спри­ймайте все викла­де­не як догму. S Принцип єди­но­го обо­в'я­зку Single Responsibility Principle

Клас має мати лише один мотив для зміни.

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

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

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

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

При­клад

Клас Employee має від­ра­зу кілька при­чин для зміни. Перша пов’язана з голо­вним зав­да­нням класу — керу­ва­нням дани­ми спів­ро­бі­тни­ка. Але є й інша: зміни, пов’язані з форма­ту­ва­нням звіту для друку, зачі­па­ти­му­ть клас спів­ро­бі­тни­ків.

ДО: клас спів­ро­бі­тни­ка місти­ть різно­рі­дні поведінки.

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

ПІСЛЯ: зайва пове­ді­нка пере­їха­ла до вла­сно­го класу.

O Принцип від­кри­то­сті/закри­то­сті Open/Closed Principle

Роз­ши­рю­йте класи, але не змі­ню­йте їхній поча­тко­вий код.

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

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

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

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

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

При­клад

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

ДО: код класу замов­ле­ння потрі­бно буде змі­ню­ва­ти при дода­ва­нні ново­го спосо­бу доставки.

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

ПІСЛЯ: нові спосо­би доста­вки можна дода­ти, не зачі­паю­чи клас замовлень.

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

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

L Принцип під­ста­но­вки Лісков Liskov Substitution Principle 7

Під­кла­си пови­нні допо­вню­ва­ти, а не під­мі­ня­ти пове­ді­нку базо­во­го класу.

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

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

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

Типи пара­ме­трів мето­ду під­кла­су пови­нні збі­га­ти­ся або бути більш абстра­ктни­ми, ніж типи пара­ме­трів базо­во­го мето­ду. Зву­чи­ть заплу­та­но? Роз­гля­не­мо, все на прикладі.

Базо­вий клас має метод feed(Cat c), який вміє году­ва­ти хатніх котів. Кліє­нтський код це знає і завжди пере­дає до мето­ду кота. Добре: Ви ство­ри­ли під­клас і пере­ви­зна­чи­ли метод году­ва­ння так, щоб наго­ду­ва­ти будь-яку тва­ри­ну: feed(Animal c). Якщо під­ста­ви­ти цей клас у кліє­нтський код — нічо­го пога­но­го не ста­не­ться. Кліє­нтський код пода­сть до мето­ду кота, але метод вміє году­ва­ти всіх тва­рин, тому наго­дує і кота. Пога­но: Ви ство­ри­ли інший під­клас, в якому є метод, що