8.3. Стрічки (основні операції та функції; переваги порівняно із c - стрічками).

Шаблони

Для того, аби зрозуміти усю потужність методології ТОП звернемо увагу на кращі досягнення багаторічних досліджень у напрямку стандартизації та типізації рішень для створення ефективного програмного забезпечення. Тут відзначимо два ключових напрямки: стандартна бібліотека шаблонів (STL - Standard Template Library) та шаблони проектування (Design Patterns).

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

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

забезпечення є доволі багато, але власне під терміном "Шаблони проектування" (design patterns), переважно, мають на увазі 23 шаблони, розроблені групою відомих програмістів (теоретиків та основоположників сучасного ТОП), відомою як GoF - Gang of Four ("банда чотирьох") - Ерік Гамма (Erich Gamma), Річард Хелм (Richard Helm), Ральф Джонсон (Ralph Johnson) та Джон Вліссідс (John Vlissides). Навідміну від "тактичних" досягнень, втілених у STL, досягнення втілені у шаблонах проектування можна назвати "стратегічними". Зважаючи на великі обсяги теоретичного і прикладного матеріалу, необхідні для знайомства з шаблонами проектування, далі зупинимося лише на базовій класифікації і призначенні цих шаблонів.

Шаблони класів

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

template <опис параметрів шаблону>

class НазваКласу

{

/* /* опис класу */

};

Використаємо наведень нами раніше приклад, зокрема, клас "Товар".

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

##ifndef _tovar_h_

##define _tovar_h_

##include<string>

##include<iostream>22

using namespace std;

template <class Currency> class Tovar

{

static Currency sum;

Currency price;

string units;

public:

static Currency GetSum(void);

bool Sell(void);

Tovar();

Tovar(Currency);

Tovar(Currency, const string&);

friend ostream& operator<< <Currency>(ostream&, Tovar<Currency>&);

};

template <class Currency> Currency Tovar<Currency>::sum = 0;

template <class Currency> Currency Tovar<Currency>::GetSum(void)

{

return sum;

}

template <class Currency> bool Tovar<Currency>::Sell(void)

{

if(price>0)

{

sum+=price;

price = 0;

return true;

}

else return false;

}

template <class Currency> Tovar<Currency>::Tovar()

{

price = 1;

units = "piece";

}

template <class Currency> Tovar<Currency>::Tovar(Currency p)

{

price = (p>0)?p :0;

units = "piece";

}

template <class Currency> Tovar<Currency>::Tovar(Currency p, const string& ov)

{

price = (p>0)?p :0;

units = ov;

}

template <class Currency> ostream& operator<< (ostream& os, Tovar<Currency>& t)

{

if(t.price>0) return os<<"$"<<((Currency)t.price)<<" per 1 "<<t.units;

else return os<<"Sold 1 "<<t.units<<" Cash=="<< Tovar<Currency>::sum;

}

##endif23

Одразу відзначимо кілька важливих особивостей у описі шаблону класу :

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

2. Використання значень за замовчуванням у конструкторах не бажане, щоб уникнути помилок компілятора, пов'язаних із неоднозначністю описів.3. Можна декларувати дружні функції і оператори, в тому числі перевантажені, але у MS Visual Studio 2008 та 2010 це слід робити так: friend ostream& operator<< <Currency>(ostream&, Tovar<Currency>&);

або так:

friend ostream& operator<< <>(ostream&, Tovar<Currency>&);

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

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

template <class Currency>

ostream& operator << (ostream& os, Tovar<Currency>& t)

{ /* тіло оператора (так само може бути функції чи методу) */ }

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

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

на прикладі (два останніх рядки у головній програмі).

Отже, для перевірки роботи описаного шаблону використаємо таку головну програму (файл maintovar.cpp) :

##include<iostream>

##include" tovar.h"

using namespace std;

void main(void)

{

Tovar<int> tovar1_int;

Tovar<int> tovar_int(10);

Tovar<float> tovar_float(25.95","kg);

cout <<"INT typed Tovar :"<<endl<<tovar1_int<<endl<<tovar_int<<endl;

cout << "FLOAT typed Tovar :" << endl << tovar_float << endl;

cout << "NOW SALE!!"! <<endl;

if(tovar1_int.Sell()) cout << "Sell ok! ";

cout << "tovar 1_int : " << tovar1_int << endl;

if(tovar_int.Sell()) cout << "Sell ok! ";

cout << "tovar_int: " << tovar_int << endl;

if(tovar_float.Sell()) cout << "Sell ok! ";

cout << "tovar_float: " << tovar_float << endl;

cout << "Cash<INT>: " << Tovar<int>::GetSum() << endl;24

cout << "Cash<FLOAT>: " << Tovar<float>::GetSum() << endl;

}

Результатом роботи цієї програми буде такий вивід на екран:

INT typed Tovar :

$$1 per 1 piece

$$10 per 1 piece

FLOAT typed Tovar :

$$25.95 per 1 kg

NOW SALE!!!

Sell ok! tovar1_int: Sold 1 piece Cash==1

Sell ok! tovar_int: Sold 1 piece Cash==11

Sell ok! tovar_float: Sold 1 kg Cash==25.95

Cash<INT>: 11

Cash<FLOAT>: 25.95

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

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

Шаблони проектування (Design Patterns) загалом поділяють на три групи:

 Породжуючі або твірні шаблони (Creational Patterns).

 Структурні шаблони (Structural Patterns).

 Шаблони поведінки (Behavioral Patterns).

До першої групи (Creational Patterns) належать такі шаблони :

Абстрактна фабрика (Abstract Factory) - забезпечує інтерфейс для

створення сімейств пов'язаних чи залежниз об' єктів без вказання їх

конкретних класів.

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

Фабричний метод (Factory method) - визначає інтерфейс для створення об' єкту, але дозволяє підкласам вирішувати, які саме екземпляри класів створювати. Фабричний метод дозволяє класу перекласти інстанціювання (створення екземплярів) на підкласи.

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

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

До другої групи (Structural Patterns) належать такі шаблони :

Адаптер (Adapter) - перетворює інтерфейс класу до іншого інтерфейсу, якого очікують клієнти. Адаптер дозволяє працювати разом класам, які через несумісність інтерфейсів інакше не змогли б. Інша назва цього шаблону -"Обгортка" (Wrapper).

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

Компонувальник (Composite) - поєднує об' єкти у деревовидні структури для пердставлення ієрархії типу "частина-ціле". Дозволяє клієнтам звертатися до окремих об' єктів і їх композицій однаково.

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

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

Для порівняння "Адаптер" забезпечує точно визначений інтерфейс із підтримкою поліморфної поведінки. Водночас, навідміну від шаблону "Замісник", який працює непомітно (є прозорим) для клієнта, "Фасад" акцентовано перебирає на собі усі повноваження по взаємодії із прихованими за ним підсистемами.

Легковаговик (Flyweight) - використовує розподілене використання ресурсу (пам' яті) для ефективної підтримки великої кількості дрібних об' єктів.

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

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

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

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

До третьої групи (Behavioral Patterns) належать такі шаблони :

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

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

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

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

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

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

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

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

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

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

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

Спостерігач (Observer) - визначає залежність між об' єктами типу "один до багатьох", де зміна стану одного об' єкту (спостережуваного - observable) автоматичний викликає повідомлення і здійснення відповідних змін (оновлення) в усіх решта залежних об' єктів (спостерігачів - observers). Суть взаємодії між спостережуваним об' єктом і його спостерігачами у тому, що спостерігачі реєструються у спостережуваного об' єкту (як спостерігачі), а спостережуваний об' єкт зобов'язаний повідомляти спостерігачів про будь- які свої зміни стану.

Далі спостерігача самостійно повинні вирішувати, що робити із одержаною інформацією чи як реагувати на отримане повідомлення. Інша назва цього шаблону "Видавець/передплатник" (Publish/subscribe), можливо, більш яскраво розкриває його суть: передплатники реєструються у видавця і очікують на видання, яку видавець розсилає усім передплатникам.

Стан (State) - дозволяє об' єкту змінювати свою поведінку, коли змінюється його внутрішній стан. Виглядатиме це як зміна класу об' єкта. Цей шаблон також ще називають "Об' єкти для станів" (Objects for states).

Принципове призначення шаблону - представляти стан об' єкту. І цей шаблон надає допустимий шлях для об' єкту частково змінити свій тип під година роботи програми (at runtime).

Стратегія (Strategy) - визначає сімейство алгоритмів, інкапсулює кожен із них та дозволяє зробити їх взаємозамінними. Шаблон передбачає можливість змінювати алгоритм незалежно від клієнтів, що ним користуються. Фактично це особливий шаблон, який дозволяє обирати алгоритм під година роботи програми (at runtime) поклад від ситуації яка складається. Наприклад, від типу покладу даних, які потрібно обробити, алгоритми обробки можуть радикально відрізнятися. Але про ті, які конкретно дані прийдуть на обробку, програма дізнається вже лише у процесі роботи. Тому потрібен механізм для вибору адекватного алгоритму і шаблон "Стратегія" визначає цей механізм.

Шаблонний метод (Template method) - визначає скелет алгоритму у операції, відкладаючи деякі крокі для визначення у підкласах. Цей шаблон дозволяє підкласам перевизначити окремі крокі алгоритму, не змінюючи загальну структуру цього алгоритму. Принцип реалізації шаблону доволі простий і грунтується на перевантаженні (overriding) методів у класах-нащадках. Фактично, деякий базовий клас визначає "шаблонний метод" у термінах окремих операцій (методів класу, що можуть бути навіть чисто віртуальними). Нащадки цього базового класу, перевизначивши відповідні операції, вже як власні методи, додають власну специфіку і забезпечують виконання вусі того ж глобально визначеного алгоритму.

Відвідувач (Visitor) - представляє операцію, яка повинна бути виконана на елементах структури об' ктів. Шаблон дозволяє визначити нову операцію без зміни класів елементів, на яких вона працює. Цее шлях для відокремлення алгоритму від структури об' єктів, на якій цей алгоритм працює. Практичний результат такого відокремлення полягає у здатності додавати нові операції до існуючої структури об' ктів без внесення змін у цю структру. Це один із шляхів дотримуватися відкрито -закритого принципу (open/closed principle - OCP). По суті, шаблон "Відвідувач" дозволяє додавати нові віртуальні функції у сімейство класів, не змінюючи самих класів. Замість цього створюється клас- відвідувач, який реалізує усі відповідні спеціалізації віртуальної функції. Клас- відвідувач приймає на вхід посилання на екземпляр і реалізує цілі через механізм "Подвійної відправки" (механізм, що передбачає відправку виклику функції до різних конкретних функцій поклад від типів парі об' єктів, задіяних у виклику під година виконання програми).

Серед корисних шаблонів, які часто доводитися зустрічати, але які не належать до визначених GoF шаблонів проектування (design patterns), відмітимо шаблон "Відкладена ініціалізація" (Lazy Initialisation) - тактика відтермінування створення об' єкту, обчислення значення, чи будь-якого іншого витратного (доладного, ресурсоємного, тривалого, худо) процесу до моменту годині, коли це справді буде необхідним. Цей шаблон належить до групи породжуючи шаблонів. (Цей шаблон не належить до Design Patternsвизначених GoF.)

Загальні вхідні дані для курсу лабораторних зайняти Курс лабораторних робіт розрахований на 64 аудиторних години та складається з 8 лабораторних робіт. Завдання передбачають виконання усіх лабораторних робіт на мові C++ у середовищі Microsoft Visual Studio.