сформулювати й так: В«Мій модуль робить це. Вам не потрібно знати, як В». p align="justify"> Яскравим прикладом є правило приховування полів у класах. У них не повинно бути полів у відкритому доступі. Доступ до полів повинні забезпечувати спеціальні методи (accessors). Навіть якщо спочатку ці методи будуть працювати тривіально, у програміста буде можливість додати в них більш складну поведінку, не зламавши клієнтський код. Також можна зробити поле доступним тільки для читання, і всі це зрозуміють: немає методу на запис - значить, немає. Це ще одна ілюстрація необхідності єдності дизайну: якщо у всій системі доступ до полів надається через методи, всі будуть думати в цих термінах і не будуть намагатися шукати спосіб записувати значення в полі, для якого немає методу запису. p align="justify"> Крім того, інкапсуляція покращує якість абстракції: залишаючи тільки необхідне, зближується уявлення про об'єкт з його інтерфейсом. До того ж, приховану від чужих очей реалізацію можна замінити більш ефективною, не порушивши працездатності клієнтів. br/>
Залежності між модулями
Композиція (як і програмування взагалі) - справа непроста. Одні модулі використовують інші, через що виникають складні залежності. І ось вже будь-яку систему не можна розглядати як набір модулів, оскільки це моноліт, зібраний з того, що замишлялося як модулі, і обв'язаний навколо залежностями, при цьому жоден модуль не може працювати без інших. Модифікувати таку систему не просто важко, а неможливо. p align="justify"> Для боротьби з цим явищем існує кілька методів. Один з них називається Законом Деметри (не має прямого відношення до богині родючості, просто так називався проект, в якому розвинулася ця техніка), він формулюється так: В«Never talk to strangersВ» - В«Ніколи не розмовляйте з невідомимиВ». Проектувати системи таким чином складно, хоча можливо. До цього правила слід ставитися як до рекомендації. p align="justify"> Набагато більш дієве правило формулюється як В«Low coupling, high cohesionВ» - В«Низька зв'язність, високе зачепленняВ». Кожен модуль повинен бути зв'язковим (логічно єдиним) - елементи всередині модуля повинні бути сильно пов'язані між собою, інакше його варто розділити на кілька модулів. Різні модулі повинні бути пов'язані як можна менше. Ідеальним є випадок, коли зв'язки між модулями зовсім не утворюють циклів: B не залежить від A (прямо чи опосередковано, через інші модулі), якщо A залежить від B.
Те ж саме можна виразити в термінах горизонтальних і вертикальних залежностей. Хай по вертикалі йдуть рівні абстракції, а по горизонталі на кожному рівні - модулі, що відповідають цьому рівню. Так от горизонтальних зв'язків має бути якомога менше (краще, щоб не було зовсім), у той час як вертикальні зв'язку (наслідок композиції) повинні бути чіткими. p align="justify"> Виконання цього правила полегшує композицію і підтримує систему...
