ВУЗ:
Рис. 6.6. Диаграмма взаимодействий для простой ролевой игры
Поэтому в объектно-ориентированной системе большинство межмодульных связей имеет форму связей, устанавливаемых
между объектами, которые, как правило, реализуются как связи по управлению. Таким образом, обращение к объекту с за-
просом о выполнении некоторого задания является, по существу, запросом о выполнении некоторого метода (процедуры)
внутри объекта. Поэтому такой запрос вызывает передачу управления объекту аналогично тому, как управление передается
вызываемой процедуре при императивном подходе.
Один из способов представления связей между объектами в объектно-ориентированном проектировании состоит во
внесении информации в диаграмму классов в целях построения диаграммы взаимодействий, которая, по существу, является
диаграммой классов, показывающей, как различные объекты системы взаимодействуют друг с другом. Простая диаграмма
взаимодействий для нашей ролевой игры (с использованием обозначений языка UML) представлена на рис. 6.6. На ней пока-
зано, что объект класса Room может послать сообщение объекту класса PlayerRecord, предлагая ему обновить значение сче-
та, а объект класса PlayerRecord может послать сообщение объекту класса Room, запрашивая у него сведения об очередном
помещении.
Независимо от типа связей, программисту следует стремиться к тому, чтобы они были явно видны в конечной версии
программы. Скрытая связанность называется неявной и приводит к множеству ошибок в программном обеспечении. Обычно
образование неявных связей происходит при использовании глобальных данных – элементов данных, которые автоматически
доступны всем модулям системы. В отличие от них, локальные данные доступны только внутри определенного модуля, если
они не пересылались другому в явной форме. В большинстве языков высокого уровня существуют методы реализации как
глобальных, так и локальных данных.
Связность элементов модуля. Почти столь же важной задачей, как минимизация связей между модулями, является
достижение максимальной внутренней связности элементов внутри каждого модуля. Термин связность (cohesion) относится
именно к этим внутренним связям или, другими словами, к степени взаимосвязанности внутренних частей модуля. Чтобы
убедиться в важности понятия связности, необходимо выйти за рамки процесса первоначальной разработки системы и обра-
титься ко всему жизненному циклу программного обеспечения. Если возникает необходимость внести изменения в модуль,
то существование множества разнообразных действий внутри него может существенно усложнить процесс, который в про-
тивном случае мог бы оказаться совсем простым. Следовательно, помимо поиска любых возможностей уменьшить связыва-
ние отдельных модулей, разработчики программного обеспечения должны стремиться к достижению самого высокого уров-
ня связности элементов внутри каждого модуля.
Самая слабая форма связности – логическая связность. Этот тип связности внутри модуля строится на том, что его
внутренние элементы выполняют действия, сходные по своей логической природе. Например, рассмотрим модуль, осущест-
вляющий все связи системы с внешним миром. "Клеем", скрепляющим элементы такого модуля, является то, что все дейст-
вия внутри этого модуля так или иначе относятся к обмену информацией с внешним миром. Однако назначение такого об-
мена в каждом конкретном случае может сильно отличаться. Например, одни действия могут быть связаны с получением дан-
ных, а другие – с выдачей сообщений об ошибках.
Более сильная форма связности – функциональная связность; она означает, что все части модуля собраны вместе для
выполнения одних и тех же действий. Модуль SimulateGreatHall, показанный на рис. 6.3, нельзя считать функционально
связным, если он содержит сведения, необходимые для создания изображения на экране большого зала замка, представления
всех связанных с этим залом задач и обработки ответных действий игрока. Однако если эти детали локализованы в других
модулях и используются модулем SimulateGreatHall в качестве абстрактных инструментов, то каждый этап работы этого мо-
дуля можно рассматривать в общем контексте наблюдения за действиями игрока, связанными с большим залом замка. В
этом случае модуль SimulateGreatHall выглядит более функционально связным.
В объектно-ориентированном проектировании объекты в целом обычно являются только логически связными, так как мето-
ды внутри объектов зачастую выполняют слабо связанные действия. Единственное, что объединяет все методы объекта, –
это то, что они выполняют эти действия с одним и тем же объектом. Например, в нашей ролевой игре каждый объект поме-
щения будет, вероятно, содержать метод для создания изображения этого помещения наряду с методами, необходимыми для
представления связанных с ним задач и получения ответа игрока. Следовательно, каждый такой объект представляет собой
лишь логически связный модуль. Однако разработчики программного обеспечения должны стремиться делать каждый метод
внутри объекта функционально связным. Другими словами, даже если объект в целом является всего лишь логически связ-
ным, каждый метод внутри объекта должен выполнять всего лишь одну функционально связную задачу (показано на рис.
6.7).
Страницы
- « первая
- ‹ предыдущая
- …
- 147
- 148
- 149
- 150
- 151
- …
- следующая ›
- последняя »
