1. 程式人生 > >oop設計模式抽象總結

oop設計模式抽象總結

構造 ces 外觀模式 步驟 實例化 長時間 一對多 隊列 好處

創建型模式:

一、簡單工廠,工廠方法,抽象工廠

簡單工廠:只有一層抽象,由工廠去獲得抽象類的具體對象,工廠內的方法可以看做靜態方法

工廠方法:有兩個抽象,工廠的抽象和具體類的抽象。

舉個例子: 有個汽車生產工廠,最開始規模比較小,轎車和SUV啊客車等在一個車間裏面,你要哪個車就對這個工廠說,我要xx車,這個工廠就出來一個這個車。

一段時間的運行效益越來越好,要把這三條流水線分開,就分出了三個工廠,轎車工廠,SUV工廠和客車工廠。

工廠方法和簡單工廠相比,1工廠方法更好的實現了開閉原則,要增加類只需要增加代碼,簡單工廠會改類裏面的代碼,會增加分支判斷2工廠方法把簡單工廠的if else分支判斷交給了客戶端

抽象工廠:拿數據庫的例子來說,有user表操作接口(包括SQL實現,和access實現)有dept表操作接口(包括SQL實現和access實現) 抽象工廠類(獲取user表操作,獲取dept表操作) 具體實現類(SQL工廠access工廠)。 抽象工廠的客戶端需要知道有哪些工廠可以選擇,先new出來具體的工廠,再用具體的工廠獲取具體的對象。

抽象工廠這個例子裏面有兩種具體的表(user和dept),兩個處理方式(SQL和access)。 按處理方式來分成兩種工廠,每個工廠都有兩種抽象的表處理, 每個表處理是一種抽象。

二、單例模式

單例模式的特點是有兩個類(一個業務類構造方法私有,一個工廠類負責保存業務類的單例,註意多線程的使用)

三、建造者模式

建造過程分為幾部分,由Builder決定

具體的創建部分,由具體的類Dress決定

創建部分的先後順序,由Director決定

建造者模式可以將一個復雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。

四、原型模式

結構型設計模式

適配器模式、橋接模式、裝飾模式、組合模式、享元模式、代理模式、外觀模式

死亡之組啊、。

適配器模式:

橋接模式:

品牌和軟件可以獨立變化,增加

裝飾模式:

組合模式:

享元模式:

程序設計中,有時需要生成大量細粒度的類實例來表示數據,如果能發現這些實例除了幾個參數外基本都是相同的,如果能把那些參數移到類實例外面,在方法調用時將它們傳進來,就可以通過共享大幅度減少單個實例的數目User變化的 website不變的

什麽情況用享元模式:
如果一個應用程序使用了大量的對象,而大量的這些對象造成了很大的存儲開銷時就應該考慮使用;還有就是對象的大多數狀態是外部狀態 如果刪除對象的外部狀態,可以用相對較少的共享對象取代很多組對象,也可以考慮用享元模式

代理模式:

應用場景一:遠程代理,為一個對象在不同的地址空間提供局部代表。這樣可以隱藏一個對象存在於不同地址空間的事實
應用場景二:虛擬代理,是根據需要創建開銷很大的對象。通過它來存放實例化需要很長時間的真實對象。例如很大的HTML網頁,圖片框通過虛擬代理替代了真實的圖片
應用場景三:安全代理,用來控制真實對象訪問時的權限。一般用於對象應該有不同的訪問權限的時候。
應用場景四:智能指引,是指當調用真實的對象時,代理處理另外一些事。如計算真實對象引用次數,訪問一個世紀對象時,檢查是否已經鎖定它,確保其他對象不能改變它。都是通過代理在訪問一個對象時附加一些內務處理

外觀模式:

行為型設計模式一:

觀察者模式、模板方法模式、命令模式、狀態模式、職責鏈模式

觀察者模式:

觀察者模式又叫發布-訂閱模式
觀察者模式定義了一種一對多的依賴關系,讓多個觀察者對象同時監聽某一個主題對象。
這個主題對象在狀態發生變化時,會通知所有觀察者對象,使他們能夠自動更新自己

模板方法模式:

當要完成在某一細節層次一致的一個過程或一系列步驟,
但其個別步驟在更詳細層次上的實現可能不同時,我們通常考慮用模板方法模式來處理

當不變的和可變的行為在方法的子類實現中混合在一起的時候,不變的行為就會在子類中重復出現。我們通過模板方法模式把這些行為搬移到單一的地方
這樣就幫助子類擺脫重復的不變行為的糾纏

命令模式:

命令模式好處 ; 把請求一個操作的對象與知道怎麽執行一個操作的對象分割開
1較容易設計一個命令隊列
2在需要的情況下,較容易將命令記入日誌
3允許接收請求一方是否要否決請求
4容易實現請求的撤銷和重做
5加新的命令類很容易

狀態模式:簡單版

復雜版,上班的狀態。

職責鏈模式:

行為型設計模式二組:

解釋器模式、中介者模式、訪問者模式、策略模式、備忘錄模式、叠代器模式

解釋器模式:

如果要增加一個音速
直接增加一個Speed類,然後在客戶端條件判斷裏面加一個分支
可以用簡單工廠加反射這樣可以不用增加客戶端代碼了。

中介者模式:

中介者與同事類要互相關聯
中介者模式很容易在系統中應用,也很容易在系統中誤用,當系統中出現了‘多對多’交互復雜的對象群時,不要急於使用中介者模式,
而要先反思你的系統在設計上是否合理
中介者模式優點:
mediater的出現減少了各個Colleague的耦合,使得可以獨立改變和復用各個Colleague類和mediater
其次由於把對象如何協作進行了抽象,將中介作為一個獨立的概念並將其封裝在一個對象中,這樣關註的對象就從對象各自本身的行為轉移到它們之間的交互上來
也就是站在一個更宏觀的角度看待系統
中介者模式缺點:
由於ConcreteMediater控制了集中化,於是就把交互復雜性變為了中介者的復雜性,這樣就使得中介者會變得比任何一個ConcreteColleague都復雜。

應用場景:中介者模式一般應用於一組對象以定義良好但是復雜的方式進行通信的場合 以及想定制一個分布在多個類中的行為,而又不想生成太多的子類的場合

訪問者模式:

這樣如果要增加結婚狀態就很方便了
男女對比這麽多的原因是因為人類在性別上就只有男人和女人兩類,這也正是訪問者模式可以實施的前提
(保證了Action類中的方法數量穩定)
訪問者模式適用於數據結構相對穩定的系統,它把數據結構和作用於結構上的操作之間的耦合解脫開,使得操作集合可以相對自由地演化
訪問者模式的目的是要把處理從數據結構分離出來,很多系統可以按照算法和數據結構分開,如果這樣的系統有比較穩定的數據結構,又有易於
變化的算法的話,使用訪問者模式就是比較合適的,因為訪問者模式使得算法操作的增加變得容易
反之,如果這樣的系統數據結構對象易於變化,經常要有新的數據對象增加進來 ,就不適合使用訪問者模式

優點: 增加新的操作很容易,因為增加新的操作就意味著增加一個新的訪問者,訪問者模式將有關的行為集中到一個訪問者對象中
缺點: 使增加新的數據結構變得困難

策略模式:

該例中,策略模式用來封裝算法。但在實踐中,可以用它來封裝幾乎任何類型的規則,只要分析不同規則之間的相同點,抽象出
抽象類或接口。然後再基於抽象類或接口進行編程

備忘錄模式:

Role,記錄當前時刻內部狀態、負責創建備忘錄、用備忘錄恢復內部狀態

Memento,負責保存Role內部狀態。由Role去恢復。Caretaker負責傳遞備忘錄

Caretaker,負責保存備忘錄,不能對備忘錄的內容進行操作或檢查

為了安全。對客戶端來說,備忘錄應不可見

用到需要撤銷的情況,可以用備忘錄去實現,恢復到之前狀態這樣的

叠代器模式:

oop設計模式抽象總結