Me interesó esta página de StackExchange donde se debate sobre reescribir un código de programación estructurada en programación orientada a objetos.
Transcribo los comentarios mas llamativos (corresponden a diferentes comentadores):
The question is: do you expect further development? Procedural programming is the easiest and fastest approach when you know EXACTLY what you need and it’s not going to change. Any change to procedural code will be pain, in OOP it would be much easier.
…
There are loads of problem domains which should never be expressed in terms of OOP.
…
My general take on paradigms (and why none of the three major paradigms is the right way or the wrong way to program):
Procedural programming is good when you have a problem that’s simple at a high level (though it may be complex at a low level) and want to write correspondingly simple, linear code. It’s arguably easier to write and understand than OO and functional if the problem isn’t in need of strong decoupling anywhere. Examples: Numerics code, most small scrips, most small subproblems once you’ve broken things down using OO or functional.
Object oriented code is good when you need to strongly decouple concerns because you may have more than one implementation of some concerns. Example: Most large business software. You may, for example, want to strongly decouple business logic from presentation logic because they probably will need to change independently.
Functional-style programming is good when you need strong separation of mechanism from policy. Having a mechanism function that accepts a policy function is a nice pattern. (I learned about it by looking at the D programming language’s std.algorithm module.) Abstracting away mutable state at the boundary between policy and mechanism code generally makes the API easier to reason about. If mutable state is used privately in either, this is an implementation detail. Functional programming’s other strength is concurrency, for self-evident reasons.
Los comentarios comparten el punto de vista de que OOP está sobrevalorado, no aplica a todos los casos y en general es un error empezar un proyecto con este paradigma sólo porque se supone que es la opción correcta o un paradigma de resolución general de problemas. Quizás OOP no sea un paradigma general de resolución de problemas, y sólo sea buena idea aplicarlo a ciertos casos, donde el dominio o modelo de negocios encaja bien con OOP, y donde hay grandes posibilidades de reusar código o de reimplementar el código en otros proyectos en el futuro.
Java vs C# 