lect06b
Constructors deconstructed
lect06b

Review Exercise

How do you declare a variable of type Dog?
How do you create a new Dog object, by calling the constructor directly?
Combine the above two into a single line; recall that this is what happens when you use BlueJ and right-click to create a new instance: it makes a new object, and declares and initializes a local variable (local to the Code Pad).
How would you declare a new field ssn, to hold the social security number of a PizzaServer?

Modify our constructor to initialize that field:

class PizzaServer {

  double salary = 5.15;   // In $/hr.
  boolean isManager = false;
  double balance = 0.0;
  String almaMater;       // Name of the highschool graduated from.

  
  /** The PizzaServer constructor.
   * @param _almaMater The highschool graduated from.
   *    Don't include a suffix " High School"; that is
   *    automatically added.
   * Example:
   *    new PizzaServer( "Radford" )
   */
  PizzaServer( String _almaMater ) {
    this.almaMater = _almaMater + " High School";
    }


  /* method definitions omitted ... */
  }

Call the constructor to create a PizzaServer who went to Pulaski High School, and who has the social security number 123-45-6789.

Constructors, deconstructed

The syntax for a constructor's signature:

Signature_constructor ::=
Name_class ( paramater-declaration-list )

constructor-call ::=
 new Name_class( argument-list )

There are two unusual things about the constructor's signature:

No return type is specified!
You don't get to choose the name. The name must be exactly the same as the class.

Moreover, the constructor is called differently than other methods: it uses new.

What exactly¹ happens, when you call a constructor, like new Blarg(…)?

Java makes a new Blarg with all of its fields undefined ².
Java looks at your class file, from top-to-bottom, and every time it sees a declared (non-static) field which you had initialized, it gives that value to the field.
Then, Java runs the constructor code, starting from its first line.

If Java can't guarantee in advance that you'll have provided an initial field for every field, you'll get a compile-time eror.

Constructors rarely do anything interesting, besides accept some values which (almost always) are directly put into fields. Note that there are two common naming conventions: You can use parameter names which start with underscores (but otherwise have the meaningful name corresponding to the field):

class Blarg {
  int    blargNum;
  String blargName;
  double blargDub = Double.MIN_VALUE:
  boolean blargTF;
  
  /**
   * Construct a Blarg, given
   */
  Blarg( int _blargNum, String _blargName ) {
    this.blargNum  = _blargNum;
    this.blargName = _blargName;
    this.blargTF   = false;      // This initial value could have been provided when 
                                 // the field was declared, as with blargDub.
    }

Again, there is nothing special about these parameter names; the underscore is (as far as Java cares) just another letter, usable in names. We want to use a name which is both (a) highly reminiscent of of the actual field's name, and yet (b) slightly different from the field's name (so we don't confuse the parameter name with the field name). Using the underscore is a common way of achieving these two goals. But you can use whatever parameter name you like (as long as it's meaningful to human readers).

Beware calling methods from constructors

While it's technically legal to call a method (in the same class) from a constructor, you should be very careful about doing this: People writing the other methods always assume the object being worked with (this) is in a valid, fully-initialized state. But if you call it from the middle of a constructor, you're only half initialized! Even getters and setters should be avoided in this one situation.

That's all good and well, but what if this warning conflicts with our princicple of avoiding repeated code? That is, what if you have code which needs to be performed both in the constructor and in regular methods? It's an annoying conflict of interest. There is a solution, but we don't yet have the tools: static methods. Fortunately, this situation doesn't arise too often; constructors are usually extremely boring: they just initialize fields more-or-less directly from their parameters.

¹ Well, this isn't the whole story, as we ignore initialization blocks, as well as not mention static (class) initializon nor superclass constructors. ↩

²Actually, they are set to a zero-ish value (0.0 for float, false for boolean, ).
But even if you want some field to have the value 0 initially, you should set it yourself explicitly, so others reading your code know what you really intended, and don't have to guess whether you have a bug of uninitialized variables.
For this course, you'll be required to initialize every field. ↩

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University
Last modified 2007.Aug.27 (Mon) Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu

lect06bConstructors deconstructedlect06b

Review Exercise

Constructors, deconstructed

Beware calling methods from constructors

lect06b
Constructors deconstructed
lect06b