关于《java与模式》一书中工厂方法模式的异议?

关于《java与模式》一书中工厂方法模式的异议?

关于工厂方法的一点讨论,我们知道工厂方法属于类型创建模式,而抽象工厂
属于对象创建模式,并且所谓的类创建模式就是把创建工作延迟到子类,而
对象创建模式则将延迟到另一个对象。
并且设计模式中指出,类模式处理类和子类子间的关系,这些关系通过继承建立,
是静态的,在编译时刻便确定下来。对象模式则处理对象之间的关系,是动态的,
运行时刻是可以变化的,更具动态性。
工厂方法由于属于类型创建模式,因此它的创建工作由子类完成,而不是使用对象进行创建,
并且在《设计模式》中工厂方法的动机一节有一个示例,
它的类大致如下:
//抽象产品,可以是接口或者抽象类
public abstract class document {
public void open(){
...............
...............
}
public void close(){
...............
...............
}
public void save();
}
//具体的产品,
public class Mydocument extends document{
public void open(){
.............
..............
}

...............

}
我们工厂方法
public abstract class appliaction {
//该方法是工厂方法,由子类实现
public abstract document createDocument();

//模板方法,在方法中使用了工厂方法
pubic void newDocument(){
//使用工厂方法,获得doc,而实际有子类完成,
//这里可以看出,对象的创建,是通过继承来实现,是静态的,编译时已经确定
//而不是通过对象的委托来实现,故属于类创建型模式
Document doc=createDocument();
doc.open();
....................
doc.save();
}
}

具体的工厂实现由子类来实现工厂方法:
public class myappliaction extends appliaction {
public document createDocument(){
return new Mydocument();
}
}

大家可以看出,这其实使用template method模式,抽象方法
声明创建对象,而模板方法完成业务逻辑,她使用抽象创建方法,由继承
来获得产品,而不是使用对象来创建对象的。

并且大家仔细看<设计模式>71页的结构图,里的creator里有两个方法,
其中一个使用factorymethod方法,另外一个就是普通的方法,
anOperation它调用了工厂方法,
product=factorymethod()来获得产品对象。


现在问题就出现在这里,而另外一本书阎宏的《java与模式》的167地结构图中
却没有把这点作出标记,并且提供的示例,也不像最初<设计模式>中的工厂方法的例子,
他的示例如下:

//抽象工厂,而这里却没有方法使用工厂方法:
public interface Creator{
/**
* 工厂方法
*/
public Product factory();
}

public class ConcreteCreator1 implements Creator
{
/**
* 工厂方法
*/
public Product factory()
{
return new ConcreteProduct1();
}
}

而客户端却使用;
public static void main(String[] args){
creator1 = new ConcreteCreator1();
prod1 = creator1.factory();
}


我感觉这样示例有问题,或者不妥,或者不能表达原意。
在客户端,他的对象创建使用了
prod1 = creator1.factory();
这样显然使用对象creator1来创建对象的,而不是使用继承,类模式来完成
创建的。这与工厂方法的原意,类模式,把创建工厂延迟到子类实现,等有冲突。
这样想对象创建模式。

我的理解不知是否有问题?我花了很多时间在这上面,国外的其他书中的例子与阎宏的也不同。
大家是怎样理解的??可以讨论

我不认为工厂方法和抽象工厂的区别在于什么类(class)型创建模式和对象(object)创建模式的区别,

抽象工厂和工厂方法的主要区别是,抽象工厂是由一个或几个工厂方法组成,创建的一系列产品类型,两者区别应该从他们原理结构上区分,而不要从代码的编译和运行机制上去区分。

如果我们使用UML来表述抽象工厂和工厂方法的区别,我不是很清楚如何表达这些语言的模式?

Java与模式 我大概看了一下目录,不少概念我也是第一次听说,可能是翻译成中文的意思不一样。

The second criterion, called scope, specifies whether the pattern applies primarily to classes or to objects. Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static―fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labeled "class patterns" are those that focus on class relationships. Note that most patterns are in the Object scope.

Creational class patterns defer some part of object creation to subclasses, while Creational object patterns defer it to another object. The Structural class patterns use inheritance to compose classes, while the Structural object patterns describe ways to assemble objects. The Behavioral class patterns use inheritance to describe algorithms and flow of control, whereas the Behavioral object patterns describe how a group of objects cooperate to perform a task that no single object can carry out alone.

在开始模式进行分类的时候,有这种分发,类模式和对象模式。并且把工厂方法模式分成类创建型模式。当然我这种太细不好,是我做设计模式讲座时遇到的一个问题? 但是工厂模式的原意,的确是gof《设计模式》的那种例子.

为什么一定要强调类模式哪,我觉得java中其实并不鼓励类继承,而且我觉得一个模式只是提供一个思想,没有必要去追究实现的细节。

工厂方法和抽象工厂只是抽象层次上的不同吧,抽象工厂对工厂又实现了一级抽象。

我个人觉得class 或object patterns的划分 对于模式理解没有多大意思。

模式理解关键是参与者角色已经他们之间的关系,引入太多概念无法快速帮助别人理解模式,模式有时就象1+1=2的公式。

着啊,模式某种意义上就应该象公式

看看下面这段吧。我觉得那些概念是为了更好的理解模式应运而生的。
先有模式,而后有概念,如果死扣概念的话,就有可能钻牛角尖。

GoF Structure Diagram Considered Harmful
There's a mistake that's repeated throughout the Design Patterns book, and unfortunately, the mistake is being repeated by new patterns authors who ape the GoF style.
Each GoF pattern has a section called "Structure" that contains an OMT (or for more recent works, UML) diagram. This "Structure" section title is misleading because it suggests that there is only one Structure of a Pattern, while in fact there are many structures and ways to implement each Pattern.

But inexperienced Patterns students and users don't know this. They read the Patterns literature too quickly, often thinking that they understand a Pattern merely by understanding it's single "Structure" diagram. This is a shortcoming of the GoF Form, one which I believe is harmful to readers.

What about all those important and subtle Implementation notes that are included with each GoF Pattern? Don't those notes make it clear that a Pattern can be implemented in many ways? Answer: No, because many folks never even read the Implementation notes. They much prefer the nice, neat Structure diagrams, because they usually only take up a third of a page, and you don't have to read and think a lot to understand them.

Diagrams are seductive, especially to engineers. Diagrams communicate a great deal in a small amount of space. But in the case of the GoF Structure Diagrams, the picture doesn't say enough. It is far more important to convey to readers that a Pattern has numerous Structures, and can be implemented in numerous ways.

I routinely ask folks to add the word "SAMPLE" to each GoF Structure diagram in the Design Patterns book. In the future, I'd much prefer to see sketches of numerous structures for each Pattern, so readers can quickly understand that there isn't just one way to implement a Pattern. But if an author will take that step, I'd suggest going even further: loose the GoF style altogether and communicate via a pattern language, rich with diagrams, strong language, code and stories.

我觉得工厂就是用来有选择地构造类。把决定因素从被构造的类中剥离出来,推迟决定。
而抽象工厂无非就是对工厂的再抽象,推迟对某些方法的实现。

如果你对creator1没有任何类型层次要求,也许称为抽象工厂是合适的;

如果你希望creator1必须是某个类型(或其子类)的实例,除了调用它的factory()以外,你还希望它满足该类型的其它接口(例如显示...等等),此时factory()就成为一个普通的虚函数,如果不同的子类对该虚函数的实现不一样,我认为称为“延迟到子类”中是贴切的。

这个示例中“Creator/ConcreteCreator1”这个类型的命名有误导之嫌,假如它的名字是“Window/BlackWindow”,“Device/Printer”,或者其它什么的,我想你会注意到其中蕴涵的“类模式”的概念。

另外,就算是抽象工厂,如果存在一组派生层次(实际上通常如此),它工作起来也就用到“工厂方法”模式,这也是《设计模式》中多次提到这两个模式常会一起使用的含义。

所谓通过“继承”建立的关系是“静态”的这种说法,只是指你在代码中“静态”地使用了受该继承关系约束的类型时,才受此约束,如果你的实现是在动态地选用不同子类的对象,其行为当然不可能编译时确定,这就回到更基本的“动态绑定”的话题,“抽象工厂/工厂方法”的组合使用,其本质就是利用“动态绑定”这个基础来动态地选用类型,大约是动态的平方这个意思。

《java与模式》(阎宏)

是个垃圾,卖的倒很火,厚的象砖头一样,实际是在骗钱。

个人就得还不如jdon里写得明白。


恨!为啥中国没出个大师级的人物,出书的都是骗子,

再也不卖国内写的书了

luyao_bai 也不要偏激,对照着看,如果你发现写的有问题,表示你进步了。多些参考资料就更好。