47186

Розробка методичних матеріалів для вивчення курсу ООП

Дипломная

Педагогика и дидактика

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

Украинкский

2013-11-24

1.36 MB

11 чел.

ЗМІСТ

стор.

СПИСОК СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ 3

ВСТУП  4

  1.  ОГЛЯД ІСНУЮЧИХ РІШЕНЬ
    1.  Огляд існуючих рішень у інтернет ресурсах 6
    2.  Огляд друкованих видань 10
    3.   Платформа Moodle 12
  2.  СТРУКТУРНІ ШАБЛОНИ ПРОЕКТУВАННЯ
    1.  Загальний опис 17
    2.  «Адаптер»  18
    3.   «Декоратор»  22
    4.   «Міст»  27
    5.   «Пристосуванець»  31
    6.   «Заступник»  37
    7.   «Фасад»  41
  3.  ОБГРУНТУВАННЯ ВИБОРУ ЗАСОБІВ РОЗРОБКИ
    1.   Платформа .NET  45
    2.   Мова C#  47
    3.   Платформа Joomla  49
  4.  ПРОГРАМНІ ЗАСОБИ ПІДТРИМКИ
    1.  Загальний опис  51
    2.  Будова сайту 52
    3.  Приклади роботи сайту 53

ВИСНОВКИ  55

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ  56

ДОДАТОК 1. Копії графічних матеріалів

ДОДАТОК 2. Лістинг прикладів

СПИСОК СКОРОЧЕНЬ ТА ПОЗНАЧЕНЬ

ASPActive Server Pages (активні серверні сторінки);

OOП – обєктно-орієнтоване програмування

ПЗ – програмне забезпечення

HTTPHyper Text Transfer Protocol (протокол передачі гіпертекстових документів);

SMTP – Simple Mail Transfer Protocol (простий протокол пересилання пошти);

XML – Extensible Markup Language (розширювана мова розмітки);

GoF – Gang of four (Колектив авторів книги «Design Patterns»)


В
СТУП

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

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

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

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

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

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

  1.  ОГЛЯД ІСНУЮЧИХ РІШЕНЬ

1.1 Огляд існуючих рішень у інтернет ресурсах

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

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

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

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

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

Популярним є сайт www.design-pattern.ru, автори якого взяли за основу статті з сайту Мартіна Фаулера (martinfowler.com), переклали та допрацювали, додавши  ілюстрацій та виправлень.

Особливістю даного сайту є те, що тут подана не традиційна класифікація шаблонів, яку запропонувала знаменита  «Банда чотирьох» (структурні, породжуючи та поведінкові), а класифікація описана у книзі Фаулера «Patterns of Enterprise Application Architecture» (Архітектура корпоративних програмних додатків), у якій шаблони надають рішення більш конкретних проблем проектування. Слід зазначити, що шаблони описані «Бандою чотирьох» є основою майже для всіх інших шаблонів проектування.

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

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

Книга «Архітектура корпоративних програмних додатків» («Шаблони корпоративних програмних додатків») складається з двох частин. Перша частина являє собою короткий (100 сторінок) підручник з архітектури корпоративних програм. Автор, відомий фахівець в області об'єктно-орієнтованого програмування, зауважив, що з розвитком технологій базові принципи проектування і вирішення загальних проблем залишаються незмінними  та у основній частині книги виділив більш ніж 40 найбільш вживаних підходів, які оформлені у вигляді типових рішень (шаблонах). Кожен шаблон описується у подробицях, включаючи те як він працює, коли використовується. Також додаються приклади коду на Java та C #, так як ці мови зрозуміли для всіх розробників ПЗ.

Також розглянемо досить об’ємну статтю написану Ольгою Дубіною для сайту www.citforum.ru. Дана робота представляє собою огляд декількох найбільш значних монографій, присвячених патернам проектування інформаційних систем. Ця робота охоплює усі основні шаблони.  Матеріал оформлений у вигляді структурованого довідника, в який включено паттерни проектування об'єктів інформаційних систем, архітектурні системні патерни і патерни інтеграції інформаційних систем. У довіднику наведено короткі описи патернів проектування. Описи паттернів структуровані таким чином, щоб забезпечити максимальну зручність в їх освоєнні і використанні. Для цієї мети виділені і систематично, на єдиних принципах описані три групи патернів проектування, обговорювані в порядку зростання "масштабу" розв'язуваних завдань. Всередині цих груп патернів проведена своя структуризація, яка спрощує пошук і розуміння призначення патернів проектування. Наприклад, усередині групи патернів проектування класів / об'єктів виділені патерни для організації класів / об'єктів в більші структури, патерни для розподілу обов'язків між класами / об'єктами і патерни для створення класів або об'єктів. Також поданий словник термінів, що значно полегшує розуміння матеріалу особливо для тих, хто вперше ознайомлюється з даною темою.

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

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

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

Першим оглянемо ресурс www.dofactory.com. На цьому сайті розглянуті основні шаблони (так звані шаблони «банди чотирьох»). Теоретичний опис є реферативним та складається з UML діаграми та визначення. Головною ж перевагою є приклади. Вони поділяються на структурні та приклади з реального світу, які є достатньо наочними та допомагають зрозуміти суть шаблону набагато краще ніж це роблять абстрактні структурні приклади. Код  написаний на мові С#, яку розуміють всі сучасні розробники ПЗ.

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

Наступним розглянемо сайт sourcemaking.com. Тут можна знайти найповніший опис основних типів шаблонів. Приклади написані на всіх сучасних об’єктно - орієнтованих мовах програмування. Серед них є як абстрактні так і досить наглядні приклади використання патернів. Цей ресурс найповніше розкриває тему шаблонів проектування.

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

1.2 Огляд друкованих виданнів

Перейдемо до друкованих виданнів.  Спершу  зупинимось на книзі Джона Вліссідеса «Применение шаблонов проектирования. Дополнительные штрихи». Дана книга призначена для розробників програмного забезпечення, що використовують у своїй роботі шаблони проектування. У цій книзі розглядаються важливі аспекти застосування шаблонів проектування, які не були належним чином висвітлені в знаменитій книзі "Design Patterns" (Джон Вліссідес є одним з її співавторів). Тут представлені варіації вже відомих шаблонів, а також нові шаблони. Крім того автор виклав своє розуміння процесу розробки шаблонів,  і запропонував ряд рекомендацій починаючим розроблювачам, виділивши 7 неформальних, але вельми дієвих правила, які привели до створення 23-х шаблонів, описаних у книзі GoF Design Patterns. Корисно знати, як саме відбувається розробка шаблонів, оскільки це дозволяє співвіднести шаблони з реальністю, де діють прагматичні правила повсякденного життя.

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

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

Наступною розглянемо книгу Алана Шаллоуея та Джеймса Р. Тротта «Шаблоны проектирования. Новый подход к объектно-ориентированному анализу и проектированию». Ця книга дає точне уявлення про десять найбільш важливих шаблонів проектування, які ніколи не використовуються самостійно, а тільки у взаємодії один з одним, що й гарантує надійність створюваних додатків. Отриманих знань буде цілком достатньо для подальшого вивчення літератури по шаблонах проектування, і навіть для створення своїх власних шаблонів. Книга призначена як для професійних розробників ПЗ, так і для студентів, які вивчають основи ООП.

Останньою розглянемо класичну книгу, яка стала причиною зростання популярності шаблонів проектування - «Приемы объектно-ориентированного проектирования. Паттерны проектирования». Її написала так звана «банда чотирьох» у яку входили Эріх Гамма, Річард Хелм, Ральф Джонсон, Джон Вліссідес. У цій  книзі  описуються прості й витончені рішення типових завдань, що виникають в об'єктно-орієнтованому проектуванні. Паттерни з'явилися тому, що багато розроблювачів шукали шляхи підвищення гнучкості й ступені повторного використання своїх програм. Знайдені рішення втілені в короткій і легко застосовної на практиці формі. Автори викладають принципи використання патернів проектування і приводять їх каталог. Таким чином, книга одночасно вирішує два завдання. По-перше, тут демонструється роль паттернів у створенні архітектури складних систем. По-друге, застосовуючи патерни, що містяться в довіднику, проектувальник зможе з легкістю розробляти власні додатки.

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

1.3 Платформа Moodle

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

 Open Source СДО Moodle широко відома в світі, використовується більш ніж у 100 країнах.

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

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

Широкі можливості для комунікації - одна з найсильніших сторін Moodle. Система підтримує обмін файлами будь-яких форматів - як між викладачем і студентом, так і між самими студентами. Сервіс розсилки дозволяє оперативно інформувати всіх учасників курсу або окремі групи про поточні події. Форум дає можливість організувати навчальний обговорення проблем, при цьому обговорення можна проводити по групах. До повідомленнями у форумі можна прикріплювати файли будь-яких форматів. Є функція оцінки повідомлень - як викладачами, так і студентами. Чат дозволяє організувати навчальний обговорення проблем в режимі реального часу. Сервіси «Обмін повідомленнями», «Коментар» призначені для індивідуальної комунікації викладача та студента: рецензування робіт, обговорення індивідуальних навчальних проблем. Сервіс «Учительський форум» дає педагогам можливість обговорювати професійні проблеми.

Важливою особливістю Moodle є те, що система створює і зберігає портфоліо кожного учня: всі здані ним роботи, всі оцінки і коментарі викладача до робіт, всі повідомлення у форумі.

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

При підготовці та проведенні занять в системі Moodle викладач використовує набір елементів курсу, до якого входять:

    * Глосарій

    * Ресурс

    * Завдання

    * Форум

    * Wiki

    * Урок

    * Тест і ін

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

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

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

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

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

При додаванні нового форуму викладач має можливість вибрати його тип із декількох: звичайний форум з обговоренням однієї теми, доступний для всіх загальний форум або форум з однією лінією обговорення для кожного користувача.
Форум Moodle підтримує структуру дерева. Ця можливість зручна як у випадку розгалуженого обговорення проблем, так, наприклад, і при колективному створенні текстів за принципом «Додати фрагмент» - як послідовно, так і до будь-яких фрагментів тексту, написаних іншими студентами.
Повідомлення з форуму можуть, за бажанням викладачеві, автоматично розсилатися учням по електронній пошті через 30 хвилин після їх додавання (протягом цього часу повідомлення можна відредагувати або видалити).
Всі повідомлення студента у форумі зберігаються в портфоліо.

Moodle підтримує дуже корисну функцію коллективного редагування текстів (елемент курсу «Wiki»).

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

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

Елемент курсу «Тести» дозволяє викладачеві розробляти тести з використанням питань різних типів:

    * Питання в закритій формі (множинний вибір)

    * Так / Ні

    * Коротка відповідь

    * Числовий

    * Відповідність

    * Випадкове питання

    * Вкладена відповідь та ін.

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

Так як дана система реалізує філософію так званої «педагогіки соціального конструктивізму» та орієнтована насамперед на організацію взаємодії між викладачем та учнями, тому на мою думку більш доцільним для використання у даному дипломному проекті є звичайний web - сайт створений та керований за допомогою програми Joomla!.

 

2.СТРУКТУРНІ ШАБЛОНИ ПРОЕКТУВАННЯ

2.1 Загальний опис

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

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

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

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

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

2.2) «Адаптер» (Adapter) - структурний шаблон проектування, призначений для організації використання функцій об'єкта, недоступного для модифікації, через спеціально створений інтерфейс.

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

Способи реалізації шаблону адаптер:

1) Адаптер класу реалізується через множинне спадкування. Цим досягається адаптація одного інтерфейсу до іншого:

Рис.2.1 Структура шаблону проектування «Адаптер класу»

2) Адаптер об'єкта застосовує композицію об'єктів:

Рис.2.2 Структура шаблону проектування «Адаптер обєкта»

Учасники схеми шаблону Адаптер (Adapter):

1. Ціль - цільовий інтерфейс.

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

2.Клієнт.

Взаємодіє з об'єктами, що задовольняють інтерфейсу Ціль.

3. Адаптований інтерфейс.

Визначає існуючий інтерфейс класу (бібліотеки), який потребує адаптації.

4.Адаптер.

Клас, що готує інтерфейс Adaptee до інтерфейсу Target

Застосовується у випадках:

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

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

Плюси:

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

- перехід на використання інших зовнішніх класів не вимагає переділки самої системи, достатньо реалізувати один клас Adapter.

Споріднені шаблони: Фасад, Декоратор

Простий приклад використання шаблону адаптер:

using System;

 class MainApp

 {

   static void Main()

   {

     // Створюємо екземпляр адаптеру та робимо виклик

     Target target = new Adapter();

     target.Request();

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

     Console.Read();

   }

 }

 // Клас ціль

 class Target

 {

   public virtual void Request()

   {

     Console.WriteLine("Called Target Request()");

   }

 }

 // Клас адаптер 

 class Adapter : Target

 {

   private Adaptee adaptee = new Adaptee();

   public override void Request()

   {

     // Possibly do some other work

     // and then call SpecificRequest

     adaptee.SpecificRequest();

   }

 }

 // Клас, що адаптується

 class Adaptee

 {

   public void SpecificRequest()

   {

     Console.WriteLine("Called SpecificRequest()");

   }

 }

Приклад з реального світу:

Маємо інтерфейс Phone, у якому об'явлений метод Make Call (Зробити Виклик). Зробити можливим використання відео камери (клас VideoCamera) при відео виклику.  

Схема класів:

Рис.2.3 Структура класів програми-прикладу

2.2 «Декоратор» (Decorator) — структурний шаблон проектування, призначений для динамічного підключення додаткового поведінки до об'єкта. Також фігурує під ім'ям Wrapper.

Рис.2.4 Структура шаблону проектування «Декоратор»

Учасники схеми шаблону Декоратор (Decorator)

1. Компонент.

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

2. Конкретний компонент.

Визначає об'єкт, на який покладаються додаткові обов'язки, вішаються додаткові можливості.

3. Декоратор.

Зберігає посилання на об'єкт Component і успадкує реалізацію його інтерфейсу по-умалчанію

4. Конкретний декоратор.

Покладає додаткові обов'язки на компонент.

Шаблон декоратор застосовується:

1. Для динамічного і прозорого для клієнтів додавання нових можливостей, «фіч» об'єктах;

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

3. Коли розширення шляхом породження підкласів з якихось причин незручно або неможливо. Іноді доводиться реалізовувати багато незалежних розширень, так що породження підкласів для підтримки всіх можливих комбінацій призведе до комбінаторному зростання їх числа («Комбінаторний вибух»). В інших випадках визначення класу може бути приховано або чому-небудь ще недоступно, так що породити від нього підклас не можна.

Плюси:

1) Немає необхідності створювати підкласів для розширення функціональності об'єкта;

2) Можливість динамічно підключати нову функціональність до або після основної функціональності об'єкту.

3) Більша гнучкість, ніж у статичного успадкування.

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

4) Дозволяє уникнути перевантажених функціями класів на верхніх рівнях ієрархії.

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

Мінуси:

1) Декоратор і його компонент не ідентичні.

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

2) Безліч дрібних об'єктів.

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

Споріднені шаблони: Фасад, Адаптер.

Простий приклад використання шаблону:

using System;

 class MainApp

 {

   static void Main()

   {

     // Створюємо конкретний компонент та 2 декоратори 

     ConcreteComponent c = new ConcreteComponent();

     ConcreteDecoratorA d1 = new ConcreteDecoratorA();

     ConcreteDecoratorB d2 = new ConcreteDecoratorB();

     // Пов’язуємо декоратори  

     d1.SetComponent(c);

     d2.SetComponent(d1);

     d2.Operation();

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

     Console.Read();

   }

 }

 // Клас компонент 

 abstract class Component

 {

   public abstract void Operation();

 }

 // Клас конкретний компонент 

 class ConcreteComponent : Component

 {

   public override void Operation()

   {

     Console.WriteLine("ConcreteComponent.Operation()");

   }

 }

 // Клас декоратор 

 abstract class Decorator : Component

 {

   protected Component component;

   public void SetComponent(Component component)

   {

     this.component = component;

   }

   public override void Operation()

   {

     if (component != null)

     {

       component.Operation();

     }

   }

 }  

 // Конкретний декоратор А

 class ConcreteDecoratorA : Decorator

 {

   private string addedState;

   public override void Operation()

   {

     base.Operation();

     addedState = "New State";

     Console.WriteLine("ConcreteDecoratorA.Operation()");

   }

 }

 // Конкретний декоратор Б 

 class ConcreteDecoratorB : Decorator

 {

   public override void Operation()

   {

     base.Operation();

     AddedBehavior();

     Console.WriteLine("ConcreteDecoratorB.Operation()");

   }

   void AddedBehavior()

   {

   }

 }

Більш складний приклад:

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

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

Схема класів:

Рис.2.5 Структура класів програми-прикладу

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

Шаблон міст застосовується:

1. Потрібно уникнути постійної прив'язки абстракції до реалізації.

2. Коли конкретну реалізацію необхідно вибирати під час виконання програми

3. І абстракції, і реалізації повинні розширюватися новими підкласами. У такому випадку патерн міст дозволяє комбінувати різні абстракції та реалізації та змінювати їх незалежно.

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

5. Кількість класів починає швидко рости, як ми бачили на першій діаграмі з прикладу. Це ознака того, що ієрархію слід розділити на 2 частини.

6. Ви хочете розділити одну й ту ж реалізацію між кількома об'єктами, і цей факт необхідно приховати від клієнта

Плюси:

1. Відділення реалізації від інтерфейсу.

2. Підвищення ступеня розширюваності.

3. Приховування деталей реалізації від клієнтів.

Споріднені шаблони: адаптер, абстрактна фабрика

Рис.2.6 Структура шаблону проектування «Міст»

Учасники схеми шаблону Міст (Bridge)

1. Абстракція (Abstraction).

Визначає інтерфейс абстракції і агрегує (зберігає посилання) на об'єкт типу Implement.

2. Уточнена абстракція (RefinedAbstraction)

Більш специфічний підклас основний абстракції, розширює інтерфейс, визначений абстракцією Abstraction.

3. Виконавець (Implementor).

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

4. Конкретний виконавець(ConcreteImplementor) - один з конкретних (платформо-залежних) виконавців.

Містить конкретну реалізацію інтерфейсу класу Implementor, тобто по-своєму реалізує примітиви, визначені в Implementor-е.

Простий приклад використання шаблону:

using System;

 class MainApp

 {

   static void Main()

   {

     Abstraction ab = new RefinedAbstraction();

     // Встановлюємо та викликаємо виконавця

     ab.Implementor = new ConcreteImplementorA();

     ab.Operation();

     //Змінюємо виконавця

     ab.Implementor = new ConcreteImplementorB();

     ab.Operation();

     // Очикування користувача 

     Console.Read();

   }

 }

 // Клас абстракція 

 class Abstraction

 {

   protected Implementor implementor;

   // Property

   public Implementor Implementor

   {

     set{ implementor = value; }

   }

   public virtual void Operation()

   {

     implementor.Operation();

   }

 }

 // Клас виконавець

 abstract class Implementor

 {

   public abstract void Operation();

 }

 // Клас уточнена абстакція

 class RefinedAbstraction : Abstraction

 {

   public override void Operation()

   {

     implementor.Operation();

   }

 }

 // Конкретний виконавець А 

 class ConcreteImplementorA : Implementor

 {

   public override void Operation()

   {

     Console.WriteLine("ConcreteImplementorA Operation");

   }

 }

 // Конкретний виконавець Б 

 class ConcreteImplementorB : Implementor

 {

   public override void Operation()

   {

     Console.WriteLine("ConcreteImplementorB Operation");

   }

 }

Більш складний приклад:

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

Блок-схема класів:

Рис.2.7 Структура класів програми-прикладу

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

Патерн пристосуванець застосовується, коли виконані всі перелічені нижче умови:

1. У додатку використовується велика кількість об'єктів і через це накладні витрати на зберігання високі.

2. Більшу частину статків об'єктів можна винести назовні (у відповідальність клієнтів, які створюють і використовують ці об'єкти).

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

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

Рис.2.8 Структура шаблону проектування «Пристосуванець»

На наступній діаграмі показано, як пристосуванці розділяються:

Рис.2.9 Розділення пристосуванців

Учасники патерну пристосуванець (Flyweight):

1. Пристосуванець(Flyweight)

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

2. Конкретний пристосуванець (ConcreteFlyweight)

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

3. Неподіляємий конкретний пристосуванець(UnsharedConcreteFlyweight )

Не всі підкласи Flyweight обов'язково повинні бути розподільними. Інтерфейс Flyweight допускає розділення, але не нав'язує його. Часто у об'єктів UnsharedConcreteFlyweight на деякій рівні структури пристосуванця є нащадки у вигляді об'єктів класу ConcreteFlyweight, як, наприклад, у об'єктів класів Row і Column.

4. Фабрика пристосуванців( FlyweightFactory)

Створює об'єкти-пристосуванці і керує ними.

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

5. Клієнт( Client )

Зберігає посилання на одного або кількох пристосуванців.

Обчислює або зберігає зовнішній стан пристосуванців.

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

Економія пам'яті виникає з ряду причин:

Плюси використання:

  1.  Зменшення загальної кількості примірників.
  2.  Скорочення обсягу пам'яті, необхідного для зберігання внутрішнього стану.
  3.  Обчислення, а не зберігання зовнішнього стану

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

Споріднені патерни: компонувальник

Простий приклад використання шаблону:

using System;

using System.Collections;

 class MainApp

 {

   static void Main()

   {

     // Довільний зовнішній стан 

     int extrinsicstate = 22;

 

     FlyweightFactory f = new FlyweightFactory();

     //Працюємо з різними конкретними пристосуванцями

     Flyweight fx = f.GetFlyweight("X");

     fx.Operation(--extrinsicstate);

     Flyweight fy = f.GetFlyweight("Y");

     fy.Operation(--extrinsicstate);

     Flyweight fz = f.GetFlyweight("Z");

     fz.Operation(--extrinsicstate);

     UnsharedConcreteFlyweight uf = new 

       UnsharedConcreteFlyweight();

     uf.Operation(--extrinsicstate);

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

     Console.Read();

   }

 }

 // Фабрика пристосуванців 

 class FlyweightFactory

 {

   private Hashtable flyweights = new Hashtable();

   // Конструктор

   public FlyweightFactory()

   {

     flyweights.Add("X", new ConcreteFlyweight());    

     flyweights.Add("Y", new ConcreteFlyweight());

     flyweights.Add("Z", new ConcreteFlyweight());

   }

   public Flyweight GetFlyweight(string key)

   {

     return((Flyweight)flyweights[key]);

   }

 }

 // Клас пристосуванець

 abstract class Flyweight

 {

   public abstract void Operation(int extrinsicstate);

 }

 // Клас конкретний пристосуванець 

 class ConcreteFlyweight : Flyweight

 {

   public override void Operation(int extrinsicstate)

   {

     Console.WriteLine("ConcreteFlyweight: " + extrinsicstate);

   }

 }

 // Нерозподілений конкретний пристосуванець 

 class UnsharedConcreteFlyweight : Flyweight

 {

   public override void Operation(int extrinsicstate)

   {

     Console.WriteLine("UnsharedConcreteFlyweight: " +

       extrinsicstate);

   }

 }

Більш складний приклад:

На підприємстві працює велика кількість працівників, різних спеціальностей.

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

Блок-схема класів:

Рис.2.10 Структура класів у програмі-прикладі

2.5) Proxy (Заступник) - Шаблон проектування. Надає об'єкт, який контролює доступ до іншого об'єкта через перехоплення всіх викликів.

Рис.2.11 Структура шаблону проектування «Заступник»

Ось як може виглядати діаграма об'єктів для структури з заступником під час виконання:

Рис.2.12 Діаграма об’єкті для структури з заступником під чс виконання

Учасники схеми шаблону Заступник (Proxy)

1. Проксі (Proxy) - заступник,

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

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

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

Виконує інші обов'язки - залежить від виду заступника.

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

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

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

2. Суб'єкт (Subject )

Визначає загальний для RealSubject і Proxy інтерфейс, так що клас Proxy можна використовувати скрізь, де очікується RealSubject

3. Реальний суб'єкт (RealSubject)

Визначає реальний об'єкт, представлений заступником.

Шаблон Проксі використовується:

1) Коли потрібно віддалений функціонал.

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

2) Коли потрібен віртуальний заступник.

Віртуальний заступник створює «важк» об'єкти за вимогою. 3) Коли потрібно контролювати доступ до вихідного об'єкту.

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

4) Коли потрібно виконувати додаткові дії при доступі до об'єкта.

«Розумне посилання» - це заміна звичайного покажчика. Вона дозволяє виконати додаткові дії при доступі до об'єкта. До типових застосуванням такого посилання можна віднести:

- Підрахунок числа посилань на реальний об'єкт, з тим, щоб займану ним пам'ять можна було звільнити автоматично, коли не залишиться жодного посилання (такі посилання називають ще «розумними» покажчиками);

- Завантаження об'єкта в пам'ять при першому зверненні до нього;

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

Плюси використання шаблону:

- віддалений заступник;

- віртуальний заступник може виконувати оптимізацію;

- захищає заступник;

- "розумна" посилання;

Мінуси:

- різке збільшення часу відгуку.

Споріднені шаблони: Декоратор

Простий приклад використання шаблону:

using System;

 

 class MainApp

 {

   static void Main()

   {

     // Створити заступника та зробити запит

     Proxy proxy = new Proxy();

     proxy.Request();

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

     Console.Read();

   }

 }

 // Клас суб’єкт 

 abstract class Subject

 {

   public abstract void Request();    

 }

 // Клас реальний суб’єкт

 class RealSubject : Subject

 {

   public override void Request()

   {

     Console.WriteLine("Called RealSubject.Request()");

   }

 }

 // Клас заступник

 class Proxy : Subject

 {

   RealSubject realSubject;

   public override void Request()

   {

     // Use 'lazy initialization'

     if (realSubject == null)

     {

       realSubject = new RealSubject();

     }

     realSubject.Request();

   }  

 }

Більш складний приклад:

Дано клас, який інкапсулює масив чисел та надає методи обробки та читання даного масиву. Реалізувати політику безпеки, яка має 3 рівня доступу:

повний доступ, частковий доступ(тільки читання), заборона доступу.

Блок-схема класів:

Рис.2.13 Структура класів у програмі-прикладі

3.6) «Фасад» (Facade) - Шаблон проектування, що дозволяє приховати складність системи шляхом зведення всіх можливих зовнішніх викликів до одного об'єкта, яка делегує їх відповідним об'єктів системи.

Рис.2.14 Структура шаблону проектування «Фасад»

Учасники схеми шаблону Фасад (Facade)

1. Фасад (Facade)

Обізнаний про те, яким класам підсистеми адресувати запит.

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

2. Класи підсистеми

Реалізують функціональність підсистеми.

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

Нічого не «знають» про існування самого фасаду, тобто не зберігають посилань на нього.

Шаблон фасад застосовується в таких випадках:

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

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

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

Плюси:

1. Ізолює клієнтів від компонентів підсистеми.

2. Дозволяє послабити зв'язаність між підсистемою та її клієнтами.

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

Споріднені шаблони : Адаптер

Простий приклад використання шаблону:

using System;

 class MainApp

 {

   public static void Main()

   {

     Facade facade = new Facade();

     facade.MethodA();

     facade.MethodB();

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

     Console.Read();

   }

 }

 // Підсистема Клас 1

 class SubSystemOne

 {

   public void MethodOne()

   {

     Console.WriteLine(" SubSystemOne Method");

   }

 }

 // Підсистема Клас 2

 class SubSystemTwo

 {

   public void MethodTwo()

   {

     Console.WriteLine(" SubSystemTwo Method");

   }

 }

 // Підсистема Клас 3

 class SubSystemThree

 {

   public void MethodThree()

   {

     Console.WriteLine(" SubSystemThree Method");

   }

 }

 // Підсистема Клас 4 

 class SubSystemFour

 {

   public void MethodFour()

   {

     Console.WriteLine(" SubSystemFour Method");

   }

 }

 // Клас Фасад

 class Facade

 {

   SubSystemOne one;

   SubSystemTwo two;

   SubSystemThree three;

   SubSystemFour four;

   public Facade()

   {

     one = new SubSystemOne();

     two = new SubSystemTwo();

     three = new SubSystemThree();

     four = new SubSystemFour();

   }

   public void MethodA()

   {

     Console.WriteLine("\nMethodA() ---- ");

     one.MethodOne();

     two.MethodTwo();

     four.MethodFour();

   }

   public void MethodB()

   {

     Console.WriteLine("\nMethodB() ---- ");

     two.MethodTwo();

     three.MethodThree();

   }

 }

Більш складний приклад:

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

Блок-схема класів:

Рис.2.15 Структура класів у прикладі

3. ОБГРУНТУВАННЯ ВИБОРУ ЗАСОБІВ РОЗРОБКИ

3.1. Платформа .NET

Microsoft .NET— програмна технологія, запропонована фірмою Microsoft як платформа для створення як звичайних програм, так і веб-програм. Багато в чому є продовженням ідей та принципів, покладених в технологію Java.

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

Кожна бібліотека (збірка) в .NET має свідчення про свою версію, що дозволяє усунути можливі конфлікти між різними версіями збірок.

.NET — кросплатформена технологія, на даний момент існує реалізація для платформи Microsoft Windows, FreeBSD (від Microsoft) і варіант технології для ОС Linux в проекті Mono (в рамках угоди між Microsoft з Novell), DotGNU [1].

Захист авторських прав відноситься до створення середовищ виконання (CLR — Common Language Runtime) для програм .NET. Компілятори для .NET випускаються багатьма фірмами для різних мов вільно.

.NET поділяється на дві основні частини — середовище виконання (по суті віртуальна машина) та інструментарій розробки.

Середовища розробки .NET-програм:
Visual Studio .NET (C++, C#, J#), SharpDevelop, Borland Developer Studio (Delphi, C#) і т. д. Середовище Eclipse має додаток для розробки .NET-програм. Застосовні програми також можна розроблювати в текстовому редакторі та використовувати консольний компілятор.

Також як і технологія Java, середовище розробки .NET створює байт-код, призначений для виконання віртуальною машиною. Вхідна мова цієї машини в .NET називається CIL (Common Intermediate Language), також відома як MSIL (Microsoft Intermediate Language), або просто IL. Застосування байт-кода дозволяє отримати кроссплатформеність на рівні скомпільованого проекту (в термінах .NET: збірка), а не на рівні початкового тексту, як, наприклад, в С. Перед запуском збірки в середовищі виконання (CLR) байт-код перетворюється вбудованим в середовище JIT-компілятором (just in time, компіляція на льоту) в машинні коди цільового процесора.

Слід зазначити, що один з перших JIT-компіляторів для Java був також розроблений фірмою Microsoft (на даний момент в Java використовується більш досконала багаторівнева компіляція — Sun HotSpot). Сучасна технологія динамічної компіляції дозволяє досягнути аналогічного рівня швидкодії з традиційними «статичними» компіляторами (наприклад, С++) і питання швидкодії часто залежить від якості того чи іншого компілятора.

3.2 Мова програмування С#

Мова C # досить успішно використовується в проектах багатьох типів, у тому числі для розробки Web-додатків, баз даних, GUI і т. д.

Як і решта .NET-орієнтованих мов, C # компілюється в MSIL (Microsoft intermediate language), який виконується в загальномовного виконуючого середовища (CLR). CLR можна спрощено представити як комбінацію оптимізуючий JIT компілятора і збирача сміття. C # надає і використовує велику частину функціональності CLR, тому важливо детальніше розглянути, що відбувається в виконуючою середовищі.

Одна з ключових вимог вчених - портуємість коду (можливість його переносу між платформами).

CLR дозволяє писати програми та бібліотеки на декількох мовах, модульна в MSIL. Потім MSIL може бути запущений в будь-якій архітектурі, яка підтримує його. Тепер вчені можуть писати свої математичні бібліотеки на FORTRAN, задіяти їх в C + + і використовувати C # і ASP.NET для публікації результатів в Інтернеті.

CLR - на відміну від Java Virtual Machine (JVM) - це універсальне середовище і цільова платформа для багатьох мов програмування. Більш того, CLR забезпечує взаємодію на рівні даних, а не тільки на рівні додатків, і дозволяє розділяти ресурси між мовами.

З точки зору реалізації, автоматичне керування пам'яттю, напевно, найкращий подарунок CLR розробникам. Пам'ять виділяється відносно швидко (покажчик купи просто переміщається на наступний вільний слот) - у порівнянні з більш повільним і марнотратним переглядом списку вільних сторінок у викликах malloc або new в C / C + +. Більш того, у період виконання пам'ять управляється автоматично, звільняючи і ущільнюючи незадіяний простір.

Програмістам більше не треба ганятися за вказівниками, передчасно звільняючи блоки пам'яті або не звільняючи їх зовсім (хоча такі мови, як C # та Visual C + +, як і раніше дають таку можливість).

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

3.3 Платформа Joomla

CMS Joomla! включає в себе різні інструменти для виготовлення веб-сайту. Важливою особливістю системи є мінімальний набір інструментів при початковій установці, який доповнюється в міру необхідності. Це знижує захаращення адміністративної панелі непотрібними елементами, а також знижує навантаження на сервер і економить місце на хостингу.
Joomla! дозволяє відображати інтерфейс фронтальної та адміністративної частини будь-якою мовою. Каталог розширень містить безліч мовних пакетів [4], які встановлюються штатними засобами адміністрування. Доступні пакети російського, українського та ще деяких мов країн СНД.
Основні можливості :
    * Функціональність можна розширювати за допомогою додаткових модулів (розширень, плагінів).
    * Модуль безпеки для багаторівневої аутентифікації користувачів та адміністраторів.
    * Система шаблонів дозволяє легко змінювати зовнішній вигляд сайту.
    * Настроювані схеми розташування модулів, включаючи лівий, правий і центральний блоки меню.
    * До переваг системи можна віднести те, що всі модулі, компоненти, плагіни, шаблони можна написати самому, розмістити їх в структурованому каталозі розширень або відредагувати існуюче розширення на свій розсуд.
Можливості адміністрування:
    * Для кожної динамічної сторінки можна створити свій опис і ключові слова в цілях підвищення рейтингу в пошукових системах;
    * Початок і закінчення публікації будь-яких матеріалів можна запрограмувати за календарем;
    * Можливість обмежити доступ до певних розділів сайту тільки для зареєстрованих користувачів;
    * Настроювані схеми розміщення елементів по областях шаблону
    * Різні модулі (останні новини, лічильник відвідувань, докладна статистика відвідувань, гостьова книга, форум та інші);
    * Можливість створення не однієї, а декількох форм зворотного зв'язку для кожного контакту;
    * Модуль прийому від віддалених авторів новин, статей і посилань;
    * Ієрархія об'єктів;
    * Менеджер розсилки новин. Підтримка більш ніж 360 служб розсилки новин по всьому світу;
    * Вбудований візуальний редактор TinyMCE;
    * Близько 5000 готових модулів і компонентів

  1.  ПРОГРАМНІ ЗАСОБИ ПІДТРИМКИ

4.1 Загальний опис

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

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

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

З допомогою джумла дуже легко можна запустити опитування на сайті. Сайти на джумлі мають чітку та зрозумілу структуру. Джумла є Open Source платформою тому користувач можу підлаштувати або переписати будь-який модуль під себе.

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

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

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

4.2 Будова сайту

  •  administrator Директорія традиційно відповідає за back-end, тобто за адмінку сайту. У ній є також важливі піддиректорії:
  •  components сюди зберігається вся back-end частина компонентів, тобто та їх частина що призначена для роботи адміністратора.
  •  includes тут зберігаються файли реалізують Application Layer у додатку.
  •  language в цій папці зберігаються локалізації back-end'а
  •  templates директорія з шаблонами back-end'а
  •  modules папка з адміністраторськими модулями, такими як toolbar, або панель швидкого доступу.
  •  components в цій директорії зберігаються файли всіх встановлених в системі компонентів. Кожен компонент набір файлів приписаний API і вибраною моделлю.
    •  images папка зображень joomla, має важливу підпапку stories в яку зберігаються призначені для користувача зображення.
    •  includes - папка з файлами реалізовують Application Layer, проте безліч файлів в цій директорії залишені для сумісності зі старою версією CMS
    •  language це лише локалізації front-end'а
    •  libraries вміст цієї директорії реалізує Framework Layer CMS, в ній зберігається як сам фреймворк joomla, так і сторонні бібліотеки необхідні для роботи.
    •  modules - це модулі front-end'а
    •  plugins в попередній версії CMS, вони називалися Мамботи (mambots), з точки зору проектування, плагіни - це обробники подій, вони викликаються компонентами в певний час генерації контента, наприклад перед його розміщенням. templates - шаблони, шаблони joomla дуже сильні у своїй реалізації. Особливо це стало зручно саме в новій версії.
    •  xmlrpc - в цій папці зібрані файли реалізують доступ до сайту з протоколу XML-RPC

4.3 Приклади роботи сайту

Рис. 5.5 Демонстрація інтерфейсу користувача та меню сайту

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

Кожен пункт меню – це окремий вид шаблонів: породжуючі,  структурні та поведінкові.

Також кожен пункт має підпункти – це структури, об’єкти та класі які відносяться до даного типу шаблонів.

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

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

Рис. 5.6 Демонстрація модуля коментування

Окремої уваги заслуговує додатковій модуль, який було інтегровано до Джумли. Це модуль коментування статтей. Коментарі дозволяють підтримувати контакт з безпосереднім користувачем сайту.

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

ВИСНОВОК

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

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

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

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

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

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

 

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1.     Павловская Т. А. С#. Программирование на языке высокого уровня. Учебник для вузов. —СПб.: Питер, 2009. — 432 с: ил.

2.     Мэтью Мак-Дональд, Марио Шпушта  Microsoft ASP.NET 3.5 с примерами на C# 2008 для профессионалов.: Питер, 2007. - 366 с.

4.     A. Troelsen Pro C# 2008 and the .NET 3.5 Framework , Fourth Edition,  ISBN10: 1-59059-884-9  ISBN13: 978-1-59059-884-9, Apress, 2007. – 1370 pp.

5.     J. Bishop C# 3.0 Design Patterns ISBN 10: 0-596-52773-X, ISBN 13: 978-0-596-52773-0, O’Reilly, 2008. – 290pp.

6. http://sourcemaking.com/design_patterns/

7. http://www.dofactory.com/Patterns/

8. http://ru.wikipedia.org/wiki/

9. Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес Приемы объектно-ориентированного проектирования. Паттерны проектирования. — СПб: «Питер», 2007. — С. 366. — ISBN 978-5-469-01136-1


 

А также другие работы, которые могут Вас заинтересовать

72101. Характеристика взаимоотношений царской администрации с народами Сибири и Дальнего Востока 19.23 KB
  На территории Сибири и Дальнего Востока проживало огромное количество народов с разными уровнями развития и которые вели разный образ жизни оседлый живущие в городах или селениях кочевой кочующие земледельцы и бродячие свободно переходящие из губернии в губернию...
72106. Характеристика французского книжного рынка 20.66 KB
  Если в эпоху Дидро книгоиздатель выполнял все операции связанные с изготовлением и распространением книги то сегодня подготовка к изданию полиграфическое исполнение сбыт распространение и продажа разграничены. Согласно этому закону нельзя превышать отпускную...
72108. Современное состояние книжного дела в России 21.69 KB
  Правовой основой становления новой издательской системы стали важнейшие положения Закона Российской Федерации О средствах массовой информации принятого парламентом России в декабре 1991 г. Наконец формированию новой издательской системы России в значительной степени способствовала...