一、面向对象的六大原则

• 单一职责原则——Single Responsiblity Principle

• 迪米特原则——Law Of Demeter

1. 定义：一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的这么多public方法，我就调用这么多，其他的我一概不关心。
2. 迪米特法则告诉我们一个类只和朋友类交流。朋友类的定义是这样的：出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。
3. 一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少 public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前 不加访问权限则默认为包类型）、protected等访问权限，是否可以加上final关键字等。
4. 
   
5. 如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

• 开闭原则——Open Close Principle

1. 定义：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的。程序一旦开发完成，程序中的一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建类可以通过继承的方式来重用原类代码。
2. 
   
3. 使用开闭原则——抽象约束：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。
4. 使用开闭原则——元数据控制模块行为：是尽量使用元数据来控制程序的行为，减少重复开发。元数据用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。通过扩展一个子类，修改配置文件，完成业务变化。
5. 使用开闭原则——制定项目章程：章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。
6. 使用开闭原则——封装变化：：第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或 抽象类中。

二、单例模式 

http://callmegod.iteye.com/blog/1474441

• 定义：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。（许多时候整个系统只需要拥有一个全局对象，这样有利于我们协调系统整体的行为）                                                                                                        
• 单利模式的关键点

1. 构造函数不对外开放，一般为private
2. 通过一个静态方法或者枚举返回单例类对象
3. 确保单例类对象有且只有一个，尤其是在多线程环境下
4. 确保单例类对象在反序列化时不会重新构建对象

• 单例模式通用代码——饿汉单例模式，在类加载时就生成实例。

  
  public class Singleton{
      private static final Singleton singleton=new Singleton();
      private Stingleton(){}
      public static Singleton getInstance(){
         return singleton;
      }
  }
  

• 懒汉单例模式：每次调用getInstance()都会进行同步，这样会消耗不必要的资源。在第一次调用getInstance方法是才会生成实例。

  
  public class Singleton{
      private static Singleton singleton;
      private Stingleton(){}
      public static synchronized Singleton getInstance(){
         if(singleton==null)
             singleton=new Singleton();
         return singleton;
      }
  }
  

• Double Check Lock(DCL)单例模式：既能够在需要时才初始化单例，又能够保证线程安全，且单例对象初始化后调用getInstance不进行同步锁。

  
  public class Singleton{
      private (volatile 防止编译器乱序执行) static Singleton singleton;
      private Stingleton(){}
      public static Singleton getInstance(){
         //第一层判空是为了避免不必要的同步
         if(singleton==null)
         {
             synchronized(Singleton.class){
                 //第二层判空则是为了在null情况下创建实例
                 if(singleton==null)
                    singleton=new Singleton();
             }
         }   
         return singleton;
      }
  }
  

  
  
• 静态内部类单例模式

  
  public class MaYun {
     private static class SigletonHolder {
        private static final instance = new MaYun();
     }
     public static final getInstance() {
        return SigletonHolder.instance;
     }
     private MaYun() {
        //MaYun诞生要做的事情
     }
  

• 枚举单例模式：实现简单，并且创建时线程安全，在任何情况下都是一个单例。无偿提供序列化机制，绝对防止多次实例化，即使在面对复杂的序列化或者反射攻击的时候

  
  public enum SingletonEnum{
     INSTANCE;
     public void doSomething(){...}
  }
  
  //使用
  SingletonEnum.INSTANCE.doSomething();
  

三、工厂方法模式

• 定义

1. 定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
2. 在工厂方法模式中，抽象产品类Product负责定义产品的共性，实现对事物最抽象的定义；Creator为抽象创建类，也就是抽象工厂，具体如何创建产品类是由具体的实现工厂 ConcreteCreator完成的。
   
3. 通用代码                                                                                                        

• 工厂方法模式的优点

1. 良好的封装性，代码结构清晰。一个对象创建是有条件约束的，如一个调用者需
   要一个具体的产品对象，只要知道这个产品的类名（或约束字符串）就可以了，不用知道创建对象的艰辛过程，降低模块间的耦合。
2. 工厂方法模式的扩展性非常优秀。在增加产品类的情况下，只要适当地修改具体 的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。
   
3. 屏蔽产品类。这一特点非常重要，产品类的实现如何变化，调用者都不需要关
   心，它只需要关心产品的接口，只要接口保持不变，系统中的上层模块就不要发生变化。也就是说一旦创建产品类的过程需要修改时，只要修改工厂类即可，不需要一个个地区修改每一个创建的对象。
4. 工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类，其他的实
   现类都不用关心，符合迪米特法则，我不需要的就不要去交流；也符合依赖倒置原则，只依赖产品类的抽象；当然也符合里氏替换原则，使用产品子类替换产品父类，没问题！

• 工厂方法模式的扩展

1. 缩小为简单工厂模式：一个模块仅需要一个工厂类，没有必要把它生产出来，使用静态的方法就可以了。简单工厂模式，去掉了工厂的抽象类，再把创建对象的方法改为静态类型，简化了类的创建过程。                                                                                     
2. 升级为多个工厂类：当我们在做一个比较复杂的项目时，经常会遇到初始化一个对象很耗费精力的情况，所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰。考虑到需要结构清晰，我们就为每个产品定义一个创造者，然后由调用者自己去选择与哪个工厂方法关联。
3. 代替单例模式                                                                                                
4. 延迟初始化：一个对象被消费完毕后，并不立刻释放，工厂类保持其初始状态，等待再次被使用。                                                                                  

四、抽象工厂模式

• 抽象工厂模式定义

1. 为创建一组相关或相互依赖的对象提供一个接口，而且无须指定他们的具体类。
                                         
2.                                                    有N个产品族，在抽象工厂类中应该有N个创建方法；有M个产品等级就应该有M个实现工厂类，在每个实现工厂中，实现不同产品族的生产任务。
   
   

• 抽象工厂模式的优点

1. 封装性，每个产品的实现类不是高层模块要关心的，它要关心的是什么？是接口，是抽象，它不关心对象是如何创建出来，这由谁负责呢？工厂类，只要知道工厂类是谁，我就能创建出一个需要的对象，省时省力，优秀设计就应该如此。
2. 产品族内的约束为非公开状态。

• 抽象工厂模式的缺点：产品族扩展非常困难。
• 使用场景：一个对象族（或是一组没有任何关系的对象）都有相同的约束，则可以使用抽象工厂模式。

五、模板方法模式

• 模板方法模式定义

1. 定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
2. 模板方法模式非常简单，仅仅使用了JAVA的继承机制。AbstractClass叫做抽象模板，它的方法分为两类：基本方法和模板方法。
3. 基本方法：也叫做基本操作，是由子类实现的方法，并且在模板方法被调用。
4. 模板方法：可以有一个或几个，一般是一个具体方法，也就是一个框架，实现对基本方法的调度，完成固定的逻辑。为了防止恶意的操作，一般模板方法都加上final关键字，不允许被覆盖。
5. 抽象模板中的基本方法尽量设计为protected类型，符合迪米特法则，不需要暴露的属性或方法尽量不要设置为public类型。实现类若非必要，尽量不要扩大父类中的访问权限。

• 例子

• 模板方法模式的优点

1. 封装不变部分，扩展可变部分：把认为是不变部分的算法封装到父类实现，而可变部分的则可以通过继承来继续扩展。
2. 提取公共部分代码，便于维护。
3. 行为由父类控制，子类实现。

• 使用场景

1. 多个子类有公有的方法，并且逻辑基本相同。
2. 重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
3. 重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通 过钩子函数（见“模板方法模式的扩展”）约束其行为。
   

• 扩展

1. 子类的返回值影响了模板方法的执行结果，该方法就叫做钩子方法。
2.                                  
                       
   

五、备忘录模式

• 例子

1. 一个类如果想要保存和恢复其原来的状态，需要在类中增加一个方法或者其他的内部类来保存这个状态。但是这样做事对单一职责原则的一种破坏，例如，BOY类本身的职责是追女孩，而保留和恢复状态则应该由另外一个类来承担，这个类我们取名为备忘录。
2. 
   
3. BOY类与备忘录类直接产生联系破坏了迪米特原则，因此多创建一个备忘录的管理类Caretaker对Memento进行管理，这就实现了保存多种状态的功能。                                                                
                                          
      
   
   

• 备忘录模式的定义

1. 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象回复到原先保存的状态。
2. 
   

• 备忘录模式的使用场景

1. 需要保存和回复数据的相关状态场景。
2. 提供一个可回滚（rollback）的操作；比如Word中的CTRL+Z组合键，IE浏览器中的后 退按钮，文件管理器上的backspace键等。
   
3. 需要监控的副本场景中。例如要监控一个对象的属性，但是监控又不应该作为系统的主业务来调用，它只是边缘应用，即使出现监控不准、错误报警也影响不大，因此一般的做法是备份一个主线程中的对象，然后由分析程序来分析。

• 备忘录模式扩展——clone方式的备忘录

1. 该模式就是通过复制的方式产生一个对象的内部状态，恢复和保存都在对象的内部进行，只要实现Cloneable就可以。
2. 
   
3. 使用Clone方式的备忘录模式，可以使用在比较简单的场景或者比较单一的场景
   中，尽量不要与其他的对象产生严重的耦合关系。

• 备忘录模式扩展——多状态的备忘录模式

1. 
   
2. BeanUtils通过反射的方法将对象的多个状态保存到HashMap中，并将HashMap交给备忘录进行保存。恢复时使用BeanUtils中的方法，将备忘录中保存的HashMap中的内容通过反射重新恢复。
3. 
   
4. 
   
5. 
   

• 多备份的备忘录

1. 
   
2. 
   
3. 内存溢出问题，该备份一旦产生就装入内存，没有任何销毁的意向，这是非常危 险的。因此，在系统设计时，要严格限定备忘录的创建，建议增加Map的上限，否则系统很容易产生内存溢出情况。

六、原型模式

• 定义

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

• 原型模式的优点

1. 性能优良：原型模式是对内存二进制流的拷贝，要比直接new一个对象性能好很多，特别是要在一个循环体内产生大量的对象时。
2. 避免构造函数的约束。

• 原型模式的使用场景

1. 资源优化创景：类初始化需要消耗非常多的资源。
2. 性能和安全要求的场景：通过new产生一个对象需要非常繁琐的数据准备或访问权限。
3. 一个对象多个修改者的场景：一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时。

• 原型模式的注意事项

1. 构造函数不会被执行：对象拷贝时构造函数确实没有被执行，这点从原理来讲也是可以讲得通的，Object类的 clone方法的原理是从内存中（具体地说就是堆内存）以二进制流的方式进行拷贝，重新分配一个内存块，那构造函数没有被执行也是非常正常的了。
2. 浅拷贝：Object类提供的方法clone只是拷贝本对象，其对象内部的数组、引用对象等都不拷贝，还是指向原生对象的内部元素地址（基本类型和string类型还是会被拷贝），这种拷贝就叫做浅拷贝。也就是说当拷贝对象修改了内部引用对象的值，那么原型对象内部引用对象的值也会被改变。
                          使用原型模式时，引用的成员变量必须满足两个条件才不会被拷贝：一是类的成员变量，而不是方法内变量；二是必须是一个可变的引用对象，而不是一个原始类型或不可变对象。
3. 深拷贝：对私有的成员变量进行独立拷贝，原生对象和拷贝对象互不影响，这种拷贝就叫做深拷贝。                                                                                   
4. 对象的clone与对象内的final关键字是有冲突的，所以要使用clone方法，类的成员变量上不要增加final关键字。

七、代理模式

• 定义

1. 为其他对象提供一种代理以控制对这个对象的访问。代理模式也叫做委托模式，它是一项基本设计技巧。许多其他模式，如状态模式、策略模式、访问者模式本质上是在更特殊的场合采用了委托模式。
2. 
   
3. Subject抽象主题角色：抽象主题类可以是抽象类也可以是接口，是一个最普通的业务类型定义，无特殊要求； RealSubject具体主题角色：也叫做被委托角色、被代理角，它是业务逻辑的具体执行者；Proxy代理主题角色：也叫做委托类、代理类。它负责对真实角色的应用，把所有抽象主题类定义的方法限制委托给真实主题角色实现，并且在真实主题角色处理完毕前后做预处理和善后处理工作。

public interface Subject {     
   //定义一个方法     
   public void request(); 
}

public class RealSubject implements Subject {     
   //实现方法     
   public void request() {             
        //业务逻辑处理    
   } 
}

• 代理模式的优点

1. 职责清晰：真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件事物，附带的结果就是编程简洁清晰。
2. 高扩展性：具体主题角色是随时都会发生变化的，只要它实现了接口，无论如何变化，代理类完全就可以不在做任何修改的情况下使用。
3. 智能化

• 代理模式的使用场景：只需专注地做好自己的工作，对于其他不属于自己的事情不关心，全部都交给代理来完成。例如，打官司要找律师，你不想参与中间过程的是是非非，只要完成自己的答辩就成，其他的比如事前调查、事后追查都由律师来搞定，这就是为了减轻你的负担。
• 代理模式的扩展——普通代理

1. 首先说普通代理，它的要求就是客户端只能访问代理角色，而不能访问真实角色。也就是场景类不能再直接new一个GamePlayer对象了，它必须由GamePlayerProxy来进行模拟场景。
   
2. 
   
3. 
   
4. 在该模式下，调用者只知代理而不用知道真实的角色是谁，屏蔽了真实角色的变更对高层模块的影响，真实的主题角色想怎么修改就怎么修改，对高层次的模块没有任何的影响，只要你实现了接口所对应的方法，该模式非常适合对扩展性要求较高的场合。

• 代理模式的扩展——强制代理

1. 一般的思维都是通过代理找到真实 的角色，但是强制代理却是要“强制”，你必须通过真实角色查找到代理角色，否则你不能访 问。甭管你是通过代理类还是通过直接new一个主题角色类，都不能访问，只有通过真实角 色指定的代理类才可以访问，也就是说由真实角色管理代理角色。
   
2. 
   

• 代理类需要增加个性服务

1. 一个类可以实现多个接口，完成不同任务的整合。也就是说代理类不仅仅可以实现主题接口，也可以实现其他接口完成不同的任务，而且代理的目的是在目标对象方法的基础上作增强，这种增强的本质通常就是对目标对象的方法进行拦截和过滤。
2. 
   
3. 
   

• 代理模式的扩展——动态代理

1. 动态代理是在实现阶段不用关心代理谁，而在运行阶段才指定代理哪一个对象。相对来说，自己写代理类的方式就是静态代理。本章节的核心部分 就在动态代理上，现在有一个非常流行的名称叫做面向横切面编程，也就是AOP（Aspect Oriented Programming），其核心就是采用了动态代理机制。
2. 
   
3. 在类图中增加了一个InvocationHandler接口和GamePlayIH类，作用就是产生一个对象的代理对象，其中InvocationHandler是JDK提供的动态代理接口，对被代理类的方法进行代理。
   
4. 我们主要通过invoke方法来调用具体的被代理方法，也就是调用真实的方法。我们声明一个Object引用，该引用将指向被代理类，而我们调用被代理类的具体方法则在invoke方法中执行。                                                                                                动态代理是根据被代理的接口生成所有的方法， 也就是说给定一个接口，动态代理会宣称“我已经实现该接口下的所有方法了”，那各位读者想想看，动态代理怎么才能实现被代理接口中的方法呢？默认情况下所有的方法返回值都是空的，是的，代理已经实现它了，但是没有任何的逻辑含义，那怎么办？好办，通过 InvocationHandler接口，所有方法都由该Handler来进行处理，即所有被代理的方法都由 InvocationHandler接管实际的处理任务。
5. 
   
6. 将动态产生代理者的方法进行封装：

八、责任链模式

• 定义

1. 使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关
   系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
2.                                                                         因为责任链中的请求和对应的处理规则是不尽相同的，在这种情况下可以将请求进行封装，同时对请求的处理规则也进行封装作为一个独立的对象。
   
3. 
   
4. 
   
5. 
   

• 责任链模式的优点：责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌，两者解耦，提高系统的灵活性。
• 责任链模式的缺点：：一是性能问题，每个请求都是从链头遍历到链尾，特别
  是在链比较长的时候，性能是一个非常大的问题。二是调试不很方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。
• 注意事项：链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在setNext方法中判断是否已经是超过其阈值，超过则不允许该链建立，避免无意识地破坏系统性能。

九、建造者模式

• 定义

1. 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
2. 
   
3. Product产品类——通常是实现了模板方法模式，也就是由模板方法和基本方法；Builder抽象建造者——规范产品的组件，一般由子类实现；ConcreteBuilder具体建造者——实现抽象类定义的所有方法，并且返回一个组件好的对象；Director导演类——负责安排已有模块的顺序，然后告诉Builder开始建造。
4. 建造者模式是将所有的先后顺序进行封装？如果我突然要增加一个过程，那不是要修改大量的代码吗？
5. 
   
6. 例子：                                                                                                           

• 建造者模式的优点

1. 封装性：使用建造者模式可以使客户端不必知道产品内部组成的细节。
2. 建造者独立，容易扩展。
3. 便于控制细节风险：由于具体的建造者是独立的，因此可以对建造过程逐步细化，而不对其他的模块产生任何影响。

• 使用场景：建造者模式关注的是零件类型和装配工艺（顺序），这是它与工厂方法模式最大不同的地方，虽然同为创建类模式，但是注重点不同。                                                                                                               
• 建造者模式最主要的功能是基本方法的调用顺序安排，也就是这些基本方法已经实现了，通俗地说就是零件的装配，顺序不同产生的对象也不同；而工厂方法则重点是创建，创建零件是它的主要职责，组装顺序则不是它关心的。

十、桥接模式