Page 13 - 4252

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

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

Наш модуль copy може виглядати приблизно так.

while (($ data = readKeyboard ())! == false)
{
writeFile (". / filename", $ data);
}

Низькорівневі модулі readKeyboard і writeFile володіють високою гнучкіс-
тю. Ми легко можемо використовувати їх у контексті відмінному від функції
copy. Проте сама функція «copy» не може бути повторно використана в іншому
контексті. Наприклад, для відправки даних з файлу системного оброблювача
логів.
Використовуючи принцип інверсії залежностей, можна зробити модуль
copy незалежним від об'єктів джерела і призначення даних. Для цього необхід-
но виробити абстракції для цих об'єктів, і зробити модулі залежними від цих
абстракцій, а не один від одного.

12