DvdListIterator.java - the Iterator Interface

package behavioral.interator.pattern;

public interface DvdListIterator {

    public void first();

    public void next();

    public boolean isDone();

    public String currentItem();
}

DvdList.java - the Concrete Aggregate (with a Concrete Iterator inner class)

TestDvdIterator.java - testing the iterator

package behavioral.interator.pattern;

public class TestDvdIterator {
    public static void main(String[] args) {
        DvdList fiveShakespeareMovies = new DvdList();
        fiveShakespeareMovies.append("10 Things I Hate About You");
        fiveShakespeareMovies.append("Shakespeare In Love");
        fiveShakespeareMovies.append("O (2001)");
        fiveShakespeareMovies.append("American Pie 2");
        fiveShakespeareMovies.append("Scotland, PA.");
        fiveShakespeareMovies.append("Hamlet (2000)");

        DvdListIterator fiveShakespeareIterator = fiveShakespeareMovies.createIterator();
        while (!fiveShakespeareIterator.isDone()) {
            System.out.println(fiveShakespeareIterator.currentItem());
            fiveShakespeareIterator.next();
        }

        fiveShakespeareMovies.delete("American Pie 2");

        System.out.println(" ");
        fiveShakespeareIterator.first();
        while (!fiveShakespeareIterator.isDone()) {
            System.out.println(fiveShakespeareIterator.currentItem());
            fiveShakespeareIterator.next();
        }
    }
}

Test Results

10 Things I Hate About You
Shakespeare In Love
O (2001)
American Pie 2
Scotland, PA.
Hamlet (2000)
 
10 Things I Hate About You
Shakespeare In Love
O (2001)
Scotland, PA.
Hamlet (2000)

UML

References

Interpreter解释器设计模式角色如下：

(1).抽象表达式(AbstractExpression)角色：声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要定义一个interpret()方法，称做解释操作。 
(2).终结符表达式(TerminalExpression)角色：没有子节点的表达式。 
(3).非终结符表达式(NonterminalExpression)角色：有子节点的表达式，解释操作以递归方式调用其子节点表达式。 

(4).上下文(Context)角色：上下文提供解释器之外的一些全局信息，比如变量的真实量值等。 

Interpreter解释器设计模式结构如下：

通过编写一个模拟java中日期格式化为指定字符串的例子来演示Interpreter解释器设计模式，代码如下：

Interpreter解释器设计模式的应用场景：

在软件构建过程中，若果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，再构建一个解释器来解释这样的句子，从而达到解决问题的目的。

JDK中Interpreter解释器设计模式典型应用就是正则表达式。

In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.

Motivation

When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality. This is known as a "has-a" relationship between objects.^[2] The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.

[edit]When to use

Composite can be used when clients should ignore the difference between compositions of objects and individual objects.^[1] If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.

Structure

Composite pattern in UML.

Component

• is the abstraction for all components, including composite ones
• declares the interface for objects in the composition
• (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate

Leaf

• represents leaf objects in the composition .
• implements all Component methods

Composite

• represents a composite Component (component having children)
• implements methods to manipulate children
• implements all Component methods, generally by delegating them to its children
  
  
  import java.util.List;
  import java.util.ArrayList;
   
  /** "Component" */
  interface Graphic {
   
      //Prints the graphic.
      public void print();
  }
   
  /** "Composite" */
  class CompositeGraphic implements Graphic {
   
      //Collection of child graphics.
      private List<Graphic> childGraphics = new ArrayList<Graphic>();
   
      //Prints the graphic.
      public void print() {
          for (Graphic graphic : childGraphics) {
              graphic.print();
          }
      }
   
      //Adds the graphic to the composition.
      public void add(Graphic graphic) {
          childGraphics.add(graphic);
      }
   
      //Removes the graphic from the composition.
      public void remove(Graphic graphic) {
          childGraphics.remove(graphic);
      }
  }
   
  /** "Leaf" */
  class Ellipse implements Graphic {
   
      //Prints the graphic.
      public void print() {
          System.out.println("Ellipse");
      }
  }
   
  /** Client */
  public class Program {
   
      public static void main(String[] args) {
          //Initialize four ellipses
          Ellipse ellipse1 = new Ellipse();
          Ellipse ellipse2 = new Ellipse();
          Ellipse ellipse3 = new Ellipse();
          Ellipse ellipse4 = new Ellipse();
   
          //Initialize three composite graphics
          CompositeGraphic graphic = new CompositeGraphic();
          CompositeGraphic graphic1 = new CompositeGraphic();
          CompositeGraphic graphic2 = new CompositeGraphic();
   
          //Composes the graphics
          graphic1.add(ellipse1);
          graphic1.add(ellipse2);
          graphic1.add(ellipse3);
   
          graphic2.add(ellipse4);
   
          graphic.add(graphic1);
          graphic.add(graphic2);
   
          //Prints the complete graphic (four times the string "Ellipse").
          graphic.print();
      }
  }

　　UML类图如下：

　　其中类和对象的关系：

　　1. Flyweight(抽象轻量级类)：声明一个接口，通过它可以接受外来的参数(状态)，并对新状态做出出来(作用)。

　　2. ConcreteFlyweight(具体轻量级类)：实现Flyweight的接口，并为内部状态增加存储空间，ConcreteFlyweight对象必须是可以共享的，它所有存储的状态必须是内部的，它独立存在于自己的环境中。

　　3. UnsharedConcreteFlyweight(不共享具体轻量级类)：不是所有的Flyweight子类都需要包儿共享，Flyweight的共享不是强制的。在某些Flyweight的结构层次中，UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点。

　　4. FlyweightFactory(轻量级类工厂)：创建并管理flyweight对象；确保享用flyweight。当用户请求一个flyweight时，FlyweightFactory提供一个已创建的实例或者创建一个实例。

　　5. Client(客户应用程序)：维持一个对flyweight的引用；计算或存储一个或多个flyweight的外部状态。

　　典型应用的顺序图如图：

　　客户初次从轻量级类工厂取flyweight时，轻量级类工厂创建一个新的具体flyweight对象，并且保存起来，下次客户取用时，就不用重新创建，直接在保存池中返回。客户负责处理flyweight的状态。

• 实例1——文档编辑器

　　潜在的，每个字符都被大量的采用，因此共享这些字符对象将会节省大量的存储空间。文档编辑器的UML类图如下：

代码

 //Flyweight工厂
 class CharacterFactotry
    {
        private Hashtable characters = new Hashtable();
        public Character GetCharacter(char key)
        {
            //在初始化的Hashtable中取出字符
            Character character = (Character)characters[key];
            //如果取出的字符为null，初始化它
 if (character == null)
            {
                switch (key)
                {
                    case 'A':
                        character = new CharacterA();
                        break;
                    case 'B':
                        character = new CharacterB();
                        break;
                    case 'Z':
                        character = new CharacterZ();
                        break;
                }
                characters.Add(key, character);
            }
            return character;
        }
    }
    //Flyweight
 abstract class Character
    {
        protected char symbol;
        protected int width;
        protected int height;
        protected int ascent;
        protected int descent;
        protected int pointSize;
        public abstract void Draw(int pointSize);
    }
    class CharacterA : Character
    {
        public CharacterA()
        {
            this.symbol = 'A';
            this.height = 100;
            this.width = 120;
            this.ascent = 70;
            this.descent = 0;
        }
        public override void Draw(int pointSize)
        {
            this.pointSize = pointSize;
            Console.WriteLine(this.symbol);
        }
    }
    class CharacterB : Character
    {
        public CharacterB()
        {
            this.symbol = 'B';
            this.height = 100;
            this.width = 140;
            this.ascent = 72;
            this.descent = 0;
        }
        public override void Draw(int pointSize)
        {
            this.pointSize = pointSize;
            Console.WriteLine(this.symbol);
        }
    }
    class CharacterZ : Character
    {
        public CharacterZ()
        {
            this.symbol = 'Z';
            this.height = 100;
            this.width = 100;
            this.ascent = 68;
            this.descent = 0;
        }
        public override void Draw(int pointSize)
        {
            this.pointSize = pointSize;
            Console.WriteLine(this.symbol);
        }
    }


    //客户应用测试
 class Client
    {
        [STAThread]
        static void Main(string[] args)
        {
            //用字符数组创造document
 char[] document = { 'A', 'B', 'Z', 'Z', 'A', 'A' };
            CharacterFactotry f = new CharacterFactotry();
            //外部状态
 int pointSize = 12;
            //为每一个字符使用一个flyweight对象
 foreach (char c in document)
            {
                Character character = f.GetCharacter(c);
                character.Draw(pointSize);
            }
            Console.Read();
        }
    }

• 优势和缺陷

　　Flyweight模式需要你认真考虑如何能细化对象，以减少处理的对象数量，从而减少存留对象在内存或其他存储设备中的占用量。然而，此模式需要维护大量对象的外部状态，如果外部状态的数据量大，传递、查找、计算这些恶数据会变得非常复杂。当外部和内部的状态很难分清时，不宜采用flyweight模式。

• 应用情景

　　下面的情景很适合应用轻量级模式：

　　1. 系统需要存在大量的对象而共享某些本质的、不变的信息。

　　2. 对象可以同时用于多个环境下。

　　3. 在每个实例下，flyweight可以作为一个独立的对象。

Class Diagram

Participants

Example: Product Cache

Example: Class Diagram

Example: Java sample code

Benefits

Usage

In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.^[1]

For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, and/or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed. The validation strategies, encapsulated separately from the validating object, may be used by other validating objects in different areas of the system (or even different systems) without code duplication.

The essential requirement in the programming language is the ability to store a reference to some code in a data structure and retrieve it. This can be achieved by mechanisms such as the native function pointer, the first-class function, classes or class instances in object-oriented programming languages, or accessing the language implementation's internal storage of code via reflection.

Example

The following example is in Java.

// The classes that implement a concrete strategy should implement this. // The Context class uses this to call the concrete strategy.

interface Strategy {

     int execute(int a, int b);

 }  

// Implements the algorithm using the strategy interface

class ConcreteStrategyAdd implements Strategy {

       public int execute(int a, int b) {

       System.out.println("Called ConcreteStrategyAdd's execute()");

       return a + b; 

// Do an addition with a and b

 }

 }  

class ConcreteStrategySubtract implements Strategy {

       public int execute(int a, int b) {

         System.out.println("Called ConcreteStrategySubtract's execute()");

         return a - b;

 // Do a subtraction with a and b

     }

 }

class ConcreteStrategyMultiply implements Strategy {

       public int execute(int a, int b) {

         System.out.println("Called ConcreteStrategyMultiply's execute()");

         return a * b;

     // Do a multiplication with a and b

}

}  

// Configured with a ConcreteStrategy object and maintains a reference to a Strategy object

class Context {

       private Strategy strategy;

       // Constructor

    public Context(Strategy strategy) {

         this.strategy = strategy;

     }

     public int executeStrategy(int a, int b) {

         return strategy.execute(a, b);

     }

 }

 // Test application class StrategyExample {

       public static void main(String[] args) {

           Context context;

           // Three contexts following different strategies

         context = new Context(new ConcreteStrategyAdd());

         int resultA = context.executeStrategy(3,4);

         context = new Context(new ConcreteStrategySubtract());

         int resultB = context.executeStrategy(3,4);

         context = new Context(new ConcreteStrategyMultiply());

         int resultC = context.executeStrategy(3,4);

     }

 }

Strategy versus Bridge

The UML class diagram for the strategy pattern is the same^{[further explanation needed]} as the diagram for the Bridge pattern. However, these two design patterns aren't the same in their intent. While the strategy pattern is meant for behavior, the Bridge pattern is meant for structure.

The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.

Strategy and open/closed principle

Accelerate and brake behaviors must be declared in each new car model

According to the strategy pattern, the behaviors of a class should not be inherited, instead they should be encapsulated using interfaces. As an example, consider a car class. Two possible functionalities for car are brake and accelerate.

Since accelerate and brake behaviors change frequently between models, a common approach is to implement these behaviors in subclasses. This approach has significant drawbacks: accelerate and brake behaviors must be declared in each new Car model. The work of managing these behaviors increases greatly as the number of models increases, and requires code to be duplicated across models. Additionally, it is not easy to determine the exact nature of the behavior for each model without investigating the code in each.

The strategy pattern uses aggregation instead of inheritance. In the strategy pattern behaviors are defined as separate interfaces and specific classes that implement these interfaces. Specific classes encapsulate these interfaces. This allows better decoupling between the behavior and the class that uses the behavior. The behavior can be changed without breaking the classes that use it, and the classes can switch between behaviors by changing the specific implementation used without requiring any significant code changes. Behaviors can also be changed at run-time as well as at design-time. For instance, a car object’s brake behavior can be changed from BrakeWithABS() to Brake() by changing the brakeBehavior member to:

brakeBehavior = new Brake();

This gives greater flexibility in design and is in harmony with the Open/closed principle (OCP) that states that classes should be open for extension but closed for modification.