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

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

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

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

Інкапсулюйте те, що змінюється

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

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

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

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

При­клад інка­псу­ля­ції на рівні мето­ду

При­пу­сті­мо, що ви роз­ро­бляє­те інте­рнет-мага­зин. Десь все­ре­ди­ні вашо­го коду зна­хо­ди­ться метод getOrderTotal, що роз­ра­хо­вує фіна­льну суму замов­ле­ння з ура­ху­ва­нням роз­мі­ру податку.

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

Через ці зміни вам дове­де­ться пості­йно торка­ти­ся мето­ду getOrderTotal, який, наспра­вді, не осо­бли­во ціка­ви­ться дета­ля­ми обчи­сле­ння податків.

method getOrderTotal(order) is
  total = 0
  foreach item in order.lineItems
    total += item.price * item.quantity

  if (order.country == "US")
    total += total * 0.07 // US sales tax
  else if (order.country == "EU"):
    total += total * 0.20 // European VAT

  return total

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

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

method getOrderTotal(order) is
  total = 0
  foreach item in order.lineItems
    total += item.price * item.quantity

  total += total * getTaxAmount(order.country)

  return total

method getTaxAmount(country) is
  if (country == "US")
    return 0.07 // US sales tax
  else if (country == "EU")
    return 0.20 // European VAT
  else
    return 0

ПІСЛЯ: роз­мір пода­тку можна отри­ма­ти, викли­ка­вши один метод.

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

При­клад інка­псу­ля­ції на рівні класу

Видо­бу­ти логі­ку пода­тків до вла­сно­го класу? Якщо логі­ка пода­тків стала зана­дто скла­дною, то чому б і ні?

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

Об’єкти замов­ле­нь деле­гу­ва­ти­му­ть обчи­сле­ння пода­тків окре­мо­му об’єкту-кальку­ля­то­ру податків.

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

Програмуйте на рівні інтерфейсу

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

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

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

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

До та після вилу­че­ння інте­рфе­йсу.
Код пра­во­руч більш гну­чкий, але й більш скла­дний від того коду, що ліворуч.