您正在查看: Java 分类下的文章

设计模式之Strategy

设计模式之Strategy(策略)

Strategy是属于设计模式中 对象行为型模式,主要是定义一系列的算法,把这些算法一个个封装成单独的类.

Stratrgy应用比较广泛,比如, 公司经营业务变化图, 可能有两种实现方式,一个是线条曲线,一个是框图(bar),这是两种算法,可以使用Strategy实现.

这里以字符串替代为例, 有一个文件,我们需要读取后,希望替代其中相应的变量,然后输出.关于替代其中变量的方法可能有多种方法,这取决于用户的要求,所以我们要准备几套变量字符替代方案.

首先,我们建立一个抽象类RepTempRule 定义一些公用变量和方法:

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;


}

在RepTempRule中 有一个抽象方法abstract需要继承明确,这个replace里其实是替代的具体方法.
我们现在有两个字符替代方案,
1.将文本中aaa替代成bbb;
2.将文本中aaa替代成ccc;

对应的类分别是RepTempRuleOne RepTempRuleTwo

public class RepTempRuleOne extends RepTempRule{


public void replace() throws Exception{

  //replaceFirst是jdk1.4新特性
  newString=oldString.replaceFirst("aaa", "bbbb")
  System.out.println("this is replace one");
  
}


}

public class RepTempRuleTwo extends RepTempRule{


public void replace() throws Exception{

  newString=oldString.replaceFirst("aaa", "ccc")
  System.out.println("this is replace Two");
  
}


}

第二步:我们要建立一个算法解决类,用来提供客户端可以自由选择算法。

public class RepTempRuleSolve {

  private RepTempRule strategy;

  public RepTempRuleSolve(RepTempRule rule){
    this.strategy=rule;
  }

  public String getNewContext(Site site,String oldString) {
    return strategy.replace(site,oldString);
  }

  public void changeAlgorithm(RepTempRule newAlgorithm) {
    strategy = newAlgorithm;
  }

}

调用如下:

public class test{

......

  public void testReplace(){

  //使用第一套替代方案
  RepTempRuleSolve solver=new RepTempRuleSolve(new RepTempRuleSimple());
  solver.getNewContext(site,context);

  //使用第二套

  solver=new RepTempRuleSolve(new RepTempRuleTwo());
  solver.getNewContext(site,context);

  }

.....

}

我们达到了在运行期间,可以自由切换算法的目的。

实际整个Strategy的核心部分就是抽象类的使用,使用Strategy模式可以在用户需要变化时,修改量很少,而且快速.

Strategy和Factory有一定的类似,Strategy相对简单容易理解,并且可以在运行时刻自由切换。Factory重点是用来创建对象。

Strategy适合下列场合:

1.以不同的格式保存文件;

2.以不同的算法压缩文件;

3.以不同的算法截获图象;

4.以不同的格式输出同样数据的图形,比如曲线 或框图bar等

设计模式之Chain of Responsibility

设计模式之Chain of Responsibility(职责链)

Chain of Responsibility定义
Chain of Responsibility(CoR) 是用一系列类(classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说,来了一个请求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去。

如何使用?
虽然这一段是如何使用CoR,但是也是演示什么是CoR.

有一个Handler接口:

public interface Handler{
  public void handleRequest();
}

这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化:

最先想到的解决方案是:在接口中增加多个请求:
public interface Handler{
  public void handleHelp();
  public void handlePrint();
  public void handleFormat();

}

具体是一段实现接口Handler代码:
public class ConcreteHandler implements Handler{
  private Handler successor;

  public ConcreteHandler(Handler successor){
  this.successor=successor;
}

  public void handleHelp(){
    //具体处理请求Help的代码
    ...
  }

  public void handlePrint(){
    //如果是print 转去处理Print
    successor.handlePrint();
  }
  public void handleFormat(){
    //如果是Format 转去处理format
    successor.handleFormat();
  }

}
一共有三个这样的具体实现类,上面是处理help,还有处理Print 处理Format这大概是我们最常用的编程思路。

虽然思路简单明了,但是有一个扩展问题,如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。

第二方案:将每种request都变成一个接口,因此我们有以下代码 :

public interface HelpHandler{
  public void handleHelp();
}

public interface PrintHandler{
  public void handlePrint();
}

public interface FormatHandler{
  public void handleFormat();
}

public class ConcreteHandler
  implements HelpHandler,PrintHandler,FormatHandlet{
  private HelpHandler helpSuccessor;
  private PrintHandler printSuccessor;
  private FormatHandler formatSuccessor;

  public ConcreteHandler(HelpHandler helpSuccessor,PrintHandler printSuccessor,FormatHandler             formatSuccessor)
  {
    this.helpSuccessor=helpSuccessor;
    this.printSuccessor=printSuccessor;
    this.formatSuccessor=formatSuccessor;
  }

  public void handleHelp(){
    .......
  }

  public void handlePrint(){this.printSuccessor=printSuccessor;}

  public void handleFormat(){this.formatSuccessor=formatSuccessor;}

}

这个办法在增加新的请求request情况下,只是节省了接口的修改量,接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。

解决方案3: 在Handler接口中只使用一个参数化方法:
public interface Handler{
  public void handleRequest(String request);
}
那么Handler实现代码如下:
public class ConcreteHandler implements Handler{
  private Handler successor;

  public ConcreteHandler(Handler successor){
    this.successor=successor;
  }

  public void handleRequest(String request){
    if (request.equals("Help")){
      //这里是处理Help的具体代码
    }else
      //传递到下一个
      successor.handle(request);

    }
  }

}

这里先假设request是String类型,如果不是怎么办?当然我们可以创建一个专门类Request

最后解决方案:接口Handler的代码如下:
public interface Handler{
  public void handleRequest(Request request);
}
Request类的定义:
public class Request{
  private String type;

  public Request(String type){this.type=type;}

  public String getType(){return type;}

  public void execute(){
    //request真正具体行为代码
  }
}
那么Handler实现代码如下:
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);

    }
  }

}

这个解决方案就是CoR, 在一个链上,都有相应职责的类,因此叫Chain of Responsibility.

CoR的优点:
因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。

缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR

扩展性差,因为在CoR中,一定要有一个统一的接口Handler.局限性就在这里。

设计模式之Observer

设计模式之Observer

Java深入到一定程度,就不可避免的碰到设计模式(design pattern)这一概念,了解设计模式,将使自己对java中的接口或抽象类应用有更深的理解.设计模式在java的中型系统中应用广泛,遵循一定的编程模式,才能使自己的代码便于理解,易于交流,Observer(观察者)模式是比较常用的一个模式,尤其在界面设计中应用广泛,而本站所关注的是Java在电子商务系统中应用,因此想从电子商务实例中分析Observer的应用.

虽然网上商店形式多样,每个站点有自己的特色,但也有其一般的共性,单就"商品的变化,以便及时通知订户"这一点,是很多网上商店共有的模式,这一模式类似Observer patern.

具体的说,如果网上商店中商品在名称 价格等方面有变化,如果系统能自动通知会员,将是网上商店区别传统商店的一大特色.这就需要在商品product中加入Observer这样角色,以便product细节发生变化时,Observer能自动观察到这种变化,并能进行及时的update或notify动作.

Java的API还为为我们提供现成的Observer接口Java.util.Observer.我们只要直接使用它就可以.

我们必须extends Java.util.Observer才能真正使用它:
1.提供Add/Delete observer的方法;
2.提供通知(notisfy) 所有observer的方法;

//产品类 可供Jsp直接使用UseBean调用 该类主要执行产品数据库插入 更新
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 float getPrice(){ return price;}
  public void setPrice(){
   this.price=price;
  //设置变化点
   setChanged();
   notifyObservers(new Float(price));

  }

  //以下可以是数据库更新 插入命令.
  public void saveToDb(){
  .....................

}


我们注意到,在product类中 的setXXX方法中,我们设置了 notify(通知)方法, 当Jsp表单调用setXXX(如何调用见我的另外一篇文章),实际上就触发了notisfyObservers方法,这将通知相应观察者应该采取行动了.

下面看看这些观察者的代码,他们究竟采取了什么行动:

//观察者NameObserver主要用来对产品名称(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);

    }

  }

}

//观察者PriceObserver主要用来对产品价格(price)进行观察的
public class PriceObserver implements Observer{

  private float price=0;

  public void update(Observable obj,Object arg){

    if (arg instanceof Float){

     price=((Float)arg).floatValue();
  
     System.out.println("PriceObserver :price changet to "+price);

    }

  }

}


Jsp中我们可以来正式执行这段观察者程序:

<jsp:useBean id="product" scope="session" class="Product" />
<jsp:setProperty name="product" property="*" />

<jsp:useBean id="nameobs" scope="session" class="NameObserver" />
<jsp:setProperty name="product" property="*" />

<jsp:useBean id="priceobs" scope="session" class="PriceObserver" />
<jsp:setProperty name="product" property="*" />

<%

if (request.getParameter("save")!=null)
{
  product.saveToDb();


  out.println("产品数据变动 保存! 并已经自动通知客户");

}else{

  //加入观察者
  product.addObserver(nameobs);

  product.addObserver(priceobs);

%>

  //request.getRequestURI()是产生本jsp的程序名,就是自己调用自己
  <form action="<%=request.getRequestURI()%>" method=post>

  <input type=hidden name="save" value="1">
  产品名称:<input type=text name="name" >
  产品价格:<input type=text name="price">
  <input type=submit>

  </form>

<%

}

%>

执行改Jsp程序,会出现一个表单录入界面, 需要输入产品名称 产品价格, 点按Submit后,还是执行该jsp的
if (request.getParameter("save")!=null)之间的代码.


由于这里使用了数据javabeans的自动赋值概念,实际程序自动执行了setName setPrice语句.你会在服务器控制台中发现下面信息::

NameObserver :name changet to ?????(Jsp表单中输入的产品名称)

PriceObserver :price changet to ???(Jsp表单中输入的产品价格);

这说明观察者已经在行动了.!!
同时你会在执行jsp的浏览器端得到信息:

产品数据变动 保存! 并已经自动通知客户

上文由于使用jsp概念,隐含很多自动动作,现将调用观察者的Java代码写如下:

public class Test {

  public static void main(String args[]){

Product product=new Product();

NameObserver nameobs=new NameObserver();
PriceObserver priceobs=new PriceObserver();

//加入观察者
product.addObserver(nameobs);
product.addObserver(priceobs);

product.setName("橘子红了");
product.setPrice(9.22f);

  }

}

你会在发现下面信息::

NameObserver :name changet to 橘子红了

PriceObserver :price changet to 9.22

这说明观察者在行动了.!!

设计模式之Memento

设计模式之Memento(备忘机制)

Memento定义:
memento是一个保存另外一个对象内部状态拷贝的对象.这样以后就可以将该对象恢复到原先保存的状态.

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;
  }

}

我们再看看Memento类:

private class Memento implements java.io.Serializable{

  private int number;

  private File file = null;

  public Memento( Originator o){

    number = o.number;
    file = o.file;

  }

}

可见 Memento中保存了Originator中的number和file的值. 通过调用Originator中number和file值改变的话,通过调用setMemento()方法可以恢复.

Memento模式的缺点是耗费大,如果内部状态很多,再保存一份,无意要浪费大量内存.

Memento模式在Jsp+Javabean中的应用
在Jsp应用中,我们通常有很多表单要求用户输入,比如用户注册,需要输入姓名和Email等, 如果一些表项用户没有填写或者填写错误,我们希望在用户按"提交Submit"后,通过Jsp程序检查,发现确实有未填写项目,则在该项目下红字显示警告或错误,同时,还要显示用户刚才已经输入的表项.

如下图中 First Name是用户已经输入,Last Name没有输入,我们则提示红字警告.:

这种技术的实现,就是利用了Javabean的scope="request"或scope="session"特性,也就是Memento模式.

具体示例和代码见 JavaWorld的英文原文 , Javabean表单输入特性参见我的另外一篇文章.

设计模式之Flyweight

设计模式之Flyweight(享元)

Flyweight定义:
避免大量拥有相同内容的小类的开销(如耗费内存),使大家共享一个类(元类).

为什么使用?
面向对象语言的原则就是一切都是对象,但是如果真正使用起来,有时对象数可能显得很庞大,比如,字处理软件,如果以每个文字都作为一个对象,几千个字,对象数就是几千,无疑耗费内存,那么我们还是要"求同存异",找出这些对象群的共同点,设计一个元类,封装可以被共享的类,另外,还有一些特性是取决于应用(context),是不可共享的,这也Flyweight中两个重要概念内部状态intrinsic和外部状态extrinsic之分.

说白点,就是先捏一个的原始模型,然后随着不同场合和环境,再产生各具特征的具体模型,很显然,在这里需要产生不同的新对象,所以Flyweight模式中常出现Factory模式.Flyweight的内部状态是用来共享的,Flyweight factory负责维护一个Flyweight pool(模式池)来存放内部状态的对象.

Flyweight模式是一个提高程序效率和性能的模式,会大大加快程序的运行速度.应用场合很多:比如你要从一个数据库中读取一系列字符串,这些字符串中有许多是重复的,那么我们可以将这些字符串储存在Flyweight池(pool)中.

如何使用?

我们先从Flyweight抽象接口开始:

public interface Flyweight
{
  public void operation( ExtrinsicState state );
}

//用于本模式的抽象数据类型(自行设计)
public interface ExtrinsicState { }

下面是接口的具体实现(ConcreteFlyweight) ,并为内部状态增加内存空间, ConcreteFlyweight必须是可共享的,它保存的任何状态都必须是内部(intrinsic),也就是说,ConcreteFlyweight必须和它的应用环境场合无关.

public class ConcreteFlyweight implements Flyweight {
  private IntrinsicState state;
  
  public void operation( ExtrinsicState state )
  {
      //具体操作
  }

}

当然,并不是所有的Flyweight具体实现子类都需要被共享的,所以还有另外一种不共享的ConcreteFlyweight:

public class UnsharedConcreteFlyweight implements Flyweight {

  public void operation( ExtrinsicState state ) { }

}

Flyweight factory负责维护一个Flyweight池(存放内部状态),当客户端请求一个共享Flyweight时,这个factory首先搜索池中是否已经有可适用的,如果有,factory只是简单返回送出这个对象,否则,创建一个新的对象,加入到池中,再返回送出这个对象.池

public class FlyweightFactory {
  //Flyweight pool
  private Hashtable flyweights = new Hashtable();

  public Flyweight getFlyweight( Object key ) {

    Flyweight flyweight = (Flyweight) flyweights.get(key);

    if( flyweight == null ) {
      //产生新的ConcreteFlyweight
      flyweight = new ConcreteFlyweight();
      flyweights.put( key, flyweight );
    }

    return flyweight;
  }
}

至此,Flyweight模式的基本框架已经就绪,我们看看如何调用:

FlyweightFactory factory = new FlyweightFactory();
Flyweight fly1 = factory.getFlyweight( "Fred" );
Flyweight fly2 = factory.getFlyweight( "Wilma" );
......

从调用上看,好象是个纯粹的Factory使用,但奥妙就在于Factory的内部设计上.

Flyweight模式在XML等数据源中应用
我们上面已经提到,当大量从数据源中读取字符串,其中肯定有重复的,那么我们使用Flyweight模式可以提高效率,以唱片CD为例,在一个XML文件中,存放了多个CD的资料.

每个CD有三个字段:
1.出片日期(year)
2.歌唱者姓名等信息(artist)
3.唱片曲目 (title)

其中,歌唱者姓名有可能重复,也就是说,可能有同一个演唱者的多个不同时期 不同曲目的CD.我们将"歌唱者姓名"作为可共享的ConcreteFlyweight.其他两个字段作为UnsharedConcreteFlyweight.

首先看看数据源XML文件的内容:


<?xml version="1.0"?>
<collection>

<cd>
<title>Another Green World</title>
<year>1978</year>
<artist>Eno, Brian</artist>
</cd>

<cd>
<title>Greatest Hits</title>
<year>1950</year>
<artist>Holiday, Billie</artist>
</cd>

<cd>
<title>Taking Tiger Mountain (by strategy)</title>
<year>1977</year>
<artist>Eno, Brian</artist>
</cd>

.......

</collection>


虽然上面举例CD只有3张,CD可看成是大量重复的小类,因为其中成分只有三个字段,而且有重复的(歌唱者姓名).

CD就是类似上面接口 Flyweight:


public class CD {

  private String title;
  private int year;
  private Artist artist;

  public String getTitle() {  return title; }
  public int getYear() {    return year;  }
  public Artist getArtist() {    return artist;  }

  public void setTitle(String t){    title = t;}
  public void setYear(int y){year = y;}
  public void setArtist(Artist a){artist = a;}

}

将"歌唱者姓名"作为可共享的ConcreteFlyweight:

public class Artist {

  //内部状态
  private String name;

  // note that Artist is immutable.
  String getName(){return name;}

  Artist(String n){
    name = n;
  }

}

再看看Flyweight factory,专门用来制造上面的可共享的ConcreteFlyweight:Artist

public class ArtistFactory {

  Hashtable pool = new Hashtable();

  Artist getArtist(String key){

    Artist result;
    result = (Artist)pool.get(key);
    ////产生新的Artist
    if(result == null) {
      result = new Artist(key);
      pool.put(key,result);
      
    }
    return result;
  }

}

当你有几千张甚至更多CD时,Flyweight模式将节省更多空间,共享的flyweight越多,空间节省也就越大.