* What this often means, in practice, is that it provides a structured way to write spaghetti code. * I've had to refactor code that my co-workers have written

* What this often means, in practice, is that it provides a structured way to write spaghetti code. * I've had to refactor code that my co-workers have written several times because they end up throwing code in a class where it works but doesn't "belong". For example, the REST API I'm building has thin controllers, thick domains, and thin data access layer with various supporting models. I had a co-worker write a Domain object that acted like a model (a single object that should be instantiated, properties set, and a calculation function run). I had to refactor all his code out into a reusable model and then build helper functions in the domain for the controller to consume. Whenever I see that I need to do the same type of operation in multiple places, it tells me that code should probably be consolidated into a structured class to make sure that any bugs in the code can be fixed in one place instead of a dozen. So in a way the code was structured in a class but was still a mess. OOP isn't just about classes and inheritance but about structure, architecture, and how classes interact with each other.