跳转至

六个原则

时间: 2017-06-29 00:08:43

六个原则#

原则是一种约束，按照原则做设计和开发理论上可以避免一些问题，提高项目的可维护性和开发效率，以及代码的可读性。但是有时候如果按照原则来做项目的话，可能会出现不可预期的坏结果。因此在遵循原则的同时也要考虑实际情况，做好取舍。

单一职责原则（Single Responsibility principle）#

1
There should never be more than one reason for a class to change.
  • 一个方法只做一件事吗，具体怎么划分？如修改用户信息（用户名、性别、年龄等）和修改密码。
  • 层次分离，抽象出底层业务，供高层模块调用。

里氏替换原则(Liskov Substitution Principle)#

1
2
3
4
5
If for each object O1 of Type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

O1 --> S;
O2 --> T;
P -->T <==> P --> S; ==>S extends T

父类出现的地方可以使用子类替换。在 JAVA 中继承和接口都可以满足里氏替换原则。

  • 继承关系，实现多态。 Human human = new Female();

依赖倒置原则（Dependence Inversion Principle）#

1
High level modules should not depend upon low level modules,Both should depend upon abstractions,Abstractions should not depend upon details. Details should depend upon abstractions.
  • 高层模块不应该依赖低层模块，两者都应该依赖其抽象。
  • 抽象不应该依赖细节
  • 细节应该依赖抽象

尽量依赖抽象类和接口，而不是依赖具体的类，依赖抽象的好处是 依赖的抽象可以被不同的具体的实现类替代，更换不同的实现类就能实现不同的业务，类似于模块儿更换，换一个模块换一种功能，避免更改原有业务实现。

接口隔离原则( Interface Segregation Principle)#

1
2
3
4
Clients should not be forced to depend upon interfaces that they don't use.

The dependency of one class to another one should depend on the smallest possible interface.
//最小知识是原则，只知道自己需要知道的，不关心其他的。不会造成混乱

通俗点说就是接口的方法要尽量少，根据接口本身区分业务，而不是通过方法区分业务。

迪米特法则(Law of Demeter)，最少知识原则#

  1. 只和朋友类进行交流，朋友类：成员变量、方法的输入输出参数。出现在方法体中的类不属于朋友类。==>不要在方法内部构造对象。
  2. 对朋友了解的越少越好。
  3. 是自己的就是自己的，如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

减少使用依赖类所依赖的类。

开闭原则#

1
Software entities like classes, modules and functions should be open for extension but closed for modifications.

对扩展开放，对修改关闭。

  • 对于可也通过模块儿扩展和修改原有业务逻辑实现的业务，避免修改原有的业务逻辑。
  • 系统设计的时候多考虑扩展性，对于以后的业务追加，尽量可以通过扩展实现。
  • 避免过于复杂的业务逻辑，业务逻辑越复杂修改就越困难，复杂业务可以拆分成模块，这样即使修改也只需要部分模块，代码也更加清晰。