Практичне застосування паттернів проектування

Найчастіше причини, по яких варто вивчати паттерни проектування, формулюють наступним чином [10]:

1. Можливість багаторазового використання. Повторне використання рішень із уже завершених успішних проектів дозволяє швидко приступити до рішення нових проблем і уникнути типових помилок. Розробник одержує пряму вигоду від використання досвіду інших розробників, уникнувши необхідності знову і знову «винаходити велосипед».

2. Застосування єдиної термінології. Професійне спілкування і робота в групі (команді розробників) вимагає наявності єдиного базового словника і єдиної точки зору на проблему. Паттерни проектування надають подібну загальну точку зору як на етапі аналізу, так і при реалізації проекту.

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

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

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

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

1. Відшукати паттерни, що є присутніми у ПрО, і проаналізувати отриманий набір.

2. Для отриманого набору паттернів виконати такі дії:

а) вибрати паттерн, що найбільшою мірою формує контекст для всіх інших паттернів;

б) застосувати цей паттерн до самого верхнього рівня реалізації проекту;

в) виявити будь-які додаткові паттерни, що можуть з’явитися в отриманій схемі, і додати їх до набору, що був отриманий у результаті попереднього аналізу;

г) повторно застосувати зазначений процес до набору паттернів, виділених у результаті аналізу.

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

При розробці дизайну системи варто керуватися такими базовими принципами [12]:

- завжди формувати простий дизайн: із двох запропонованих рішень, як правило, кращим є те, що простіше;

- слабка залежність: дизайн модуля повинен бути таким, що б у випадку його модифікації залежні фрагменти системи не вимагали або майже не вимагали змін.

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

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

При практичному застосуванні паттернів проектування також не слід забувати про те, що ООП постійно розвивається. Підходи, які раніше вважалися зразковими, згодом можуть стати антипаттернами [14], а їм на зміну можуть прийти значно кращі рішення (як, наприклад, трапилося з паттерном Sіngleton).

Поиск по сайту: