Java 设计模式

设计模式之Chain of Responsibility -职责链
在责任链模式中,很多对象由每一个对象对其下家的引用而接 起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。
设计模式之Chain of Responsibility -职责链
晚上去上英语课,为了好开溜坐到了最后一排,哇,前面坐了好几个漂亮的MM哎,找张纸条,写上“Hi,可以做我的女朋友吗?如果不愿意请向前传”,纸条就一个接一个的传上去了,糟糕,传到第一排的MM把纸条传给老师了,听说是个老处女呀,快跑!
设计模式之Chain of Responsibility -职责链
public interface Handler{
  public void handleRequest(Request request);
}
public class Request{
  private String type;
  public Request(String type){this.type=type;}
  public String getType(){return type;}
  public void execute(){
    //request真正具体行为代码
  }
}
public class ConcreteHandler implements Handler{
  private Handler successor;
  public ConcreteHandler(Handler successor){
    this.successor=successor;
  }
  public void handleRequest(Request request){
    if (request instanceof HelpRequest){
      //这里是处理Help的具体代码
    }else if (request instanceof PrintRequst){
      request.execute();
    }else
      //传递到下一个
      successor.handle(request);
    }
  }
}
设计模式之COMMAND - 命令模式
命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,以及操作是否执行,何时被执行以及是怎么被执行的。系统支持命令的撤消。
设计模式之COMMAND - 命令模式
俺有一个MM家里管得特别严,没法见面,只好借助于她弟弟在我们俩之间传送信息,她对我有什么指示,就写一张纸条让她弟弟带给我。这不,她弟弟又传送过来一个COMMAND,为了感谢他,我请他吃了碗杂酱面,哪知道他说:“我同时给我姐姐三个男朋友送COMMAND,就数你最小气,才请我吃面。”,
设计模式之COMMAND - 命令模式
public interface Command {
  public abstract void execute ( );
}
public class producer{
  public static List produceRequests() {
    List queue = new ArrayList();
    queue.add( new DomesticEngineer() );
    queue.add( new Politician() );
    queue.add( new Programmer() );
    return queue;
  }
}
public class TestCommand {
  public static void main(String[] args) {
    
    List queue = Producer.produceRequests();
    for (Iterator it = queue.iterator(); it.hasNext(); )
        //取出List中东东,其它特征都不能确定,只能保证一个特征是100%正确,
        // 他们至少是接口Command的"儿子"。所以强制转换类别型为界面Command
        ((Command)it.next()).execute();
     }
}
设计模式之INTERPRETER -解释器模式
给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样在有了一个简单的文法后,使用模式设计解释这些语句。在解释器模式里面提到的语言是指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类的等级结构,也就是一系列的组合规则。每一个命令对象都有一个解释方法,代表对命令对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
设计模式之INTERPRETER -解释器模式
俺有一个《泡MM真经》,上面有各种泡MM的攻略,比如说去吃西餐的步骤、去看电影的方法等等,跟MM约会时,只要做一个Interpreter,照着上面的脚本执行就可以了。
设计模式之INTERPRETER -解释器模式
定义语言的文法 ,并且建立一个解释器来解释该语言中的句子。
设计模式之ITERATOR -迭代子模式
迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多个对象聚在一起形成的总体称之为聚集,聚集对象是能够包容一组对象的容器对象。迭代子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。迭代子模式简化了聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象,每一个迭代子的迭代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
设计模式之ITERATOR -迭代子模式
我爱上了Mary,不顾一切的向她求婚。
  Mary:“想要我跟你结婚,得答应我的条件”
  我:“什么条件我都答应,你说吧”
  Mary:“我看上了那个一克拉的钻石”
  我:“我买,我买,还有吗?”
  Mary:“我看上了湖边的那栋别墅”
  我:“我买,我买,还有吗?”
  Mary:“我看上那辆法拉利跑车”
  我脑袋嗡的一声,坐在椅子上,一咬牙:“我买,我买,还有吗?”
  ……
设计模式之ITERATOR -迭代子模式
用来遍历Collection中物件
public class TestCommand {
  public static void main(String[] args) {
    
    List queue = Producer.produceRequests();
    for (Iterator it = queue.iterator(); it.hasNext(); )
        //取出List中东东,其它特征都不能确定,只能保证一个特征是100%正确,
        // 他们至少是接口Command的"儿子"。所以强制转换类别型为界面Command
        ((Command)it.next()).execute();
     }
}
 
设计模式之MEDIATOR -调停者模式
调停者模式包装了一系列对象相互作用的方式,使得这些对象不必相互明显作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时,不会立即影响其它的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互作用转化为一对多的相互作用。
调停者模式将对象的行为和协作抽象化,把对象在小尺度的行为上与其它对象的相互作用分开处理。
设计模式之MEDIATOR -调停者模式
四个MM打麻将,相互之间谁应该给谁多少钱算不清楚了,幸亏当时我在旁边,按照各自的筹码数算钱,赚了钱的从我这里拿,赔了钱的也付给我,一切就OK啦,俺得到了四个MM的电话。
设计模式之MEDIATOR -调停者模式
public interface Mediator { }
public class ConcreteMediator implements Mediator {    //假设当前有两个成员.
   private ConcreteColleague1 colleague1 = new ConcreteColleague1();
   private ConcreteColleague2 colleague2 = new ConcreteColleague2();
   ... }
public class Colleague {
   private Mediator mediator;
   public Mediator getMediator() {
      return mediator;
   }
   public void setMediator( Mediator mediator ) {
      this.mediator = mediator;
   }
}
public class ConcreteColleague1 { }
public class ConcreteColleague2 { }
设计模式之MEMENTO -备忘录模式
备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下,将一个对象的状态捉住,并外部化,存储起来,从而可以在将来合适的时候把这个对象还原到存储起来的状态。
设计模式之MEMENTO -备忘录模式
同时跟几个MM聊天时,一定要记清楚刚才跟MM说了些什么话,不然MM发现了会不高兴的哦,幸亏我有个备忘录,刚才与哪个MM说了什么话我都拷贝一份放到备忘录里面保存,这样可以随时察看以前的记录啦。
设计模式之MEMENTO -备忘录模式
public class Originator {
   private int number;
   private File file = null;
  public Originator(){}  // 创建一个Memento
  public Memento getMemento(){
    return new Memento(this);
  }  // 恢复到原始值
  public void setMemento(Memento m){
     number = m.number;
     file = m.file;
  }
}
private class Memento implements java.io.Serializable{   
       private int number;
  private File file = null;
  public Memento( Originator o){
    number = o.number;
    file = o.file;
  }
}
设计模式之OBSERVER -观察者模式
观察者模式定义了一种一队多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时,会通知所有观察者对象,使他们能够自动更新自己。
设计模式之OBSERVER -观察者模式
想知道咱们公司最新MM情报吗?加入公司的MM情报邮件组就行了,tom负责搜集情报,他发现的新情报不用一个一个通知我们,直接发布给邮件组,我们作为订阅者(观察者)就可以及时收到情报啦
设计模式之OBSERVER -观察者模式
public class product extends Observable{
  private String name;
  private float price;
  public String getName(){ return name;}
  public void setName(){
   this.name=name;
  //设置变化点
   setChanged();
   notifyObservers(name);
  }   
}
public class NameObserver implements Observer{   private String name=null;
  public void update(Observable obj,Object arg){
    if (arg instanceof String){
     name=(String)arg;
     //产品名称改变值在name中
     System.out.println("NameObserver :name changet to "+name);
    }
  }
}
设计模式之STATE -状态模式
状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里,每一个状态对象都属于一个抽象状态类的一个子类。
状态模式的意图是让一个对象在其内部状态改变的时候,其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时,系统便改变所选的子类。
设计模式之OBSERVER -观察者模式
跟MM交往时,一定要注意她的状态哦,在不同的状态时她的行为会有不同,比如你约她今天晚上去看电影,对你没兴趣的MM就会说“有事情啦”,对你不讨厌但还没喜欢上的MM就会说“好啊,不过可以带上我同事么?”,已经喜欢上你的MM就会说“几点钟?看完电影再去泡吧怎么样?”,当然你看电影过程中表现良好的话,也可以把MM的状态从不讨厌不喜欢变成喜欢哦。
设计模式之OBSERVER -观察者模式
public class BlueState extends State{
   public void handlepush(Context c){
     //根据push方法"如果是blue状态的切换到green" ;
     c.setState(new GreenState());
  }
  public void handlepull(Context c){
     //根据pull方法"如果是blue状态的切换到red" ;
    c.setState(new RedState());
  }
  public abstract void getcolor(){ return (Color.blue)}
}
public class Context{
  private Sate state=null; //我们将原来的 Color state 改成了新建的State state;
  //setState是用来改变state的状态 使用setState实现状态的切换
  pulic void setState(State state){
    this.state=state;
  }
  public void push(){
    //状态的切换的细节部分,在本例中是颜色的变化,已经封装在子类别的handlepush中实现,这里无需关心
    state.handlepush(this);
    
    //因为sample要使用state中的一个切换结果,使用getColor()
    Sample sample=new Sample(state.getColor());
    sample.operate();
  }
 
  public void pull(){
    state.handlepull(this);
    
    Sample2 sample2=new Sample2(state.getColor());
    sample2.operate();
  }
}
设计模式之STRATEGY-策略模式
策略模式针对一组算法,将每一个算法封装到具有共同接口的独立的类中,从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。策略模式把行为和环境分开。环境类负责维持和查询行为类,各种算法在具体的策略类中提供。由于算法和环境独立开来,算法的增减,修改都不会影响到环境和客户端。
设计模式之STRATEGY-策略模式
跟不同类型的MM约会,要用不同的策略,有的请电影比较好,有的则去吃小吃效果不错,有的去海边浪漫最合适,单目的都是为了得到MM的芳心,我的追MM锦囊中有好多Strategy哦。
设计模式之STRATEGY-策略模式
public abstract class RepTempRule{
protected String oldString="";
public void setOldString(String oldString){
  this.oldString=oldString;
}
protected String newString="";
public String getNewString(){
  return newString;
}
 
public abstract void replace() throws Exception;
}
public class test{ ......
  public void testReplace(){    //使用第一套方案进行替换。
    RepTempRule rule=new RepTempRuleOne();
    rule.setOldString(record);
    rule.replace();   }.....
}
设计模式之TEMPLATE METHOD-模板方法模式
模板方法模式准备一个抽象类,将部分逻辑以具体方法以及具体构造子的形式实现,然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。
设计模式之TEMPLATE METHOD-模板方法模式
追MM圣经规定了追MM在不同时期有不同的步骤(Template method),但每个步骤针对不同的情况,都有不一样的做法,这就要看你随机应变啦(具体实现);
设计模式之TEMPLATE METHOD-模板方法模式
public abstract class Benchmark
{
  /**
  * 下面操作是我们希望在子类别中完成
  */
  public abstract void benchmark();   /**
  * 重复执行benchmark次数
  */
  public finalong repeat (int count) {
    if (count <= 0)
      return 0;
    else {
      long startTime = System.currentTimeMillis();    for (int i = 0; i < count; i++)
      benchmark();
    long stopTime = System.currentTimeMillis();
    return stopTime - startTime;
  }
}
}
public class MethodBenchmark extends Benchmark
{
  /**
  * 真正定义benchmark内容
  */
  public void benchmark() {
    for (int i = 0; i < Integer.MAX_VALUE; i++){
      System.out.printtln("i="+i);    
    }
  }
}
设计模式之VISITOR -访问者模式
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统,它把数据结构和作用于结构上的操作之间的耦合解脱开,使得操作集合可以相对自由的演化。访问者模式使得增加新的操作变的很容易,就是增加一个新的访问者类。访问者模式将有关的行为集中到一个访问者对象中,而不是分散到一个个的节点类中。当使用访问者模式时,要将尽可能多的对象浏览逻辑放在访问者类中,而不是放到它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。
设计模式之VISITOR -访问者模式
情人节到了,要给每个MM送一束鲜花和一张卡片,可是每个MM送的花都要针对她个人的特点,每张卡片也要根据个人的特点来挑,我一个人哪搞得清楚,还是找花店老板和礼品店老板做一下Visitor,让花店老板根据MM的特点选一束花,让礼品店老板也根据每个人特点选一张卡,这样就轻松多了;
设计模式之VISITOR -访问者模式
public interface Visitable
{
   public void accept(Visitor visitor);
}
public class ConcreteVisitor implements Visitor
{
   //在本方法中,我们实现了对Collection的元素的成功访问
   public void visitCollection(Collection collection) {
      Iterator iterator = collection.iterator()
      while (iterator.hasNext()) {
         Object o = iterator.next();
         if (o instanceof Visitable)
            ((Visitable)o).accept(this);
      }    public void visitString(String string) {
      System.out.println("'"+string+"'");
   }
   public void visitFloat(Float float) {
      System.out.println(float.toString()+"f");
   }
}
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值