I’ve written previously about my dislike of the way the object initialiser is misused in C# 3.0 and although I’ve also written about my preference for explicit modeling and the need for objects to act as good citizensI’ve never quite been able to articulate what it is I dislike so much about having setter methods on objects.

I’ve learnt from experience that it leads to a world of pain in our code by having the ability to setup an object after construction using setters and in a conversation with a colleague about this last week he suggested that the reason it’s such a bad practice to follow is that it makes us lose our trust in not only that object but in all the other objects in the application.

The thinking here is that if we get caught out (usually by a null pointer exception) when using an object which wasn’t completely set up at construction then we are likely to have a seed of doubt in our mind when we come across another object as to whether the same pattern has been followed with that one - we’ve lost a little bit of our belief that we can just use this object and it will work the way we expect it to.

As a result of that loss of trust we end up spending more time looking at more implementation details of an object just to check how it has been designed to ensure that we don’t get caught out.

I don’t think this is a particularly useful way to spend our time and it also adds another thing that we have to keep in our mind when looking at code, further dragging us away from the task that we originally intended to do.

Apart from when we’re creating fluent interface style DSLs I’ve always felt more pain from using setters than I’ve gained from that so when I don’t see a good reason for them - sometimes Java frameworks might need them (thanks Dahlia!) - to exist I pretty much follow the boy scout rule and try and get rid of them.