На этом шаге рассмотрим очередную составную часть объектной модели - модульность.
В некоторых языках программирования, например в Smalltalk, модулей нет, и единственной физической единицей декомпозиции является класс. Во многих других языках, включая Object Pascal, C++ и Ada, модуль — это самостоятельная языковая конструкция, позволяющая создавать комплексы отдельных проектных решений. В этих языках логическую структуру системы образуют классы и объекты. Она помещается в модули, из которых состоит физическая структура системы. Это свойство особенно полезно в крупных системах, состоящих из многих сотен классов.
Модульность — это разделение программы на фрагменты, которые компилируются по отдельности, но связаны между собой. Связи между модулями — это их предположения о работе друг друга. В большинстве языков, поддерживающих принцип модульности как самостоятельную концепцию, интерфейс модуля отделен от его реализации. Таким образом, можно утверждать, что модульность и инкапсуляция тесно связаны между собой. Модули служат физическими контейнерами, содержащими классы и объекты, возникающие при логическом проектировании системы.
Разработчик, решающий небольшие задачи, может описать все классы и объекты в одном модуле. Однако при создании большинства программ (кроме самых простых) лучше объединить логически связанные классы и объекты, оставив открытыми лишь те элементы, которые нельзя скрывать от других модулей.
В традиционном структурном проектировании модульность, как правило, проявляется в группировке подпрограмм по логическим группам на основе критериев связности и целостности.
В объектно-ориентированном программировании модульность имеет несколько иной характер, поскольку она предусматривает физическую упаковку классов и объектов, существенно отличающихся от подпрограмм.
Структура каждого модуля должна быть достаточно простой для понимания, допускать независимую реализацию других модулей и не влиять на поведение других модулей, а также позволять легкое изменение проектных решений. На практике эти принципы реализуются лишь частично.
Изменяемые детали системы следует скрывать в отдельных модулях. Открытыми следует оставлять лишь элементы, обеспечивающие связь между модулями, вероятность изменения которых крайне мала. Все структуры данных в модуле должны быть закрыты. Они могут оставаться доступными для процедур внутри модуля, но должны быть недоступными для всех внешних подпрограмм. Доступ к информации, хранящейся внутри модуля, должен осуществляться с помощью вызова процедур данного модуля. Иначе говоря, следует создавать цельные (объединяющие логически связанные между собой абстракции) и слабо связанные между собой модули.
Таким образом, можно сформулировать следующее определение. Модульность — это свойство системы, разложенной на цельные, но слабо связанные между собой модули.
Итак, принципы абстракции, инкапсуляции и модульности являются синергетическими. Объект позволяет определить четкие границы отдельной абстракции, а инкапсуляция и модульность создают барьеры между абстракциями.
Разделение системы на модули имеет два дополнительных аспекта. Во-первых, поскольку модули, как правило, являются элементарными и неделимыми структурными элементами программного обеспечения и могут использоваться в приложениях неоднократно, разделение программы на модули должно допускать повторное использование кода. Во-вторых, многие компиляторы создают отдельные сегменты кода для каждого модуля. Следовательно, могут возникнуть физические ограничения на размер модуля. Динамика вызовов подпрограмм и размещение объявлений внутри модулей могут существенно влиять на локальность ссылок и на управление страницами виртуальной памяти.
Выявление классов и объектов, с одной стороны, и организация их в виде отдельных модулей, с другой стороны, - это практически независимые проектные решения.
Идентификация классов и объектов представляет собой часть логического проектирования системы, а идентификация модулей — часть ее физического проектирования. Разумеется, невозможно полностью осуществить логическое проектирование системы до реализации физического проектирования, и наоборот. Два этих процесса носят итеративный характер.
На следующем шаге рассмотрим пример модульности.
