Summary prepared by Kirk Scott Design Patterns in Java Part III Construction Patterns Chapter 14 Introducing Construction Summary prepared by Kirk Scott

Standard construction means writing suitable constructors in a class definition Construction design patterns cover cases where a simple set of class constructors won’t satisfy the needs of a given application Before previewing the construction patterns, the book reviews construction in general

A Few Construction Challenges The book describes constructors a kind of specialized method Purists might disagree Like methods, constructors have access modifiers, overloading, and parameters However, what the constructor returns is fixed—and there is no return statement for the programmer to fiddle with There are a number of special syntactical and semantic aspects to constructors

Challenge 14.1 List four rules that govern the use and behavior of constructors in Java.

Solution 14.1 Special rules regarding constructors include the following. 1. If you do not supply a constructor for a class, Java will provide a default. 2. Constructor names must match the class name. (Thus, constructor names typically start with a capital letter, unlike most method names.)

3. Constructors can invoke other constructors with this() and super(), so long as this invocation is the first statement in the constructor. Comment mode on: The use of super() was covered in CS 202 The user of this() wasn’t However, there is nothing difficult about using this It simply lets one constructor make use of another

4. The “result” of a constructor is an instance of the class, whereas the return type of an ordinary method can be anything. 5. You use new, or reflection, to invoke a constructor Comment mode on: You might also observe that user class construction ultimately relies on construction in the Object class Stay tuned for a bit more information on reflection

There are more details that didn’t make it into the previous list Summarizing the whole mess: If you don’t supply a constructor, Java will provide a default constructor If your constructor doesn’t use this() or super(), by default, it is as if the first line of code in your constructor is super()

Most importantly, as a potential source of cryptic errors: If you do provide any constructor at all, Java no longer provides a default constructor If default constructor is needed, it has to be explicitly supplied by the programmer It’s easy to come up with clear examples of how this can cause problems

The book chooses to illustrate this with code that is not quite so simple On the following overhead code is given for: A superclass with a constructor A subclass (without a constructor) The code is problematic The code is followed by a challenge that asks for an explanation

public class Fuse { private String name; /* public Fuse(String name) this.name = name; } */ } public class QuickFuse extends Fuse

Challenge 14.2 Explain the error that will occur if you uncomment the lines that allow the Fuse superclass to accept a fuse name in its constructor

Solution 14.2 This is not a copy of the book’s answer, but it says the same thing The TextPad compiler gives this error message cannot find symbol symbol : constructor Fuse() location: class Fuse class QuickFuse extends Fuse

Solution 14.2, continued This message is telling you that there is no default constructor in the Fuse class There is none because a non-default constructor was supplied The system doesn’t supply one when the programmer provides any other constructor Plus, the programmer didn’t provide one

Solution 14.2, continued Why is a default Fuse class constructor needed? The programmer didn’t provide any constructor for the subclass, QuickFuse Therefore the system supplies a default constructor Even though the default constructor in the subclass isn’t visible, it relies on the existence of a default constructor in its superclass As noted, a default constructor doesn’t exist in its superclass Therefore, compilation fails

Reflection is that part of Java that allows a program to make calls like getClass() In other words, it’s possible for a program to “find out” what kinds of objects it’s working with Reflection makes it possible to find out many more things about an object than just what class it is an instance of

For example, it’s also possible to obtain the constructors for the class Even though reflection is only touched on sparingly in CS 202 and thus far in CS 304, the book provides a little example The code on the following overhead makes use of the getConstructors() method of reflection On the overhead after that a challenge asks what the code does

import java.awt.Point; import java.lang.reflect.Constructor; public class ShowReflection { public static void main(String args[]) Constructor[] cc = Point.class.getConstructors(); Constructor cons = null; for (int i = 0; i < cc.length; i++) if (cc[i].getParameterTypes().length == 2) cons = cc[i]; try Object obj = cons.newInstance( new Object[] { new Integer(3), new Integer(4) }); System.out.println(obj); } catch (Exception e) System.out.println("Exception: " + e.getMessage());

Challenge 14.3 What does the ShowReflection program print out?

Solution 14.3 The program prints: java.awt.Point[x=3, y=4] (It has successfully found a constructor that takes two arguments and created a new point with the arguments given.)

Summary From the point of view of standard construction: You write a set of constructors for your classes, making sure not to trip up on any rules In advance cases, you might use reflection, assuming you knew how… Note: As usual, with an introductory chapter, more stuff follows the summary

Beyond Ordinary Construction Ordinary construction works fine assuming that the client code programmer knows the following: Which class is an instance needed of? What are the construction parameters? Does the client code have values for the needed parameters in hand? If available, does the client code have the values in the right format?

The book tries to sketch out a scenario where ordinary construction might not be sufficient Suppose an application may run on either a desktop or a handheld device Which user interface components to construct, or which construction parameters to use might depend on the environment in which the application is currently running

The table on the next overhead previews the construction design patterns As usual, the authors try to explain and distinguish the patterns according to their intent, or purpose Each of these patterns is supposed to help make construction easier or more appropriate in a particular programming context

The End