7. Чисто Об’єктно-орієнтовані й гібридні мови

Розрізняються чисті й гібридні Об’єктно-орієнтовані мови. Чисті - це ті, які дозволяють використати тільки одну модель програмування – об′єктну-орієнтовану. Ви можете повідомляти класи й методи, але не можете завести глобальні змінні й звичайні функції й процедури старого типу.

Серед трьох наших мов, тільки Java є чистим ОО мовою (як Eiffel й Smalltalk). На перший погляд це здається позитивною ідеєю. Однак вона веде до того, що ви використаєте купу статичних методів і статичних даних, що не так вуж відрізняється від використання глобальних функцій і даних, за винятком більше складного синтаксису. Чисті ОО мови дають перевага новачкам в ООП, тому що програміст змушений використати (і вчити) модель ООП. C++ й Object Pascal, навпаки, - типові приклади гібридних мов, які дозволяють програмістам використати при необхідності традиційний підхід C або Pascal.

Проста об'єктна модель і об′єктно-посилаюча модель

Властивість: Третій елемент, по якому розрізняються мови ООП - їхня об'єктна модель. Деякі традиційні мови ООП дозволяють програмістам створювати об'єкти в стеці, у купі (у хипе - heap) або в статичній пам'яті. У цих мовах змінна типу клас відповідає об'єкту в пам'яті. Так працює C++.

Останнім часом з'явилася тенденція використати іншу модель, часто названу об′єктно-посилаючою моделлю. У цій моделі кожен об'єкт динамічно розміщається в купі, а змінна типу клас фактично є посиланням або хэндлом об'єкта в пам'яті (технічно це щось подібне до покажчика). Java й Object Pascal обоє використають цю посилальну модель. Як ми побачимо, коротенько це значить, що вам необхідно не забути виділити пам'ять для об'єкта.

7. Переваги ооп у порівнянні із процедурним програмуванням:

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

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

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

8. Методологія Об’єктно-орієнтованого програмування

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

Об’єктно-орієнтоване програмування (ООП, Object-Oriented Programming) - сукупність принципів, технологій , а також інструментальних засобів для створення програмних систем на основі архітектури взаємодії об'єктів.

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

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

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

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

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

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

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

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

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

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

Рис. 1.1.  Ієрархія вкладеності класів для приклада загального класу "Комп'ютер"

Подібне зображення має серйозний недолік. Із представленого малюнка не ясно, чи зображена на ньому ієрархія понять або декомпозиція класу "Комп'ютер" на його складові частини. Як буде показано далі, використання нотації UML дозволяє усунути дану невизначеність за допомогою введення в розгляд двох різних відносин: узагальнення й агрегації (Лекція 6).

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

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

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

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

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

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

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

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

Методологія Об’єктно-орієнтованого аналізу й проектування

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

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

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

Об′єктно-орієнтований аналіз і проектування (ООАП, Object-Oriented Analysis/Design) -технологія розробки програмних систем, в основу яких покладена об′єктно-орієнтована методологія подання предметної області у вигляді об'єктів, що є екземплярами відповідних класів.

Методологія ООАП тісно пов'язана з концепцією автоматизованої розробки програмного забезпечення (Computer Aided Software Engineering, CASE). До перших CASE-засобів віднеслися з певною сторожкістю. Згодом з'явилися як захоплені відкликання про їхнє застосування, так і критичні оцінки їхніх можливостей. Причин для настільки суперечливих думок було трохи. Перша з них полягає в тім, що ранні CASE-засоби були простою надбудовою над системою керування базами даних (СУБД). Візуалізація процесу розробки концептуальної схеми БД має немаловажне значення, проте, вона не вирішує проблем створення додатків інших типів.

Друга причина пов'язана із графічною нотацією, реалізованої в CASE-засобі. Якщо мови програмування мають строгий синтаксис, то спроби запропонувати підходящий синтаксис для візуального подання концептуальних схем БД, були сприйняті далеко не однозначно. На цьому тлі розробка й стандартизація уніфікованої мови моделювання UML викликала наснагу у всього співтовариства корпоративних програмістів.

У рамках ООАП історично розглядалися три графічних нотації:

• діаграми "сутність-зв'язок" (Entity-Relationship Diagrams, ERD),

• діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT),

• діаграми потоків даних (Data Flow Diagrams, DFD).

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

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

Зв'язок (relationship) визначається як відношення або асоціація між окремими сутностями. Прикладами зв'язків можуть бути родинні відносини, зокрема "батько-син" або виробничі - "начальник-підлеглий". Інший тип зв'язків задається відносинами "мати у власності" або "мати властивість". Різні типи зв'язків графічно зображуються у формі ромба з відповідним ім'ям даного зв'язку.

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

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

Рис. 1.2.  Діаграма "сутність-зв'язок" для приклада співробітників компанії, що працюють над різними проектами

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

1. Які існують підходи до написання програм?

2. Яка парадигма вважається найбільш вдалою для розв’язування конкретного класу завдань?

3. Що являє собою програма при об’єктно-орієнтованому підході? Які ви знаєте об’єктно-орієнтовані мови програмування?

4. Що називається об’єктом? Навести приклади.

5. Що називається полем і методом об’єкта?

6. Які типи методів можна задавати для об’єкта?

7. Навести приклади об’єктів в офісних програмах. Вказати для кожного з них поля і методи.

8. Вказати спільні риси та відмінності між записами та об’єктами в мові Pascal.

9. Вказати співвідношення між поняттями клас, об’єкт, екземпляр.

10. Вказати переваги ООП у порівнянні з процедурним програмуванням.

11. Охарактеризувати основні принципи ООП.

12. Які існують етапи розробки програмних систем з використанням ООП?

13. Навести формат оголошення класу в мові Pascal.

14. Навести приклади звернення до полів і методів об’єкта.

15. Вказати призначення оператора приєднання With. Навести приклад його використання.