There are millions of programmers and trillons of lines of code out there that use Java, but as Java is an All-purpose language, most of the code produced is procedural redump of what people did when they used C or Fortran.

I came up with a short-list of sanity checks that I use to benchmark my designs.

1. No public method shall return null, this applies also to protected methods of non-final classes
2. Never pass this as an argument
3. Getters and Setters are evil
4. A public method shall be declared by an interface (sometimes an abstract class is sufficient and more convenient)
5. No switch / if-else if on class invariants (this includes instanceof)
6. A class shall be either (conceptually)final or abstract
7. No method declares a foreign exception (I am OK with some checked exceptions from the java* packages)
8. An object that can be passed back to the API shall be immutable or a Builder
9. Prefer delegation over inheritance (this makes 6. reasonable)
10. The class skeleton shall fit on a single page, as do all methods (including the private methods that are used by a single method only)
11. The number of ctors shall be much smaller than the number of instance methods
12. All statics are in enums

This is no style-guide (most of them are a waste of time with as little impact as knowledge is required to contribute), this is what I distilled out of code that pleases me and that really works and has been proven to be maintainable and easy to integrate.
To be continued / comments and suggestions are welcome.

Actually I know of style-guide that focussed on more than indentation and the placement of whitespace: JSF air vehicle C++ coding standards

Update: I started some explainatory notes on each topic (1-6,10,11 for the moment) under Design Rules

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 »

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 »

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*.

*Please note:

…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:-)