設計模式基本思想

2019-11-17 04:38:17

字體：大中小

來源：轉載

供稿：網友

好的系統設計追求如下特性：

l 可擴展性（ Extensibility ）：新的功能或特性很輕易加入到系統中來； l 靈活性（ Flexibility ）：可以答應代碼修改平穩發生，對一處的修改不會波及到很多其他模塊； l 可插入性（ Pluggability ）：可以很輕易地將一個類或組件抽出去，同時將另一個有相同接口的類 / 接口加入進來。具有如上特性的系統才有真正的可維護性和可復用性。而可維護性和可復用性對一個持續接入新需求，現有功能逐步完善，新功能不斷豐富，版本不會終止的大型軟件產品來說至關重要。傳統的復用包括：代碼的 copy 復用，算法的復用，數據結構的復用。在面向對象領域，數據的抽象化、封裝、繼續和多態性是幾項最重要的語言特性，這些特性使得一個系統可以在更高的層次上提供可復用性。數據的抽象化和繼續關系使得概念和定義可以復用；多態性使得實現和應用可以復用；而抽象化和封裝可以保持和促進系統的可維護性。這樣，復用的焦點不再集中在函數和算法等具體實現細節上，而是集中在最重要的宏觀的業務邏輯的抽象層次上。復用焦點的倒轉不是因為實現細節的復用不再重要，而是因為這些細節上的復用往往已經做的很好（例如，很輕易找到并應用成熟的數據結構類庫等），而真正沖擊系統的是其要實現業務的千變萬化。本質上說，假如說一個軟件的需求是永不變更或發展的，該軟件也就不需要任何設計，怎么編碼實現都行，只要需求滿足，性能達標。但事實上，軟件的本性就是不斷增強，不斷拓展的，不斷變化的。我們可以控制指尖流淌出的每行代碼，但控制不了奉為上帝的用戶的需求。編碼結束，測試全部通過，用戶在試用過程中才發現原來的需求有問題，需要變更或提出新需求，怎么辦？向用戶抗議：需求總在變，沒法做！？平抑心中的抱怨，加班加點大量的修改代碼，瘋狂的測試，依然是時間緊迫，心中沒底？抑或了然于胸：這個變更或小需求合理，系統很方便納入；于是坦然地和用戶協商下一個交付時間點？要使系統最大程度的適應需求的變更或新增，就必須在其要實現的宏觀業務邏輯的抽象復用上下功夫。而設計模式就是綜合運用面向對象技術和特性來提高業務邏輯可復用性的常用方法和經驗的提取和匯總。把握 23 種設計模式的要害是理解它們的共通目的：使所設計的軟件系統在一般或特定（系統將來在特定點上擴展的可能性大）場景下，盡可能的對擴展開放，對修改關閉。即面對新需求或需求變更時，輕易開發獨立于既有代碼的新代碼接入到現有系統或對現有代碼做可控的少量修改，而不是在現有代碼基礎上做大量的增、刪、改。為了這一目的， 23 種設計模式貫穿了面向對象編程的基本原則： l 面向接口或抽象編程，而不是面向實現編程。
l 一個對象應當對其他對象有盡可能少的了解，即松耦合。 l 純粹的功能復用時，盡量不要使用繼續，而是使用組合。使已有的對象成為新對象的一部分；新的對象通過向這些對象的委派達到復用已有功能的目的。進入討論組討論。

上一篇：遇上用例驅動的團隊

下一篇：2007年值得去思考的N大軟件技術