Надо признать, входной порог использования ООП оказался гораздо выше, чем предполагалось в 1980–90-х гг. С учётом девальвации среднего уровня знаний «прогрессивных технологий», меняющихся по законам бизнеса ква-зимонополий, и прибывающих выпускников трёхмесячных курсов этот порог ещё и растёт с каждым годом.
Практика подтвердила, что технология, будучи обёрнутой в относительно безопасные языковые средства и жёсткие стандарты, допускает применение в больших проектах. С другой стороны, немалое число крупных проектов принципиально не используют ООП, например, ядро операционной системы Linux, Windows API или движок Zend уже упоминавшегося PHP. Язык C по-прежнему занимает первое место согласно статистике активности сообществ программистов[44], стабильно опережая второго лидера Java – например, индексы ноября 2012 показывают 19 % против 17 %.
Разумнее предположить, что реальную отдачу от ООП вы получите, только создав достаточно хорошие модели предметных областей. То есть тот самый минимально необходимый словарь и язык вашей системы для выражения её потребностей, доступный не только современным Пушкиным от программирования. Модели будут настолько простыми и ясными, что их реализация не погрузит команду в инфернальные нагромождения шаблонных конструкций и непрерывный рефакторинг, а фреймворки будут легко использоваться прикладными программистами без помощи их авторов. Правда, тогда неизбежно встанет вопрос о необходимости использования ООП…
Осталось решить небольшую организационную задачу: где в некритичном проекте автоматизации «отдела Х» найти бюджет на компетентного системного аналитика, технического архитектора и ведение хотя бы минимального набора проектной документации.
ORM, или объектно-реляционный проектор
Сокрытие базы данных, или Как скрестить ежа с ужом
Упомянув один из крупнейших столпов современного софтостроения – мир ООП, нельзя обойти вниманием и другой – мир реляционных баз данных. Я намеренно вставил прилагательное «реляционные» применительно ко всем основным СУБД[45], хотя ещё в 1970-х годах такое обобщение было бы неправомерным.
Тем не менее именно реляционным СУБД удалось в 1980-х годах освободить программистов от знания ненужных деталей организации физического хранения данных, отгородиться от них структурами логического уровня и стандартизованным языком SQL[46] для доступа к информации. Также оказалось, что большинство форматов данных, которыми оперируют программы, хорошо ложатся на модель двумерных таблиц и связей между ними. Эти два фактора предопределили успех реляционных СУБД, а в качестве поощрительной премии сообщество получило строгую математическую теорию в основании технологии.
