結構設計，應該面向什麼？

結構設計應該面向什麼？在UML設計與模式開發一書講到，設計的主要思維是面向對象，以職責（responsibility）來驅動整個對象，進而來快速管理開發項目。最近一段時間我又設計開發一個新的項目，基于TCP/IP的C/S網絡應用程式，結果在設計開發中又是遇到一系列讓我頭痛的問題。核心的問題是：系統效率問題，資源浪費問題，錯誤處理等一些與類的設計無關的問題。從類的設計上看，問題都不是很明顯。從一開始設計到後來的測試以及修改，最開始的類都沒有什麼變化，而做了大的變動的是資料及消息的處理子產品。這讓我有點郁悶。應該說，在軟體的設計上，隻是面向對象還是不夠的。對于系統的架構，還應該考慮性能與效率問題。

例如，一個網絡連接配接設計成一個類，它自己負責接收與發送資料，并通知上層應用程式資料的接收成功及錯誤等一系列問題。這樣的設計理論上很不錯不是嗎？而且它還可以很快的擴充到其它應用程式中，形成一個底層的資料收發小子產品。這樣可以重複應該，而且做一些資料接口，在後續的應用層上，如果在擴充資料類型也可以很友善的使用。然而問題是，如果讓一個類來自己處理資料的接收與發送，必然會讓它有自己的處理單元，至少要一個線程。這樣一來，當連接配接使用者過多的時候，系統的線程就會負擔過重。進而使這樣的一種設計方法全部被否決。必須讓一個線程處理多個使用者的資料，并且要合理的分布資源，在某些使用者的網絡速度不佳的時候，能保證網絡速度快的使用者能以最合理的網速來處理資料。這樣一來，前面的設計，面向單個連接配接的思想就全部無效了。必須重新考慮，應該面向整個資料處理子產品了。

最近一直沒寫什麼東西，就是被這個小項目搞糊了！本來還想寫一篇關于用C＃寫網絡應用程式的文章以及利用IIS做類似FTP的小應用程式。結果在測試後，讓我很失望，自己的一些想法以及做法又是失敗的。這個項目已經重新寫了兩次了，而昨天又已經決定重新再寫一次！希望能越改越好。