Бертран Мейер - Основы объектно-ориентированного программирования

Другая известная проблема - Millenium - переход компьютеров на даты нового тысячелетия.

Вопрос не в том, что некоторая часть программы знает физическую структуру данных: это неизбежно, поскольку доступ к данным необходим. Но при традиционных методах построения это знание распространяется слишком на многие части системы, приводя к неоправданно большим программным изменениям при изменении физической структуры. Другими словами, если почтовые коды изменяются с пяти до девяти цифр или даты требуют еще одной цифры, то резонно ожидать, что программа, манипулирующая кодами и датами, будет требовать адаптации. Недопустимо лишь, чтобы изменения в программе были несоизмеримы по сравнению с концептуальным размером изменения спецификации.

Теория абстрактных типов данных даст ключ к этой проблеме (Лекция 6 подробно описывает абстрактные типы данных), позволяя программам иметь доступ к данным с помощью внешних свойств, а не физической реализации.

Следующие пункты в списке Лиенца и Свонсона также интересны, но не так непосредственно связаны с темами этой книги. Аварийная отладка (производимая в спешке, когда пользователь сообщает, что программа не дает ожидаемых результатов или ведет себя катастрофически) стoит больше, чем обычные плановые исправления. Это так не только потому, что она производится в короткие сроки, но и потому, что она прерывает плановый процесс выпуска новых (безошибочных) вариантов и может дать новые ошибки.

Еще одно интересное наблюдение в распределении затрат по видам деятельности - это сравнительно низкая доля (5,5%) стоимости документации. Помните, что это - стоимость задач, решаемых в период эксплуатации. Наблюдение здесь - или скорее, догадка, при отсутствии более точных данных - таково: проект должен либо заботиться о том, чтобы создание документации стало частью разработки, либо совсем не делать этого. Мы научимся использовать стиль построения, в котором большая часть документации действительно встроена в ПО, и есть специальные инструменты для ее извлечения.

Последние два вида работ дают очень малую долю:

[x].Первый - это улучшение эффективности; похоже, предполагается, что когда система работает, менеджеры проекта и программисты неохотно прерывают ее работу с целью улучшения производительности, предпочитая не трогать довольно хорошую систему. (При рассмотрении принципа "сначала сделай ее хорошо, а потом сделай ее быстрой" многие проекты, возможно, вполне довольствуются первым шагом.)

[x].Небольшие средства тратятся и на "переход к новой аппаратной среде". Из-за отсутствия более детальных данных можно высказать лишь некоторое предположение. Все системы относятся к двум крайним случаям, промежуточные варианты практически отсутствуют. В первом случае системы изначально строятся как переносимые, и потому для них этот вид затрат невелик. Другие настолько тесно привязаны к своей первоначальной платформе и перенос был бы так труден, что разработчики даже не пытаются делать что-то в этом направлении.

[x].Целью программной инженерии является нахождение путей построения ПО высокого качества.

[x].Качество ПО лучше всего видится как компромисс между целым рядом различных целей, а не как единый фактор.

[x].Внешние факторы, понятные пользователям и клиентам, следует отличать от внутренних факторов, понятных проектировщикам и конструкторам.

[x].Действительное значение имеют внешние факторы, но управление системой возможно только через внутренние факторы, благодаря которым достигается нужный эффект.

[x].Список основных внешних факторов качества приведен выше. ОО-метод направлен на улучшение качества тех факторов, которые прежде всего нуждаются в лучших подходах. К ним относятся факторы корректности и устойчивости, связанные с безопасностью, вместе известные как надежность, и факторы, требующие децентрализованной архитектуры ПО, - повторное использование и расширяемость, вместе известные как модульность.

[x].Сопровождение ПО, потребляющее большую долю его стоимости, находится в невыгодном положении из-за трудности реализации изменений в ПО и из-за слишком большой зависимости программ от физической структуры данных, которыми они манипулируют.

В предыдущей лекции исследовались цели ОО-метода. Готовясь к чтению технических деталей метода в следующих лекциях, полезно быстро, но с широких позиций рассмотреть ключевые аспекты ОО-разработки ПО. Такова цель этой лекции. Прежде всего, здесь будет дано лаконичное пояснение того, что делает систему объектно-ориентированной. Уже в этом есть определенная польза, поскольку этот термин используется так неразборчиво, что необходим список точных свойств; имея их, мы сможем оценить метод, язык или инструмент, претендующие на звание объектно-ориентированных.

Ограничимся минимумом объяснений, поэтому при первом чтении нельзя надеяться на понимание деталей всех перечисленных критериев; объяснение их - задача остальных разделов книги. Можно считать это обсуждение предваряющим просмотром - не настоящим кино, а анонсом. В отличие от анонса, эта лекция скорее является так называемым спойлером (spoiler) - она пересказывает сюжет, нарушая порой общий план книги. Этим она отличается от других лекций, в особенности лекций 3-6, терпеливо выстраивающих объектную технологию, рассматривающих проблему за проблемой на пути к получению и обоснованию решения. Если вам нравится идея обзора, предшествующая глубокому изучению вопросов, эта лекция для вас. Но если вы предпочитаете не портить удовольствия, открывая решения одно за другим, то просто пропустите ее.

Рассмотрим выбор критериев, позволяющих оценить объектную ориентированность системы (objectness).

Список, представленный ниже, включает все свойства, кажущиеся существенными для создания высококачественного ПО ОО-методом. Наш список может показаться бескомпромиссным и даже догматичным. Какие заключения следует делать, если среда удовлетворяет некоторым, но не всем этим критериям? Следует ли считать ее полностью неадекватной?

Только вы, мой читатель, можете ответить на этот вопрос применительно к собственному контексту. Вот несколько причин, по которым может быть необходим компромисс:

[x].Быть ОО-системой - это не булево условие. Из двух сред А и В первая может быть более объектно-ориентированной, хотя и не является таковой на все 100%. Поэтому если внешние ограничения сводят ваш выбор только к А и В, следует выбрать А как наименьшее из двух зол.