Inspired by some sessions at the TSSJS, I spent some thought on the "old school" object oriented design programming model. It appears to me that, although we are all using object oriented languages like Java, the core idea of object orientation has somewhat failed without anybody actually admitting it. Here are the arguments that should make you think about it:
- The original idea (at least how it is introduced to beginners) of OO is to create real-life "stuff" in software, like a library, books, etc. - nowadays referred to as the domain model. In reality, the domain model is often less than 10-20% of your codebase - the major part are "abstract" infrastructure elements like facades, notifiers, providers, factories, services, etc. Although people will argue that these also have an equivalent in the real-world, one cannot really disguise the very technical concepts that lie within them, which seem to be rather forced into an OO shape.
- For many people it has become a best practice to design an anemic domain model. This really makes objects lifeless as all logic is taken away from them and they degrade to pure data containers.
- From other classes that still contain logic, AOP tries to squeeze out the cross-cutting pieces, like logging, transaction handling, etc. This functionality is then instead kept in aspects (does anybody really dare to call them objects?) that are attached to the outside of the objects like contagious pimples. (Don't get me wrong - I like the idea of AOP very much!)
- Having internal states of objects results in a bad memory footprint, so to be scalable we prefer having stateless services without any internal state.
- Passing objects via method invocation might work for some internal classes, but on the SOA-enabled systems, we are passing XML data structures to remote stateless services.
- Public constructors are outdated, better use factories instead, or - even better for decoupling - a Spring container that handles this for you.
- The object-relational mapping stays a nightmare, despite Hibernate and JPA. JDBC result sets still appear to be an adequate solution, especially if one only needs a few fields from a long list of records.
- Business logic as the core part of the software needs to be quickly adaptable to new business requirements. Therefore it is taken out from the objects and moved somewhere else, e.g. in a rule repository (e.g. VisualRules, jRules or any kind of script) where it can be replaced or updated without recompilation and redeployment. Another option is to call it service orchestration and call global functions (web services) in a procedural manner driven by a BPEL file.