Примерно в то же время в сообществе начались дискуссии, появились первые публикации вроде уже ставшей классической «Почему объектно-ориентированное программирование провалилось?»[41]. Эксперты по ООП в своих книгах стали нехотя писать о том, что технология тем эффективнее, чем более идеален моделируемый ею мир.
Рис. 3. Эмпирическое сравнение производительности процедурно-реляционного и объектно-ориентированного подходов в зависимости от достигнутой степени формализации моделируемого мира
Действительно, вспомним ещё раз Smalltalk. Его концепции выросли из задач построения графического интерфейса пользователя. Взглянув на любой оконный фреймворк, вы увидите искусственный мир, идеальный с точки зрения его авторов. Многоуровневые иерархии классов не воссозданы многолетним трудом классификации объектов окружающего мира, а выращены в виртуальных пробирках лабораторий разработчиков.
Учебники по ООП полны примеров, как легко и красиво решается задачка отображения геометрических фигур на холсте с одним абстрактным предком и виртуальной функцией показа. Но стоит применить такой подход к объектам реального мира, как возникнет необходимость во множественном наследовании от сотни разношёрстных абстрактных заготовок. Объект «книга» в приложении для библиотеки должен обладать свойствами «абстрактного печатного издания», в магазине – «абстрактного товара», в музее – «абстрактного экспоната», в редакции, типографии, в службе доставки… Можете продолжить сами.
Попытки выпутаться из этой ситуации за счёт агрегации приводят к новым дивным мирам, существующим только в воображении разработчиков. Теперь объект «книга» это контейнер для чего-то продающегося, выдаваемого, хранящегося и пылящегося. Необходимо быстро менять контекст: в магазине вкладывать в книгу товар, в библиотеке – печатное издание, в отделе «книга-почтой» – ещё какую-нибудь хреновину. Плодятся новые многоуровневые иерархии, но теперь уже не наследования (is a), а вложения (is a part of).
Изящнее выглядят интерфейсы. Но если в реальном мире книга, она и в музее – книга, то во вселенной интерфейсов «книга в музее» – неопознанный объект, пока не реализован соответствующий интерфейс «экспонат». Дальше интерфейсы пересекаются, обобщаются, и мы получаем ту же самую иерархию наследования, от которой сбежали. Но теперь это уже иерархия, во-первых, множественная, а во-вторых, состоящая из абстрактных классов без какой-либо реализации вообще (интерфейс, по сути, есть pure abstract class). Если же мы отказываемся от обобщения интерфейсов, то фактически оказываемся в рамках современных реализаций модульного программирования типа Оберон[42].
Тем не менее все три подхода применимы и могут дать хороший результат при высокой квалификации проектировщиков и наличии проработанных моделей предметной области.
Одна из причин подобных злоключений в том, что концепции, выдвигаемые ООП, на самом деле не являются его особенностями за исключением наследования реализации от обобщённых предков с виртуализацией их функций. И по несчастливому стечению обстоятельств именно наследование реализации является одним из основных механизмов порождения ада наследуемых ошибок, неявных зависимостей и хрупкого дизайна. Все остальные концепты от инкапсуляции и абстракции до полиморфизма имеются в вашем распоряжении без ООП. Полиморфизм с проекциями вместо таблиц наличествует даже в SQL.
Мой субъективный опыт подтверждает, что за исключением фреймворков весьма абстрактного уровня, сделанных «с чистого листа» небольшими группами профессионалов высокого класса, Объектно-Ориентированный Подход на практике в большинстве случаев превращает проект или продукт, переваливший за сотню-другую тысяч строк, в упомянутый Ад Паттернов, который, несмотря на формальную архитектурную правильность и её же функциональную бессмысленность, никто без помощи авторов развивать не может.
С другой стороны, любая неясность в постановке задачи вынуждает разработчиков сосредотачиваться не на её решении, а на архитектуре, позволяющей «без особых затруднений» менять логику приложения и переходить с расчёта зарплаты колхоза на прогноз удоев фермы.
Результат неизменно стабильный…
Особо хочу остановиться на тезисе уменьшения сложности при использовании ООП для создания фреймворков. Современное состояние дел – это платформа. NET с примерно 40 тысячами классов и типов ещё в версии 3.5. Вдумайтесь, вам предлагают для выражения потребностей прикладного программирования язык с 40 тысячами слов, без учёта глаголов и прилагательных, называя такую технологию упрощением.
Александр Сергеевич Пушкин использовал в своем творчестве порядка 24 тысяч слов. Толковый словарь Ожегова содержит около 70 тысяч слов. Среднестатистический русский человек использует в повседневной жизни от 5 до 10 тысяч слов[43], из них только 3 тысячи являются общеупотребительными. Получается, что даже наследник гения Пушкина способен охватить менее половины предлагаемой технологии, при том что её словарь сравним с естественным языком!
Примечания
1
Электронная Вычислительная Машина, вдруг кто забыл, как назывались компьютеры в русском языке.
2
Числовое Программное Управление.
3
Научно-Исследовательский Институт.
4
Конструкторское Бюро.
5
Конструкторско-Технологический Центр.
6
Вычислительный Центр.
7
Высшие учебные заведения.
8
Неформальное название учебных заведений.
9
Оригинальное немецкое название: Bedingungsloses Grundeinkommen.
10
Вычислительный Центр Коллективного Пользования.
11
Центр Обработки Данных (англ. Data Center).
12
«With today's news, the companies are reinforcing their commitment to the Java community, which comprises more than six million developers worldwide» // IBM Taps Boom in Linux Growth by Expanding Commitment to Partners, Linux and Open Source, december 2005.
13
От англ. framework. В рамках объектно-ориентированного подхода – библиотека классов с двусторонним (взаимным) управлением потоком исполнения программы. Более общее значение – каркас, предоставляющий стандартные службы, библиотеки и компоненты для разработки программ в рамках накладываемых им ограничений.
14
От англ. mainframe – классическая большая универсальная ЭВМ.
15
Коэффициент интеллекта (англ. intelligence quotient).
16
От англ. «reverse engineering» – восстановление общих проектных решений и концепций по имеющейся частной их реализации.
17
Англ. Drag and drop.
18
Международный стандарт, регламентирующий кодификацию валют.
19
Грабли – синоним скрытой ошибки в программе. «Наступить на грабли» в программистском фольклоре означает выявить скрытую проблему за собственный счёт.
20
SSIS – SQL Server Integration Services, служба управления пакетами обработки данных, внешних по отношению к СУБД. По сути, среда для быстрой визуально-скриптовой разработки программ-конвертеров данных.
21
От английского «Business Intelligence» – служба предприятия, занятая аналитической обработкой данных.
22
Возможность разделения визуальной части и бизнес-логики по разным файлам. Одна из ключевых концепций в ASP.NET.
23
От англ. «MVC, Model-View-Controller» – концепция построения приложений графического интерфейса пользователя. Развитие концепции, полностью исключающее связь модели и вида – MVP, Model-View-Presenter.
24
От английского термина «applet» – приложеньице.
25
«Java Runtime Environment is found on over 700 million personal computers», пресс-релиз Sun, 2007.
26
«Java runs on more than 850 million personal computers worldwide, and on billions of devices worldwide», пресс-релиз Oracle, 2011.
27
От англ. RIA – Rich Internet Applications.
28
«In Q1 2005 48 % of business PCs ran Windows 2000, 38 % ran Windows XP», исследование AssetMetrix, 2005.
29
Windows Presentation Foundation – технология Microsoft построения Windows-приложений с богатыми возможностями отображения информации и графики.
30
От англ. unicode – международный стандарт кодирования символов, позволяющий представить знаки практически всех известных алфавитов, включая иероглифы.
31
American Standard Code for Information Interchange – американская стандартная таблица кодов печатных символов.
32
См. пресс-релиз компании Microsoft «Our strategy with Silverlight has shifted».
33
В языке C нет понятия модуля, поэтому этот показатель несколько ниже.
34
Ф. Брукс описывает софтостроение по принципу «операционной бригады» в своей книге «Мифический человеко-месяц»[0].
35
Rational Unified Process – итеративная тяжеловесная методология софтостроения от компаний Rational и IBM.
36
От англ. design pattern – шаблон проектирования.
37
От англ. refactoring – реструктуризация и факторизация программного кода. В экстремальных методиках при отсутствии концепции системы и анализа предметной области формально требуется постоянный рефакторинг кода, при помощи которого предполагается чудесным образом прийти к хорошему решению ничего не проектируя.
38
Термин широко используется в автоматизации предприятий и происходит от «лоскутного одеяла» – разрозненного набора программ и пакетов, решающих локальные задачи подразделений.
39
API (Application Programming Interface) – интерфейс программирования приложений, функциональность, которую предоставляет модуль, компонент или библиотека программисту.
40
От англ. openspace – большое офисное помещение, зал без перегородок с расположенными в нем рабочими местами.
41
См. публикацию «Objects Have Failed» (2000 г.) и материалы конференции OOPSLA (Object-Oriented Programming, Systems, Langauges and Applications) по данной теме в 2002 г.
42
Оберон – семейство языков программирования высокого уровня, разработанных Никлаусом Виртом и его школой.
43
Объем активного словаря образованного человека оценивается в среднем в 5–10 тысяч слов. «Сколько слов в русском языке?», Наука и жизнь, 2004, № 11.