軟體設計意味著去構思、創造或發明一套方案，把乙份計算機軟體的規格說明書轉變為可實際執行的軟體。設計就是把需求分析和編碼除錯連在一起的活動。
設計是乙個險惡的問題：只有通過解決或部分解決才能被明確的問題。
設計是個了無章法的過程（即使他能得出清爽的成果）。
設計就是確定取捨和調整順序的過程。
設計受到諸多限制。
設計是不確定的。
實際是乙個啟發式過程。
設計是自然而然形成的。
好的設計源於對一小批關鍵設計概念的理解。
偶然的難題和本質的難題：偶然是碰巧的，大部分偶然性難題在很久之前已經得到了解決。在軟體開發剩下的那些本質性困難上的進展相對緩慢，本質性困難來自很多方面：必須去面對複雜、無序的現實世界；精確而完整地識別出各種依賴關係與例外情況；設計出完全正確而不是大致正確的解決方案；諸如此類。
管理複雜度的重要性：
當專案由技術原因導致失敗的時候，其原因通常就是失控的複雜度。有關軟體變得極端複雜，讓人無法知道他究竟是做什麼的。
如何應對複雜度：
把任何人在同一時間需要處理的本質複雜度的2⃣️減到最少；
不要讓偶然性的複雜度沒有限制地快熟增長。
最小的複雜度、易於維護、鬆散耦合、可擴充套件性、可重用性、高扇入、低扇出、可移植性、精簡行、層次性、標準技術
第1層：軟體系統
第2層：分解為子系統和包
第3層：分解為包中的類
第4層：分解為類中的資料和子層序
第5層：子層序內部
由於軟體是非確定性的，因此，靈活熟練地運用一組有效的啟發式方法（試探法），便成了合理的軟體設計核心工作。
找出現實世界中的物件
使用物件進行設計的步驟是：
* 辨識物件及其屬性（方法和資料）。
* 確定可以對各個物件進行的操作。
* 確定各個物件能對其他物件進行的操作。
* 確定物件的哪些部分對其他物件可見——哪些部分是公用的，哪些部分是私有的。
* 定義每個物件的公開介面。
形成一致的抽象
抽象是一種能讓你在關注某一概念的同時可以放心地忽略其中一些細節的能力——在不同的層次處理不同的細節。
封裝實現細節
封裝填補了抽象留下的空白。
當繼承能簡化設計時就繼承
定義物件之間的相同點和不同點叫繼承。繼承的好處在於他能夠很好地輔佐抽象的概念。繼承能簡化程式設計的工作。繼承是物件導向程式設計中最強大的工具之一。
隱藏資訊
資訊隱藏是結構化程式設計與物件導向設計的基礎之一，資訊隱藏是減少重複工作的強大技術。
兩種秘密：
* 隱藏複雜度：這樣你就不用再去應付他，除非需要特別關注的時候。
* 隱藏變化源：這樣當變化發生時，其影響就能被限制在區域性範圍內。
資訊隱藏的障礙：資訊過度分散、迴圈依賴、把類內資料誤認為是全域性資料、可以覺察的效能損耗。
資訊隱藏的價值：修改容易、有啟發力、有助於設計類的公開介面。
找出容易改變的區域
1. 找出看起來容易變化的專案。
2. 把容易變化的專案分離出來。
3. 把看起來容易變化的專案隔離開來。
一些容易變化的區域：業務規則、對硬體的依賴性、輸入和輸出、非標準語言特性、困難的設計區域和構建區域、狀態變數。
保持鬆散耦合
偶和標準：規模、可見性、靈活性。
耦合種類：簡單資料引數耦合、簡單物件耦合、物件引數耦合、語義上的耦合。
查閱常見的設計模式
常見的設計模式包括介面卡、橋接、裝飾器、外觀、工廠方法、觀察者、單件、策略及模板方法。
使用設計模式的好處：
設計模式通過提供現成的抽象來減少複雜度；設計模式通過把常見解決方案的細節予以制度化來減少出錯；設計模式通過提供多種設計方案而帶來啟發性的價值；設計模式通過把設計對話提公升到乙個更高的層次上來簡化交流。
其他啟發式方法
高內聚性、構造分層結構、嚴格描述類契約、分配職責、為測試而設計、避免失誤、有意識地選擇繫結時間、建立**控制點、考慮使用蠻力突破、畫乙個圖、保持設計的模組化
關於設計啟發的總結
主要的啟發式方法：
尋找現實世界中的物件
形成一致的抽象
封裝實現細節
在可能的情況下繼承
資訊隱藏
找出容易改變的區域
保持鬆散的耦合
探尋通用的設計模式
下列啟發式方法又是也很有用：
高內聚性
構造分層結構
嚴格描述類契約
分類職責
為測試而設計
有意識地選擇繫結時間
建立**控制點
考慮使用蠻力
畫乙個圖
保持設計模組化
迭代、分而治之、自上而下和自下而上的設計方法、建立試驗性原型、合作設計、要做多少設計才夠、記錄你的設計成果
設計實踐
- [ ] 你已經做過多次迭代，並且從眾多嘗試結果中選擇了最佳的一種，而不是簡單選擇第一次嘗試的結果嗎？
- [ ] 你嘗試多種方案來分解系統，以確定最佳方案嗎？
- [ ] 你同時用自下而上和自上而下的方法來解決軟體設計問題嗎？
- [ ] 為了解決某些特定的問題，你對系統中的風險部分或者不熟悉的部分建立過原型、寫出數量最少的可拋棄式**嗎？
- [ ] 你的設計方案被別人檢查了嗎？
- [ ] 你一直在展開設計，直到實施細節躍然紙上了嗎？
- [ ] 你用某種適當的技術——比如說wiki、電子郵件、掛圖、數碼**、uml、crc卡或者在**寫注釋——來保留設計成果嗎？
設計目標
- [ ] 你的設計是否充分地處理了由系統架構層定義出並且推遲確定的事項？
- [ ] 你的設計被劃分為層次嗎？
- [ ] 你對吧這一程式分解為子層序、包和類的方式感到滿意嗎？
- [ ] 你把對這個類分解成子層序的方法感到滿意嗎？
- [ ] 類與類之間的互動關係是否已設計為最小化了？
- [ ] 類和子程式是否被設計為能夠在其他系統中重用？
- [ ] 程式是不是易於維護？
- [ ] 實際是否精簡？設計出來的每一部分都絕對必要嗎？
- [ ] 設計中是否採用了標準的技術？是否避免使用怪異且難以理解的元素？
- [ ] 整體而言，你的設計是否有助於最小化偶然性的和本質性的複雜度嗎？
第五章 軟體構建中的設計
5.1設計中的挑戰 設計就是把需求分析和編碼除錯連在一起的活動。險惡的問題就是那種只有通過解決或部分解決才能被明確的問題。設計是個了無章法的過程。設計就是確定取捨和調整順序的過程。設計受到諸多限制。設計是不確定的。設計是乙個啟發式過程。設計是自然而然形成的。5.2關鍵的設計概念 好的設計源於對一小批...
第五章 軟體構建中的設計
5.1 5.2 設計相關概念 一 理想設計的特徵 設計範疇內的特徵有 1 最小複雜度 設計應該簡單且易於理解。2 易於維護 3 鬆散耦合 合理抽象 封裝 資訊隱藏，設計出相互關聯盡可能少得類。4 可擴充套件性 5 可重用性 6 高扇入 讓大量的類使用某個給定的類 如工具類 7 低扇入 乙個類裡適量使...
構建之法第五章
構建之法第五章 本章為團隊和流程，主要介紹了典型的軟體團隊模式和開發流程以及它們的優缺點 tsp mvp mbp rup團隊 並不是幾個人湊到一起就叫團隊，稱之為團隊 1 應該有一致的集體目標，團隊要一起完成這目標 2 團隊成員有各自的分工，互相依賴合作，共同完成任務 軟體團隊的模式 1 主治醫師模...