Як визначити, чи правильно виконано шаблон дизайну?

Я успішно вмію масштабувати всі мої старі програми, які не використовували задокументовані шаблони дизайну. Якою б не була модель, я не знаю. Значною мірою я відчував лише потребу у використанні простих концепцій ООП.

Концепція шаблонів дизайну є складною і важкою для розуміння. Як реалізується, як визначити, чи правильна реалізація та чи програма має реальну розв'язаність?

Щоб відповідь була лаконічною, я б сказав, якщо наступні характеристики видно у вашому коді, ви можете бути впевнені, що шаблони існують, навіть якщо ви не доклали зусиль (що це не проблема) щодо цього.

Бажані характеристики:

1. База коду перевіряється на рівні одиниці
2. Щоразу, коли ви впроваджуєте будь-які запити на зміни, ви вносите зміни лише у відповідні класи, які співвідносяться у домені.
3. У вашій кодовій базі не виявляється ентропія програмного забезпечення .

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

1. Зворотний інженер для вашої кодової бази, щоб генерувати кілька дамрів UML.
2. Візуально порівняйте діаграми з будь-якими готовими посиланнями на довідковий матеріал зразків.

Це повинно дати вам добру думку.

Ви згадуєте як схеми дизайну, так і з'єднання. Це окремі поняття, тому я з ними розбираюся окремо. Єдиний справжній зв’язок полягає в тому, що моделі дизайну, як правило, сприяють слабкому з'єднанню (оскільки це головний аспект хорошого дизайну).

Шаблони дизайну

Концепція шаблонів дизайну насправді досить проста: вони просто набір шаблонів, як вирішувати різні поширені проблеми. Є дві основні причини, по яких вони популярні:

1. Вони «перевірені»: вони використовувалися раніше, і переваги / недоліки кожного з них відомі, зокрема відомі будь-які найтонші проблеми, які можуть спричинити великі проблеми.
2. Вони надають загальний набір термінології, і таким чином дозволяють легше спілкуватися. Якщо хтось каже, що "клас X грає роль спостерігача за схемою спостерігача", тоді розробники, які знайомі з цим шаблоном, можуть негайно зрозуміти, що відбувається.

Звідки ви знаєте, що ви правильно його реалізували? Це хитро. Для більшості моделей це просто - ви або прикусили його, або не зробили. Деякі зразки менш чітко визначені, ніж інші - наприклад, модель-перегляд-контролер . Такі зразки краще використовувати як загальні вказівки. Специфіка того, як ви його реалізуєте, менш важлива, ніж розуміння причин того, що існує, і того, що його потрібно досягти.

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

Зчеплення

Це дійсно важлива ідея в галузі інформатики. Оскільки вимоги до більшості програмних проектів змінюються з часом (іноді значно), то здатність дизайну впоратися зі змінами є важливою. З'єднання в основному є мірою "як важко було б замінити цей компонент на інший?" "Компонент" може бути методом, класом, пакетом, бібліотекою тощо.

У цій статті у Вікіпедії перераховані різні типи зчеплення .

Відповідь насправді - мета, яку ви хочете написати зразки дизайну з самого початку. Чому ви хочете гнучкість?

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

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

Шаблони дизайну самі по собі є реалізацією Об'єктно-орієнтованих принципів дизайну. Поки ви дотримуєтесь цих принципів, ваші програми будуть гнучкими та масштабованими; навіть якщо ви дійсно не маєте фактичного дизайну. Як коментував вище Йоахім Зауер, вони є загальними рішеннями загальних проблем.