ER图中的主要成分为实体类型和联系类型，转换算法将实体类型和联系类型转换为关系模式。转化为关系模式，主要确定3部分内容，关系模式的名称，属性，码。
 
转换分为两个步骤：1.实体的转换。2.关系模式的转换；
 
1.实体的转换
 
    将ER图中的实体逐一转换为一个关系模式
 
 
 
 
 
 
关系模式
 
 
实体
 
 
名称              
 
 
实体名                                         
 
 
属性
 
 
实体的属性                
 
 
关系的码
 
 
实体标识符
 
 
 
 
 

 
 
2.联系的转换
 

     根据联系所连接的实体的个数划分：一元，二元，三元联系。
 

 
 
 
2.1 二元联系
 
    1:1
 
 
(1).联系-->独立的关系模式
 
 
 
 
 
 
关系模式
 
 
联系
 
 
名称
 
 
联系名称
 
 
属性              
 
 
该联系所关联的两个实体的码和联系的属性                  
 
 
关系的码 
 
 
取自任一方实体的码
 
 
 
 
 
(2).将联系归并到关联的两个实体的任一方
 
 
 
 
 
 
关系模式
 
 
实体
 
 
名称
 
 
待归并一方实体名称
 
 
属性              
 
 
给待归并的一方实体属性集增加另一方实体的码和该联系的属性  
 
 
关系的码
 
 
归并后的实体码保持不变
 
 
 
 
 
    
 
    1:m
 
 
(1).联系-->独立的关系模式。
 
 
 
 
 
 
关系模式
 
 
联系
 
 
名称
 
 
联系名
 
 
属性              
 
 
该联系所关联的两个实体的码及联系的属性                    
 
 
关系的码
 
 
多方实体的码
 
 
 
 
 
 
(2).将联系归并到关联的两个实体的多方。
 
 
 
 
 
 
关系模式
 
 
实体
 
 
名称
 
 
多方实体名
 
 
属性              
 
 
给待归并的多方实体属性集中增加一方实体的码和该联系的属性  
 
 
关系的码
 
 
归并后的多方实体码保持不变
 
 
 
 
 
 
 
    m:n
 
(1).只能转换成一个独立的关系模式
 
 
 
 
 
 
关系模式
 
 
联系
 
 
名称              
 
 
联系的名称
 
 
属性
 
 
关系模式的属性取该联系的两个多方实体的码及联系的属性     
 
 
关系的码
 
 
两个多方实体码构成的属性组；
 
 
 
 
 

 
 
2.2 一元联系
 
     与二元联系转换类似
 
 
2.3 三元联系
 
    三元联系实体间联系分为：1:1:1 , 1:1:N , 1:M:N , M:N:P.
 
     1:1:1:三个实体类型转换成的三个关系模式。在任一一个关系模式中加入另外两个关系模式的键（作为外键）和联系类型的属性。
 
    1:1:N:在多端实体类型转化的关系模式中，加入两个1端实体类型的键（作为外键）和联系的类型；
 

 
 
联系转化为关系模式
 
    1:M:N:联系转化为关系模式，属性是两个多端实体类型的键（作为外键）和联系类型的属性。关键码是两个多端实体键的组合；
 
    M:N:P:联系转化为关系模式，属性为三端实体类型的键（作为外键）加上联系类型的属性。三端实体键的组合为关键码；
 

 
 
3.总结
 
    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

转换一般遵循如下原则：
 
 1．一个实体型转换为一个关系模式。实体的属性就是关系的属性。实
 体的码就是关系的码。
 例如在我们的例子中，学生实体可以转换为如下关系模式，其中学号
 为学生关系的码：
 学生（学号，姓名，出生日期，所在系，年级，平均成绩） 同样，性
 别、宿舍、班级、档案材料、教师、课程、教室、教科书都分别转换
 为一个关系模式。
 
 2.一个联系转化为一个关系模式，与该联系相连的各实体的码以及联系
 的属性转化为关系的属性，该关系的码则有三种情况：
 若联系为1：1，则每个实体的码均是该关系的后选码。
 若联系为1：n，则关系的码为n端实体的码。
 若联系为m：n，则关系的码为诸实体码的组合。
 
 2.1 联系为1：1
 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对
 应的关系模式合并。
 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及
 联系本身的属性均转换为关系的属性，l 每个实体的码均是
 该关系的候选码。
 如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加
 入另一个关系模式的码和联系本身的属性。
 例如在我们的例子中，"管理"联系为1:1联系，我们可以将其转换为
 一个独立的关系模式：
 管理（职工号，班级号）或 管理（职工号，班级号）
 管理"联系也可以与班级或教师关系模式合并。如果与班级关系模式合
 并，则只需在班级关系中加入教师关系的码，即职工号：
 班级：｛班级号，学生人数，职工号｝
 同样，如果与教师关系模式合并，则只需在教师关系中加入班级关系
 的码，即班级号：
 教师：｛职工号，姓名，性别，职称，班级号，是否为优秀班主任｝
 
 2.2 联系为1：n
 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的
 关系模式合并。
 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及
 联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
 如果与n端对应的关系模式合并，则在n端实体对应模式中加入1端
 实体所对应关系模式的码，以及联系本身的属性。而关系的码为n端
 实体的码。
 例如在我们的例子中，"组成"联系为1:n联系，将其转换为关系模式。
 一种方法是使其成为一个独立的关系模式：
 组成（学号，班级号）
 其中学号为"组成"关系的码。
 另一种方法是将其学生关系模式合并，这时学生关系模式为：
 学生（学号，姓名，出生日期，所在系，年级，班级号，平均成绩）
 后一种方法可以减少系统中的关系个数，一般情况下更倾向于采用这
 种方法。
 
 2.3 联系为m：n
 一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及
 联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
 例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如
 下关系模式，其中学号与课程号为关系的组合码：
 选修（学号，课程号，成绩）
 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多
 元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
 例如在我们的例子中，"选修"联系是一个m:n联系，可以将它转换为如
 下关系模式，其中学号与课程号为关系的组合码：
 选修（学号，课程号，成绩）
 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多
 元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
 而关系的码为各实体码的组合。
 例如在我们的例子中，"讲授"联系是一个三元联系，可以将它转换为
 如下
 关系模式，其中课程号、教师号和书号为关系的组合码：  
 讲授（课程号，教师号，书号）
 
 3．同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和
 m:n三种情况分别处理。
 例如，如果教师实体集内部存在领导与被领导的1:n自联系，我们可
 以将该联系与教师实体合并，这时主码职工号将多次出现，但作用不
 同，可用不同的属性名加以区分，比如在合并后的关系模式中，主码
 仍为职工号，再增设一个"系主任"属性，存放相应系主任的职工号。
 
 4．具有相同码的关系模式可合并。
 为了减少系统中的关系个数，如果两个关系模式具有相同的主码，可
 以考虑将他们合并为一个关系模式。合并方法是将其中一个关系模式
 的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可
 能同名也可能不同名），并适当调整属性的次序。
 例如我们有一个"拥有"关系模式：拥有（学号，性别）
 有一个学生关系模式： 学生（学号，姓名，出生日期，所在系，年级，
 班级号，平均成绩）
 这两个关系模式都以学号为码，我们可以将它们合并为一个关系模式，
 假设合并后的关系模式仍叫学生：
 学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均
 成绩）
 按照上述4条原则，学生管理子系统中的18个实体和联系可以转换为
 下列关系模型：
 学生（学号，姓名，性别，出生日期，所在系，年级，班级号，平均
 成绩，档案号）
 性别（性别，宿舍楼）
 宿舍（宿舍编号，地址，性别，人数）
 班级（班级号，学生人数）
 教师（职工号，姓名，性别，职称，班级号，是否为优秀班主任）
 教学（职工号，学号）
 课程（课程号，课程名，学分，教室号）
 选修（学号，课程号，成绩）
 教科书（书号，书名，价钱）
 教室（教室编号，地址，容量）
 讲授（课程号，教师号，书号）
 档案材料（档案号，......）
 该关系模型由12个关系模式组成。其中学生关系模式包含了"拥有"联
 系、"组成"联系、"归档"联系所对应的关系模式；教师关系模式包含
 了"管理"联系所对应的关系模式；宿舍关系模式包含了"住宿"联系所
 对应的关系模式；课程关系模式包含了"开设"联系所对应的关系模式。

 
 
先来张图，看看这11中模式的关系：
 
 
第一类：通过父类与子类的关系进行实现。
 
 
第二类：两个类之间。
 
 
第三类：类的状态。
 
 
第四类：通过中间类
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   image.png
  
 
 
 
 
父类与子类关系
 
 
0、策略模式（strategy）
 
 
策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数，关系图如下：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   策略模式
  
 
 
 
 
图中ICalculator提供同意的方法，
 AbstractCalculator是辅助类，提供辅助方法，接下来，依次实现下每个类：
 
 
首先统一接口：
 
 
public interface ICalculator {  
    public int calculate(String exp);  
}  
 
 
辅助类：
 
 
public abstract class AbstractCalculator {  
    public int[] split(String exp,String opt){  
        String array[] = exp.split(opt);  
        int arrayInt[] =  new int[2];  
        arrayInt[0] = Integer.parseInt(array[0]);  
        arrayInt[1] = Integer.parseInt(array[1]);  
        return arrayInt;  
    }  
}  
 
 
三个实现类：
 
 
public class Plus extends AbstractCalculator implements ICalculator {  
    @Override  
    public int calculate(String exp) {  
        int arrayInt[] = split(exp,"\\+");  
        return arrayInt[0]+arrayInt[1];  
    }  
}  
public class Minus extends AbstractCalculator implements ICalculator {  
    @Override  
    public int calculate(String exp) {  
        int arrayInt[] = split(exp,"-");  
        return arrayInt[0]-arrayInt[1];  
    }  
}  
public class Multiply extends AbstractCalculator implements ICalculator {  
    @Override  
    public int calculate(String exp) {  
        int arrayInt[] = split(exp,"\\*");  
        return arrayInt[0]*arrayInt[1];  
    }  
}  
 
 
简单的测试类：
 
 
public class StrategyTest {  
    public static void main(String[] args) {  
        String exp = "2+8";  
        ICalculator cal = new Plus();  
        int result = cal.calculate(exp);  
        System.out.println(result);  
    }  
}  
 
 
输出：10
 
 
策略模式的决定权在用户，系统本身提供不同算法的实现，新增或者删除算法，对各种算法做封装。因此，策略模式多用在算法决策系统中，外部用户只需要决定用哪个算法即可。
 
 
1、模板方法模式（Template Method）
 
 
解释一下模板方法模式，就是指：一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用，先看个关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   模板方法模式
  
 
 
 

 
就是在AbstractCalculator类中定义一个主方法calculate，calculate()调用spilt()等，Plus和Minus分别继承AbstractCalculator类，通过对AbstractCalculator的调用实现对子类的调用，看下面的例子：
 
 
public abstract class AbstractCalculator {  
    /*主方法，实现对本类其它方法的调用*/  
    public final int calculate(String exp,String opt){  
        int array[] = split(exp,opt);  
        return calculate(array[0],array[1]);  
     }  
    /*被子类重写的方法*/  
    public abstract int calculate(int num1, int num2);  
    public int[] split(String exp,String opt){  
        String array[] = exp.split(opt);  
        int arrayInt[] = new int[2];  
        arrayInt[0] = Integer.parseInt(array[0]);  
        arrayInt[1] = Integer.parseInt(array[1]);  
        return arrayInt;  
    }  
}  
public class Plus extends AbstractCalculator {  
    @Override  
    public int calculate(int num1, int num2) {  
        return num1 + num2;  
    }  
}  
 
 
测试类：
 
 
public class StrategyTest {  
    public static void main(String[] args) {  
        String exp = "8+8";  
        AbstractCalculator cal = new Plus();  
        int result = cal.calculate(exp, "\\+");  
        System.out.println(result);  
    }  
}  
 
 
我跟踪下这个小程序的执行过程：首先将exp和"\+"做参数，调用AbstractCalculator类里的calculate(String,String)方法，在calculate(String,String)里调用同类的split()，之后再调用calculate(int ,int)方法，从这个方法进入到子类中，执行完return num1 + num2后，将值返回到AbstractCalculator类，赋给result，打印出来。正好验证了我们开头的思路。
 
 
类之间的关系
 
 
2、观察者模式（Observer）
 
 
包括这个模式在内的接下来的四个模式，都是类和类之间的关系，不涉及到继承。观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。先来看看关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   image.png
  
 
 
 
 
MySubject类就是我们的主对象，Observer1和Observer2是依赖于MySubject的对象，当MySubject变化时，Observer1和Observer2必然变化。AbstractSubject类中定义着需要监控的对象列表，可以对其进行修改：增加或删除被监控对象，且当MySubject变化时，负责通知在列表内存在的对象。我们看实现代码：
 
 
一个Observer接口：
 
 
public interface Observer {  
    public void update();  
}  
 
 
两个实现类：
 
 
public class Observer1 implements Observer {  
    @Override  
    public void update() {  
        System.out.println("observer1 has received!");  
   }  
}  
public class Observer2 implements Observer {  
    @Override  
    public void update() {  
        System.out.println("observer2 has received!");  
    }  
}  
 
 
Subject接口及实现类：
 
 
public interface Subject {  
    /*增加观察者*/  
    public void add(Observer observer);  
    /*删除观察者*/  
    public void del(Observer observer);  
    /*通知所有的观察者*/  
    public void notifyObservers();  
    /*自身的操作*/  
    public void operation();  
}  
public abstract class AbstractSubject implements Subject {  
    private Vector<Observer> vector = new Vector<Observer>();  
    @Override  
    public void add(Observer observer) {  
        vector.add(observer);  
    }  
    @Override  
    public void del(Observer observer) {  
        vector.remove(observer);  
    }  
    @Override  
    public void notifyObservers() {  
        Enumeration<Observer> enumo = vector.elements();  
        while (enumo.hasMoreElements()){  
            enumo.nextElement().update();  
        }  
    }  
}  
public class MySubject extends AbstractSubject {  
    @Override  
    public void operation() {  
        System.out.println("update self!");  
        notifyObservers();  
    }  
}  
 
 
测试类：
 
 
public class ObserverTest {  
    public static void main(String[] args) {  
        Subject sub = new MySubject();  
        sub.add(new Observer1());  
        sub.add(new Observer2());  
        sub.operation();  
    }  
}  
 
 
输出：
 
 
update self!
 observer1 has received!
 observer2 has received!
 
 
3、迭代子模式（Iterator）
 
 
顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。我们看下关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   迭代子模式
  
 
 
 
 
MyCollection中定义了集合的一些操作，MyIterator中定义了一系列迭代操作，且持有Collection实例，我们来看看实现代码：
 
 
两个接口：
 
 
public interface Collection {  
    public Iterator iterator();  
    /*取得集合元素*/  
    public Object get(int i);  
    /*取得集合大小*/  
    public int size();  
}  
public interface Iterator {  
    //前移  
    public Object previous();  
    //后移  
    public Object next();  
    //是否有下一个
    public boolean hasNext();  
    //取得第一个元素  
    public Object first();  
}  
 
 
两个实现：
 
 
public class MyCollection implements Collection {  
    public String string[] = {"A","B","C","D","E"};  
    @Override  
    public Iterator iterator() {  
        return new MyIterator(this);  
    }  
    @Override  
    public Object get(int i) {  
        return string[i];  
    }  
    @Override  
    public int size() {  
        return string.length;  
    }  
}  
public class MyIterator implements Iterator {  
    private Collection collection;  
    private int pos = -1;  
    public MyIterator(Collection collection){  
        this.collection = collection;  
    }  
    @Override  
    public Object previous() {  
        if(pos > 0){  
            pos--;  
        }  
        return collection.get(pos);  
    }  
    @Override  
    public Object next() {  
        if(pos<collection.size()-1){  
            pos++;  
        }  
        return collection.get(pos);  
    }  
    @Override  
    public boolean hasNext() {  
        if(pos<collection.size()-1){  
            return true;  
        } else {  
            return false;  
        }  
    }  
    @Override  
    public Object first() {  
        pos = 0;  
        return collection.get(pos);  
    }  
 }  
 
 
测试类：
 
 
public class Test {  
    public static void main(String[] args) {  
        Collection collection = new MyCollection();  
        Iterator it = collection.iterator();  
        while(it.hasNext()){  
            System.out.println(it.next());  
        }  
    }  
}  
 
 
输出：A B C D E
 
 
4、责任链模式（Chain of Responsibility）
 
 
接下来我们将要谈谈责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。先看看关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   责任链模式
  
 
 
 
 
Abstracthandler类提供了get和set方法，方便MyHandle类设置和修改引用对象，MyHandle类是核心，实例化后生成一系列相互持有的对象，构成一条链。
 
 
public interface Handler {  
    public void operator();  
}  
public abstract class AbstractHandler {  
    private Handler handler;  
    public Handler getHandler() {  
        return handler;  
    }  
    public void setHandler(Handler handler) {  
        this.handler = handler;  
    }  
 }  
public class MyHandler extends AbstractHandler implements Handler {  
    private String name;  
    public MyHandler(String name) {  
        this.name = name;  
    }  
    @Override  
    public void operator() {  
        System.out.println(name+"deal!");  
        if (getHandler() != null){  
            getHandler().operator();  
        }  
    }  
}  
public class Test {  
    public static void main(String[] args) {  
        MyHandler h1 = new MyHandler("h1");  
        MyHandler h2 = new MyHandler("h2");  
        MyHandler h3 = new MyHandler("h3");  
        h1.setHandler(h2);  
        h2.setHandler(h3);  
        h1.operator();  
    }  
}  
 
 
输出：
 h1deal!
 h2deal!
 h3deal!
 
 
此处强调一点就是，链接上的请求可以是一条链，可以是一个树，还可以是一个环，模式本身不约束这个，需要我们自己去实现，同时，在一个时刻，命令只允许由一个对象传给另一个对象，而不允许传给多个对象。
 
 
5、命令模式（Command）
 
 
命令模式很好理解，举个例子，司令员下令让士兵去干件事情，从整个事情的角度来考虑，司令员的作用是，发出口令，口令经过传递，传到了士兵耳朵里，士兵去执行。这个过程好在，三者相互解耦，任何一方都不用去依赖其他人，只需要做好自己的事儿就行，司令员要的是结果，不会去关注到底士兵是怎么实现的。我们看看关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   命令模式
  
 
 
 
 
Invoker是调用者（司令员），Receiver是被调用者（士兵），MyCommand是命令，实现了Command接口，持有接收对象，看实现代码：
 
 
public interface Command {  
    public void exe();  
}  
public class MyCommand implements Command {  
    private Receiver receiver;  
    public MyCommand(Receiver receiver) {  
        this.receiver = receiver;  
    }  
    @Override  
    public void exe() {  
        receiver.action();  
    }  
}  
public class Receiver {  
    public void action(){  
        System.out.println("command received!");  
    }  
}  
public class Invoker {  
    private Command command;  
    public Invoker(Command command) {  
        this.command = command;  
    }  
    public void action(){  
        command.exe();  
    }  
}  
public class Test {  
    public static void main(String[] args) {  
        Receiver receiver = new Receiver();  
        Command cmd = new MyCommand(receiver);  
        Invoker invoker = new Invoker(cmd);  
        invoker.action();  
    }  
}  
 
 
输出：command received!
 
 
类的状态
 
 
6、备忘录模式（Memento）
 
 
主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。做个图来分析一下：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   备忘录模式
  
 
 
 
 
Original类是原始类，里面有需要保存的属性value及创建一个备忘录类，用来保存value值。Memento类是备忘录类，Storage类是存储备忘录的类，持有Memento类的实例，该模式很好理解。直接看源码：
 
 
public class Original {  
    private String value;  
    public String getValue() {  
        return value;  
    }  
    public void setValue(String value) {  
        this.value = value;  
    }  
    public Original(String value) {  
        this.value = value;  
    }  
    public Memento createMemento(){  
        return new Memento(value);  
    }  
    public void restoreMemento(Memento memento){  
        this.value = memento.getValue();  
    }  
}  
public class Memento {  
    private String value;  
    public Memento(String value) {  
        this.value = value;  
    }  
    public String getValue() {  
        return value;  
    }  
    public void setValue(String value) {  
        this.value = value;  
    }  
}  
public class Storage {  
    private Memento memento;  
    public Storage(Memento memento) {  
        this.memento = memento;  
    }  
    public Memento getMemento() {  
        return memento;  
    }  
    public void setMemento(Memento memento) {  
        this.memento = memento;  
    }  
}  
 
 
测试类：
 
 
public class Test {  
    public static void main(String[] args) {  
        // 创建原始类  
        Original origi = new Original("egg");  
        // 创建备忘录  
        Storage storage = new Storage(origi.createMemento());  
        // 修改原始类的状态  
        System.out.println("初始化状态为："  + origi.getValue());  
        origi.setValue("niu");  
        System.out.println("修改后的状态为：" + origi.getValue());  
        // 回复原始类的状态  
        origi.restoreMemento(storage.getMemento());  
        System.out.println("恢复后的状态为：" + origi.getValue());  
    }  
}  
 
 
输出：
 
 
初始化状态为：egg
 修改后的状态为：niu
 恢复后的状态为：egg
 
 
简单描述下：新建原始类时，value被初始化为egg，后经过修改，将value的值置为niu，最后倒数第二行进行恢复状态，结果成功恢复了。其实我觉得这个模式叫“备份-恢复”模式最形象。
 
 
7、状态模式（State）
 
 
核心思想就是：当对象的状态改变时，同时改变其行为，很好理解！就拿QQ来说，有几种状态，在线、隐身、忙碌等，每个状态对应不同的操作，而且你的好友也能看到你的状态，所以，状态模式就两点：1、可以通过改变状态来获得不同的行为。2、你的好友能同时看到你的变化。
 看图：
 
 

 
 
  
 
   
 
   

    
   
 
  
 
  

   状态模式
  
 
 
 

 
State类是个状态类，Context类可以实现切换，我们来看看代码：
 
 
public class State {  
    private String value;  
    public String getValue() {  
        return value;  
    }  
    public void setValue(String value) {  
        this.value = value;  
    }  
    public void method1(){  
        System.out.println("execute the first opt!");  
    }  
    public void method2(){  
        System.out.println("execute the second opt!");  
    }  
}  
public class Context {  
    private State state;  
    public Context(State state) {  
        this.state = state;  
    }  
    public State getState() {  
        return state;  
    }  
    public void setState(State state) {  
        this.state = state;  
    }  
    public void method() {  
        if (state.getValue().equals("state1")) {  
            state.method1();  
        } else if (state.getValue().equals("state2")) {  
            state.method2();  
        }  
    }  
}  
 
 
测试类：
 
 
public class Test {  
    public static void main(String[] args) {  
        State state = new State();  
        Context context = new Context(state);  
        //设置第一种状态  
        state.setValue("state1");  
        context.method();  
        //设置第二种状态  
        state.setValue("state2");  
        context.method();  
    }  
}  
 
 
输出：
 
 
execute the first opt!
 execute the second opt!
 
 
根据这个特性，状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。
 
 
通过中间类
 
 
8、访问者模式（Visitor）
 
 
访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。
 
 
简单来说，访问者模式就是一种分离对象数据结构与行为的方法，通过这种分离，可达到为一个被访问者动态添加新的操作而无需做其它的修改的效果。简单关系图：
 
 
 
  
 
   
 
   

    
   
 
  
 
  

   image.png
  
 
 
 
 
来看看原码：一个Visitor类，存放要访问的对象，
 
 
public interface Visitor {  
    public void visit(Subject sub);  
} 
public class MyVisitor implements Visitor {  
    @Override  
    public void visit(Subject sub) {  
    System.out.println("visit the subject："+sub.getSubject());  
    }  
}  
 
 
Subject类，accept方法，接受将要访问它的对象，getSubject()获取将要被访问的属性，
 
 
public interface Subject {  
    public void accept(Visitor visitor);  
    public String getSubject();  
}  
public class MySubject implements Subject {  
    @Override  
    public void accept(Visitor visitor) {  
        visitor.visit( this );  
    }  
    @Override  
    public String getSubject() {  
        return  "love";  
    }  
 }  
 
 
测试：
 
 
public class Test {  
    public static void main(String[] args) {  
        Visitor visitor = new MyVisitor();  
        Subject sub = new MySubject();  
        sub.accept(visitor);      
    }  
}  
 
 
输出：visit the subject：love
 
 
该模式适用场景：如果我们想为一个现有的类增加新功能，不得不考虑几个事情：1、新功能会不会与现有功能出现兼容性问题？2、以后会不会再需要添加？3、如果类不允许修改代码怎么办？面对这些问题，最好的解决方法就是使用访问者模式，访问者模式适用于数据结构相对稳定的系统，把数据结构和算法解耦，
 
 
9、中介者模式（Mediator）
 
 
中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。先看看图：
 
 

 
 
  
 
   
 
   

    
   
 
  
 
  

   中介者模式
  
 
 
 

 
User类统一接口，User1和User2分别是不同的对象，二者之间有关联，如果不采用中介者模式，则需要二者相互持有引用，这样二者的耦合度很高，为了解耦，引入了Mediator类，提供统一接口，MyMediator为其实现类，里面持有User1和User2的实例，用来实现对User1和User2的控制。这样User1和User2两个对象相互独立，他们只需要保持好和Mediator之间的关系就行，剩下的全由MyMediator类来维护！基本实现：
 
 
public interface Mediator {  
   public void createMediator();  
   public void workAll();  
}  
public class MyMediator implements Mediator {  
   private User user1;  
   private User user2;  
   public User getUser1() {  
       return user1;  
   }  
   public User getUser2() {  
       return user2;  
   }  
   @Override  
   public void createMediator() {  
       user1 = new User1( this );  
       user2 = new User2( this );  
   }  
   @Override  
   public void workAll() {  
       user1.work();  
       user2.work();  
   }  
}  
public abstract class User {  
   private Mediator mediator;  
   public Mediator getMediator(){  
       return mediator;  
   }  
   public User(Mediator mediator) {  
       this.mediator = mediator;  
   }  
   public abstract void work();  
}  
public class User1 extends User {  
   public User1(Mediator mediator){  
       super(mediator);  
   }  
   @Override  
   public void work() {  
       System.out.println("user1 exe!");  
   }  
}  
public class User2 extends User {  
   public User2(Mediator mediator){  
       super (mediator);  
   }  
   @Override  
   public void work() {  
       System.out.println("user2 exe!");  
   }  
}  
 
 
测试类：
 
 
public class Test {  
    public static void main(String[] args) {  
        Mediator mediator = new MyMediator();  
        mediator.createMediator();  
        mediator.workAll();  
    }  
}  
 
 
输出：
 
 
user1 exe!
 user2 exe!
 
 
10、解释器模式（Interpreter）
 
 
一般主要应用在OOP开发中编译器的开发中，所以适用面比较窄。
 
 

 
 
  
 
   
 
   

    
   
 
  
 
  

   解释器模式
  
 
 
 

 
Context类是一个上下文环境类，Plus和Minus分别是用来计算的实现，代码如下：
 
 
public interface Expression {  
    public int interpret(Context context);  
}  
public class Plus  implements Expression {  
    @Override  
    public int interpret(Context context) {  
        return context.getNum1()+context.getNum2();  
    }  
}  
public class Minus implements Expression {  
    @Override  
    public int interpret(Context context) {  
        return context.getNum1()-context.getNum2();  
    }  
}  
public class Context {  
    private int num1;  
    private int num2;  
    public Context( int num1, int num2) {  
        this.num1 = num1;  
        this.num2 = num2;  
    }  
    public int getNum1() {  
        return num1;  
    }  
    public void setNum1( int num1) {  
        this.num1 = num1;  
    }  
    public int getNum2() {  
        return num2;  
    }  
    public void setNum2( int num2) {  
        this.num2 = num2;  
    }  
}  
public class Test {  
    public static void main(String[] args) {  
        // 计算9+2-8的值  
        int result = new Minus().interpret(( new Context( new Plus().interpret( new Context(9, 2)),  8)));  
        System.out.println(result);  
    }  
}  
 
 
最后输出正确的结果：3。
 
 
基本就这样，解释器模式用来做各种各样的解释器，如正则表达式等的解释器等等！
 
 
转自:http://blog.csdn.net/zhangerqing