9 Елементи концепції “документ – вигляд”

9.1 Загальні особливості концепції “Документ – вигляд”

Слід зауважити, що протягом восьми попередніх розділів розглядалася лише одна концепція програмування засобами Visual C++. Ця концепція передбачала розробку програми на основі щонайменше двох основних класів: класу головного вікна (породжуваного від CFrameWnd або CDialog) та класу при-кладки (породжуваного від CWinApp). Об’єкти цих класів – об’єкти прикладки і вікна забезпечували працездатність практично усієї програми. При цьому практично завжди створювався пустий проект типу “Win32 Application”, до якого додавалися необхідні класи, об’єкти та функції. Таким чином, побудова проекту проваджувалася “з чистого аркуша”.

Але є й інші підходи. Вони тією чи іншою мірою реалізують концепцію швидкої розробки (RAD – rapid application development), в якій певна структура програми має організовуватися автоматично засобами середовища програмування. У Visual C++ ця концепція підтримується програмними проектами типу MFC AppWizard (див. підрозділ 1.1) та проектами більш складного типу. Слід зазначити, що й більшість літератури з програмування на Visual C++(наприклад [6, 9]) акцентує увагу на створенні програм саме у цей спосіб. Щоправда, програміст-початківець, створивши засобами Application Wizard свій проект, може задати запитання: чому порожня програма займає декілька сторінок тексту, складається з декількох класів та багатьох функцій і чи всі ці класи та функції є конче необхідними? Також може виникати певний сумнів у тому чи повністю програміст контролює поведінку створюваного проекту, чи може призвести поведінка програми до неконтрольованих наслідків.

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

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

Програми, що підтримують таку концепцію, породжують документ від класу CDocument, а об’єкт вигляду – від класу CView. Щоправда у таких програмах зберігаються і “старі” класи – породжені від класу головного (діалогового) вікна та класу прикладки, причому клас вікна має зменшену роль, тому що CView перекриває у більшості функцій клас CFrameWnd.

У концепції “Документ – вигляд” документом є блок даних, з яким співпрацює програма, а виглядом документа є фізичне відображення даних. Вигляд даних є неоднозначним і неоднаковим, наприклад під час виведення на екран або на принтер. Можна сказати, що документ є “чистими” даними, тоді як вигляд є конкретним способом їх відображення.

У Microsoft Windows програми на основі концепції “Документ – вигляд” можуть будуватися на основі інтерфейсу SDI (single document interface – інтерфейс одного документу) та MDI (multi-document interface – інтерфейс багатьох документів). З точки зору користувача різниця між двома інтерфейсами полягає у способі відображення документів.

SDI відображує кожен новий документ у новій копії програми. Це наявно демонструється програмою Internet Explorer, де кожна нова сторінка відображається за допомогою нового запуску програми. Програма, побудована відповідно до інтерфейсу MDI міститиме декілька вікон одночасно. Під час побудови проектів типу “MFC AppWizard” можна обрати будь-який з інтерфейсів, хоча Microsoft з точку зору побудови самої операційної системи як базовий інтерфейс рекомендує SDI.

Класи MFC дозволяють автоматизувати зберігання документів у файлах на диску. Цей процес має назву серіалізації – від назви функції Serialize() класу CDocument. Клас CDocument підтримує стандартні операції створення доку-мента, завантаження та збереження.

2. Програмна реалізація концепції “Документ – вигляд”

9.2 1 Динамічне створення об’єктів

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

DECLARE_DYNCREATE( class_name )

IMPLEMENT_DYNCREATE( class_name, base_class_name )

Їх параметрами є class_name – ім’я класу (не вміщене у лапки), для якого оголошується можливість динамічного створення об’єктів та base_class_name –ім’я базового класу (також не вміщене у лапки).

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

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

Друга макрокоманда – IMPLEMENT_DYNCREATE має дозволити динамічне створення об’єктів класів, породжених від CObject, під час виконання програми. Цей макрос додається у *.cpp-файл програми.

Якщо використовуються макроси DECLARE_DYNCREATE та IMPLEMENT_DYNCREATE, можна використовувати ще один макрос – RUNTIME_CLASS та функцію-член CObject :: IsKindOf() для визначення класу об’єктів під час виконання програми.

9.2.2 Загальний порядок створення програми

Визначимо особливості створення програми відповідно концепції “Документ – вигляд”. Зазначимо, що при створенні проекту типу “MFC AppWizard” така послідовність здійснюється автоматично без втручання програміста.

Для створення програми, що відповідає концепції “Документ – вигляд” необхідно здійснити такі кроки:

1. створити класи прикладки, головного вікна програми, документа, вигляду;

2. дозволити динамічне створення об’єктів класів головного вікна, документа та вигляду;

3. створити шаблон документа, що має об’єднати класи головного вікна, документа та вигляду;

4. реалізувати обробку командного рядка програми;

5. перевизначити необхідні функції класів програми, наприклад COblect::Serialize(); або CView::OnDraw();

9.2.3 Створення класів програми

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

Для класу головного вікна, виводиться з класу CFrameWnd, має забезпечуватися динамічне створення об’єктів. Таким чином опис класу вікна міститиме макрос DECLARE_DYNCREATE(). Клас головного вікна також включатиме всі об’єкти елементів керування вікна. Приклад 9.1 демонструє такий клас вікна.