Monday, July 15, 2013

The Trouble with Objects

When I discovered objects in the early '80s my mind was blown away. This was a technology that felt right, it gave me a way to think about my software that I utterly missed in structured programming. My career in the 90's centered around helping companies getting started with objects. Objects had clearly won, it was a run race. Lately, however, I have been getting more and more doubts.
The unique selling points of objects is that the data can change while the behavior remains the same (or at least backward compatible) via its public interface. If the world is the process then this is a great model. However, with 10Gb ethernets and larger, larger problems, cheaper computers, the world of a program is no longer a process: You are building distributed systems.
Distributed systems exchange information. In Java an attempt was made to preserve the object oriented semantics by not only communicating the data, but also sending the classes. However, ensuring that each system would use the correct class version and maintaing security turned quickly into a quagmire except for the simplest of systems. And even if it does work, it excludes any non-Java participant from collaborating. It is not that the OO community did not get any warning signals. The object oriented impedance mismatch with relational databases shows, at least in retrospect, that hiding your data while persisting it is not an option. At the time, we thought this was a problem that would solve itself when object oriented databases were ready (any day now!). Alas, they largely ran into the same problem that ensuring that the classes that read/wrote the data were of the same or compatible version was hard, if not impossible in many cases.
Looking at Java (and non-Java) persistence solutions I was ran into JOOQ, a library that declares peace between Java and SQL. Instead of abstracting it, it provides a type safe, fluid builder, way to use relational databases. It gave up on abstracting the database but it seems to have won a lot in simplicity and exploiting the powerful relational model. I cannot but wonder if all those abstractions to make the life of the application developer easier are in the end worth the increased complexity. Would it be worth to create a small, pet clinic like, OSGi application that would use all these different persistence models?

1 comment:

  1. OO was supposed to be a universal tool for everything at the time it was hyped, just like XML was, shortly after OO (remember SOAP, or worse, UDDI?), or JSON shortly after XML (when will this JavaScript bomb explode?). People will always try to find the Paradigm-To-Rule-Them-All, just to find themselves with more impedance mismatches again.

    OO is particularly tenacious, as it shipped with "Design Patterns" that introduce an awful amount of complexity to simple problems. One example is the Visitor Pattern, which is misused so often by Architecture Astronauts.

    It's nice to see that jOOQ is referenced as a possible way to bring back simplicity and clarity to people who know their tools (Java and SQL)