Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
(Источник)
Хочу внести свои «5 копеек» в неутихающий спор противников и сторонников ООП. Из недавних публикаций на эту тему можно отметить ярко негативный заголовок «Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ», более миролюбивый «Хватит спорить про функциональное программирование и ООП» и умеренно позитивный «Объектно ориентированное програмирование в графических языках».
Но на идею этой заметки меня натолкнул комментарий к другой статье:
Отличный пример для того, что ООП — это просто ужас. Система трейтов отлично реализует ваш случай, и совершенно не требует отвечать на Экзистенциальный Вопрос Объектного Программирования — «Что Есть Объект?». [...] Забудьте про ООП, это была удачная для GUI метафора, которую попытались возвести в статус религии.
На мой взгляд, это очень показательный типичный комментарий, где критикуется не сам ОО подход (даже отдается должное ООП в GUI), но мифы, возникшие вокруг ООП. Таким образом, на мой взгляд, правы все: и сторонники, когда указывают на удобства ООП, например, при программировании GUI, и противники, когда негодуют на возведение ООП в статус серебряной пули, абсолютного оружия.
Сразу стоит отметить, что в каждом ОО ЯП свой ОО подход, иногда сильно, иногда не очень сильно отличающийся от других ОО подходов. Буду исходить из умеренного простого подхода ОО Паскаля, заложенного еще в Turbo Pascal 5.5 и окончательно оформившегося к Delphi 7 (можно отметить и близкие по концепции ЯП других производителей, например, Think Pascal для MacOS). В этом ОО подходе есть основополагающие принципы: инкапсуляция, наследование (простое), полиморфизм; и существенные ограничения: например, нет по сути очень непростого множественного наследования.
Как уже написал в комментарии к упомянутой выше статье — переход от классического Паскаля к ОО Паскалю выглядел, на мой взляд, очень наглядным и оправданным:
Простейшая инкапсуляция уже есть в записях (record). Далее понятие о наследовании приходит в таких простых примерах:
type TCoord = record // координаты точки x, y : integer end; TRect = record // прямоугольник leftTop, RBot : TCoord; end;
Остается заменить слово «record» на слово «class» (с указанием имени предка в скобках), разрешить записывать заголовки методов внутри таких «записей» и оговорить несложные правила полиморфизма.
Приведенный пример — реализация графических примитивов, это уже более широкая задача, чем задачи GUI. Здесь иерархия объектов выглядит очевидной и не возникает отмеченного выше «Экзистенциального Вопроса „Что Есть Объект?“». — Понятно, что точка — объект и прямоугольник — другой объект. Но в общем случае четко выделить объекты и расположить их в единственно правильную иерархию далеко не всегда возможно. Здесь противники ООП правы, но дело в том, что это не нужно! ОО подход часто называют модельным подходом (одним из). Основной принцип модельного подхода — моделирование не всех свойств прототипа, а только некоторых, значимых свойств для целей данной модели. Хрестоматийный пример — испытание модели самолета в аэродинамической трубе. Очевидно, что для таких испытаний не нужно делать у модели двигатели, иллюминаторы, шасси, убранные при полете в корпус и кресла в салоне, как и сам салон — достаточно выстругать эту модель из цельного куска дерева, воспроизведя только предполагаемые обводы корпуса. Такие испытания проводят не только для реальных моделей в реальной трубе, но и для виртуальных моделей в виртуальной трубе. Если реализовать виртуальное испытание с применением ООП, то принципы будут аналогичные реальным испытаниям — ненужные свойства и обекты в программу не попадут. Но если мы захотим повторно использовать код этой модели для моделирования дизайна самолета, то можем столкнуться с иерархическими проблемами при добавлении новых объектов. Является ли это недостатком именно ООП? — На мой взгляд нет: всякое моделирование сопряжено с жесткими ограничениями. Более того, для моделирования существует ряд других сложных принципиальных проблем. Подробнее см.:
Блехман И.И., Мышкис А.Д., Пановко Я.Г. Механика и прикладная математика. Логика и особенности приложений математики.
Мышкис А. Д., Элементы теории математических моделей. Изд. 3-е, исправленное. М.: КомКнига, 2007
В приведенных книгах упомянуто много источников на тему моделирования, в том числе цитируется следующий пример. Если поставить 3 табуретки друг на друга, то эта конструкция будет вполне устойчивой, чтобы водрузить на нее бумажный кубик для школьного урока рисования. Но эта же конструкция явно неустойчива, чтобы с ее помощью поменять сгоревшую лампочку. Никакая математика сделать такие выводы не сможет. Таким образом, существует не чисто математическая проблема интерпретации результатов моделирования. Эта проблема будет возникать в любой реализации модели: как с применением, так и без применения ООП. Но люди склонны к когнитивному искажению, и зачастую обвиняют инструмент-зеркало в отображении неприятной им информации ;)
В конце прошлого века всемирно известные люди Билл Гейтс, Филипп Кан, Бьёрн Страуструп, Никлаус Вирт и др., не желая того, заложили бомбу под ООП, слишком восторженно его пропагандируя. Почти все им поверили, и только сейчас наступило отрезвление. Но этот процесс отрезвления опасен другой крайностью — попытками полного отказа от зарекомендовавших себя во многих областях технологий. Только попыткой — вряд ли это возможно, хотя бы потому, что:
прежде всего забыть ООП [...] не реально, т.к. очень многие IDE имеют графические инструменты для создания GUI, и эти инструменты генерируют ОО код.
На мой взгляд, как и в случае любой модели, от модели с применением ООП не стоит ждать, что она чудесным образом раскроет все тайны мироздания. Каждая модель адекватна только в своих узких рамках: «что заложено — то и получим». При этом, согласно требованию естественно-научного подхода, каждый результат, полученный на модели, должен быть перепроверен экспериментально. Но при таких природных ограничениях существуют не всеми осознанные бонусы: к моделированию зачастую возможен примитивно-формальный подход. Так, в случае ООП не нужно пытаться вникнуть глубже возможного при определении объектов и их иерархии. (Аналогично, например, в химии: современные химики знают, что атом не шарик, а химическая связь не стержень фиксированной длины, но это не мешает им использовать шаростержневые модели и структурные формулы.) — Иерархия нужна, чтобы навести порядок в коде модели, но она никогда не будет в точности отвечать гораздо более сложному, чем всякая модель, прототипу.
