设计模式 -- 概述

最新推荐文章于 2023-02-05 00:57:06 发布

leo_messi94

最新推荐文章于 2023-02-05 00:57:06 发布

阅读量121

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/weixin_39724194/article/details/107086147

版权

设计模式专栏收录该内容

8 篇文章 0 订阅

订阅专栏

学习设计模式的目的：

代码重用性
可读性
可扩展性
可靠性
使程序呈现高内聚，低耦合的特性

设计模式七大原则

1.单一职责原则

对类来说，即一个类只负责一项职责。

假如类A负责2个不同的职责：职责1和职责2，当职责1因为需求而发生改变时，可能造成职责2执行错误。所以需要将类A的粒度分解为A1，A2。

1.1 注意事项和细节

降低类的复杂度，一个类只负责一项职责
提高类的可读性，可维护性
降低变更引起的分线
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。

1.2 举例：

public class DanYiZhiZeTest1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.run("飞机");
    }
}

/**
 * 交通工具类
 * 飞机不能在公路上飞行，违反了单一职责原则
 * 解决方法1：
 *      可以将交通工具类拆分成公路交通工具类和天空交通工具类
 * 问题：这种方法造成类冗余，同时修改了客户端（main方法）
 */
class Vehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上运行。。。");
    }
}

结果：

在这里插入图片描述

解决方法1：

将类拆分为公路交通工具类和天空交通工具类

但是这样容易造成类冗余，同时会大量修改客户端代码，也会造成堆空间对象大量增加

解决方法2：

将run方法拆分为run和runAir方法：

// 这种方法虽然没有在类级别满足单子职责原则，但是在方法级别满足了单一职责原则
class Vehicle2 {
    public void run(String vehicle) {
        System.out.println(vehicle + "在公路上运行。。。");
    }

    public void runAir(String vehicle) {
        System.out.println(vehicle + "在天空运行。。。");
    }
}

2.接口隔离原则

2.1 基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的以来应该建立在最小的接口上
也称接口最小化原则，强调的是一个接口拥有的行为应该尽可能的小

如果我们不满足接口隔离原则，经常会出现：我们实现了一个接口，但是这个接口中很多方法我们不需要使用，有很多空实现。这样做不仅会导致代码冗余，还会给别人一个错觉，我们这个类拥有这个方法，但实际上里面没有任何实现。

举例：

假如我们新建了一个老年机对象，我们还需要实现其中的play方法，但是老年机显然是不能够玩游戏的

// 一个手机不应该拥有玩游戏的功能，这是智能手机才能完成的事情
interface phone {
    void call(); //打电话
    void play(); // 玩游戏
}

改进：

interface phone {
    void call(); //打电话
    //void play(); // 玩游戏
}

interface smartPhone extends phone {
    void play();
}

3.依赖倒转原则

3.1 基本介绍

高层模块不应该依赖底层模块，二者都应该以来其抽象
抽象不应该依赖细节，细节应该依赖抽象
依赖倒转的中心思想是面向接口编程
依赖倒转原则是基于这样的设计理念：相对于细节的对变形，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节就是具体的实现类。
使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

3.2 举例：

情况一：

分析：
1.比较简单实现
2.如果我们信息来源是微信，短信，这样就需要修改我们的Person类

public class DependecyInversion {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }
}

class Email {
    public String getInfo() {
        return "电子邮件 ： hello";
    }
}

class Person {
    public void receive(Email email) {
        email.getInfo();
    }
}

情况二：
改进，添加一个接收接口，让电子邮件，微信，短信实现这个接口。
使用接口传递。

public class DependecyInversion2 {
    public static void main(String[] args) {
        Person2 person = new Person2();
        person.receive(new Email2());
    }
}

interface IReceiver {
    String getInfo();
}
class Email2 implements IReceiver {
    public String getInfo() {
        return "电子邮件 ： hello";
    }
}

class WeChat implements IReceiver {
    public String getInfo() {
        return "微信 ： hello";
    }
}

class Person2 {
    public void receive(IReceiver iReceiver) {
        iReceiver.getInfo();
    }
}

3.3 依赖传递的三种方式：

通过接口传递
通过构造器
通过setter方法

3.4 依赖倒转原则的注意事项和细节

底层模块尽量都是抽象类或接口，或者两者都有，程序稳定性更好
变量的声明类型尽量使抽象类或接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化
继承时遵循里氏替换原则

4.里氏替换原则

4.1 OO的继承性的思考和说明

继承包含这样一层含义：父类中凡事已经实现好的方法，实际上实在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些七月，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏
继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

4.2 基本介绍

里氏替换原则：如果对每个类型为T1的对象o1，都有类型为T2 的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换为o2时，程序P的行为没有发生变化，那么类型T是类型T1的子类型。换句话说：一个子类应该可以替换掉父类并且可以正常工作。
在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。
继承实际上让2个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。

5.开闭原则

一个软件实体如类、模块、函数应该：对扩展开放（对提供方），对修改关闭（对使用方）；用抽象构建矿建，用实现扩展细节。
当软件需要变化是，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有代码来实现变化

6.迪米特法则（最小知道原则）

基本介绍：

一个对象应该对其他对象保持最少的了解
类与类的关系越密切，耦合度越大
迪米特法则又叫最小知道原则，即一个类对自己以来的类知道的越少越好。也就是说，对于被依赖的类不管多复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不泄露任何信息。
应该尽可能将一个类的细节全部写在这个类的内部，不要漏出来给其他类知道，否则其他类就很容易会依赖于这些细节，这样类之间的耦合度就会急速上升，这样做的后果往往是一个类随便改点东西，依赖于它的类全部都要改
简单点说：降低类的耦合，只对外公布（public）必须要公布的。