关于面向对象的六大原则,自己的一些总结

1.开闭原则(开闭原则OCP)

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

       就像实现一个计算器一样,实现了简单的加减乘除之后,如果要加一些其他的运算,比如开根,比如求次方运算,这时候就不能对原来的代码进行修改,我们可以写一个基类Opreation,自带getCalValue(int opeA,int opeB)方法,所有加减乘除等操作都是这个类派生出来的操作类AddOperation,SubOperation,我们只要切换运算符号,就可以new一个相应的类出来,然后只要传进去两个操作数,我们就可以得到最后的结果,这样子就可以实现对扩展开放,对修改关闭。

2.里氏替换原则(Liskov Substitution Principle LSP)

子类必须能够替换基类,否则不应当设计为其子类。也就是说,子类只能去扩展基类,而不是隐藏或者覆盖基类。

就比如上面提到的计算器设计,我们就可以用派生出来的AddOperation,子操作类分别完成对操作数的加和减操作。

3.依赖倒置原则(依赖倒置原则DIP)

依赖于抽象而不依赖于具体。

说白了,就是针对接口编程,不要针对实现编程。

无论主板,CPU,内存,硬盘都是针对接口设计了,只要接口是稳定的,那么任何一个模块坏了都不会影响到其他的模块,说白了,主板不依赖于内存,内存也不依赖于主板,也就是高层模块和底层模块都没有互相依赖,他们依赖的都是接口。

4.接口隔离原则(接口隔离原理ISP)

第一种定义: 客户端不应该依赖它不需用的接口。

ISP可以达到不强迫客户(接口的使用方)依赖于他们不用的方法,接口的实现类应该只呈现为单一职责的角色(遵守SRP原则)。

  ISP还可以降低客户之间的相互影响——当某个客户程序要求提供新的职责(需求变化)而迫使接口发生改变时,影响到其他客户程序的可能性会最小。

第二种定义:类间的依赖关系应该建立在最小的接口上。

 比如在应用继承时,由于子类将继承父类中的所有可用的方法;而父类中的某些方法,在子类中可能并不需要。例如,普通员工和经理都继承自雇员这个接口,员工需要每天写工作日志,而经理则不需要。因此不能用工作日志来卡经理,也就是经理不应该依赖于提交工作日志这个方法。

  ISP强调的是接口对客户端的承诺越少越好,并且要做到专一。当某个客户程序的要求发生变化,而迫使接口发生改变时,影响到其他客户程序的可能性小。这实际上就是接口污染的问题。

 

5.单一职责原则(组成/聚合重用原则CARP)

就一个类而言,应该仅有一个引起它变化的原因。

比如手机,可能单一做好它的通话功能就非常棒了,它多一个摄像功能,而且如果做的还比较鸡肋的话,到用到摄像的时候,还不好使,修的话,你又要去拆一整个手机,去排查它坏在哪了,这就很尴尬了。

软件设计真正要做的许多内容,就是发现职责并把那些职责互相分离。如果你能够想到多余一个的动机去改变一个类,那么这个类就具有多于一个的职责。

单一职责原则和接口隔离原则的区别,其一,单一职责原则原注重的是职责;而接口隔离原则注重对接口依赖的隔离。其二,单一职责原则主要是约束类,其次才是接口和方法,它针对的是程序中的实现和细节;而接口隔离原则主要约束接口接口,主要针对抽象,针对程序整体框架的构建。

6.迪米特原则或者最少知识原则(得墨忒耳定律或最小知识原理LOD或LKP)

根本思想是强调了类之间的松耦合。

在类的结构设计上,每一个类都应当尽量降低成员的访问权限。

类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对有关系的类造成波及。也就是说,信息的隐藏促进了软件的复用。

比如说公司部门之间协作,你不需要知道要找这个部门的具体谁帮你做,你只需要知道找这个部门的主管是谁就好了,他会帮你安排人。

;