|
|||||||
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Примітка. Як буде видно з подальшого викладу, ієрархічна схема організації понять не тотожна ієрархії класів, оскільки взаємозв'язки між класами можуть мати і інші
Як буде видно з подальшого викладу, ієрархічна схема організації понять не тотожна ієрархії класів, оскільки взаємозв'язки між класами можуть мати і інші якісні особливості. З іншої сторони, ієрархія понять є більш загальною категорією в порівнянні з ієрархією рівнів абстракції класів ООП. Основними принципами ООП є успадкування, інкапсуляція і поліморфізм. Принцип, відповідно до якого знання про загальнішу категорію дозволяється застосовувати для вужчої категорії, називається успадкуванням. Успадкування тісно пов'язане з ієрархією класів, яка визначає, які класи слід вважати найабстрактнішими і загальнішими відносно інших класів. При цьому, якщо деякий батьківський клас (предок) володіє фіксованим набором властивостей і поведінкою, то похідний від нього клас (нащадок) повинен містити цей же набір властивостей і поведінку, а також додаткові, які характеризуватимуть унікальність отриманого таким чином класу. В цьому випадку говорять, що похідний клас успадковує властивості і поведінку батьківського класу. Для ілюстрації принципу успадкування можна навести наступний приклад. Розглянемо загальний клас "Автомобіль". Даний клас визначається як деяка абстракція властивостей і поведінки всіх реально існуючих автомобілів. При цьому властивостями класу "Автомобіль" можуть бути такі загальні властивості, як наявність двигуна, трансмісії, коліс, рульового керування. Якщо як похідний клас розглянути клас "Легковий автомобіль", то всі виділені вище властивості будуть властиві і цьому класу. Можна сказати, що клас "Легковий автомобіль" успадковує властивості батьківського класу "Автомобіль". Проте, окрім перерахованих властивостей, клас-нащадок міститиме додаткові властивості, наприклад такі, як наявність салону з кількістю посадочних місць 2-5. У свою чергу, клас "Легковий автомобіль" здатний породжувати інші підкласи, які цілком можуть відповідати, наприклад, моделям конкретних фірм-виробників. Таким чином, можна розглядати клас "Легковий автомобіль виробництва ВАЗ". Оскільки автомобільний завод Волжський випускає декілька моделей автомобілів, одним з похідних класів для попереднього класу може бути конкретна модель автомобіля, наприклад, ВАЗ-21083. Нарешті, виготовлений автомобіль має унікальний заводський номер, що відрізняє один автомобіль від іншого. Таким номером може бути, наприклад, XTA-210830S1594301. В останньому випадку клас складатиметься з єдиного об'єкту або екземпляра, яким буде легковий автомобіль виробництва ВАЗ з вказаним вище заводським номером. Описана вище інформація про співвідношення класів в нашому прикладі володіє одним серйозним недоліком, а саме відсутністю наочності. У зв'язку з цим виникає питання: а чи можливо представити ієрархію успадкування класів у візуальній формі? Традиційно для зображення понять у формальній логіці використовувалися кола або прямокутники. Тоді для розглянутого прикладу ієрархія породження класів може бути представлена у вигляді вкладених прямокутників, кожен з яких відповідає окремому класу (рис. 3.2). Рис. 3.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 в тому вигляді, як він зображений у відповідній документації (рис. 3.3). Процес розроблення програм в середовищі Borland/Inprise Delphi також тісно пов'язаний з використанням бібліотеки стандартних класів – VCL (Visual Component Library) або бібліотеки візуальних компонентів. Ця бібліотека теж побудована за ієрархічним принципом, відповідно до якого компоненти рівнів, що знаходяться нижче, успадковують властивості і методи вищерозміщених компонент. Для цього випадку також приводиться фрагмент ієрархії класів VCL (рис. 3.4). Рис. 3.3. Фрагмент ієрархії класів MFC, використовуваних в середовищі програмування MS Visual C++ 5/6 Рис. 3.4. Фрагмент ієрархії класів VCL використовуваних в середовищі програмування Borland/Inprise Delphi 15.4 Навіть цих простих прикладів досить, щоб зрозуміти наступний факт. Для однієї і тієї ж загальної концепції ієрархії класів використовуються абсолютно різні графічні засоби. У першому випадку – вкладені прямокутники, в другому – зв'язні прямокутники. Насправді різних способів зображення класів запропоновано значно більше, невелика частина з них буде розглянута нижче. Проте вже зараз важливо усвідомити, що подібну ситуацію слід було б уніфікувати, тобто використовувати для цієї мети деяку єдину систему позначень. Наступний принцип ООП – інкапсуляція. Цей термін характеризує приховування окремих деталей внутрішнього устрою класів від зовнішніх по відношенню до нього об'єктів або користувачів. Дійсно, суб'єктові, що взаємодіє з класом, або клієнтові немає необхідності знати, яким чином реалізований той або інший метод класу, послугами якого він вирішив скористатися. Конкретна реалізація властивих класу властивостей і методів, які визначають поведінку цього класу, є власною справою даного класу. Більше того, окремі властивості і методи класу взагалі можуть бути невидимі за межами цього класу, що є базовою ідеєю введення різних категорій видимості для компонентів класу. Якщо продовжити розгляд прикладу з класом "Легковий автомобіль", то неважко проілюструвати інкапсуляцію таким чином. Основним суб'єктом, який взаємодіє з цим класом, є водій. Цілком очевидно, що не кожен водій досконало знає внутрішній устрій легкового автомобіля. Більше того, окремі деталі цього пристрою свідомо приховані в корпусі двигуна або в коробці передач. А у разі порушення роботи автомобіля, необхідний ремонт виконує професійний механік. Інкапсуляція веде своє походження від ділення модулів в деяких мовах програмування на дві частини або секції: інтерфейс і реалізацію. При цьому в інтерфейсній секції модуля описуються всі оголошення функцій і процедур, а можливо і типів даних, доступних за межами даного модуля. Іншими словами, вказані процедури і функції є способами надання послуг зовнішнім клієнтам. У іншій секції модуля, званою реалізацією, міститься програмний код, який визначає конкретну реалізацію оголошених в інтерфейсній частині процедур і функцій. Принцип розділення модуля на інтерфейс і реалізацію відображає суть наших уявлень про навколишній світ. У інтерфейсній частині вказується вся інформація, необхідна для взаємодії з будь-якими іншими об'єктами. Реалізація приховує або маскує від інших об'єктів всі деталі, що не мають відношення до процесу взаємодії об'єктів (рис. 3.5). Рис. 3.5. Ілюстрація проховування внутрішніх деталей реалізації методів класів Поиск по сайту: |
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.006 сек.) |