虽然还是小菜鸟，但既然看过了设计模式，还是希望能用起来的。

想做个自娱自乐的j2ee的东西。

关于得到数据库连接部分，一开始觉得是用工厂模式，用工厂模式得到Connection对象，试了几次好像不行。

然后尝试单态模式，创造了一个DatabaseGeneralServices类，来提供数据库连接和关闭数据库等一些通用的服务。
一切正常。有点小感悟，代码如下，希望高手指点。

package com.ClockWise.ray.persistence;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;

public class  DatabaseGeneralServices {
 private DataSource ds;
 private InitialContext ic;
 
 private static DatabaseGeneralServices dgs = new DatabaseGeneralServices();
 
 
 private DatabaseGeneralServices()//use singleton pattern, so the constructor is private
  { 
   try{
      ic = new InitialContext ();
      ds = (DataSource)ic.lookup("java:jdbc/readshare");//get database connection
  }catch(NamingException e){
   e.printStackTrace();
  }
 }
 
 public  Connection getConnection(){
  try{
   return ds.getConnection();
  }catch(SQLException e){
   e.printStackTrace();
  }
  return null;
 }
 
 public  void closeConnection(ResultSet rs,PreparedStatement ps,Connection conn){
     try{
      if(rs!=null){
       rs.close();
       }
      if(ps!=null){
       ps.close();
      }
      if(conn!=null){
       conn.close();
      }
     }catch(SQLException e ){
      e.printStackTrace();
     }
 }
 
 public static DatabaseGeneralServices getInstance()//get the sigleton instance
 {
  if(null==dgs){dgs= new DatabaseGeneralServices();} 
  return dgs;
 }

}

从这个模式的名字就可以知道个大概，Template说明这个模式有一个模版，子类都要按照父类列出的大纲来干活。在这个模式中，父类通常是abstract的。为什么不用接口？因为对某些所有子类都要用到的方法，父类中就给出了代码，而接口中是不能有具体实现代码的。

父类中有一个总的方法就是所谓的template method，这个方法通常被声明为final，这样子类就无法override它，保证了它的权威性。这个template method调用其它方法，这些“其它方法”包括了三个类型：

第一种，是abstract类型，子类需要根据自己的情况实现这部分代码；

第二种，是final型的，这种方法父类把它写死了，子类必须遵守；

第三种，就是普通方法，是optional的，子类可以延用父类的方法，也可以override掉它，写自己的代码，这种optional的方法给它一个名字叫做hook。

这个父类通常是这种形势。

abstract class AbstractClass{

  final void templateMethod(){

      a();

      b();

      c();

      …

}

    abstract void a();

    final void b(){}

    void c(){}

}

应该说这个模式既蕴含着权威性和自由性。

Iterator and Composite Patterns

       这个模式的研究对象是Collection，包括ArrayList、Array甚至还有Hashmap等等一切java里面的集合对象。Iterator的理念是把集合对象中的遍历等功能独立抽取出来，实现一个Iterator的接口，主要实现next（）和hasNext（）两个方法，这些东西和数据结构里面的东西基本一样。

而以此为基础的Composite Pattern其实就是数据结构里面树的概念，所以这里的东西还是找本数据结构书看看更好。

The State Pattern

       初看这个模式，发现里面有一个类似UML中状态图的东西，如其名字，这个模式主要描述如何处理应用中出现的“状态”。

       解决方式是这样的：

.      第一步，创建一个叫做State的接口，里面包含什么东西呢？记得UML状态图中发生状态转换时箭头上面那些改变的条件？把这些条件全部转化为方法，表示当这个条件发生时，状态该怎么变。

       第二步，每个具体的concreteState都要实现都要实现State这个接口。怎么实现？当然，state不是独立出现的，总有一个把它作为参数的类，里面有个私有变量保存当前的状态，暂且就把它称作currentState吧。接口中定义的方法，在concreteState中这样实现：每个方法根据条件定义，将currentState改成相应的状态。

       以上其实就是State Pattern的精髓。

Singleton Pattern

针对一些在应用中只会有一个对象存在的类而总结的模式。

令人意想不到的是，它是通过声明该类的构造函数为私有这种方法来实现的。

疑问就是，既然构造函数都成私有了，那怎么来创建这个类的对象呢？

解答就是通过在类中声明一个静态方法，返回这个对象。

典型的写法是

public static Singleton getInstance(){

 if(uniqueInstance==null){uniqueInstance = new Singleton();}

return uniqueInstance;

}

这个模式的精髓就这么简单，剩下的就是线程对对象的操作安全，要把这个方法加上synchronized关键字。

Command Pattern

书中是以餐馆点菜作比来讲述这个模式的。

其中的对比概念如下

Customer-------Client

Order------------Command

Waitress--------Invoker

Cook------------Receiver

Take order--------setCommand

orderUp-----------excute

怎么来解释呢？说白了，就是把调用类要达成的操作封装成一个Command对象，就像点菜那张单子一样，当然这个Command要符合一定的规则实现Command接口，里面非常重要的一个方法就是execute。

setCommand方法相当于waitress把菜单递给了厨师，在接收者方面他只管运行execute，具体做什么传过来的command对象都已经设定好了。

Adapter & Façade

适配器模式其实没什么多说的，就是要把传过去的对象要实现接收者支持的格式，那个格式实际上就是一个接口。

而Façade模式是一种衍生物，它的目的是让操作简单化。将一系列不同对象中的操作整合，提供给其它类调用接口书上的例子是家庭影院，要看部电影，要开这个电器，开那个电器，通过Façade模式，将要看电影所必须的动作整合起来，一键搞定。明白了这点，也就理解了这个模式。

Factory Pattern

书中举了匹萨店的例子，一开始的类，将制作不同类型匹萨的方法都包含在里面，整个类显得很冗余。顺着正常的思路，将制作匹萨的方法从这个类里面剥离出去单独形成一个类，这个类就像生产对象的工厂，只要你告诉它该生产的产品的型号，它就生产对应的对象再发送给客户。

按照书中的例子，如果匹萨店开在同一个城市以内，匹萨的风味多样，那么上述的模式很好地实现了上面的功能。但如果是连锁店，每个地方的风味不同呢？……

是的，每个地方的风味不同，但同一个地方不同匹萨的种类却相当有限。也就是说可以有一个匹萨店父类，然后各地的分店是这个父类的子类。而其中最重要的制作匹萨的方法在父类中被声明为虚函数，由各个具体的子类来实现。这样“工厂”又被搬回具体的类中间。

具体如何使用，我个人觉得是要看情况的。上面两个是工厂模式的两种表现形式。

    对于后一种模式，里面用到的对象，比如例子中匹萨的原材料，同样可以用工厂模式来实现，这样程序的结构就相当灵活了。

其中的“一”，类似于定报纸系统的发送方，而“多”就是订阅方。当有新的“报纸”时，发送方将最新的报纸送达订阅方手中。发送方维护着一个订阅方的列表。

文中通过一个气象站的例子来解说这个模式。WeatherData实现Subject接口，里面包括所要传送的private 数据，还有注册Observer和去除Observer的方法。当数据有所更新时调用measurementChanged方法，这个方法再调用notifyObservers方法。

而在Observer那端，有一个subject对象的私有数据，通过构造函数将要注册的Subject作为参数来对它进行初始化，以此建立Observer和Subject的联系。

最后还介绍了java那建的Observer模式。通过继承Observable来成为Subject，通过实现Observer接口来成为Observer。但其有一定弊病，因为java不支持多继承，这就限制了使用这个模式的灵活性。所以我觉得以后如果真的用到Observer模式还是自己编程比较好。

以前已经看过两章了，实在太过久远，只得重温一下。

前面的 Introduction 其实是非常有意思的，在这先不赘述了。

介绍的第一个 Pattern 是 Strategy Pattern 。

通过一个 duck 的例子，在讲述 Strategy Pattern 的过程中引出了三个 Design Principles

它们是：

1．              Identify the aspects of your application that vary and separate them from what stays the same.

2．              Program to an interface, not an implementation.

3．              Favor composition over inheritance.

Duck 例子完美地体现了以上三个 Principles 。

一开始 Duck 类是这样的，里面有三个方法： quack(), swim() 和 display(), 其它一些特殊的 Duck 子类继承这个父类，并重载 display 方法去显示各种不同种类的 Duck 。

现在需求变更，需要让一些 Duck 能够有飞的能力，理所当然地，在父类中加上了 fly() 这个方法。但一些不能飞的 Duck 类却同时拥有了 fly() 方法，这显然是不对的。

可能有人提出解决的方法是重载那些不需要 fly() 方法的 duck 类的 fly() ，让这个方法什么也不做，但你有没有想过如果这么处理，以后再加一些不需要一些方法的子类是不是很繁琐？

也许又有人想到了，把 fly() 和 quack() 提取出来，编程 interface 。如果某个子类需要这个能力可以去 implement 这个 interface 。

有没有想过后果？每一个子类都要重写 fly() 和 quack(),OO 的代码重用的特性荡然无存。

那什么才是最好的解决之道呢？？？

书里面给出了答案。

把 fly() 和 quack() 两个功能提取出来这个思路是对的。这里体现了第一个 Principle 。首先声明 FlyBehavior() 和 QuackBehavior() 两个 interface ，然后实现各种 fly 和 quack ，比如 FlyWithWings, FlyNoWay ； Quack, Squeak 等等。这里体现了第二个 Principle 。

现在的 Duck 父类已经变了，里面有两个私有变量 FlyBehavior fb, 和 QuackBehavior qb 。

Duck 父类甚至可以直接声明成 Abstract 类，当有子类继承它的时候，可以在构造函数里给 fb 和 qb 初始化的时候直接赋给它需要的 fly 和 quack 种类。这里体现了第三个 Principle 。

小小的一个例子已经分析的那么专业，让我受益匪浅。好书！