小序
……走四方，路迢迢、水长长，迷迷茫茫一村又一庄……
多么熟悉的歌啊！歌声中，想像着自己有一天也能背着行囊、迎着远方又大又红的苹果，sorry，是夕阳，在晚霞的光辉中走向远方，追寻自己的梦想——真美。
相信大家都知道这首歌的名字——《走四方》，演唱者是我最喜欢的歌手韩磊，我也非常喜欢他唱的《天蓝蓝，海蓝蓝》、《向天再借500年》，总之很喜欢他的歌，有男人味！可惜的是市面上没有他的CD，最近好像他也不唱歌了。前两天才听说，他不唱歌的原因是转行搞IT了！！
前两天我不是失恋了吗，唉~~~发现自己对女孩的了解远不如对计算机的了解，于是打算买几本书提高一下自己的恋爱专知识业水平。进了书店，按说应该去社科类找书啊，结果腿肚子不听大脑指挥，又把身子绑架到IT书架前面去了——无奈应。你不得不佩服人家Apress公司的书封美工——人家设计出来的书皮不用你去仔细找，就会往你眼里跳——黑底、黄条，这本来就是自然界的“警告色”搭配，想想马蜂的屁股你就知道了。我发展在新书展架上有一本名为《Beginning C# Objects——概念到代码》的书，心中先是一惊，然后就是按捺不住的喜悦。你想啊！Object是什么？对象耶！C#那是我的本行，还是Beginning，也就是说这本书的书名译过来就是“学C#的人怎样从零开始搞对象”，而且，还是从概念到实现手把手地教你！哇噻噻……冲过去拿起来一看，译者中竟然有韩磊的大名！天空中仿佛出现了我崇拜的神的光辉……（音响！灯光！开始！）真想立刻就开始通读啊，于是抱起一本就往家冲。刚到门口，就听到一阵警报，门卫小姑娘笑嘻嘻地对我说：仙僧，收款台在那边~~
正文
扯淡完毕，步入正题。前段时间我写了一个《深入浅出话XX》系列文章，主要讲解的是一些C#语言本身的知识。系列还没有完，有机会我继续写。现在开始写的这个《用C#搞对象》系列，主要内容是讲解如何使用C#语言、UML语言进行面向对象（ Object Oriented，OO）的需求分析、建模、开发。对于这个话题，我自己的水平不够高，于是选了一本书为学习纲要，就是上面提到的《Beginning C# Objects——概念到代码》一书。其实，选哪本书并不重要，重要的是你花了多大心思去学习、去挖掘。这本书读起来挺舒服的，不简单，也不难，正好是一个从单纯的C#语言到高深的Design Pattern的台阶。强烈建议在校的大学生朋友能读一读这本书，一定会很有收获。
       面向对象概念绝对已经不是什么新技术了。现在是个初学编程的人就知道这个词，所以我们假设知道“面向对象”这个词的人数为100%。然后当你让所有人解释“什么是面向对象”的时候，会有一些人答不上来或者答不正确，我们暂且按80%的人能答对来算（其实有50%就不错）。接着，我们再让这些答对的人用某种他/她熟悉的语言来实现一下面向对象的三个基本特点（自定义类、继承、多态），至少会有50%的人当下傻眼。到此为止，出错的大多都是学生或者没有工作经验的人。后面的就是专业人士之间的PK了。
你让一个专业人士用他的技术去写封装、继承和多态，他会认为你是在侮辱他的智商，所以面试的时候一般对于有经验的面试者我会选择一个实际场景，让面试者用自己的眼光抽象出一些类、然后再确定类与类之间的关系及它们之间的消息流等——这个时候，学习过UML及Design Pattern的正规军和业余选手立刻就分出来了——学习过UML/DP的人，程序的架构会很清晰、很稳定（至少与给他的10分钟时间是相称的），而业余选手完全可能给你写出一个超大型的、几乎无所不包的类，或者类与类的功能重复……能通过这一关的，我们也算50%。最后一个问题：你以前做过的项目中，使用的是哪些DP？结果是令人沮丧的——有些理论很好的兄弟在工程实践中是根本不使用UML/DP的，他们给我的理由主要是这几个： 1 ，用着麻烦，感觉一个小软件不值当的那么兴师动众； 2 ，老板不让，说那样会耽误工期； 3 ，怕自己 UML/DP 水平不过关，不敢乱用所以选择了最保险（也是最危险）的办法——不用。卡在最后一步上的人我们也按50%算。OK，现在让我们计算一下中国合格软件工程师的百分比： 100% X 80% X 50% X 50% X 50% = 10%，也就是说， 乐观的估计，我们只有十分之一合格的软件工程师，或者说，我们约有 90%的软件人正在做着有潜在问题的工作（其中有一部分非OO编程的兄弟除外，比如C和汇编的，在此请诸位见谅）。而且，上面的计算只是“乐观的”估计，实际面试中情况要糟得多。以前我做过生意，感觉想从别人手里挣点钱可是真难，如今做HR了，手里拿着大把大把的Offer却没人能取到——想不到给人发钱也这么难！
问题出在哪儿了？
我认为问题出在中国软件的风气上——没有形成良好的、使用UML/DP来开发软件的风气。没有这个风气，师傅不用，徒弟自然也不用，师傅自立门户成为经理之后不用，下面的员工自然也不用（而且目前大多数软件企业的高层都是从非OO时代过来的，并没有对OO优势的深刻认识）。给大家举个际点的例子。
在中国，软件是卖不上价的。软件成本中最大的一块不是硬件投入，而是程序员的工资。一般一个中型软件（比如汽车、化工、医药类的行业软件）除去硬件、工位、水电什么的，毛利最多也就那么10万块钱。一个程序员，按北京来算一个月怎么着也得4000~5000吧，咱们按4000算。中型软件一般是5个左右的程序员干，一个月的工资就是2万，连需求分析、开发、测试、修改干上2个月，4万块钱还没见着就蒸发了。你不敢保证这个活干完立刻就有下一个活吧，咱们就算等半个月，又1万蒸发了。别忘了，客户这时候还没把钱给你呢！钱拿到手，纯利算出来，市场部的人手里的刀也已经麿的锃亮、等着分提成了:P
然后你再找老板说：咱们这个项目分析的时候使用UML/DP吧，以后再升级的时候会比较方便、别的项目代码和库的复用性也高……
老板：     “大概需要增加多长时间？”
你：        “一个月吧”
老板：     “拿我的菜刀来！！”
你：        “冤枉啊！！！……”
       唉，想想杨修是怎么死的——还不是一个劲在那儿“基类”、“基类”叫个不停、非逼着曹承相使OO，结果引火上身的。
       OO不让用，那让我们看看程序员兄弟们是怎样写这个程序的吧。一般情况下，这样的程序会是一个MIS系统，如果你使用了OO/DP，它有可能是一个3层或者N层架构的软件，现在不是没时间抽象OO吗？OK，那咱就按着功能来，一个Button对应一个function，这总可以了吧，我不写3层的，写2层的可以了吧：
Button1里需要连数据库，好，搞一个SQL连接出来，放在Button1的事件处理函数中……
Button2也要连数据库了，好，也搞一个同样的……
Button3也需要了，靠，有点乱了，好办！把这个连接挪到窗体级，成为窗体类的成员吗！OK，问题解决了！把Button1和Button2的事件处理函数改一改……
Button4用到一个数据集，吼吼，这回学聪明了，先在窗体级声明一个数据集……
Button5，哈哈，用到Button4时声明的那个数据数了，聪明！
Button6，喔~~好像也要用到那个数据集，但需要对数据集内部的结构调整一下……这可怎么办捏？要不声名一个新的数据集吧——可是名字就会搞乱。唉……算了，不用窗体级的数据集了，各回各的Button处理函数里呆着吧。把Button4和Button5的函数统统改了……
……
我们的很多程序就是这么开发出来的。
如果你问他们——你用OO了吗？他们也会理直气壮地告诉你：用了！你没见我们的窗体都是类、我们的事件处理函数都是成员方法、我们有很多“精巧”的成员变量吗？？！！
My god，这算什么OO？！这是语言本身要求的最起码的OO，如果连这个都没有，程序连启动都启动不了——不是你在用OO，而是程序自己在用OO。你的程序无非是一个披着OO外套的面向功能（过程）的程序罢了。你的“窗体类”实质是一个包袱皮，你的成员方法（事件处理函数们）无非是Mian方法调用的子函数，你“精巧”的成员变量仍然是全局变量的思想……
让我们OO+DP吧——如何学习OO
       其实，在软件工作中使用OO和DP远没有我们想象的那么难，OO分析（OOA）、OO设计（OOD）和OO测试（OOT）加起来的时间也绝对不会超过在一堆凌乱的Function（通常称为“意大利面条”的那种程序）中Debug的时间——更何况你的软件还有复用的余地，可以让你“一次编译，处处捞钱”，何乐而不为呢？不过，有两种情况除外：
1． 你写的软件很小，小到百余行代码就搞定的地步。日常工作中不就常写这种小软件吗？解决一个专一的小问题，能用就行了。本来吗，从德胜门到上地犯不着坐航班吗:P
2． 你打算跟客户做“一锤子买卖”。以后反正也不跟你玩儿了，不再更新和扩展了。这样的程序可以随便写，不过你公司的前途吗……自己看着办。
OO对于老板也是有好处滴，那并不是让你的产品越来越复杂，而是让你的产品越来越稳定、后续工期越来越短，你省下的银子也越多。
       OK，那么摆在我们面前的一个新问题是：作为一个新手，我应该怎样学习面向对象编程呢？我来试着回答一下这个问题，不见得完全正确（本人的水平本身就相当于茶壶里的一只青蛙）也不见得适合你（你和我是人类的两个不同实例，参数诸元都是有区别滴）。文章后面肯定有很多拍砖的，看完文章再看看砖头你就能有一个较完整的认识了。
       一个初学者从零开始到成为一个高级软件工程师，他的学习历程大概应该是这样的：
（1）       确定自己的开发领域：比如是Web开发，Windows开发，手机开发……
（2）       选择一门自己喜爱的、面向对象的开发语言：比如C++、C#、Java、VB.NET……
（3）       精通这门语言的语义：比如每个关键字是什么意思
（4）       精通这门语言的面向过程部分：分支、循环、跳转……这是书写OO类中成员方面的基本功
（5）       了解和使用这门语言的类库：C++的STL、MFC、VCL、ATL，C#/VB.NET的.NET Framework，Java的JDK。有时候，我们也把这些类库称为OO程序设计的API。这时候，你已经可以写出一点有商业价值的程序了，大胆地去使用这些现成的类库吧！
（6）       开始学习语言的OO部分：自己动手写自定义的类，照猫画虎吗！ 注意，这个时候你还是在学习语言，而不没有进入 OO 程序设计阶段——因为你手头根本没有真实需求，只是“为 OO 而 OO ”，现在的大学生多停留在这个阶段。
（7）       开始学习真正的OO：这个时候你已经把语言玩的透熟，可以用它来自由地表达自己的思想了。你应该学习的知识是UML和Design Pattern。学习完这些知识再用来指导实践，呵呵，你就真的是小鸡变凤凰了——薪水大概也能涨一大块。但是，从编程语言到“语言中立”的UML+DP，跨度太大了，毕竟这是一个思想上的转变而非技术上的转变——或者说，编程语言和UML+DP根本就是两个不同的东西，怎么把他们有机地结合起来，是个很头疼的问题。
（8）       书写自己的类库：这个时候，你已经能把类良好地封装在DLL中供软件工程复用了，你的薪水也基本上步入了与经验同步增长的阶段。
（9）       书写自己的Framework：相互独立、割裂的类库是没有生命力的，而当你把你的类库组织成有生命力的工作流、数据处理流程这样的Application Framework时，你基本上就可以拿它来作为产品的基座、只更改表示层（UI）来生产软件产品了——可以考虑开个自己的公司。我就见过几个兄弟靠一套Framework吃了2年。
（10）   架构师：你能写一个像.NET Framework这样的Application Framework吗？或者是MFC？JDK？喔……加油啊！
当然，由于个人的工作视野所限，在这个学习结构中，我没有提及那些UI方便的语言和设计方法，比如HTML、JavaScript、ActionScript……工作需要的时候，我们也必需去深入扎实地学习它们，不过我更喜欢在业余时间把这些知识当做小茶点来品尝。
       BTW，我把北京地区以上各阶段的平均薪水和学习时间列出来，供大家参考一下：
-----------------------------------------------------------------------------------------------
（1）to（4）         1到2年         薪水0k                  建议在大学时代完成
（5）to（6）         1到2年         薪水4~5k              建议在大学时代完成
（7）to（8）         2到3年         薪水6~8k              必需在工作实践中积累
（9）to（10）       2到5年         薪水>10k               靠经验也靠悟性
------------------------------------------------------------------------------------------------
       通过上表大家也能看出来，要成为一个优秀的软件工程师，少则五六年，多则十来年而且在（7）这个地方是一个收入的分水岭。
将OO进行到底
《大学生们站起来》
那就等着沦陷吧！
如果 OO 真伟大……
想起面试官的话，
眼泪哭的哗啦啦……
 
       呵呵，校园招聘马上又要开始了，想一想又要面对那一双双迷茫而无助的眼睛，唉……亲爱的大多数大学生朋友们——不是你不明白，是这世界变化快啊。今年的应届生，你们进大学的时候，AJAX还如同彗星暗行，等你们上到大二，她已经开始向人们展示美丽的慧发，等你们毕业，Atlas已经呱呱坠地……
       现在说这些没用。把握我们手里的今天。踏踏实实学习，从什么时候开始都不晚。
       学习是一种投资，花钱买书是小事，投入进去的时间是最重要的，如果你学错了知识或者选错了学习途径，一年下来，你发现原来比你差的同学都已经拿到了比你高的薪水，那么你就赔了！
       从今天开始，我就和大家一起以《Beginning C# Objects》这本书为纲，深入学习一下OO程序设计。一来，我可以学到很多东西、丰富自己的知识、扎实自己的技能，二来希望能给大家带去些学习方法，为中国的程序界做那么一丁丁点贡献、留下点东西。
为什么我选用了这本书为纲要呢？
1． 我个人很喜欢这本书，英文版的时候就看过
2． 我在用这本书培训我们公司的新员工，可以精读一下
3． 这本书里包含的内容很全面，不用我给大家发一大捆书
4． 名家（书封上有），名作（Java系列也是他们写的），名译（韩磊耶！还有戴飞先生）
5． 读这本书的好处多多、实惠多多——下面我列出来一些
定位
       我感觉这本书的定位非常好。为什么这么说呢？请看下图：
如果没有这本书，我们翻越上面提到的“分水岭”时，学习用书大概是这样的：
       
从这张图里，我们可以看出——如果我们想达到用C#来表现UML+DP的境界，那么就要在把C#语言本身精通的前提下再去学习“语言中立”的UML语言，然后再学Design Pattern。由于国内的UML和C# Design Pattern的书比较少，我们的组合手法也只能是这样了（ 希望高手们能提出更好的建议）。而即使是你已经把C#和UML都学会了，再打开C# Design Pattern这本书，你仍然会感觉头大，原因很简单：没有实践经验的积累和活生生的例子的指引。而在Beginning一书中，从始至终都用一个学生选课系统贯穿下来，一下子把C#语言、UML、设计模式统一了起来。
Beginning C# Objects将自己定位在C#为OO方面的专著，但不是C#语言教材、也不是UML教材、也不是Design Pattern教材。它是是一个承上启下者。它最大的作用是为你在“业余”与“专家”之间开通一个快速通道、像催化剂一样降低了这一学习的难度。
毕设
       这本书最大的一个特点就是拿实例说事儿。里面有一个贯穿始终的实例。很精巧，也非常实用，包括从需求分析、提取数据、抽象出对象来……。如果你正在写毕业设计，那么最好看一看，能给你很多思路，也为你的毕业论文增色不少、让你的毕业答辩更加专业。更重要的是，你如果在你的毕业设计中采用这种规范的设计方式，那么在你对付面试官的时候，你就可以像一个做过项目的人一样胸有成竹了——没有竹子，竹笋也是还可以的吧，总比一句也答不上来强。
面试
       校园招聘快开始了，这一周来，我在出笔试题，其中很多与OO相关的题就来源于这本书的习题——这本书每个章节都不长，从躺到床上到睡着，正好可以看一节，每节后面都有思考题，所以你一定做一个神奇的美梦。如果你能把这些题多多少少看一下，那么在面试的时候你会比较沾光——至少我看了些别的公司的笔试题，在这本书里也都有答案。
纯正
       这本书就是单把C#的面向对象部分拎出来讲，讲透了为止，所以说它是OO的专著。味道很纯正，单讲OO。我不知道会不会有哪位大学里的老师会看到偶滴Blog，如果你正好看到这篇文章，建议你考虑考虑能把这本书当做选修课的教材——让学生们能在必修课选逃、选修课必逃的年代里也能自学些企业里急需的技术。
       还有，这本书使用的是C#语言。我个人很喜欢C#语言，认为他的确比Java语言入门要容易得多，至少支撑它的.NET Framework类库要比JDK规整得多，开发工具（也就是集成环境）的获得、安装、配置和使用也比Java的来得方便得多（我知道，因为这句话后面肯定又得有人用砖拍我，说我中微软的毒太深，OKOK，您尽管拍，我挣我的薪水），这样，由语言因素造成的学习羁绊就降到了最低。
手把手
       我比较喜欢这本书的第三部分，从UML的框架到C#语言代码的实现。呵呵，让我想想我妹妹画动画了。先是用直线画出一个动物的姿态框架，框架画好之后就不能乱改了，然后用曲线把动物的“肉”画出来——如果不够胖，就把线再弯曲一点，如果太胖了，就把线拉直一点（想想我自己就比较可怜了，骨架长的也不错，可惜就是外面长的这身肉，该曲的不曲，该直的不直……麻烦）。根据需要分析设计出来的UML图是语言中立的，随便你用C++、C#、Java实现都可以。这本书里自然是手把手地教你如何用C#严丝合缝地把UML框架实现出来了。
结束
       没想到自己一口气写了这么多。这说明一个问题：我大概已经一瘸一拐地从阴影中走出来了。也许只有读书才能让我孤单而不孤独。
       最后，如果让我重新设计这本书的封皮的话，我宁可不把那些吹捧话放在书封上——什么“C#领域里的Java编程思想”，一看就起火，好像C#哪儿比Java差一样。还有那句“轻松打通C#学习的‘任’‘督’二脉”——悬了点儿吧，再说了，这“任督二脉”指的又是什么呢？不得而知。还有更可气的，把Amazon里读者的评价也印上了（有谁能保证那不是枪手写的！），还用好多大红字标出来……看了感觉有点肉麻。如果我可以选择把什么文字写在这里的话，我希望是书中P.259（原版P.332）的话：
---------------------------------------------------------------------------------
对象建模何谈容易
       为软件系统开发合适的抽象模型，可能是软件工程中最为困难的方面，这是因为：
       存在无穷多可能。抽象是观察者眼力的延展：独立工作的观察者，几乎总是会造出彼此不同的模型。哪个最棒？争论随之而来。
       对于将来的复杂状况，永远不会有“最好”的或“正确”的模型，对于要解决的问题只存在“较好”或“较差”的模型。同一情形可能有多种功效等同的建模方式……
       ……要测知模型是否已经全然捕捉到用户需求，这可没有现成的试剂。
----------------------------------------------------------------------------------
       这叫什么？这叫实话！
 
法律声明： 本文章受到知识产权法保护，任何单位或个人若需要转载此文，必需保证文章的完整性（未经作者许可的任何删节或改动将视为侵权行为）。若您需要转载，请务必注明文章出处为 CSDN 以保障网站的权益；请务必注明文章作者为 刘铁猛 （ [url]http://blog.csdn.net/FantasiaX[/url] ），并向 [email]liutm@beyondsoft.com[/email] 发送邮件，标明文章位置及用途。转载时请将此法律声明一并转载，谢谢！