從項目始末談面向對象——領域分析、需求分析、分析模型、設計、實現
經過了六年的工作經驗，有必要從實戰的角度來談面向對象設計。
因爲經驗派跟學院派的總結或多或少有些不同，也只有經歷過，才知道血汗之辛苦。
“沒經歷過炮火的摧殘，是不會知道戰略、戰術的實施智慧”。
以前從課本上、培訓教材上看到的，一實際實踐起來還是有很多的艱辛要體驗。
畢竟沒有實踐經驗的，多多少少有點紙上談兵的毛病，對實際情況做了很多理想化的假設。
一個實際的項目往往受到三角制約：時間、工作量、進度。
因此，很多設計實際上必須經歷權衡，而不是想當然的完美設計，
而且在實際上的設計由於系統本身的約束關係， 也必須在某些特性之間做權衡。
因此在設計過程中有時爲了防止過度設計，可能會遵從一些簡單的原則，這些原則可能要根據個人的品味去領悟了。
其實，我也領悟不是很深。
原則：
1）一致性：正交性（不要將獨立的東西耦合起來）、妥適性(不要引入無形的東西)、普遍性(不要限制固有的東西)。
2）簡單(KISS)：簡化你的設計，不過從實際的工作經驗來看要簡化你的設計其實是很難的，需要你多層次的思考，才能達到簡化。
也可以說簡單是經歷過後的境界，隨便的簡單，其實就是一種粗暴的行爲。
3）三思而後行：想清楚你要做什麼，避免返工，勞心勞力。
4）儘快建立原型：可以工作的程序，勝過完備的文檔。
以下附上UNIX的設計哲學，覺得UNIX設計哲學從實踐的角度來看，更有指導意義。
上面的一致性和簡單性有時是有矛盾的，需要犧牲一方成就另一方。
這裏引“簡單之美——系統設計黃金法則”，對比學院派和實踐派方法的不同。
1）MIT Approach
簡單性：設計必須簡單，這既是對實現的要求，也是對接口的要求。接口的簡單要比實現的簡單更加重要。
正確性：設計在任何值得注意的方面都要保證正確。不正確是絕對不允許的。
一致性：設計必須保持一致兼容。設計可以允許輕微少量的不簡單和不完整，來避免不一致。一致性和正確性同等重要。
完整性：設計必須覆蓋到實際應用的各種重要場景。所有可預料到的情況都必須覆蓋到。簡單性不能過度的損害完整性。
2）New Jersey Approach
簡單性：設計必須簡單，這既是對實現的要求，也是對接口的要求。實現的簡單要比接口的簡單更加重要。簡單是設計中需要第一重視的因素。
正確性：設計在任何值得注意的方面都要求正確。爲了簡單性，正確性可以做輕微的讓步。
一致性：設計不能過度不兼容一致。爲了簡單，一致性可以在某些方面做些犧牲，但與其允許設計中的這些處理不常見情況的部分去增加實現的複雜性和不一 致性，不如丟掉它們。
完整性：設計必須覆蓋到實際應用的各種重要場景。所有可預料到的情況都應該覆蓋到。爲了保證其它幾種特徵的品質，完整性可以作出犧牲。事實上，一旦 簡單性受到危害，完整性必須做出犧牲。一致性可以爲實現的完整性作出犧牲；最不重要的是接口上的一致性。
如果覺得這種哲學描述太抽象的話，原文中有一個關於 Unix 中斷處理的例子，非常生動。一位 MIT 的教授一直困惱於 Syscall 處理時間過長出現中斷時如 何保護用戶進程某些狀態，從而讓用戶進程能繼續執行。他問新澤西人，Unix 是怎麼處理這個問題。新澤西人說，Unix 只支持大多數 Syscall 處理時間較短 的情況，如果時間太長出現中斷 Syscall 不能完成，那就會返回一個錯誤碼，讓用戶重新調用 Syscall。但 MIT 人不喜歡這個解決方案，因爲這不是“正確的 做法”。
Unix/C開發於 1970 年前後，那時離 1964 年剛推出的 IBM System/360 沒幾年，軟件剛擺脫硬件束縛，能移植到不同的機器上，從而變成了一種可單獨 出售的產品。就是這樣的一個軟件產業的萌芽期，這種“實現簡單”的理念被證明是更有效的。那麼在今天的互聯網時代，這種理念還有效嗎？我們再來看下一 篇文章。
有興趣的同學可以看：http://kb.cnblogs.com/page/143113/
廢話了這麼多，後繼將介紹實際的工作體會，分享當時的設計體會。
不過，有些由於涉及到公司的信息安全問題，舉的例子可能是LINUX裏面的例子。
