面向对象与面向过程理解

本文源地址：

http://blog.csdn.net/ithzhang/article/details/52983530
http://blog.csdn.net/ithzhang/article/details/51952797

面向过程与面向对象

一位计算机界的大师曾说过，“我认为，面向对象的目标从来都不是复用和扩展，而是提供一种处理复杂问题的方法”。

面向过程讲究自顶向下逐步求精。找到一个系统的入口然后顺藤摸瓜，分析出每一步以及影响这一步的其他因素，我们就能够定义这个系统。

面向对象认为世界是有很多对象组成的，各个对象之间相互独立，平时并没有什么关系。在某些外力的作用之下对象之间相互协作，表现出一定的行为，最终塑造了这个复杂的世界。面向过程和面向对象都是人们认识和了解这个世界的手段和方法，并无优劣之分，只有是否适用之差别。

面向对象和面向过程的最根本区别就是提供了一种新的认识和了解复杂系统的方法。面向对象有一个术语：抽象层次。比如对一辆汽车来说，从整体上来看，它是由底盘、悬挂、发动机、变速箱、外壳等部件组成的。而从发动机这个抽象层次来看，它是由活塞、曲轴、连杆、火花塞、油底壳、缸壁等组成。不同的抽象层次上会有不同的认识。通过不断变换抽象层次，我们能对系统有个更好的认识。在每个层次上我们只需要关心当前层次上的对象和它们之间的交互。其他层次上的东西，与本层次无关。这样带来的好处是：无论出于哪个层次上，我们都面临有限的对象和复杂度，从而可以更专心的了解这个层次上的对象是如何工作的。通过不断分离关注点，达到降低复杂度的目的。

抽象层次的另一个好处就是更换低层次的零件不会对高层次进行影响。比如，更换全新的发动机之后不会导致汽车无法行驶，更换火花塞之后不会导致发动机无法运转。低层次的信息对高层次隐藏，高层次不知道也不想知道低层次的零件如何工作。

回到大师的话，面向过程需要分析出整个系统的所有细节，当系统规模足够复杂，复杂到了超越其处理能力，使用结构化程序设计常常有无处下手的无力感。采用面向对象方法，引入了有个抽象层次的概念，我们就能通过不断提升抽象级别来构建更大更复杂的系统。

抽象层次越高，具体信息越少，细节也就越少，也就越容易理解。而抽象层次越低，具体信息越多，细节也越多。细节越多越容易陷入枝枝叶叶的泥潭而无法自拔。一旦超越人脑的处理极限，就很难去理解了。人们认识事物总是习惯从表面到本质，由表及里的一步步去分析。刚认识一件事物时我们可以从外观、整体较高的抽象层次去认识，然后逐步深入。比如对一个不了解汽车的人讲汽车，我们可以从整体介绍汽车包括底盘、发送机、变速箱、悬挂等。这时我们的抽象层次是很高的。当介绍清楚之后，我们可以深入到下一个层次，比如讲发动机结构。在发动机结构讲清楚以后，我们在从力学、热学的角度讲述发动机的工作原理。这样逐步深入，结构清晰，听的人也容易理解。逐步的深入中我们的抽象层次是逐渐降低的。反过来如果上来就讲发动机工作原理，听的人必定一头雾水。上面这个由表面到机理的过程其实就是自顶向下方法。另一种方法是自底向上。先从内部、底层讲起，逐步提高抽象层次。

这两种方法都是分析、研究问题的方法。在软件开发过程中，主体上应该采用自顶向下的方法，用少量的概念抽象、概括系统，再逐步降低抽象层次，直到代码编写。同时辅以自底向上的方法，通过总结在较低抽象层次的实践经验，来改进较高层次的概念以提升软件质量。

抽象层次高了，具体信息越少，分析问题简单了，但是随之而来也会带来另一个问题：抽象层次太高。抽象层次太高具体信息太少，又会导致信息量不足。所以在面向对象的分析过程中，在适当的时候选择适当的抽象层次是十分重要的。

层次确定好了，接下来就是在该层次上进行面向对象的分析工作了。无论任何时候在同一个抽象层次上，都应当将对象看成一个不可分割的整体。无论对象的规模多么大，大到一个国家、一座工厂，只要我们认为它是对象，它与其他对象交互时就是一个整体，不能分割。这就是说的对象的原子性，一旦破坏了原子性，就表示在同一抽象层次上 的对象不具备同一粒度，就将使得分析工作陷入混乱 。

在分析工作中，应该牢记对象有一个边界，不应该打破边界去窥探对象内部。形象一点来说，对象看上去就像是一个鸡蛋，蛋壳就是鸡蛋的边界。在分析对象的过程中。对鸡蛋的所有关系都是通过蛋壳发生。如果我们试图了解对象内部的细节，就像打破蛋壳去窥探鸡蛋内部，内部一团黏黏糊糊，无从下手。

下面内容主要关注以下四个方面：

1. 面向对象为什么那么难？
2. 类和对象是从石头里蹦出来的么？
3. 设计模式有那么重要么？
4. UML和面向对象什么关系？

首先我们来看下为什么面向对象那么难。很多科班出身的程序猿，当然也包括我。第一门编程语言学习的是C语言。众所周知，C语言是一门面向过程的语言，在编写复杂的C程序时，用的最多的就是流程图和伪代码。只要使用流程图详细描述出程序的每一步，就可以很容易的照猫画虎将流程图转换成C代码。这也是C语言这类面相过程语言的特点，讲究自顶向下逐步求精。任何系统，只要找到它的入口，从入口开始，详细分析它的每一步以及影响这一步的所有因素，然后顺藤摸瓜，直至分析完整个系统。

很多人的思维被面向过程先入为主，每次拿到一个需求时，都会强迫自己去分析所有的流程。小的系统还好，如果一个相对复杂的系统，流程众多且复杂、参与者众多，这个时候尝试去分析其中的每一步，经常会遇到陷入业务细节的泥潭无法自拔的问题。而面向对象思想的出现就是为了解决这类复杂的问题。

面向过程存在的另一个问题是，整个系统的分析是顺序的，下一步依赖上一步的分析结果。如果上一步不稳定或存在问题，以后就死翘翘了。我们经常说瀑布式软件开发过程存在问题，大力提倡敏捷，一个很重要的原因是：瀑布式开发过程太过依赖上一步的结果，一旦上一步存在问题，后面将会全盘皆输。这是不能令人接受的。

C++这门编程语言，既支持面向对象又支持面向过程。因此我们在实现一个东西时，既可以这样做又可以那么做。过多的选择反而让我们无所适从。有时候我们经常会想明明加一个else、case或者在一个方法里实现的问题，为何要使用那么多类来实现。这不是多此一举吗。有些时候确实是多此一举。但面向对象语言存在的目的就为了构建可维护、可扩展、灵活性好的系统。可维护、可扩展和可维护听起来很高大上，但是只是飘在天上的遥远关键词，好像在我这里无法落地。无法落地的原因就是你还没有真正理解什么是面向对象。

面向对象关注类、对象以及对象间的交互。再复杂的系统，都是由相互独立的对象通过一定的交互和协作来完成。就像现实中大家协作完成一件事情一样，每个人各司其职，既相互独立又关系密切。而所谓的面向对象的系统，就是我们的系统有很多相互独立的对象。每个对象具有一定的职责，对象之间相互交互或协作。整个软件系统就是靠这些众多对象之间的交互来运作。

类和对象是可以依据一定的规则推导出来的。OOA（面向对象分析）和OOD（面向对象设计）就是叩开面向对象大门的金钥匙。通过OOA、OOD我们发现和描述对象、定义对象的职责、描述对象间的交互等等。

很多初学者听别人说到过设计模式很重要，但是却不明白为什么设计模式如此重要。设计模式是计算机大牛们在编程时，针对某些特定问题总结出来的一套经验。经典设计模式有23种，后来又慢慢扩展越来越多。学会前人的这样经验固然重要，但是却没有想象中的重要。沿着前人的车辙，固然可以让我们少走弯路，但更要的是学会前人分析解决问题的思路。大家可以看到每种设计模式在介绍时，都会有一个前提，即这个模式在XX情况下适用，可以解决什么问题，有什么样的副作用。所以每种设计模式都有自己的适用背景，平时使用时如果不考虑这些背景以及导致的副作用，经常会出现得不偿失的效果。很多人都很苦恼的是为何我看了那么多的设计模式，却仍然无法将设计模式应用到我的工作中去。对设计模式没有那么了如指掌是一方面的问题，但更重要的是经典的设计模式背景太过纯粹，而我们的所面临的背景相对复杂。有些时候这些设计模式是不能那么轻而易举原封不动的照搬过来。因此工作中经常遇到的就是我们使用的设计模式并不是纯粹的XX设计模式，而是基于它的改进或变体或者是几种设计模式的混用。设计模式是面向对象思想的很好的体现，应用了设计模式的系统，具备很好的灵活性。对象之间解耦合，内聚性强。很容易扩展和修改。应用设计模式的设计良好的系统，后面维护起来也很容易，不像我们的代码出现越维护越糟糕，这里一句if那里一句magic code，类、方法变得臃肿，职责越来越不清晰、分支越来越多，圈复杂度越来越高，四处有重复代码。读起来都费劲，更别提基于此继续修改了。

设计模式也是基于面向对象思想总结出来的，因此比掌握设计模式更重要的是学会面向对象的思想。当你达到一定的高度，你也可以创造属于自己的设计模式。因此比掌握某个设计模式更重要的是学会面向对象的思想，哪怕没有应用任何设计模式，也一样可以构造出好的面向对象的代码。

UML （Unified Modeling Language）统一建模语言。 是一种可视化的建模语言。用来描述需求、设计。方便参与软件系统构建的各方交流沟通。

就像学会英语这门外语并不能保证你口若悬河出口成章字字珠玑一样。学会UML只是让你有了可以表达和描述你的设计的工具。UML只是和面向对象更配哦。

现在软件分工越来越细，需求分析、建模、设计、实现往往有很多人参与，UML的出现方便了各方的交流沟通。使用各种图来描述系统，比文字更有清晰直观，结合文字描述更容易理解。

UML包括九种图：用例图、类图、对象图、状态图、序列图（顺序图）、协作图（通信图）、活动图、构件图、部署图。最常用到的图是用例图、类图、序列图

从上面大家可以看到，UML并不包括流程图。流程图这个东西是面向过程时代的产物。它有一个致命的缺陷就是只描述了流程，却无法给出有哪些对象参与以及对象间的协作。UML定义了活动图用于替代流程图，活动图中引入了泳道的概念，泳道即代表每一个参与的对象。因此推荐大家在写概要设计文档时避免使用流程图，而应该使用活动图。概要设计使用流程图，只是描述了业务流程，并没有进行任何设计。流程图描述的客户业务流程应该在更早一些的产品需求文档里体现。

UML不仅仅可以在设计阶段使用，还可以应用在需求阶段。需求分析阶段使用用例图、用例文本描述整个系统的功能范围。设计阶段使用类图说明类之间的静态结构关系、使用序列图说明类之间的交互顺序、使用活动图描述复杂业务流程。