六个原则

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

六个原则¶

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

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

There should never be more than one reason for a class to change.

一个方法只做一件事吗，具体怎么划分？如修改用户信息（用户名、性别、年龄等）和修改密码。
层次分离，抽象出底层业务，供高层模块调用。

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

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）¶

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)¶

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)，最少知识原则¶

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

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

开闭原则¶

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

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

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