5.1-5.2--設計相關概念
一、理想設計的特徵
設計範疇內的特徵有：
（1）最小複雜度：設計應該簡單且易於理解。
（2）易於維護
（3）鬆散耦合：合理抽象、封裝、資訊隱藏，設計出相互關聯盡可能少得類。
（4）可擴充套件性
（5）可重用性
（6）高扇入：讓大量的類使用某個給定的類（如工具類）。
（7）低扇入：乙個類裡適量使用其他類。
（8）可移植性
（9）精簡性
（10）層次性
（11）標準技術：盡量用標準化、常用的方法。
二、設計的層次
第一層：軟體系統。
第二層：分解為子系統或包。如使用者介面、資料庫、業務規則、對系統的依賴因素、企業級的工具等。同時， 不同的子系統之間應該制定相應的規則進行限制，使得子系統之間的互動變得簡單。
第三層：分解為類。
第四層：分解成子程式。
第五層：子程式內部的設計。
5.3--設計構造塊：啟發式方法
一、找出現實世界的物件
使用物件進行設計的步驟：
（1）找出物件，確定其屬性及方法
（2）確定每個物件可以對其他物件進行的操作：最常見的關係為包含關係和繼承關係。
（3）確定哪些部分對其他物件可見。對資料和方法都要明確是public，private還是protected。
public:可以被任意實體訪問
protected:只允許子類及本類的成員函式訪問
private:只允許本類的成員函式訪問
（4）定義每個物件的介面。
實踐心得：
在定義類的時候，要確定哪些資料是物件的屬性，哪些方法是與物件操作相關的，哪些方法是為了實現物件的某個操作而存在的工具方法。盡量避免將用到的資料或者方法一股腦兒全定義在類的.h檔案裡，否則類的功能會變得很不清晰。
二、形成一致的抽象
用一種簡化的觀點來考慮複雜的概念。
三、封裝實現細節
封裝：不只是讓你能用簡化的檢視來看複雜的概念，同時還不能讓你看到複雜概念的任何細節。你能看到的就是你能全部得到的。
四、當繼承能簡化設計時就繼承
注意多型的使用。
多型：允許將子類型別的指標賦值給父類型別的指標。c++通過虛函式來實現多型。
五、資訊的隱藏
1. 隱藏起來的資訊可能是某個易變的區域、檔案格式、資料型別的實現方式，或者是需要隔離的區域（這個區域中發生的錯誤不會給程式其餘部分帶來太大的損失）。
類的職責就是把這些資訊隱藏起來並保護自己的隱私權！。
2. 要隱藏的資訊主要有兩大類：隱藏複雜度（如複雜的資料型別、檔案結構、演算法等）和隱藏變化源（將變化帶來的影響限制在區域性範圍）。
3.資訊隱藏的障礙：
一是資訊在系統中過度分散。
二是迴圈依賴。即a類中得程式呼叫了b類中的程式，而b類中的程式又呼叫了a類中的程式。
三是把類內資料誤認為全域性資料。
全域性資料會帶來兩類問題：（1）子程式對全域性資料進行操作時，不知道還有其他子程式對這些全域性變數進行了操作。（2）子程式知道其他子程式也在用全域性資料進行操作，但不明確都進行了哪些操作。
而類內資料只有類內部的少數幾個子程式才能直接訪問這些資料，所以很少出現全域性資料出現的兩個問 題。但是如果類內的子程式過於龐大，那也會出現類似問題。
四是試圖在系統架構層和編碼層均避免效能損耗。
這種擔心其實不必要。因為：（1）在系統架構層按照資訊隱藏的目標去設計並不會和按照效能目標去設計相衝突。（2）在編碼層，能為效能目標所做的最好準備，便是做出高度模組化的設計來。而不是擔心因為有了額外層次的物件例項化和子程式呼叫而帶來效能上得損耗。
4.資訊隱藏的價值:
(1) 按照資訊隱藏的原則來思考，可以激發和促進某些設計決策的形成。
（2）資訊隱藏有助於設計類的公開介面。介面設計的核心：這個類需要隱藏些什麼？
請養成問：「我該隱藏些什麼？」的習慣！！！
在實際使用，可以通過下面的一些方式來實現資訊的隱藏：
（1）將實現細節封裝成乙個函式：比如要獲取id號，可以用id = newid();如果以後需要改動生成id的方式，只要在newid函式中進行修改即可。
（2）將具名常量代替字面常量：如在程式的好多**中都用了「100」這個數，則可以把100寫入常量max_count中，這樣對這個值進行改動時，只需要修改一處即可。
（3）利用typedef來隱藏資料型別：
例如，如果類的乙個公開介面pt_fopen()返回了乙個指向檔案索引資訊的結構體fileindex(該結構體反映了檔案儲存格式)，這就暴露了你的檔案儲存格式。進行隱藏時，可以將這個結構體的定義放在類的私有成員中，然後定義typedef void* tphandle。在子程式中通過強制型別轉換的方式來傳遞想要傳遞的資料，而呼叫者只能看到tphandle為void * ，卻不知道其具體的結構。
再如，可以通過typedef int idtype；來隱藏id號的型別。以後如果要將id號修改為string型別，只要修改一處即可。
（4）確定類的公開介面：比如資源包打包工具的類，暴露給外面的介面就是執行打包packfile()，因此可將其訪問許可權設為pubic，而其具體實現細節則可以放在private中。
六、找出容易改變的區域
將不穩定的區域隔離開來，將其影響限制在乙個子程式、類或者包的內部。
容易改變的區域通常有：
（1）業務規則：如稅率結構改變，合同內容的改變等。
（2）對硬體的依賴性
（3）輸入和輸出
（4）非標準的語言特性
（5）困難的設計區域和構建區域
（6）狀態變數：
不要使用布林變數作為狀態變數，請換用列舉型別。
使用訪問器子程式取代對狀態變數的直接檢查。（避免硬編碼）
（7）資料量的限制：如定義100個元素的資料的時候，實際上就向外界透露了100這個上限的資訊。
七、保持鬆散耦合
耦合度表示模組之間的關係緊密程度。
耦合標準：
（1）規模：指模組間的連線數。通過乙個引數連線起來的兩個模組之間的耦合度要小於2個，3個引數的。
具有4個公用方法的類與它的呼叫者的偶爾度要低於有40個公用方法的。
（2）可見性：指兩個模組之間連線的顯著程度。程式開發應該通過把模組之間的連線關係變得廣為人知而獲取信任。因此，應該盡可能通過參數列來傳遞資料，而不要通過全域性資料這種「鬼鬼祟祟」的方法。
（3）靈活性：指模組間是否容易改動。理想狀態就像熱插拔usb聯結器。
耦合的常見種類：
（1）簡單資料引數耦合：通過引數傳遞資料。
（2）簡單物件耦合：乙個模組例項化乙個物件。
（3）物件引數耦合：相對簡單資料引數耦合來說，這種更為緊密。
（4）語義上的耦合：乙個模組不僅使用了另乙個模組的語法元素，還使用了有關那個模組內部工作細節的語義知識。
八、其他設計啟發方法
（1）查閱常用的設計模式
（2）高內聚性
（3）構造分層結構
（4）分配職責
（5）為測試而設計
（6）避免失誤
（7）有意識的選擇繫結時間
（8）建立**控制點
（9）考慮使用蠻力突破
（10）畫圖
（11）保持設計的模組化
（12）自上而下
（13）自下而上
第五章 軟體構建中的設計
5.1設計中的挑戰 設計就是把需求分析和編碼除錯連在一起的活動。險惡的問題就是那種只有通過解決或部分解決才能被明確的問題。設計是個了無章法的過程。設計就是確定取捨和調整順序的過程。設計受到諸多限制。設計是不確定的。設計是乙個啟發式過程。設計是自然而然形成的。5.2關鍵的設計概念 好的設計源於對一小批...
第五章 軟體構建中的設計
軟體設計意味著去構思 創造或發明一套方案，把乙份計算機軟體的規格說明書轉變為可實際執行的軟體。設計就是把需求分析和編碼除錯連在一起的活動。設計是乙個險惡的問題 只有通過解決或部分解決才能被明確的問題。設計是個了無章法的過程 即使他能得出清爽的成果 設計就是確定取捨和調整順序的過程。設計受到諸多限制。...
構建之法第五章
構建之法第五章 本章為團隊和流程，主要介紹了典型的軟體團隊模式和開發流程以及它們的優缺點 tsp mvp mbp rup團隊 並不是幾個人湊到一起就叫團隊，稱之為團隊 1 應該有一致的集體目標，團隊要一起完成這目標 2 團隊成員有各自的分工，互相依賴合作，共同完成任務 軟體團隊的模式 1 主治醫師模...