用C#搞對象（一）——啓程

小序

……走四方，路迢迢、水長長，迷迷茫茫一村又一莊……

多麼熟悉的歌啊！歌聲中，想像着本身有一天也能揹着行囊、迎着遠方又大又紅的蘋果，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] 發送郵件，標明文章位置及用途。轉載時請將此法律聲明一併轉載，謝謝！