class Children{
 static private Vector<Observer> obs;
 static private String state=null;
 static{
  obs=new Vector<Observer>();
 }
 public static void attach(Observer o){
  obs.addElement(o);
 }
 public static void detach(Observer o){
  obs.removeElement(o);
 }
 public void setState(String str){
  state=str;
 }
 public String getState(){
  return state;
 }
 public void notifyObs(){
  for(Observer o:obs){
   o.update(this); 
  }
 }
}
interface Observer{
 public void update(Children child);
}
class Parent implements Observer{
 public void update(Children child){
  if(child.getState().equals("fight")){
   System.out.println("Parent，他和别人打架了");
  }else if(child.getState().equals("scholarship")){
   System.out.println("告诉Parent,他得到了奖学金");
  }
 }
}
class Mother implements Observer{
 public void update(Children child){
  if(child.getState().equals("fight")){
   System.out.println("告诉Mother，他和别人打架了");
  }else if(child.getState().equals("scholarship")){
   System.out.println("告诉Mother,他得到了奖学金");
  }
 }
}
public class Client {

 public static void main(String[] args) {
  Children child=new Children();
  Observer parent=new Parent();
  Observer mother=new Mother();
  child.attach(parent);
  child.attach(mother);
  child.setState("fight");
  child.notifyObs();
  child.setState("scholarship");
  child.notifyObs();

 }

}

输出如下:
告诉Parent，他和别人打架了
告诉Mother，他和别人打架了
告诉Parent,他得到了奖学金
告诉Mother,他得到了奖学金
 小结：对于Observer模式，触发事件的对象-Subject对象无法预测可能需要知道该事件的所有对象。为了解决这一问题，我们创建一个Observer接口，要求所有的Observer负责将自己注册到Subject上。

代码如下：
abstract class Component{
 abstract public void printTicket();
}
class SalesTicket extends Component{
 public void printTicket() {
  System.out.println("打印出salesTicket的内容");
 }
}
abstract class TicketDecorator extends Component{
 private Component myTrailer;
 public TicketDecorator(Component myComponent){
  myTrailer=myComponent;
 }
 public void callTrailer(){
  if(myTrailer!=null)
   myTrailer.printTicket();
 }
}
class Header extends TicketDecorator{
 public Header(Component myComponent){
  super(myComponent);
 }
 public void printTicket(){
  System.out.println("打印salesTicket的头信息");
  super.callTrailer();
  
 }
}
class Footer extends TicketDecorator{
 public Footer(Component myComponent){
  super(myComponent);
 }
 public void printTicket(){
  super.callTrailer();
  System.out.println("打印salesTicket的页脚信息");
 }
}
public class Client {

 public static void main(String[] args) {
  System.out.println("====================================");
  new Header(new Footer(new SalesTicket())).printTicket();
  System.out.println("====================================");
  new Footer(new Header(new SalesTicket())).printTicket();
  System.out.println("====================================");
 }

}
输出结果如下:
====================================
打印salesTicket的头信息
打印出salesTicket的内容
打印salesTicket的页脚信息
====================================
打印salesTicket的头信息
打印出salesTicket的内容
打印salesTicket的页脚信息
====================================
从这个例子我们可以看出，Decorator模式把问题分为两部分：
1） 如何实现提供新功能的对象。
2） 如何为每种特殊情况组织对象。
这样能够将Decorator对象的实现与决定如何使用Decorator的对象分离开来，从而提高了内聚性，因为每个Decorator对象只用关心自己添加的功能，无需关心自己是如何被加入到对象链中。还可以任意地重排Decorator的顺序，无需改变其任何代码。
小结：Decorator模式的适用场合是，各种可选的功能在另一个肯定要执行的功能之前或之后执行。

    为创建一组相关或相互依赖的对象提供一个接口，而且无需指定它们的具体类。
  大致意思是说：我们在创建这些对象的时候，并不需要指定它们的具体类，这些具体类的对象是由工厂对象负责实例化的。下面是《Design Patterns Explained》一书的例子，有关计算机系统的显示和打印程序，用来显示和打印的分辨率取决于当前运行的系统。低端机使用低分辨率的显示和打印驱动程序，高端机使用高分辨率的显示和打印驱动程序。其结构图如下：

代码如下:

abstract class ResFactory{

    abstract public DisplayDriver getDisplayDrvr();

    abstract public PrintDriver getPrintDrvr();

}

class LowResFact extends ResFactory{

    public DisplayDriver getDisplayDrvr() {

        returnnew LRDD();

    }

    public PrintDriver getPrintDrvr() {

        returnnew LRPD();

    }

}

class HighResFact extends ResFactory{

    public DisplayDriver getDisplayDrvr() {

        returnnew HRDD();

    }

    public PrintDriver getPrintDrvr() {

        returnnew HRPD();

    }

}

abstract class DisplayDriver{

}

abstract class PrintDriver{

}

class HRDD extends DisplayDriver{
    public HRDD() {
        System.out.println("使用高端机的显示驱动程序")
 } 

}

class LRDD extends DisplayDriver{

    public LRDD(){

        System.out.println("使用低端机的显示驱动程序");

    } 

}

class HRPD extends PrintDriver{

    public HRPD() {

        System.out.println("使用高端机的打印驱动程序");

    }

}

class LRPD extends PrintDriver{

    public LRPD() {

        System.out.println("使用低端机的打印驱动程序");

    } 

}

public class ApControl {

    public static ResFactory getResFactory(ResFactory factory){

        return factory;

    }

    public static void main(String[] args) {

        ResFactory highResFact=ApControl.getResFactory(new HighResFact());

        highResFact.getDisplayDrvr();

        highResFact.getPrintDrvr();

        ResFactory lowResFact=ApControl.getResFactory(new LowResFact());

        lowResFact.getDisplayDrvr();

        lowResFact.getPrintDrvr();

    }

}输出结果：

使用高端机的显示驱动程序

使用高端机的打印驱动程序

使用低端机的显示驱动程序

使用低端机的打印驱动程序

    在这个例子中ApControl使用派生自两个不同的服务类(DisplayDriver和PrintDriver)的对象。这个设计非常简化，隐藏了实现细节，系统的可维护性也更好。ApControl不知道自己拥有的服务对象的那个特定具体实现，因为创建对象是工厂的职责。ApControl也不知道自己使用的是哪个特定工厂，因为它只知道自己有一个ResFactory对象。它可能是一个HighResFact也可能是一个LowResFact，但它不知道到底是哪一个。

    小结：在必须协调一组对象的创建时，可以应用Abstract Factory模式。它提供了一种方式，将如何执行对象实例化的规则从使用这些对象的客户对象中提取出来。首先，找出实例化的规则，定义了一个带接口的抽象类，其中的接口为每种需要实例化的对象提供一个方法。然后，从这个类为每个组实现具体类。最后，由客户对象决定使用具体工厂来创建所需的对象。它主要适用于以下几种情况:

1)     一个系统要独立于它的产品的创建、组合和表示时。

2)    可以对系统进行配置，以便系统可以使用多个产品系列中的某一个。

3)    当需要强调一系列相关产品对象的设计以便进行联合使用时。

4)    当希望提供一个产品类库，而只想显示他们的接口而不是实现时。

将抽象与其实现解耦，使它们都可以独立地变化。

大致意思是说：将一组实现与另一组使用他们的对象分离。这里的实现指的是抽象类及其

派生类用来实现自己的对象（而不是抽象类的派生类，这些派生类被称为具体类）。下面

是《Design Patterns Explained》书中的例子。其结构图如下：
  

下面是它的实现：

abstract　class Shape{

    protected Drawing myDrawing;

    abstract　public　void draw();

    Shape(Drawing drawing){

        myDrawing=drawing;

    }

    protected　void drawLine(){

        myDrawing.drawLine();

    }

    protected　void drawCircle(){

        myDrawing.drawCircle();

    }

}

class Rectangle extends Shape{

    public Rectangle(Drawing darw){

        super(darw);

    }

    public　void draw(){

        drawLine();

        drawLine();

        drawLine();

        drawLine();

    }

}

 class Circle extends Shape{

    public Circle(Drawing draw){

        super(draw);

    }

    publicvoid draw(){

        myDrawing.drawCircle();

    }

}

abstract　class Drawing{

    abstract　public　void drawLine();

    abstract　public　void drawCircle();

}

class V1Drawing extends Drawing{

    public　void drawLine(){

        DP1.draw_a_line();

    }

    public　void drawCircle(){

        DP1.draw_a_circle();

    }

}

class V2Drawing extends Drawing{

    public　void drawLine(){

        DP2.drawLine();

    }

    public　void drawCircle(){

        DP2.drawCircle();

    }

}

class DP1{

    public　static　void draw_a_line(){

        System.out.println("使用DP1的draw_a_line()画线");

    }

    public　static　void draw_a_circle(){

        System.out.println("使用DP1的draw_a_circle()画圆");

    }

}

class DP2{

    public　static　void drawLine(){

        System.out.println("使用DP2的drawLine()画线");

    }

    public　static　void drawCircle(){

        System.out.println("使用DP2的drawCircle()画圆");

    }

}

 public　class BridgeClient {

    public　static　void main(String[] args) {

        Drawing draw1=new V1Drawing();

        Drawing draw2=new V2Drawing();

        Shape shape1=new Rectangle(draw1);

        shape1.draw();

        Shape shape2=new Circle(draw2);

        shape2.draw();

    }

}

输出结果如下：

使用DP1的draw_a_line()画线

使用DP1的draw_a_line()画线

使用DP1的draw_a_line()画线

使用DP1的draw_a_line()画线

使用DP2的drawCircle()画圆

在这个例子中Shape对象实际上是一个Retangle或Circle对象，但Client并不知道到底是那个，因为它们看起来都一样。Drawing实际上是一个V1Drawing或V2Drawing,但Shape对象并知道到底是哪个，因为它们看起来都一样。DP1或DP2使用它的Drawing对象知道是哪一个。Shape是事物的抽象，Drawing是实现或者操作事物方法的抽象。他们两个都可以独立地变化。正如例子中所说那样，我们可以输出一个矩形可以使用V1Drawing也可以使用V2Drawing来完成，输出一个圆形也是一样都有两种方法。Bridge模式遵循了设计模式中两条基本策略：找出变化并封装之和优先使用对象聚集，而不是类继承。

    小结：Bridge模式是一种抽象与其实现相分离的模式。它主要应用于：当事物是一组变化量，和对这些事物的操作方法(实现)也是一组变化量的情况，也就是说它们都是多变的。

    定义一系列的算法，把他们一个个封装起来，并且使它们可相互替换。Strategy模式使算法可独立于使用它的客户而变化。

    Strategy模式以下列几条原则为基础：

1） 每个对象都是一个具有职责的个体。

2） 这些职责不同的具体实现是通过多态的使用来完成的。

3） 概念上相同的算法具有多个不同的实现，需要进行管理。

下面我将通过一个实例来说明它的具体使用，这个例子是关于数据库连接的。代码如下：

interface DatabaseStrategy{

    public void process();

}

class MysqlDBStrategy implements DatabaseStrategy{

    public void process() {

       System.out.println("处理Mysql数据库连接");

    }

}

class OracleDBStrategy implements DatabaseStrategy{

    public void process() {

       System.out.println("处理Oracle数据库连接");

    }

}

class DataBaseManager{

    public void process(DatabaseStrategy dbStrategy){

       dbStrategy.process();

    }

}

publicclass StrategyClient {

    public static void main(String[] args) {

       MysqlDBStrategy mysql=new MysqlDBStrategy();

       DataBaseManager manager=new DataBaseManager();

       manager.process(mysql);

       OracleDBStrategy oracle=new OracleDBStrategy();

       manager.process(oracle);

    }

}

    在我们的实际编程中经常会遇到系统要连接的数据库可能不只一种，如果采用传统的方法，即修改连接Url的方法，这种方法确实可行，但是有一个问题要经常修改源代码，不利于以后的维护，那么有没有一种更好的方法呢？答案是有，使用Strategy模式，首先定义一个连接数据库通用的接口（在上面的例子中是DatabaseStrategy）,然后再定义实现该接口的具体类(MysqlDBStrategy、OracleDBStrategy)，在这些具体类，实现具体的逻辑。最后再定义一个管理数据库连接的类(DataBaseManager),它的内部有一个方法可以接受具体类实例的参数。我们可以看到这个参数是DatabaseStrategy类型的，也就是说它可以接受任何一个实现了DatabaseStrategy接口的类的具体实例（这里运用了对象替换机制，多态的一种），从而完成数据库连接的处理。如果我们还需要处理另外一种数据库如sqlserver，我们只需要建立一个SqlserverDBStrategy类实现DatabaseStrategy接口，把该类的实例传给DatabaseManager的process方法即可。

    这段话大致是说：我们需要一种方式，为一个功能正确但接口不合的对象创建一个新接口。例如，客户给我们如下需求：

1） 为都有“显示”(display)行为的点、线、正方形分别创建类。

2） 客户对象不必知道自己到底拥有点、线、还是正方形。它只需知道拥有这些形状中的一个。

也就是说，我们要用一个更高层次的概念将这些具体形状都涵盖进去，这个高层概念可以称为：“可显示的形状”。因此，我们需要创建一个接口Shape:

interface Shape{

    publicvoid display();

}

现在客户忽然间有让我们给这个系统增加一个画圆的功能。这个看起来很简单，只需定义一个Circle类来实现Shape接口，但是我们要给它编写display方法，这可不是件简单的事，假如此时我们正好发现一个XXCircle类，它有一个方法刚好可以完成这个功能，那么有没有更好的方法来利用它呢，这时我们就要用到Adapter模式了。XXCircle代码如下：

class XXCircle{

    public void displayCircle(){

       System.out.println("通过XXCircle.displayCircle()画圆");

    }

}

    Adapter模式有两种类型：

1)    对象Adapter模式，它依赖于一个对象（适配器）包含另一个对象(被适配的对象)。

class CircleObject implements Shape{

    public XXCircle circle;

    public CircleObject(XXCircle xxcircle){

    circle=xxcircle;

    }

    public void display() {

       circle.displayCircle(); 

    }

}

public class Client {

    public static void main(String[] args) {

       XXCircle circle=new XXCircle();

       CircleObject co=new CircleObject(circle);

       co.display();

    }

}

2)     类Adapter模式，它是通过多重继承来实现的（java中没有多继承，是通过接口来实现的）。

class CircleClass extends XXCircle implements Shape{

    public void display() {

       super.displayCircle();  

    }

}

public class Client {

    public static void main(String[] args) {

       CircleClass cc=new CircleClass();

       cc.display();

    }

}

    小结：Adapter模式是一个很常用的模式，它将一个（或多个）类的接口转换成我们需要类所具备的一个接口。它的实现方式是：创建一个具备所需接口的类，然后包装原有类的方法，这样实际上就包含了被适配的对象。它主要适用于以下几种情况：

1） 你希望使用他人编写的子程序或方法，因为你需要它所执行的功能。

2） 你无法将这个子程序直接加入程序中。

3） 子程序的接口或调用方式与需要使用它的相关对象不完全相同。

       为子系统中的一组接口提供一个统一接口。Facade模式定义了一个更高层的接口，使子系统更加容易使用。

       大致意思是说：使用一种比原有方式更简单的办法与系统交互。例如，我们把一个很文件的文件，放在了第二抽屉里，而第二个抽屉的钥匙放在了第一个抽屉里，我们要想取出这个文件，第一步肯定要拿到第一个抽屉的钥匙，然后打开它再拿出第二个抽屉的钥匙，最后打开第二个抽屉取出文件。

       我就上面说的那个情形写一下实现代码，首先我们要实现二个子系统,呵呵，把抽屉比喻成系统，有点夸张了（DrawerOne、DrawerTwo）：

class DrawerOne {

    public void open(){

       System.out.println("第一个抽屉被打开了");

       getKey();

    }

    public void getKey(){

       System.out.println("得到第二个抽屉的钥匙");

    }

}

class DrawerTwo{

    public void open(){

       System.out.println("第二个抽屉被打开了");

       getFile();

    }

    public void getFile(){

       System.out.println("得到这个重要文件");

    }

}

public class Client{

    public static void main(String []args){

       DrawerOne darwerOne=new DrawerOne();

       DrawerTwo darwerTwo=new DrawerTwo();

       darwerOne.open();

       darwerTwo.open();

    }

}

由于没有使用Façade模式，可以看到要想得到这个文件要首先打开第一个抽屉，然后再打开第二个抽屉，在我们实际所开发的系统中，有时候客户要实现某一操作，并不需要知道实现这一操作的详细步骤，而是简单地点击某一个按钮就可以得到自己想要的结果。下面对上面的代码使用Façade模式进行改进，建立一个FacadeDrawer类：

class DrawerFacade{

    DrawerOne darwerOne=new DrawerOne();

    DrawerTwo darwerTwo=new DrawerTwo();

    public void open(){

       darwerOne.open();

       darwerTwo.open();

    }

}

修改Client类：

public class DrawerClient{

    public static void main(String []args){

       DrawerFacade drawer=new DrawerFacade();

       drawer.open();

    }

}

输出结果如下：

第一个抽屉被打开了

得到第二个抽屉的钥匙

第二个抽屉被打开了

得到这个重要文件

正如上面所说，客户端client，它并不需要关心子系统，而是关心DrawerFacade所留下来的和外部交互的接口，而子系统在DrawerFacade的聚合。

以上只是个人拙见，哪里有不正确的地方，希望大家多多批评指正。^_^

    Facade模式主要适用于以下几种情况:

1)    不需要使用一个复杂系统的所有功能，而且可以创建一个新的类，包含访问系统的所有规则。如果只需要使用系统的部分功能，那么你为新类所创建的API将比原系统的API简单的多。

2)    希望封装或者隐藏系统原系统。

3)    希望使用原系统的功能，而且还希望增加一些新的功能。

4)    编写新类的成本小于所有人学会使用或者未来维护原系统上所需的成本。