Методичні вказівки до виконання самостійних робіт з дисципліни: «проектний практикум»



Сторінка1/6
Дата конвертації19.03.2016
Розмір1.1 Mb.
  1   2   3   4   5   6
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

МАРІУПОЛЬСЬКИЙ МАШИНОБУДІВНИЙ КОЛЕДЖ

ДЕРЖАВНОГО ВИЩОГО НАВЧАЛЬНОГО ЗАКЛАДУ

"ПРИАЗОВСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ"



МЕТОДИЧНІ ВКАЗІВКИ

до виконання самостійних робіт

з дисципліни:
«ПРОЕКТНИЙ ПРАКТИКУМ»
Для студентів спеціальності:

5.05010301«Розробка програмного забезпечення»

Розробив викладач

ММК ДВНЗ "ПДТУ" ___________ В.В.Горобей
Розглянуто та схвалено

на засіданні циклової комісії

ММК ДВНЗ ПДТУ Протокол № ____

від ___________20___ р.


Голова циклової комісії

з напряму 6.050103 «Програмна

інженерія» ММК ДВНЗ "ПДТУ" __________ О.О.Тузенко

ПОЯСНЮВАЛЬНА ЗАПИСКА


Відповідно до навчального плану на вивчення курсу предмета "Проектний практикум" студентами спеціальності 5.05010301«Розробка програмного забезпечення» призначено 33 години та 18 годин (прискорена підготовка) на самостійну роботу.

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

У ході самостійної роботи студент повинен користуватися методичними вказівками викладача, у яких викладені технологія, послідовність самостійного вивчення теми чи розділу, можливі помилки в розумінні теми.

Самостійна підготовка студентів має ціль:



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

  • Прищеплювання студентам навичок самостійної роботи з літературою і електроними джерелами інформації.

Задачі курса:

  • Розширити знання студентів вивченням тем і розділів предмета, визначених робочею програмою для самостійних занять;

  • Поглибити знання студентів вивченням тем і розділів, висунутих робочею програмою на лекційні та лабораторні заняття;

  • Навчити студентів працювати зі спеціальною літературою по предмету;

  • Виробити у студентів навички по самостійному створенню конспектів, довідкових посібників, інструкцій;

  • Навчити студентів роботі з електроними джерелами інформації.

Завдання для самостійної роботи студентів з предмету

«Проектний практикум»





Змістовий модуль

Кількість годин

Питання, які студент повинен розглянути

Форми контролю

1

2

3

4

5

1


Змістовий модуль 1.

Шаблони проектування



8

Різноманітні шаблони проектування

Реферат

Шаблони Façade, Adapter, Bridge

Тестове опитування

2

Змістовий модуль 2.

Специфікація та документування вимог



8/6

Розробка специфікацій для обраної предметної області

Розробка специфікацій

Проектування постановки задачі, аналізу предметної області

Усне опитування

3

Змістовий модуль 3.

Технології розробки програмного забезпечення



8/6

Технології розробки програмного забезпечення (RAD, RUP, KANBAN)

Реферат, усне опитування, тестове опитування

4

Змістовий модуль 4.

Процеси управління якістю програмного забезпечення



9/6

Види моделі оцінки зрілості проекту, відповідність програмного забезпечення основим положенням моделі

Письмове опитування




Разом годин

33/18






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

Реферат оформляється письмово на аркушах паперу формату А4 з титульним аркушем.

Змістовий модуль 1. Шаблони проектування

Проектування проекту з використанням шаблону Façade
У книзі "банди чотирьох" призначення шаблону Facade (фасад) визначається наступним чином. Надання єдиного інтерфейсу для набору різних інтерфейсів в системі. Шаблон Facade визначає інтерфейс більш високого рівня, що упрощаетработу з системою. В основному цей шаблон використовується в тих випадках, коли необхідний новий спосіб взаємодії з системою - простіший порівняно з уже існуючим. Крім того, він може застосовуватися, коли потрібно використовувати систему деяким специфічним чином - наприклад, звертатися до програми тривимірної графіки для побудови двомірних зображень. У цьому випадку нам буде потрібно спеціальний метод взаємодії з системою, оскільки використовуватиметься лише частина її функціональних можливостей.

У моїй практиці був випадок, коли я працював за контрактом для великої інженерно-виробничої компанії. У день мого першого появи на новому робочому місці безпосередній керівник проекту був відсутній. Компанія відмовлялася оплатити цей робочий день просто так, але ніхто не знав, яке завдання мені слід доручити. Вони хотіли, щоб я робив хоч чтонибудь, навіть якщо це не принесло б ніякої користі! Думаю, вам теж доводилося стикатися з чимось подібним. Зрештою, одна зі співробітниць знайшла для мене заняття. Вона сказала: "Вважаю, що рано чи пізно, але вам обов'язково потрібно вивчити ту САПР, яка використовується у нас в даний час, - так що ви можете приступити до цього прямо зараз ". Після цих слів дівчина вказала мені на стос документації, що займала на книжковій полиці майже 3 метри. Книги були надруковані дрібним шрифтом на аркушах формату А4, і вся ця гора паперу представляла собою технічний опис однієї єдиної, але дуже складною системи.

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

Це і є шаблон проектування Facade. Він спрощує використання складної системи, окремої частини системи або забезпечує звернення до системи деяким специфічним чином. Ми маємо складну систему, і нам потрібно використовувати тільки якусь її частину (окремий модуль). В результаті застосування шаблону Facade ми отримаємо нову, більш просту у використанні систему, яка будетточно відповідати нашим потребам.

Основна частина роботи як і раніше буде виконуватися вихідною системою. Шаблон Facade надає лише колекцію методів, простих у розумінні та використанні. Ці методи звертаються до основної системи для реалізації знову певних функцій зовнішньої системи.


Шаблон Facade також може використовуватися для приховування або інкапсуляції базової системи. У цьому випадку клас Facade включає основну систему як свій закритий член. Тому основна система буде взаємодіяти тільки з класом Facade, залишаючись недоступною і невидимою для всіх інших користувачів.

Є декілька причин для інкапсуляції основної системи.

• Контроль за використанням системи. Змушуючи користувачів всі звернення до системи виконувати тільки через клас Facade, легко можна контроліроватьіх доступ до неї.

• Спрощення заміни системи. У майбутньому може знадобитися замінити існуючу систему нової. Подання базової системи як закритого члена класу Facade істотно спрощує цю процедуру. Хоча обсяг необхідних змін може виявитися досить великим, всі вони будуть зосереджені тільки в одному місці програмного коду - в класі Facade.
Шаблон проектування Facade названий так тому, що він як би встановлює новий фасад (інтерфейс) для основної системи. Шаблон Facade застосовується в наступних випадках.

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

• Існує необхідність в інкапсуляції первісної системи.

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

• Вартість розробки нового класу менше вартості навчання всіх учасників проекту роботі з базовою системою або суми майбутніх витрат на супровід створюваної ними системи.

Проектування проекту з використанням шаблону Adapter

Найпростіший спосіб зрозуміти призначення шаблону Adapter - це розглянути його

застосування на прикладі. Припустимо, існують такі вимоги.

• Створити класи для представлення в системі точок, ліній і квадратів, кожен з яких матиме метод display (відобразити).

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

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

• При цьому включити готову підпрограму безпосередньо в створювану програму неможливо.

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

абстрактні фігури.

• Це дозволить об'єктам-клієнтам працювати з будь-якими типами об'єктів-даних одним і тим же чином, не беручи до уваги існуючі між ними відмінності (рис. 7.1).

• Крім того, з'являється можливість згодом додавати в систему нові види фігур, не вносячи жодних змін в ті об'єкти, які будуть їх використовувати.


Тут використовується принцип поліморфізму; тобто в системі присутні об'єкти-дані різних типів, але використовують їх об'єкти-клієнти повинні взаємодіяти з ними одним і тим же чином. У результаті об'єкт-клієнт може просто вказати об'єкту-даному (незалежно від того, представляє він точку, лінію або квадрат), що необхідно виконати ту чи іншу дію - наприклад, відобразити себе на екрані або, навпаки, видалити з екрану своє зображення. У цьому випадку кожен об'єкт, що представляє точку, лінію або квадрат, повинен буде нести повну відповідальність за коректне виконання необхідних операцій в повній відповідності зі своїм типом. Для вирішення поставленого завдання створимо клас Shape (фігура), а потім визначимо похідні від нього класи, що представляють точки (Point), лінії (Line) і квадрати

(Square) - як показано на рис. 7.2.



Насамперед необхідно визначити специфічну поведінку, яке повинен демонструвати клас Shape. Для вирішення цього завдання слід описати у ньому інтерфейс виклику методів, відповідальних за поведінку, а потім реалізувати ці методи в кожному з породжених класів. Поведінка, яка має демонструвати клас Shape, передбачає наступні методи (рис. 7.3).

• Отримати дані про становище об'єкта Shape (метод setLocation).

• Повідомити дані про становище об'єкта Shape (метод getLocation).

• Показати представлену об'єктом фігуру на екрані (метод display).

• Зафарбувати зображення фігури вказаним кольором (метод fill).

• Встановити колір зафарбовування фігури (метод setColor).

• Видалити зображення фігури з екрана (метод undisplay).

Припустимо, що в систему необхідно включити новий тип об'єктів класу Shape, призначений для представлення кіл (не забувайте, що вимоги постійно змінюються!). Для цієї мети створимо новий клас, Circle (Коло), який представлятиме в системі окружності. Реалізуємо клас Circle як похідний від класу Shape, що дозволить скористатися перевагами його полиморфного поведінки.

Тепер необхідно написати методи display, fill і Undisplay для класу Circle. Це завдання може виявитися досить складною. На щастя, після недовгих пошуків альтернативних рішень (що завжди повинен робити кожен хороший програміст), з'ясувалося, що один з моїх колег вже описав в системі клас XXCircle, призначений для роботи з колами (рис. 7.4). На жаль, він попередньо не порадився зі мною, як краще назвати методи цього класу, тому вони отримали такі імена:

• displayIt

• fillIt

• undisplayIt

В результаті, безпосередньо використовувати клас XXCircle не можна, оскільки бажано зберегти поліморфну ​​поведінку, реалізоване в класі Shape, але цьому перешкоджають наступні моменти.

• Клас Shape і клас XXCircle включають методи з різними іменами і різними списками параметрів.

• Клас XXCircle повинен не тільки мати співпадаючі імена методів, а й обов'язково бути похідним від класу Shape.




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

• Функції, реалізовані у вже існуючому класі, просто адаптуються за описаною вище схемою.

• Відсутні функції реалізуються заново - безпосередньо в об'єкті-оболонці. Це менш ефективне рішення, але воно все ж дозволяє уникнути реалізації всієї необхідної функціональності. Шаблон Adapter дозволяє в процесі пр оектірованія не брати до уваги можливих відмінностей в інтерфейсах вже існуючих класів. Якщо є клас, що володіє необхідними методами і властивостями, - принаймні, концептуально, то при необхідності завжди можна буде т скористатися шаблоном Adapter для приведення його інтерфейсів до потрібного вигляду. Ця особливо важливо, якщо застосовується відразу кілька шаблонів, оскільки багато шаблони вимагають, щоб використовувані в них класи були породжені від одного і того ж класу. Якщо в проект предст ВІТ включити вже існуючі класи, шаблон Adapter може використовуватися для адаптації їх до необхідного абстрактного класу (подібно до того, як клас ХХCircle був адаптований до абстрактноктного класу Shape за допомогою класу-оболонки Circle). Фактично існує два типи шаблонів Adapter.

• Об'єктний шаблон Adapter. Той варіант шаблону Adapter, який ми обговорювали вище, називають об'єктним шаблоном Adapter, оскільки він реалізується за допомогою приміщення одного об'єкт а (адаптируемого) в інший (адаптирующий).

• Класовий шаблон Adapter. Другий варіант реалізації шаблону Adapter використовує механізм множинного спадкоємства і отримав назву клас ¬ сового шаблону Adapter.

• Як шаблон Facade, так і шаблон Adapter використовують вже існуючі класи.

• Однак для шаблону Facade необхідно самостійно розробити необхідний інтерфейс, а не використовувати вже існуючий, як для шаблону Adapter.

• Реалізація шаблону Facade Не перед вбачає підтримки поліморфізму, тоді як при застосуванні шаблону Adapter це може виявитися необхідним. (Можливі ситуації, при яких потрібна лише підтримка певного API, а значить, при використанні шаблону Adapter поліморфізм нас цікавити не буде - саме тому тут вжито слово "може").

• При використанні шаблону Facade наша мета - спростити існуючий інтерфейс. А для шаблону Adapter нам потрібна підтримка вже існуючого інтерфейсу і не допускаються ніякі спрощення, навіть якщо вони цілком можливі.

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

• Наявність варіацій в абстрактному представленні концепцій.

• Наявність варіацій в тому, як ці концепції реалізуються.

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

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

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

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

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

Наше завдання полягає в тому, щоб визначити, де можливі зміни (аналіз спільності), а потім встановити, як це зміна відбувається (аналіз мінливості). За Коплін, "аналіз спільності полягає в пошуку спільних елементів, що допоможе зрозуміти, чим члени сімейства схожі один на одного." Таким чином, це процес пошуку спільних рис у всіх елементах, складових деяке сімейство (і, отже, їх відмінностей). Аналіз мінливості дозволяє встановити, яким чином члени сімейства змінюються. Мінливість має сенс тільки в межах даної спільності. Аналіз спільності передбачає виявлення структур, які навряд чи будуть змінюватися з плином часу, тоді як аналіз мінливості полягає у виявленні структур, які, ймовірно, зміняться. Аналіз мінливості має сенс тільки в термінах контексту, певного попереднім аналізом спільності. В архітектурному сенсі аналіз спільності дає архітектурі її довговічність, а аналіз мінливості сприяє досягненню зручності у використанні.

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

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

• Знайти те, що змінюється, і инкапсулировать це.

• Переважно використовувати композицію замість успадкування.

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

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

Тепер, коли ми проаналізували, як шаблон Bridge працює, варто подивитися на нього з більш концептуальної точки зору. Шаблон включає дві частини - абстрактну (зі своїми похідними класами) та реалізації. При проектуванні з використанням шаблону Bridge корисно завжди пам'ятати про ці двох частинах. Інтерфейс в частині реалізації слід розробляти з урахуванням особливостей різних похідних класів того абстрактного класу, який цей інтерфейс буде підтримувати. Зверніть увагу на те, що проектувальник не обов'язково повинен поміщати в ІНТЕРФОМ з реалізації всіх можливих похідних класів абстрактного класу (це ще одна можлива причина виникнення "Паралічу від аналізу"). Слід брати до уваги тільки ті похідні класи, які дійсно необхідно підтримувати. Не раз і не два автори цієї книги отримували підтвердження, що навіть невелике зусилля по збільшенню гнучкості в цій частині проекту істотно його покращує. Зауваження. У мові C + + реалізація шаблону Bridge повинна здійснюватися тільки за допомогою абстрактного класу, визначального відкритий інтерфейс. У мові Java можуть використовуватися як абстрактний клас, так і інтерфейс. Вибір залежить від того, чи дає перевагу розділення в реалізації спільних рис абстрактних класів.




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

• Знайдіть те, що змінюється, і Інкапсулює це.

• Віддавайте перевагу композиції, а не спадкоємства.

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

  1   2   3   4   5   6


База даних захищена авторським правом ©refs.in.ua 2016
звернутися до адміністрації

    Головна сторінка