Про ООП

Чем больше читаю про ООП, тем больше возникает ощущение, что ООП понимают не только лишь все. Очередная статья этому пример ^[1].

Тут можно долго расписывать нелепость аргументаций в приведенной выше статье. Но в целом, всю статью можно перечеркнуть буквально следующим.

Следующее

С ростом сложности софта возникла потребность в изоляции сложности, разбитии ее на части. Просто порубить на части не получится, т.к. возникнет проблема соединения частей. И тут умные люди придумали: а давайте изолируем части так, чтобы была важна внешняя часть, а не то, как это внутри устроено. Т.е. не надо думать о механизмах, надо думать о контрактах.

ООП

Именно это называется ООП, и именно изоляция сложности привела, в каком-то смысле, к революции, т.к. стало возможным писать гораздо более сложные программы.

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

То, во что превратилось ООП сегодня, является следствием непонимания целей разработки софта: борьба со сложностью. Так уж получилось, что мозг ^[2] не вмещает все аспекты и части системы, мы можешь лишь держать малую часть. Поэтому борьба со сложностью и есть драйвер и мотивация для создания новых парадигм. Более того, это может являться критерием правильности выбора парадигмы: насколько просто и понятным оказывается итоговый код.

Итого

Итак, главное в программировании — это не использование новомодных или старомодных практик, а корректный контроль сложности в каждой части системы.

Автор: Григорий Демченко

Источник ^[3]