fisher (raa) wrote,
fisher
raa

Categories:

ООП



Итак, для начала необходимы некоторые мета-физические изыскания, и я очень прошу их вытерпеть - это самое важное. Я не претендую на математическую корректность изложения, но полагаю, что формализм присутствует в достаточной степени - ровно в той, чтобы не утомить (и не утомиться). Короче, возьмем класс задач такой, что любая задача может быть сформулирована в виде закона движения F(r,t). Я робко предполагаю, что большинство задач программирования под этот класс попадают. Значит, есть некое пространство возможных значений r и есть некий закон движения F, а t - время. Важно, что состояние r отделено от закона движения F. В процессе решения этой задачи, извлечения каких-то фактов, не суть - всегда r и F - разные вещи синтаксически и на самом деле. Но в реальной жизни в задачах большой размерности всегда существует какая-то возможность декомпозиции, такая, что та же задача может быть записана в виде законов движения подсистем. Любая декомпозиция снижает размерность, упорядочивает - короче, упрощает. Если есть возможность провести декомпозицию - её нужно провести. Но подсистемы вторичны. И, опять же математически, никто не гарантирует, что набор подсистем {f} через которые может быть записана первоначальная задача движения F(r,t), также сможет описать задачу движения G(r,t).

Теперь вернемся к программированию. Интуитивно мне кажется, что структурное программирование, в котором основой языка являются независимые "состояние" (переменные, или пространство значений) и "поведение" (функции, или законы движения) является более естественным с математической точки зрения. Именно потому, что нет никакой жесткой зависимости между законом движения и состоянием. Объекты же, совмещающие в себе и "состояние", и "поведение" - результат той самой декомпозиции. Объекты вторичны. Что важно - программист конструирует объекты интуитивно, как удобно, и удачная модель помимо собственно упрощения даёт ряд неоспоримых плюсов:
1) более жесткие условия на структуру кода, который становится более понятным (синтаксически нам проще читать предложение ктоТо->сделалЧтоТо(); принципиально разные проблемы "локализуются" вокруг классов и более просты для понимания)
2) повторное использование

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

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

Что из всего этого следует? Объектно-ориентированное программирование интуитивно более простое и в первом приближении даёт кучу плюсов. Однако в процессе эволюции задачи, если проект на многие человеко-годы - подход таит риски, которые, накапливаясь, могут убить проект куда быстрее, чем если бы мы использовали структурное программирование. Не говоря уж о цене ошибки дизайна, заложенной где-то изначально. И требуется довольно высокая квалификация и воля, чтобы адекватно менять проект. Я не говорю, что ООП - плохо. Просто нужно иметь это в виду. Я могу сказать, что самое мерзкое дерьмо, которое я когда либо производил в своей жизни - был херовый объектно-ориентированный код (возможно, я просто хуёво знаю парадигму и ващелох). А каждый раз, когда мой код эволюционировал от "классов" к "пакетам" (кастрированное ООП, или даже одно лишь первое "О" - объектное) - становилось всё понятнее, проще и удобнее.

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

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 28 comments