設計模式六大原則及設計模式分類

2021-10-05 05:27:56 字數 2117 閱讀 1789

設計模式分類

2. 結構型設計模式

3. 行為型設計模式

總結:我們遇到什麼困難,也不要怕,微笑著面對他,消除恐懼的最好辦法就是面對恐懼,堅持,才是勝利,加油!奧利給!?

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

錯誤:開發者在activity中寫bean檔案、網路資料處理,甚至 adapter 也寫在 activity 中。

正解:activity就寫activity;其他的輔助類或者工具類重新寫出來;最好是把activity、service、adapter、beans等檔案分類分包裝好;

定義:類、模組、函式等應該是可以拓展的,但是不可修改。拓展是開放的,修改是封閉的

正解:面對複雜多變的「需求」;我們應該盡量通過擴充套件的方式來實現變化,而不是通過修改原有的**來實現。

舉例:我們要實現乙個列表,一開始只有查詢的功能,後來要新增「新增」功能,過幾天又要增加「刪除」功能。

錯誤:大多數人的做法是寫乙個方法,然後通過傳入不同的值控制方法來實現不同的功能。但是如果又要新增功能,我們還得修改方法。

正解:用開發封閉原則解決就是增加乙個抽象的功能類,讓新增、刪除和查詢作為這個抽象功能類的子類。這樣再新增功能,就無須修改原有的類,只需要新增乙個功能類的子類實現功能類的方法。

定義:所有引用基類(父類)的地方必須能透明地使用其子類的物件。

注釋:在軟體中將乙個基類物件替換成其子類物件,程式將不會產生任何錯誤和異常;反過來不成立;→《類似於多型性的定義》

建議:在程式中使用基類型別來對物件進行定義,而在執行時再確定其子類型別,用子類物件來替換父類物件。比如:

可以使用 object url =

""代替 string url =

""在執行時,在對url進行型別判斷;

注意:子類的所有方法必須在父類中宣告,或子類必須實現父類中宣告的所有方法;

盡量把父類設計為抽象類或者介面,讓子類繼承父類或實現父介面,並實現在父類中宣告的方法;

定義:高層模組不應該依賴低層模組,兩者都應該依賴於抽象;抽象不應該依賴於細節,細節應該依賴於抽象;

抽象即介面或者抽象類;細節即具體實現類或者new 的物件;《並沒有整明白》

定義:乙個軟體實體應當盡可能少地與其他實體發生相互作用。

注釋:設計系統時,應該儘量減少物件之間的互動。如果兩個物件之間不必彼此直接通訊,那麼這兩個物件就不應當發生任何直接的相互作用;如此當其中某乙個模組發生修改時,就會盡量少地影響其他模組。

正解:

類的劃分上,應當盡量建立耦合度低的類,這樣類一旦被修改,則不會較大的影響關聯的類;

類的結構設計上,每個類都應當盡量降低其成員變數和成員函式的訪問許可權。

對其他類的引用上,乙個物件對其他物件的引用應當降到最低。

定義:乙個類對另乙個類的依賴應該建立在最小的介面上。

要為各個類建立專用的介面,而不要試圖建立乙個很龐大的介面供所有依賴它的類呼叫;建立單一介面,不要建立龐大臃腫的介面;要細化介面,介面中的方法盡量少;

注意

對介面進行細化可以提高程式設計的靈活性;但是如果過小,則會造成介面數量過多,使設計複雜化。所以要適度。

只暴露給呼叫的類它需要的方法,它不需要的方法則隱藏起來。

介面方法盡量少用public修飾。介面是對外的承諾,承諾越少對系統的開發越有利,變更風險也會越少。

與物件建立有關;共5種:單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式;

6種單例模式.

共7種:介面卡模式、裝飾模式、**模式、外觀模式、橋接模式、組合模式、享元模式。

共11種:策略模式、模板方法模式、觀察者模式、迭代器模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。等

大佬劉望舒的部落格已經寫得很全面了,作為學習《高階之光》整理筆記的板塊,實在汗顏;大佬的原文部落格: 設計模式.。

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

0.05 設計模式 設計模式 規範 筆記 大話設計模式 物件導向的關鍵在於封裝,封裝好了才能很好的復用,達到單一職責和開放擴充套件 封閉更改的效果。1 單一職責原則 就乙個類而言,應該僅有乙個引起它變化的原因.增加功能不應該修改已有的 避免修改出錯及重複測試.如果你能夠想到多於乙個的動機去改變乙個類...

設計模式六大原則

參考文章 單一職責原則 single responsibility principle,srp 乙個類只負責乙個功能領域中的相應職責,或者可以定義為 就乙個類而言,應該只有乙個引起它變化的原因。開閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開放,對修改關閉。...