ВУЗ:
Составители:
Рубрика:
10
1. НАДЕЖНОСТЬ И КОРРЕКТНОСТЬ КОДА
Что надо делать для создания корректного и устойчивого программного
продукта?
Как минимум, необходимо:
• создать надежный код, корректность которого предусматривается с само-
го начала;
• отладить этот код;
• предусмотреть в нем обработку исключительных ситуаций.
1.1. Создание надежного кода
Большинство вопросов, затрагиваемых в этом пособии, в том числе и
проблемы создания надежного кода, заслуживают отдельного и глубокого рас-
смотрения. Поэтому приведем для введения лишь ряд тезисов.
Для повышения надежности нужно уменьшить сложность системы, и
главное в этом процессе – это повторное использование. В идеале большая
часть системы должна быть собрана из уже готовых компонентов. Объектная
технология проектирования вносит свой вклад в повышение надежности кода.
Наследование и универсализация позволяют, не изменяя уже существующие
классы, создать новые классы, новые типы данных, придающие проектируемой
системе новые свойства при минимальных добавлениях нового кода. Статиче-
ский контроль типов позволяет выявить многие ошибки еще на этапе компиля-
ции. Динамическое связывание и полиморфизм позволяют автоматически
включать объекты классов-потомков в уже существующие схемы работы – ме-
тоды родителя могут вызывать методы потомков, ничего не зная о появлении
этих новых потомков. Автоматическая сборка мусора позволяет снять с разра-
ботчика обязанности управления освобождением памяти и предотвратить появ-
ление крайне неприятных и опасных ошибок, связанных с некорректным уда-
лением объектов.
Крайне важную роль в создании надежного кода играют спецификации
методов класса, класса в целом, системы классов. Спецификации являются ча-
стью документации, встроенной в проект, и вообще важной его частью. Их су-
ществование облегчает не только создание корректного кода, соответствующе-
го спецификации, но и создание системы тестов, проверяющих корректность
кода. Нужно сказать, что существуют специальные инструментальные средства,
поддерживающие автоматическое создание тестов на основе спецификаций.
Незаменима роль спецификаций на этапе сопровождения и повторного исполь-
зования компонентов. Невозможно повторно использовать компонент, если у
него нет ясной и полной спецификации.
Страницы
- « первая
- ‹ предыдущая
- …
- 8
- 9
- 10
- 11
- 12
- …
- следующая ›
- последняя »
