Модульність

Обмеження доступу.

Абстрагування.

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

Процес захисту окремих елементів об' єкту, що не зачіпає істотних характеристик об' єкту, як цілого.

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

Існування ієрархій.

Ранжирування, впорядковування за деякими правилах об' єктів системи.

Модульність - це розподіл програми на окремо компільовані фрагменти, які мають між собою засоби зв'язку.

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

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

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

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

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

Модульність - це властивість системи, яка полягає в можливості її декомпозиції на низку тісно пов'язаних між собою модулів.

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

У процесі поділу системи на модулі можуть бути корисними два правила.

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

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

Ієрархія

Ієрархія - це ранжована чи впорядкована система абстракцій. Основні відіа ієрархічних структур стосовно складних систем такі:

Структура класів (ієрархія за номенклатурою).

Структура об' єктів (ієрархія за складом).

Приклади ієрархії

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

А. Просте успадкування.

Розглянемо, наприклад, різноманітні відіа рослин, які вирощуються в теплиці.

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

…

class StundartFruitGrowingPlan: public GrowingPlan

{

public:

StundartFruitGrowingPlan ();

StundartFruitGrowingPlan (const StundartFruitGrowingPlan &);

virtual StundartFruitGrowingPlan ();

virtual int daysUntilHarvest (day currentDay) count;

private:

day timeToHarvest;

};

Із наведеного прикладу бачимо, що клас StundartFruitGrowing - Plan точно повторює свій суперклас GrowingPlan за кількома ви-нятками. У підклас введень новий елемент структури (timeTo - Harvest), змінені конструктор та деконструктор, додана віртуальна функція (daysUntilHarvest). Використовуючи цей новий клас вже як суперклас, можна визначити ще більш спеціалізовані підкласи, наприклад для плану вирощування яблук.

Б. Множинне успадкування.

Отже, вирощування квітів, овочів та фруктів у тепличному господарстві має свою специфіку. Наприклад, для квітів важливо знаті момент зацвітання, а для фруктів - момент збору врожаю.

Щоб реалізувати зазначені вимоги, необхідно з даного класу утворити два нових класи:

FloweringPlant та Fruit/VegetablePlant.

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

Ці класи самостійні та призначені для подальшого змішування між собою з метою створення підкласів.

Дата добавления: 2013-12-14