设计模式我学过呀，就是没用过

Posted 2021-08-04 架构师社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了设计模式我学过呀，就是没用过相关的知识，希望对你有一定的参考价值。

写在前面

在开发中，不使用设计模式也不是不可以，但是用好设计模式能帮忙我们更好的去解决实际问题。

其实，我们天天都在和设计模式打交道，很多人却完全不知道自己在使用设计模式，你有这种感觉吗？

一个不好笑的笑话：

世界上有10种人，一种是懂设计模式的，一种是不懂设计模式的。

不会有人来问我，还有8种在哪里？大家觉得我该怎么回答。

什么是设计模式

设计模式（ Design Pattern ）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长一段时间的试验和错误总结出来的。

前人种树，后人乘凉

我们可以从以下三个关键点来理解设计模式：

最佳实践
解决方案
试验和错误总结

从上面的三个关键点中可以总结出，设计模式就是在针对编码过程中遇到的问题总结出来的最佳解决方案。

那么这些问题指的是什么问题呢？

面向对象的程序应该具有可维护性、代码可复用性、扩展性及灵活性，要解决的问题就是代码可维护性问题、复用性问题、扩展性问题及灵活性问题。

简单来说，设计模式就是指导你如何写出可维护、可复用、可扩展及灵活的代码。

在1995年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）的书，四位作者合称 GOF（四人组，全拼 Gang of Four），该书收录了23种设计模式，是软件设计模式领域的里程碑。所有有时候设计模式我们称之为GoF23。

设计模式的原则

开闭原则

开闭原则（Open-Closed Principle，简称OCP）是指一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。

强调的是用抽象构建框架，用实现扩展细节。可以提高软件系统的可复用性及可维护性。开闭原则，是面向对象设计中最基础的设计原则。它指导我们如何建立稳定灵活的系统，例如：我们版本更新，我尽可能不修改源代码，但是可以增加新功能。

依赖倒置原则

依赖倒置原则（Dependence Inversion Principle简称DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节；细节应该依赖抽象。

通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并能够降低修改程序所造成的风险。

单一职责原则

单一职责（Simple Responsibility Pinciple，简称SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的

逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢？我们就要给两个职责分别用两个 Class 来实现，进行解耦。

后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一个Class、Interface、Method 只负责一项职责。

接口隔离原则

接口隔离原则（Interface Segregation Principle，简称ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。这个原则指导我们在设计接口时应当注意以下几点：

一个类对一类的依赖应该建立在最小的接口之上。
建立单一接口，不要建立庞大臃肿的接口。
尽量细化接口，接口中的方法尽量少（不是越少越好，一定要适度）。

接口隔离原则符合我们常说的高内聚低耦合的设计思想，从而使得类具有很好的可读性、可扩展性和可维护性。我们在设计接口的时候，要多花时间去思考，要考虑业务模型，

迪米特法则

迪米特原则（Law of Demeter，简称LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle，简称LKP），尽量降低类与类之间的耦合。

迪米特原则主要强调只和朋友交流，不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类，而出现在方法体内部的类不属于朋友类。

里氏替换原则

里氏替换原则（Liskov Substitution Principle，简称LSP），在面向对象的程序设计中，里氏替换原则是对子类的特别定义，这里给出两个定义：

如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。
程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的。

以上两种定义，反过来就不成立了，有子类出现的地方，父类未必就能适应。

我们可以对里氏替换原则归纳为：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
子类中可以增加自己特有的方法。
当子类的方法重载父类的方法时，方法的前置条件（即方法的输入/入参）要比父类方法的输入参数更宽松。
当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的输出/返回值）要比父类更严格或相等。

使用里氏替换原则有以下优点：

约束继承泛滥，开闭原则的一种体现。
加强程序的健壮性，同时变更时也可以做到非常好的兼容性，提高程序的维护性、扩展性。降低需求变更时引入的风险。

合成复用原则

合成复用原则（Composite/Aggregate Reuse Principle,简称CARP）是指尽量使用对象组合(has-a)/聚合(contanis-a)，而不是继承关系达到软件复用的目的。可以使系统更加灵活，降低类与类之间的耦合度，一个类的变化对其他类造成的影响相对较少。继承我们叫做白箱复用，相当于把所有的实现细节暴露给子类。

组合/聚合也称之为黑箱复用，对类以外的对象是无法获取到实现细节的。要根据具体的业务场景来做代码设计，其实也都需要遵循 OOP模型。

tips

学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。

另外：如果大家觉得还是没有理解上面的几个原则，那我下一篇文章使用代码来诠释。

设计模式的种类

设计模式分为三类：

创建型模式
行为性模式
结构性模式

三种模式的分类如下：

经典案例

我们最初刚刚开始接触JDBC那会，第一个JDBC编程如下：

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class JdbcDemo {
    public static final String URL = "jdbc:mysql://localhost:3306/tian";
    public static final String USER = "root";
    public static final String PASSWORD = "123456"; 
    
    public static void query() throws Exception {
        Class.forName("com.mysql.jdbc.Driver");//1
        Connection conn = DriverManager.getConnection(URL, USER, PASSWORD);//2
        Statement stmt = conn.createStatement();//3
        ResultSet rs = stmt.executeQuery("SELECT id, name, age FROM m_user where id =1");//4
        while(rs.next()){
            System.out.println("name: "+rs.getString("name")+" 年龄："+rs.getInt("age"));
        }
    }
}

这个案例中，我们可以把JDBC编程分为五个步骤。

一个查询写了五个步骤，再来个新增又写五个步骤，再来个删除又写五个步骤....长此以往下去，真的成为“搬砖人了”，这是不使用任何设计模式的代价。

天天写这种重复的代码，自己很累，工作效率低，长此以往的下去，就算你干了10年还不如很多人一年的工作经验。