面向?qū)ο蟮脑O(shè)計模型，數(shù)學模型，物理模型
***次看到OO（面向?qū)ο螅┻@個概念是在一本C++的書里面。里面舉了個動物的例子。講禽類，哺乳類，昆蟲等等動物的繼承關(guān)系，多態(tài)，等等概念。想起大學時候讀的C語言里面的一張程序邏輯圖。感覺這個OO實在是太神奇了。再后來接觸到.net 。開始基于.net平臺，用C#語言編寫程序。一開始感覺相當好，文件操作 。用一個System.File 搞定。要擴充功能的話。自己自定義一個類，把System.File的功能拿過來就是。很舒服哦。這種感覺持續(xù)了兩個月，等做到項目的中期，代碼越來越多。結(jié)構(gòu)越來月復(fù)雜。開始變的沮喪起來。原有功能保持不變，同時，要新增新的功能還要保持原有功能正常運轉(zhuǎn)。我的天啊。我開始做起意大利面了。用更復(fù)雜的方法解決越來越多的問題。我開始反思這個OO了。OO到底是個什么概念。從設(shè)計到現(xiàn)在的意大利面。OO到底干了什么，我又干了什么。
設(shè)計階段
用OO設(shè)計是一件很舒服的事，舉例：兩個人下棋
設(shè)計一個下棋的場景：拿生活中的例子看很容易看出至少三個對象，棋盤，下棋的人兩個人如果再抽象點,就兩個對象，下棋的人和棋盤。對這三個對象做一個分析，屬性字段，值，方法，接口等等，是不是可以動手寫代碼了。好舒服。
和結(jié)構(gòu)性設(shè)計比起來，簡直太舒服了。Class player ,Class player,Class Chessboard……里面要填什么功能的話，加方法，加接口，就算你的對象面向擴展，面向修改全開放。都沒關(guān)系。就算你不懂i/o,不懂cpu，沒關(guān)系，.net 有現(xiàn)成的類庫。拿來使就是了。好了，我們大功告成了。
偽代碼
- PublicClassPlayer: Status:name,IDFunction: Do()，Show(),UserInterface();
- PublicClass Chessboard :Status: Color , SchemaFunction : Run(); HandleError();
就這么簡單嗎？
如果我們就這么寫，就又會發(fā)現(xiàn)很多的問題，棋盤規(guī)則 需要建一個對象嗎？用戶接口 需要建一個對象嗎？還是當一個屬性，用戶是用抽象的類描述還是用實體類，棋盤呢？用form做用戶接口嗎？fom程序又怎么設(shè)計？等等。。。。。
等我們滿頭大汗的硬著頭皮寫完了。第二天，經(jīng)理發(fā)話了。我們需要在這個設(shè)計中加一張凳子。那還不簡單，再建一個凳子類，ClassStool.好。凳子給誰使用呢？放那呢？Stool怎么顯示呢？是不是又要把棋盤的顯示再抄過來，改幾行代碼。如果，顯示又要換成瀏覽器呢？是不是又要考慮改動其它的代碼？
等再過兩天.經(jīng)理又說了：我們要加個空調(diào)。而且要有一個用戶的接口，我們這個空調(diào)還要有收電費的功能。
我的天啊。直接崩潰了。當你看著自己寫的上萬行甚至幾萬行惡心的代碼。想死的心都有了。如果您耐心的讀到這，肯定有些朋友會說：唉。你去讀讀設(shè)計模式吧。你的設(shè)計有問題，那么請問：有沒有一種設(shè)計模式能在一開始就解決后面的擴展問題？就算你經(jīng)驗再豐富，設(shè)計水平再高。你就能保證你的模式能面對一個一個神奇的需求？只是加個接口加個屬性或是價格對象就能解決問題？
怎么辦？
這就是我的親身經(jīng)歷。我開始反問自己。到底什么是對象。對象就是你寫的那一長串不加注釋就很難讀懂的字符串？對象就是你腦子里面描述的一個抽象概念？對象是什么？到現(xiàn)在為止，我也沒有找到一個合適的概念去理解它。只能從幾個側(cè)面去想想。
從設(shè)計上來講：
對象設(shè)計的確很容易，我以前參與過一個網(wǎng)頁游戲的設(shè)計，代碼編寫。設(shè)計師給我的類圖就一張比我上面描述的圖詳細不了一點點的圖。代碼已經(jīng)寫了上萬行了，我的天。我足足用一個星期只能看懂一部分代碼，參與不到一個星期，游戲設(shè)計者和程序員已經(jīng)開始互相抱怨了。怎么老改啊？這么簡單的功能不能實現(xiàn)嗎？等等。一個小人兒，加個棋盤這就是對象設(shè)計嗎？
從我目前的經(jīng)驗來說，我認為在需求分析，功能分析等等的最初階段，就壓根兒不用考慮計算機的問題，這種工作***讓市場人員來做。用一個一個的對象把客戶的要求描述出來，比如說上面的棋盤和棋手，（在這我只是描述我的觀點與線程設(shè)計回溯設(shè)計無關(guān)），客戶想干嘛，想得到什么，客戶是什么類型，。。。這些信息組合起來。得到一張最原始的需求圖。同時對更改留下一部分的接口空間。這個圖與計算機無關(guān)。
從數(shù)學模型來講：
圖已經(jīng)設(shè)計好了，那拿到這個圖之后怎么辦呢？我們一分析，三層架構(gòu)？用戶接口就出來了？不。我認為這里有一個最核心的設(shè)計。數(shù)學模型。這個階段***也不要考慮計算機的問題。
為什么？因為從客戶需求，只是一種需求，對需求而言，計算機只是一種工具，計算機只能做一件事，就是計算。而且計算機本身其實就是數(shù)學家設(shè)計出來的。用馮諾依曼的思想來講。它只做一件事，就是連續(xù)的執(zhí)行程序。計算。就算我們的軟件再天花亂墜。計算機就只有一種功能，軟件也是同步計算實現(xiàn)各種需要的。所以，在這個階段。我們需要干一件事。講客戶需求的類圖，轉(zhuǎn)換為數(shù)學模型類型類圖。這些對象的關(guān)系是什么，對象有哪些,對象有什么方法。在這個階段。對象就是數(shù)學意義上的對象。
講這個需求用數(shù)學模型模擬出來。形成完成的數(shù)學結(jié)構(gòu)，類似于（多形數(shù)據(jù)類型《嚴蔚敏》）的理解。
比如
數(shù)據(jù)：DataD
數(shù)據(jù)間的關(guān)系：Relation R
數(shù)據(jù)方法：Function F
< D,R,F>
拿下棋的例子來說：我們需要用數(shù)學模型講。棋手，棋盤，棋子，下棋的動作，棋盤面，甚至顏色，這些數(shù)據(jù)元素用結(jié)構(gòu)嚴整的數(shù)學模型描述起來。建立一個健康的數(shù)學模型
從物理模型來講：
數(shù)學模型圖與物理模型設(shè)計應(yīng)該是同步完成的。就像編譯時的語法，詞法分析過程一樣。
（不知道有沒有這樣的程序，可以幫我們自己建立數(shù)學模型。：））
物理模型才是程序員最綜的工作。
拿到數(shù)學模型，
< D,R,F>
使用專業(yè)技能用計算機模擬操作。把操作步驟存儲在計算機內(nèi)。供客戶使用。.net平臺只是一個平臺，讓我們設(shè)計完成這些工作的一個穩(wěn)定良好的平臺。你用C 語言來面向?qū)ο笤O(shè)計，也是一樣。當然肯定不好用啦。它的設(shè)計是結(jié)構(gòu)性的。用來控制計算機的。畢竟我們手頭上的硬件設(shè)計還是面向結(jié)構(gòu)的。
另外我的感覺是：
面向?qū)ο蟮脑O(shè)計和代碼編寫，對程序員的要求更高了，它需要程序員掌握很多的設(shè)計，數(shù)學，硬件知識，我見很多人說，程序員離底層原來越遠了，我實不以為然，不管是現(xiàn)在的面向?qū)ο筮€是將來面向服務(wù)啊。或什么的。要求程序員對機器的掌控能力更強了。機器是死的，軟件是活的。拿現(xiàn)在的例子來說。對象這個數(shù)據(jù)類型設(shè)計容易，還是原來的只有int ,double.。。。設(shè)計容易？你可以很容易掌控int 在內(nèi)存幾個字節(jié)，在那.那，一個對象呢？用對象這個數(shù)據(jù)類型來處理對象容易，還是1+1 =2 容易？接觸底層的意思不是說。一天到晚的敲匯編。就是接觸底層了。如果，那一天，計算機硬件不用二進制了呢？程序不用鍵盤寫了呢？cpu不用電平或脈沖信號了呢？是不是我們所學的就沒有用了？計算機也只是工具而已。
【編輯推薦】
