Модели реализации объектно-ориентированных программных систем - Сцепление объектов |
Страница 20 из 26
Сцепление объектов
В классическом методе Л. Констентайна и Э. Йордана определены шесть типов сцепления, которые ориентированы на процедурное проектирование [77]. Принципиальное преимущество объектно-ориентированного проектирования в том, что природа объектов приводит к созданию слабо сцепленных систем. Фундаментальное свойство объектно-ориентированного проектирования заключается в скрытости содержания объекта. Как правило, содержание объекта невидимо внешним элементам. Степень автономности объекта достаточно высока. Любой объект может быть замещен другим объектом с таким же интерфейсом. Тем не менее наследование в объектно-ориентированных системах приводит к другой форме сцепления. Объекты, которые наследуют свойства и операции, сцеплены с их суперклассами. Изменения в суперклассах должны проводиться осторожно, так как эти изменения распространяются во все классы, которые наследуют их характеристики. Таким образом, сами по себе объектно-ориентированные механизмы не гарантируют минимального сцепления. Конечно, классы — мощное средство абстракции данных. Их введение уменьшило поток данных между модулями и, следовательно, снизило общее сцепление внутри системы. Однако количество типов зависимостей между модулями выросло. Появились отношения наследования, делегирования, реализации и т. д. Более разнообразным стал состав модулей в системе (классы, объекты, свободные функции и процедуры, пакеты). Отсюда вывод: необходимость измерения и регулирования сцепления в объектно-ориентированных системах обострилась. Рассмотрим объектно-ориентированные метрики сцепления, предложенные М. Хитцем и Б. Монтазери [38].
Зависимость изменения между классами
Зависимость изменения между классами CDBC (Change Dependency Between Classes) определяет потенциальный объем изменений, необходимых после модификации класса-сервера SC (server class) на этапе сопровождения. До тех пор, пока реальное количество необходимых изменений класса-клиента СС (client class) неизвестно, CDBC указывает количество методов, на которые влияет изменение SC. CDBC зависит от: q области видимости изменяемого класса-сервера внутри класса-клиента (определяется типом отношения между CS и СС); q вида доступа СС к CS (интерфейсный доступ или доступ реализации). Возможные типы отношений приведены в табл. 14.3, где п — количество методов класса СС, — количество методов СС, потенциально затрагиваемых изменением.
Таблица 14.3. Вклад отношений между клиентом и сервером в зависимость изменения
Конечно, здесь предполагается, что те элементы класса-сервера SC, которые доступны классу-клиенту СС, являются предметом изменений. Авторы исходят из следующей точки зрения: если класс SC является «зрелой» абстракцией, то предполагается, что его интерфейс более стабилен, чем его реализация. Таким образом, многие изменения в реализации SC могут выполняться без влияния на его интерфейс. Поэтому вводится фактор стабильности интерфейса для класса-сервера, он обозначается как к (0 < k < 1). Вклад доступа к интерфейсу в зависимость изменения можно учесть умножением на (1 - k). Метрика для вычисления степени CDBC имеет вид: ; CDBC(CC, SC) = min(n, A). Пути минимизации CDBC: 1) ограничение доступа к интерфейсу класса-сервера; 2) ограничение видимости классов-серверов (спецификаторами доступа public, protected, private).
|