Nathalie spent a huge amount of time going through the very creative process of trying out the wildest shapes, discarting them all and finally coming up with a very nice and pure new logo for RIFE.

Tell us what you think.

For a long time I have been coding the tests of the code I write through deducation and analysis of testworthy situations. About a year ago I started looking into Clover as a coverage tool and shivered with horror after the first runthrough. Here I thought that almost everything was thoroughly tested and I only got 70% coverage! So I began to spend time getting that percentage higher by writing testcode for every expression that Clover marked as untested. To ensure that I don't have to do this afterwards for new developments I started

I used to write a collection of constructors when a class could be instantiated in a variety of ways. An important amount of time was spent selecting sensible combinations of constructor arguments to make them easy to use and as readable as possible.

Recently however, I started to work differently since I noticed that complex constructors always end up becoming mysterious. Without looking at the javadocs it's often difficult to understand what each argument stands for.

Consider this example class:

public class Constraint
{
    private String     mName = null;
    private boolean    mNotNull = false;
    private boolean    mNotEmpty = false;
    
    public Constraint(String name, boolean notNull, boolean notEmpty)
    {
        mName = name;
        mNotNull = notNull;
        mNotEmpty = notEmpty;
    }
}

One would create an instance of Constraint like this:

Constraint constraint = new Constraint("name", true, false);

When you re-read this statement afterwards, you immediately start to wonder which properties the true and false relate to. Was is first notNull and then notEmpty, or was it the other way around?

Now consider this alternative implementation:

public class Constraint
{
    private String     mName = null;
    private boolean    mNotNull = false;
    private boolean    mNotEmpty = false;
    
    public Constraint(String name)
    {
        mName = name;
    }
    
    public Constraint notNull(boolean state)
    {
        mNotNull = state;
        
        return this;
    }
    
    public Constraint notEmpty(boolean state)
    {
        mNotEmpty = state;
        
        return this;
    }
}

To create a instance of Constraint you would now do:

Constraint constraint = new Constraint("name").notNull(true).notEmpty(false);

This is immediately readable without any doubt or confusion. You also don't lose the benefit of being able to instantiate and setup an instance in one line.
Therefore, I now try to create as little constructors as possible. Just the bare minimum is needed to ensure that each instance receives enough information to be initialized in a usable state. All the other optional setup behaviour can be achieved through chainable setters.

You might wonder why I didn't simply change the return type of a regular setter from void to the class type. This is because the javabean spec mandates a void return type on setters. If you don't respect this, the setter will not be found through bean introspection.

Check this out: http://www.extremeironing.com

This post: "Don't be afraid to be wrong by Jim Cushing -- How fruit flies lead to a revelation about software development", is exactly how I feal about these matters. Since many years I've always taken risks and been very flexible towards design decisions and customer requests. I've had the chance to have been wrong many times and will probably be wrong many more times, and all the better! It helped me to advance quickly, to experiment, to learn, to discover, to be productive in many domains and to start my own business.

Admit that you're wrong as quickly as possible when you identify it and, more importantly, take responsability for it! Boldly fix the problems and move towards your new insights. Many small efforts like this will be bearable for your ego and still leave you with enough energy. One huge revelation in the end is often a fatal blow and difficult to accept.

When you're listening you'll feel when new insights and directions appear, be on the lookout for them, but also be alert enough to not jump on another track each time you arrive at a crossroad. When you need to decide you'll know it and the best decision will always present itself if you're patient enough to wait for the signs. It's sometimes as important to resist a temptation as it is to take another turn, but most importantly: don't be afraid since "Fear is the mind-killer" (Dune - Frank Herbert).