??? 茫茫人海千千万万，感谢这一刻你看到了我的文章，感谢观赏，大家好呀，我是最爱吃鱼罐头，大家可以叫鱼罐头呦~???
从今天开始，将开启一个专栏，【贯穿设计模式】，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。为了能更好的设计出优雅的代码，为了能更好的提升自己的编程水准，为了能够更好的理解诸多技术的底层源码， 设计模式就是基石，万丈高楼平地起,一砖一瓦皆根基。 ✨✨欢迎订阅本专栏✨✨
? 本人不才，如果文章知识点有缺漏、错误的地方 ?，也欢迎各位人才们评论批评指正！和大家一起学习，一起进步! ?
❤️ 愿自己还有你在未来的日子，保持学习，保持进步，保持热爱，奔赴山海！ ❤️
? 最后，希望我的这篇文章能对你的有所帮助！ ? 点赞 ? 收藏 ⭐留言 ? 都是我最大的动力！
⛹? 设计模式的七大原则
? 为了能够更好的进入到设计模式的学习过程中，在设计程序的过程中，我们应当遵守以下原则，这也是各种设计模式的基础（即：设计模式为什么这样设计的依据）
单一职责原则开闭原则依赖倒转原则里氏替换原则接口隔离原则迪米特法则合成复用原则
??♀️单一职责原则
今天我们首先学习的是单一职责原则，一个类应该只有一个职责。
??概述
该原则是指对一个类来说，应当只有一个引起它变化的原因，否则类应该被拆分，即一个类应该只有一个职责，其中的职责表示引起该类变化的原因。简单理解为一个类应该只负责一项职责，这就是所谓的单一职责原则。如一个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 + " 正在认真听讲老师的内容上课！"); }}上面代码运行结果为：
张三 正在认真听讲老师的内容上课！李四 正在认真听讲老师的内容上课！
可事实上，你会发现在学校中，总不可能所有的学生都是会认真上课的，也是有分好学生或者坏学生的吧，好学生都会认真上课，坏学生总是在上课时候打瞌睡，那以我们现在的代码，貌似完成不了这种需求，现在的attendClass上课方法中，如果也负责坏学生上课的方法的话，就会导致违反了单一职责原则。接下来就看下上面的出现的问题如何解决。
??♂️解决方案
解决方案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 + " 正在听讲老师的催眠曲睡大觉~~~"); }}上面代码运行结果为：
张三 正在认真听讲老师的内容上课！李四 正在认真听讲老师的内容上课！赵六 正在听讲老师的催眠曲睡大觉~~~
可是我们会发现如果这样修改花销是很大的，除了将原来的类分解之外，还需要修改main方法中代码。并且，如果又多一种其他类型的学生的话，类又需要重新拆分，main方法中的代码又得重新改一遍，所以这样虽然遵守了单一职责原则，但其实是不可取的。接下来就看下上面的出现的问题如何解决。
解决方案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 + " 正在听讲老师的催眠曲睡大觉~"); }}上面代码运行结果为：
张三 正在认真听讲老师的内容上课！李四 正在认真听讲老师的内容上课！赵六 正在听讲老师的催眠曲睡大觉~
可以看到，这种修改方式没有对类进行一个改动，反而是在类中新加了一个方法，这样虽然也违背了单一职责原则，但在方法级别上却是符合单一职责原则的，这也体现了只负责一项职责的功能，并且对于的代码的改动相对会比较少。
这三种方式各有优缺点，那么在实际编程中，采用哪一中呢？其实这真的比较难说，需要根据实际情况来确定。我的原则是：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
? 完结
相信各位看官看到这里大致都对设计模式中的其中一个原则有了了解吧，单一职责原则实际上的定义就是一个类应该只负责一项职责，以此控制类的粒度大小、将对象解耦、提高其内聚性。
学好设计模式，让你感受一些机械化代码之外的程序设计魅力，也可以让你理解各个框架底层的实现原理。最后，祝大家跟自己能在程序员这条越走越远呀，祝大家人均架构师，我也在努力。接下来期待第二话：开闭原则。 ???
文章的最后来个小小的思维导图：
? 本人不才，如有什么缺漏、错误的地方，也欢迎各位人才们评论批评指正！???
? 当然如果这篇文章确定对你有点小小帮助的话，也请亲切可爱的人才们给个点赞、收藏下吧，非常感谢！???
? 虽然这篇文章完结了，但是我还在，永不完结。我会努力保持写文章。来日方长，何惧车遥马慢！✨✨✨
? 感谢各位看到这里！愿你韶华不负，青春无悔！让我们一起加油吧！ ???
? 学到这里，今天的世界打烊了，晚安！???
