SOLID设计原则中，如何体现单一职责原则？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1315个文字，预计阅读时间需要6分钟。
介绍SOLID原则是由5个设计原则组成的，分别为：S（单一职责原则）、O（开闭原则）、L（里氏替换原则）、I（接口隔离原则）和D（依赖倒置原则）。分别解释如下：
（S）单一职责原则：一个类应该只有一个引起它变化的原因。（O）开闭原则：软件实体应该对扩展开放，对修改关闭。（L）里氏替换原则：任何可由基类对象替换的派生类对象，都能在不修改原有代码的前提下替换基类对象。（I）接口隔离原则：多个特定客户端接口，而不是单一接口，客户端应该与接口的抽象层而非实现层耦合。（D）依赖倒置原则：高层模块不应该依赖低层模块，两者都应该依赖于抽象。
单一职责原则SRP的英文是Single Responsibility Principle。
介绍SOLID 原则是由 5 个设计原则组成的，分别为：(S)单一职责原则、(O)开闭原则、(L)里式替换原则、(I)接口隔离原则和(D)依赖反转原则；
单一职责原则SRP单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP；
它的意思是一个类或者模块只负责完成一个职责，也就是说不要设计大而全的类，要设计粒度小、功能单一的类；
换个角度讲，就是一个类如果包含两个或两个以上业务不相干的功能，那它就不满足单一职责原则，比如一个类包含了用户的操作和订单操作；
如何判断一个类是否单一呢？其实还是要根据实际情况来分析，例如：我们可以先写个大概的类来满足现有的业务需求，当这个类业务不断扩展，代码越来越多时，这时候我们就需要考虑拆分为几个更细的颗粒度；
开闭原则OCP开闭原则的英文全称是 Open Closed Principle，简写为 OCP；
它的意思是软件实体（模块、类、方法等）应该对扩展开放、对修改关闭，即应该在已有代码基础上拓展代码，而不是直接修改已有代码（当然并不是说完全不修改代码，而是以最小修改代码的代价来完成新功能开发）;
换个角度讲，就是一段代码是否易扩展，如果某段代码能应对未来需求变化时，做到开闭原则，那就是说明这段代码扩展性好；
里式替换原则 LSP里式替换原则的英文翻译是：Liskov Substitution Principle，缩写为 LSP;
它的意思是父类定义了函数的约定，子类可以改变函数的内部实现逻辑，但不能改变函数原有的约定，即不破坏原有程序的正确性（这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明）；
换个角度，比如，父类定义了一个按照数量排序的函数，而子类重写了这个函数是按日期来排序的，这就违反了里式替换；或者说父类定义了函数抛出TestException异常，那么子类设计时只能允许抛出TestException异常，其他任何异常抛出都不行；
接口隔离原则 ISP接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP;
它的意思是客户端不应该被强迫依赖它不需要的接口，这里的接口可以理解为1：api接口集合 2：单个api接口或者函数 3：oop中的接口；
换个角度，比如，一个接口有查询的函数又有删除的函数，如果一个类实现了这个接口，但只用到查询的函数，而更新函数不用，就违反了接口隔离原则；
依赖反转原则 DIP依赖反转原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP;
它的意思是高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。这里的高层模块为调用者，底层模块为被调用者；
换个角度，比如，tomcat是运行web应用程序的容器，web应用部署在tomcat下，便可被tomcat调用执行，所以tomcat为高层模块，web应用程序为底层模块。tomcat和应用程序代码之间没有直接依赖关系，而是两者依赖同一个抽魈，即servlet规范；
本文共计1315个文字，预计阅读时间需要6分钟。
介绍SOLID原则是由5个设计原则组成的，分别为：S（单一职责原则）、O（开闭原则）、L（里氏替换原则）、I（接口隔离原则）和D（依赖倒置原则）。分别解释如下：
（S）单一职责原则：一个类应该只有一个引起它变化的原因。（O）开闭原则：软件实体应该对扩展开放，对修改关闭。（L）里氏替换原则：任何可由基类对象替换的派生类对象，都能在不修改原有代码的前提下替换基类对象。（I）接口隔离原则：多个特定客户端接口，而不是单一接口，客户端应该与接口的抽象层而非实现层耦合。（D）依赖倒置原则：高层模块不应该依赖低层模块，两者都应该依赖于抽象。
单一职责原则SRP的英文是Single Responsibility Principle。
介绍SOLID 原则是由 5 个设计原则组成的，分别为：(S)单一职责原则、(O)开闭原则、(L)里式替换原则、(I)接口隔离原则和(D)依赖反转原则；
单一职责原则SRP单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP；
它的意思是一个类或者模块只负责完成一个职责，也就是说不要设计大而全的类，要设计粒度小、功能单一的类；
换个角度讲，就是一个类如果包含两个或两个以上业务不相干的功能，那它就不满足单一职责原则，比如一个类包含了用户的操作和订单操作；
如何判断一个类是否单一呢？其实还是要根据实际情况来分析，例如：我们可以先写个大概的类来满足现有的业务需求，当这个类业务不断扩展，代码越来越多时，这时候我们就需要考虑拆分为几个更细的颗粒度；
开闭原则OCP开闭原则的英文全称是 Open Closed Principle，简写为 OCP；
它的意思是软件实体（模块、类、方法等）应该对扩展开放、对修改关闭，即应该在已有代码基础上拓展代码，而不是直接修改已有代码（当然并不是说完全不修改代码，而是以最小修改代码的代价来完成新功能开发）;
换个角度讲，就是一段代码是否易扩展，如果某段代码能应对未来需求变化时，做到开闭原则，那就是说明这段代码扩展性好；
里式替换原则 LSP里式替换原则的英文翻译是：Liskov Substitution Principle，缩写为 LSP;
它的意思是父类定义了函数的约定，子类可以改变函数的内部实现逻辑，但不能改变函数原有的约定，即不破坏原有程序的正确性（这里的约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明）；
换个角度，比如，父类定义了一个按照数量排序的函数，而子类重写了这个函数是按日期来排序的，这就违反了里式替换；或者说父类定义了函数抛出TestException异常，那么子类设计时只能允许抛出TestException异常，其他任何异常抛出都不行；
接口隔离原则 ISP接口隔离原则的英文翻译是“ Interface Segregation Principle”，缩写为 ISP;
它的意思是客户端不应该被强迫依赖它不需要的接口，这里的接口可以理解为1：api接口集合 2：单个api接口或者函数 3：oop中的接口；
换个角度，比如，一个接口有查询的函数又有删除的函数，如果一个类实现了这个接口，但只用到查询的函数，而更新函数不用，就违反了接口隔离原则；
依赖反转原则 DIP依赖反转原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP;
它的意思是高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。这里的高层模块为调用者，底层模块为被调用者；
换个角度，比如，tomcat是运行web应用程序的容器，web应用部署在tomcat下，便可被tomcat调用执行，所以tomcat为高层模块，web应用程序为底层模块。tomcat和应用程序代码之间没有直接依赖关系，而是两者依赖同一个抽魈，即servlet规范；