Зміст
Частина І Основи об’єктно-орієнтованого програмування 2
Тема № 1: Концепція об’єктно-орієнтованого програмування. Об’єктна модель. 2
Тема № 2: Об’єктна модель. Складові об’єктного підходу. 6
Тема № 3: Класи та об’єкти. 16
Тема № 4: Процес проектування. 29
Частина ІІ Об’єктно-орієнтоване програмування під ОС Windows 31
Тема № 5: Основи операційної системи Windows 31
Тема № 6 : Структура програм під ОС Windows 36
Тема № 7 : Бібліотека базових класів Microsoft (MFC) 40
Тема № 8: Структура програми на основі класів MFC 44
Тема № 9: Основні типи програм на основі класів MFC 51
Тема № 10: Елементи інтерфейсу користувача на основі класів MFC 57
Тема № 11: Графічні об’єкти в MFC 65
Контрольні запитання 68
До модулю 1. 68
До модулю 2. 68
Екзаменаційні. 68

Частина ІОснови об’єктно-орієнтованого програмування
Тема № 1: Концепція об’єктно-орієнтованого програмування. Об’єктна модель.
План
1. Складні системи. Декомпозиція, абстрагування та ієрархія.
2. Еволюція об’єктної моделі. Основи об’єктної моделі.
3. Об’єктно-орієнтовані програмування, проектування та аналіз.
Складні системи
Складність систем ми будемо розглядати стосовно промислових програмних продуктів, що розробляються групою розробників або навіть і декількома групами. Суттєва риса промислових програм - рівень складності. Одинокий розробник або навіть й група розробників не в стані охопити всі аспекти такої системи. Складність таких систем здебільшого перевищує можливості людського інтелекту. Згаданою складністю очевидно володіють усі великі системи. Цю складністю можна подолати, але уникнути її неможливо. Тому необхідно розглянути надійні способи побудови складних систем, які б з високою ймовірністю гарантували успіх в їх проектуванні.
Аспекти складності стосовно розробки програмного забезпечення:
- складність реального світу, або тої його частини яку моделює програма;
- складність управління процесом розробки;
- проблеми описання поведінки великих дискретних систем.
Структура складних систем
Основні властивості складних систем, що обґрунтовують об’єктний підхід:
- складні системи є ієрархічними і складаються із взаємопов’язаних частин, що також можуть ділитися на підсистеми;
- розділ систем на елементарні компоненти є відносно довільний і здебільшого залежить від дослідника;
- зв’язок в середині компонентів набагато сильніший ніж між компонентами, це обумовлює “високочастотну” взаємодію всередині компонентів та “низькочастотну” між компонентами;
- ієрархічні системи складаються з невеликої кількості типів підсистем різним чином скомбінованих та організованих;
- діюча складна система є результатом розвитку більш простої системи, що працювала раніше. (Складна система, що спроектована з “нуля” навряд чи запрацює.)
Досвід проектування складних систем показує [Буч], що найбільш успішними є ті системи в яких закладено добре продумані структури класів та об’єктів і які володіють згаданими вище властивостями.
Структури класів та об’єктів системи разом називають архітектурою системи.
При проектуванні складних систем розглядають три основні аспекти:
- декомпозиція;
- абстрагування;
- ієрархія.
Декомпозиція
На древньому принципі управління “розділяй та владарюй” і зараз базується побудова та управління складною системою. При проектування програмна система розкладається на все менші та менші підсистеми, що можуть розроблятися та вдосконалюватися незалежно.
До сих пір ми мали справу зі структурним проектуванням “зверху вниз” і декомпозиція сприймається як розділення алгоритмів, де кожен модуль виконує якусь частину загального процесу.
При об’єктно-орієнтованій декомпозиції система розбивається на об’єкти, кожен з яких живе своїм життям (знаходиться у якомусь стані). Обмінюючись повідомленнями об’єкти об’єднуються у систему для виконання спільних дій.
При проектуванні систем важливі як алгоритмічна так і об’єктна декомпозиції. Вони є взаємодоповнюючими а не взаємозамінними. Але об’єктно-орієнтована декомпозиція значно зменшує об’єми програмних систем за рахунок повторного використання загальних механізмів, що приводить до економії засобів вираження сутності системи.
Абстракція
Абстракція полягає у виділенні (на певному рівні) найбільш важливих ознак об’єктів (інформації про об’єкти) реального світу які моделюються та в абстрагуванні від незначних деталей. Таким чином формується узагальнююча, ідеалізована модель об’єкту. Незначні на певному рівні абстракції елементи моделі можуть уточнюватися на нижчих рівнях і на їх основі об’єкти розрізняються між собою.
Ієрархія
Ієрархія класів та об’єктів є способом розширення інформативності елементів системи. Об’єктна структура ілюструє схему взаємодії об’єктів між собою. Структура класів визначає узагальнення структур та їх поведінку в середині системи.
Визначити ієрархічні зв’язки в системі не завжди просто, але після їх визначення структура складної системи та сама система стає зрозумілішою.
Зміст проектування
Під проектування розуміють деякий уніфікований підхід за допомогою якого шукають шляхи вирішення певної проблеми. Під проектуванням розглядають побудову системи, що
- задовольняє заданим (часто неформальним) специфікаціям функціонування;
- узгоджується з обмеженнями, що накладаються обладнанням;
- задовольняє явні та неявні вимоги з експлуатації та ресурсоспоживанню;
- відповідає вимогам до самого процесу розробки, таким як тривалість та вартість, а також використання додаткових інструментальних засобів.
При проектуванні здебільшого застосовується моделювання в значній мірі тому, що воно реалізує принципи декомпозиції, абстракції та ієрархії. Кожна модель описує певну частину системи, а ми будуємо нові на базі старих, в яких ми більше чи менше впевнені.
Методи проектування володіють деякими спільними властивостями:
- умовні позначення – мова для описання кожної моделі;
- процес правила проектування моделей;
- інструменти – засоби, які пришвидшують процес створення моделей, і в яких вже закладені закони функціонування моделей. Інструменти дозволяють виявити помилки в процесі розробки.
Еволюція об’єктної моделі
Протягом розвитку мов програмування високого рівня розвилася та закріпилася тенденція переходу від імперативних (які вказують комп’ютеру, що робити) до декларативних (які описують ключові абстракції проблемної галузі) мов.
Мови програмування умовно розбиваються на чотири покоління в залежності від мовних конструкцій, що в них реалізовані.
Перше покоління FORTRAN I, ALGOL58 (математичні формули). Вони орієнтувалися в основному на інженерні та наукові розрахунки та підтримували виключно математичні абстракції.
Друге покоління FORTRAN II (підпрограми, роздільна компіляція), ALGOL60 (блокова структура, типи даних), COBOL (описання даних, робота з файлами), Lisp (обробка списків, вказівними, збирання сміття). Основна тенденція цього покоління мов розвиток алгоритмічних абстракцій.
Третє покоління PL/1 (FORTRAN + ALGOL + COBOL), ALGOL68 (строгий нащадок ALGOL60), Pascal (спрощений нащадок ALGOL60), Simula (класи, абстрагування даних) характеризується більш суттєвим кроком від підтримки машини до предметної галузі.
У четвертому поколінні було створено багато мов програмування високого рівня, але мало з них вижили. Але механізми, що були запропоновані ними втілювалися у нових версіях старіших мов. Саме тоді розвинулися об’єктні та об’єктно-орієнтовані мови Smalltalk (по новому розвинутий спадок від Simula). Ada (нащадок ALGOL68 та Pascal з елементами Simula) CLOS (об’єднав Lisp, LOOPS та Flavors), C++ (гібрид C та Simula), Eiffel (об’єднання Simula та Ada). Ці мови можна назвати зараз об’єктно-орієнтованими.
Приклад (графічний). Структура об’єктно-орієнтованої програми представляється графом а не деревом, як у випадку процедурно-орієнтованої.
В основному об’єктно-орієнтований підхід пов’язаний з такими подіями як:
- значний прогрес в галузі архітектури ЕОМ;
- розвиток мов програмування, таких як Simula, Smalltalk, Ada;
- розвиток технології програмування,