| "Services" in the JVM, usually in the sense of Spring or some other service management framework, is just procedural code with a thing object instantiation layer which allows late binding invocations across services, which in complicated code turns out to be enormously useful: - enable/disable/manage caching layers to procedure... uh... method calls - play tricks with remote invocations that look like local ones - enable advanced testing frameworks with mocked parameters and data connections - enable/disable logging at runtime, and target specific services - "aspects" to target various patterns of invocation and inject interceptors/decorators/etc to the procedure... uh... method call. JVM service management OOP is a very different thing than domain/data object modeling OOP. JVM service management OOP is a slam dunk in terms of delivered value. In the referenced Alan Kay bullet points, it is mostly extreme late binding, and kind-of message passing that delivers tremendous value. Data modeling OOP and GUI framework OOP is the old dog is-a animal, but is-a pet and all that headache. Because Java's behavioral compositional model is basically single inheritance (yeah, there's interfaces if you want to copy-paste or write your own delegates), it is fundamentally limited. That is the OOP that has squarely and properly been questioned over the last 10 years. |