Чем быстрее вы откажетесь от ООП, тем лучше для вас и вашего программного обеспечения Перевод

Это перевод первых абзацев статьи Dawid Ciężarkiewicz, с его блога: противоречивые заметки о разработке программного обеспечения, взломе открытого исходного кода, криптовалютах и ​​т.д.

Объектно-ориентированное программирование — исключительно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер В. Дейкстра

Может быть, это всего лишь мой опыт, но объектно-ориентированное программирование кажется стандартной, наиболее распространенной парадигмой программной инженерии.

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

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

Данные важнее кода

По своей сути все программное обеспечение предназначено для манипулирования данными для достижения определенной цели. Цель определяет, как должны быть структурированы данные, а структура данных определяет, какой код необходим.

Эта часть очень важна, поэтому я повторюсь. goal -> data architecture -> code.

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

По моему опыту, самая большая проблема с ООП заключается в том, что она побуждает игнорировать архитектуру модели данных и применять бездумный паттерн хранения всего в объектах, обещая некоторые неопределенные преимущества. Если он выглядит как кандидат в класс, он переходит в класс. У меня есть Customer? Это входит в class Customer. У меня есть контекст рендеринга? Это входит в class RenderingContext.

Вместо построения хорошей архитектуры данных внимание разработчиков смещается на создание «хороших» классов, отношений между ними, таксономий, иерархий наследования и так далее. Мало того, что это бесполезное усилие. На самом деле это очень вредно.

Плохая производительность

Комбинация данных, разбросанных между множеством небольших объектов, интенсивное использование косвенных обращений и указателей и отсутствие правильной архитектуры данных в первую очередь приводит к низкой производительности во время выполнения. Достаточно.

Продолжение можно прочитать тут: dpc.pw