架构师之路---面向过程和面向对象.docx

架构师之路(1)-面向过程和面向对象王泽宾收藏亨1、引言机算机科学是一门应用科学，它的知识体系是典型的倒三角结构，所用的根底知识并不多，只是随着应用领域和方向的不同，产生了很多的分支，所以说编程并不是一件很困难的事情，一个高中生经过特定的训练就可以做得到。但是，会编程和编好程绝对是两码事，同样的程序员，有的人几年之后成为了架构师，有的人却还在不停地Coding,只不过Ctric、Ctrl，用得更加纯熟了。在中国，编程人员最终的归途无外乎两条：一是转向技术管理，它的终点是CT0；二是继续深入，它的终点是首席架构师，成为CEO的人毕竟是少数。如果你现在还是个普通的程序员，希望继续在技术这条路上前进的话，我想你还是应该先补充一点软件工程的思想，学习一点有关设计模式的知识，只有具备这些能力，你才能从整体和宏观层面来考虑问题、分析问题和解决问题。本人Coding了很多年，中间走了不少弯路，虽然最终没什么大成就，但总算有一些心得，很愿意把自己的一些经验拿出来跟大家分享，这或许对你的开展有所帮助。由程序员转为架构师，最绕不开的概念就算是面向对象(C)O)了。记得在大学的时候，我们专业开了一门课叫面向对象的编程。那个时候，我们刚刚学了一门C语言，开发环境用的还是DoS下的TurboC,半点工程开发的经验都没有，纯粹的空对空。所以，一学期下来，我始终处于一种懵懂状态，既没领会面向过程和面向对象到底有什么区别，也没搞懂面向对象能带来什么好处。2、面向过程(OP)和面向对象(Oo)2.1 蛋炒饭和盖浇饭有人这么形容OP和00的不同：用面向过程的方法写出来的程序是一份蛋炒饭，而用面向对象写出来的程序是一份盖浇饭。所谓盖浇饭，北京叫盖饭，东北叫攵会饭，广东叫碟头饭，就是在一碗白米饭上面浇上一份盖菜，你喜欢什么菜，你就浇上什么菜。我觉得这个比喻还是比拟贴切的。蛋炒饭制作的细节，我不太清楚，因为我没当过厨师，也不会做饭，但最后的一道工序肯定是把米饭和鸡蛋混在一起炒匀。盖浇饭呢，那么是把米饭和盖菜分别做好，你如果要一份红烧肉盖饭呢，就给你浇一份红烧肉；如果要一份青椒土豆盖浇饭，就给浇一份青椒土豆丝。蛋炒饭的好处就是入味均匀，吃起来香。如果恰巧你不爱吃鸡蛋，只爱吃青菜的话，那么唯一的方法就是全部倒掉，重新做一份青菜炒饭了。盖浇饭就没这么多麻烦，你只需要把上面的盖菜拨掉，更换一份盖菜就可以了。盖浇饭的缺点是入味不均，可能没有蛋炒饭那么香。到底是蛋炒饭好还是盖浇饭好呢？其实这类问题都很难答免，非要比个上下上下的话，就必须设定一个场景，否那么只能说是各有所长。如果大家都不是美食家，没那么多讲究，那么从饭馆角度来讲的话，做盖浇饭显然比蛋炒饭更有优势，他可以组合出来任意多的组合，而且不会浪费。2.2 软件工程盖浇饭的好处就是''菜K饭别离，从而提高了制作盖浇饭的灵活性。饭不满意就换饭，菜不满意换菜。用软件工程的专业术语就是''可维护性比拟好，''饭和''菜的耦合度比拟低。蛋炒饭将''蛋K饭搅和在一起，想换'蛋八'饭中任何一种都很困难，耦合度很高，以至于''可维护性比拟差。软件工程追求的目标之一就是可维护性，可维护性主要表现在3个方面：可理解性、可测试性和可修改性。面向对象的好处之一就是显著的改善了软件系统的可维护性。面向过程(OP)和面向对象(Oo)是不是就是指编码的两种方式呢？不是！你拿到了一个用户需求，比方有人要找你编个软件，你是不是需要经过需求分析，然后进行总体/详细设计，最后编码，才能最终写出软件，交付给用户。这个过程是符合人类根本行为方式的：先想做什么，再想如何去做，最后才是做事情。有的同学说：'、我没按照你说的步骤做啊，我是直接编码的。其实，你一定会经历了这三个阶段，只不过你潜意识里没有分得那么清楚。对于拿到需求就编码的人，可能编着编着，又得倒回去重新琢磨，还是免不了这些过程，以00为例，对应于软件开发的过程，00衍生出3个概念：00A、OoD和OOP。采用面向对象进行分析的方式称为00A,采用面向对象进行设计的方式称为00D,采用面向对象进行编码的方式称为OOP。面向过程(OP)和面向对象(C)O)本质的区别在于分析方式的不同，最终导致了编码方式的不同。2.3 面向过程(OP)和面向对象(OO)2.4 面向过程编程(OPP)和面向对象编程(OOP)的关系关于面向过程的编程(C)PP)和面向对象的编程(OoP),给出这它们的定义的人很多，您可以从任何资料中找到很专业的解释，但以我的经验来看，讲的相对枯燥一点，不是很直观。除非您已经有了相当的积累，否那么说起来还是比拟费力。我是个老程序员出身，虽然现在的日常工作更多倾向了管理，但至今依然保持编码的习惯，这句话什么意思呢？我跟大家沟通应该没有问题。无论你是在重复我走过的路，或者已经走在了我的前面，大家都会有那么一段相同的经历，都会在思想层面上有一种理解和默契，所以我还是会尽量按照大多数人的常规思维写下去。面向过程的编程(OPP)产生在前，面向对象的编程(OOP)产生在后，所以面向对象的编程(OOP)一定会继承前者的一些优点，并摒弃前者存在的一些缺点，这是符合人类进步的自然规律。两者在各自的开展和演变过程中，一定会相互借鉴，相互融合，吸收对方的优点，从而出现某些方面的趋同性。但是，即使两者有更多的相似点，也不会改变它们本质上的不同，因为它们的出发点不同，完全是两种截然不同的思维方式。关于两者的关系，我的观点是这样的：面向对象编程(OoP)在局部上一定是面向过程(C)P)的，面向过程的编程(OPP)在整体上应该借鉴面向对象(OC)的思想。这一段说的确实很空洞，而且也一定会有引来争议，不过，我劝您还是在阅读了后面的内容之后，再来评判我观点的正确与否。象C+、C#、JaVa等都是面向对象的语言，c,php(暂且这么说，因为php4以后就支持00)都是面向过程的语言，那么是不是我用C+写的程序一定就是面向对象，用C写的程序一定就是面向过程呢？这种观点显然是没有真正吃透两者的区别。语言永远是一种工具，前辈们每创造出来的一种语言，都是你用来实现想法的利器。我觉得好多人用C#,JaVa写出来的代码，要是仔细看看，那实际就是用面向对象(Oo)的语言写的面向过程(OP)的程序,所以，即使给关羽一根木棍，给你一杆青龙偃月刀，他照样可以打得你满头是包。你就是扛着个偃月刀，也成不了关羽，因为你缺乏关羽最本质的东西一绝世武功。同样的道理，如果你没有领会00思想，怎么可能写得出真正的00程序呢？那是不是面向过程就不好，也没有存在的必要了？我从来没有这样说过。事实上，面向过程的编程(OPP)已经存在了几十年了，现在依然有很多人在使用。它的优点就是逻辑不复杂的情况下很容易理解,而且运行效率远高于面向对象(00)编写的程序。所以，系统级的应用或准实时系统中，依然采用面向过程的编程(OPP)。当然，很多编程高手以及大师级的人物，他们由于对于系统整体的掌控能力很强,也喜欢使用面向过程的编程(OPP),比方像ApachezQMaiIzPostFixzICE等等这些比拟经典的系统都是OPP的产物。象PhP这些脚本语言，主要用于Web开发，对于一些业务逻辑相对简单的系统，也常使用面向过程的编程(OPP),这也是PhP无法跨入到企业级应用开发的原因之一，不过php5目前已经能够很好的支持00了。2.5 详解面向过程的编程(OPP)在面向对象出现之前，我们采用的开发方法都是面向过程的编程(OPP)。面向过程的编程中最常用的一个分析方法是''功能分解。我们会把用户需求先分解成模块，然后把模块分解成大的功能，再把大的功能分解成小的功能，整个需求就是按照这样的方式，最终分解成一个一个的函数。这种解决问题的方式称为''自顶向下"，原那么是''先整体后局部"，''先大后小，也有人喜欢使用''自下向上的分析方式，先解决局部难点，逐步扩大开来，最后组合出来整个程序。其实，这两种方式殊路同归，最终都能解决问题，但一般情况下采用''自顶向下的方式还是较为常见，因为这种方式最容易看清问题的本质。我举个例子来说明面向过程的编程方式：用户需求：老板让我写个通用计算器。最终用户就是老板，我作为程序员，任务就是写一个计算器程序。0K,很简单，以下就是用C语言完成的计算器：假定程序的文件名为：main.Cointmain(intargc,char*argv)变量初始化intnNuml,nNum2;charcpr;intnResult;nNuml=Num2=0;cpr=0;nResult=0;输入数据printf("Pleaseinputthefirstnumber:rn");scanf("%d"Numl);printf("Pleaseinputtheoperator:rn");scanf("%s"z8cpr);printf("Pleaseinputthesecondnumber:rn");scanf("%d"Num2);计算结果if(cpr=,+')<nResult=nNuml+Num2;elseif(cpr=)<nResult=nNuml-Num2;elseprintf("Unknownoperator!");return-1;输出结果printf("Theresultis%d!"znResult);return0;抛开细节不讲，我想大多数人差不多都会这么实现吧，很清晰，很简单，充分表达了''简单就是美"的原那么，面向过程的编程就是这样有条理的按照顺序来逐步实现用户需求。但凡做过程序的人都知道，用户需求从来都不会是稳定的，最多只能够做到“相对稳定“。用户可能会随时提出加个功能，减个功能的要求，也可能会要求改动一下流程，程序员最烦的就是频繁地变动需求，尤其是程序已经写了大半了，但这种情况是永远无法防止的，也不能完全归罪到客户或者需求分析师。以我们上面的代码为例，用户可能会提出类似的要求：首先，你程序中实现了''加法和''减法，我还想让它也能计算''乘法、''除法。其次，你现在的人机界面太简单了，我还想要个WindoWS计算器的界面或者MaC计算器的界面。用户需求开始多了，我得琢磨琢磨该如何去写这段代码了。我今天加了''乘K除的运算，明天保不齐又得让我加个''平方、''立方的运算，这要是把所有的运算都穷尽了，怎么也得写个千八百行代码吧。还有，用户要求界面能够更换，还得写一大堆界面生成的代码，又得来个千八百行。以后，这么多代码堆在一起，怎么去维护，找个变量得半天，看懂了代码得半天，万一不小心改错了，还得调半天。另外，界面设计我也不擅长，得找个更专业的人来做，做完了之后再加进来吧。这个过程也就是''软件危机产生的过程。伴随着软件广泛地应用于各个领域，软件开发的规模变得越来越大，复杂度越来越高，而其用户的需求越来越不稳定。根据用户提出的两个需求，面向过程的编程该如何去应对呢？我想大家都很清楚怎么去改。Veryeasy,把''计算和''界面分开做成两个独立的函数，封装到不同的文件中。假定程序的文件名为：main.Co#include"interface.h"#include"calculate.h"intmain(intargczchar*argv)变量初始化intNumlznNum2;charcpr;intnResult;nNuml=Num2=O;cpr=0;nResult=0;输入数据if(getPaametes(&nNuml,&nNum2,&cOpr)=-1)return-1;计算结果if(CaICMaChine(nNu