高质量代码

类中的代码行数

函数或者属性是否过多

类依赖的其他类是否过多

私有方法是否过多

是否比较难给类起一个合适的名字

类中是否有大量的方法都是集中操作类中的某几个属性

时刻具备扩展意识、抽象意识、封装意识。

子类违背父类声明要实现的功能

子类违背父类对输入、输出、异常的约定

子类违背父类注释中所罗列的任何特殊说明

单一职责原则针对的是模块、类、接口的设计

接口隔离原则相对于单一职责原则，一方面更侧重于接口的设计，另一方面它的思考角度也是不同的

接口隔离原则提供了一种判断接口的职责是否单一的标准：通过调用者如何使用接口来间接地判定。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。

是一个比较笼统的设计思想，并不是一种具体的实现方法，一般用来指导框架层面的设计。

这里所说的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程通过框架来控制。流程的控制权从程序员“反转”给了框架。

是一种具体的编码技巧，不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。

依赖注入框架提供的扩展点，简单配置一下所有需要的类及其类与类之间依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。

继承复用

合成复用

单一职责原则

基于接口而非实现编程

依赖注入

多用组合少用继承

迪米特法则

Singleton Design Pattern 

一个类只允许创建一个对象（或者实例），这个类就是一个单例类 

单例的实现：饿汉式、懒汉式、双重检查、静态内部类、枚举 

作用：避免频繁创建和销毁系统全局使用的对象 

应用场景：全局唯一类，如 系统配置类、系统硬件资源访问类；公共服务类：如 servlet、springmvc 中的 bean、数据库连接池；Web 计数器、序列号生成器 

缺陷：对 OOP 特性的支持不友好、隐藏类之间的依赖关系、对代码的扩展性不友好、对代码的可测试性不友好、不支持有参数的构造函数 

替代方案：程序员控制、工厂模式、IOC 容器 

扩展：线程纬度的单例、集群环境下的单例、多例模式 

Factory Design Pattern

分为：简单工厂、工厂方法和抽象工厂。简单工厂可以看作是工厂方法的一种特例 

作用：封装变化（创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明）、代码复用（创建代码抽离到独立的工厂类之后可以复用）、隔离复杂性（封装复杂的创建逻辑，调用者无需了解如何创建对象）、控制复杂度（将创建代码抽离出来，让原本的函数或类职责更单一，代码更简洁） 

简单工厂适用场景：对象的创建逻辑比较简单，if-else 并不多 

工厂方法适用场景：对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作；避免 if-else 

抽象工厂适用场景：可以创建多种不同类型的工厂，能够创建一族对象，减少了工厂类 

简单工厂、工厂方法、抽象工厂之间的关系与选择：如果实例对象的创建逻辑并发不复杂、实例对象的种类并不多即 if 分支不多，且基本不会有太大变动，使用简单工厂模式；需要创建的实例化对象种类较多、变动可能性大、对象的创建逻辑比较复杂，使用工厂方法，可以去除 if 多分支、将复杂的对象创建逻辑封装到每个具体工厂中；抽象工厂的使用并不多，适用于实例对象的层级逻辑比较复杂，抽象出多个实例对象组，每个工厂创建一组实例对象 

Builder Design Pattern 

应用场景：能够解决构造方法的参数很多传错参数的问题；可以保证类属性字段安全，不用提供 public setter 方法；可以进行属性字段间的校验、计算、填充等 

缺点：创建对象前必须创建 Builder 对象，多一些性能开销，对性能要求极高的的场景下慎用；代码有点啰嗦 

Prototype Design Pattern 

作用：对象的创建成本比较大，同一个类的不同对象之间的大部分字段相同，可以对已有对象进行拷贝的方式创建新对象，达到节省新对象的创建时间的目的 

方式

实现

Proxy Design Pattern

作用：在不改变原始类（或叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。使用代理对象完成用户请求，屏蔽用户对真实对象的访问

方式：静态代理、动态代理（JDK 自带、cglib、Javassist 可实现）

应用场景

缺点与注意 

Bridge Design Pattern 

作用：将抽象和实现解耦，让它们可以独立变化；让一个类拥有两个或多个独立变化的维度，通过组合的方式，让这两个或多个维度可以独立进行扩展 

实际应用：JDBC 驱动程序的加载、JVM 在多操作系统间的实现、GUI 在多操作系统间的实现 

优点：分离抽象接口与实现、类似多继承但比多继承灵活、可扩展性强、功能对用户透明，隐藏了实现细节 

缺点：需要抽象出变化的维度，对业务理解程度要求较高、对系统的设计能力要求较高、代码较难理解 

Decorator Design Pattern 

作用

角色 

优点：可以动态扩展一个实现类的功能，装饰类和被装饰类可以独立扩展，不会相互耦合 

缺点：层次关系比较复杂 

Adapter Design Pattern 

作用：适配，将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作 

应用场景 

实际例子

优点：适配器模式是一种补充模式，可以用来系统的后期扩展与修改 

缺点：不适合过多使用，否则代码中的方法调用比较乱 

Facade Design Pattern 

门面模式为子系统提供一组统一的接口，定义一组高层接口让子系统更易用 

作用

Composite Design Pattern 

作用 

使用场景：主要用来处理树形结构的数据。如部门、人员组成树状结构，计算薪资 

优点：灵活增加节点、调用简单、代码简洁 

缺点：适用场景非常单一 

Flyweight Design Pattern 

作用：复用对象，节省内存。（前提是享元对象是不可变对象） 

应用场景：当一个系统中存在大量重复对象的时候，可以利用享元模式，将对象设计成享元，在内存中只保留一份实例，供多处代码引用，减少内存中对象的数量，节省内存。如JDK 中 Integer 类就使用了享元模式缓存了 -128 ～ 127 范围的整数

实现：主要是通过工厂模式，在工厂类中，通过一个 Map 或者 List 来缓存已经创建好的享元对象，以达到复用的目的 

Observer Design Pattern 

定义：在对象之间定义一个一对多的依赖，当一个对象状态改变的时候，所有依赖的对象都会自动收到通知 

优点：降低了目标与观察者之间的耦合关系、目标与观察者之间建立了一套触发机制 

缺点：当观察者对象很多时，通知的发布会花费很长时间 

应用场景：对象间存在一对多关系，一个对象的状态发生改变会影响其他对象 

实际应用：邮件订阅、RSS Feeds、MQ 消息发布与订阅 

Template Method Design Pattern 

定义：模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤 

实际应用：Java InputStream、Java AbstractList、Java Servlet、JUnit TestCase 

作用 

缺点：某种实现都需要子类，类的数量增多；代码可读性变差 

Strategy Design Pattern 

定义：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户 

理解：包含策略的定义、实现类的创建、静态或者动态使用不同策略 

应用场景：替代根据类型进行多层 if -else 判断 

优点 

缺点：策略实现类会比较多 

Chain of Responsibility Design Pattern 

作用：将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。将这些接收对象串成一条链，并沿着这条链传递这个请求，直到链上的某个接收对象能够处理它为止 

优点

缺点：不能保证每个请求一定被处理 

使用场景： 可动态指定一组对象处理请求 

实际应用：Servlet Filter、Spring Interceptor、Dubbo Filter、 Netty ChannelPipeline 

State Design Pattern 

定义：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为 

应用场景

实际应用：状态机、游戏中不同人物角色的切换 

优点：封装状态变化、减少对象间的相互依赖、利于程序的扩展 

缺点：结构与实现都较为复杂 

Iterator Design Pattern 

定义：提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示 

实际应用：JDK 中 Iterator 接口 

优点

Visitor Design Pattern 

定义：允许一个或者多个操作应用到一组对象上，解耦操作和对象本身 

作用：在被访问的类里面加一个对外提供接待访问者的接口，解决稳定的数据结构和易变的操作耦合问题 

应用场景：对象结构相对稳定，但其操作算法经常变化；对象提供多种不同且不相关的操作，避免对结构的影响

优点

缺点

Memento Design Pattern 

定义：在不违背封装原则的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便之后恢复对象为先前的状态 

作用：提供了恢复状态的机制；实现了内部状态的封装，满足单一职责原则 

实际场景：游戏存档、编辑器和 IDE 的 ctrl+Z 回滚、数据库回滚 

缺点：内容过多或者过频繁备份，资源消耗大；适用场景单一 

Command Design Pattern 

定义：将请求（命令）封装为一个对象，这样可以使用不同的请求参数化其他对象（将不同请求依赖注入到其他对象），并且能够支持请求（命令）的排队执行、记录日志、撤销等（附加控制）功能 

作用：将调用操作的对象与实现该操作的对象解耦；增加或删除命令非常方便，不影响其他类，符合开闭原则 

实际应用：游戏开发中将把请求包含的数据和处理逻辑封装为命令对象执行；与备忘录模式组合，实现 redo、undo 功能 

缺点：产生大量具体命令类 

Interpreter Design Pattern 

定义：为某个语言定义它的语法（或者叫文法）表示，并定义一个解释器用来处理这个语法 

作用：构建固定文法的句子的解释器 

缺点

Mediator Design Pattern 

定义：定义了一个单独的（中介）对象，来封装一组对象之间的交互。将这组对象之间的交互委派给与中介对象交互，来避免对象之间的直接交互 

作用：引入中介这个中间层，将对象间的一对多关联转变为一对一的关联，只需要跟中介对象交互即可 

优点：降低了代码的复杂度，提高了代码的可读性和可维护性 

缺点：中介者的职责很大时，代码将复杂，可维护性降低