设计模式学习1：设计模式简述和设计模式原则

最新推荐文章于 2024-04-27 09:13:51 发布

小关同学喜欢吃汉堡

最新推荐文章于 2024-04-27 09:13:51 发布

阅读量174

点赞数

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

本文链接：https://blog.csdn.net/weixin_45784666/article/details/120049580

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

设计模式简述

什么是设计模式？
软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。

设计模式的目的：

代码高可用（相同作用的代码能重复使用）
可读性（编程规范性）
可扩展性（增加新的功能时，非常方便）
可靠性（增加新的功能后，对原有的功能没有影响）
代码的高内聚、低耦合

设计模式分为三种类型，共23种：

创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)。注意：不同的书籍上对分类和名称略有差别

设计模式的原则

设计模式常用的七大原则（设计模式为什么这样设计的依据）：

单一职责原则
接口隔离原则
依赖倒转（倒置）原则
里氏替换原则
开闭原则
迪米特法则
合成复用原则

单一职责原则（SRP）

单一职责原则（Single responsibility principle）：对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A按照相应的职责分解为 A1，A2这两个类，分别去负责职责1和职责2。
例如：Dao层中的接口，每一个接口只负责对应实体类的增删改查。

例：

/**
 * @author 小关同学
 * @create 2021/9/1
 */
//交通工具类
//在run方法中，违反了单一职责原则
//解决方式：根据交通工具运行方式的不同，分成不同的职责类
class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上运行");
    }
}
public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("摩托车");
        vehicle.run("飞机");
    }
}

运行结果：
在这里插入图片描述
总运行结果我们可以看到，该交通工具类承担了不止一个职责，所以我们需要将它承担的职责再细分，分成相应承担不同职责的类或者方法

方案一：

/**
 * @author 小关同学
 * @create 2021/9/1
 */

//在类这个级别上遵守单一职责原则
class RoadVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在公路上运行");
    }
}
class AirVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在天空中运行");
    }
}
class WaterVehicle{
    public void run(String vehicle){
        System.out.println(vehicle+"在水中运行");
    }
}
public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        AirVehicle airVehicle = new AirVehicle();
        WaterVehicle waterVehicle = new WaterVehicle();
        airVehicle.run("飞机");
        roadVehicle.run("汽车");
        waterVehicle.run("船");
    }
}

运行结果：
在这里插入图片描述
方案二：

/**
 * @author 小关同学
 * @create 2021/9/1
 */
//在方法级别上遵守单一职责原则（建议还是在类级别上遵守单一职责原则）
class Vehicle2{
    public void runRoad(String vehicle){
        System.out.println(vehicle+"在公路上运行");
    }

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

    public void runWater(String vehicle){
        System.out.println(vehicle+"在水中运行");
    }
}
public class SingleResponsibility3 {
    public static void main(String[] args) {
        Vehicle2 vehicle2 = new Vehicle2();
        vehicle2.runAir("飞机");
        vehicle2.runRoad("汽车");
        vehicle2.runWater("轮船");

    }
}

运行结果：
在这里插入图片描述

有人可能会问，我使用if-else的方法也能实现上面两种方法的效果，为什么还要这个原则呢？
解释：使用if-else虽然也能完成上面的效果，但是会造成代码的耦合度和复杂度变高，耦合度高了我们以后再进行修改可能就会出现一些问题。

单一职责原则注意事项和细节：

降低类的复杂度，一个类只负责一项职责。
提高类的可读性，可维护性
降低变更引起的风险

通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级别违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离原则（ISP）

接口隔离原则（Interface Segregation Principle）的定义：

客户端不应该依赖它不需要的接口
类间的依赖关系应该建立在最小的接口上

其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿不堪。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加轻便灵活。

接口隔离原则和单一职责原则的区别：
接口隔离原则和单一职责原则的审视角度是不同的，单一职责原则要求类和接口职责单一，注重的是职责，是业务逻辑上的划分，而接口隔离原则要求方法要尽可能的少，是在接口设计上的考虑。总之，接口隔离原则要“瘦接口”，不要“胖接口”。

依赖倒转原则（DIP）

依赖倒转原则(Dependence Inversion Principle)是指：

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

例如：

public class DependecyInversion {

	public static void main(String[] args) {
		//客户端无需改变
		Person person = new Person();
		person.receive(new Email());
		person.receive(new WeiXin());
	}

}

//通过接口传递实现依赖
//定义接口
interface IReceiver {
	public String getInfo();
}

class Email implements IReceiver {
	public String getInfo() {
		return "电子邮件信息: hello,world";
	}
}

//增加微信
class WeiXin implements IReceiver {
	public String getInfo() {
		return "微信信息: hello,ok";
	}
}

遇事不决加一层…

依赖倒转有三种实现方式，它们分别是：

接口传递
构造方法传递
setter方法传递

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

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

里氏替换原则（LSP）

继承性的思考和说明：

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

定义：

里氏替换原则(Liskov Substitution Principle)通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能，即子类尽量不要重写父类的方法；
里氏代换原则告诉我们，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类对象的话，那么它不一定能够使用基类对象；
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象；
里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。

例子：

// A类
class A {
	// 返回两个数的差
	public int func1(int num1, int num2) {
		return num1 - num2;
	}
}

// B类继承了A
// 增加了一个新功能：完成两个数相加,然后和9求和
class B extends A {
	//这里，重写了A类的方法, 可能是无意识
	public int func1(int a, int b) {
		return a + b;
	}

	public int func2(int a, int b) {
		return func1(a, b) + 9;
	}
}

public class Liskov {

	public static void main(String[] args) {
		A a = new A();
		System.out.println("11-3=" + a.func1(11, 3));
		System.out.println("1-8=" + a.func1(1, 8));

		System.out.println("-----------------------");
		B b = new B();
		System.out.println("11-3=" + b.func1(11, 3));//这里本意是求出11-3
		System.out.println("1-8=" + b.func1(1, 8));// 1-8
		System.out.println("11+3+9=" + b.func2(11, 3));
	}
}

运行结果：
在这里插入图片描述

开闭原则（OCP）

基本介绍

开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

简单地来说就是一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

例子：
比如公司现在要弄一个打折活动，小说类的书籍要打折，按照开闭原则我们应该扩展来实现，而不应该修改原有代码，所以我们设置一个打折子类来继承小说类，在子类中实现打折方法，也遵循了里式替换原则【嘻嘻】。

//书籍接口类
interface IBook{
    String getName();
    double getPrice();
    String getAuthor();
}

//小说子类
class NovelBook implements IBook{

    String name;
    double price;
    String author;

    public NovelBook(String name,int price,String author){
        this.name = name;
        this.price = price;
        this.author = author;
    }

    public String getAuthor(){
        return this.author;
    }

    public String getName(){
        return this.name;
    }

    public double getPrice(){
        return this.price;
    }
}

//小说打折子类
class OffNovelBook extends NovelBook{

    public OffNovelBook(String name,int price,String author){
        super(name,price,author);
    }

    //当价格大于40，就打8析，其他价格就打9析
    public double getDiscountPrice(){
        if(this.price > 40){
            return this.price * 0.8;
        }else{
            return this.price * 0.9;
        }
    }
}

public class OpenClosedPrinciple {
    public static void main(String[] args){
        OffNovelBook offNovelBook = new OffNovelBook("笑傲江湖",100,"金庸");
        System.out.println("书籍名字："+offNovelBook.getName()+",书籍作者："+offNovelBook.getAuthor()+",书籍价格："+offNovelBook.getPrice());
        System.out.println("打折后的价格："+offNovelBook.getDiscountPrice());
    }
}

运行结果：
在这里插入图片描述

迪米特法则（DP）

基本介绍

一个对象应该对其他对象保持最少的了解。类与类关系越密切，耦合度越大
迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息
迪米特法则还有个更简单的定义：只与直接的朋友通信
直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现在成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
迪米特法则初衷在于降低类之间的耦合。由于每个类尽量减少对其它类的依赖，因此。很容易使得系统的功能模块独立，相互之间不存在(或很少有)依赖关系。

迪米特法则大概可以理解保持神秘感（朋友对你了解得不多）+只和朋友来往，以降低类之间的耦合，怎么感觉这么像特工。。。

合成复用原则

尽量使用合成/聚合的方式，而不是使用继承。

PS：也可以到我的个人博客查看更多内容
个人博客地址：小关同学的博客

小关同学喜欢吃汉堡

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
设计模式学习1：设计模式简述和设计模式原则

设计模式简述什么是设计模式？软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。设计模式的目的：代码高可用（相同作用的代码能重复使用）可读性（编程规范性）可扩展性（增加新的功能时，非常方便）可靠性（增加新的功能后，对原有的功能没有影响）代码的高内聚、低耦合设计模式的原则设计模式常用的七大原则（设计模式为什么这样设计的依据）：单一职责原则接口隔离原则依赖倒转（倒置）原则里氏替换原则开闭原则迪米特法则合成复用
复制链接

扫一扫