Skip to end of metadata
Go to start of metadata

Least surprise, least paranoia

Authors: Dan North, Aslak Hellesoy

Imagine a software system where there is no need for you to spend your time programming defensively; your objects will be used responsibly, and your methods will always be passed sensible arguments.

This low-friction utopia can be approached by establishing some simple programming rules so that every class acts as a 'good citizen' in the society of classes collaborating at runtime.

This page outlines some rules that we, and others, believe lead to good citizenship. All are aimed at improving clarity, reducing surprise, and promoting basic consistency.

As a good citizen, I...

  • Keep a consistent state at all times - init() or populate() is a code smell.
  • Have no static fields or methods
  • Never expect or return null.
  • FailFast - even when constructing.
  • Am Easy to test- all dependent object I use can be passed to me, often in my constructor (typically as Mock Objects).
  • Accept dependent object that can easily be substituted with Mock Objects (I don't use Concrete Class Dependency).
  • Chain multiple constructors to a common place (using this(...)).
  • Always define hashCode() alongside equals()
  • Prefer immutable value objects that I can easily throw away.
  • Have a special value for 'nothing' - e.g. Collections.EMPTY_SET.
  • Raise checked exceptions when the caller asked for something unreasonable - e.g. open a non-existant file.
  • Raise unchecked exceptions when I can't do something reasonable that the caller asked of me - e.g. disk error when reading from an opened file.
  • Only catch exceptions that can be handled fully.
  • Only log information that someone needs to see.

Classes that are designed for Constructor Injection are better citizens than those that are not.

Labels:
  1. Feb 24, 2004

    I think having no static methods is extreme - aren't static helpers useful in some cases? What's not acceptable are static methods or object state, as explained in the singletons page.

  2. Mar 04, 2004

    Static methods are a problem for testing, because you can't mock them out. Also, you can 'extend' them to take advantage of polymorphism.

  3. Apr 17, 2004

    I like the rules on exceptions, and they're stated well. I also like the null pointer idea. But what happens if you have a bad citizen? Just like in real life, one bad citizen can wreck havoc in the entire system. So this seems a bit of Utopia to me. Any way to enforce it short of throwing bad citizens in jail (which obviously doesn't work)?

  4. Jun 12, 2007

    Good list guys!  I stumbled on this looking for opinions on extreme IOC via setter injection and init() style methods on the one hand and consistent objects that fix their invariants at construction time as finals on the other.  I'm obviously more of a proponent of the latter style, espcially after having read the recommendations made in the excellent Java Concurrency In Practice.

    Just one thing, I also happen to think that the restriction on statics is a step too far... and perhaps the authors do too as they advocate Collections.EMPTY_SET as good practice (wink)

    Cheers,
    Christian