Як зробити кращу архітектуру

Якість архітектури. Ознаки загниваючого проекту

Отже, будь-який програмний код має взаємозалежності одних частин від інших. Класи вимагають наявності інших класів, одні функції викликають інші і т.д. У міру зростання будь-якого проекту взаємозалежностей стає все більше і більше. Вимоги до проекту змінюються, розробники іноді вносять швидкі й не завжди вдалі рішення. Якщо залежностями грамотно не управляти, то проект неминуче почне загнивати. Код стає складніше розуміти, він частіше ламається, стає менш гнучким і важким для повторного використання. У результаті швидкість розробки падає, проект чинить опір змінам, і ось вже серед розробників звучать заклики «Давайте все переробимо! Наступного разу ми зробимо супер-архітектуру». Ось найбільш поширені ознаки поганого або загниваючого в плані коду проекту:

- Закритість (rigid) - система відчайдушно чинить опір змінам, неможливо сказати, скільки займе реалізація тієї або іншої функціональності, тому що зміни, швидше за все, торкнуться багатьох компонентів системи. Через це вносити зміни стає занадто дорого, тому що вони вимагають багато часу.

- Нестійкість, крихкість (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) - дочірні класи можна використовувати через інтерфейси базових класів без знання про те, що це саме дочірній клас. Інакше - дочірній клас не повинен заперечувати поведінку батьківського класу і повинна бути можливість використовувати дочірній клас скрізь, де використовувався батьківський клас.

Принцип інверсії залежностей (Dependency Inversion Principle) - всередині системи стоять на основі абстракцій. Модулі верхнього рівня не залежать від модулів нижнього рівня. Абстракції не залежать від подробиць.

Принцип відділення інтерфейсу (Interface Segregation Principle) - клієнти не повинні потрапляти в залежність від методів, якими вони не користуються. Клієнти визначають, які інтерфейси їм потрібні.

Дата добавления: 2017-02-01