1.2. Методологія об'єктно-орієнтованого програмування
З часом ситуація стала істотно змінюватися. Виявилося, що трудомісткість розробки програмних додатків на початкових етапах програмування оцінювалася значно нижче реально затрачуваних зусиль, що служило причиною додаткових витрат і затягування остаточних термінів готовності програм. В процесі розробки додатків змінювалися функціональні вимоги замовника, що ще більш віддаляло момент закінчення роботи програмістів. Збільшення розмірів програм приводило до необхідності залучення більшого числа програмістів, що, у свою чергу, зажадало додаткові ресурси для організації їх злагодженої роботи.
Але не менше важливими виявилися якісні зміни, пов'язані із зсувом акценту використовування комп'ютерів. Якщо в епоху «великих машин» основними споживачами програмного забезпечення були крупні підприємства, компанії і установи, то пізніше з'явилися персональні комп'ютери і стали повсюдним атрибутом дрібного і середнього бізнесу. Обчислювальні і розрахунково‑ алгоритмічні задачі в цій області традиційно займали другорядне місце, а на перший план виступили задачі обробки і маніпулювання даними.
Стало очевидним, що традиційні методи процедурного програмування не здатні справитися ні з складністю програм і їх розробки, що росте, ні з необхідністю підвищення їх надійності. В другій половині 80-х років виникла настійна потреба в новій методології програмування, яка була б здатна вирішити весь цей комплекс проблем. Такою методологією стало об'єктно-орієнтоване програмування (ООП).
Фундаментальними поняттями ООП є поняття класу і об'єкту. При цьому під класом розуміють деяку абстракцію сукупності об'єктів, які мають загальний набір властивостей і володіють однаковою поведінкою. Кожний об'єкт в цьому випадку розглядається як екземпляр відповідного класу. Об'єкти, які не мають повністю однакових властивостей або не володіють однаковою поведінкою, за визначенням, не можуть бути віднесені до одного класу.
Примітка
Приведене вище визначення класу є достатньо загальним. В подальших розділах у міру вивчення матеріалу цей термін уточнюватиметься на основі встановлення семантичних зв'язків з іншими поняттями об'єктно-орієнтованого аналізу і проектування.
Важливою особливістю класів є можливість їх організації у вигляді деякої ієрархічної структури, яка на вигляд нагадує схему класифікації понять формальної логіки. В зв'язку з цим слід помітити, що кожне поняття в логіці має деякий об'єм і зміст. При цьому під об'ємом поняття розуміють всі інші мислимі поняття, для яких початкове поняття може служити визначальною категорією або головною частиною. Зміст поняття складає сукупність всіх його ознак або атрибутів, що відрізняють дане поняття від всіх інших. У формальній логіці має місце закон зворотного відношення: якщо зміст поняття А міститься в змісті поняття В, то об'єм поняття В міститься в об'ємі поняття А.
Ієрархія понять будується таким чином. Як саме загальне поняття або категорія береться поняття, що має найбільший об'єм і, відповідно, якнайменший зміст. Це найвищий рівень абстракції для даної ієрархії. Потім дане загальне поняття деяким чином конкретизується, тим самим зменшується його об'єм і збільшується зміст. З'являється менш загальне поняття, яке на схемі ієрархії буде розташоване на рівень нижче за початкове поняття. Цей процес конкретизації понять може бути продовжений до тих пір, поки на самому нижньому рівні не буде одержано поняття, подальша конкретизація якого в даному контексті або неможлива, або недоцільна.
Прикладами самих загальних понять можуть служити такі абстрактні категорії, як система, структура, інтелект, інформація, єство, зв'язок, стан, подія і багато інших. В процесі вивчення цих категорій з'являються нові особливості їх змісту і об'єму. Саме з цих причин завжди важко дати їм точне визначення. Як приклади конкретних понять можна привести поняття книги, яку читач тримає в руках, або поняття мікропроцесора Intel Pentium П‑ 300.
Примітка
Як буде видно з подальшого викладу, ієрархічна схема організації понять не тотожна ієрархії класів, оскільки взаємозв'язки між класами можуть мати і інші якісні особливості. З другого боку, ієрархія понять є більш загальною категорією в порівнянні з ієрархією рівнів абстракції класів ООП.
Основними принципами ООП є спадкоємство, інкапсуляція і поліморфізм. Принцип, відповідно до якого знання про більш загальну категорію дозволяється застосовувати для більш вузької категорії, називається спадкоємством. Спадкоємство тісно пов'язано з ієрархією класів, яка визначає, які класи слід вважати найабстрактнішими і загальними по відношенню до інших класів. При цьому, якщо деякий більш загальний або батьківський клас (предок) володіє фіксованим набором властивостей і поведінкою, то похідний від нього клас (нащадок) повинен містити цей же набір властивостей і поведінку, а також додаткові, які характеризуватимуть унікальність одержаного таким чином класу. В цьому випадку говорять, що похідний клас успадковує властивості і поведінку батьківського класу.
Для ілюстрації принципу спадкоємства можна привести наступний приклад. Розглянемо як загальне клас «Автомобіль». Даний клас визначається як деяка абстракція властивостей і поведінки всіх реально існуючих автомобілів. При цьому властивостями класу «Автомобіль» можуть бути такі загальні властивості, як наявність двигуна, трансмісії, коліс, рульового управління. Якщо як похідний клас розглянути клас «Легковий автомобіль», то всі виділені вище властивості будуть властиві і цьому класу. Можна сказати, що клас «Легковий автомобіль» успадковує властивості батьківського класу «Автомобіль». Проте, окрім перерахованих властивостей, клас‑ нащадок міститиме додаткові властивості, наприклад таке, як наявність салону з кількістю посадочних місць 2–5.
У свою чергу, клас «Легковий автомобіль» здатний породжувати інші підкласи, які цілком можуть відповідати, наприклад, моделям конкретних фірм‑ виробників. Таким чином, можна розглядати клас «Легковий автомобіль виробництва ВАЗ». Оскільки Волжській автомобільний завод випускає декілька моделей автомобілів, одним з похідних класів для попереднього класу може бути конкретна модель автомобіля, наприклад, ВАЗ‑ 21083. Нарешті, виготовлений автомобіль має унікальний заводський номер, що відрізняє один автомобіль від іншого. Таким номером може бути, наприклад, XTA‑ 210830S1594301. В останньому випадку клас складатиметься з єдиного об'єкту або екземпляра, яким буде легковий автомобіль виробництва ВАЗ з вказаним вище заводським номером.
Описана вище інформація про співвідношення класів в нашому прикладі володіє одним серйозним недоліком, а саме відсутністю наочності. В зв'язку з цим виникає питання: а чи можливо представити ієрархію спадкоємства класів у візуальній формі? Традиційно для зображення понять у формальній логіці використовувалися кола або прямокутники. Тоді для розглянутого прикладу ієрархія породження класів може бути представлена у вигляді вкладених прямокутників, кожний з яких відповідає окремому класу (мал. 1.2).
Мал. 1.2. Ієрархія вкладеності класів для прикладу «Автомобіль»
Поява об'єктно-орієнтованих язиків програмування була пов'язана з необхідністю реалізації концепції класів і об'єктів на синтаксичному рівні. З погляду ООП клас є подальшим розширенням структури (structure) або запису (record). Включення у відомі язики програмування З і Pascal класів і деяких інших можливостей привело до появи відповідно C++ і Object Pascal, які на сьогодні є найпоширенішими язиками розробки додатків. Розповсюдженню C++ і Object Pascal сприяла та обставина, що язик C++ був вибраний як базове для програмного інструментарію MS Visual C++, а язик Object Pascal– для популярного засобу швидкої розробки додатків Borland/Inprise Delphi.
За короткий період часу обидва інструментарії перетворилися на могутні системи розробки програм з відповідними бібліотеками стандартних класів, що містять сотні різних властивостей і методів. Стосовно середовища MS Visual C++ 5/6 така бібліотека має спеціальну назву – MFC (Microsoft Foundation Classes), т. е. фундаментальні класи від Microsoft. При цьому похідні класи успадковують властивості і методи батьківських класів. Нижче приводиться фрагмент ієрархії класів MFC в тому вигляді, як він зображений у відповідній документації (мал. 1.3).
Мал. 1.3. Фрагмент ієрархії класів MFC, що використовуються в середовищі програмування MS Visual C++ 5/6
Мал. 1.4. Фрагмент ієрархії класів VCU використовуються в середовищі програмування Borland/Inprise Delphi 3‑ 4
Процес розробки програм в середовищі Borland/Inprise Delphi також тісно зв'язаний з використанням бібліотеки стандартних класів – VCL (Visual Component Library) або бібліотеки візуальних компонентів. Ця бібліотека теж побудована за ієрархічним принципом, відповідно до якого компоненти нижчележачих рівнів успадковують властивості і методи вищерозміщених компонентів. Для даного випадку також приводиться фрагмент ієрархії класів VCL (мал. 1.4).
Навіть цих простих прикладів достатньо, щоб зрозуміти наступний факт. А саме, для однієї і тієї ж загальної концепції ієрархії класів використовуються абсолютно різні графічні засоби. В першому випадку – вкладені прямокутники, в другому – зв'язні прямокутники. Насправді різних способів зображення класів запропоновано набагато більше, невелика частина з них буде розглянута нижче. Проте вже зараз важливо усвідомити, що подібну ситуацію було б слід уніфікувати, т. е. використовувати для цієї мети деяку єдину систему позначень.
Наступний принцип ООП – інкапсуляція. Цей термін характеризує заховання окремих деталей внутрішнього пристрою класів від зовнішніх по відношенню до нього об'єктів або користувачів. Дійсно, взаємодіючому з класом суб'єкту або клієнту немає необхідності знати, яким чином реалізований той або інший метод класу, послугами якого він вирішив скористатися. Конкретна реалізація властивих класу властивостей і методів, які визначають поведінку цього класу, є власною справою даного класу. Більш того, окремі властивості і методи класу взагалі можуть бути невидимі за межами цього класу, що є базовою ідеєю введення різних категорій видимості для компонентів класу.
Якщо продовжити розгляд прикладу з класом «Легковий автомобіль», то неважко проілюструвати інкапсуляцію таким чином. Основним суб'єктом, який взаємодіє з цим класом, є водій. Цілком очевидно, що не кожний водій досконало знає внутрішній пристрій легкового автомобіля. Більш того, окремі деталі цього пристрою свідомо приховані в корпусі двигуна або в коробці передач. А у разі порушення роботи автомобіля, причиною неадекватності його поведінки, що є, необхідний ремонт виконує професійного механіка.
Інкапсуляція веде своє походження від розподілу модулів в деяких язиках програмування на дві частини або секції: інтерфейс і реалізацію. При цьому в інтерфейсній секції модуля описуються всі оголошення функцій і процедур, а можливо і типів даних, доступних за межами даного модуля. Іншими словами, вказані процедури і функції є способами надання послуг зовнішнім клієнтам. В іншій секції модуля, званою реалізацією, міститься програмний код, який визначає конкретні чини реалізацій оголошених в інтерфейсній частині процедур і функцій.
Принцип розділення модуля на інтерфейс і реалізацію відображає суть наших уявлень про навколишній світ. В інтерфейсній частині указується вся інформація, необхідна для взаємодії з будь-якими іншими об'єктами. Реалізація приховує або маскує від інших об'єктів всі деталі, що не мають відношення до процесу взаємодії об'єктів (мал. 1.5).
Мал. 1.5. Ілюстрація заховання внутрішніх деталей реалізації методів класів
Примітка
Ступінь затемнення фону на приведеному вище малюнку має більш глибокий сенс, чим може показатися на перший погляд. Якщо асоціювати реалізацію програмного модуля з. водою в акваріумі, то видимість об'єктів, що знаходяться у воді, залежатиме від ступеня її чистоти або забруднення. В ООП існують різні варіанти доступу до властивостей і методів класів, які одержали назву видимості властивостей і методів. В цьому випадку використовування різних форм видимості для компонентів класів зручно асоціювати з прозорістю фону малюнка або видимістю у воді акваріума. Більш детальний розгляд різних форм видимості приводиться в частині II книги.
Третім принципом ООП є поліморфізм. Під поліморфізмом (грец. Poly– багато, morfos – форма) розуміють властивість деяких об'єктів приймати різні зовнішні форми залежно від обставин. Стосовно ООП поліморфізм означає, що дії, виконувані однойменними методами, можуть відрізнятися залежно від того, якому з класів відноситься той або інший метод.
Розглянемо, наприклад, три об'єкти або клас: двигун автомобіля, електричне світло в кімнаті і персональний комп'ютер. Для кожного з них можна визначити операцію «вимкнути». Проте єство цієї операції відрізнятиметься для кожного з розглянутих об'єктів. Так для двигуна автомобіля виклик методу двигун_автомобиля. вимкнути про означає припинення подачі палива і його зупинку. Виклик методу Кімната. электричне_світло. вимкнути про означає просте клацання вимикача, після чого кімната зануриться в темноту. В останньому випадку дія персональный_комп'ютер. вимкнути про може бути причиною втрати даних, якщо виконується нерегламентованим чином.
Примітка
В розглянутому вище прикладі використовувалася одна з прийнятих нотацій в деяких мовах програмування (наприклад, в Object Pascal) для позначення приналежності методу тому або іншому класу. Відповідно до цієї нотації, спочатку вказується ім'я класу, в якому визначений метод, а потім через крапку ім'я самого методу. Якщо метод визначений в деякому підкласі, то повинна бути вказаний весь ланцюжок класів, починаючи з самим загальним з них. При цьому характерною ознакою методу є пара дужок, які використовуються для вказівки списку аргументів або формальних параметрів даного методу.
В нашому прикладі для операції вимкнути () можна визначити такі додаткові параметри, як час виключення, деяка умова знаходження об'єкту в заздалегідь включеному стані і ін. Для цього після імені операції указуються дужки, в яких можуть бути вказані ці додаткові параметри або аргументи. У разі відсутності аргументів вважається, що список параметрів порожній. Проте дужки все одно записуються і указують на той факт, що відповідне ім'я є ім'ям операції або методу, на відміну від властивостей або атрибутів класу, які записуються без дужок.
Поліморфізм об'єктно-орієнтованих мов пов'язаний з перевантаженням функцій, але не рівний їм. Важливо мати у вигляді, що імена методів і властивостей тісно пов'язані з класами, в яких вони описані. Ця обставина забезпечує певну надійність роботи програми, оскільки виключає випадкове вживання методу для вирішення невластивої йому задачі.
Широке розповсюдження методології ООП зробило вплив на процес розробки програм. Зокрема, процедурно‑ орієнтована декомпозиція програм поступилася місцем об'єктно-орієнтованої декомпозиції, при якій окремими структурними одиницями програми сталі бути не процедури і функції, а класи і об'єкти з відповідними властивостями і методами. Як наслідок, програма перестала бути послідовністю приречених на етапі кодування дій, а стала подія‑ керованою. Остання обставина стала домінуючою при розробці широкого круга сучасних додатків. В цьому випадку кожна програма є нескінченним циклом очікування деяких наперед певних подій. Ініціаторами подій можуть бути інші програми або користувачі. При настанні окремої події, наприклад, натиснення клавіші на клавіатурі або клацання кнопкою миші, програма виходить із стану очікування і реагує на цю подію цілком адекватним чином. Реакція програми при цьому теж зв'язується з наступними подіями.
Найістотнішою обставиною в розвитку методології ООП з'явилося усвідомлення того факту, що процес написання програмного коду може бути відокремлений від процесу проектування структури програми. Дійсно, до того як почати програмування класів, їх властивостей і методів, необхідно визначити, чим же є самі ці класи. Більш того, потрібно дати відповіді на такі питання, як: скільки і які класи потрібно визначити для вирішення поставленої задачі, які властивості і методи необхідні для додання класам необхідної поведінки, а також встановити взаємозв'язки між класами.
Ця сукупність задач не стільки пов'язана з написанням коду, скільки із загальним аналізом вимог до майбутньої програми, а також з аналізом конкретної наочної області, для якої розробляється програма. Всі ці обставини привели до появи спеціальної методології, що одержала назву методології объектно‑ ориентированнного аналізу і проектування (ООАП).