【贯穿设计模式】，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。为了能更好的设计出优雅的代码，为了能更好的提升自己的编程水准，为了能够更好的理解诸多技术的底层源码，设计模式就是基石，万丈高楼平地起,一砖一瓦皆根基。 ✨✨欢迎订阅本专栏✨✨
评论批评指正！和大家一起学习，一起进步! 👀
愿自己还有你在未来的日子，保持学习，保持进步，保持热爱，奔赴山海！ ❤️
⛹🏼 设计模式的七大原则
🤔 为了能够更好的进入到设计模式的学习过程中，在设计程序的过程中，我们应当遵守以下原则，这也是各种设计模式的基础（即：设计模式为什么这样设计的依据）
单一职责原则
- 开闭原则
- 依赖倒转原则
- 里氏替换原则
- 接口隔离原则
- 迪米特法则
- 合成复用原则
🏋🏼♀️单一职责原则
今天我们首先学习的是单一职责原则，一个类应该只有一个职责。
🤾🏼概述
- 该原则是指对一个类来说，应当只有一个引起它变化的原因，否则类应该被拆分，即一个类应该只有一个职责，其中的职责表示引起该类变化的原因。
- 简单理解为一个类应该只负责一项职责，这就是所谓的单一职责原则。
- 如一个A类它负责多个职责，那么应该将A类拆分为多个类，将类的负责的职责力度细分，拆分为A1、A2、A3类等等来分别执行某一个职责。
- 在我们编写代码的过程中，总会一些需求功能的变更，而我们也会很顺手的在每个类上加上各种各样的功能。这样意味着，无论任何需求要来，你都需要更改这个类，这样其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。如果一个类承担的职责过多，就等于把这些职责耦合起来，一个职责变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到很多意想不到的破坏。所以我们在对于一个复杂的功能实现中，也可以利用这种思想，将这个复杂功能进行细粒度拆分，逐个完成拆分后的任务，这样开发和设计起来更加高效，更不容易出错。
🤹🏼♀️特点
优点 ：
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多；
- 提高类的可读性和可维护性。复杂性降低，相对可读性和可维护性都会提高；
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
- 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则
🤸🏼♀️问题引出
package com.ygt.principle.single;
public class SingleResponsibility {
public static void main(String[] args {
// 这里创建出来学生类
Student student = new Student(;
// 学生中都会有一个功能，认真听讲上课
// 分别创建张三和李四去认真听讲上课
student.attendClass("张三";
student.attendClass("李四";
}
}
// 学生类
class Student {
// 上课方法
public void attendClass(String student {
System.out.println(student + " 正在认真听讲老师的内容上课！";
}
}
上面代码运行结果为：
张三 正在认真听讲老师的内容上课！
李四 正在认真听讲老师的内容上课！
🚵🏼♂️解决方案
解决方案1：
好学生类的上课方式是认真听讲上课，而坏学生类则是上课睡觉。
package com.ygt.principle.single;
public class SingleResponsibility2 {
public static void main(String[] args {
// 这里创建出来两个学生类，分别好好学生和坏学生
GoodStudent goodStudent = new GoodStudent(;
BadStudent badStudent = new BadStudent(;
// 好学生中认真听讲上课，分别创建张三和李四去认真听讲上课
goodStudent.attendClass("张三";
goodStudent.attendClass("李四";
// 坏学生中就不会认真听讲上课，只会上课睡觉，创建赵六这个老六去睡觉
badStudent.attendClass("赵六";
}
}
// 好学生类
class GoodStudent {
// 上课方法
public void attendClass(String student {
System.out.println(student + " 正在认真听讲老师的内容上课！";
}
}
// 坏学生类
class BadStudent {
// 上课方法
public void attendClass(String student {
System.out.println(student + " 正在听讲老师的催眠曲睡大觉~~~";
}
}
上面代码运行结果为：
张三 正在认真听讲老师的内容上课！
李四 正在认真听讲老师的内容上课！
赵六 正在听讲老师的催眠曲睡大觉~~~
解决方案2：
package com.ygt.principle.single;
public class SingleResponsibility3 {
public static void main(String[] args {
// 这里创建出来学生类
Student2 student = new Student2(;
// 调用好学生方法去执行认真听讲上课
student.goodAttendClass("张三";
student.goodAttendClass("李四";
// 调用坏学生方法去执行认真睡觉
student.badAttendClass("赵六";
}
}
// 学生类
class Student2 {
// 好学生上课方法
public void goodAttendClass(String student {
System.out.println(student + " 正在认真听讲老师的内容上课！";
}
// 坏学生上课方法
public void badAttendClass(String student {
System.out.println(student + " 正在听讲老师的催眠曲睡大觉~";
}
}
上面代码运行结果为：
张三 正在认真听讲老师的内容上课！
李四 正在认真听讲老师的内容上课！
赵六 正在听讲老师的催眠曲睡大觉~
这三种方式各有优缺点，那么在实际编程中，采用哪一中呢？其实这真的比较难说，需要根据实际情况来确定。我的原则是：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
🌸 完结
学好设计模式，让你感受一些机械化代码之外的程序设计魅力，也可以让你理解各个框架底层的实现原理。最后，祝大家跟自己能在程序员这条越走越远呀，祝大家人均架构师，我也在努力。 接下来期待第二话：开闭原则。 💪💪💪
🤩 当然如果这篇文章确定对你有点小小帮助的话，也请亲切可爱的人才们给个点赞、收藏下吧，非常感谢！🤗🤗🤗
💟 感谢各位看到这里！愿你韶华不负，青春无悔！让我们一起加油吧！ 🌼🌼🌼