April 23rd, 2006
This is somewhat a follow up to my blog on (non-reusable) components. I advocated there small components with simple interfaces that get tied together to implement the actual feature.
On DI and how to implement this much had been written, so the composition and the necessary techniques are common.
The communication among the components is less stamdardized and becomes quite a problem when dealing with many components.
The component technology du jour is SOA. SOA is using BPEL in an Orchestration manager to define and execute a complex operation. As a backbone of SOA WebServices get mentioned the most (there are other options). So what the orchestration-manager practically does is sending SOAP-Messages to different machines and collecting the results, to form new call and so on. When you keep all messages send, you can replay them eventually to duplicate the process.
This is very interesting for the analysis of errors. A complex business-function uses millions of lines of code and you have to have a tool to replay the action to see what happened and what exactly went wrong. The hardest bugs are the phantoms, the bugs you cannot reproduce but keep popping up at you customer. Read the rest of this entry »
April 9th, 2006
The C++ folks complain about a feature Java is lacking, the “constness”.
For the younger readers: The keyword const can be added to a method to make it promise not to modify the status of the object, as the same keyword for a variable means that you are only allowed to call const-methods on it.
Thus a const-type is a supertype of the type. Some types in Java are actually const: Number and String are immutable that is even stronger (they never change at all, while a const-object restricts only the reference holder to modify its state).
The Problem with Java is simple to explain: Imagine you had MutableString extends String. When implementing an interface do(String) just implementing do(MutableString) is not sufficient because there are MutableStrings that are not mutable - being plain Strings. When you design the interface of your class carefully, you can have constness: Create a const-interface and extend it by an interface defining all other methods. This is cumbersome and really hard to maintain. The implementation of a getter - see below - can call some non-const method; slicing the class creates problems down the road because of Java’s restriction to single inheritance.
My point here is that I argue that the concept of constness is of any good use in OOD at all.
Let aside the documentary benefit of a const method ( you should be concious about what a method does when you plan to use it), the const is used mainly for return-values of functions and one could view the need of const methods just a by-product of this modifier since otherwise the object at hand would be 100% useless (there are some subtleties with operator overloading, but this doesn’t apply to Java and the C++ syntax is questionable there anyway).
Read the rest of this entry »
March 27th, 2006
Just read over Kimchy’s Blog that pointed to an article by Martin Fowler which dates back to the end of 2003…
Oh my god this was definitely ahead of my time. As I started my current project I had been well aware of it (I am not sure anymore - I think I even read it shortly after it had been originally published). In fact we moved a system having an anemic domain model to a more object-oriented system (very sucessful by the way - perhaps the thing I am most proud of in my whole career).
Well I had been aware of it. Or I had been occupied by to many things at the “outer rim” to notice: Now we have “Assistants”, “BusinessProcesses” and “Calculator” that stripped out functionality from the business (or domain) objects. They now became more an more a bogus layer between the procedural code and the database*.
…which typically results in a whole layer of O/R mapping. This is worthwhile iff you use the powerful OO techniques to organize complex logic
“Iff” means “if and only if” - so you should employ OO-techniques to do the mapping and not only for the sake of having a mapping layer. In a non-trivial application you will have the need for it so plan for, do not take it too lightly
… the last sentence is perhaps the obligatory detail where I disagree with Martin:-)