Хабрахабр

Про ООП

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

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

Следующее

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

ООП

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

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

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

Итого

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть