亚洲国产精品VA在线看黑人,色婷婷亚洲一区二区三区,亚洲熟妇av一区二区三区下载

Twelve: Iterator Design Pattern

明年今日 — Tue, 06 Nov 2012 02:49:00 GMT

Iterator (aka Cursor) Overview

One object can traverse all of the elements of another object.

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)

package behavioral.interator.pattern;

public class DvdList {

    private String[]    titles;

    private int                titleCount;

    private int                arraySize;

    public DvdList() {
        titles = new String[3];
        titleCount = 0;
        arraySize = 3;
    }

    public int count() {
        return titleCount;
    }

    public void append(String titleIn) {
        if (titleCount >= arraySize) {
            String[] tempArray = new String[arraySize];
            for (int i = 0; i < arraySize; i++) {
                tempArray[i] = titles[i];
            }
            titles = null;
            arraySize = arraySize + 3;
            titles = new String[arraySize];
            for (int i = 0; i < (arraySize - 3); i++) {
                titles[i] = tempArray[i];
            }
        }
        titles[titleCount++] = titleIn;
    }

    public void delete(String titleIn) {
        boolean found = false;
        for (int i = 0; i < (titleCount - 1); i++) {
            if (found == false) {
                if (titles[i].equals(titleIn)) {
                    found = true;
                    titles[i] = titles[i + 1];
                }
            } else {
                if (i < (titleCount - 1)) {
                    titles[i] = titles[i + 1];
                } else {
                    titles[i] = null;
                }
            }
        }

        if (found == true) {
            --titleCount;
        }
    }

    public DvdListIterator createIterator() {
        return new InnerIterator();
    }

    private class InnerIterator implements DvdListIterator {
        private int    currentPosition    = 0;

        private InnerIterator() {
        }

        public void first() {
            currentPosition = 0;
        }

        public void next() {
            if (currentPosition < (titleCount)) {
                ++currentPosition;
            }
        }

        public boolean isDone() {
            if (currentPosition >= (titleCount)) {
                return true;
            } else {
                return false;
            }
        }

        public String currentItem() {
            return titles[currentPosition];
        }
    }
}

Try the Design Patterns Video Tutorial from SourceMaking

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

UML for Iterator

References

明年今日 2012-11-06 10:49 发表评论

Eleven: Memento Design Pattern

明年今日 — Tue, 06 Nov 2012 01:45:00 GMT

Refer to:http://blog.sina.com.cn/s/blog_4a2100f8010142n1.html

1.1.1.概述

备忘录是一个非常容易理解的模式�Q�只需要看一下后面的客户端测试代码就能明白备忘录模式的用意。备忘录模式��是用来保存对象的某一个状态，�q�样在一定时候，可以通过备忘录来恢复对象的状态�?/div>

针对上面所说的用意�Q�实现�v来就需要一个类来保存这个状态，�q�个�c�d��是备忘录�c�R��鉴于备忘录很容易理解，��q��接看后面的代码实现吧�?/div>

1.1.2.代码实现

在代码实��C��Q�备忘录模式一共有三个�c�，Originator�c�L��原始的对象，正是�q�个对象的状态需要备忘，�q�样是�ؓ了在一个时��_��q�个对象可以恢复到备忘的状态。还有一个类是Memento�Q�这个是备忘录，用于保存Originator�cȝ��状态。还有一个类CareTaker用来��理备忘录�?/div>

首先看Originator的代码实现�?/div>

///

/// 用于创徏备忘录的原发器，记录当前的内部状�?/span>
///

    public class Originator
    {
        ///

/// 当前的状�?/span>
///

private string state;

///

/// 创徏一个当前状态的备忘�?/span>
///

        ///
        public Memento CreateMemento()
        {
            return new Memento(this.state);
        }

        ///

/// 恢复当前状态�ؓ备忘录所保存的状�?/span>
///

        ///
        public void RestoreMemento(Memento memento)
        {
            this.state = memento.GetState();
        }

        public string GetState()
        {
            return this.state;
        }

        public void SetState(string state)
        {
            this.state = state;
        }

    }

Originator�c�d��有一个状态属性，�q�个属性代表了Originator对象的实时状态，CreateMemento()�Ҏ��用来保存Originator对象的一个状态作为备忘，在以后需要的时候可以显�C�。也��是说通过�q�个�Ҏ��可以给Originator对象产生一个备忘录。RestoreMemento()�Ҏ��用来从保存的备忘录中恢复Originator的状态，��Originator的状态设�|��ؓ之前的一个备忘状态�?/div>

下面是备忘录�c�Memento�cȝ��代码实现�?/div>

///

/// 备忘录类
///

    public class Memento
    {
        ///

/// 备忘录所保存的状�?/span>
///

private string state;

///

/// 构造函�?/span>
///

        ///
        public Memento(string state)
        {
            this.state = state;
        }

        public string GetState()
        {
            return this.state;
        }

        public void SetState(string state)
        {
            this.state = state;
        }
    }

因�ؓMemento�c�需要保存Originator对象的状态，所以Memento��h��一个Originator状态一��L��属性state�Q�这个state用来保存Originator的一个状态�?/div>

Memento�cȝ��理者是CareTaker�c�，CareTaker�cȝ��代码如下�?/div>

///

/// 负责保存备忘录的��理�?/span>
///

    public class CareTaker
    {
        ///

/// 备忘�?/span>
///

private Memento memento;

///

/// �q�回所拥有的备忘录
///

        ///
        public Memento retrieveMemento()
        {
            return this.memento;
        }

        ///

/// 保存一个备忘录
///

        ///
        public void SaveMemento(Memento memento)
        {
            this.memento = memento;
        }
    }

CareTaker�cȝ��来管理Memento对象�Q�所以自�w�拥有一个Memento对象。�ƈ且有一个设�|�Memento对象�Ҏ��Q�SaveMemento�Q�和一个取得Memento的方法（retrieveMemento�Q��?/div>

备忘录模式的核心代码已经定义好了�Q�下面通过客户端代码来��试一下备忘录模式�?/div>

  private static Originator o = new Originator();
        private static CareTaker c = new CareTaker();
        public static void Test()
        {
            o.SetState("On");
            c.SaveMemento(o.CreateMemento());
            Console.WriteLine("�W�一�ơ�ؓ" + o.GetState());
            o.SetState("Off");
            Console.WriteLine("�W�二�ơ�ؓ" + o.GetState());
            o.RestoreMemento(c.retrieveMemento());
            Console.WriteLine("恢复��C��一�ơ�ؓ" + o.GetState());
        }

在客��L��代码中，定义了一个Originator的对象o和CareTaker 的对象c�Q�首先对o讄��了一个状态，�q�且通过c�Q�c是管理备忘录的）来把o目前的状态备忘（保存为备忘录�Q�。然后��l�设�|�了一下o的状态，在此�Ӟ��o��x��复自��q��状态到之前�Q�因为想恢复的状态保存在了备忘录中，所以通过o的RestoreMemento可以��状态恢复�ؓ备忘录所记蝲的状态�?/div>

客户端的��试代码演示的是备忘录模式的意图�Q�而之前的代码演示的是备忘录模式的�l�构�?/div>

1.1.3.模型表示

备忘录模式的UML�c�d��如下所�C��?/div>

在备忘录模式的类模型图中可以看出来，Originator�Q�Memento和CareTaker三者之间的关系�Q�Memento用来保存Originator的一个状态，Caretaker用来��理Memento。在Originator需要Memento的时候，通过Caretaker卛_��得到。在Originator需要备忘一个状态的时候，通过Caretaker卛_��备忘�?/div>

1.1.4.模式分析

备忘录模式就是用来在对象的外部可以保存对象的一个内部状态。用来存储另外一个对象内部状态的快照。备忘录卛_��象的一个检查点�Q�也是一个还原点�?/div>

��查点�Q�某一个快照所处的位置�Q�即一个状态）�?/div>

备忘录模式的意图是在不破坏封装性的前提下，捕获一个对象的内部状态，�q�在该对象之外保存这个状态，�q�样以后��可以将该对象恢复到原先保存的状态�?/div>

通过代码实现中的客户端测试代码即可看到备忘录模式的��用场景：

1、必��M��存一个对象在某一个时�ȝ��状态，�q�样以后需要的时候就能恢复到之前的状态�?/div>

2、如果用接口来让其他对象直接得到�q�些状态，��会暴露对象的实现细节�ƈ破坏对象的封装性�?/div>

通过使用备忘录模式，可以辑ֈ�一些效果：

1、保持封装边界。应用��用备忘录模式�Q�将Originator对象中的一些细节隔��d��了Caretaker和Memento中。保持了Originator�c�d��部信息对其他对象的隐藏，从而保持了��装边界�?/div>

2、简化了Originator�c�，��Originator�c�M��的一些操作交�l�了Caretaker和Memento�?/div>

3、增加了额外的代��P��使用了备忘录模式�Q�就��D��了Originator�c�M��的状态在产生备忘录的时候复制了信息�Q�这样如果需要备忘的信息量很大，那么备忘录模式会��D��额外大量的开销�?/div>

4、定义窄接口和宽接口。一些语�a�中可能难以保证只有Originator可访问备忘录的状态。也��是说Originator之外的对象可能会讉K��Memento的状态，��D��不安全�?/div>

5、维护备忘录存在潜在的代仗��Caretaker在维护Memento的时候，因�ؓCaretaker不知道备忘录Memento所保存的状态数量，所以在通过Caretaker来保存Memento的时候，可能会导致大量的存储开销�?/div>

因�ؓ效果4所说的潜在的安全问题，备忘录还有另外一�U�安全的实现方式�Q�也��是��Memento定义为Originator的内部类�Q�这��L��话Memento也就是只有Originator才能讉K��了�?/div>

安全模式的一�U�备忘录模式代码实现�Q�如下：

  public interface IMementoSafeMode
    {
    }

定义一个备忘录的接口，�q�样��封装了备忘录的讉K��Q�外部的�c�都通过讉K��接口来访问备忘录。备忘录模式的一个要点就是不破坏��装性�?/div>

下面是一�U�安全实现的备忘录管理员�cȝ��实现�?/div>

  public class CareTakerSafeMode
    {
        private IMementoSafeMode memento;
        public IMementoSafeMode RetriveMemento()
        {
            return this.memento;
        }
        public void SaveMemento(IMementoSafeMode memento)
        {
            this.memento = memento;
        }
    }

通过接口的实玎ͼ��理员完全不会访问备忘录�cȝ��Q�这样就使得备忘录类只会暴露�l�和他有关系的类�Q�这也是单一原则的体玎ͼ�卌��_�c�特法则�Q�LOD�Q�：只与你的朋友通信�Q�不和陌生�h说话�?/div>

下面是安全的备忘录模式的核心实现�?/div>

  public class OriginatorSafeMode
    {
        private string state;
        public OriginatorSafeMode() { }

        public IMementoSafeMode CreateMemento()
        {
             MementoSafeMode mbox = new MementoSafeMode(this.state);
             return mbox;
        }
        public void RestoreMemento(IMementoSafeMode memento)
        {
            MementoSafeMode mementoSafeMode = (MementoSafeMode)memento;
            this.state = mementoSafeMode.State;
        }
        public string State
        {
            get { return this.state; }
            set { this.state = value; }
        }

        protected class MementoSafeMode : IMementoSafeMode
        {
            private string state;
            ///

///

            ///
            public MementoSafeMode(string state)
            {
                this.state = state;
            }
            public string State
            {
                get { return this.state; }
                set { this.state = value; }
            }
        }
    }

在之前的备忘录模式中�Q�备忘录模式Memento和Originator�c�L��分开的，�q�里��Memento作�ؓOriginator的内部类�Q�这样限制了Memento的访问范��_��卛_��有Originator�cȝ��内部才能讉K��?/div>

注意C#和JAVA在处理内部类的时候有不一致的地方。C#中内部类的Public属性只能是外部�c�范围内讉K��Q�如果是private则外部类也无法访问，只有在内部类之内才能讉K��。但是在java中要实现�q�样的效果，内部�cȝ��所有属性都必须是Private�Q�这��h��限制了只有外部类讉K��。在java中，外部�cȝ��g��一个命名空��_��通过外部�c�d��以看到内部类�Q�OriginatorSafeMode.MementoSafeMode�q�样的写法就��D��了内部类的暴�Ԍ��只不�q�无法实例化而已�Q�。即使不能实例化�Q�但是也对外暴露了内部类。在C#中这一�Ҏ��所改进�Q�内部类在外面根本无法看到�?/div>

实现了内部类的UML�c�d��省略�Q�内部类在UML中��用圈里面包含的一个叉来显�C�，另一端是��头�Q�箭头指向的是内部类。Visual Studio 2010中自带的UML�c�d��和Visio中的UML�c�d��都不支持内部�cȝ��表示�Q��用rose可以甅R�?/div>

1.1.5.思想

目的�Q�在不破坏封装性的前提下，捕获一个对象的内部状态，�q�在该对象之外保存这个状态。这样以后就可以��该对象恢复到原先保存的状态�?/div>

实现思想�Q�用一个Memento的类来保存需要恢复的状态，可以是一个或者多个。�ƈ且由另一个类CareTaker来负责恢复�?/div>

1.1.6.应用

应用中如果有�c�M��历史记录机制的功能，那么�q�个功能有可能就能��用备忘录模式�Q�因为历史记录就是一个过�ȝ��状态，那么如果要访问历史记录就表示要恢复状态。保存历史记录的�c�d��是一个备忘录�c�R�?/div>

当然了，如果理解了之前的备忘录模式的实现�Q�那么根据其要点“恢复到原先保存的状�?#8221;�Q�那么如果需要恢复一个类的状态到以前的某个状态，则备忘录基本上就可以搞定�Q�但是，切忌杀鸡用牛刀的悲剧�?/div>

明年今日 2012-11-06 09:45 发表评论

Ten: Mediator Design Pattern

明年今日 — Mon, 05 Nov 2012 03:45:00 GMT

Refer to: http://blog.sina.com.cn/s/blog_3fe961ae0100qbz6.html

意图

通过引入中介者模式来在对象之间传递消息（承担中介者）�Q�以��化对象之间的通信�?/div>

什么是中介者模�?/div>

中介者模式包装了一�p�d��对象�怺�作用的方式，使得�q�些对象不必互相明显引用。从而��它们可以较松散地耦合。当�q�些对象中的某些对象之间的相互作用发生改变时�Q�不会立卛_��响到其他的一些对象之间的�怺�作用。从而保证这些相互作用可以彼此独立地变化�?/div>

在中介者模式中�Q�所有的成员对象者可以协调工作，但是又不直接�怺��理。这些对象都与一个处于中心地位的中介者对象发生紧密的关系�Q�由�q�个中介者对象进行协调工作。这个协调者对象叫做中介者（Mediator�Q�，而中介者所协调的成员对象称做同事（Colleague�Q�对象�?/div>

�c�d��

角色

�Q?�Q�抽象中介者（Mediator�Q�角�Ԍ��定义出同事对象到中介者对象的接口�Q�其中主要的�Ҏ��是一个（或者多个）事�g�Ҏ��。在有些情况下，�q�个抽象对象可以省略�?/div>

�Q?�Q�具体中介者（ConcreteMediator�Q�角�Ԍ��从抽象中介者��承而来�Q�实��C��抽象��类所声明的事件方法。具体中介者知晓所有的具体同事�c�，它从具体同事对象接收消息、向具体同事对象发出命��o�?/div>

�Q?�Q�抽象同事类�Q�Colleague�Q�角�Ԍ��定义��Z��介者到同事对象的接口。同事对象只知道中介者而不知道其余的同事对象�?/div>

�Q?�Q�具体同事类�Q�ConcreteColleague�Q�角�Ԍ��所有的具体同事�c�d��从抽象同事类�l�承而来。每一个具体同事类都很清楚它自己在��范围内的行为，而不知道它在大范围内的目的。在�C�意性的�c�d��中，具体同事�c�L��Colleague1和Colleague2�?/div>

源代�?/div>

package 中介者模�?

//抽象中介�?/span>
public abstract class Mediator {

//事�g�Ҏ��Q�由子类实现
public abstract void colleagueChanged(Colleague c);
}

package 中介者模�?

//抽象同事�c?/span>
public abstract class Colleague {
private Mediator mediator;

//构造函敎ͼ�中介者作为参�?/span>
public Colleague(Mediator m){
this.mediator=m;
}

public Mediator getMediator(){
return this.mediator;
}

//行动�Ҏ��Q�由子类实现
public abstract void action();

//当同事对象发生变化时�Q�告知中介�?/span>
public void change(){
mediator.colleagueChanged(this);
}
}

package 中介者模�?

public class Colleague1 extends Colleague {

public Colleague1(Mediator m) {
super(m);
}

@Override
public void action() {
System.out.println("Colleague1 action");
}

}

package 中介者模�?

public class Colleague2 extends Colleague {

public Colleague2(Mediator m) {
super(m);
}

@Override
public void action() {
System.out.println("Colleague2 action");
}

}

package 中介者模�?

//具体中介�?/span>
public class ConcreteMediator extends Mediator{

private Colleague1 colleague1;
private Colleague2 colleague2;

@Override
public void colleagueChanged(Colleague c) {
//中介者通知其它同事对象作出响应�Q�实际的代码要复杂得�?/span>
if(c==colleague1){
System.out.println("colleague1发生改变�Q�其他同事对象作出响�?);
this.colleague2.action();
}else if(c==colleague2){
System.out.println("colleague2发生改变�Q�其他同事对象作出响�?);
this.colleague1.action();
}
}

public void createConcreteColleague(){
colleague1=new Colleague1(this);
colleague2=new Colleague2(this);
}

public Colleague1 getColleague1() {
return colleague1;
}

public Colleague2 getColleague2() {
return colleague2;
}
}

package 中介者模�?

public class Client {
public static void main(String[] args) {
ConcreteMediator m = new ConcreteMediator();
m.createConcreteColleague();
Colleague c1=m.getColleague1();
Colleague c2=m.getColleague2();
c1.change();
c2.change();
}
}

输出�Q?/div>

colleague1发生改变�Q�其他同事对象作出响�?/div>

Colleague2 action

colleague2发生改变�Q�其他同事对象作出响�?/div>

Colleague1 action

明年今日 2012-11-05 11:45 发表评论

Nine: Interpreter Design Pattern

明年今日 — Mon, 05 Nov 2012 02:34:00 GMT

Interpreter解释器设计模式的定义�Q�给定一个语�a��Q�定义其文法的一�U�表�C�，�q�定义一个解释器�Q�这个解释器使用该表�C�来解释语言中的句子�?/p>

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

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

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

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

通过�~�写一个模拟java中日期格式化为指定字�W�串的例子来演示Interpreter解释器设计模式，代码如下�Q?/p>

[java] view plain copy

package behavioral.interpreter.pattern;

import java.util.Date;

public interface AbstractExpression {

    public String format(Date date);;
}

package behavioral.interpreter.pattern;

import java.util.Calendar;
import java.util.Date;

public class DataFormatExpression implements AbstractExpression {

    private static final String        pattern1    = "yyyy-MM-dd";
    private static final String        pattern2    = "yyyy/MM/dd";
    private static final Calendar    calendar    = Calendar.getInstance();

    private String                                separator    = "";

    public DataFormatExpression() {
    };

    public DataFormatExpression(String pattern) {
        if (pattern1.equals(pattern)) {
            separator = "-";
        } else if (pattern.equals(pattern)) {
            separator = "/";
        }
    }

    public String getYear(Calendar cal) {
        return cal.get(Calendar.YEAR) + "";
    }

    public String getMonth(Calendar cal) {
        int month = cal.get(Calendar.MONTH) + 1;
        return month < 10 ? "0" + month : "" + month;
    }

    public String getDay(Calendar cal) {
        int day = cal.get(Calendar.DAY_OF_MONTH);
        return day < 10 ? "0" + day : "" + day;
    }

    @Override
    public String format(Date date) {
        calendar.setTime(date);
        return getYear(calendar) + separator + getMonth(calendar) + separator + getDay(calendar);
    }
}

package behavioral.interpreter.pattern;

import java.util.Date;

public class InterpreterDemo {

    public static void main(String[] args) {
        Date date = new Date();
        AbstractExpression expression1 = new DataFormatExpression();
        System.out.println(expression1.format(date));

        AbstractExpression expression2 = new DataFormatExpression("yyyy-MM-dd");
        System.out.println(expression2.format(date));

        AbstractExpression expression3 = new DataFormatExpression("yyyy/MM/dd");
        System.out.println(expression3.format(date));
    }
}

Interpreter解释器设计模式的应用场景�Q?/p>

在��Y件构��E�中�Q�若果某一特定领域的问题比较复杂，�c�M��的模式不断重复出玎ͼ�如果使用普通的�~�程方式来实现将面��非常频繁的变化。在�q�种情况下，��特定领域的问题表达为某�U�语法规则下的句子，再构��Z��个解释器来解释这��L��句子�Q�从而达到解决问题的目的�?/p>

JDK中Interpreter解释器设计模式典型应用就是正则表辑ּ��?/p>

明年今日 2012-11-05 10:34 发表评论

Eight: State Design Pattern

明年今日 — Fri, 02 Nov 2012 06:56:00 GMT

摘要: State Design Pattern is mainly for changing state at run-time.The Java example below shows how State pattern works.The idea behind the example: people normally work harder when they are poor and play ... 阅读全文

明年今日 2012-11-02 14:56 发表评论

Seven: Visitor Design Pattern

明年今日 — Fri, 02 Nov 2012 06:16:00 GMT

In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to easily follow the open/closed principle.

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.

interface CarElementVisitor {
    void visit(Wheel wheel);
    void visit(Engine engine);
    void visit(Body body);
    void visit(Car car);
}

interface CarElement {
    void accept(CarElementVisitor visitor); // CarElements have to provide accept().
}

class Wheel implements CarElement {
    private String name;

    public Wheel(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    public void accept(CarElementVisitor visitor) {
        /*
         * accept(CarElementVisitor) in Wheel implements
         * accept(CarElementVisitor) in CarElement, so the call
         * to accept is bound at run time. This can be considered
         * the first dispatch. However, the decision to call
         * visit(Wheel) (as opposed to visit(Engine) etc.) can be
         * made during compile time since 'this' is known at compile
         * time to be a Wheel. Moreover, each implementation of
         * CarElementVisitor implements the visit(Wheel), which is
         * another decision that is made at run time. This can be
         * considered the second dispatch.
         */
        visitor.visit(this);
    }
}

class Engine implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}

class Body implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}

class Car implements CarElement {
    CarElement[] elements;

    public Car() {
        //create new Array of elements
        this.elements = new CarElement[] { new Wheel("front left"),
            new Wheel("front right"), new Wheel("back left") ,
            new Wheel("back right"), new Body(), new Engine() };
    }

    public void accept(CarElementVisitor visitor) {
        for(CarElement elem : elements) {
            elem.accept(visitor);
        }
        visitor.visit(this);
    }
}

class CarElementPrintVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {
        System.out.println("Visiting " + wheel.getName() + " wheel");
    }

    public void visit(Engine engine) {
        System.out.println("Visiting engine");
    }

    public void visit(Body body) {
        System.out.println("Visiting body");
    }

    public void visit(Car car) {
        System.out.println("Visiting car");
    }
}

class CarElementDoVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {
        System.out.println("Kicking my " + wheel.getName() + " wheel");
    }

    public void visit(Engine engine) {
        System.out.println("Starting my engine");
    }

    public void visit(Body body) {
        System.out.println("Moving my body");
    }

    public void visit(Car car) {
        System.out.println("Starting my car");
    }
}

public class VisitorDemo {
    static public void main(String[] args) {
        Car car = new Car();
        car.accept(new CarElementPrintVisitor());
        car.accept(new CarElementDoVisitor());
    }
}

明年今日 2012-11-02 14:16 发表评论

Six: Composite pattern

明年今日 — Thu, 01 Nov 2012 09:10:00 GMT

In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

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 childGraphics = new ArrayList();

    //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();
    }
}

明年今日 2012-11-01 17:10 发表评论

Five: Bridge Design Pattern

明年今日 — Thu, 01 Nov 2012 08:00:00 GMT

“Decouple an abstraction from its implementation so that the two can vary independently” is the intent for bridge design pattern as stated by GoF.

Bridge design pattern is a modified version of the notion of “prefer composition over inheritance”.

Problem and Need for Bridge Design Pattern

When there are inheritance hierarchies creating concrete implementation, you loose flexibility because of interdependence. Oops! these kind of sentencies shows that the author(I) didn’t understand and tries to escape! Okay, I will decrypt this sentence in the coming paragraphs.

Decouple implentation from interface and hiding implementation details from client is the essense of bridge design pattern.

Elements of Bridge Design Pattern

Abstraction – core of the bridge design pattern and defines the crux. Contains a reference to the implementer.

Refined Abstraction – Extends the abstraction takes the finer detail one level below. Hides the finer elements from implemetors.

Implementer - This interface is the higer level than abstraction. Just defines the basic operations.

Concrete Implementation – Implements the above implementer by providing concrete implementation.

Example for core elements of Bridge Design Pattern

Vehicle -> Abstraction

manufacture()

Car -> Refined Abstraction 1

manufacture()

Bike -> Refined Abstraction 2

manufacture()

Workshop -> Implementor

work()

Produce -> Concrete Implementation 1

work()

Assemble -> Concrete Implementation 2

work()

Generic UML Diagram for Bridge Design Pattern

Before Bridge Design Pattern

After Bridge Design Pattern

Sample Java Code for Bridge Design Pattern

package com.javapapers.designpattern;

/**

* abstraction in bridge pattern

* */

abstract class Vehicle {

protected Workshop workShop1;

protected Workshop workShop2;

protected Vehicle(Workshop workShop1, Workshop workShop2) {

this.workShop1 = workShop1;

this.workShop2 = workShop2;

}

abstract public void manufacture();

}

package com.javapapers.designpattern;

/**

* Refine abstraction 1 in bridge pattern

public class Car extends Vehicle {

public Car(Workshop workShop1, Workshop workShop2) {

super(workShop1, workShop2);

}

@Override

public void manufacture() {

System.out.print("Car ");

workShop1.work();

workShop2.work();

}

package com.javapapers.designpattern;

/**

* Refine abstraction 2 in bridge pattern

public class Bike extends Vehicle {

public Bike(Workshop workShop1, Workshop workShop2) {

super(workShop1, workShop2);

}

@Override

public void manufacture() {

System.out.print("Bike ");

workShop1.work();

workShop2.work();

}

package com.javapapers.designpattern;

/**

* Implementor for bridge pattern

* */

public interface Workshop {

abstract public void work();

}

package com.javapapers.designpattern;

/**

* Concrete implementation 1 for bridge pattern

* */

public class Produce implements Workshop {

@Override

public void work() {

System.out.print("Produced");

}

package com.javapapers.designpattern;

/**

* Concrete implementation 2 for bridge pattern

* */

public class Assemble implements Workshop {

@Override

public void work() {

System.out.println(" Assembled.");

}

package com.javapapers.designpattern;

* Demonstration of bridge design pattern

public class BridgePattern {

public static void main(String[] args) {

Vehicle vehicle1 = new Car(new Produce(), new Assemble());

vehicle1.manufacture();

Vehicle vehicle2 = new Bike(new Produce(), new Assemble());

vehicle2.manufacture();

}

Output:

Car Produced Assembled.

Bike Produced Assembled.

Summary of Bridge Design Pattern

Creates two different hierarchies. One for abstraction and another for implementation.

Avoids permanent binding by removing the dependency between abstraction and implementation.

We create a bridge that coordinates between abstraction and implementation.

Abstraction and implementation can be extended separately.

Should be used when we have need to switch implementation at runtime.

Client should not be impacted if there is modification in implementation of abstraction.

Best used when you have multiple implementations.

Bridge Vs Adapter Design Pattern

The adapter design pattern helps it two incompatible classes to work together. But, bridge design pattern decouples the abstraction and implementation by creating two different hierarchies.

明年今日 2012-11-01 16:00 发表评论

Four: Flyweight Pattern

明年今日 — Tue, 30 Oct 2012 07:08:00 GMT

�q�用�׃�n技术有效地支持大量�l�粒度的对象�Q�系�l�只使用��量的对象，而这些对象都相近�Q�状态变化很��，对象使用�ơ数增多�?/p>

　　UML�c�d��如下�Q?/p>

　　其中�c�d��对象的关�p�：

　　1. Flyweight(抽象轻量�U�类)�Q�声明一个接口，通过它可以接受外来的参数(状�?�Q��ƈ�Ҏ��状态做出出�?作用)�?/p>

　　2. ConcreteFlyweight(具体轻量�U�类)�Q�实现Flyweight的接口，�q��ؓ内部状态增加存储空��_��ConcreteFlyweight对象必须是可以共享的�Q�它所有存储的状态必��L��内部的，它独立存在于自己的环境中�?/p>

　　3. UnsharedConcreteFlyweight(不共享具体轻量��c?�Q�不是所有的Flyweight子类都需要包儿共享，Flyweight的共享不是强制的。在某些Flyweight的结构层�ơ中�Q�UnsharedConcreteFlyweight对象通常��ConcreteFlyweight对象作�ؓ子节炏V�?/p>

　　4. FlyweightFactory(轻量�U�类工厂)�Q�创建�ƈ��理flyweight对象�Q�确保��n用flyweight。当用户��h��一个flyweight�Ӟ��FlyweightFactory提供一个已创徏的实例或者创��Z��个实例�?/p>

　　5. Client(客户应用�E�序)�Q�维持一个对flyweight的引用；计算或存储一个或多个flyweight的外部状态�?/p>

　　典型应用的顺序图如图�Q?/p>

　　客户初次从轻量��c�d��厂取flyweight�Ӟ��轻量�U�类工厂创徏一个新的具体flyweight对象�Q��ƈ且保存�v来，下次客户取用�Ӟ��׃��用重新创建，直接在保存池中返回。客戯��责处理flyweight的状态�?/p>

实例1——文档�~�辑�?/h2>

　　潜在的，每个字符都被大量的采用，因此�׃�n�q�些字符对象��会节省大量的存储空间。文档编辑器的UML�c�d��如下�Q?/p>

代码

 //Flyweight工厂
 class CharacterFactotry
    {
        private Hashtable characters = new Hashtable();
        public Character GetCharacter(char key)
        {
            //在初始化的Hashtable中取出字�W?/span>
            Character character = (Character)characters[key];
            //如果取出的字�W��ؓnull�Q�初始化�?/span>
 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)
        {
            //用字�W�数�l�创造document
 char[] document = { 'A', 'B', 'Z', 'Z', 'A', 'A' };
            CharacterFactotry f = new CharacterFactotry();
            //外部状�?/span>
 int pointSize = 12;
            //为每一个字�W���用一个flyweight对象
 foreach (char c in document)
            {
                Character character = f.GetCharacter(c);
                character.Draw(pointSize);
            }
            Console.Read();
        }
    }

优势和缺�?/h2>

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

应用情景

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

　　1. �pȝ��需要存在大量的对象而共享某些本质的、不变的信息�?/p>

　　2. 对象可以同时用于多个环境下�?/p>

　　3. 在每个实例下�Q�flyweight可以作�ؓ一个独立的对象�?/p>

明年今日 2012-10-30 15:08 发表评论

Three: Prototype Design

明年今日 — Fri, 26 Oct 2012 06:30:00 GMT

Prototype Definition

Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Class Diagram

Participants

Prototype
- declares an interface for cloning itself.
ConcretePrototype.
- implements an operation for cloning itself.
Client.
- creates a new object by asking a prototype to clone itself.

Example: Product Cache

When object instantiation is a lot more expensive than cloning, Prototype pattern may offer a useful optimization technique.

Example assumptions:

An e-commerce application gathers product information trough complex queries against a legacy database.
The legacy database is updated at predefined intervals which are known.
The number of products allows caching with a reasonable memory consumption.

When a user asks for information for a certain product the application could gather that information in two ways:

execute the complex query against legacy database, gather the information, and instantiate the object.
instantiate the objects at predefined intervals and keep them in a cache, when an object is requested, it is retrieved from cache and cloned. When the legacy database is updated, discard the content of the cache and re-load with new objects.

The second approach is based on Prototype pattern and it is illustrated below:

Example: Class Diagram

Example: Java sample code

    public abstract class Product implements Cloneable {
        private String SKU;
        private String description;

        public Object clone() {
            Object clone = null;
            try {
                clone = super.clone();
            } catch (CloneNotSupportedException e) {
                e.printStackTrace();
            }
            return clone;
        }
        public String getDescription() {
            return description;
        }
        public String getSKU() {
            return SKU;
        }
        public void setDescription(String string) {
            description = string;
        }
        public void setSKU(String string) {
            SKU = string;
        }
    }
    public class Book extends Product {
        private int numberOfPages;

        public int getNumberOfPages() {
            return numberOfPages;
        }
        public void setNumberOfPages(int i) {
            numberOfPages = i;
        }
    }
    public class DVD extends Product {
        private int duration;

        public int getDuration() {
            return duration;
        }
        public void setDuration(int i) {
            duration = i;
        }
    }
    import java.util.*;
    public class ProductCache {
        private static Hashtable productMap = new Hashtable();

        public static Product getProduct(String productCode) {
            Product cachedProduct = (Product) productMap.get(productCode);
            return (Product) cachedProduct.clone();
        }

        public static void loadCache() {
            // for each product run expensive query and instantiate product
            // productMap.put(productKey, product);
            // for exemplification, we add only two products
            Book b1 = new Book();
            b1.setDescription("Oliver Twist");
            b1.setSKU("B1");
            b1.setNumberOfPages(100);
            productMap.put(b1.getSKU(), b1);
            DVD d1 = new DVD();
            d1.setDescription("Superman");
            d1.setSKU("D1");
            d1.setDuration(180);
            productMap.put(d1.getSKU(), d1);
        }
    }
    public class Application {
        public static void main(String[] args) {
            ProductCache.loadCache();

            Book clonedBook = (Book) ProductCache.getProduct("B1");
            System.out.println("SKU = " + clonedBook.getSKU());
            System.out.println("SKU = " + clonedBook.getDescription());
            System.out.println("SKU = " + clonedBook.getNumberOfPages());

            DVD clonedDVD = (DVD) ProductCache.getProduct("D1");
            System.out.println("SKU = " + clonedDVD.getSKU());
            System.out.println("SKU = " + clonedDVD.getDescription());
            System.out.println("SKU = " + clonedDVD.getDuration());
        }
    }

Benefits

Adding and removing products at runtime.
Specifying new objects by varying values.
Specifying new objects by varying structure.
Reduced subclassing.
Configuring an application with classes dinamincally.

Usage

When the classes to instantiate are specified at run time.
When you want to avoid building a class hierarchy of factories that parallels the class hierarchy of products.
When instances of a class can have one of only a few combinations of state.

明年今日 2012-10-26 14:30 发表评论

Two: Strategy pattern

明年今日 — Mon, 25 Jun 2012 21:31:00 GMT

Strategy pattern

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.

明年今日 2012-06-26 05:31 发表评论

One: Decorator pattern

明年今日 — Mon, 25 Jun 2012 21:30:00 GMT

摘要: This pattern is designed so that multiple decorators can be stacked on top of each other, each time adding a new functionality to the overridden method(s). Introduction The decorator pattern can be u... 阅读全文

明年今日 2012-06-26 05:30 发表评论

亚洲国产精品VA在线看黑人,色婷婷亚洲一区二区三区,亚洲熟妇av一区二区三区下载

Twelve: Iterator Design Pattern

Iterator (aka Cursor) Overview

DvdListIterator.java - the Iterator Interface

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

TestDvdIterator.java - testing the iterator

Test Results

UML

References

Eleven: Memento Design Pattern

Ten: Mediator Design Pattern

Nine: Interpreter Design Pattern

Eight: State Design Pattern

Seven: Visitor Design Pattern

Six: Composite pattern

Motivation

[edit]When to use

Structure

Five: Bridge Design Pattern

Four: Flyweight Pattern

实例1——文档�~�辑�?/h2>

优势和缺�?/h2>

应用情景

Three: Prototype Design

Prototype Definition

Class Diagram

Participants

Example: Product Cache

Example: Class Diagram

Example: Java sample code

Benefits

Usage

Two: Strategy pattern

One: Decorator pattern