JavaBeans, immutability and constructors

Dan Moore shot me an email with a question about JavaBeans, constructors and immutability. It is something that I have been thinking about and implementing in various ways for a while because of my passion for domain modeling. My reply to Dan was one of the two ways that I prefer to implement immutability with JavaBeans. The other method, I’ll save for another entry. Here is a copy of Dan’s email and my response:

Dan’s email

Hi Brian,

I had a javabeans question and figured you’ve spent a fair bit of time wallowing in those specifications.

Does a javabean need a no arg constructor to be a proper javabean? Is this in the spec anywhere? I looked in the JAF spec and the Javabeans 1.0.1 spec, but couldn’t find anything about constructors.

Can you help me?

My response

Yeah. The spec is not exact on this because it takes into account immutable beans as well as clients instantiating beans by hand. I think the rule of thumb goes like this:

– Immutable beans are read only (only getters) and have public constructors with arguments that satisfy immutability.

– Mutable beans are read/write (getters and setters) and have public no-arg constructors.

I have found that lately my immutable beans are to restrictive for most cases and have started adding in protected no-arg constructors and protected member variables to allow sub-classes to provide mutability.

The reason I’ve started doing this is so that I can protect my domain model but allow front-ends to reuse my domain objects rather than having to copy and paste from model-beans (which I loath). For example, if I have a CD, I’d model it like this:

public class CompactDisc extends Item {
   protected String name;
   protected Artist artist;

   // Provides the ability to make mutable sub-classes
   protected CompactDisc() {}

   public CompactDisc(String name, Artist artist) { ...}

   public String getName() { ... }
   public Artist getArtist() { ... }

Now, I can use this object with something like JSF or Verge by sub-classing and using that bean on my form:

public class MutableCompactDisc extends CompactDisc {
   public void setName(String name) { ... }
   public void setArtist(Artist artist) { ... }

The downside here is that my objects are now not as safe and I haven’t defined the class or the member variables as final to model true immutability. This is a trade-off that I’m willing to make to reduce complexity and code redundancy. I think the next generation will allow immutable objects to be used with front-ends, but it hasn’t quite gotten there yet. The upside to all this is that by contract, my domain model remains immutable and as long as I code to the immutable class, I can ensure that I won’t have data-loss, or data-swapping.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s