Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляетмодульностьи чистые интерфейсы. Другая точка зрения подчёркиваетинкапсуляцию— невозможность увидеть и ещё менее изменить внутреннюю структуру детали. Ещё одна точка зрения отмечаетнаследованиеи сопутствующую емуиерархическуюструктуру классов с виртуальными функциями. И ещё один взгляд: важнейшей являетсясильная абстрактная типизация данныхвместе с гарантиями, что конкретный тип данных будет обрабатываться только применимыми к нему операциями.
В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция.
Почему объектно-ориентированная технология медленно развивалась?В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку вThe C++ Report , даёт такое объяснение:
Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как « связанный список » вместо « интерфейс пользователя », или « луч радиации », или « модель из конечных элементов ». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких. [110]
Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путём подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы:
Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека; их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция даёт и маленькую выгоду.
Дэвид Парнас, чья статья была одним из источников идей объектно-ориентированного программирования, смотрят на вещи по иному. Он писал мне:
Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определённого инструмента. Любыми срадствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдёт в моду.
Расходы сейчас, прибыль потом.По моему мнению, у объектно-ориентированных методологий особенно тяжёлый случай болезни, характерной для многих усовершенствований в методологии. Весьма существенны предварительные издержки — в основном, чтобы научить программистов мыслить совершенно по новому, а также на преобразование функций в обобщённые классы. Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении.
Коггинс коворит: «Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.» [111]
Рисковать реальными начальными деньгами ради предполагаемых, но неопределённых прибылей в будущем — это то, чем инвесторы занимаются изо дня в день. Однако во многих программирующих организациях менеджерам требуется для этого смелость — качество более редкое, чем компетенция в технических вопросах или административное мастерство. Я полагаю, что крайняя степень авансироания расходов и откладывания прибыли является самым существенным фактором, замедляющим принятие О-О технологий. Но даже в таких условиях C++, похоже, уверенно вытесняет C во многих организациях.
Что с повторным использованием?
Лучший способ справиться с разработкой части программной системы, относящейся к её сущности — это вообще её не разрабатывать. Пакеты программ — один из способов сделать это. Другой способ — повторное использование. Действительно, одной из наиболее привлекательных черт объектно-ориентированного программирования является обещание простоты повторного использования классов в сочетании с лёгкостью настройки благодаря наследованию.
Как часто бывает, после получения некоторого опыта работы по новой технологии обнаруживается, что она не так проста, как казалось на первый взгляд.
Конечно, программисты всегда повторно использовали собственные разработки. Джонс пишет:
У наиболее опытных программистов есть свои личные библиотеки, позволяющие им при разработке новых программ повторно использовать до 30% кода по объёму. На корпоративном уровне повторное использование приближается к 75% по объёму и требует специальных библиотек и администрирования. Повторное использование кода в корпоративных масштабах требует изменений в бухгалтерии проекта и методах измерения работы. [112]
У. Хуан (W. Huang) предложил организацию программного производства с матричной структурой управления функциональными специалистами, чтобы держать под контролем их естественную склонность к повторному использованию собственного кода. [113]
Ван Шнайдер (Van Snyder) из JPL напоминает мне, что в кругах разработчиков математического программного обеспечения существует давняя традиция повторного использования программ:
Мы полагаем, что препятствия к повторному использованию возникают не со стороны производителя, а со стороны потребителя. Если разработчик программного обеспечения — потенциальный потребитель стандартных программных компонентов — считает, что найти и проверить нужный компонент дороже, чем написать его заново, значит, будет написан новый компонент, дублирующий прежний. Обратите внимание, мы сказали «считает» — реальная стоимость повторной разработки не имеет значения.
Повторное использование кода имеет успех при разработке математических программ. Причин этому две: 1) это магия, требующая огромного интеллектуального вклада в каждую строчку кода, и 2) существует богатая и стандартная терминология, а именно — математика, для описания функциональности любых компонентов. Поэтому повторно разработать математический компонент стоит дорого, а разобраться в функциональности стоит дёшево. Давняя традиция публикации и сбора алгоритмов профессиональными журналами и предложения их по умеренной цене, а также коммерческое предложение высококачественных алгоритмов по несколько более высокой, но всё же скромной цене, делают поиск требуемых компонентов проще, чем в других областях, где часто невозможно точно и сжато описать требуемое. Благодаря совместному действию этих факторов повторное использование математических программ более привлекательно, чем повторное их изобретение.