Реферат — Інкапсуляція — скачати безкоштовно

Модуль як програмний еквівалент класу об’єктів. — Концепція імпорту/експорту. — Закритий та відкритий експорт. — Експорт типів та змінних. — «Свої» та «чужі» об’єкти. — Розшарування властивостей.

Інкапсуляція — Одна із специфічних особливостей програмування, орієнтованого на об’єкти. Ця особливість передбачає як можливості » розкладання цілого на частини » (принципу, визначального основи будь-якого програмування), а й уміння » приховувати » зокрема від загального (цілого). Такий підхід дозволяє програмісту не знати приватних деталей реалізації програмної системи, здійснювати конструювання з елементів, реалізація яких прихована від нього під оболонкою модуля. Модуль у цьому підході набуває роль основного конструктивного елемента, що використовується для синтезу та розробки нових систем.

Специфічні особливості модуля полягають у наступному:

1) модуль — це програмна одиниця, що автономно компілюється;

2) інформаційні та керуючі зв’язки між модулями вимагають використання у його описі декларацій, які в сукупності визначають оболонку модуля, що регламентує такі зв’язки;

3) складання програмної системи з модулів пов’язана з окремим технологічним етапом — компонуванням (лінківкою) програми. Правила такого компонування повністю визначаються системою модульних оболонок.

Концепція оболонки реалізується деклараціями імпорту/експорту, які регламентують, які об’єкти, визначені всередині модуля, можна використовувати «за його межами». Подібні декларації можуть бути оформлені у різних видах. У Модулі-2, наприклад, для цього використовується спеціальний вид опису модуля — так звана специфікуюча оболонка (оболонка визначень, DEFINITION MODULE). У цій оболонці перераховуються об’єкти, що експортуються з модуля, і специфікуються методи їх використання (фактично, дії над об’єктами). Причому, специфікація процедурних методів проводиться на рівні програми, що використовує модуль (споживача), якому надаються тільки заголовки процедур для роботи з експортованими об’єктами, але не програми їх реалізації. Наприклад:

DEFINITION MODULE A;

EXPORT QUALIFIED B, C, D;

TYPE B;

VAR C: B;

PROCEDURE D(C:B);

END A.

У цьому прикладі дозволено використання «за межами» модуля A трьох визначених у ньому програмних об’єктів: типу, змінної С і процедури D.

Концепція модуля як програмного еквівалента класу об’єктів передбачає використання його як визначника власної (індивідуальної) алгебри: безлічі можливих об’єктів та дій над ними. Така концепція має на увазі, що в модулі визначається абстрактний тип та методи — процедури, що маніпулюють з об’єктами цього типу. У цьому стиль програмування, орієнтованого на об’єкти, рекомендує експортувати межі модуля лише тип і процедури — створення об’єктів цього має проводитися поза модулем — экспортеpа. Попередній приклад щодо цього порушує такий стиль, дозволяючи експорт змінної C.

Такі стильові особливості експорту визначаються такими міркуваннями. Адже змінна C у наведеному прикладі – власна (внутрішня) змінна модуля A, розміщена у його статичній пам’яті. Чи можна змінювати значення цієї змінної за межами модуля? Чи це не відповідає загальним «життєвим» уявленням про експорт? І взагалі, що можна робити із змінною C за межами модуля? Якщо будь-що, то який сенс заводити C у модулі А? Якщо події над C внутрі A регламентовані процедурами A, то доцільно експортувати лише такий регламент, тобто. процедури. У будь-якому випадку змінна, визначена в одному модулі і використовується в іншому, набуває характеру змінної, що розділяється — з нею можуть працювати програми, визначені в різних модулях і, можливо, написані різними людьми. Звичайно, існують ситуації, коли від такого експорту неможливо або недоцільно відмовлятися, але погодьтеся, що в деяких випадках він може бути схожим на експорт верстатів, які використовуються як металобрухт.

Для ідентифікації «своїх» та «чужих» об’єктів (що належать іншому модулю) можуть використовуватися дві форми імпорту/експорту: кваліфікований та некваліфікований. Перша форма пов’язана з використанням ключового слова QUALIFIED у пропозиції експорту і дозволяє звертатися до об’єктів, що експортуються, тільки за їх «внутрішнім» ім’ям, без префіксації ім’ям модуля-експортера. Друга форма не вимагає використання цього ключового слова, але коректна ідентифікація об’єктів, що експортуються, у цьому випадку завжди пов’язана з префіксацією. Наприклад, для використання змінної C за межами специфікуючої оболонки, визначеної вище для модуля A, у разі кваліфікованого експорту досить простого іменування C, а при некваліфікованому експорті пов’язано з використанням префіксованого імені AC

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

Закритий експорт забороняє використання будь-яких операцій над об’єктами, що експортуються, крім тих, які визначені в модулі-експортеpі. У цьому сенсі закритий експорт — це «експорт сировини», «споживчих продуктів» тощо.

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

DEFINITION MODULE SINCHRON;

EXPORT QUALIFIED SIGNAL, SEND, WAIT;

TYPE SIGNAL;

PROCEDURE SEND (VAR S: SIGNAL);

PROCEDURE WAIT (VAR S:SIGNAL);

END SINCHRON.

Закритість експорту в цьому модулі дозволяє його розглядати як повністю інкапсульоване визначення абстрактного типу (алгебри) синхронізуючих сигналів. Всі іманентні властивості об’єктів-сигналів приховані від користувача (в реалізуючій оболонці модуля — IMPLEMENTATION) і лише два методи (SEND та WAIT) винесені на експорт. Закритість експорту дозволяє над будь-якими сигналами, визначеними поза SINCHRON, виконання лише двох дій: SEND та WAIT; використання для цього будь-яких інших процедур та/або операторів мови неможливе.

Реалізують визначення та іманентні властивості класу SIGNAL, визначені в модулі IMPLEMENTATION, уточнюють визначення сигналу SIGNAL = POINTER TO PASPORT (див. pазд.VII) та визначають всі деталі роботи з об’єктами цього типу.

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

                           ----¬
               --------->--+ A ¦
               ¦           LTTT-
               ¦   ----->----¦L---<----¬
               ¦ --+-¬     --^-¬     --+-¬
               ¦ ¦ B ¦     ¦ C +-->--+ D ¦
               ¦ L-T--     LT-T-     L-T--
               ¦   ¦        ¦ ¦        ¦
               ¦ --+-¬      ¦ ¦        ¦
               L-+ E +-->---- ¦        ¦
                 L-T--        ¦        ¦
                   L----<-----+---------
                         -----^---¬
                         ¦ SYSTEM ¦
                         L---------

Тут головний модуль A використовує модулі B, C, D, E та системний модуль SYSTEM. Стрілки показують напрямок експорту програмних об’єктів, інкапсульованих у відповідних модулях. Структура зв’язків на цій ілюстрації характеризується наявністю базових модулів (з них стрілки тільки виходять), модулів верхнього рівня (він тут один — A), в які стрілки тільки входять, шляхів між базовими і верхніми модулями (SYSTEM ), (SYSTEM-CDEBA і т.д.) та петель (CDEC).

Незважаючи на те, що наявність петель, взагалі кажучи, не є фатальним при компонуванні моделі A з модулів нижніх рівнів, проте «розв’язка» таких петель пов’язана з деякими проблемами. Реалізаційно і технологічно вони вирішуються коректним конструюванням послідовності декларацій імпорту в модулі A. Методологічно ж будь-яка петля відбиває неякісну декомпозицію завдання, непродуману ієрархію понять і методів, пов’язаних з її рішенням. У цьому плані краща схема імпорту-експорту повинна ґрунтуватися на виділенні програмних шарів, починаючи з базового рівня і закінчуючи верхнім, предметно-орієнтованим пакетом прикладних програм. При цьому напрямок стрілок експорту має бути тільки знизу-вгору від базового шару до верхніх і, зрозуміло, петлі повинні бути виключені.

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

Висновок

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

Даний посібник, присвячений окремим аспектам об’єктно-орієнтованого підходу, має фактично одну мету — сформувати у читача загальне уявлення про парадигму абстрагування, використовуючи для цього уявлення і термінологію об’єктно-орієнтованого підходу. Посібник, зрозуміло, не вичерпує всіх питань і не висвітлює всіх тонкощів програмування, орієнтованого на об’єкти. Більше того, при написанні цього посібника автор навмисне не орієнтувався на конкретну об’єктно-орієнтовану мову (наприклад, Smalltalk). Такий підхід визначається тим, що специфіка реалізації, термінології і методології використання конкретної мови завжди затушовує інтуїтивні, абстрактні початки в процесі розробки програм, відриває користувача від звичних категорій непрограмування і підготовка психологічний і стратегічний процес. У цьому сенсі автор вважав для себе важливим «зламати» такий бар’єр, показавши читачеві, що інтуїтивно легко відчувається категорія об’єкта є абсолютно природною для програмування, «вбирає» в себе всі аспекти процесу структурування і в цьому плані логічно розвиває і доповнює засобами абстрагування.

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

© Реферат плюс