Согласно одному из взглядов на объектно-ориентированное программирование эта дисциплина осуществляет модульность

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

В настоящее время не нужен весь пакет Smalltalk или C++, чтобы использовать любой из этих дисциплин — многие из них поглотили объектно-ориентированные технологии. Объектно-ориентированный подход привлекателен, как поливитамины: одним махом (т.е. переподготовкой программиста) получаешь все. Очень многообещающая концепция.

Почему объектно-ориентированная технология медленно развивалась? В течение девяти лет после выхода «СПН» надежды неуклонно росли. Почему развитие было таким медленным? Теорий много. Джеймс Коггинс, в течение четырех лет ведущий колонку в The C++ Report, дает такое объяснение:

Проблема в том, что программисты, работающие в ООП, экспериментировали с кровосмесительными приложениями и были нацелены на низкий уровень абстракции. Например, они строили такие классы, как «связанный список» вместо «интерфейс пользователя», или «луч радиации», или «модель из конечных элементов». К несчастью, строгая проверка типов, которая помогает программистам C++ избегать ошибок, одновременно затрудняет построение больших объектов из маленьких. [21]

Он возвращается к фундаментальной проблеме программирования и доказывает, что один из способов удовлетворить потребность в программном обеспечении — увеличить численность образованной рабочей силы путем подготовки и привлечения наших клиентов. В пользу нисходящего проектирования приводятся такие аргументы:

Если мы проектируем крупные классы, представляющие концепции, с которыми наши клиенты уже работают, то они в состоянии понимать и критиковать проект по мере его развития, а также вместе с нами разрабатывать контрольные примеры. Офтальмологов, с которыми я работаю, не волнует организация стека; их волнует описание формы роговицы с помощью полиномов Лежандра. Маленькая инкапсуляция дает и маленькую выгоду.

Дэвид Парнас, чья статья была одним из источников идей объектно-ориентированного программирования, смотрят на вещи по иному. Он писал мне:

Ответ прост. Это из-за привязанности ООП к сложным языкам. Вместо объяснения людям, что ООП является видом проектирования, и вооружения их принципами проектирования, их учили, что ООП — это использование определенного инструмента. Любыми срадствами можно писать и плохие, и хорошие программы. Если не учить людей проектированию, то языки не имеют большого значения. Результатом будут плохие разработки с помощью этих языков и малая выгода. А если выгода невелика, то ООП не войдет в моду.

Расходы сейчас, прибыль потом. По моему мнению, у объектно-ориентированных методологий особенно тяжелый случай болезни, характерной для многих усовершенствований в методологии. Весьма существенны предварительные издержки — в основном, чтобы научить программистов мыслить совершенно по новому, а также на преобразование функций в обобщенные классы. Выгоды, которые я считаю реальными, а не чисто предположительными, достигаются во время всего цикла разработки, но настоящая окупаемость происходит при разработке последующих программ, расширении и сопровождении. Коггинс коворит: «Объектно-ориентированное программирование не ускорит разработку первого проекта, так же как и второго. А вот пятый проект из того же семейства будет сделан очень быстро.»