用C#搞对象(一)——启程

  1. 云栖社区>
  2. 博客>
  3. 正文

用C#搞对象(一)——启程

余二五 2017-11-14 18:40:00 浏览531
展开阅读全文
小序
……走四方,路迢迢、水长长,迷迷茫茫一村又一庄……
多么熟悉的歌啊!歌声中,想像着自己有一天也能背着行囊、迎着远方又大又红的苹果,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程序设计阶段——因为你手头根本没有真实需求,只是“为OOOO”,现在的大学生多停留在这个阶段
(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)的话:
---------------------------------------------------------------------------------
对象建模何谈容易
       为软件系统开发合适的抽象模型,可能是软件工程中最为困难的方面,这是因为:
       存在无穷多可能。抽象是观察者眼力的延展:独立工作的观察者,几乎总是会造出彼此不同的模型。哪个最棒?争论随之而来。
       对于将来的复杂状况,永远不会有“最好”的或“正确”的模型,对于要解决的问题只存在“较好”或“较差”的模型。同一情形可能有多种功效等同的建模方式……
       ……要测知模型是否已经全然捕捉到用户需求,这可没有现成的试剂。




本文转自 水之真谛 51CTO博客,原文链接:http://blog.51cto.com/liutiemeng/18750,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
余二五
+ 关注