Object-oriented programming, or OOP, is a programming paradigm that uses “objects” – usually instances of a class – consisting of data fields and methods together with their interactions – to design applications and computer programs.
In practical terms, to build a program, you define objects that contain data and expose operations (called methods). A typical, boring-to-death example is a Car class, with a Color property and TurnEngineOn() and TurnEngineOff() operations.
This model, despite being used by most software developers, has something wrong in an increasing number of scenarios. Take web applications: you usually have a model layer that represents – or models – the information that the application handles, and then you have a business logic layer, often implemented as a set of controllers. You see, each data class exposes properties, but no methods. Each controller exposes methods but very little, if any, properties. It’s still OOP, but it’s starting to look like something different.
When you work with distributed/parallel architectures this phenomenon gets even worse, as you have classes that only do data/events/jobs storage, classes that only implement business logic, and classes that only hold data (aka entities). In a way, each single piece is simpler to allow scalability, entities become read-only to avoid side-effects in parallel environments and there are huge blocks of code loading-crunching-saving data.
I suspect that most OOP goes into building frameworks (.NET, Java, RoR, etc.), and we just leverage them to build not-so-OO programs.
I don’t have a solution for this – I’m not sure it actually needs a solution (functional languages anyone?) – but when your only tool is a hammer, everything looks like a nail.