大話設計模式學習(三) 四大原則

2021-05-22 10:26:53 字數 1693 閱讀 3448

一 單一職責原則

就乙個類而言,應該僅有乙個引起它變化的原因。

我們在做程式設計的時候,很自然的就會給乙個類增加各種各樣的功能,比如我們寫乙個窗體應用程式,一般都會產生乙個doc這樣的類,於是我們會把各種各樣的**,像某種商業運算的演算法啊,資料庫訪問的**啊什麼的都寫到這樣的類中,這就意味著,無論任何需求要來,你都需要更改這個類,這是很糟糕的,維護麻煩,復用基本不可能。

如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會受到意想不到的破壞。

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

二 開放—封閉原則

開放-封閉原則,是說軟體實體(類、模組、函式等)應該可以擴充套件,但是不可修改。具體說,這個原則包含兩個特徵:

1.對於擴充套件是開放的

2.對於更改是封閉的

怎樣的設計才能面對需求的改變卻可以保持相對穩定,使得系統在第乙個版本以後不斷推出新的版本呢?最好的辦法,就是多擴充套件,少修改。涉及的時候,時刻要考慮,盡量讓這個類足夠好,寫好了就不要去修改了,如果新的需求來,增加一些類就完事了,原來的**能不動則不動。

無論模組是如何的封閉,設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須猜測出最有可能發生的變化種類,然後構造抽象來隔離哪些變化。在我們最初寫**時,假設變化不會發生。當變化發生時,我們就建立抽象來隔離以後發生的同類變化,查明可能發生的變化所等待的時間越長,要建立正常的抽象就越難

開放-封閉原則是物件導向設計的核心所在,遵循這個原則可以帶來物件導向所聲稱的巨大好處,也就是可維護,可擴充套件,可復用,靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那部分作出抽象,然而,對於應用程式中的每個部分都刻意地進行抽象同樣不是乙個好主意,拒絕不成熟的抽象和抽象一樣重要。

三 依賴倒轉原則

1.高層模組不應該依賴底層模組。兩個都應該依賴抽象

2.抽象不應該依賴細節,細節應該依賴抽象

面向過程的開發中,為了使得**可以復用,一般會把常用**寫成許許多多函式的程式庫,這樣我們在做新的專案時,去呼叫這些底層的函式就可以了。比如我們做的專案大多數要訪問資料庫,所以我們就把訪問資料庫的**寫成了函式,每次做新的專案時就去呼叫這些函式。這就是高層模組依賴低層模組

問題也就出在這裡,我們要做新專案時,發現業務邏輯的高層都是一樣的,大客戶卻希望都不同的資料庫或儲存資訊方式,這時候就出現麻煩了,我們希望能再次利用這些高層模組,但是高層模組都是與低層的訪問資料庫繫結在一起的,沒辦法復用這些高層模組,這就糟糕了。

不管高層還是低層模組,他們都依賴於抽象,具體一點就是介面或者抽象類,只要介面是穩定的,那麼任何乙個的更改都不用擔心其他受到影響,這就是的無論高層還是低層模組都可以很容易被復用,這才是最好的辦法。

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

四 黎克特制代換原則

子型別必須能夠替換掉他們的父型別

乙個軟體實體如果使用的是乙個父類的話,那麼一定適用於其子類,而他察覺不出父類和子類的區別。也就是說,在軟體裡面,把父類都替換成他的子類,程式的行為沒有變化。正式由於子型別的可替換性才使得使用父類型別的模組在無需修改的情況下才可以擴充套件

大話設計模式 (六大原則)

設計模式六大原則分別是單一職責原則 spr 開放 封閉原則 黎克特制代換原則 lsp 依賴倒轉原則 迪公尺特原則 lod 和合成 聚合復用原則 carp 1.單一職責原則,就乙個類而言,應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑...

大話設計模式 六大原則

設計模式六大原則分別是單一職責原則 spr 開放 封閉原則 黎克特制代換原則 lsp 依賴倒轉原則 迪公尺特原則 lod 和合成 聚合復用原則 carp 1.單一職責原則,就乙個類而言,應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多,就等於把這些職責耦合在一起,乙個職責的變化可能會削弱或者抑...

設計模式之四大原則

看了大話設計模式,想自己總結一下,以加深印象。本次來總結設計模式中的設計原則。以下大部分來自大話設計模式 一 單一職責原則 它的準確解釋是 就乙個類而言,應該僅有乙個引起它變化的原因。通俗的說,就是乙個類不應該有太多的職責,不然的話,當需求發生改變時,你要改動的地方可能非常多且複雜,設計會遭到意想不...