Page 9 - 4252

Нестійкість, крихкість (fragile) - система ламається в непередбачених мі-
сцях, хоча зміни, були проведені до цього, зламані компоненти явно не зачіпа-
ли.
Нерухомість або монолітність (not reusable) - система побудована таким
чином і характер залежностей такий, що використовувати будь-які компоненти
окремо від інших не представляється можливим.
В'язкість (high viscosity) - код проекту такий, що зробити що-небудь не-
правильно набагато простіше, ніж зробити щось правильно.
Невиправдані повторення (high code duplication) - розмір проекту наба-
гато більший, ніж він міг би бути, якби абстракції застосовувалися частіше.
Надмірна складність (overcomplicated design) - проект містить рішення,
користь від яких неочевидна, вони приховують реальну суть системи, усклад-
нюючи її розуміння і розвиток.
Майже будь-який більш-менш досвідчений розробник може пригадати
приклад коду, який відповідав хоча б одному за цією ознакою.

Як зробити кращу архітектуру
За довгі роки розумні люди виробили деякі основоположні принципи
ООП, дотримання яких дозволяє створювати кращу архітектуру:
Висока зчепленість коду (High Cohesion) - код, відповідальний за яку-
небудь одну функціональність, повинен бути зосереджений в одному місці.
Низька зв'язаність коду (Low Coupling) - класи повинні мати мінімальну
залежність від інших класів.
Вказуй, а не питай (Tell, Don't Ask) - класи містять дані і методи для опе-
рування цими даними. Класи не повинні цікавитися даними з інших класів.
Не розмовляй з незнайомцями (Don't talk to strangers) - класи повинні
знати тільки про своїх безпосередніх сусідів. Чим менше знає клас про існуван-
ня інших класів або інтерфейсів - тим більш стійкий код.
Всі ці рекомендації спрямовані на те, щоб постаратися розвести класи по
сторонах, зосередити сильні взаємозв'язки в одному місці і провести чіткі роз-
межувальні лінії в коді.
Але ці принципи надто розпливчасті, тому з'явився якийсь набір більш чі-
тких правил, якими слід керуватися при формуванні архітектури.
Принцип персональної відповідальності (Single Responsibility Principle)
- клас володіє тільки 1 відповідальністю, тому існує тільки 1 причина, що при-
водить до його зміни.
Принцип відкриття-закриття (Open-Closed Principle) - класи повинні бу-
ти відкриті для розширень, але закриті для модифікацій. Здається, що це немо-
жливо, однак варто згадати шаблон проектування Strategy і стає більш-менш
зрозуміло.
Принцип підстановки Ліскоу (Liskov Substitution Principle) - дочірні кла-
си можна використовувати через інтерфейси базових класів без знання про те,
що це саме дочірній клас. Інакше - дочірній клас не повинен заперечувати по-
ведінку батьківського класу і повинна бути можливість використовувати дочір-
ній клас скрізь, де використовувався батьківський клас.

8