Принципи гарної ахрітектури

Принцип відкриття-закриття (Open Close Principle або OCP)

Програмні суті такі як класи, модулі та функції повинні бути відкриті для розширення, але закриті для змін.

Ви можете обговорювати його, коли пишете ваші класи, щоб бути впевненими в тому, що коли вам буде потрібно розширити поведінку, ви не повинні будете змінювати клас, але можете розширювати його. Подібний же принцип застосуємо для модулів, пакетів і бібліотек. Якщо у вас є бібліотека, що складається з множини класів, то є багато причин для того, щоб ви вважали за краще розширення замість зміни коду, який вже написаний (заради зворотної сумісності, повернення до попереднього тестування і т.д.). Це причина, по якій ми повинні бути впевнені, що наші модулі слідують Принципу відкриття-закриття. По відношенню до класів Принцип відкриття-закриття може бути гарантовано корисний за рахунок використання Абстрактних Класів і конкретних класів для реалізації їх поведінки. Це буде змушувати мати Конкретні Класи, що розширюють Абстрактні Класи замість їх зміни. Деякі приватні випадки цього принципу є Шаблонний Патерн і Стратегічний Патерн (Template Pattern and Strategy Pattern).

Принцип Заміщення Ліскоу (Liskov's Substitution Principle)

Похідні типи повинні бути здатні повністю заміщатися їх базовими типами.

Цей принцип є всього лише розширенням Принципу відкриття-закриття в умовах поведінки, що означає, що ми повинні бути впевнені, що нові похідні класи є розширенням базових класів без зміни їх поведінки. Нові похідні класи повинні бути здатні замінювати базові класи без будь-яких змін у коді. Принцип Заміщення Ліскоу був введений на 1987 Conference on Object Oriented Programming Systems Languages and Applications, in Data abstraction and hierarchy.

Принцип Єдиної Відповідальності (Single Responsibility Principle)

Клас повинен мати тільки одну причину для зміни.

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

Принцип Єдиної Відповідальності був введений Tom DeMarco в його книзі «Structured Analysis and Systems Specification, 1979». Роберт Мартін переробив цю концепцію і визначив, що відповідальність є причиною для зміни.

Принцип Відділення Інтерфейсу (Interface Segregation Principle)

Клієнти не повинні бути залежними від інтерфейсів, які вони не використовують.

Цей принцип вчить нас піклуватися про те, як ми пишемо наші інтерфейси. Коли ми пишемо інтерфейси, ми повинні подбати про додавання тільки тих методів, які там повинні бути. Якщо ми додаємо методи, які не повинні бути там, тоді класи, що реалізують інтерфейс будуть повинні реалізовувати зайві методи так само як і інші методи. Наприклад, якщо ми створюємо інтерфейс, званий Worker (Робочий) і додаємо метод lunch break (обідня перерва), тоді всі workers (робітники) будуть мати реалізацію цього зайвого методу. А що якщо робітник виявився роботом?

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

Принцип інверсії залежностей

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

Принцип інверсії залежностей в деталях

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

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

Суть принципу

1. Модулі верхнього рівня не повинні залежати від модулів нижнього рівня. Обидва типи модулів повинні залежати від абстракцій;

2. Абстракція не повинна залежати від реалізації. Реалізація повинна залежати від абстракції.

Традиційні методи розробки (наприклад, процедурне програмування) мають тенденцію до створення коду, в якому високорівневі модулі, як раз, залежать від низькорівневих. Це відбувається через те, що одна з цілей цих методів розробки - визначення ієрархії підпрограм, а отже і ієрархії викликів усередині модулів (високорівневі модулі викликають низькорівневі). Саме це є причиною низької гнучкості і закостенілості дизайну. При правильному використанні, ГО методики дозволяють обійти це обмеження.

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

Повторне використання коду (англ. code reuse) - методологія проектування комп'ютерних та інших систем, що полягає в тому, що система (комп'ютерна програма, програмний модуль) частково або повністю повинна складатися з частин, написаних раніше компонентів і / або частин іншої системи. Повторне використання - основна методологія, яка застосовується для скорочення трудовитрат при розробці складних систем.

Найпоширеніший випадок повторного використання коду - бібліотеки програм. Бібліотеки надають загальну досить універсальну функціональність, яка покриває обрану предметну область. Приклади: Бібліотека функцій для роботи з комплексними числами, бібліотека функцій для роботи з 3D-графікою, бібліотека для використання протоколу TCP / IP, бібліотека для роботи з базами даних. Розробники нової програми можуть використовувати існуючі бібліотеки для вирішення своїх завдань.

Повторне використання коду за межами одного проекту практично неможливо, якщо у вас немає розробленого проектного каркаса [framework]. У різних проектах різні набори сервісів, що і ускладнює повторне використання об'єкта.

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