SE450: Lecture 5 (Patterns/Canonical form of classes)

Homework Solutions (HW3 and HW4)

Composite and Command Patterns

Inner Class Idiom and Anonymous Inner Classes

The Canonical form of classes

Assertions in java

Design By Contract

Project Overview

Refactoring

Quiz questions

One way to do the homework assignment.

The files are here.

One way to do the homework assignment.

The TestCase (I wrote this one first) FlightTest.java.

The implementation. Flight.java.

One note on Comparable.... if compareTo isn't consistent with equals

JUnit is actually a great demonstration of a number of patterns from GoF. We will look at examples of Template Method(325), Composite (163) and the Command (233) patterns. JUnit also uses Adapter (139).

GenericClass: TestCase

ConcreteClass: VectorTest

public abstract class TestCase extends Assert implements Test {
	/**
	 * Runs the bare test sequence.
	 * @exception Throwable if any exception is thrown
	 */
	public void runBare() throws Throwable {
		setUp();
		try {
			runTest();
		}
		finally {
			tearDown();
		}
	}
	/**
	 * Sets up the fixture, for example, open a network connection.
	 * This method is called before a test is executed.
	 */
	protected void setUp() throws Exception {
	}
	/**
	 * Tears down the fixture, for example, close a network connection.
	 * This method is called after a test is executed.
	 */
	protected void tearDown() throws Exception {
	}
}

• Name - Command
• AKA - Action, Transaction
• Intent - Encapsulate a request as an object, letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
• Problem -
  • Actions need to be taken in a generic fashion, but the requester of the action can't know (or need to know) information about the request
  • Actions need to be run in sequence, or in different ordering depending on who runs them, or why they are being run.
  • Actions need to be re-run, or undone
• Solution - Have all commands implement a generic interface that allows the clients of the command to use them in a generic manner. The clients of the command use the simple interface instead of knowing all the details about what the command does.
• Participants and Collaborators
  • Command - (TestCase)
  • ConcreteCommand - (VectorTest)
  • Client - (TestRunner)
  • Invoker - (TestRunner)
  • Reciever - your code being tested
• Consequences
  • Command decouples the object that invokes the operation from the one that knows how to perform it.
  • Commands are first class objects, so they can be extended and manipulated like any other object.
  • You can use the Composite pattern to assemble commands.
  • You can add new commands without changing existing classes.
• Implementation JUnit Source Code
• GoF Reference (233)

Participants and Collaborators

• Command - (TestCase)
• ConcreteCommand - (VectorTest)
• Client - (TestRunner)
• Invoker - (TestRunner)
• Receiver - your code being tested (Vector)

public interface Test {

	/**
	 * Runs a test and collects its result in a TestResult instance.
	 */
	public abstract void run(TestResult result);

}        

public abstract class TestCase extends Assert implements Test {
 
       /**
	 * Runs the test case and collects the results in TestResult.
	 */
	public void run(TestResult result) {
		result.run(this);
	}

}

public class TestRunner extends BaseTestRunner {
	public TestResult doRun(Test suite, boolean wait) {
		TestResult result= createTestResult();
		result.addListener(fPrinter);
		long startTime= System.currentTimeMillis();
		suite.run(result);
		long endTime= System.currentTimeMillis();
		long runTime= endTime-startTime;
		fPrinter.print(result, runTime);

		pause(wait);
		return result;
	}
}

• Name - Composite
• Intent - Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly
• Problem -
  • Objects need to be treated the same whether they are a single object or a group of objects.
  • Clients should be able to treat whole objects or groups of objects the same, without knowing (or needing to know) the difference.
• Solution - Use a command abstract class for both the groups and the individual objects
• Participants and Collaborators
  • Component - (Test)
  • Leaf - (TestCase)
  • Composite - (TestSuite)
  • Client - (TestRunner)
• Consequences
  • Defines class heirarchies consisting of primitive objects and composite objects. Client code that expects a primitive object can alo take a composite.
  • The client is simple. No if-else, case-statements needed to handle the Composite.
  • New Components can be added easily. They work automatically with existing clients.
  • The design can be made overly general. It can be too hard to restrict the components of the composite. Run-time checks of the type will be needed to constrain the components.
• Implementation JUnit Source Code
• GoF Reference (163)

Participants and Collaborators

• Component - (Test)
• Leaf - (TestCase)
• Composite - (TestSuite)
• Client - (TestRunner)

public interface Test {
	/**
	 * Runs a test and collects its result in a TestResult instance.
	 */
	public abstract void run(TestResult result);
}

public abstract class TestCase extends Assert implements Test {
	/**
	 * Runs the test case and collects the results in TestResult.
	 */
	public void run(TestResult result) {
		result.run(this);
	}
}

public class TestSuite implements Test {
	/**
	 * Adds a test to the suite.
	 */
	public void addTest(Test test) {
		fTests.addElement(test);
	}
	/**
	 * Runs the tests and collects their result in a TestResult.
	 */
	public void run(TestResult result) {
		for (Enumeration e= tests(); e.hasMoreElements(); ) {
	  		if (result.shouldStop() )
	  			break;
			Test test= (Test)e.nextElement();
			runTest(test, result);
		}
	}
}

In Java, classes and interfaces can be members of other classes and interfaces. These are considered nested classes and nested interfaces. They are part of the contract of their enclosing type.

Nested classes and interfaces can be assigned the same access as other members of a class.

The simplest nested class to talk about is a static nested class - technically called a top-level nested class (but this is a terribly confusing name). Static nested classes aren't inner classes.

public class BankAccount {
  private long number;
  private long balance; 

  public static class Permissions {
    public boolean canDeposit,
                   canWithdraw,
		   canClose;
  }
  // ...
}

The full name of this class is BankAccount.Permissions.

static inner classes can be intantiated without creating an instance of the outer class. They make sense when used as a namespace mechanism more than anything. They can have any level of accessibility

When talking about non-static nested classes, we refer to them as inner classes. You need an instance of the outer class to instantiate the inner class.

For example:

public class BankAccount {
  private long number;
  private long balance;
  private Action lastAct;

  public class Action {
    private String act;
    private long amount;
    Action(String act, long amount) {
      this.act = act;
      this.amount = amount;
    }
    public String toString() {
      return number + ": " + act + " " + amount;
    }
  }

  public void deposit(long amount) {
    balance += amount;
    lastAct = new Action("deposit", amount);
  }  

  public void withdraw(long amount) {
    balance -= amount;
    lastAct = new Action("withdraw", amount);
  }  
  // ...
}

the creation of the Action could be written more explicitly as lastAct = this.new Action("deposit", amount); . Outside the BankAccount class, this would look like this:

BankAccount ba = new BankAccount();
Action act = ba.new Action("deposit", 4);

A nested class can use other members of the enclosing class without qualification (including private fields). A static nested class (last slide) can directly access only static members of the enclosing class.

The toString() method above could be written as return BankAccount.this.number + ": " + act + " " + amount; This is the way that you access the outer class from the inner class if you need to explicitly accesss an enclosing class's members.

It is recommended that you only nest classes one deep, but any level is allowed.

Inner classes can't have static members.

Inner classes can be created in code blocks, such as method bodies. These classes are not members of the class, so they can't be private, protected, public, static or final. They have access to the final variables of the code block as well as other members of the class, static and not-static. (think scope as to why this is the case)

Consider the Iterator interface (we talked about it last week and will look at it again tonight).

public interface Iterator {
  public boolean hasNext();
  public Object next();
  public void remove();
}

public static Iterator walthThrough(final Object[] objs) {

  // local inner class
  class Iter implements Iterator {
    private int pos = 0;
    public boolean hasNext() {
      return (pos < objs.length);
    }
    public Object next() throws NoSuchElementException {
      if(pos < objs.length)
        throw new NoSuchElementException();
      return objs[pos++];
    }
  }

  return new Iter();
}

Anonymous classes can be written that implement an interface or extend another class. These classes are just defined at the same time they are created with new. They are perfect for times when you don't want the weight of a full class in your code

For example:

public static Iterator walthThrough(final Object[] objs) {

  // anonymous class
  return new Iterator() {
    private int pos = 0;
    public boolean hasNext() {
      return (pos < objs.length);
    }
    public Object next() throws NoSuchElementException {
      if(pos <= objs.length)
        throw new NoSuchElementException();
      return ojs[pos++];
    }
  };
}

Attr name = new Attr("Name") {
   public Object setValue(Object nv) {
     System.out.println("name set to " + nv);
     return super.setValue(nv);
   }
};

goButton.addActionListener
(
  new ActionListener() {
    public void actionPerformed(ActionEvent e) {
      someMethod();
    }
  }
);

In order to behave properly in the Java environment, you need to be aware of some issues when you construct your classes.

Many of these issues will come up as you move into larger projects and programs

We use the term the canonical form to describe classes that will be well behaved when manipulated by the java run-time environment and other classes, such as the collections framework

When you design classes for general use, you should consider the following:

• No-arg constructor
• Object equality
• String representation
• cloning
• Serialization (persistence)

A zero arg constructor is needed by any code that calls the new operator on your class.

It is also needed by code that dynamically instantiates your class. This can be done as follows:

        Class yourClass = Class.forName("se450.mwright1.hw4.Student");

        Student student = (Student)yourClass.newInstance();
	  
        

This kind of code is used in various application servers as well

JavaBeans are classes that need a 0-arg constructor to work properly by other Java classes as well

A good equals means the following is true. It is:

1. Reflexive
2. Symmetric
3. Transitive
4. Consistent
5. Non-null

The Hashcode is used in collections classes such as HashSet and HashMap. If the equals method is overridden, it is necessary to override the hashCode method.

In general, it can be done as follows:

1. Compute a hash code for each significant field. A field is considered significant if it is part of the equals implementation. For primitive types, the hashcode is the type as an integer. For a reference type, it is the hashCode (if it is not null)
2. Combine the fields into the hash code.

The combination can be done as follows:

1. Bitwise-or hash = hash << n | c where n is an arbitrary integer, say 8.
2. Addition hash = hash * p + c where p is a prime number, say 37

The key is to make sure that the hashcode is always the same for equal values. If it isn't, a value can be put in a hashtable, and then never be able to be retrieved

We have looked at the equals, toString, and hashCode methods that are all inherited from Object. We now need to look at the clone method.

It is analogous to the Copy constructor in C++

The intent is that

x.clone() != x

x.clone().getClass() == x.getClass()

x.clone().equals(x)

The last intent is not a requirement, but is generally true.

By convention, you obtain the returned object by calling super.clone(). If all superclasses do this, then x.clone().getClass() == x.getClass() will be true.

Object doesn't implement Cloneable itself

The Cloneable interface is meant to be a mixin interface, however it doesn't do a very good job of this. The Cloneable interface doesn't contain the clone method, so classes can't be guaranteed to call this method (it may not have the right visibility). But since it is in pretty wide use, we should understand it. We will look at a design pattern, the Prototype in a few weeks that is a better way to do this.

However, you need to be concerned about the deep vs. shallow copy problem. If a there are mutable objects that are members of the object being cloned, they may need to be copied during the clone operation, and references to the objects changed to point to the new objects.

To clone you need:

• the empty Cloneable interface (note the misspelling)
• The Object.clone method (or your superclass's clone method)
• CloneNotSupportedException, to signal the clone method shouldn't have been called.

You can:

• Ignore it.. and use the default Object.clone method, but it is protected, so it is not of much use for other classes to use.
• Support clone
• Conditionally support clone
• Allow subclasses to support clone
• Forbid clone

Simple:

public class MyClass extends HerClass implements Clonable {
  public Object clone throws CloneNotSupportedException {
    return super.clone();
  }
  // ...
}

public class IntegerStack implements Clonable {
  private int[] buffer;
  private int top;
  
  public IntegerStack(int maxContents) {
   buffer = new int[maxContents];
   top = -1;
  }
  
  public void push(int val) {
    buffer[++top] = val;
  }

  public int pop() {
    return buffer[top--];
  }

}

What does the default clone method do?

Fix this by overriding clone

public Object clone() {
  try {
    IntegerStack nObj = (IntegerStack)super.clone();
    nObj.buffer = (int[])buffer.clone();
    return nObj;
  } catch (CloneNotSupportedException e) {
    // cannot happen since we and arrays support clone
    throw new Error(e.toString());
  }
}

To disallow cloning:

public final Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
}

There are alternatives:

• Use the Prototype Design pattern (later)
• Use a Copy Constructor public Foo(Foo foo)
• Use a static Factory Design pattern (later)

the toString method is invoked whenever you use the object in System.out.println. A good String representation of your object makes debugging it much easier than the standard String representation. A good rule of thumb is to include significant fields of an object (like those in the equals method in your toString method.

Avoid this, of course, if they will make it confusing or violate encapsulation. Never put data in your toString method that users may come to depend on because you don't provide an accessor to it.

Java supports serialization for any object that implements the java.io.Serializable interface.

// write.java
import java.io.*;
public class write {
  public static void main(String args[])
  {
    try {
      FileOutputStream fos =
        new FileOutputStream("file.out");
      ObjectOutputStream oos =
        new ObjectOutputStream(fos);
      oos.writeObject(new Test("testing", 37));
      oos.flush();
      fos.close();
    }
    catch (Throwable e) {
      System.err.println(e);
    }
  }
}

// read.java
import java.io.*;
public class read {
  public static void main(String args[])
  {
    Test testobj = null;
    try {
      FileInputStream fis =
        new FileInputStream("file.out");
      ObjectInputStream ois =
        new ObjectInputStream(fis);
      testobj = (Test)ois.readObject();
      fis.close();
    }
    catch (Throwable e) {
      System.err.println(e);
    }
    System.out.println(testobj.str);
    System.out.println(testobj.ivalue);
  }
}

// Test.java
public class Test implements java.io.Serializable {
  public String str;
  public transient int ivalue;
  public Test(String s, int i)
  {
    str = s;
    ivalue = i;
  }

Serialization is used by many Java APIs, especially RMI and many J2EE technologies

You can control serialization with more detail using the java.io.Externalizable interface.

package java.io;
public interface Externalizable extends Serializable {
    public void writeExternal(ObjectOutput out) throws IOException;
    public void readExternal(ObjectInput in) throws IOException, 
                             java.lang.ClassNotFoundException;
}

Control whether fields get persisted using transient. You must be aware that an object that is restored from persistence will need its transient fields initialized.

You may find it very useful in your project

Any questions about the quiz?

Revised: 2003/2/3