所谓“面向过程”，就是指你的着眼点在实现的细节。过程是实际的动作，就如对机器人的指挥，逐条指令发出，向上方90度抬左手、然后逆时针旋转30度、张开手掌、握住某物……这样的一连串具体指令，就是面向过程的着眼点，再细微的细节都要你考虑到，是否完成任务，看你的指令是否精确和恰当，连可能会遇到什么情形应该有什么应对，都要考虑在内。这就是“过程”，而你的主要精力，就关注在这样的过程之中。此时，任务被一层一层分解，而你是逐步完成每一个分解的任务，倒转过来逼近目标，一切为了完成任务服务。这样，你的思维就集中在实物上，比如，要排序一个数组，你的注意力就集中在数组的元素是什么类型、规模、数组的边界、排序的算法等等方面，而通常你的编程经验，会告诉你数组的元素类型对算法和过程的实现是起决定性作用的，为此，你必须针对各种各样不同的元素类型做不同的排序算法过程。

这样思考模式，就很容易让你忽略了一点：排序的手法其实是大同小异的，有一个固定的套路，这个套路是抽象的，你可以不断地重复同样的套路，但极可能没想到要把它通用化，达到偷懒的目的。难道不是吗？人都是想偷懒的，冒泡排序算法再熟练，要你写针对不同的数据类型写十次同样的代码，你自己都会生厌——如果没有厌烦之心，说明你没有进取精神，对机械重复没有疲劳感觉。

这就是“面向对象”的思想发端。对于分配内存必须匹配释放，你可能已经厌倦透顶，本来指针应该在我明确不会再使用它的时候触发释放机制，但偏偏要我手动写那么些释放代码，难道没有更聪明一点的做法让它在适当的时候自己释放自己？指针在函数A创建并动态分配内存，然后传递到函数B、C、D……中使用，为了释放这块内存，显然不能在后面那些子函数中释放（除了多次书写同样的释放代码之外，更主要的考虑是不知道它在别的子函数中是否还有用），那么可靠的办法只能是确保这些函数最终都要归口回到函数A，在函数A的末端释放内存。这种面向过程的精细思考，就是把你的精力耗费在太多枝节地方了。解放自己的办法，是想办法让指针自己释放自己，就如在函数代码中的Auto变量一样，在代码执行超越花括号两端时不存在。对象就是基于这样的需求而产生。“对象”就如事物，有产生、使用、发展、消亡的演化阶段，在这个对象身上的皮、毛、血、肉，都在对象产生时创建，在它消亡时一并消失，只要这些东西都明确是属于这个对象的，那么就一切都是跟随着的，程序员很明确，只要我宣布释放这个对象，那么不管它身上带着什么、都处于什么状态，都必然一并释放掉，而释放的具体操作，是对象某个方法自动执行的，要做什么、怎么做，是它自己想办法（写这个方法的，就沿用面向过程的编程方法），我不需要关心。这样，我就成了领导者，而类代码是下属，我可以指挥手下办事，而不是事事亲力亲为，能够做的东西就多了。（这里所说的，只是面向过程和面向对象的诸多关系之一极少领域，具体就不详说了，自己可以慢慢体会）

管理者和行动者，思维方式是极不相同的。每当接到任务：行动者的头脑，是思考如何完成任务；管理者的头脑，是思考这个任务能够让谁来完成。而平时的训练，前者是刻意锻炼实际操作的能力，而后者是着眼培训和提炼组织结构的事情（这有如看见火警，马上投入扑火救灾跟打电话呼叫消防队的区别）。当然了，管理者对实务不可能一窍不通的，因此他必须有面向过程的基础，他知道手下是怎么办事的、需要什么资源、什么配合，给出指导和调配，但他又不需要十分精通，良好的结构和组织，尽管每个零件都有粗疏之处，但完成的效率不会比精英零件的乌合之众差，而如果他拥有许多精英手下（市面成熟的函数库），那就如虎添翼了。作为一个领导者，他的头脑不可能被技术束缚住，即使他无法编写高效的树搜索算法代码，但他不会笨到不知道使用数据库的高效搜索引擎替他完成任务；即使不知道递归搜索目录树的API函数，但他也不会就此无法获得目录树。而行动者，他就会产生好胜之心，硬要在技术上闯这样的关，彻底弄懂不可，殊不知就是这样的枝节不断把他引离目标，到最后连自己原先想干什么都忘记了，迷失在技术和知识的海洋之中。而面向对象，也同样有容易误入的误区，就是把架构设计得过于复杂，间接环节太多，构想过于庞大，希图包罗万有，反而臃肿不堪使用（MFC就是一个样板）。

一个凡事就想到如何动手去做的人，是不能当领导者的，这种思想和性格越顽固，就越难扭转思维成功换位。这就是我前面所说的那个过渡难点。

过犹不及，平衡艺术（此处是艺术，不是技术）是最重要的。过分偏重面向过程，不屑面向对象，或者反过来，过分偏重面向对象，不屑面向过程，都是不可取的。总之，凡事不要死板。但是，你要学会面向对象，确实必须要克服面向过程的思维陷阱。过了那道关，才可以返回来加深面向过程的认识，此时对两者都有益。过不了，就终身处于抗拒状态。

楼上的，

我真佩服你的耐心，码那么多的字。