A minor

“高内聚、松耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。很多设计原则都以实现代码的“高内聚、松耦合”为目的，比如单一职责原则、基于接口而非实现编程等。实际上，“高内聚、松耦合”是一个比较通用的设计思想，可以用来指导不同粒度代码的设计与开发，比如系统、模块、类，甚至是函数，也可以应用到不同的开发场景中，比如微服务、框架、组件、类库等。为了方便讲述，接下来就以“类”作为这个设计思想的应用对象来展开讲解，其他应用场景读者可以自行类比。在这个设计思想中，

实际上，咱们平时嘴中常说的“好”和“烂”，是对代码质量的一种描述。“好”笼统地表示代码质量高，“烂”笼统地表示代码质量低。对于代码质量的描述，除了“好”“烂”这 样比较简单粗暴的描述方式之外，我们也经常会听到很多其他的描述方式。这些描述方法语义更丰富、更专业、更细化。下面这些几乎涵盖我们所能听到的描述代码质量的所有常用词汇。灵活性（flexibility）、可扩展性（extensibility）、可维护性（maintainability）、可读性（readability）、可理解性（understanda

1. 面向对象（编程范式）现在，主流的编程范式或者是编程风格有三种，它们分别是面向过程、面向对象和函数式编程。面向对象这种编程风格又是这其中主流的。现在比较流行的编程语言大部分都是面向 对象编程语言。大部分项目也都是基于面向对象编程风格开发的。面向对象编程因为其具有 丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，是很多设计原则、设计模式编码实现的基础。2. 设计原则SOLID 原则 -OCP 开闭原则SOLID 原则 -DIP 依赖倒置原则SOLID 原则 -SRP 单一职责

单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导 致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性 ， 提高系统的可维护性 ， 降低变更引起的风险 。 总

开闭原则（Open-Closed Principle, OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开 闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统， 例如：我们版本更新，我尽可能不修改源代码，但是可以增加新功能。在现实生活中对于开闭原则也有体现。比如，很多互联网公司都实行弹性制作息时间， 规定每天工作 8 小时。意思就是说，

里氏替换原则（Liskov Substitution Principle,LSP）是指如果对每一个类型为 T1 的对 象 o1，都有类型为 T2 的对象 o2，使得以 T1 定义的所有程序 P 在所有的对象 o1 都替换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。定义看上去还是比较抽象，我们重新理解一下，可以理解为一个软件实体如果适用一个父类的话，那一定是适用于其子类，所有引用父类的地方必须能透明地使用其子类的对象，子类对象能够替换父类对象，而程序逻辑不变。根据这个

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时应当注意一下几点：一个类对一类的依赖应该建立在最小的接口之上。建立单一接口，不要建立庞大臃肿的接口。尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、 可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考

依赖倒置原则（Dependence Inversion Principle,DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所造成的风险。接下来看一个案例，还是以课程为例，先来创建一个类 Jack：public class Jack { public void studyJavaCourse(){ System.o

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合。迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。现在来设计一个权限系统，Boss 需要查看目前发布到线上的课程数量。这时候，Boss 要找到 TeamLeader 去进行统计，TeamLeader 再把统计结

合成复用原则（Composite/Aggregate Reuse Principle,CARP）是指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计， 其实也都需要遵循 OOP 模型。还是以数据库操作为例，先来创建 DBC

简单工厂并不属于GOF23中设计模式，更类似与一种编码习惯；但可以与之后的工厂模式进行对比归纳定义：由一个工厂决定创建那个对象实例适用场景工厂类负责创建的对象比较少客户端（应用层）只知道传入工厂类参数，对如何创建对象（逻辑）并不关心优点工厂的优点：解耦了应用层与实际对象的类（可能有多个），让应用层只依赖与接口与工厂，提高了稳定性只需要知道要传入的参数，甚至都不用知道类名，就可以获取到所需要的对象无须知道创建细节缺点工厂类的职责相对过重，一个工厂要创建多个对象工厂内部有大

产品产品族：可以类成品牌，如华为的手机，电脑，电视 --> 抽象工厂产品等级：可以理解成功能，如华为的手机，小米的手机，苹果的手机 --> 工厂方法定义抽象工厂模式提供一个创建一系列相关或相互依赖的接口无需指定他们的具体类适用场景客户端（应用层）不依赖于产品实例如何被创建，实现等细节强调一系列相关的产品对象（属于同一产品族）一起适用创建对象需要大量重复代码提供了一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现优点具体产品.

产品产品族：可以类成品牌，如华为的手机，电脑，电视 --> 抽象工厂产品等级：可以理解成功能，如华为的手机，小米的手机，苹果的手机 --> 工厂方法定义：针对每一种产品提供一个工厂类。通过不同的工厂实例来创建不同的产品实例。在同一等级结构中，支持增加任意产品。工厂：为每个产品等级定义一个抽象工厂（抽象类/接口）方法：一个具体工厂生产一个具体产品适用场景创建对象需要大量重复代码客户端（应用层）不依赖于对象是如何创建，实现细节等一个类通过其子类来指定创建那个.

单例模式（Singleton Pattern）是指确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。单例模式是创建型模式。单例模式在现实生活中应用也非常广泛。 例如，国家主席、公司 CEO、部门经理等。在 J2EE 标准中，ServletContext、 ServletContextConfig 等；在 Spring 框架应用中 ApplicationContext；数据库的连接池也都是单例形式。单例模式可以保证内存里只有一个实例，减少了内存开销；可以避免对资源的多重占用。1.饿汉式单

大家有没有发现，之前介绍的单例模式的构造方法除了加上 private 以外，没有做任何处理。如果我们使用反射来调用其构造方法，然后，再调用 getInstance()方法，应该就会两个不同的实例。现在来看一段测试代码，以 LazyInnerClassSingleton 为例：public class LazyInnerClassSingletonTest { public static void main(String[] args) { try{ //

当我们将一个单例对象创建好，有时候需要将对象序列化然后写入到磁盘，下次使用时再从磁盘中读取到对象，反序列化转化为内存对象。反序列化后的对象会重新分配内存， 即重新创建。那如果序列化的目标的对象为单例对象，就违背了单例模式的初衷，相当于破坏了单例。PS：序列化就是说把内存中的状态通过转换成字节码的形式，从而转换一个 IO 流，写入到其他地方(可以是磁盘、网络 IO)，即内存中状态给永久保存下来了。反序列化，是将已经持久化的字节码内容，转换为 IO 流，通过 IO 流的读取，进而将读取的内容转换为 Java

枚举单例属于注册式单例，注册式单例又称为登记式单例，就是将每一个实例都登记到某一个地方，使用唯一的标识获取实例。来看枚举式单例的代码，创建 EnumSingleton 类：public enum EnumSingleton { INSTANCE; private Object data; public Object getData() { return data; } public void setData(Object data) { thi

我们先来看看原型模式的应用场景，你一定遇到过大篇幅 getter、setter 赋值的场景。例如这样的代码public void setParam(ExamPaperVo vo){ ExamPaper examPaper = new ExamPaper(); //试卷主键 examPaper.setExaminationPaperId(vo.getExaminationPaperId()); //剩余时间 curForm.setLeavTime(examPaper.

所谓简单克隆也就是浅拷贝，即它只会拷贝对象中的基本数据类型的数据（比如，int、long），以及引用对象(比如 List）的内存地址，不会递归地拷贝引用对象本身。PS：在 Java 语言中，Object 类的 clone() 方法执行的就是浅拷贝。下面，我们还是通过示例来演示一下，如何实现基于浅拷贝的原型模式…具体示例一个标准的原型模式代码，应该是这样设计的。先创建原型 Prototype 接口：public interface Prototype{ Prototype clone();}

实现深度克隆有两种方案：递归拷贝对象、对象的引用对象以及引用对象的引用对象……直到要拷贝的对象只包含基本数据类型数据，没有引用对象为止。先将对象序列化，然后再反序列化成新的对象，在反序列时就会将重新创建一个对象，然后会自动创建原对象持有引用的对象。我们还是通过一个场景来演示，大家都知道齐天大圣。首先它是一只猴子，有七十二般变化，把一根毫毛就可以吹出千万个泼猴，手里还拿着金箍棒，金箍棒可以变大变小。这就是我们耳熟能详的原型模式的经典体现创建原型猴子 Monkey 类，它是 QiTianDaShen

1.理论定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的对象用户只需指定要建造的类型就可以得到他们，建造过程及细节不需要知道适用场景如果一个对象有非常复杂的内部结构（很多属性）想把对象的创建与使用分离优点封装性好，创建和使用分离扩展性好，建造类之间独立，一定程度上解耦缺点产生多余Builder对象产品内部发生变化，建造者都需要修改，成本较大与工厂模式对比建造者更适用于创建对象的方法流程复杂，而工厂模式适合创建对象的方法简单（或单一）

下面我们来一个实际的业务场景，利用适配模式来解决实际问题。我们很早以前开发的老系统应该都有登录接口，但是随 着业务的发展和社会的进步，单纯地依赖用户名密码登录显然不能满足用户需求了。现在，我们大部分系统都已经支持多种登录方式，如 QQ 登录、微信登录、手机登录、微博登录等等，同时保留用户名密码的登录方式。虽然登录形式丰富了，但是登录后的处理逻辑可以不必改，同样是将登录状态保存到 session，遵循开闭原则。首先创建统一的返回结果 ResultMsg 类：public class ResultMsg {

代理模式（Proxy Pattern）定义非常简单，是指为其他对象提供一种代理，以控制对这个对象的访问。 代理对象在客服端和目标对象之间起到中介作用，代理模式属于结构型设计模式。使用代理模式主要有两个目的：一保护目标对象，二增强目标对象。在生活中，我们经常见到这样的场景，如：租房中介、售票黄牛、婚介、经纪人、快递、 事务代理、非侵入式日志监听等，这些都是代理模式的实际体现。代理模式一般分为静态代理和动态代理，本篇我们先来看静态代理…举个例子，人到了适婚年龄，父母总是迫不及待希望早点抱孙子。而现在社会的

动态代理和静态对比基本思路是一致的，只不过动态代理功能更加强大，随着业务的扩展适应性更强。拿上一篇介绍静态代理时的例子，如果找对象这项业务发展成了一个产业，不仅仅只是父亲给儿子找对象，出现了媒婆、婚介所等这样的形式。那么，此时用静态代理成本就更大了，所以需要一个更加通用的解决方案，要满足任何单身人士找对象的需求。我们升级一下代码：// 实现 InvocationHandler 接口public class JDKMeipo implements InvocationHandler { /

在前两篇文章我们分别介绍了静态代理，以及基于 JDK 实现的动态代理，本篇我们再来介绍一下 Cglib 动态代理。代理模式都是生成一个新的类，去实现增强代码逻辑的功能，但JDK Proxy 对于用户而言，必须要有一个接口实现，目标类相对来说复杂；而 CGLib 可以代理任意一个普通的类，没有任何要求。PS：JDK是采用读取接口的信息，CGLib覆盖父类方法。还是以媒婆为例，创建 CglibMeipo：// 实现 MethodInterceptor 接口public class CGlibMei

代理模式（Proxy Design Pattern）的原理和代码实现都不难掌握。它在不改变原始类（或叫被代理类）代码的情况下，通过引入代理类来给原始类附加功能。1.代理模式的实现与原理在不改变原始类（或叫被代理类）的情况下，通过引入代理类来给原始类附加功能。一般情况下，我们让代理类和原始类实现同样的接口。但是，如果原始类并没有定义接口，并且原始类代码并不是我们开发维护的。在这种情况下，我们可以通过让代理类继承原始类的方法来实现代理模式。2.静态代理和动态代理区别静态代理需要针对每个类都创建一个代理类

适配器模式（Adapter Pattern）是指将一个类的接口转换成客户期望的另一个接口，使原本的接口不兼容的类可以一起工作，属于结构型设计模式。适配器适用于以下几种业务场景：已经存在的类，它的方法和需求不匹配（方法结果相同或相似）的情况适配器模式不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品、不同厂家造成功能类似而接口不相同情况下的解决方案。有点亡羊补牢的感觉。生活中也非常的应用场景，例如电源插转换头、手机充电转换头、显示器转接头。在中国民用电都是 220V 交流电，但我们手机使

装饰者模式（Decorator Pattern）是指在不改变原有对象的基础之上，将功能附加到对象上，提供了比继承更有弹性的替代方案（扩展原有对象的功能），属于结构型模式。装饰者模式在我们生活中应用也比较多如给煎饼加鸡蛋；给蛋糕加上一些水果；给房子装修等，为对象扩展一些额外的职责。装饰者在代码程序中适用于以下场景：用于扩展一个类的功能或给一个类添加附加职责动态的给一个对象添加功能，这些功能可以再动态的撤销1.代码示例来看一个这样的场景，上班族白领其实大多有睡懒觉的习惯，每天早上上班都是踩点，于

在之前的代码中我们列举了非常几个业务场景，相信小伙伴对委派模式和策略模式有了非常深刻的理解了。现在，我们再来回顾一下，DispatcherServlet 的委派逻辑，代码如下：public class DispatcherServlet extends HttpServle { protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOExcept

三类设计模式：创建型设计模式：主要解决“对象的创建”问题结构型设计模式：主要解决“类或对象的组合或组装”问题行为型设计模式：主要解决的就是“类或对象之间的交互”问题观察者模式（Observer Pattern）定义了对象之间的一对多依赖，让多个观察者对象同时监听一个主体对象，当主体对象发生变化时，它的所有依赖者（观察者）都会收到通知并更新，属于行为型模式。观察者模式有时也叫做发布订阅模式。观察者模式主要用于在关联行为之间建立一套触发机制的场景。观察者模式在现实生活应用也非常广泛， 比如：微.

模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤。属于行为性设计模式。这里的“算法”，我们可以理解为广义上的“业务逻辑”，并不特指数据结构和算法中的“算法”。这里的算法骨架就是“模板”，包含算法骨架的方法就是“模板方法”，这也是模板方法模式名字的由来。模板方法适用于以下应用场景一次性实现一个算法的不变的部分，并将可变的行为留给子类来实现各子类中公共的行为被提取出来并集中到一个公共的父类中，从而避免代

委派模式不属于 GOF23 种设计模式中。委派模式（Delegate Pattern）的基本作用就是负责任务的调用和分配任务，跟代理模式很像，可以看做是一种特殊情况下的静态代理的全权代理，但是代理模式注重过程，而委派模式注重结果。委派模式在 Spring 中应用非常多，大家常用的 DispatcherServlet 其实就是用到了委派模式。现实生活中也常有委派的场景发生，例如：老板（Boss）给项目经理（Leader）下达任务，项目经理会根据实际情况给每个员工派发工作任务，待员工把工作任务完成之后，再由项

策略模式（Strategy Pattern）是指定义了算法家族、分别封装起来，让它们之间可以互相替换，此模式让算法的变化不会影响到使用算法的用户。我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式跟两者类似，也能起到解耦的作用，不过，它解耦的是策略的定义、创建、使用这三部分。策略模式的应用场景：假如系统中有很多类，而他们的区别仅仅在于他们的行为不同一个系统需要动态地在几种算法中选择一种1.代码示例为了加深对策略模式的理解，我们来举一个案例。相信小伙伴们都用过

责任链模式的定义是：将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。将这些接收对象串成一条链，并沿着这条链传递这个请求，直到链上的某个接收对象能够处理它 为止。说的更直白一些，在责任链模式中，多个处理器（也就是刚刚定义中说的“接收对象”）依次处理同一个请求。一个请求先经过 A 处理器处理，然后再把请求传递给 B 处理器，B 处理器处理完后再传递给 C 处理器，以此类推，形成一个链条。链条上的每个处理器各自承担各自的处理职责，所以叫作责任链模式。1.代码示例// 抽象处理者public a

迭代器模式（Iterator Design Pattern），也叫作游标模式（Cursor Design Pattern）。 它用来遍历集合对象。这里说的“集合对象”也可以叫“容器”“聚合 对象”，实际上就是包含一组对象的对象，比如数组、链表、树、图、跳表。迭代器模式将 集合对象的遍历操作从集合类中拆分出来，放到迭代器类中，让两者的职责更加单一。迭代器是用来遍历容器的，所以，一个完整的迭代器模式一般会涉及容器和容器迭代器两部 分内容。为了达到基于接口而非实现编程的目的，容器又包含容器接口、容器实现类，迭代

我们知道，创建型设计模式主要解决“对象的创建”问题，结构型设计模式主要解决“类或对象的组合”问题，那行为型设计模式主要解决的就是“类或对象之间的交互”问题。行为型模式比较多，有 11 种，它们分别是：观察者模式、模板模式、策略模式、职责链模式、迭代器模式、状态模式、访问者模式、备忘录模式、命令模式、解释器模式、中介模式。1.观察者模式观察者模式将观察者和被观察者代码解耦。观察者模式的应用场景非常广泛，小到代码层面的解耦，大到架构层面的系统解耦，再或者一些产品的设计思路，都有这种模式的影子，比如，邮件订

设计模式其实一门艺术。设计模式来源于生活，不要为了套用设计模式而去使用设计模式。设计模式是在我们迷茫时提供的一种解决问题的方案，或者说用好设计模式可以防范于未然。设计模式总结的是经验之谈,总结的是前人的经验，提供给后人去借鉴使用，前人栽树， 后人乘凉。设计模式可以帮助我们提升代码的可读性、可扩展性；降低维护成本；解决复杂的业务问题，但是，千万千万不要死记硬背，生搬硬套。分类设计模式创建型工厂方法模式（Factory Method）、抽象工厂模式（Abstract Factory）、