Вибір правильної моделі дизайну

Я завжди визнавав важливість використання дизайнерських моделей. Мені цікаво, як інші розробники йдуть на вибір найбільш підходящого. Чи використовуєте ви ряд характеристик (як блок-схема), щоб допомогти вам прийняти рішення?

Наприклад:

Якщо об'єкти пов'язані, але конкретний клас ми не хочемо вказувати, розглянемо Анотацію

Коли примірник залишається похідним класам, врахуйте Factory

Потрібно отримувати доступ до елементів сукупного об'єкта послідовно, спробуйте Iterator

чи щось подібне?

Основна помилка в сучасному світі кодування полягає в тому, що моделі є будівельними блоками. Ви берете AbstractFactoryтут і Flyweightтам, а може і Singletonтам і з'єднуєте їх разом з XML та presto, у вас є робоча програма.

Їх немає.

Гм, це було недостатньо велико.

Візерунки не є будівельними блоками

Так краще.

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

Але зауважте, що це щось, що ви виявите у своєму коді, а не те, з чого ви починаєте. Творці Java не сказали : «О, ми будемо ставити муху в Integer» на самому початку, а скоріше зрозуміли , проблеми з продуктивністю , яка може бути вирішена з допомогою балансира .

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

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

Коли ви пишете код, розуміючи, що ви пишете Фабрику, ви можете сказати "а-ха! Це фабрика, про яку я буду писати", і використати свої знання про знання фабрики, щоб швидко написати наступний шматочок код, не намагаючись знову виявити заводський візерунок. Але ви не починаєте з "У мене тут клас, я напишу для нього фабрику, щоб він міг бути гнучким" - бо не буде.

Ось уривок з інтерв'ю з Еріхом Гаммою (про Gamma, Helm, Johnson та Vissides ): Як використовувати шаблони дизайну :

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

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

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

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

Я запитую себе:

1. Яку проблему я намагаюся вирішити?
2. Яка схема дизайну програмного забезпечення (якщо така є) найбільш тісно вирішує ту саму проблему або забезпечує логічний шлях до вирішення моєї проблеми?
3. Чи потрібна мені додаткова абстракція (і складність), яку надає модель, чи це надмірна інженерія для моєї конкретної проблеми? Чи можна вирішити проблему більш простим та ефективним способом без шаблону?

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