面向对象和面向过程的区别（成神之路一）

面向对象：

首先声明目前面向对象没有明确的定义，不同的阶段你对面向对象的理解也是不同的，在此鄙人只是发表一下自己的观点，有什么不正确的地方欢迎指正。

面向对象：万物皆对象，客观存在的和抽象的都可是对象，解决问题的一个方法也可以看成对象。说到底面向对象是一种解决问题的思想。本人也开始参与一些小项目，做的多了，也会加深一些理解，反过来看得话，面向对象编程就是把一个项目拆成一个个小模块，几个小模块组成一些实现特定业务功能。而这些业务模块，随着项目功能的不断增加，新人非常容易不注重各个模块的耦合度。会造成那种修改A模块中的每个模块，会影响到其他模块，导致开发效率低下，维护困难等问题，扯远了好像。

面向过程：

因为刚开始接触就是面向对象的思想，没有去从面向过程的思想去编写程序。也是从百度等搜索的，也算是比较容易理解的。与面向对象不同的思想，它是以过程为中心的编程思想，分析解决一个问题的过程，然后根据过程去编程解决这个问题，很容易造成“牵一发而动全身”的后果。以前相对简单的业务问题不是很明显，但随着业务复杂度的不断加大，其短板显而易见了，面向对象就应运而生了。

面向对象的三大特性：

封装、继承、多态，相信大多数兄die能够脱口而出。

封装：见名知意了，对数据和行为进行包装。也就是类了，它安全，方便。对自身及其属性进行权限设置，可以限定被所认可的类或者对象访问的，也可隐藏自己的一些属性或者行为。

继承：可以使用现有类的所有功能，在不进行编译的情况下扩展功能，是代码的复用，就Java而言，只支持单继承，为了弥补这一缺点，多实现应用而生。继承类之间的关系是属于的关系is-a。

多态：说到多态，大家通常会想到重写和重载。父对象的一种行为发生时，父对象的根据当前赋予子对象的不同特性，发生不同的行为。其实严格来说，重载并不算是多态特性，编译期时是对应的不同函数，是静态的并不是动态的。

 

总结一下：封装，隐藏实现细节，是代码模块化。继承，可以扩展已经存在的代码模块。二者都算是代码的重用。而多态是接口的重用。保证继承体系中某一属性或者行为的正确调用。

你以为程序中用到这三个特性就算是面向对象设计，图样图森剖。面向对象设计和面向对象是不同的。

面向对象的五大原则:

单一职责原则（SRP），开放封闭原则（OCP），里氏替换原则（LSP），依赖倒置原则（DIP），接口隔离原则（ISP）

单一职责原则：

一个类应该仅有一个引起它变化的原因（说起来简单，做起来难，其实我们去看看源代码，其面向对象设计原则很经典）直接搬过来一个例子：

职员类例子：
比如在职员类里，将工程师、销售人员、销售经理这些情况都放在职员类里考虑，其结果将会非常混乱，在这个假设下，职员类里的每个方法都要if else判断是哪种情况，从类结构上来说将会十分臃肿，并且上述三种的职员类型，不论哪一种发生需求变化，都会改变职员类！这个是大家所不愿意看到的。

原理：如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

没有任何的程序设计人员不清楚应该写出高内聚低耦合的程序，但是很多耦合常常发生在不经意之间，其原因就是：

职责扩散：因为某种原因，某一职责被分化为颗粒度更细的多个职责了。

解决办法就是遵守单一职责原则，将不同的职责封装到不同的类或模块中。

开放封闭原则：

既开放有封闭，矛盾不，不矛盾。对扩展开放，对更改封闭。

当我们的模块需要扩展时，可能是实际业务发生改变，也可能出现新出的需求，我们的模块能很好的支持扩展。更改封闭紧随而来，扩展模块时，我们不需要对源代码进行变动，这个原则对我们在设计类的时候很有帮助，坚持这个原则就必须尽量考虑接口封装，抽象机制和多态技术。

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。

对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。

开放封闭原则是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。

具体实例可参考百度百科开放封闭原则

里氏替换原则：

子类可以替换父类，并且出现在父类可能出现的任何地方，简言之，就是面向接口编程。父类尽可能的用接口或者抽象类来实现。好处就是父类接口进行扩展时，增加对应的新子类不影响当前功能的使用。

依赖倒置原则：

传统的结构化编程中，都是上层依赖下面的子模块来实现，称为高层依赖地底层。而依赖倒置原则就是反其道行之，让高层不再依赖底层模块。

那应该怎么解决呢，按照下面两个原则：

1.高层模块不应该依赖底层模块，二者都该依赖于抽象。

2.抽象不应该依赖细节，细节应该依赖于抽象。

不难看出都是依赖抽象，这样解释还是有点抽象哈。再具体点，其实也是面向对象的标志，依赖抽象参考以下生成规则：

1.任何变量，类都不应该有一个指向具体类的指针或者引用。

2.任何类都不应该从具体类派生。

3.任何方法都不该重写它的任何基类中已经实现了的方法。

依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

接口隔离原则：

客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。

使用多个专门的接口比使用单个接口要好的，在实际编程中，为了减少接口的定义，我们通常将许多类似的方法都放在一个接口中，随着功能的增多及复杂化，我们维护和实现接口时浪费了大量时间，客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上，也算是一种降低耦合度的原则。

以上原则都可参考百度百科，例子很形象，贴切