Data-Orientation versus Object-Orientation
Java is obsessed with objects, so if you want to manipulate some data you first create a data access object to represent it, fill it in, and then send it along the wire. Better still, you teach the object to serialize and deserialize itself, and now you can just interact with the data through Plain Old Java Objects!
Now some editorializing: That is completely insane.
Sure, if that’s what you’re used to, it will make more sense to you, but your data is data on both ends of this process, and there’s great effort in the middle to essentially create a little proprietary DSL with which to manipulate these DAOs. In other words, you’re doing unnecessary work to make it less generally accessible for the time while it’s being handled by your program. Why not just leave it as data, and manipulate it directly?
It’s a language thing. Object-oriented languages put heavy emphasis on objects, which are suitable for modeling components and processes, and a terrible for modeling data. Data-oriented languages (like Clojure) try to ensure whenever possible that data remains data, in a format common to practically all libraries. There isn’t a separate DSL for each type of datum, so you can reuse the same functions over and over again on all data that comes to you, easily and generically.
Lastly, I understand that the desire to transform data into objects also stems from the desire to strongly type data. This is understandable, but I beleive also misguided. The very reason we may feel the need to impose a type system upon data is that it didn’t contain the type information in the first place. Which means the data itself isn’t strongly typed when it comes in, and it isn’t strongly typed when it goes out. We should avoid pretending that it obeys a rigid model for the sake of API evolution and interoperability. There are other ways to do validation and coercion of data, and schemas aren’t just for object-oriented models.
comments powered by Disqus