一篇本人在公司做面向对象技术分享时的文章

一篇本人在公司做技术分享时的文章！

上次插件进程化分享时，感觉大家对面向对象思想的理解还停留在很基础的层次。面向对象思想确实很难理解，因此学习面向对象思想并非一日之功。我看过很多面向对象的书，包括OOA、OOD、设计模式、UML、架构设计等，因此对于面向对象思想有了一些自己的浅显的理解，希望能对大家理解面向对象有所帮助。由于仅仅处于入门阶段，很多东西理解并不是那么透彻，可能存在很多错误或理解不够准确的地方，希望各位能指出来大家共同进步。

面向对象的东西很多，因此打算分多次介绍。这次主要介绍一些基础概念，后面如果有机会再跟大家进一步的讨论面向对象跟深入的东西。

这次主要关注以下四个方面：

1.       面向对象为什么那么难？

2.       类和对象是从石头里蹦出来的么？

3.       设计模式有那么重要么？

4.       UML和面向对象什么关系？

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

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

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

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

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

但是这些对象或类是如何产生的。是从石头里蹦出来的么？很多时候大家在介绍自己的设计时，会说我觉得这里应该有一个类，它有XX职责，然后跟XX是什么关系，它们进行交互。当问他为何要有这样一个对象时，好像也说不太清楚，只能告诉你是通过多年的经验分析出来的，等你到我这个年纪也会明白，然后留下无助的你继续迷茫，还是不懂为何要在这里安置这样一个类。经验这个东西的最大特点就是不能复制和验证。别人的经验只能保证他的设计，而无法有效指导你进行设计，别人的经验也无法给出详细的推导，也就无法验证其正确性。

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

 

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

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

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

如果有人跟你说学好UML你就学会了面向对象，你可千万不要相信他。

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

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

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

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

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

         第一次分享不准备写太多，有些关键词先让大家混个耳熟吧，后面再给大家详细介绍！

                   关于面向对象和面向过程的本质区别，其实并不仅仅局限上面的那些，那么它们的本质区别是什么呢？下次再跟大家分享。

2016.10.31于浙江杭州