《代码大全》阅读笔记-5-软件构建中的设计
生活随笔
收集整理的這篇文章主要介紹了
《代码大全》阅读笔记-5-软件构建中的设计
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
無論是以何種方式來進行設計,小型項目也能和大型項目一樣從精心的設計之中獲益,而如果能認識到設計是一項明確的活動,你就更會獲益匪淺。
設計過程充滿了不確定性,因此設計技術也趨于探索性質、
軟件的首要技術使命:管理復雜度
設計特征:
- 最小復雜度
- 易于維護
- 松散耦合
- 可擴展性
- 可重用性
- 高扇入:大量的類使用某個給定的類
- 低扇出:一個類里少量/適量地使用其他的類
- 可移植性
- 精簡性
- 層次性
- 標準技術:盡量少依賴外來的,盡量使用標準的、常用的
系統層設計圖應該是無環圖
抽象是一種能讓你在關注某一概念的同事可以放心地忽略其中一些細節的能力——在不同的層次處理不同的細節。抽象的主要好處就在于它使得你能忽略無關的細節,抽象是我們用來得以處理顯示世界中 復雜度的原著中重要手段
在設計一個類的時候,一項關鍵性的決策就是確定類的哪些特性應該對外可見,而哪些特性應該隱藏起來
信息隱藏中所說的秘密主要分為兩大類:
- 隱藏復雜度,
- 隱藏變化源
把容易變化的地方隔離開來
- 業務規則
- 對硬件的依賴性
- 輸入和輸出
- 非標準的語言特性
- 困難的設計區域和構建區域
- 狀態變量
常用的設計模式
- 抽象工廠(Absctruct Factory):通過制定對象組的種類而非對單個對象的類型來支持創建一組相關的對象
- 適配器(Adapter):把一個類的接口轉變成另一個接口
- 橋接(Bridge):把接口和實現分離開來,使他們可以獨立變化
- 組合(Composite):創建一個包含其他同類對象的對象,使得客戶端代碼可以與最上層對象交互而無需考慮所有的細節對象
- 裝飾器(Deractor):給一個對象動態的添加職責,而無需為了每一種可能的職責配置情況去創建特定的子類(派生類)
- 外觀(Facade):為沒有提供一直接口的代碼提供一個一致的接口
- 工廠方法(Factory Method):做特定基類的派生類的實例化時,除了在Factory Method內部之外均無需了解各派生對象的具體類型
- 觀察者(Observer):使一組相關對象相互同步,方法是讓另一個對象負責:在這組對象中的任何一個發生改變時,由它把這種變化通知給這個組里的所有對象
- 單例模式(Singleton):為有且僅有一個實例的類提供一種全局訪問的可能
- 策略(Strategy):定義一組算法或者行為,使得他們可以動態地相互替換
- 迭代方法(Iterator):提供一個服務對象來順序的訪問一組元素中的各個元素
- 模板方法(Template Method):定義一個操作的算法結構,但是把部分實現的細節留給子類(派生類)
設計模式的益處
- 設計模式通過提供縣城的抽象來減少復雜度
- 設計模式通過把常見解決方案的細節予以制度化來減少出錯
- 設計模式通過提供多種設計方案而帶來啟發性價值
- 設計模式通過把設計對話提升到一個更高的層次上來簡化交流
設計模式的陷阱
- 強迫讓代碼適用于某個模式
- 為了模式而模式
設計中啟發式方法的總結:
- 尋找顯示世界的對象
- 形成一致的抽象
- 封裝實現細節
- 在可能的情況下繼承
- 信息隱藏
- 找出容易改變的區域
- 找出容易改變的區域
- 保持松散的耦合
探尋通用的設計模式
- 高內聚性
- 構造分層結構
- 嚴格描述這類契約
- 分配職責
- 為測試而設計
- 避免失誤
- 有意識地選擇綁定時間
- 創建中央控制點
- 考慮蠻力
- 畫一個圖
- 保持設計模塊化
解決問題的方法
4.回顧
實際上,如果你嘗試了一些設計方案,但沒有很好的解決問題的時候,更自然的方式是讓那些問題留在未解決的狀態,等到你擁有更多信息之后再去做
迭代、分而治之、自上而下(分解)、自下而上(合成)
記錄你的設計成果
- 把設計文檔插入到代碼
- 用wiki來記錄設計討論和決策
- 寫總結郵件
- 使用數碼相機
- 保留設計掛圖
- 使用CRC卡片
- 在適當的細節層創建UML圖
核對表:軟件構造中的設計
設計實踐
- 你已經做過多少次迭代,并且從眾多嘗試結果中選擇最佳的一種,而不是簡單選擇第一次嘗試的結果嗎
- 你嘗試用多種方案來分解系統,以確定最佳方案嗎?
- 你同事用自上而下和自下而上的方法來解決涉及問題嗎?
- 為了解決某些特定的問題,你對系統中的風險部分或者不熟悉的部分創建過原型、寫出數量最少的可拋棄的代碼嗎?
- 你的設計方案被其他人檢查了嗎(無論正確與否)?
- 你一直在展開設計,直到實施細節躍然紙上了嗎?
- 你用某種適當的技術——比如說wiki、電子郵件、掛圖、數碼照片、UML、CRC卡片或者在代碼里寫注釋——來保留設計成果嗎?
設計目標
- 你的設計是否充分地處理了由系統架構層定義出并且推遲確定的事項?
- 你的設計被劃分為層次嗎?
- 你對把這一程序分解成為子程序、包、類的方式感到滿意嗎?
- 類與類之間的交互關系是否已經設計為最小化了?
- 類和子程序是否被設計為能夠在其他的系統中重用?
- 程序是不是易于維護
- 設計是否精簡?設計出來的每一部分都是絕對必要的嗎?
- 設計中是否采用了標準的技術?是否避免了使用怪異且難以理解的元素?
- 整體而言,你的設計是否有助于最小化偶然性的和本質性的復雜度嗎?
要點
- 軟件的首要技術使命就是管理復雜度。以簡單作為努力目標的設計方案對此最有幫助
- 簡單性可以通過兩種方式獲取:一是減少在同一時間所關注的本質性復雜度的量;而是避免生成不必要的偶然的復雜度
- 設計是一種啟發式的過程。固執于某一種單一方法會損害創新能力,從而損害你的程序
- 好的設計都是迭代的。你嘗試設計的可能性越多,你的最終分設計方案就會變得越好、
- 信息隱藏是個非常有價值的概念。通過詢問“我應該隱藏什么?”能夠解決很多困難的設計問題
總結
以上是生活随笔為你收集整理的《代码大全》阅读笔记-5-软件构建中的设计的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 漫谈 | “黎曼猜想”和区块链加密算法到
- 下一篇: QQ音乐:React v16 新特性实践