设计模式 更新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 {
@Test
void 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 {
@Override
public void content() {
System.out.println("vip用户,1080p");
}
@Override
public 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和实际的奖品逻辑区分开了 没有写在一起 ,但是如果奖品种类太多 也会代码过多,通过后续的设计模式来补足。