Чем ООП опасно при решении оптимизационных задач. Люблю с разработчиком спорить насчет ООП в жизни. Я сам как-то проехал мимо и не очень люблю. Хотя понимаю, что штука полезная. И есть куча задач, где это прямо то, что надо. Но вот оптимизационные задачи не попадают в это место. При этом сам код, который решает задачу и обвязка вполне могут и должны быть ООП. Проблема возникает, если программист начинает решать в императивном стиле и саму задачу. А это неосознанное решение, которое задает стеклянный потолок для решения. В простых случаях это прокатывает, а более сложных приходится постоянно чинить решение. Под императивным стилем решения я имею в виду следующую схему. Сгенерировали примерное решение, оно где-то некорректное. В одном месте поправили, сломали в другом, чиним второе место сломали в третьем. И надеемся что процесс сойдется. Вспоминается анекдот "Хармса": Однажды у Ф. М. Достоевского засорилась ноздря. Стал продувать — лопнула перепонка в ухе. Заткнул пробкой — оказалась велика, череп треснул. Связал веревочкой — смотрит, рот не открывается. Тут он проснулся в недоумении, царство ему небесное. Рецепт от этого следующий. Автор системы должен владеть не только парадигмой ООП, но и другими (ФП в первую очередь конечно). Чтобы уметь осознавать, когда он её использует, а когда нет. Человек в одной парадигме не осознает что он её использует. Мы не особо замечаем воздух, пока не попадем в воду. А еще лучше когда задачу решают не прогеры, а математики всё таки. Это меня пригласили экспертом поработать в одном проекте. Смотрю на него и немного грущу. Проект в целом живой, но на анекдот Хармса местами смахивает. И проснуться нельзя ))