14.2.4. Модульність

Поняття модульності. Поділ програми на модулі певною мірою дозволяє зменшити її складність. Однак набагато важливіше той факт, що всередині модульної програми створюється множина добре сформованих і документованих інтерфейсів. Ці інтерфейси необхідні для вичерпного розуміння програми в цілому. У деяких мовах програмування, наприклад в Smalltalk, модулів нема, і класи становлять єдину фізичну основу декомпозиції. В інших мовах, включаючи Object Pascal, C++, Ada, CLOS, модуль - це самостійна мовна конструкція. У цих мовах класи й об'єкти становлять логічну структуру системи, вони містяться в модулі, що утворюють фізичну структуру системи. Ця властивість стає особливо корисною, коли система складається з багатьох сотень класів.

Модульність - це поділ програми на фрагменти, які компілюються окремо, але можуть встановлювати зв'язки з іншими модулями. Зв'язок між модулями - це їхнє подання один про одного. У більшості мов, що підтримують принцип модульності як самостійну концепцію, інтерфейс модуля відділений від його реалізації. Таким чином, модульність і інкапсуляція дуже близькі між собою. У різних мовах програмування модульність підтримується по-різному. Наприклад, в C++ модулями є роздільно компілюючі файли. Для C/C++ традиційним є зберігання інтерфейсної частини модуля в окремому файлі з розширенням .h (так звані файли-заголовки). Реалізація, тобто текст модуля, зберігається у файлах з розширенням .с (у програмах на C++ часто використовуються розширення .сс, .ср і .срр). Зв'язок між файлами оголошується директивою макропроцесора #include. Такий підхід не є строгою вимогою самої мови. У мові Object Pascal принцип модульності формалізований трохи суворіше. У цій мові визначений особливий синтаксис для інтерфейсної частини й реалізації модуля (unit). Мова Ada іде ще на крок далі: модуль (названий package) також має дві частини - специфікацію й тіло. Але, на відміну від Object Pascal, допускається роздільне визначення зв'язків з модулями для специфікації й тіла пакету. Таким чином, допускається, щоб тіло модуля мало зв'язки з модулями, які невидимі для його специфікації.

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

Модулі виконують роль фізичних контейнерів, в яких містяться класи і об'єкти під час логічного проектування системи. Така ж ситуація виникає в проектувальників бортових комп'ютерів. Логіка електронного устаткування може бути побудована на основі елементарних схем типу НЕ, І-НЕ, АБО-НЕ, але можна об'єднати такі схеми в стандартні інтегральні схеми (модулі), наприклад, серій 7400, 7402 або 7404.

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

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

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

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

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

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

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

На вибір розбивання на модулі можуть впливати й деякі зовнішні обставини. Під час колективного розроблення програм розподіл роботи здійснюється, як правило, за модульним принципом й правильний поділ проекту мінімізує зв'язки між учасниками. При цьому досвідченіші програмісти звичайно відповідають за інтерфейс модулів, а менш досвідчені - за реалізацію. На більшому рівні такі ж співвідношення справедливі для відношень між субпідрядниками. Абстракції можна розподілити так, щоб швидко встановити інтерфейси модулів за згодою між компаніями, що беруть участь у роботі. Зміни в інтерфейсі викликають багато розмов і сперечань, не говорячи вже про величезну витрату паперу, - всі ці фактори роблять інтерфейс вкрай консервативним. Що стосується документування проекту, то він будується, як правило, також за модульним принципом - модуль служить одиницею опису й адміністрування. Десять модулів замість одного потребують у десять разів більше описів, і тому, на жаль, іноді вимоги з документування впливає на декомпозицію проекту (у більшості випадків негативно). Можуть позначатися й вимоги таємності: частина коду може бути несекретною, а інша - секретною; остання тоді виконується у вигляді окремого модуля (модулів).

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

Приклади модульності. Подивимося, як реалізується модульність у гідропонній городній системі. Припустимо, замість закупівлі спеціалізованого апаратного забезпечення, вирішено використовувати стандартну робочу станцію із графічним інтерфейсом користувача GUI (Graphical User Interface). За допомогою робочої станції оператор може формувати нові плани вирощування, модифікувати наявні плани й спостерігати за їхнім виконанням. Тому що абстракція плану вирощування - одна із ключових. Створимо модуль, що містить всі ці операції стосовно плану вирощування. На C++ нам буде потрібний приблизно такий файл-заголовок (нехай він називається gplan.h).

// gplan.h

#ifndef _GPLAN_H

#define _GPLAN_H 1

#include "gtypes.h"

#include "except.h"

#include "actions.h"

class GrowingPlan ...

class FruitGrowingPlan ...

class GrainGrowingPlan ...

#endif

Тут ми імпортуємо у файл три інших заголовних файли з визначенням інтерфейсів, на які будемо посилатися: gtypes.h, except .h і actions.h. Власне код класів ми помістимо в модуль реалізації, у файл із ім'ям gplan.cpp.

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

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