My last blog post, about pushing behaviour onto enum subclasses, got quite a few votes on dzone. Interestingly, about a third voted the post down, not up – though no-one left any comment to explain why they thought it was a bad idea.

So, here’s another example of using this technique, but from a somewhat different source. I was recently writing some code that needed some fairly standard collections manipulation, but rather than write it myself I thought I’d check out the google-collections API (now at v1.0). I remembered reading that this library has support for caching along with soft or weak references, and browsing into the source code I came across MapMaker#Strength: Read the rest of this entry →

Having seen how to teach Naked Objects to support Java 5 enums directly, let’s use this new capability to avoid inheritance hierarchies in entities using powertypes.
Read the rest of this entry →

If you’ve just stumbled across this blog and are wondering what “domain driven design” is all about, you might like to check out an article I wrote for the Methods and Tools journal. It’s downloadable in their (free) PDF magazine, and is also available online in HTML form.

Thanks to Vaughn Vernon for his time reviewing it… but any mistakes and errors are mine alone!

I’ve recently discovered javaposse.com (recommended), and was listening to an podcast from last year on the DRY principle.

One of the questions asked was: when coding in Java, where do we have to repeat ourselves? There was the usual point made about generics being overly verbose (Java 7′s diamond operator will help), but another answer came back about the repetition required in having to explicitly say that a class implemented an interface in addition to just providing an implementation of all the methods in that interface… in other words, why can’t Java support duck typing:

So, suppose:

public interface IDuck {
    public void quack(int volume);
    public void float();
}

and

public class DuckLike {
    public void quack(int volume) {  .... }
    public void float() { }
}

What our speaker wanted was to be able to pass a DuckLike object around to something that would use IDucks, without having to say class DuckLike implements IDuck:

public class DuckUser {
    public void useDuck(Object o) {
        ... use the supplied object as a duck if it quacks and floats ...
    }
}

In order to support ducktyping, note that the DuckUser#useDuck takes an Object, not an IDuck.

So, one solution that came back was a utility to automatically provide a proxy for the duckLike thing that implements IDuck if it does indeed have a suitable implementation. This proxy then delegates to the underlying duckLike. I must admit this caught my fancy so I thought I’d have a go at writing it.
Read the rest of this entry →

On the DDD newsgroup one thread started there recently asked:

Implicit concepts are an important subject in software creation. They allow for breakthroughs in hard to model systems (for example).
Did you ever use _special_ techniques to identify them? Be it via interviews, visualizations, system metaphors, code analysis or code refactoring.

It’s a good question; it’s only by identifying concepts correctly that we can hope to get a rich and useful domain model. My answer went as follows:

Read the rest of this entry →