CMPT 300 Design Patterns
May 2008

Lab 1 Introduction to the UML and Patterns

Code Download --> lab1.zip


A Handful of Fundamental Object-Oriented Principles

1.  A class should support one fundamental responsibiliity - don't create classes that do too much. They are difficult to use and maintain. Suppose you wanted to design a system to play baseball. Instead of creating a class called BatBall, create separate Bat and Ball classes. (In baseball, a bat and a ball have different responsibilities.)

2. Program to Interfaces Whenever Possible.

3. Prefer Composition Over Inheritance.



Program to Interfaces


Consider the java.util.List interface.

By programming to interfaces, we are saying  that we want to encapsulate the operations of a particular data type (in this instance, a List) into an interface. Different implementations of this interface may design it however they wish. By programming to an interface, we are separating the implementation of an interface to its behavior. A further benefit of this is that the interface can decouple the relationship between two different objects. By decoupling the relationship between objects, one object can change its implementation and the other is not affected.

- UseList.java



In-Class Exercise

Modify UseList.java so that it now uses a different implementation of the java.util.List interface instead of java.util.ArrayList. Did you have to change anything else in the program?


In-Class Exercise

Working as partners, explain the benefit of using the java.util.Iterator interface. It is probably easiest to explain using the UseList.java program - consider using a data structure different to the List but that provides an iteration. Using an iteration, illustrate how the iterator decouples the relationship between the list implementation (or any other data structure) and the method for traversing through the list.




IV. Prefer Composition Over Inheritance


Object-oriented technology favors re-use whenever possible. Assume we wanted to create a stack, the java.util.Vector class provides much of this functionality. In fact, the Java API uses inheritance to implement the java.util.Stack.

In object-oriented terminology, inheritance is known as the IS-A principle.

The problem with this is we can break the contract of a traditional stack by allowing operations not associated with a stack - notably the ability to modify the stack from a position other than the stack top:

- TestJavaUtilStack.java

An alternative approach is to implement a stack using a java.util.Vector, not extending it. That is, we are saying the stack will be composed of a java.util.Vector. By using composition in this manner, we are delegating the responsibility of the stack operations to another class.

- CompositionStack.java

Code that tests it:

- TestCompositionStack.java

In object-oriented terminology, composition is known as the HAS-A principle. This leads to the following observation: HAS-A can be better than IS-A.

As we shall see, many design patterns use composition.



UML

Once we have covered the section on UML, draw the UML class diagrams for the program you have chosen. Include any details you feel are necessary including generalizations, abstract classes, interfaces, dependencies, associations, composition, and aggregation. You do not have necessarily have to worry about including attributes and operations; focus mostly on the relationship between the different classes.

Draw the UML diagrams on a piece of paper - it is not necessary to design them using software. Once you have finished, give your diagrams as well as source code to your partner and have them check it for accuracy, missing information, etc. If your source code is only available online, switch seats with your partner so they may view the code.

Quick In-Class Exercise

Draw the UML diagram first showing the relationship between java.util.Stack and java.util.Vector.  Next, draw the relationship between CompositionStack and java.util.Vector.


Slightly-Longer In-Class Exercise

Complete the UML exercise of page 25 of your text.




What to Turn In:

To receive credit for this lab, turn in your three UML hand drawings: (1) the UML class diagram for your program, (2) the quick in-class exercise, and (3) the slightly longer in-class exercise.