ВУЗ:
Составители:
выявляться во время компиляции программы. Вопрос реализации этих условий для
конкретных языков программирования является предметом постоянных обсуждений.
Модульность
Понятие модульности. По мнению Майерса, «Разделение программы на фрагменты
позволяет частично уменьшить ее сложность. Однако гораздо важнее тот факт, что
разделение программы улучшает проработку ее частей. Эти части весьма ценны для
исчерпывающего
понимания программы в целом». В некоторых языках
программирования, модульность не реализована и классы составляют лишь физическую
основу декомпозиции. В других языках, включая модульность является элементом
конструкции и позволяет осуществлять на ее основе проектные решения. В таких языках
классы и объекты составляют логическую структуру системы; эти абстракции
организуются в модули, образуя физическую
структуру системы. Это свойство
становится особенно полезным, когда система состоит из многих сотен классов.
По Лискову, «модульность — это разделение программы на раздельно
компилируемые фрагменты, имеющие между собой средства сообщения». Можно
использовать также и определение Парнаса: «Связи между модулями — это
предположения о возможности их использования». В большинстве языков,
поддерживающих принцип модульности
как самостоятельную концепцию, также
реализуется разделение интерфейсной части и реализации. Таким образом, модульность
и ограничение доступа идут неотделимо друг от друга.
Правильное разделение программы на модули является почти такой же сложной
задачей, как выбор правильного набора абстракций. Абсолютно прав Зелковиц,
утверждая: «поскольку в начале работы над проектом решения могут быть неясными
,
декомпозиция на модули может вызвать затруднения. Для хорошо известных
приложений (например, создание компиляторов) этот процесс можно стандартизовать,
но для новых задач (военные системы или управление космическими аппаратами) задача
может быть очень трудной».
Модули выполняют роль физических контейнеров, в которые помещаются
определения классов и объектов при логическом проектировании системы. Это такая
же
ситуация, которая возникает у проектировщиков бортовых компьютеров. Логика
электронного оборудования может быть построена на основе элементарных вентилей
типа не, и-не, или-не, но можно и объединить группы таких вентилей в стандартные
интегральные схемы, например, серий 7400, 7402 или 7404. Отсутствие
стандартизованных фрагментов дает программисту гораздо большую степень свободы —
как если бы электронщик
имел в своем распоряжении средства создания кремниевых
кристаллов.
Для небольших задач допустимо описание каждого класса и объекта в отдельном
модуле. В других, наиболее тривиальных, случаях в один модуль лучше собрать все
логически связанные классы и объекты и оставить незащищенными все те элементы,
которые должны быть видимы для всей программы. Однако
такой подход применяется в
исключительных случаях. Рассмотрим, например, задачу, которая выполняется на
многопроцессорном оборудовании и требует для координации механизма передачи
сообщений. В больших системах вполне обычным является наличие нескольких сотен и
даже тысяч видов сообщений. Было бы наивным определение каждого класса сообщений
в отдельном модуле. При этом не только возникает кошмарная
ситуация с
документированием, но чрезвычайно труден для пользователя даже просто поиск
Страницы
- « первая
- ‹ предыдущая
- …
- 22
- 23
- 24
- 25
- 26
- …
- следующая ›
- последняя »
