Designing object initialization

Ensure proper initialization of your objects at all times

1 2 3 Page 3
Page 3 of 3

As a C++ programmer, I encountered a class one day that had no methods and no fields -- only a constructor. In trying to determine what this constructor did, I found that it called a function that called a function that called a function, and so on. After looking through several files, I realized that instantiating an object of this class caused a file to be parsed. After that the class was useless.

Granted, this particular class was designed by someone new to object-oriented programming, but its design illustrates an important point relating to constructors and initializers in Java: constructors and initializers should be about initialization.

In a previous section of this article, I recommended that you strive to design objects that give client programmers no way to instantiate the object in an invalid state. Another way to look at this is that client programmers should not have to do anything besides invoke a constructor to get an object in a proper initial state. An object should be fully initialized by the constructors and initializers of its class.

Likewise, just as objects should not be less than initialized after a constructor invocation, they also shouldn't be more than initialized. As a general principle, constructors and initializers should do no more than bring the new object to a proper initial state. To get the object moving after construction has brought it to a proper initial state, you should require that client programmers invoke a method on the object.


Two important design guidelines this article attempts to promote are the "canonical object design" and "omni-valid state principle."

The canonical object design

An object should have state, represented by instance variables that are private. Invoking an object's instance methods should be the only way code defined in other classes can affect the object's state.

The omni-valid state principle

Objects should have a valid state, and experience only valid state transitions, from the beginning of their lifetimes to the end.

With respect to object initialization, this article suggests a number of handy guidelines:

  • The no-way-to-create-an-object-with-an-invalid-state guideline -- Design an object's initializers and constructors such that the object cannot possibly be created in an invalid state.
  • The not-natural rule of thumb -- If an instance variable doesn't have a natural default value, force client programmers to pass an initial value (or data from which an initial value can be calculated) to every constructor in the class.
  • The exceptional rule concerning bad constructor input -- Check for invalid data passed to constructors. On detecting invalid data passed to a constructor, throw an exception.
  • The valid guideline about invalid objects -- Sometimes it will make sense to design a class whose instances can, at times, be in an invalid, unusable state. For such classes, throw an exception when a method can't perform its normal duties because the object's state was invalid when the method was invoked.
  • The hold-your-horses-during-initialization guideline -- Constructors and initializers should be about initialization, the whole initialization, and nothing but initialization.

One last guideline pertains to the nature of guidelines themselves. The guidelines proposed in this column are not proposed as laws you should blindly follow at all times but as rules of thumb you'll probably want to follow much of the time. They are intended to help you acquire a mindset conducive to good design. Thus, the final guideline is:

  • The guideline guideline -- All guidelines proposed by this column should be disregarded some of the time -- including this one.

A request for reader participation

Software design is subjective. Your idea of a well-designed program may be your colleague's maintenance nightmare. In light of this fact, I hope to make this column as interactive as possible.

I encourage your comments, criticisms, suggestions, flames -- all kinds of feedback -- about the material presented in this column. If you disagree with something, or have something to add, please let me know.

Next month

In next month's Design Techniques, I'll continue this mini-series of articles focusing on designing classes and objects. Next month's installment, the second of this series, will offer field and method design guidelines. :END_BODY

ENDNOTE: The small print: "Designing Object Initialization" Article Copyright (c) 1998 Bill Venners. All rights reserved. Traffic Light Applet Copyright (c) 1998 Bill Venners. All rights reserved. :END_ENDNOTE:

Learn more about this topic

  • For the source code listings that appear in this article, see
  • Recommended Books on Java Design
  • Object Orientation FAQ
  • 7237 Links on Object-Orientation
  • The Object-Oriented Page
  • Collection of Information on OO Approach
  • Design Patterns Home Page
  • A Comparison of OOA and OOD Methods
  • Object-Oriented Analysis and Design Methodsa Comparative Review
  • Patterns-Discussion FAQ
  • Implementing Basic Design Patterns in Java (Doug Lea)
  • Patterns in Java AWT
  • Software Technology's Design Patterns Page
  • Synchronization of Java Threads Using Rendezvous
  • Design PatternsElements of Reusable Object-Oriented Software, In Java :END_RESOURCES
1 2 3 Page 3
Page 3 of 3