This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Fair enough...

Posted by Bryan E. Boone on 04 May 1998, 8:41 AM

> Bryan,

> I have a couple of comments about your constructors. I assume
> you were looking at the designing initialization chapter at

> http://www.artima.com/flexiblejava/desinit.html

> or article at

> http://www.javaworld.com/javaworld/jw-03-1998/jw-03-techniques.html

> In this chapter I use the size as an example of an attribute
> that doesn't have a "natural" default value. In such cases I
> think it's best to force client programmers to specify a
> default value. But on the other hand, whether or not size has
> a natural default value is a subjective call, and I wouldn't
> really have much of a problem with a no-arg constructor that just
> sets it to SHORT, as you do here.

> > public class CoffeeCup {
> > public CoffeeCup() {
> > innerCoffee = 0;
> > setSize(SHORT);
> > }
> > public CoffeeCup(int size) {
> > this();
> > setSize(size);
> > }
> > public CoffeeCup(int size, int startingAmount) {
> > this(size);
> > add(startingAmount);
> > }
> > ... //your other functions
> > }

> I do see one thing that looks suspicious to me, however. It is
> something that I was thinking I should mention somewhere in the
> initialization chapter. You are calling constructors with this()
> that have fewer parameters. (I.e., from the constructor that
> takes 2 args, you call the constructor that takes 1 arg. From
> the 2 arg constructor, you call the no arg constructor.) What
> I would ordinarily expect to see is the no-arg constructor
> invoking the 2 arg constructor with default values, and the
> one arg constructor as well. Like this:

> public class CoffeeCup {

> // defs of sizes...
> private int innerCoffee;
> private int size;

> public CoffeeCup() {
> this(SHORT, 0);
> }

> public CoffeeCup(int size) {
> this(size, 0);
> }

> public CoffeeCup(int size, int startingAmount) {
> size = SHORT;
> innerCoffee = startingAmount;
> }

> // The other methods...
> }

> Why do I like this approach better? One reason is that this
> approach initializes each field once per instantiation, whereas
> the previous approach has multiple initializations. (But this
> isn't really likely a significant performance hit.) The big
> reason I like this better is I think it is a bit easier to
> read. (But just a bit, I can read and figure out the other
> one quickly as well.)

> What do you think?

> bv
I think your comments are fair enough. I think it just boils down to preference. However, I was thinking about extensibility issues. When CoffeeCup starts getting extended, the multiple assignments area wash (as you said) since you end up calling some super(...). I just wanted a super() that would ensure that the values of CoffeeCup were initialized to some appropriate values.