论坛首页 Java企业应用论坛

工厂方法模式和抽象工厂模式区别究竟在哪里?

浏览 27412 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2006-02-21  
pikachu 写道


楼上的正解,出发点不同,人员不同,一段代码就可能会有多种看法。

以WW的开发人员看来,他们设计框架,Action是他们的Command。从你看来你的Action像是Adaptor。为了将你的Manager适配到ww的制定接口上。


这些本身就不怎么分的清,不过有一点倒是可以作为参考

command是为了让框架结构处理未知的过程,有点回掉的味道。
Adaptor是为了让已经存在的对象转换为另一套接口上


嗯,你说的很精辟。了解了。

设计模式重的应该是意,而不是形,对吧?
0 请登录后投票
   发表时间:2006-02-22  
swiminthesea 写道
pikachu 写道


楼上的正解,出发点不同,人员不同,一段代码就可能会有多种看法。

以WW的开发人员看来,他们设计框架,Action是他们的Command。从你看来你的Action像是Adaptor。为了将你的Manager适配到ww的制定接口上。


这些本身就不怎么分的清,不过有一点倒是可以作为参考

command是为了让框架结构处理未知的过程,有点回掉的味道。
Adaptor是为了让已经存在的对象转换为另一套接口上


嗯,你说的很精辟。了解了。

设计模式重的应该是意,而不是形,对吧?


道可道,非常道
扯远了
0 请登录后投票
   发表时间:2006-02-23  
swiminthesea 写道
TO pikachu:

正好再问你一下Command模式和Adapter模式的区别。现在我怎么觉得它们两个是一样的。

以Webwork为例(因为Webwork使用了Command模式),先看看我的理解是否正确:
/**
 * 这是Webwork里面的Action接口,它充当了抽象Command的角色。
 */
public interface Action 
{
     public String execute();;
}

/**
 * 该类实现了抽象Command,扮演一个具体的Command角色
 */
public class LoginAction implements Action{
	
    // 该类是不是可以理解为一个Receiver的角色?
    private AccountManager accountManager
	
    public LoginAction(AccountManager accountManager);
   {
           this.accountManager = accountManager;
   }

   public String execute(); {
       accountManager.login();;
       return "login";
  }

}


我的理解是:Webwork中的ServletDispather充当了Invoker的角色。在一个典型的Web应用程序中,有各种请求需要处理,例如登录、查看、删除、增加、修改等等。因此根据需求的不同,会出现AccountManger,ProductManager(Receiver)等等相应的类来处理各种不同请求。然而ServletDispather并不知道该如何调用这些Receiver的方法,因此需要通过一个Action(Command)接受不同的Receiver,由Action负责调用Receiver的方法。而SerlvetDispather只需调用Action.execute()就可以了。不知道以上理解是否正确?


同时我又觉得这非常象Adapter模式。因为可以认为ServletDispather只能处理Action(Adapter模式中的Target角色)类型的接口,而我们的业务逻辑层存在大量诸如AccoutManager、ProduntManager的类(Adapter模式中的Adaptee角色),因此为了让ServletDispather来使用业务逻辑层的类,因此我们编写了诸如LoginAction、ProductAction(Adapter模式中的Adapter角色)来使用业务逻辑层的对象。因此我怎么觉得Command模式非常象Adapter模式?

我觉得不要为了使用设计模式而使用设计模式,毕竟设计模式是发现出来,要考虑具体的语境,比如ADAPTER在考虑到匹配不同接口代码的时候很容易想到,而COMMAND在考虑如何封装动作请求的时候很容易想到,所以可以把他们大致归到不同的类型,行为型模式和结构型模式.
因为设计模式背后的面向设计准则和面向设计特性都是一样的,所以每个模式看起来都有相似的地方,在做设计的时候,让设计模式慢慢的被发现和浮现出来,这样的过程也就是重构和软件系统演化的过程.
1 请登录后投票
   发表时间:2006-03-02  
受教了,

感谢楼上的几位大哥.
0 请登录后投票
   发表时间:2006-03-09  
最近,我也开始正向这方面靠近.
不过发现单靠自己也研读,也未必就能够理解大师的真正意思,所以经常来看高手们对这方面的理解.对我的帮助确实很大.
1 请登录后投票
   发表时间:2006-03-16  
工厂模式是最重要的模式,因为大多数模式都需要用到工厂模式。如果不能正确的运用工厂模式,那么可以说无法成为合格的架构师。
多数设计模式的内容讲解的都是如何设计接口。
接口如何产生呢?如果在客户代码(类库的使用者称之为客户)中直接使用具体类,那么就失去了接口的意义。因为接口的使用目的,就是要降低客户对具体类的依赖程度。如果在客户代码中直接使用接口,那么就造成了客户对具体类名称的依赖。(客户最终需要以某种方式指明所需要的具体类,如配置文件或代码,但是只需要指出一次,所以说降低对具体类的依赖程度)。要使客户代码不依赖具体类,唯一的方法,就是让客户代码不依赖具体类的部分不知道具体类的名称。知道具体类名称的部分,仅仅是配置部分。(配置文件或者配置代码)。
依赖不可能完全消除,除非二者毫无联系。但是可以将这种依赖的程度降到最低。
既然不能直接创建具体类,那么就需要通过一个创建者类来创建接口的实现类。这样就产生了工厂类。
那么现在已经知道工厂类存在的理由,抽象创建接口的过程。
这样,就可以使用简单工厂。
简单工厂,一般是两级结构。工厂类创建接口。
随着接口创建复杂性的增强,可能在接口创建的过程中,一个创建者类,无法承担创建所有的接口类的职责。
可能会有这样的情况,我们定义了一个接口,有6个实现类分别是123456号。但是,这六个实现类不可能用一个工厂创建出来,因为123号是windows下的实现,而456号是linux上的实现。(假设我们使用的语言不是广大人民群众热爱的java语言),那么这个时候,我还需要客户方用相同的方式来创建这个借口,而不是在代码中到处写
if (操作系统=="windows");{
...
}
 else{
...
}

那样就太麻烦了。设计模式就是为了减少麻烦,而不是什么别的废话,比如什么太极八卦、天人合一、面向xx之类的。因为怕麻烦,所以搞出设计模式这个咚咚减少麻烦。如果你发现用了设计模式更麻烦了,那么肯定是你用错了。
这个时候为了省事,我就把工厂也抽象成一个接口(因为我有两个相似的工厂,如果只有一个,我还废话什么呢),这样就成了工厂方法。
当然,既然工厂方法成了一个接口,那么当然也需要用一个工厂来创建它。这个时候,创建是三级结构,简单工厂(此时是工厂的工厂)创建工厂接口(本来是个类,现在因为进一步的抽象,成为接口了),工厂接口创建产品。
过了一段时间,随着我们的工厂业务不断发展,我们有了很多产品。
比如,我们有锤子和钉子两种产品。这两种产品都有windows品牌和linux品牌的。我们给锤子和钉子各自定义了一个创建的接口。
interface 锤子工厂{
造锤子();
}
interface 钉子工厂{
造钉子();;
}

可是,我们发现某些用户,用windows的锤子去敲linux的钉子,从而把程序敲出了bug。这当然是我们的错误,因为我们违反了一条金科玉律:
要想使你的程序稳定运行,你假设用户是猪。
所以,我们把锤子和钉子的工厂合并,让一个工厂只能造出配套的锤子和钉子,这样猪就没有犯错误的机会了。
于是我们搞出一个抽象工厂:
interface 铁匠铺{
造锤子();
造钉子();
}
当然,这个铁匠铺是个接口,所以同样需要用一个工厂来创建它。所以,这个时候,工厂还是三级结构。
我们的工厂,业务很多,而且产品一般都是配套使用的(这样可以多骗点钱),所以,我们大多数情况下,都是使用抽象工厂和简单工厂。简单工厂用来创建工厂,抽象工厂创建产品。
工厂的作用,就是创建接口。
其实我们不知道什么是设计模式,我们只是怕麻烦。什么是麻烦呢?
我们觉得把同样的代码写两遍就非常麻烦。所以,我们宁可多写几句,也要解决麻烦。猪不怕麻烦,可以日复一日的重复相同的事情,可是我们不是猪。
3 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics