程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> C# >> C#入門知識 >> 設計模式原則(單一、開放封閉、裡氏代換、依賴倒轉、迪米特法則五大原則)

設計模式原則(單一、開放封閉、裡氏代換、依賴倒轉、迪米特法則五大原則)

編輯:C#入門知識

單一職責原則,就一個類而言,應該僅有一個引起它變化的原因。

        如果一個類承擔的職責過多,就等於把這些職責耦合在一起,一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力,當變化發生時,設計會遭受到意想不到的破壞。事實上,我們完全可以找出來進行分類,分離。

        軟件設計真正要做的許多內容,就是發現職責並把那些職責相互分離。其實要去判斷是否應該分離出類來,也不難,那就是如果你能夠想到多余一個的動機去改變一個類,那麼這個類就具有都與一個的職責,就應該考慮類的職責分離。

開放-封閉原則,是說軟件實體(類、模塊、函數等等)應該可以擴展,但是不可修改。
      這兩個原則其實是有兩個特征,一個是說“對於擴展是開放的”,另一個是說“對於更改是封閉的”。

      無論模塊是多麼封閉,都會存在一些無法對之封閉的變化。既然不可能完全封閉,設計人員必須對於他設計的模塊應該對那種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類,然後構造抽象來隔離那些變化。

      面對需求,對程序的改動是通過增加新代碼進行的,而不是更改現有的代碼。這就是開放-封閉原則的精神所在。

      開放封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術所聲稱的巨大好處,也就是可維護、可擴展、可復用、靈活性好。開發人員應該對程序中呈現出頻繁變化的那些部分做出抽象,然後,對於應用程序中的每個部分都刻意地進行抽象同樣不是一個好主意。

 依賴倒轉原則,就是說抽象不應該依賴細節,細節應該依賴抽象。

      這話繞口,說白了,就是要針對接口編程,不要對試下編程。舉個例子,無論電腦的主板、CPU、內存、硬盤都是在針對接口設計的,如果針對實現來設計,內存就要對應到具體的某個品牌的主板,那就會出現換內存需要把主板也換了的尴尬。

      所以說,PC電腦硬件的發展,和面向對象思想發展是完全類似的。這也說明世間萬物都是遵循牟宗類似的規律,誰先把握了這些規律,誰就最早成為了強者。

      依賴倒轉原則其實可以說是面向對象設計的標志,用那種語言來編寫程序不重要,如果編寫時考慮的都是如何針對抽象編程而不是針對細節編程,即程序中所有的依賴關系都是終止於抽象類或者接口,那就是面向對象的設計,反之那就是過程化的設計了。

 裡氏代換原則,子類型必須能夠替換掉它們的父類型。

      只有當子類可以替換掉父類,軟件單位的功能不受到影響時,父類才能真正被復用,而子類也能夠在父類的基礎上增加新的行為。

      比方說,貓是繼承動物類的,以動物的身份擁有吃喝跑叫等行為,可當某一天,我們需要夠牛羊也擁有類似的行為,由於它們都是繼承動物,所以除了更改實例化的地方,程序其他處不需要更改。

        正是由於子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展,才使得開放--封閉的原則成為了可能。

迪米特法則,如果兩個類不必彼此直接通信,那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某個方法的話,可以通過第三者轉發這個調用。

    迪米特法則首先強調的前提是在類的結構設計上,每一個類都應當盡量降低成員的訪問權限,也就是說,一個類包裝好自己的private狀態,不需要讓別的類知道的字段或行為就不要公開。

    迪米特法則其根本思想,是強調了類之間的松耦合。在程序設計時,類之間的耦合越弱,越有利於復用,一個處在弱耦合的類被修改,不會對有關系的類造成波及。也就是說,信息的隱藏促進了軟件的復用。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved