A Funny Java Flavoured Look at the World

Thursday, June 15, 2006

Constructor Initialization is the way to go

I read this article tonight on Martin Fowlers blog about ConstructorInitialization.


I have recently been favoring making objects immutable by passing in the variables the object needs and then only supplying getter methods for the variables. These objects are usually data objects used to pass around data fields that are related.

It was since using the final variable more and reading Effective Java where it recommends you make objects Immutable as often as possible. I agree with this logical because a lot of the time once you have set the values you don't really ever need to change them again, so why do you need to supply setter methods. Not to mention that setter methods increases the chance of passing in null values.

The article does state this as a reason for using this method
"Constructor initialization is the approach where you try to ensure that you always create a class in a valid state by passing in all the collaborators that the object needs in the creation method of the object."
It does also have the benefit of creating thread safe objects. It seems odd really that so much documentation talks about encapsulation and telling everyone to put getter and setter methods around their private variables but you rarely here of them saying, create the class, initialize it with variables and then don't let them change it, put only getters in. I think they should, I think people should think about whether they will need to change an objects state (internal variables) at a later date and if they don't then don't put the setter methods on there.

I view this decision a bit like making variables private which is hide as many variables as you can, the less developers can see and change the internal workings of your class the less likely they are to break it and find/create a bug.


  • Josh Bloch made an interesting update to the approach of making immutable objects at the latest JavaOne. Look for the talk with Effective Java in the name or something like that.

    Anyway, the idea is to be able to get immutable objects without unwieldy constructors or factory methods of so many parameters.

    By Anonymous Anonymous, at Thu Jun 15, 08:21:00 pm 2006  

  • Using constructor-based initialization over method-based was motivated in my project by what you pointed out explicitly gratefully, namely thread-safety!

    Instead of writing in a method:

    if (myHandler == null) {
    myHandler = new MyHandler();

    I just have to simply create the object in the constructor (or maybe inline) and don't have to worry about anything, including threads.

    Great remark!

    By Anonymous Klaus Meffert, at Fri Jun 16, 12:04:00 pm 2006  

  • Thread safety is one of the benefits from immutable objects. It also means you don't have to worry about validating the values in the class except in the constructor.

    It's certainly something I consider doing when creating objects.

    By Blogger Hosky, at Fri Jun 16, 09:28:00 pm 2006  

  • Making objects immutable is actually more then just providing no setters. Image a getter that returns a list ... the caller easaly can modify the content of that list.

    With that in mind you again need to take care of multi-threading issues, cause even if you return the list in a imutable-wrapper, while creating that another thread could modify it.

    By Anonymous Anonymous, at Fri Jun 23, 04:36:00 pm 2006  

  • immutable objects create GC pressure, think ahead.

    By Anonymous Anonymous, at Fri Jun 23, 08:15:00 pm 2006  

Post a Comment

<< Home