秒杀面试高频SOLID和设计模式基础

最新推荐文章于 2022-12-30 15:44:46 发布

何学长在奔跑

最新推荐文章于 2022-12-30 15:44:46 发布

阅读量1.2k

点赞数 6

分类专栏：设计模式文章标签：设计模式 java SOLID

本文链接：https://blog.csdn.net/weixin_44170221/article/details/106415931

版权

文章目录

👉GitHub地址：https://github.com/Ziphtracks/JavaLearningmanual

记得说好的Star哦！

搜索关注微信公众号“码出Offer”，Z哥送你学习福利资源！

一、什么是设计模式？

软件设计模式，简称设计模式。是一种可以被反复使用、多人知晓、经过分类编目、代码设计经验的总结。简单来说，就是一种经过精心考虑设计的代码设计模板，我们可以使用该设计模板反复套用，提高开发效率、代码的可重用性、代码的可读性、代码的可靠性，解决开发中的一系列问题！

二、为什么要学习设计模式？

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。

使用设计模式的好处

提高我们的逻辑思维、编程能力和设计能力。
使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

三、设计模式的基本要素

3.1 设计模式的基本要素

设计模式的基本要素大致可以分为四个主要部分：模式名称、问题、解决方案和效果。

模式名称： 每一个模式都有自己的名称，因为我们需要根据模式的问题、特点、解决方案、功能和效果等要素来确定名称，所以名称能太长，一定要方便我们记忆、讨论和设计。另外，模式名称一定要有一击必中的感觉，一个短短的词就可以概括该设计模式的特点以及作用等等。
问题： 要确定我们设计的设计模式适用于哪些反复出现的应用环境。也就是哪些应用环境可以用到该设计模式来解决一系列问题。
解决方案： 解决方案包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合（类或对象的组合）来解决这个问题。
效果： 采用该模式对软件系统其他部分的时间、空间分析和影响（优缺点），比如对系统的扩充性、可移植性的影响。影响也包括负面的影响。

3.2 设计模式的其他要素

除了四个主要的基本要素外，还包括很多其他要素，比如：别名、动机、结构、模式角色、合作关系、实现方法、适用性、已知应用、例程、模式扩展和相关模式。

别名： 一个模式可以有超过一个以上的名称。这些名称应该要在这一节注明。简单来说，就像数据库别名一样，可以为此模式取别名来方便记忆、映射其特点、作用等。
动机： 该模式应用在哪种场景的情况下，也就是解决问题的动机是什么？就在该环节提出问题与动机的设计。
应用： 所谓应用，那就如其所意。映射该模式的应用场景以及如何应用等。
结构： 就像设计一款软件一样，我们需要了解并设计它的结构。这里常用类图与互动图阐述此模式的设计结构。
模式角色： 提供在此次设计模式中的类与物件的清单，与它们在此设计模式中扮演的角色。
合作： 在此设计模式中类与物件的互动与合作。
结果： 描述使用该设计模式出现的结果，但是这里结果也是分别好结果与坏结果的，甚至还描述了结果之间的交换问题。
实现： 描述实现该模式、该模式的部分方案、实现该模式的可能技术、或者建议实现模式的方法。
例程： 示范程式。
已知应用： 业务已知的实做范例。
相关模式： 相关模式包括其他相关模式，以及与其他类似模式的不同。

四、设计模式分类

设计模式类型可以分为三类分别是创建型、结构型和行为型设计模式。

类型	设计模式
创建型	工厂方法模式、生成器模式、抽象工厂模式、原型模式、单例模式
结构型	适配器（类）模式、桥接模式、容器模式、修饰模式、扩展性模式、外观模式、享元模式、代理模式
行为型	责任链模式、命令模式、解释器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式

五、认识23种设计模式

单例（Singleton）模式： 某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
原型（Prototype）模式： 将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
工厂方法（Factory Method）模式： 定义一个用于创建产品的接口，由子类决定生产什么产品。
抽象工厂（AbstractFactory）模式： 提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
建造者（Builder）模式： 将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
代理（Proxy）模式： 为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
适配器（Adapter）模式： 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
桥接（Bridge）模式： 将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
装饰（Decorator）模式： 动态的给对象增加一些职责，即增加其额外的功能。
外观（Facade）模式： 为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
享元（Flyweight）模式： 运用共享技术来有效地支持大量细粒度对象的复用。
组合（Composite）模式： 将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
模板方法（TemplateMethod）模式： 定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
策略（Strategy）模式： 定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
命令（Command）模式： 将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
职责链（Chain of Responsibility）模式： 把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
状态（State）模式： 允许一个对象在其内部状态发生改变时改变其行为能力。
观察者（Observer）模式： 多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
中介者（Mediator）模式： 定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
迭代器（Iterator）模式： 提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
访问者（Visitor）模式： 在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
备忘录（Memento）模式： 在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
解释器（Interpreter）模式： 提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

六、设计模式六大原则

注意： 前五个设计原则也属于面向对象五大原则，简称“SOLID”。（面试中问到的SOLID就是它！）

设计原则名称
单一职责原则：SRP（Single responsibility principle）
开放封闭原则/开闭原则：OCP（open close principl）
里氏替换原则：LSP（Liskov Substitution Principle）
接口隔离原则：ISP（Interface Segregation）
依赖倒置原则：DIP（Dependence Inversion Principle）

最少知道原则/迪米特法则：LoD（Law of Demeter）

七、分布式剖析六大设计原则

7.1 单一职责原则

单一职责原则（SRP：Single responsibility principle）表示每个模块、每个类、每个方法都只负责一件事情。

比如：SpringMVC只负责简化MVC开发、Reader类只负责读取文本文件内容、Math.round方法只负责四舍五入

单一职责原则思想演进步骤如下：

大家认识了单一职责原则，想必也知道其作用了。那我们试着写一些代码去证实一下单一职责原则的作用！

首先，我先写一段代码，如下：

public class Test {
   
    public static void main(String[] args) {
   
        int num1 = 10;
        int num2 = 20;

        //求和
        int sum = num1 + num2;
        System.out.println(sum);//30

        //求积
        int product = num1 * num2;
        System.out.println(product);//200
    }
}

看到代码的你们是不是觉得这个代码太小儿科了，不就是相加求和和求数的乘积嘛，有什么特别的。但是如果要求我们得出100、200和与乘积怎么办呢？我们延续这段代码的话，就需要在再重新创建两个变量分别存储100和200，再分别求值，对不对。有没有觉得很麻烦，如果要求我们写100个数字分别求和和乘积呢？岂不是难上加难。

由此证明，该例子是一个反例。它破坏了单一职责原则，使代码失去了复用性的特点，很多功能性代码堆积在一起还显得十分冗长，就单单这两点就造成代码的可读性和复用性非常差！

聪明的小伙伴会说，我们封装成方法啊。封装成方法传参不就好了嘛。是的，这才是正解！

public class MathUtils {
   
    /**
     * 求和
     */
    public int getSum(int num1, int num2) {
   
        return num1 + num2;
    }

    /**
     * 求积
     */
    public int getProduct(int num1, int num2) {
   
        return num1 * num2;
    }
}

的确，入门级的两段代码就反映出来了单一职责原则的核心，那我们反过来考虑一下单一职责原则，是不是在我们的程序人生中随处可见呢？小到我们封装的各个方法，大到框架中的SpringMVC等都离不开单一职责原则的约束！

public class Test {
   
    public static void main(String[] args) {
   
        //求和
        System.out.println(MathUtils.getSum(100, 200));
        //求积
        System.out.println(MathUtils.getProduct(100, 200));
    }
}

7.2 开放封闭原则/开闭原则

开放封闭原则/开闭原则（OCP：open close principl）表示对功能扩展开放，对修改源码关闭。

比如：软件产品的更新换代、增加新功能。开发人员是非常忌讳去修改项目的源代码的，因为修改源代码来实现产品的更新换代是一件非常危险而且造价极高的操作。所以，项目在架构中需要对功能扩展作以要求。

开闭原则思想演进步骤如下：

为了模拟开闭原则，我们还是使用简单易懂的代码去映射。

首先，我们先创建一个产品实体类——Product

/**
 * 产品类
 */
public class Product {
   
    private String name;
    private Double price;

    public String getName() {
   
        return name;
    }

    public void setName(String name) {
   
        this.name = name;
    }

    public Double getPrice() {
   
        return price;
    }

    public void setPrice(Double price) {
   
        this.price = price;
    }
}