Page 11 - 4252

ЛЕКЦІЯ 2

ПРИНЦИПИ ГАРНОЇ АРХІТЕКТУРИ

Принцип відкриття-закриття (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 класи. Кожен клас повинен ма-
ти тільки одну відповідальність, і в майбутньому, якщо нам буде потрібно зро-

10