本文主要是介绍OO原则，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在看《HeadFirst》的过程中发现了OO原则和之前学过的《大话设计模式》有点不一样的的地方。总结一下，分享给大家。
首先我们来看《大话设计模式》里的六大原则。也可以访问之前的博客《23种设计模式》。
1、开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
2、单一职责原则（SRP），就一个类而言，应该仅有一个引起它变化的原因。
3、依赖倒转原则：A. 高层模块不应该依赖低层模块。两个都应该依赖抽象。B. 抽象不应该依赖细节。细节应该依赖抽象。
4、里氏代换原则（LSP）：子类型必须能够替换掉它们的父类型。
5、合成/聚合复用原则（CARP），尽量使用合成/聚合，尽量不要使用类继承。
6、迪米特法则（LoD），如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
再来看看《HeadFirst》中的原则，比《大话设计模式》多出了三个原则。
1、找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2、针对接口编程，而不是针对实现编程
3、多用组合，少用继承
4、为交互对象之间的松耦合设计而努力
5、开放-封闭原则：类应该对扩展开放，对修改关闭
6、依赖倒置原则：依赖抽象，不要依赖具体类
首先，这个原则听起来很像是“针对接口编程，不针对实现编程”，不是吗？的确很相似，然而这里更强调“抽象”。这个和原则说明了：不能让高层组件依赖低层组件，而且，不管高层或低层组件，“两者”都应该依赖于抽象。
7、最少知识原则：只和你的密友谈话。
最少原则告诉我们要减少对象之间的交互，只留下几个“密友”。希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中的一部分，会影响到其他部分。如果许多类之间互相依赖，那么这个系统就会变成一个易碎的系统，它需要花许多成本维护，也会因为太复杂而不容易被其他人了解。
8、好莱坞原则：别调用（打电话给）我们，我们会调用（打电话给）你。
好莱坞原则可以给我们一种防止“依赖腐败"的方法。当高层组件依赖低层组件，而低层组件又依赖高层组件，而高层组件又依赖边侧组件，而边侧组件又依赖低层组件时，依赖腐败就发生了。在这种情况下，没有人可以轻易地搞懂系统是如何设计的。
在好莱坞原则之下，我们允许低层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件。换句话说，高层组件对待低层组件的方式是“别调用我们，我们会调用你”。
9、一个类应该只有一个引起变化的原因。
我们知道要避免类内的改变，因为修改代码很容易造成许多潜在的错误。如果有一个类具有两个改变的原因，那么这会使得将来该类的变化几率上升，而当它真的改变时，你的设计中同时有两个方面将会受到影响。为了解决这个问题，我们将一个责任只指派给一个类。
小结：
学设计模式的时候我们应该搞清楚设计模式和原则之前是什么样的关系。设计代码首先是要遵循这些原则的。那些牛人们通过用这些原则来设计代码总结出来的经验最终成了我们熟知的设计模式。
这篇关于OO原则的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
