Page 96 - 4190

та. Приховування такої інформації від клієнтів допоможе уникнути
каскаду небажаних змін. Патерни проектування: абстрактна фабри-
ка, міст, зберережувач, заступник;
5) залежність від алгоритмів. Під час розроблення і подальшого

використання алгоритми часто розширюються, оптимізуються і замі-
нюються. Залежні від алгоритмів об’єкти доведеться переписувати
при кожній зміні алгоритму. Тому алгоритми, імовірність зміни яких

висока, доведеться ізолювати. Патерни проектування: міст. ітера-
тор, стратегія, шаблонний метод, відвідувач;
6) сильна пов’язаність. Сильно зв’язані між собою класи варто
використати окремо, оскільки вони залежать один від одного. Сильна

пов’язаність приводить до появи монолітних систем, в яких не мож-
ливо ні змінити, ні вилучити клас без знання деталей і модифікації
інших класів. Таку систему важко вивчати, переносити на інші плат-

форми і супроводжувати. Слабка пов’язаність підвищує імовірність
того, що клас можна буде повторно використовувати сам по собі. При
цьому вивчення, перенесення, модифікація і супроводження системи

суттєво спрощуються. Для підтримки слабко пов’язаних систем у
платформах проектування застосовують такі методи як абстрактні
зв’язки і поділ на шари. Патерни проектування: абстрактна фабри-

ка, міст. ланцюжок обов’язків, команда, фасад, посередник, спосте-
рігач;
7) розширення функціональності шляхом породження підкласів.
Спеціалізація об’єктів завдяки породженню підкласів часто виявля-

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

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

наторного росту числа класів, оскільки навіть для реалізації простого
розширення може знадобитися багато нових підкласів.
Композиція об’єктів і делегування – гнучкі альтернативи успад-

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

ному використанні композиції об’єктів проект може виявитися скла-
дним для розуміння. За допомогою багатьох патернів проектування

96