设计模式 更新ing

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和实际的奖品逻辑区分开了 没有写在一起 ，但是如果奖品种类太多 也会代码过多,通过后续的设计模式来补足。