ООП умерло? Да здравствует ООП!

На заре программирования, в 1960-х годах, компьютеры были довольно слабыми. Поэтому требовалось как-то делить их вычислительные ресурсы между данными и задачами.

Проблема заключалась в том, что тогда нельзя было обработать большой объём данных, не загрузив компьютер до предела его возможностей. А если нужно было решать много разных задач, то каждая могла работать лишь с данными небольшого объёма, иначе компьютер считал бы вечно.

И вот в середине шестидесятых Алан Кэй предложил идею автономных мини-компьютеров, которые бы обменивались не данными, а сообщениями. Так вычислительные мощности можно было бы делить гораздо эффективнее.

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

ООП правит бал сорок с лишним лет. Однако в последние годы эту парадигму всё чаще критикуют. Возможно ли, что технологии попросту её переросли?

Так ли глупо объединять данные и методы?

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

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

У современного ООП есть и другие важные принципы, которые не входили в изначальную идею. Это наследование и полиморфизм.

Наследование означает, что разработчики могут определять подклассы, которые обладают всеми свойствами, присущими родительскому классу. Эта концепция возникла в 1976 году, спустя десятилетие после появления объектно-ориентированного программирования.

Ещё через десять лет в ООП пришёл полиморфизм. В общих чертах он означает, что метод или объект могут быть шаблонами для других методов и объектов. По сути, это более универсальное понятие, чем наследование, потому что новой сущности можно передавать не все свойства исходного метода или объекта, переопределять их по необходимости.

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

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

Проблема хрупкого базового класса

Допустим, вы повторно использовали класс из прежнего проекта. Что произойдёт, если его базовый класс изменится?

Испортиться может весь ваш код, даже тот, который никто не менял. Ещё вчера производные классы работали как часы, но сегодня всё сломалось. А просто кто-то внёс незначительное изменение в базовый класс, и это оказалось критичным для целого проекта. Называется такое проблемой хрупкого («незащищённого») базового класса.

Решение использовать класс повторно кажется быстрым и эффективным, но в перспективе может обойтись слишком дорого. Иными словами, чем чаще пользуешься наследованием, тем тяжелее поддерживать работоспособность кода.

Проблема ромбовидного наследования

Наследование — мягкое и пушистое, когда мы берём свойства одного класса и передаём его другим. А если нужно смешать свойства двух разных классов?

Увы, просто и элегантно это сделать не получится.

Например, у нас есть класс Copier. Он описывает копировальный аппарат, который сканирует документ и печатает его на чистом листе.

Вопрос: подклассом чего Copier должен быть — сканера (Scanner) или принтера (Printer)?

Верного ответа просто не существует. Это называется проблемой ромба. Да, код она не ломает, но обескураживает разработчиков часто.

Проблема иерархии

Вопрос выше заключался в том, чей наследник класс Copier. А с ответом я вас обманул: из той ситуации можно выйти изящно. Делаем Copier родительским классом, а Scanner и Printer — подклассами, которые наследуют только подмножество свойств. Вуаля!

Здорово, конечно. Но что, если Copier у нас чёрно-белый, а Printer умеет печатать в цвете? Разве Printer в этом смысле не более общее понятие для Copier? И что делать, если Printer должен подключаться к Wi-Fi, а Copier нет?

Чем больше свойств добавляется в класс, тем сложнее установить правильную иерархию. В этом примере мы имеем дело с наборами свойств Copier и Printer — среди них есть как общие, так и уникальные. Если попытаться выстроить такие классы в линейную иерархию наследования (особенно в крупном и сложном проекте), то это чревато проблемами. Потому что выбрать родителя из Copier, Printer и Scanner не выходит.

Проблема ссылки

Столкнувшись с проблемой иерархии, вы можете решить: окей, займёмся
ОО-программированием в чистом виде — без всяких иерархий. Попросту будем использовать наборы свойств и наследовать их, расширяя или переопределяя когда нужно. Выйдет немного путано, но решение это вполне жизнеспособно, разве нет?

Увы и ах, но нет. Тут возникает иная сложность. Весь смысл инкапсуляции — в том, чтобы обрабатывать данные более эффективно, защищая их друг от друга. А без строгой иерархии это невозможно.

Допустим, объект A должен взаимодействовать с объектом B. Какие у них отношения — значения не имеет, важно лишь, что A не прямой потомок B.

Объект A включает в себя ссылку на B, иначе они не смогли бы взаимодействовать. Но если A содержит данные, доступ к которым также есть у дочерних элементов B, то получается, что эти данные можно изменить сразу из нескольких мест. Таким образом, данные в объекте B больше не защищены — инкапсуляция нарушена.

И хотя многие ОО-разработчики создают продукты именно с такой архитектурой, это уже не ООП, а попросту бардак.

Опасность одной парадигмы

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

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

Очевидно, что функциональное программирование набирает обороты, тогда как ООП в последние годы сдаёт позиции, его резко критикуют.

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