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