1: The pattern concept

What is a pattern?

Pattern taxonomy

1. how we write code in a particular language to do this particular type of thing. This could be something as common as the way that you code the process of stepping through an array in C (and not running off the end).
2. Design: the solution that we came up with to solve this particular problem. This might be a clever design, but it makes no attempt to be general.
3. Design: a way to solve this kind of problem. A design that has become more general, typically through reuse.
4. Pattern: how to solve an entire class of similar problem. This usually only appears after applying a standard design a number of times, and then seeing a common pattern throughout these applications.

Design Structures

•	Encapsulation: self containment and embodying a model of usage

• Gathering
• Localization
• Separation
• Hiding
• Guarding
• Connector
• Barrier/fence
• Variation in behavior
• Notification
• Transaction
• Mirror: “the ability to keep a parallel universe(s) in step with the golden world”
• Shadow “follows your movement and does something different in a different medium” (May be a variation on Proxy).

Design principles

• Principle of least astonishment (don’t be astonishing).
• Make common things easy, and rare things possible
• Law of Demeter: “don’t talk to strangers:” an object should only reference itself, its attributes, and the arguments of its methods.
• Subtraction: a design is finished when you cannot take anything else away.
• Simplicity before generality[6]. (A variation of Occam’s Razor, which says “the simplest solution is the best”). A common problem we find in frameworks is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples. So, this principle acts as the tie breaker between otherwise equally viable design alternatives. Of course, it is entirely possible that the simpler solution is the more general one.
• Reflexivity (my suggested term). One abstraction per class, one class per abstraction. Might also be called Isomorphism.
• Independence or Orthogonality. Express independent ideas independently. This complements Separation, Encapsulation and Variation, and is part of the Low-Coupling-High-Cohesion message.
• Once and once only: Avoid duplication of logic and structure where the duplication is not accidental, ie where both pieces of code express the same intent for the same reason.

The Singleton

//: c01:SingletonPattern.java
// The Singleton design pattern: you can
// never instantiate more than one.

// Since this isn't inherited from a Cloneable
// base class and cloneability isn't added,
// making it final prevents cloneability from
// being added through inheritance:
final class Singleton {
  private static Singleton s = new Singleton(47);
  private int i;
  private Singleton(int x) { i = x; }
  public static Singleton getReference() { 
    return s; 
  }
  public int getValue() { return i; }
  public void setValue(int x) { i = x; }
}

public class SingletonPattern {
  public static void main(String[] args) {
    Singleton s = Singleton.getReference();
    System.out.println(s.getValue());
    Singleton s2 = Singleton.getReference();
    s2.setValue(9);
    System.out.println(s.getValue());
    try {
      // Can't do this: compile-time error.
      // Singleton s3 = (Singleton)s2.clone();
    } catch(Exception e) {
      e.printStackTrace(System.err);
    }
  }
} ///:~

Classifying patterns

1. Creational: how an object can be created. This often involves isolating the details of object creation so your code isn’t dependent on what types of objects there are and thus doesn’t have to be changed when you add a new type of object. The aforementioned Singleton is classified as a creational pattern, and later in this book you’ll see examples of Factory Method and Prototype.
2. Structural: designing objects to satisfy particular project constraints. These work with the way objects are connected with other objects to ensure that changes in the system don’t require changes to those connections.
3. Behavioral: objects that handle particular types of actions within a program. These encapsulate processes that you want to perform, such as interpreting a language, fulfilling a request, moving through a sequence (as in an iterator), or implementing an algorithm. This book contains examples of the Observer and the Visitor patterns.

The development challenge

Exercises

1. SingletonPattern.java always creates an object, even if it’s never used. Modify this program to use lazy initialization, so the singleton object is only created the first time that it is needed.
2. Using SingletonPattern.java as a starting point, create a class that manages a fixed number of its own objects. Assume the objects are database connections and you only have a license to use a fixed quantity of these at any one time.

chris@sunpack.com Last Update:09/08/2001