Page 12 - 4252
P. 12

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


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

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

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

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

                                                           11
   7   8   9   10   11   12   13   14   15   16   17