1. 单一职责原则: 就是每个类 或者 函数方法 只负责一个逻辑功能或者说逻辑单元,很好理解的。但是要注意的就是要注意划分的粒度。
2. 里氏替换原则:每个可以用父类的地方,都可以用子类。如果一个函数接受某个类的父类作为参数,那么传入该类的子类一定也可以。实际上从语言的层面,这条规则也是满足的。但是这里要求的实逻辑不出bug。其实就是要去,子类要实现父类所有的方法,同时也慎重覆盖父类的方法,做的不好就会导致逻辑bug。
3 接口隔离原则:还有一个名字更形象叫最少知识原则,就是不要告诉我不需要的信息,只要告诉我我必须知道的消息。这样就将依赖降到最低程度。就是功能最小粒度拆分,当然也不能太小了。加入有一个类他只是处理可以飞行的物体,那么只要传入flyable 接口,而不要传入 bird 接口,因为bird 还包含 walkable 接口。所以设计的时候,要将相应的类进行接口拆分,使用的时候用哪个就传哪个。
4. 依赖倒置原则:高层代码要依赖抽象,也不要依赖具体细节。这样的好处,就是利于并行开发,接口定义好了,就可以各自做自己的工作。同时接口定义好了,后面扩展也方便,不影响上层代码。
5. 迪米特法则: 只和朋友对话,朋友就是 函数的参数,或者函数返回类,或者成员变量。这条法则要求高内聚,低耦合。类的内部不要出现不适朋友的类。
6. 开闭原则: 就是对扩展开发,对修改关闭。其实这个比较好理解,一个运行很久的代码,经过了实践的检验,那么就不要去改它了,可以去扩展他。还有改类会导致牵一发动全身的风险。换句话说,在变化发生的时候,是通过扩展的方式来修改,而不是通过修改的方式来扩展。
总结:程序或者一个系统开发出来,随着时间的推移肯定是需要不断的更新,不断的修改,那么程序的设计就必须为这些变化做准备,随时准备迎接变化,主要是目前不可以预知的变化,那么我们就尽量做到当变化发生的时候,对原有的系统冲击最小。然而,6大原则 分别从各个角度和各个方面来知道,怎么做可以在发生变化的时候,可以以最小的代价完成更新,同时保证健壮性。核心观点就是要抽象,分离,分而治之,不要过多的纠缠态细节。还有一点就是始终贯彻的,要高内聚,低耦合。