Vіsіtor (відвідувач)

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

Організація каталогу

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

Таблиця "Простір паттернов проектировани":

Критерії класифікації шаблонів:

Ціль

Рівень

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

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

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

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

Визначення ступеня деталізації об'єкта

Розміри й число об'єктів можуть сильно варіюватися. З їх допомогою може бути представлено всі, починаючи з рівня апаратур і до закінчених додатків. Так, шаблон Фасад показує, як представити у вигляді об'єкта цілі підсистеми, а шаблон Пристосованець -як підтримати велику кількість об'єктів при високому ступені деталізації. Інші шаблони вказують шлях до розкладання об'єкта на менші підоб’єкти. Абстрактна фабрика і Будівельник описують об'єкти, єдиною метою яких є створення інших об'єктів, а Відвідувач і Команда - об'єкти, відповідальні за реалізацію запиту до іншого об'єкта або групи.

Специфікування інтерфейсів об'єкта

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

Програмування відповідно до інтерфейсу, а не з реалізацією

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

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

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

У маніпулювання об'єктами строго через інтерфейс абстрактного класу є дві переваги:

Механізми повторного використання

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

Спадкування і композиція

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

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

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

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

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

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

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

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

Це підводить нас до ще одного правила об’єктно-орієнтованого проектування: композиції спадкування класу.

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

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

Перелік кроків, для ефективного застосування шаблонів:

Змінювані паттернами елементи дизайну

Класифікація архітектур програмного забезпечення

Архітектури потоків даних.

Послідовні пакети.

Канали й фільтри.

Незалежні компоненти.

Паралельні взаємодіючі процеси.

Клієнт-серверні системи.

Системи, керовані подіями.

Віртуальні машини

Інтерпретатори

Системи, засновані на правилах

Репозиторні архітектури

Бази даних

Гіпертекстові системи

Дошки оголошень

Рівневі архітектури

Низхідне та висхідне проектування

Ведення розробки об'єкта послідовно від загальних рис до детальних називається спадним проектуванням. Його результатом будуть вимоги до окремих частин і вузлів.

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

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

Ітеративне й інкрементне проектування

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

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

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

Приклад ітеративного й инкрементного методу

Метод розробки динамічних систем (Dynamіc Systems Development Method, DSDM) - методика розробки програмного забезпечення, заснована на концепції швидкої розробки додатків (Rapіd Applіcatіon Development, RAD) - ітеративний й инкрементный підхід, що надає особливого значення тривалій участі в процесі користувача.

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

Принципи DSDM

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

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

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

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

Розробка - ітеративна й инкрементная. Вона ґрунтується на зворотному зв'язку з користувачем, щоб досягти оптимального з економічної точки зору рішення.

Будь-які зміни під час розробки - оборотні.

Вимоги встановлюються на високому рівні перш, ніж почнеться проект.

Тестування інтегроване в життєвий цикл розробки.

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

Етапи стадії життєвого циклу проекту під DSDM

Дослідження

Дослідження реалізованості

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

Дослідження економічної доцільності

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

Створення функціональної моделі

Визначення функціонального прототипу

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

Узгодження планів

Відбувається узгодження як й у які строки повинен бути розроблений функціонал прототипу.

Створення функціонального прототипу

Розробка функціонального прототипу, відповідно до планів і функціональній моделі.

Аналіз функціонального прототипу

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

Проектування й розробка

Визначення конструктивного прототипу

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

Узгодження планів

Відбувається узгодження як й у які строки повинні бути реалізовані поставлені вимоги.

Створення конструктивного прототипу

Створення системи (конструктивного прототипу), яку можна віддати користувачам для тестування.

Аналіз конструктивного прототипу

Перевірити справність спроектованої системи. На цьому подэтапе застосовується тестування й перегляд результатів. Створення користувальницької документації й протоколу випробування.

Реалізація

Затвердження системи пользоваетелем

Кінцеві користувачі затверджують протестированную систему для наступної реалізації й створення керівництва.

Навчання користувачів

Навчання майбутнього користувача роботі із системою. Результат подэтапа - контингент навчених користувачів.

Реалізація

Реалізація протестированной системи серед користувачів.

Аналіз ринку системи

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

Метапрограмування

Методологія повторного використання

За терміном "повторне використання" ховається досить складна методологія, що дозволяє здійснювати метасистемні переходи.

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

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

У технологіях програмування є безліч яскравих прикладів метасистемних переходів. Наприклад, процедурне програмування полягає в розбивці програми на процедури (функції, дії), при якому для опису нових, високорівневих процедур використаються наявні більш низькорівневі процедури.

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

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

Суть повторного використання

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

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

Генерація коду

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

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

Самомодифікуємий код

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

Одними із основних методів реалізації є:

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

Інтерпретація довільного коду, представленого у вигляді рядка