设计模式简介
 
1. 设计模式的定义
      设计模式是在特定环境下为解决某一通用软件设计问题提供的一套定制的解决方案，该方案描述了对象和类之间的相互作用。
 
 2.设计模式的基本要素
 
模式名称：模式名称通过一两个单词来描述模式的问题、解决方案和效果。
问题：问题描述了应该在何时使用模式，它包含了设计中存在的问题以及问题存在的原因。
解决方案：解决方案描述了设计模式的组成成分，以及这些组成成分之间的相互关系、各自职责和协作方式。
效果：效果描述了模式应用的效果以及在使用模式时应权衡的问题。
 
 
3.设计模式的分类
 
3.1根据目的分类
 
设计模式根据目的（模式使用来做什么的）可分为创建型、结构型、行为型3类
 
3.1.1 创建型模式主要用于创建对象，GoF提供了5种创建型模式，分别是工厂方法模式、抽象工厂模式、建造者模式、原型模式和单例模式。
 
3.1.2 结构型模式主要用于处理类或对象的组合，GoF提供了7种结构型模式，分别是适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式。
 
3.1.3 行为型模式主要用于描述类或对象怎样交互和怎样分配职责，GoF提供了11种行为型设计模式，分别是职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式和访问者模式。
 
3.2根据范围分类
 
设计模式根据范围分类（即模式主要适用于处理类之间的关系还是处理对象之间的关系）可分为类模式和对象模式两种
 
3.2.1 类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时就被确定下来，是一种静态关系。
 
3.2.2 对象模式处理对象间的关系，这些关系在运行时变化，更具动态性。
 
 
创建型模式：
 
1.抽象工厂模式（Abstract Factory Pattern）：提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体指定的类。
 
2.建造者模式（Builder Pattern）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
 
3.工厂方法模式（Factory Method Pattern）:定义一个用于创建对象的接口，但是让之类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。
 
4.原型模式（Prototype Pattern）：使用原型实例指定待创建对象的类型，并且通过复制这个原型来创建新的对象。
 
5.单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点来访问这个唯一实例。
 
构型模式：
 
1.适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另一个接口。适配器模式让那些接口不兼容的类可以一起工作。
 
2.桥接模式（Bridage Pattern）：将抽象部分与它的实现部分解耦，使得两者都能独立变化。
 
3.组合模式（Composite Pattern）：组合多个对象形成树形结构以表示具有部分-整体关系的层次结构。组合模式让客户端可以统一对待单个对象和组合对象。
 
4.装饰模式（Decorator Pattern）：动态的给一个对象增加一些额外的职责。就扩展功能而言，装饰模式提供了一种比使用子类更加灵活的替代方案。
 
5.外观模式（Facade Pattern）：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
 
6.享元模式（Flyweight Pattern）：运用共享技术有效的支持大量细粒度对象的复用。
 
7.代理模式（Proxy Pattern）：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。
 
行为型模式：
 
1.责任链模式（Chain of Responsibility Pattern）：避免将一个请求的发送者与接收者耦合在一起，让多个对象都有机会处理请求。将接收请求的对象连接成一条链，并且沿着这条链传递请求，直到有一个对象能够处理它为止。
 
2.命令模式（Command Pattern）：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，对请求排队或者记录请求日志，以及支持可撤销的操作。
 
3.解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
 
4.迭代器模式（Iterator Pattern）：提供一种方法顺序访问一个聚合对象中的各个元素，而又不用暴露该对象的内部表示。
 
5.中介者模式（Mediator Pattern）：定义一个对象来封装一系列对象的交互。中介者模式使各对象之间不需要显式地相互引用，从而使其偶合松散，而且可以独立地改变它们之间的交互。
 
6.备忘录模式（Memento Pattern）：在不破坏封装的前提下捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
 
7.观察者模式（Observer Pattern）：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时其相关依赖对象皆得到通知并被自动更新。
 
8.状态模式（State Pattern）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
 
9.策略模式（Strategy Pattern）：定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法可以独立于使用它的客户而改变。
 
10.模板方法模式（Template Method Pattern）：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
 
11.访问者模式（Visitor Pattern）：表示一个作用于某对象结构中的各个元素的操作。访问者模式可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
 
 
 
 
 
 
 

  

Java设计模式
 
1.工厂模式
 
2.生成器模式
 
3.观察者模式
 
4.桥接模式
 
5.代理模式
 
6.状态模式
 
7.访问者模式
 
8.命令模式
 
9.装饰器模式
 
10.组合模式
 
 
 
1.工厂模式
 
 
工厂模式一般分为简单工厂、工厂、抽象工厂3种情况，属于创建型设计模式。
 
简单工厂（静态工厂）
 
//定义小汽车接口：ICar.java
public interface ICar{
  //由于工厂模式仅关系对象的创建，为说明方便，无需定义方法
}

//下面定义高、中、低档具体的汽车
//高档小汽车：TopCar.java
public class TopCar implements ICar{
}
//中档小汽车：MidCar.java
public class MidCar implements ICar {
}
//低档小汽车：LowCar.java
public class LowCar implements ICar {
}

//简单工厂:CarSimpleFactory.java
public class CarSimpleFactory {
    public static final String TOPTYPE = "toptype";
    public static final String MIDTYPE = "midtype";
    public static final String LOWTYPE = "lowtype";
    public static ICar create(String mark){
    ICar obj = null;
    if(mark.equals(TOPTYPE)){　//如果是高档类型
      obj = new TopCar();　　//则创建高档车对象
    }
    else if(mark.equals(MIDTYPE)){
    obj = new MidCar();
  }
    else if(mark.equals(LOWTYPE)){
    obj = new LowCar();
  }
    return obj;　　　　//返回选择的对象
  }
}

//测试程序:CarTest.java
public class CarTest {
  public static void main(String[] args) {
  //从工厂中创建对象
    ICar obj = CarSimpleFactory.create("toptype");
  }
}
 
工厂
 
//定义小汽车接口：ICar.java
public interface ICar {
//由于工厂模式仅关系对象的创建，为说明方便，无需定义方法
}
//定义高、中、低档具体的小汽车
//高档小汽车：TopCar.java
public class TopCar implements ICar {
}
//中档小汽车：MidCar.java
public class MidCar implements ICar {
}
//低档小汽车：LowCar.java
public class LowCar implements ICar {
}
//定义抽象工厂：AbstractFactory.java
public abstract class AbstractFactory {
public abstract ICar create();
}
//定义高档小汽车工厂：TopFactory.java
public class TopFactory extends AbstractFactory {
public ICar create() {
    return new TopCar(); //高档工厂生成高档小汽车对象
  }
}
//定义中档小汽车工厂：MidFactory.java
public class MidFactory extends AbstractFactory {
public ICar create() {
    return new MidCar(); //中档工厂生成中档小汽车对象
  }
}
//定义低档小汽车工厂：LowFactory.java
public class LowFactory extends AbstractFactory {
public ICar create() {
    return new LowCar(); //低档工厂生成低档小汽车对象
  }
}
//测试类：CarTest.java
public class CarTest {
public static void main(String []args){
    AbstractFactory obj = new TopFactory();//多态创建高档工厂
    ICar car = obj.create();　　　　//获得高档工厂中的小汽车对象
  }
}
 
抽象工厂
 
//小汽车接口
public interface ICar { }
public class TopCar implements ICar { }
public class MidCar implements ICar { }
public class LowCar implements ICar { }

//定义公共汽车接口、高、中、低档公共汽车类
public interface IBus { }
public class UpBus implements IBus { }
public class MidBus implements IBus { }
public class DnBus implements IBus { }

//定义抽象工厂：AbstractFactory.java
public absttract class AbstractFactory {
public abstract ICar createCar(); //产生小汽车对象
public abstract IBus createBus(); //产生公共汽车对象
}

//定义高档工厂：TopFactory.java
public class TopFactory extends AbstractFactory {
  public ICar createCar() {
    return new TopCar();　　//高档工厂生成高档小汽车对象
  }
  public IBus createBus() {
    return new UpBus();　　//高档工厂生成高档公共汽车对象
  }
}

//定义中档工厂：MidFactory.java
public class MidFactory extends AbstractFactory {
  public ICar createCar() {
    return new MidCar();　　//中档工厂生成中档小汽车对象
  }
  public IBus createBus() {
    return new MidBus();　　//中档工厂生成中档公共汽车对象
  }
}
//定义低档工厂：LowFactory.java
public class LowFactory extends AbstractFactory {
  public ICar createCar() {
    return new LowCar();　　//低档工厂生成中档小汽车对象
  }
  public IBus createBus() {
    return new DnBus();　　//低档工厂生成中档公共汽车对象
  }
}
 
 
 
2.生成器模式
 
 
生成器模式也称为建造者模式。生成器模式的意图在于将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。在软件设计中，有时候面临着一个非常复杂的对象的创建工作。这个复杂的对象通常可以分成几个较小的部分，由各个子对象组合出这个复杂对象的过程相对来说比较稳定，但是子对象的创建过程各不相同并且可能面临变化。根据OOD中的OCP原则，应该对这些子对象的创建过程进行变化封装。
 
生成器思路是产品类与创建产品的类相分离。产品类仅1个，创建产品的类有n个。
 
生成器设计模式涉及4个关键角色：产品（Product）、抽象生成器（IBuild）、具体生成器（Builder）、指挥者（Director）。
 
 
（1）定义1个产品类。
public class Unit1{……}
public class Unit2{……}
public class Unit3{……}
public class Product {
Unit1 u1;
Unit2 u2;
Unit3 u3;
}
由于不在该类完成Product类对象的创建，所以无需显示定义构造方法。

（2）定义n个生成器Build类。
根据语义，生成器是用来生成Product对象的，因此一般来说，Product是生成器类的一个成员变量；
根据语义，每创建一个Product对象，本质上都需要先创建Unit1，Unit2，…， UnitN，再把它们组合成所需的Product对象，
因此需要n个createUnit（）方法及一个组合方法composite()；由于createUnit()及composite()是共性，
因此可定义共同的生成器类接口， n个生成器类均从此接口派生即可。代码如下。
//定义生成器类接口IBuild
public interface IBuild {
public void createUnit1();
public void createUnit2();
public void createUnit3();
public Product composite();　　　　//返回值是Product对象
}
//定义3个生成器类
public class BuildProduct implements IBuild {　//生成第一种Product
Product p = new Product();　　　　　//Product是成员变量
public void createUnit1() {
//p.u1= ...　　　　　　　//创建Unit1
}
public void createUnit2() {
//p.u2 = ...　　　　　　　//创建Unit2
}
public void createUnit3() {
//p.u3 =　　//创建Unit3
}
public Product composite() {
//...　　　//关联Unit,Unit2,Unit3
return p;　　//返回Product对象p
}
}
public class BuildProduct2 implements IBuild {　　//生成第2种Product
Product p = new Product();//Product是成员变量
public void createUnit() {/*p.u = ...... */} //创建Unit
public void createUnit2(){/*p.u2 = ...... */} //创建Unit2
public void createUnit3(){/*p.u3 = ...... */} //创建Unit3
public Product composite() {
//......　　　　//关联Unit1，Unit2，Unit3
return p;　　　//返回Product对象p
}
}
public class BuildProduct3 implements IBuild {　　//生成第3种Product
Product p = new Product();//Product是成员变量
public void createUnit1() {/*p.u1 = ...... */} //创建Unit1
public void createUnit2(){/*p.u2 = ...... */} //创建Unit2
public void createUnit3(){/*p.u3 = ...... */} //创建Unit3
public Product composite() {
//......　　//关联Unit1，Unit2，Unit3
return p;　　//返回Product对象p
}
}
通过上述代码可知，若需求分析发生变化，只需增加或删除相应的生成器类即可，无需修改已有的类代码。
（3）定义1个统一调度类，也叫指挥者（Director）类，是对生成器接口IBuild的封装。该类及简单的测试代码如下。
public class Director {
private IBuild build;
public Director(IBuild build){
this.build = build;
}
public Product build(){
build.createUnit1();
build.createUnit2();
build.createUnit3();
return build.composite();
}
public static void main(String []args){
IBuild build = new BuildProduct();
Director direct = new Director(build);
Product p = direct.build();
}
}
 
 
 
3.观察者模式
 
 
观察者设计模式适合解决多种对象跟踪一个对象数据变化的程序结构问题，有一个称作“主题”的对象和若干个称作“观察者”的对象。有一个主题数据——温度，3个观察者—温度日志、温度曲线、温度报警。因此观察者设计模式涉及两种角色：主题和观察者。
 观察者设计模式可以从以下递推中得出一些重要结论。
 ● 主题要知道有哪些观察者对其进行监测，因此主题类中一定有一个集合类成员变量，包含了观察者的对象集合。
 ● 既然包含了观察者的对象集合，那么，观察者一定是多态的，有共同的父类接口。
 ● 主题完成的主要功能是：可以添加观察者，可以撤销观察者，可以向观察者发消息，引起观察者响应。这三个功能是固定的，因此主题类可以从固定的接口派生。
 因此，编制观察者设计模式，要完成以下功能类的编制。
 ● 主题ISubject接口定义。
 ● 主题类编制。
 ● 观察者接口IObserver定义。
 ● 观察者类实现。
 
 
（1）观察者接口IObserver。

    public interface IObserver {
        public void refresh(String data);
    }
    
（2）主题接口ISubject。

    public interface ISubject {
        public void register(IObserver obs);       //注册观察者
        public void unregister(IObserver obs);     //撤销观察者
        public void notifyObservers();             //通知所有观察者
    }
    
（3）主题实现类Subject。

    public class Subject implements ISubject {
        private Vector<IObserver> vec = new Vector();  //观察者维护向量
        private String data;                           //主题中心数据

        public String getData() {
            return data;
        }
        public void setData(String data) {              //主题注册（添加）
            this.data = data;
        }
        public void register(IObserver obs) {           //主题注册（添加）观察者
         vec.add(obs);
        }

        public void unregister(IObserver obs) {         //主题撤销（删除）观察者
            if(vec.contains(obs))
                vec.remove(obs);
        }
        public void notifyObservers(){             //主题通知所有观察者进行数据响应
            for(int i=0; i<vec.size(); i++){
                IObserver obs = vec.get(i);
                obs.refresh(data);
            }
        }
    }
    
    主题实现类Subject是观察者设计模式中最重要的一个类，包含了观察者对象的维护向量vec以及主题中心数据data变量与具体观察者对象的关联
    方法（通过nitofyObservers()）。也就是说，从此类出发，可以更深刻地理解ISubject为什么定义了3个方法、IObserver接口为什么定义了1个方法。
    
（4）一个具体观察者类Observer。

    public class Observer implements IObserver {
        public void refresh(String data) {
            System.out.println("I have received the data:" +data);
        }
    }
    
（5）一个简单的测试类Test。

    public class Test {
        public static void main(String[] args) {
            IObserver obs = new Observer();    //定义观察者对象
            Subject subject = new Subject();
            //定义主题对象
            subject.register(obs);             //主题添加观察者
            subject.setData("hello");          //主题中心数据发生变动
            subject.notifyObservers();         //通知所有观察者进行数据响应
        }
    }
    
该段代码的含义是：当主题中心数据变化（通过setData方法）后，主题类subject要调用notifyObservers()方法，
通知所有观察者对象接收数据并进行数据响应。
 
 
 
4.桥接模式
 
 
桥接模式是关于怎样将抽象部分与它的实现部分分离，使它们都可以独立地变化的成熟模式。
 
 
（1）定义邮寄接口IPost。

    public interface IPost{   //邮局
        public void post();   //发送功能
    }
    
（2）两个具体邮寄类SimplePost、MarkPost。

    //平信邮寄类SimplePost
    class SimplePost implements IPost{     //平信
        public void post(){                //发送
            System.out.println("This is Simple post");
        }
    }
    //挂号邮寄类
    class MarkPost implements IPost{       //挂号
        public void post(){                //发送
            System.out.println("This is Mark post");
        }
    }
    
  经过（1）、（2）的论述，完成了语义的前半部分定义：邮局有发送功能；发送有两种方式，平邮和挂号。
  
（3）抽象事物类AbstractThing。

    abstract class AbstractThing{ //抽象事物

        private IPost obj;         //有抽象发送功能
        public AbstractThing(IPost obj){
            this.obj = obj;
        }
        public void post(){
            obj.post();
        }
    }
    
该类是桥接模式的核心。分析语义“信件和包裹共享平邮与挂号功能”：信件、包裹是两个不同的事物，它们有共享的功能，
也一定有相异的功能。共享的功能一定能封装到一个类中，又由于该类不能代表一个具体的事物，所以把它定义成abstract类是恰当的。
该类共享的是多态成员obj，是IPost类型的，是抽象的、泛指的，用一条语句表明了事物共享平邮和发送功能。

（4）具体事物类Letter、Parcel。

    //信件类Letter
    class Letter extends AbstractThing{
        public Letter(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    //包裹类Parcel
    class Parcel extends AbstractThing{
        public Parcel(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    
    //编制一个简单的测试类
    public class Test {
        public static void main(String[] args) {
            IPost p = new SimplePost();

            Letter letter = new Letter(p);
            letter.post();
        }
    }
    
第一种情况：若增加了新的事物，则只需从Abstract派生一个类即可，其他无需改变。

    class NewThing extends AbstractThing{
        public NewThing(IPost obj){
            super(obj);
        }
        //其他独有变量和方法
    }
    
第二种情况：若增加了新的邮寄类别，比如特快专递，则只需从IPost接口派生一个类即可，其他无需改变。

    class EMSPost implements IPost{        //特快专递
    public void post(){                //发送
            System.out.println("This is EMS post");
        }
    }
 
 
 
5.代理模式
 
 
代理对象可以在客户端和目标对象之间起到中介的作用，并且可以通过代理对象去掉客户不能看到的内容和服务或者添加客户需要的额外服务。代理模式则是一种可以很好实现客户对象与代理对象分离的策略。
 
代理模式的定义如下：给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文叫作Proxy或Surrogate，它是一种对象结构型模式。其抽象UML图如图所示
 
 代理模式包含如下角色
 ● ISubject：抽象主题角色，是一个接口。该接口是对象和它的代理共用的接口。
 ● RealSubject：真实主题角色，是实现抽象主题接口的类。
 ● Proxy：代理角色，内部含有对真实对象RealSubject的引用，从而可以操作真实对象。代理对象提供与真实对象相同的接口，以便在任何时刻都能代替真实对象。同时，代理对象可以在执行真实对象操作时，附加其他的操作，相当于对真实对象进行封装。以买电视为例，其代码如下。
 （1）定义抽象主题——买电视。
 
interface ITV{
        public void buyTV();
    }
 
（2）定义实际主题——买电视过程。
 
class Buyer implements ITV{
    public void buyTV(){
        System.out.println("I have bought the TV by buyer proxy");
    }
}
 
真正的付费是由购买者完成的。
 （3）定义代理。
 
class BuyerProxy implements ITV{
    private Buyer buyer;
    public BuyerProxy(Buyer buyer){
        this.buyer = buyer;
    }
    public void buyTV(){
        preProcess();
        buyer.buyTV();
        postProcess();
    }
    public void preProcess(){
        //询问客户需要电视类型、价位等信息
    }
    public void postProcess(){
        //负责把电视送到客户家
    }
}
 
电视代理商BuyerProxy与购买者Buyer都实现了相同的接口ITV，是对Buyer对象的进一步封装。着重理解buyTV()方法：首先代理商要通过preProcess()询问客户买电视的类型、价位等信息，然后购买者通过buyer.buyTV()自己付费完成电视购买，最后代理商通过postProcess()协商具体的送货服务、产品三包等。
 
代理模式最突出的特点是：代理角色与实际主题角色有相同的父类接口。常用的代理方式有4类：虚拟代理、远程代理、计数代理、动态代理
 
虚拟代理
 虚拟代理的关键思想是：如果需要创建一个资源消耗较大的对象，先创建一个消耗相对较小的对象来表示，真实对象只在需要时才会被真正创建。当用户请求一个“大”对象时，虚拟代理在该对象真正被创建出来之前扮演着替身的角色；当该对象被创建出来之后，虚拟代理就将用户的请求直接委托给该对象。
 
远程代理
 远程代理的含义是：为一个位于不同的地址空间的对象提供一个本地的代理对象，这个不同的地址空间可以在同一台主机中，也可在另一台主机中。也就是说，远程对象驻留于服务器上，客户机请求调用远程对象调用相应方法，执行完毕后，结果由服务器返回给客户端。
 
 计数代理
 当客户程序需要在调用服务提供者对象的方法之前或之后执行日志或计数的额外功能时，就可以使用计数代理模式。计数代理模式并不是把这些额外操作的代码直接添加到源服务中，而是把它们封装成一个单独的对象，这就是计数代理。
 
动态代理
 对代理模式而言，一个主题类与一个代理类一一对应，这也是静态代理模式的特点。
 
 但是，也常存在这样的情况，有n个主题类，但是代理类中的“前处理、后处理”都是一样的，仅调用主题不同，需要编制如图所示的程序框架。
 
 也就是说，多个主题类对应一个代理类，共享“前处理、后处理”功能，动态调用所需主题，大大减小了程序规模，这就是动态代理模式的特点。实现动态代理的关键技术是反射。
 
 
 
6.状态模式
 
 
状态模式为研究各种状态以及状态间相互转化的实现方式提出了一种较好的设计思路。
 
● 状态类有共同的父接口（或抽象类）, n个不同的状态实现类。
 ● 事物类中包含状态类父接口成员变量声明，用以反映语义“事物有n个状态”。
 ● 事物类中一定有方法选择分支，判断事物当前处于何种状态。
 
状态模式必须完成如下内容的编制：
 ● State：状态接口，封装特定状态所对应的行为。
 ● ConcreteState：具体实现状态处理的类。
 ● Context：事物类，也称上下文类，通常用来定义多态状态接口，同时维护一个用来具体处理当前状态的示例对象。
 
状态模式的UML抽象类图如图所示
 
 状态模式的具体抽象代码如下。
 （1）定义状态抽象接口IState。
 
interface IState{
    public void goState();
}
 
（2）定义状态实现类。
 
class ConcreteStateA implements IState{//定义状态A类
    public void goState(){
        System.out.println("This is ConcreteStateA");
    }
}
class ConcreteStateB implements IState{//定义状态B类
    public void goState(){
        System.out.println("This is ConcreteStateB");
    }
}
 
（3）定义状态上下文维护类Context。
 
class Context{            //上下文有n种状态
    private IState state;
    public void setState(IState state){
        this.state = state;
    }
    public void manage(){
        //此处代码根据条件选择某种状态
        state.goState(); //执行某种状态功能
    }
}
 
Context类是实现状态模式的关键，本部分仅列出了状态模式的基本代码
 
 
 
7.访问者模式
 
 
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式，且可以在不修改原有系统的情况下增加新的操作方式，这就是访问者模式的模式动机。
 
访问者模式抽象类图
 
 访问者模式主要涉及以下四种角色：
 ● IElement：抽象的事物元素功能接口，定义了固定功能方法及可变功能方法接口。
 ● Element：具体功能的实现类。
 ● IVisitor：访问者接口，为所有访问者对象声明一个visit方法，用来代表为对象结构添加的功能，原则上可以代表任意的功能。
 ● Visitor：具体访问者实现类，实现要真正被添加到对象结构中的功能。
 
考虑这样一个应用：已知三点坐标，编写功能类，求该三角形的面积和周长。
 
如果采用访问者模式，应当这样思考：目前已确定的需求分析是求面积和周长功能，但有可能将来求三角形的重心、垂心坐标，内切、外界圆的半径等，因此，在设计时必须考虑如何屏蔽这些不确定情况。具体代码如下。
 
1．定义抽象需求分析接口IShape
 
interface IShape{
    float getArea();             //明确的需求分析
    float getLength();           //明确的需求分析
    Object accept(IVisitor v);   //可扩展的需求分析
}
 
着重理解可扩展的需求分析方法accept()，它在形式上仅是一个方法，但是按访问者模式而言，它却可以表示将来可以求重心、垂心坐标等功能，是一对多的关系，因此IVisitor一般来说是接口或抽象类，“多”项功能一定是由IVisitor的子类来实现的。那么为什么返回值是Object类型呢？可以这样理解，例如重心坐标由两个浮点数表示，外接圆半径由一个浮点数表示，为了屏蔽返回值差异，返回值定义成Object，表明可以返回任意对象类型。
 
2．定义具体功能实现类Triangle
 
class Triangle implements IShape{
    float x1, y1, x2, y2, x3, y3;           //三角形三点坐标
    public Triangle(float x1, float y1, float x2, float y2, float x3, float y3){

        this.x1=x1; this.y1=y1;
        this.x2=x2; this.y2=y2;
        this.x3=x3; this.y3=y3;
    }
    public float getDist(float u1, float v1, float u2, float v2){   //求任意两点距离
        return (float)Math.sqrt((u1-u2)*(u1-u2)+(v1-v2)*(v1-v2));
    }
    public float getArea(){            //固定需求分析求面积
        float a = getDist(x1, y1, x2, y2);
        float b = getDist(x1, y1, x3, y3);
        float c = getDist(x2, y2, x3, y3);
        float s = (a+b+c)/2;
        return (float)Math.sqrt(s*(s-a)*(s-b)*(s-c)); //海伦公式求面积
    }
    public float getLength(){          //固定需求分析求周长
        float a = getDist(x1, y1, x2, y2);
        float b = getDist(x1, y1, x3, y3);
        float c = getDist(x2, y2, x3, y3);
        return a+b+c;
    }
    public Object accept(IVisitor v){  //可扩展需求分析
        return v.visit(this);
    }
}
 
着重理解accept()方法，可以看出IVisitor接口中一定定义了多态方法visit()，那为什么把this引用传过去呢？可以这样理解：例如求三角形重心坐标，它的功能一定是在IVisitor的子类实现的，那么该子类一定得知道三角形的三个顶点坐标，因此把this引用传过去，相当于IVisitor的子类可访问Triangle类的成员变量，编制求重心坐标就容易了。
 
3．定义访问者接口IVisitor
 
interface IVisitor{
    Object visit(Triangle t);
}
 
至此为止，有了1、2、3的代码，访问者模式的代码框架就已经构建起来了。如果需求分析没有变化，那么程序一直应用即可；如果需求分析发生变化，则基础功能类不用变化，只要定义IVisitor接口的具体功能实现类就可以了，例如求三角形重心坐标代码如下。
 4．定义重心坐标实现类CenterVisitor
 
class Point{
    float x, y;
}
class CenterVisitor implements IVisitor{
    public Object visit(Triangle t){
        Point pt = new Point();
        pt.x = (t.x1+t.x2+t.x3)/3;
        pt.y = (t.y1+t.y2+t.y3)/3;
        return pt;
    }
}
 
一个简单的测试类如下。
 
public class Test3 {
    public static void main(String[] args) {
        IVisitor v = new CenterVisitor();        //定义求重心具体访问者对象
        Triangle t = new Triangle(0,0,2,0,0,2);  //定义三角形对象
        Point pt = (Point)t.accept(v);           //通过访问者对象求三角形重心坐标
        System.out.println(pt.x+"\t"+pt.y);
    }
}
 
可以知道，如果再想增加一个求三角形外接圆半径功能，只需再定义一个新类实现IVisitor接口，在该类中完成求外接圆半径功能即可。
 
 
 
8.命令模式
 
 
顾名思义，命令模式一定是有命令发送者、命令接收者。命令发送者负责发送命令，命令接收者负责接收命令并完成具体的工作。
 
命令模式主要针对需要执行的任务或用户提出的请求进行封装与抽象。抽象的命令接口描述了任务或请求的共同特征，而实现则交由不同的具体命令对象完成。每个命令对象都是独立的，它负责完成需要执行的任务，却并不关心是谁调用它。
 
命令模式抽象UML类图
 
 命令模式一般有4种角色，如下所示。
 ● ICommander：抽象命令者，是一个接口，规定了用来封装请求的若干个方法。
 ● ConcreteCommander：具体命令发送者，即命令源。它是实现命令接口的类的示例，如上文中的Teacher类。
 ● Invoker：请求者，具体命令的管理与维护类。请求者是一个包含“命令接口”变量的类的示例。请求者中的“命令”接口的变量可以存放任何具体命令的引用，请求者负责调用具体命令，让具体命令执行那些封装了请求的方法。
 ● Receiver：命令接收者，是一个类的示例。该示例负责执行与请求相关的操作，如上文中的Student类。
 
考虑老师通知学生打扫卫生的程序描述，具体代码如下。
 1．抽象命令接口ICommand
 
interface ICommand{
    public void sweep();
}
 
2．命令接收者Student
 
class Student{
    public void sweeping(){
        System.out.println("we are sweeping the floor");
    }
}
 
在命令模式中，具体工作一定是在接收者中完成的，这一点非常重要。示例中“清扫”工作是由sweeping()方法完成的。
 3．命令发送者Teacher
 
class Teacher implements ICommand{
    private Student receiver = null;
    public Teacher(Student receiver){
        this.receiver = receiver;
    }
    public void sweep(){  //发送sweep清扫命令
        receiver.sweeping();
    }
}
 
命令发送者类中，一般来说包含命令接收者的引用，表明发送命令的目的地址。所以Teacher类中定义了接收者Student类对象的引用。而实现的抽象接口方法中表明发送命令的具体过程，sweep()中利用方法转发说明具体的清扫工作是由接收者Student对象完成的。
 4．命令请求者类Invoke
 
class Invoke{
    ICommand command;
    public Invoke(ICommand command){
        this.command = command;
    }
    public void execute(){
        command.sweep();  //启动命令
    }
}    
 

 
 普通思路是命令发送者直接作用命令接收者，而命令模式思路是在两者之间增加一个请求者类，命令发送者与请求者作用，请求者再与命令接收者作用，请求者起到了一个桥梁的作用
 
5．一个简单的测试类
 
public class Test {
    public static void main(String[] args)
    {
        Student s = new Student();         //定义接收者
        Teacher t = new Teacher(s);        //定义命令发送者
        Invoke invoke = new Invoke(t);     //将命令请求加到请求者对象中
        invoke.execute();                  //由请求者发送命令
    }
}
 
 
 
9.装饰器模式
 
 
装饰器模式利用包含代替继承，动态地给一个对象添加一些额外的功能。以消息日志功能为例，其装饰器模式UML类图如图所示
 
 装饰器模式主要有如下4种角色。
 ● 抽象构件角色（Component）：
 它是一个接口，封装了将要实现的方法，如ILogger。
 ● 具体构件角色（ConcreteComponent）：
 它是多个类，该类实现了Component接口，如FileLogger、ConsoleLogger。
 ● 装饰角色（Decorator）：
 它是一个抽象类，该类也实现了Component接口，同时也必须持有接口Component的对象的引用，如事例中Decorator。
 ● 具体的装饰角色（Decorator类的子类，可以有一个，也可以有多个）：
 这些类继承了类Decorator，实现了Component接口，描述了具体的装饰过程，如UpLogger、XMLLogger。
 
1．抽象装饰器基类Decorator
 
abstract class Decorator implements ILogger{
    protected ILogger logger;
    public Decorator(ILogger logger){
        this.logger = logger;
    }
}
 
2．具体装饰类
 
//信息大写装饰类UpLogger
class UpLogger extends Decorator{
    public UpLogger(ILogger logger){
        super(logger);
    }
    public void log(String msg) {
        msg = msg.toUpperCase();     //对字符串进行大写装饰
        logger.log(msg);             //再执行已有的日志功能
    }
}
 
    //XML格式化装饰类XMLLogger
    class XMLLogger extends Decorator{
          public XMLLogger(ILogger logger){
              super(logger);
          }
          public void log(String msg) {
              String s = "<msg>\r\n" +
                       "<content>"+msg+"</content>\r\n"+
                        "<time>" + new Date().toString()+ "</time>\r\n"+
                        "</msg>\r\n";
              logger.log(s);
         }
     }
 
3．一个简单的测试类
 
public class Test {
    public static void main(String[] args)throws Exception {
        ILogger existobj = new FileLogger();     //已有的日志功能
        ILogger newobj= new XMLLogger(existobj); //新的日志装饰类，对existobj装饰
        String s[] = {"how", "are", "you"};        //仿真传送的字符串信息数组
        for(int i=0; i<s.length; i++){
            newobj.log(s[i]);
            Thread.sleep(1000);                  //每隔1 s传送一个新的字符串
        }
        System.out.println("End");
    }
}
 
 
 
10.组合模式
 
 
文件树型结构示例图
 
 根目录是由两个子目录组成的，第一级子目录由两个文件组成，第二级子目录由两个文件组成，因此树型形式也可以称作组合形式。把叶子节点与目录节点都看成相同性质的节点，只不过目录节点后继节点不为空，而叶子节点后继节点为null。这样就能够对树型结构的所有节点执行相同的操作，这也是组合模式的最大特点。采用组合模式实现文件树型结构的功能，具体代码如下。
 
1．定义抽象节点类Node
 
abstract class Node{
    protected String name;
    public Node(String name){
        this.name = name;
    }
    public void addNode(Node node)throws Exception{
        throw new Exception("Invalid exception");
    }
    abstract void display();
}
 
该类是叶子节点与目录节点的父类，节点名称是name。其主要包括两类方法：一类方法是所有节点具有相同形式、不同内容的方法，这类方法要定义成抽象方法，如display()；另一类方法是目录节点必须重写，叶子节点无需重写的方法，相当于为叶子节点提供了默认实现，如addNode()方法，因为叶子对象没有该功能，所以可以通过抛出异常防止叶子节点无效调用该方法。
 
2．文件叶子节点类FileNode
 
class FileNode extends Node{
    public FileNode(String name){
        super(name);
    }
    public void display(){
        System.out.println(name);
    }
}
 
该类是Node的派生类，仅重写display()方法即可。
 
3．目录节点类DirectNode
 
class DirectNode extends Node{
    ArrayList<Node> nodeList = new ArrayList();
    public DirectNode(String name){
        super(name);
    }
    public void addNode(Node node)throws Exception{
        nodeList.add(node);
    }
    public void display(){

        System.out.println(name);
        for(int i=0; i<nodeList.size(); i++){
            nodeList.get(i).display();
        }
    }
}
 
该类从Node抽象类派生后，与原DirectNode类相比，主要有以下不同：①由定义两个集合类成员变量转为定义一个集合类成员变量nodeList; ②由定义两个添加方法转为定义一个添加方法addNode(); ③display()方法中，由两个不同元素的循环转为一个对相同性质节点Node的循环。也就是说，原DirectNode中不论是定义成员变量、成员方法，还是方法内部的功能，都要实时考虑叶子节点、目录节点的不同性，因此它的各种定义一定是双份的。而组合模式中认为叶子节点、目录节点是同一性质的节点，因此与原DirectNode类对比，它的各种定义工作一定是减半的，也易于扩充。
 
4．一个简单的测试类
 
public class Test {
    public static void createTree(Node node)throws Exception{
        File f = new File(node.name);
        File f2[] = f.listFiles();
        for(int i=0; i<f2.length; i++){
            if(f2[i].isFile()){
                Node node2 = new FileNode(f2[i].getAbsolutePath());
                node.addNode(node2);
            }
            if(f2[i].isDirectory()){
                Node node2 = new DirectNode(f2[i].getAbsolutePath());
                node.addNode(node2);
                createTree(node2);
            }
        }
    }
    public static void main(String[] args)throws Exception {
        Node start = new DirectNode("d://data");
        createTree(start);
        start.display();
    }
}
 
通过该示例，可得组合模式更一般的UML类图，如图所示。共包括以下三种角色。
 
 ● 抽象节点：Node，是一个抽象类（或接口），定义了个体对象和组合对象需要实现的关于操作其子节点的方法，如add()、remove()、display()等。
 ● 叶节点：Leaf，从抽象节点Node派生，由于本身无后继节点，其add()等方法利用Node抽象类中相应的默认实现即可，只需实现与自身相关的remove()、display()等方法即可。
 ● 组合节点：Component，从抽象节点Node派生，包含其他Composite节点或Leaf节点的引用。
 总之，若某应用可形成树型结构，而且形成树型结构后可对叶节点及中间节点进行统一的操作，那么采用组合模式构建应用功能是一个比较好的选择。
 
资料来自《Java设计模式深入研究》

整理转载自：
 
https://blog.csdn.net/u012501459/article/details/12945191
 
https://blog.csdn.net/u013036685/article/details/49231657
 
https://blog.csdn.net/tang_huan_11/article/details/12974857
 
一.概念
 

E-R(Entity-Relationships)模式的构成成分是实体集、属性和联系集，其表示方法如下：
 
 （1） 实体集用矩形框表示，矩形框内写上实体名。
  （2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。
  （3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—N或M—N。
 
关系模式（Relation Schema）是对关系的描述,它可以形式化地表示为：
 R（U，D，dom，F）其中R为关系名，U为组成该关系的属性名集合，D为属性组U中属性所来自的域，dom为属性向域的映象集合，F为属性间数据的依赖关系集合。通常简记为：R(U)或R(A1，A2，…,An)其中R为关系名，U为属性名集合，A1，A2，…,An为各属性名。
  
 
二.E-R图转换为关系模型的转换规则
 
1.实体类型的转换
 (1)将每个实体类型转换成一个关系模式。
 (2)实体的属性即为关系模式的属性。
 (3)实体标识符即为关系模式的键。
 
2.二元联系类型的转换
(1)若实体间联系是1:1，可以在两个实体类型转换成的两个关系模式中任意一个关系模式的属性中加入另一个关系模式的键和联系类型的属性。    另一种方式是将联系转换成单独的关系模式，关系模式的名称取自联系的名称，关系模式的属性包括该联系所关联的两个实体的码及联系的属性，该关系模式的码取自任意一方的实体的码。
 
实例：
         一个学校有一个校长进行管理，一个校长只在一个学校任职，则学校和校长之间的关系为一对一。学校的信息有：学校编号，校名，地址，电话；校长的信息有；校长的职工编号，校长姓名，性别，电话。校长任职会产生任职日期的属性。
               
 转换为关系模式：
 （一）学校（学校编号，校名，地址，职工编号，任职日期）主键为学校编号，外键为职工编号
            校长（职工编号，校长姓名，性别，电话）主键为职工编号
 （二）学校（学校编号，校名，地址）主键为学校编号
            校长（职工编号，校长姓名，性别，电话，学校编号，任职日期）主键为职工编号，外键为学校编号
 （三）学校（学校编号，校名，地址）主键为学校编号
            校长（职工编号，校长姓名，性别，电话）主键为职工编号
            任职（学校编号，职工编号，任职日期）主键为学校编号或职工编号（之前的错误：学校编号和职工编号的联合主键），外键为学校编号，职工编号

(2)若实体间联系是1:N，则在N端实体类型转换成的关系模式中加入1端实体类型的键和联系类型的属性。     另一种方式是将联系转换成单独的关系模式，关系模式的名称取自联系的名称，关系模式的属性包括该联系所关联的两个实体的码及联系的属性，该关系模式的码取自多方的实体的码。
 
实例：
         一个部门中可以有多个员工，而每个员工仅属于一个部门，则部门与员工就可以表示为一对多。
                
 转换为关系模式：
 （一）部门（部门号，部门名称，电话）主键为部门号
            员工（员工号，姓名，电话，工资，部门号）主键为员工号，外键为部门号。
 （二）部门（部门号，部门名称，电话）主键为部门号
            员工（员工号，姓名，电话，工资）主键为员工号
            隶属（员工号，部门号）主键为员工号，外键为员工号、部门号

(3)若实体间联系是M:N，则将联系类型也转换成关系模式，其属性为两端实体类型的键加上联系类型的属性，而键为两端实体键的组合。
 
实例：
         在选课系统中，一个学生可以选多门课程，一个课程也有多名学生上课，学生选择的每门课程都有相应的成绩，课程和学生之间的关系就是多对多的关系。
                 
 转换为关系模式：
 课程（课程号，课程名称，授课教师）主键为课程号
 学生（学号，姓名，性别）主键为学号
 选课（课程号，学号，成绩）主键为课程号和学号组成的联合主键，外键为课程号，学号。
 
3.一元联系类型的转换
 和二元联系类型的转换类似。
 
（1）运动员名次之间存在着1:1联系
 

 　　 ①运动员（编号，姓名，性别，名次，上一名次编号）
 (2)职工之间存在上下级联系，即1:N联系
 

 　　 ①职工（工号，姓名，年龄，性别，经理工号）
 (3)工厂的零件之间存在着组合关系（M:N联系）
 

 　　 ①零件（零件号，零件名，规格）
 　　 ②组成（零件号，子零件号，数量）
 
4.三元联系类型的转换
 第一种：
 
(1)若实体间联系是1:1:1，可以在三个实体类型转换成的三个关系模式中任意一个关系模式的属性中加入另两个关系模式的键（作为外键）和联系类型的属性。
 (2)若实体间联系是1:1:N，则在N端实体类型转换成的关系模式中加入两个1端实体类型的键（作为外键）和联系类型的属性。
 (3)若实体间联系是1:M:N，则将联系类型也转换成关系模式，其属性为M端和N端实体类型的键（作为外键）加上联系类型的属性，而键为M端和N端实体键的组合。
 (4)若实体间联系是M:N:P，则将联系类型也转换成关系模式，其属性为三端实体类型的键（作为外键）加上联系类型的属性，而键为三端实体键的组合。
 
第二种：总是将三元联系类型也转换成关系模式，其属性为三端实体类型的键（作为外键）加上联系类型的属性，而键为三端实体键的组合。
 
三元联系的ER图结构转换为关系模式
 
 

 　　 ①仓库（仓库号，仓库名，地址）
 　　 ②商店（商店号，商店名）
 　　 ③商品（商品号，商品名）
 　　 ④进货（商店号，商品号，仓库号，日期，数量）

关系数据库逻辑设计 
 针对具体问题，如何构造一个适合于它的数据模式 
 数据库逻辑设计的工具──关系数据库的规范化理论 
 关系模式由五部分组成，即它是一个五元组：
 
                    R(U, D, DOM, F)
R：      关系名
U：       组成该关系的属性名集合
D：       属性组U中属性所来自的域
DOM： 属性向域的映象集合
F：       属性间数据的依赖关系集合
 
数据依赖
 
一个关系内部属性与属性之间的约束关系 
 现实世界属性间相互联系的抽象 
 数据内在的性质 
 语义的体现 
 2. 数据依赖的类型 
 函数依赖（Functional Dependency，简记为FD） 
 多值依赖（Multivalued Dependency，简记为MVD） 
 其他
 
关系模式R（U, D, DOM, F）
    简化为一个三元组：
                    R（U, F）
当且仅当U上的一个关系r满足F时，r称为关系模式 R（U, F）的一个关系
 
数据依赖对关系模式的影响
 
[例1]建立一个描述学校教务的数据库：
    学生的学号（Sno）、所在系（Sdept）
    系主任姓名（Mname）、课程名（Cname）
    成绩（Grade）

单一的关系模式 ：   Student <U、F>
U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝
 
   属性组U上的一组函数依赖F：
    F ＝｛ Sno → Sdept,  Sdept → Mname, 
                (Sno, Cname) → Grade ｝
 
关系模式Student(U, F)中存在的问题 
 1. 数据冗余太大 
 2. 更新异常（Update Anomalies） 
 3. 插入异常（Insertion Anomalies） 
 4. 删除异常（Deletion Anomalies） 
 结论： 
 Student关系模式不是一个好的模式。 
 “好”的模式： 
 不会发生插入异常、删除异常、更新异常， 
 数据冗余应尽可能少 
 原因：由存在于模式中的某些数据依赖引起的（这也是对关系 
 模式进行分解的根本理由） 
 解决方法：通过分解关系模式来消除其中不合适的数据依赖
 
分解关系模式
 
把这个单一模式分成3个关系模式：
     S（Sno，Sdept，Sno → Sdept）;
     SC（Sno，Cno，Grade，（Sno，Cno） → Grade）;
     DEPT（Sdept，Mname，Sdept→ Mname）
 
规范化
 
规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。最终使各关系模式达到某种程度的分离，即“一事一地”的模式设计原则
 
函数依赖
 
函数依赖（Functional Dependency,FD） 
 平凡函数依赖与非平凡函数依赖 
 完全函数依赖与部分函数依赖 
 传递函数依赖
 
   设R(U)是一个属性集U上的关系模式，X和Y是U的子集。
    若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等， 而在Y上的属性值不等， 则称 “X函数确定Y” 或  “Y函数依赖于X”，记作X→Y。  
 
设有关系模式R（U），X和Y是属性集U的子集，函数依赖（functional dependency，简记为FD）是形为X→Y的一个命题，若对于R(U)的任意一个可能的关系r ，对r中任意两个元组t和s，都有t［X］＝s［X］蕴涵
    t［Y］＝s［Y］，那么称FD X→Y在关系模式R（U）中成立。
 
所有关系实例均要满足
语义范畴的概念
 
例如：姓名→年龄这个函数依赖只有在该部门没有 
 同名人的条件下成立
 
平凡函数依赖与非平凡函数依赖
 
在关系模式R(U)中，对于U的子集X和Y，
如果X→Y，但Y  X，则称X→Y是非平凡的函数依赖
若X→Y，但Y  X,   则称X→Y是平凡的函数依赖
例：在关系SC(Sno, Cno, Grade)中，
            非平凡函数依赖： (Sno, Cno) → Grade
            平凡函数依赖：     (Sno, Cno) → Sno 
                                          (Sno, Cno) → Cno
 
若X→Y，则X称为这个函数依赖的决定属性组，也称为决定因素（Determinant）。
若X→Y，Y→X，则记作X←→Y。
若Y不函数依赖于X，则记作X→Y。
 
完全函数依赖与部分函数依赖
 
在R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有X’     Y, 则称Y对X完全函数依赖，记作
     X F  Y。
  若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作X   P   Y。
 

[例1] 中(Sno,Cno)→Grade是完全函数依赖，
             (Sno,Cno)→Sdept是部分函数依赖
              因为Sno →Sdept成立，且Sno是（Sno，Cno）的真子集
 
传递函数依赖
 
在R(U)中，如果X→Y，(Y X) ,Y→X Y→Z，Z ∈Y, 则称Z对X传递函数依赖。
    记为：X → Z

 注: 如果Y→X， 即X←→Y，则Z直接依赖于X。

例: 在关系Std(Sno, Sdept, Mname)中，有：
      Sno → Sdept，Sdept → Mname
      Mname传递函数依赖于Sno