I really like the way Bruce Richardson put it:
nobody slicing bread thinks they’re sending a message telling the knife to cut the bread or telling the bread to be sliced
OOP is about putting some awkward constraints on the way that you are allowed to use your language. Perhaps in some cases it makes sense, but in most cases it doesn’t. If OOP is about tying some actions to some objects, then if someone wants to perform some action that wasn’t anticipated by the designer, they have a problem.
Therefore OOP forces you to come up with solutions to issues that appear solely because someone decided to use the constraints of OOP in your project, like “which class should this method belong to?” (“oh I know I should create a controller class”).
I believe the only approach that actually scales is trying to express your way of thinking about problem, rather than imposing some arbitrary and artificial constraints beforehand. Solving problems that could be avoided is just a waste of time.
А речь о том, что написание красивого и понятного кода - это искусство, а не ремесло. В некоторых видео (каюсь, в основном только про Ruby) я пытаюсь донести эту мысль. Нужно немного расширить границы и делать не так, как учили (тем более, что обычно вообще никого не "учили"), а как кажется правильным. Да, потом это может оказаться неправильным и неоптимальным, но всё можно переписать. Зато в один прекрасный день вы увидите, что не ЯЗЫК управляет ВАМИ, а ВЫ управляете ЯЗЫКОМ. В конце концов, для кого вообще создавались языки программирования? Уж точно не для железки, которая понимает только нолики и единички (ну, в отдельных случаях бывает ещё троичная логика, да).
Долгое время понять это довольно сложно, потому что выход за рамки приводит к постоянно ломающимся программам - у меня так тоже было довольно долгое время. Но потом - бац - и что-то перещёлкивает, и ты смотришь на это всё несколько иначе.