Чем больше читаю про ООП, тем больше возникает ощущение, что ООП понимают не только лишь все. Очередная статья этому пример.
Тут можно долго расписывать нелепость аргументаций в приведенной выше статье. Но в целом, всю статью можно перечеркнуть буквально следующим.
Следующее
С ростом сложности софта возникла потребность в изоляции сложности, разбитии ее на части. Просто порубить на части не получится, т.к. возникнет проблема соединения частей. И тут умные люди придумали: а давайте изолируем части так, чтобы была важна внешняя часть, а не то, как это внутри устроено. Т.е. не надо думать о механизмах, надо думать о контрактах.
ООП
Именно это называется ООП, и именно изоляция сложности привела, в каком-то смысле, к революции, т.к. стало возможным писать гораздо более сложные программы.
Все остальное — переливание из пустого в порожнее, включая цитаты всеми известных и уважаемых людей. Проблема с ООП в том, что изначально думали про одно, но потом пришли практики и переиначили все для своих нужд, т.к. программы нужно писать не завтра или послезавтра, а сегодня. А еще лучше, чтобы вчера.
То, во что превратилось ООП сегодня, является следствием непонимания целей разработки софта: борьба со сложностью. Так уж получилось, что не вмещает все аспекты и части системы, мы можешь лишь держать малую часть. Поэтому борьба со сложностью и есть драйвер и мотивация для создания новых парадигм. Более того, это может являться критерием правильности выбора парадигмы: насколько просто и понятным оказывается итоговый код.
Итого
Итак, главное в программировании — это не использование новомодных или старомодных практик, а корректный контроль сложности в каждой части системы.
Автор: Григорий Демченко
