什么是Design Pattern...
在OO Design中，reueable 是一个非常重要的组成部分。也就是说如何让你的code能被其他的程序利用是design的要害部分！
让code reuseable有多种办法，除了oo language本身的hirechay等特性外，把现实中的问题记录下来，然后发表，可防止重复的开发过程。
Design Pattern就是一些已被记录的方法，并且有系统的描述。
根据 Christopher Alexander “每个pattern描述了在特定环境下发生了很多次的问题，然后你便可以描述这些问题的共性并提供解决的办法”
这就好象砖头一定是方的，这样他便能很轻易地和其他砖头一起被砌成房子。
Java在resuseable方面有突出的表现，如interface的引入，使很多在c++中暧昧的继续关系得到有效的解决。应该来说，java语言的本身拥有很多OO的嫡系血统，整合了现代的编程方法。当然我们都了解有关
implementation的缺陷使得它的应用受到很大限制。但从design的角度说，它的确是一种非凡的东西。这也是为什么我想用它来解释pattern的原因。
实例1：在sun java的native lib中，我们随处可见design pattern的身影。比如在新的event model中，Listener 便是一种叫Observer的pattern(MFC 中的notification 也是出于其中)
实例2：JFC UI种的plugable Look & Feel 结合了Abstract Factory 和Bridge Pattern。前者能产生一组widget factory,而后者则提供了建立
在一致interface上具体的实现方法。
当然在实际的开发中你可能碰到各种问题，假如你能把它们系统地记录下来并提供实际的解决办法，这就可能是一种新的pattern。但记住pattern是能解决一类问题的方法，而不是一个问题。所以对一类问题的共性归类很重要。在以后我们会介绍如何来做这方面的工作。
后：
1.小弟的中文水平差的可以，那位仁兄能帮忙指正的话，在下感激不尽。
2.做比说重要。
3.多谢compiler的鼓励，希望能共同努力，把这一系列写完
4.这里到底是不是java group? 怎么尽是些不着边际的post.
上一次我们主要介绍了什么是Design Pattern，作为一部分的补充，这次想讨论一下记录Design Pattern的格式和方法。
虽然Design Pattern源自于Object Oriented Design的方法，但它又是完全基于实践的。因此选择何种语言及上下文的关系对与读者至关重要。
基本上每种Pattern都会有相应的UML(1)和Interactive Diagram(2),同时配以简洁的示范代码来表达作者在当时的想法。
可以想象一种Pattern的应用面决定不止以某种特定的场景。打个比方，Composite Pattern这种建立于包含关系的object strUCture可以表达很多类事物，如桌面应用文件的结构，网络中分布对象的集合等等，它并没有局限于某类应用。
而基于不同的实现语言，Pattern的实现也会很不一样。我们以后会提到的Singleton在C++中的实现和Java中的实现有很大的区别。
大致上每种Pattern都包含了一下几个部分。
Pattern Name: 名字
Problem: 讲述Pattern的来源及上下文关系。问题的种类可有很多种，有时我们可能想用objects来表达某种算法，而有时确是为了如何表达objects之间的结构。而且在一些情况下我们还要告诉读者在碰到这个问题前，我们已经用何种方法解决了前因。
The Solution:解决之道。包括用哪些元素来做Design，Element之间的关系，结构，调用的顺序，变种等等。为了清析的表达一个Design，往往辅助以UML,Interactive Diagram,Code Sample等。因为Pattern 就象一种
Tempelate,可以应用于不同的场合，所以Solution不应该是描述一中特定的设计。
The Consequence:结果。这是最轻易被人忽视的一点。因为Design的需要Pattern并不往往是最有效率的方案，在一些情况下，我们牺牲很有效率的方案仅仅是为了让别人能看懂我们的程序。(个人认为这很重要)所以我们一定要注明在那些地方我们做了妥协。并尽可能地预计所会产生的正面及负面效果。
注：
UML:Unified Modeling Language是解释Objects静态关系的一种图表
Interactive Diagram：描述objects之间的动态关系
看着自己以前写几篇的Design Pattern文章,越看越喜欢.
算了, 不管有没有人看,写下去再说!
上几次主要介绍了Design Pattern的基本概念,和文档的
格式. Design Pattern在现实的世界中共有23种标准的
pattern. 最早出现在由Erich Gamma, Richard Helm,
Ralph Johnson和John Vlissides编写的"Design Patterns"
一书. 由于此书一成为OO Design的标准参考书之一, 所以许多专家建议在实际开发中,Developers 应该用标准的pattern来相互交流, 以便于了解彼此的设计思想. Java的标准库便运用此原则, 对于标准Pattern的扩展, 大多也有明确的出处(如Listener便源自于Observer).
按照不同的应用原则, 标准Pattern 分为三个类别
1. "Creational Patterns" 主要用于创建Objects, 典型
有Factory Pattern.
2. "Structural Patterns" 用于组织不同的objects并整合成复杂结构, 如 Adapter, Bridge 等
3. "Behavioral Patterns" 主要描述了object和class间交互的方法, 它可以把一个十分复杂控制流分解成不同的部分,并交由不同的object处理. 如 Observer, Command等
下面我将标准的Pattern列出:
==============
Creational Patterns
==============
* Abstract Factory
* Builder
* Factory Method
* Prototype
* Singleton
==============
Structural Patterns
==============
* Adapter
* Bridge
* Composite
* Decorator
* Facade
* Flyweight
* Proxy
==============
Behavioral Patterns
==============
* Chain Of Responsibility
* Command
* Interpreter
* Iterator
* Mediator
* Memento
* Observer
* State
* Strategy
* Template Method
* Visitor
现在开始, 我将有选择地介绍不同的Patterns
名字:
====
1. Factory Method, (可能是最常用的了. )
问题:
====
在一个Class继续关系中, 在最顶层的抽象类定义了一组objects
的关系. 每个object很可能属于另一个抽象的继续关系.而你
得Classes 处于整个关系的中间层次, 你需要不同的Class包含不同产品.
解决方法:
=======
参考一个简单的实列: 在一个Model View Control的结构中,
抽象的Controller需要有 Model 和 View的 Interface.
Controller的子类则需要具体的 model 和 view. 这时我们就可
以在 AbstractController中定义
Class AbstractController {
abstract protected Model createModel ();
abstract protected View createView();
}
每个controller的子类只需要overiden这两个method, 就可以获得
一个适合它的Model和View. 如在ConcreteController中
Class ConcreteController {
protected Model createModel(){
return new ConcreteModel(this);
}
protected View createView(){
return new ConcreteView(this);
}
}
这两个method就叫 "Factory Method"
其它扩展:
========
在MVC的列子中, factory method应用于hireachy中, 我们还可以在一个单一的class中根据不同的要求创建不同的产品. 设想有一中Java的component可以象 Xwindow 一样, 程序的 presentation 可以在本地的host上,也可以在remote host上. 这就需要有两种Graphics来帮助component的 rendering. 一种是LocalGraphics, 一种是RemoteGraphics. 它们都是
java.awt.Graphic的子类. 那么我们的这种非凡的component就需要overiden
Component中getGraphics()这个method.
Class DistComponent extends Component
{
.......
protected Graphics getGraphics() {
if ( isRenderingRemote())
return new RemoteGraphics();
else
return new LocalGraphics();
}
......
}
在此getGraphics就是Factory Method;
|
