设计模式更新ing

设计模式

1、六大原则
- 1.1 单一设计原则 SRP
- 1.2 开闭原则
- 1.3 里氏替换原则
- 1.4 迪米特法则
- 1.5 接口隔离原则
- 1.6 依赖倒置原则
2、工厂模式

1、六大原则

1.1 单一设计原则 SRP

一个类应该只有一个变化的原因
比如一个视频软件，区分不同的用户级别包括访客，普通用户，VIP用户，每个用户对应的方法具体实现是不同的，根据用户级别的不同，有不同的行为。
最简单的想法：我们可能会把它放到ifelse里边
比如：

package com.example.demo;/*** @ClassName VedioUser* @Description TODO* @Author lukcy* @Date 2024/12/1 15:53* @Version 1.0*/
public class VedioUser {public void VedioUserTest(String UserType){if(UserType.equals("访客")){System.out.println("访客，480p");}else if(UserType.equals("普通用户")){System.out.println("普通用户，720p");}else if(UserType.equals("Vip用户")){System.out.println("Vip用户，1080p");}}
}

package com.example.demo;import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;@SpringBootTest
class DemoApplicationTests {@Testvoid contextLoads() {VedioUser vedioUser=new VedioUser();vedioUser.VedioUserTest("Vip用户");}}

使用SRP的话先定义一个接口然后定义三个实现类

package com.example.demo;/*** @ClassName IVedioUser* @Description TODO* @Author lukcy* @Date 2024/12/1 16:10* @Version 1.0*/
public interface IVedioUser {void content();void guanggao();
}

package com.example.demo.Impl;import com.example.demo.IVedioUser;
import org.springframework.stereotype.Component;/*** @ClassName VipUser* @Description TODO* @Author lukcy* @Date 2024/12/1 16:10* @Version 1.0*/
@Component
public class VipUser implements IVedioUser {@Overridepublic void content() {System.out.println("vip用户，1080p");}@Overridepublic void guanggao() {System.out.println("vip用户，没有广告");}
}

在这里插入图片描述
这里只实现了一个，类比即可，我们可以看出，每个类都有了类似的行为，但是一个类型对应不同的类。

1.2 开闭原则

扩展开放，修改关闭
比如：
我们有一个需求是计算圆形，矩形的面积
定义了一个接口，并且有了一个实现类，且这里的Π定义的是3.14，目前有一个新的需求就是需要一个Π是3.1415926的计算圆形的类，我们不想修改之前实现的类，那么我们可以进行扩展，定义一个新的类去继承该开始的类，只扩展圆形的面积即可。
两者互不影响
在这里插入图片描述

1.3 里氏替换原则

里氏替换原则更多的是强调子类在继承父类时，不应该改变父类的行为或破坏父类的契约，以保证替换的可行性。
开闭原则则强调在不修改现有代码的情况下，通过新增代码来扩展系统的功能。它要求通过扩展现有类或接口来实现新功能，而不是修改已有类。

1.4 迪米特法则

减少知道，减少干预。
比如学生，老师和校长，
校长专注于每一个平均分其实也就可以了，没必要关注到每个学生。
让老师管理对应的班级，并且提供班级平均分等方法即可。

1.5 接口隔离原则

就是分为小的接口，可以有不同的组合实现。
比如唱歌跳舞演戏。如果我们定为一个接口
其他演员来实现时就要全部实现，即使有的技能他没有，那需要特定标识来提示。
所以我们可以把唱歌，跳舞，演习分为三个接口，然后之后多接口实现就好。

1.6 依赖倒置原则

比如上级和下级，上级应该提出一个抽象接口，然后下级按照该接口来实现，上级只需要去调用不同部门对该接口的实现类即可。这样就是依赖倒置原则，而不是说上级去依赖于下级的具体实现，应该面向抽象编程而不是面向实现编程。
比如一个抽奖有随机抽奖和权重抽奖
我们只需要定义一个接口有一个抽奖方法就好
接下来有两个实现类一个随机抽奖类一个权重抽奖类都要实现该接口。
最后有一个专门的类去调用不同的实现
参数传入接口类型即可，实际的形参时再传入具体的实现类，我们不用关注具体细节，只用关注抽象的类即可。
在这里插入图片描述
如果不用这个就会变成下边这种关注于具体的实现，调用时也要关注具体的实现，而不是关注于抽象。

在这里插入图片描述

2、工厂模式

比如一个发放奖品的业务
奖品有爱奇艺会员，卡券等，如果不用工厂模式，那么我们想到的可能就是ifelse
比如：这里我们不仅需要new不同的奖品，而且new奖品之后的逻辑也同样写在这里，之后如果奖品增加，ifelse又会增多
在这里插入图片描述
如果我们运用工厂模式
首先需要设计一个接口
之后每个奖品都要实现该接口

在这里实现了单一原则一个类负责一个接口并且之后有拓展的话可以直接继承该接口进行拓展实现开闭原则同时 new和实际的奖品逻辑区分开了没有写在一起，但是如果奖品种类太多也会代码过多,通过后续的设计模式来补足。