OO VS. PO

oo:Object Oriented.面向对象。
po:Process-Oriented面向过程。
对象这个词在我老家那常常用来指爱人，老婆老公，再加上面向这个动词，面向老婆开发？ :D
开发各种软件，都是要写N多指令序列，这些指令序列有源程序文件形式和编译后的文件形式，最后在操作系统的引导下进入执行状态。
一个软件的指令序列实在太庞大了，因为对于一套完整的业务需求，需要指示CPU做太多步骤的运行了。所以开发一套软件实在是需要一个普通的人类做太多表达，所以我估计领导们都比较适合干这个活，一般领导们讲话都是比较有条理的，都会分几大条，再分几小条。这个办法可以说蕴含着放之四海而皆准的“道”。于是很自然地将这些程序分成多个目录，多个文件，一个文件里表达几个相关的执行段，段之间可以互相调用。当然在3GL下，已经不叫段了，而是叫function。（叫函数，函数在我上学的时候是代数的概念呢）；而这个时候也没有人提出来说这是面向过程的概念，因为整个地是很自然的一个演进。随着人类在这个体系下开发的程序越来越多，越来越复杂，为了能让普通的人类大脑能表达清楚，引入了很多办法：头文件.h，可以把常用的function做重用；指针，把调用者角色的程序内容表达地更活泛；但是终于还是到了某几年，有一撮人被复杂性逼得睡不安稳，于是对先辈们开发程序的表达方式进行了一次反思，灵光一现，提出了新的表达方式。
各位同仁，那些老头子们开发程序时脑袋瓜子太直，就是把某一完整系统应有的一整套运行步骤（过程）分来分去，从顶向下啊，从下上顶啊，翻云覆雨地，说来说去，都是Process-Oriented，以运行步骤为导向的表达，那都是因为他们开发的年代还都是386呢，开发的都是简单的系统；现如今的ERP啊，RAD啊，那可内容太多了，咱们不能再那么直了，咱们绕个弯来说话吧。
你们看，我们现在也把相关的function放在一个文件组织了，但是你们有没有发现一个比较常见的现象，就是这几个相关的function往往会对同一些变量操作，而对于该文件之外的调用者而言，这个变量又完全应该是看不见的。像这种情况，我们是可以通过在main引导的时候建立全局变量或者在加载该文件所在动态库的时候动态创建出来，但是我们很自然地担心该变量会不会因此被不合适地调用，这好像是高耦合呢，还有，在编译器还要考虑和其他全局变量重名而出现编译器错误呢。啊！由此，我们发挥一下联想，我们能不能就此认为这几个function和这几个变量一起构成了一个独立的“运行单元”？就像是一个独立的显卡设备一样，有自己的内部显存，而对CPU上跑的指令序列而言只提供几个又合理又安全的调用接口指令？大胆地幻想一下，我们可不可以从静态看一个系统就是由N多个独立运行单元组成的呢？从运行看就是在引导程序里建立起一些运行单元并执行某一个接口功能，而接口功能里的执行步骤中又可以按逻辑需要加载动态创建一个一个新的运行单元，每一个运行单元都可能去调用另外一个运行单元公开的接口功能，由此协作呈现出一个系统来呢？哈！这种表达思路打了个弯，不是直脑瓜想分那些运行步骤了，而是还要想着该如何把那些相关地步骤封装成一个一个独立的功能单元。这样的好处就是把运行逻辑相对独立开来，能够降低耦合度啊！降低了耦合度，对咱们的堆积木开发总是正道啊！
同志们，我们这种新的开发思路就叫Object Oriented的吧！当然我们也承认，这是PO的一种演进，我们是在分出相关P来后又封成了O。随着这种思路用得更加成熟，我们不断吸取以前的经验，可以说取得了质的飞跃。我们有了方便的对应的4GL语言来OO开发，我们纳入了继承，多态的思想，从而能够更加有层次地发言；而且更加不同PO的，我们现在划分O时甚至直接借助现实世界的名词来开展，而不再是从计算机世界的P出发呢。为什么？因为P到底就是处理Data,而Data自然映射人类的认知体系里的名词，同一个data的多个p正是相关性所在呢。