设计模式简介

什么是设计模式Design Pattern<o:p></o:p>

在OO Design中，reueable 是一个非常重要的组成部分。也就是说如何 让你的code能被其他的程序利用是design的关键部分！ <o:p></o:p>

让code reuseable有多种办法，除了oo language本身的hirechay等特性外，把现实中的问题记录下来，然后发表，可防止重复的开发过程。 Design Pattern就是一些已被记录的方法，并且有系统的描述。 根据 Christopher Alexander “每个pattern描述了在特定环境下发生了很多次的问题，然后你便可以描述这些问题的共性并提供解决的办法” 这就好像砖头一定是方的，这样他便能很容易地和其他砖头一起被砌成房子。 <o:p></o:p>

Java在resuseable方面有突出的表现，如interface的引入，使很多在 c++中暧昧的继承关系得到有效的解决。应该来说，java语言的本身拥有很多OO的嫡系血统，整合了现代的编程方法。当然我们都了解有关 implementation的缺陷使得它的应用受到很大限制。但从design的角度说，它的确是一种非凡的东西。这也是为什么我想用它来解释pattern的原因。 <o:p></o:p>

实例1：在sun java的native lib中，我们随处可见design pattern的身 影。比如在新的event model中，Listener 便是一种叫Observer的 pattern(MFC 中的notification 也是出于其中) <o:p></o:p>

实例2：JFC UI种的plugable Look & Feel 结合了Abstract Factory 和 Bridge Pattern。前者能产生一组widget factory，而后者则提供了建立在一致interface上具体的实现方法。

当然在实际的开发中你可能遇到各种问题，如果你能把它们系统地记录下来并提供实际的解决办法，这就可能是一种新的pattern。但记住 pattern是能解决一类问题的方法，而不是一个问题。所以对一类问题的共性归类很重要。在以后我会介绍如何来做这方面的工作。<o:p></o:p>

虽然Design Pattern源自于Object Oriented Design的方法，但它又是完全基于实践的。因此选择何种语言及上下文的关系对与读者至关重要。基本上每种Pattern都会有相应的UML(1)和Interactive Diagram(2)，同时配以简洁的示范代码来表达作者在当时的想法。<o:p></o:p>

可以想象一种Pattern的应用面决定不止以某种特定的场景。打个比方，Composite Pattern这种建立于包含关系的Object structure可以表达很多类事物，如桌面应用文件的结构，网络中分布对象的集合等等，它并没有局限于某类应用。<o:p></o:p>

而基于不同的实现语言，Pattern的实现也会很不一样。我们以后会提到的Singleton在C++中的实现和Java中的实现有很大的区别。<o:p></o:p>

大致上每种Pattern都包含了一下几个部分：<o:p></o:p>

Pattern Name: 名字<o:p></o:p>

Problem: 讲述Pattern的来源及上下文关系。问题的种类可有很多种，有时我们可能想用Objects来表达某种算法，而有时确是为了如何表达Objects之间的结构。而且在一些情况下我们还要告诉读者在碰到这个问题前，我们已经用何种方法解决了前因。<o:p></o:p>

The Solution: 解决之道。包括用哪些元素来做Design，Element之间的关系，结构，调用的顺序，变种等等。为了清晰地表达一个Design，往往辅助以UML，Interactive Diagram，Code Sample等。因为Pattern 就像一种Template，可以应用于不同的场合，所以Solution不应该是描述一种特定的设计。<o:p></o:p>

The Consequence: 结果。这是最容易被人忽视的一点。因为Design需要的Pattern并不往往是最有效率的方案，在一些情况下，我们牺牲很有效率的方案仅仅是为了让别人能看懂我们的程序。(个人认为这很重要)所以我们一定要注明在那些地方我们做了妥协。并尽可能地预计所会产生的正面及负面效果。<o:p></o:p>

注：<o:p></o:p>

UML：Unified Modeling Language是解释Objects静态关系的一种图表<o:p></o:p>

Interactive Diagram：描述Objects之间的动态关系<o:p></o:p>

看着自己以前写几篇的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)。<o:p></o:p>

按照不同的应用原则， 标准Pattern 分为三个类别<o:p></o:p>

1． "Creational Patterns" 主要用于创建Objects， 典型有Factory Pattern。<o:p></o:p>

2．"Structural Patterns" 用于组织不同的Objects并整合成复杂结构， 如 Adapter， Bridge 等<o:p></o:p>

3．"Behavioral Patterns" 主要描述了Object和class间交互的方法， 它可以把一个十分复杂控制流分解成不同的部分，并交由不同的Object处理。 如 Observer， Command等<o:p></o:p>

下面我将标准的Pattern列出：<o:p></o:p>

==============

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

继续<o:p></o:p>

从现在开始， 我将有选择地介绍不同的Patterns。<o:p></o:p>

名字:<o:p></o:p>

====

1．Factory Method， (可能是最常用的了。 )

<o:p> </o:p>

问题:

====

在一个Class继承关系中， 在最顶层的抽象类定义了一组Objects

的关系。 每个Object很可能属于另一个抽象的继承关系。而你

得Classes 处于整个关系的中间层次， 你需要不同的Class包含不

同产品。

<o:p> </o:p>

解决方法:

=======

参考一个简单的实列: 在一个Model View Control的结构中， 

抽象的Controller需要有 Model 和 View的 Interface。 

Controller的子类则需要具体的 model 和 view。 这时我们就可

以在 AbstractController中定义

<o:p> </o:p>

Class AbstractController {

abstract protected Model createModel ();

abstract protected View createView();

}

<o:p> </o:p>

每个controller的子类只需要overiden这两个method， 就可以获得

一个适合它的Model和View。 如在ConcreteController中

<o:p> </o:p>

Class ConcreteController {

  protected Model createModel(){

      return new ConcreteModel(this);

  }

<o:p> </o:p>

  protected View createView(){

    return new ConcreteView(this);

  }

}

<o:p> </o:p>

<o:p> </o:p>

这两个method就叫 "Factory Method"

<o:p> </o:p>

<o:p> </o:p>

其它扩展:

========

在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。

<o:p> </o:p>

Class DistComponent extends Component

{

。。。。。。。

  protected Graphics getGraphics() {

      if ( isRenderingRemote())

          return new RemoteGraphics();

      else

          return new LocalGraphics();

  }

。。。。。。

}

<o:p> </o:p>

在此getGraphics就是Factory Method;

<o:p> </o:p>

<o:p> </o:p>

<o:p> </o:p>

Java提供了丰富的API，同时又有强大的数据库系统作底层支持，那么我们的编程似乎变成了类似积木的简单"拼凑"和调用，甚至有人提倡"蓝领程序员"，这些都是对现代编程技术的不了解所至。

在真正可复用的面向对象编程中，GoF的《设计模式》为我们提供了一套可复用的面向对象技术，再配合Refactoring(重构方法)，所以很少存在简单重复的工作，加上Java代码的精炼性和面向对象纯洁性(设计模式是java的灵魂)，编程工作将变成一个让你时刻体验创造快感的激动人心的过程。

<o:p> </o:p>

为能和大家能共同探讨"设计模式"，我将自己在学习中的心得写下来，只是想帮助更多人更容易理解GoF的《设计模式》。由于原著都是以C++为例， 以Java为例的设计模式基本又都以图形应用为例，而我们更关心Java在中间件等服务器方面的应用，因此，本站所有实例都是非图形应用，并且顺带剖析 Jive论坛系统。同时为降低理解难度，尽量避免使用UML图。

<o:p> </o:p>

如果你有一定的面向对象编程经验，你会发现其中某些设计模式你已经无意识的使用过了;如果你是一个新手，那么从开始就培养自己良好的编程习惯(让你的的程序使用通用的模式，便于他人理解;让你自己减少重复性的编程工作)，这无疑是成为一个优秀程序员的必备条件。

<o:p> </o:p>

整个设计模式贯穿一个原理:面对接口编程，而不是面对实现。目标原则是:降低耦合，增强灵活性。

<o:p> </o:p>

1:前言

学习GoF设计模式的重要性

<o:p> </o:p>

建筑和软件中模式之异同

<o:p> </o:p>

<o:p> </o:p>

2:GoF设计模式

A。创建模式  设计模式之Factory(工厂方法和抽象工厂)

使用工厂模式就象使用new一样频繁。

<o:p> </o:p>

设计模式之Prototype(原型)

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

设计模式之Builder

汽车由车轮 方向盘 发动机很多部件组成，同时，将这些部件组装成汽车也是一件复杂的工作，Builder模式就是将这两种情况分开进行。

设计模式之Singleton(单态)

保证一个类只有一个实例，并提供一个访问它的全局访问点  

<o:p> </o:p>

B。结构模式  设计模式之Facade

可扩展的使用JDBC针对不同的数据库编程，Facade提供了一种灵活的实现。

<o:p> </o:p>

设计模式之Proxy

以Jive为例，剖析代理模式在用户级别授权机制上的应用

<o:p> </o:p>

设计模式之Adapter

使用类再生的两个方式:组合(new)和继承(extends)，这个已经在"thinking in java"中提到过。

<o:p> </o:p>

设计模式之Composite

就是将类用树形结构组合成一个单位。你向别人介绍你是某单位，你是单位中的一个元素，别人和你做买卖，相当于和单位做买卖。文章中还对Jive再进行了剖析。

设计模式之Decorator

Decorator是个油漆工，给你的东东的外表刷上美丽的颜色。

设计模式之Bridge

将"牛郎织女"分开(本应在一起，分开他们，形成两个接口)，在他们之间搭建一个桥(动态的结合)

设计模式之Flyweight

提供Java运行性能，降低小而大量重复的类的开销。

<o:p> </o:p>

C。行为模式  设计模式之Template

实际上向你介绍了为什么要使用Java 抽象类，该模式原理简单，使用很普遍。

设计模式之Memento

很简单一个模式，就是在内存中保留原来数据的拷贝。  

设计模式之Observer

介绍如何使用Java API提供的现成Observer

设计模式之Chain of Responsibility

各司其职的类串成一串，好象击鼓传花，当然如果自己能完成，就不要推委给下一个。

设计模式之Command

什么是将行为封装，Command是最好的说明。

设计模式之State

状态是编程中经常碰到的实例，将状态对象化，设立状态变换器，便可在状态中轻松切换。

设计模式之Strategy

不同算法各自封装，用户端可随意挑选需要的算法。

设计模式之Mediator

Mediator很象十字路口的红绿灯，每个车辆只需和红绿灯交互就可以。

设计模式之Interpreter

主要用来对语言的分析，应用机会不多。

设计模式之Visitor

访问者在进行访问时，完成一系列实质性操作，而且还可以扩展。

设计模式之Iterator

这个模式已经被整合入Java的Collection。在大多数场合下无需自己制造一个Iterator，只要将对象装入Collection中，直接使用Iterator进行对象遍历。

<o:p> </o:p>

<o:p> </o:p>

3:英文资料

Thinking in Patterns with Java Thinking in Java的作者Eckel又一著作!

http://www。bqlr。com/designpatterns/TIPatterns/html/Index。html

<o:p> </o:p>

CMSC491D Design Patterns In Java

http://www。research。umbc。edu/%7Etarr/cs491/fall00/cs491。html

Overview of Design Patterns 精确定义各个模式以及他们的关系

http://www。mindspring。com/%7Emgrand/pattern_synopses。htm

Design Patterns Java Companion

http://www。patterndepot。com/put/8/JavaPatterns。htm

http://www。bqlr。com/books/ejbdesignpatterns。pdf

EJB设计模式(英文) 从设计模式去理解EJB或J2EE我认为是个非常有效的办