单一职责原则——面向对象设计原则 (biancheng.net)
设计模式六大原则记忆：SOLLID，坚固的，记住他们，你写的程序也会变得Solid。
1 单一职责原则（S | Single Responsibility Principle）
含义：单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
一个类不应承担过多的职责，对内而言承担过多职责会增加类的复杂度，某一职责的修改可能会影响其他模块。对外而言用户像使用单个职责时，却不得不将其他职责包含进来。
单一职责原则需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
2 开闭原则（O | Open Closed Principle）
含义：软件实体应当对扩展开放，对修改关闭。含义是，当需求发生更改时，尽量在不改动已有源码的情况下拓展模块功能，时期满足新的需求。
开闭原则的主要优点：
- 对于软件测试：测试时仅需要对新增代码进行测试，因为原有代码没有改动。
- 提高代码的可复用性：类设计的粒度越小，复用性就越强
- 程序可维护性强：遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护
3 里氏替换原则（L | Liskov Substitution Principle）
含义：继承必须确保父类所拥有的性质在子类中仍然成立。即子类可以扩展父类的功能，但不能改变父类原有的功能。
里氏替换原则的要求：
- 如果子类覆盖父类的方法，那么子类的返回结果的范围需要小于等于父类，访问权限不得小于父类，抛出的异常也不得大于父类的异常。
如果违背了里氏原则，则类对象出现在父类出现的地方则会报错。
4 迪米特法则（L | Liskov Substitution Principle）
迪米特法则（Law of Demeter，LoD）又叫作最少知道原则。
含义：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则强调以下两点：
- 从依赖者的角度来说，只依赖应该依赖的对象。
- 从被依赖者的角度说，只暴露应该暴露的方法。
具体措施：
- 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有 利于实现可复用的目标。
- 在类的结构设计上，尽量降低类成员的访问权限。
- 在类的设计上，优先考虑将一个类设置成不变类。
- 在对其他类的引用上，将引用其他对象的次数降到最低。
- 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
5 接口隔离（I | Interface Segregation Principle）
含义：客户端不应该被迫依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上。
接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。
具体措施：
- 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
- 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
- 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
6 依赖倒置原则（D | Dependence Inversion Principle）
含义：高层模块不应该依赖于底层模块，两者都应该依赖于抽象。抽象不应该依赖于细节。
软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。
具体措施：
- 每个类尽量提供接口或抽象类，或者两者都具备。
- 变量的声明类型尽量是接口或者是抽象类。
- 任何类都不应该从具体类派生。
- 使用继承时尽量遵循里氏替换原则。
网友评论