1.单一职责原则(SPR)
就一个类而言,应该仅有一个引起它变化的原因.
2.开放-封闭原则
软件实体(类,模块,函数等)应该可以扩展,但是不可修改
开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象,然而,对于应用程序中的每个部分都刻意进行抽象同样不是一个好注意.拒绝不成熟的抽象和抽象本身一样重要
3.依赖转换原则
1.高层模块不应该依赖底层模块,两个都应该依赖抽象
2.抽象不应该依赖细节,细节应该依赖于抽象,说白了就是要针对接口编程,不要对实现编程
4.里氏转换原则
一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别,也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化
迪米特法则
也叫最少只是原则.如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用.
在类的结构设计上,每个类都应当尽量降低成员的访问权限.
类之间的耦合约弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及.