C 的三種設計模式

2021-06-04 19:22:58 字數 3458 閱讀 7378

一、單件模式

動機(motivation):

在軟體系統中,經常有這樣一些特殊的類,必須保證它們在系統中只存在乙個例項,才能確保它們的邏輯正確性、以及良好的效率。

如何繞過常規的構造器,提供一種機制來保證乙個類只建立乙個例項?

這應該是類設計者的責任,而不是類使用者的責任。

意圖:

保證乙個類僅有乙個例項,並提供乙個訪問它的全域性訪問點。

------《設計模式》gof          

適用性:

(1)當類只能有乙個例項而且客戶可以從乙個眾所周知的訪問點訪問它時。

(2)當這個唯一例項應該是通過子類化可擴充套件的,並且客戶應該無需更改**就能使用乙個擴充套件的例項時。

**實現

(1)單執行緒singleton實現

以上**在單執行緒情況下不會出現任何問題。但是在多執行緒的情況下卻不是安全的。

如兩個執行緒同時執行到 if (instance == null)判斷是否被例項化,乙個執行緒判斷為true後,在進行建立

instance = new singlethread_singleton();之前,另乙個執行緒也判斷(instance == null),結果也為true.

這樣就就違背了singleton模式的原則(保證乙個類僅有乙個例項)。

怎樣在多執行緒情況下實現singleton?

(2)多執行緒singleton實現:

[c-sharp]view plain

copy

class multithread_singleton  

public static multithread_singleton instance  

}  }  return instance;  

}           

}  

此程式對多執行緒是安全的,使用了乙個輔助物件lockhelper,保證只有乙個執行緒建立例項(如果instance為空,保證只有乙個執行緒instance = new multithread_singleton();建立唯一的乙個例項)。

(3)靜態singleton實現

[c-sharp]view plain

copy

class static_singleton  

}  開等同於  

class static_singleton  

private static_singleton()   

}  

由此可以看出,完全符合singleton的原則。

優點: 簡潔,易懂

缺點: 不可以實現帶引數例項的建立。

二、介面卡模式

適配**換)的概念無處不在......

適配,即在不改變原有實現的基礎上,將原先不相容的介面轉換為相容的介面。  

動機(motivate):

在軟體系統中,由於應用環境的變化,常常需要將「一些現存的物件」放在新的環境中應用,但是新環境要求的介面是這些現存物件所不滿足的。

那麼如何應對這種「遷移的變化」?如何既能利用現有物件的良好實現,同時又能滿足新的應用環境所要求的介面?這就是本文要說的adapter 模式。

意圖(intent):

將乙個類的介面轉換成客戶希望的另外乙個介面。adapter模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。

-------《設計模式》gof     

適用性:

1.系統需要使用現有的類,而此類的介面不符合系統的需要。

2.想要建立乙個可以重複使用的類,用於與一些彼此之間沒有太大關聯的一些類,包括一些可能在將來引進的類一起工作。這些源類不一定有很複雜的介面。

3.(對物件介面卡而言)在設計裡,需要改變多個已有子類的介面,如果使用類的介面卡模式,就要針對每乙個子類做乙個介面卡,而這不太實際。

示意性**例項:

[c-sharp]view plain

copy

inte***ce istack  

//物件介面卡(adapter與adaptee組合的關係)   

public class adapter : istack //適配物件  

public void push(object item)  

public void pop()  

public object peek()  

}  類介面卡  

public class adapter :arraylist, istack  

public void pop()  

public  object peek()  

}  三、訪問者模式

動機:

在軟體構建過程中,由於需求的改變,某些類層次結構中常常需要增加新的行為(方法),如果直接在基類中做這樣的更改,將會給子類帶來很繁重的變更負擔,甚至破壞原有設計。

如何在不更改類層次結構的前提下,在執行時根據需要透明地為類層次結構上的各個類動態新增新的操作,從而避免上述問題?

意圖:

表示乙個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這引起元素的新操作。

適用性:

1.乙個物件結構包含很多類物件,它們有不同的介面,而你想對這些物件實施一些依賴於其具體類的操作。

2.需要對乙個物件結構中的物件進行很多不同的並且不相關的操作,而你想避免讓這些操作"汙染"這些物件的類。visitor使得你可以將相關的操作集中起來定義在乙個類中。當該物件結構被很多應用共享時,用visitor模式讓每個應用僅包含需要用到的操作。

3.定義物件結構的類很少改變,但經常需要在結構上定義新的操作。改變物件結構類需要重定義對所有訪問者的介面,這可能需要很大的代價。如果物件結構類經常改變,那麼可能還是在這些類中定義這些操作較好。

**實現

[c-sharp:collapse]+ expand source

view plain

copy

執行結果:

visoitr模式的幾個要點:

1.visitor模式通過所謂雙重分發(double dispatch)來實現在不更改element類層次結構的前提下,在執行時透明地為類層次結構上的各個類動態新增新的操作。

2.所謂雙重分發卻visotor模式中間包括了兩個多型分發(注意其中的多型機制);第乙個為accept方法的多型辨析;第二個為visitor方法的多型辨析。

3.visotor模式的最大缺點在於擴充套件類層次結構(增添新的element子類),會導致visitor類的改變。因此visiotr模式適用"element"類層次結構穩定,而其中的操作卻經常面臨頻繁改動".

Java三種設計模式

私有功能 private animalfactory 工廠改進 提供貓和狗這兩種動物 public static animal createanimal string type else if cat equals type else 2,工廠方法模式 需要提供抽象類,具體的類,乙個工廠介面,以及具...

常見三種設計模式

策略模式主要針對判斷條件居多但是判斷條件相對來說簡單的程式 比如 redux中的action type的判斷 值 對應的 const typeobj1 const typeobj const reducer state,action 特點 1.要在開發中使用該模式,要做好封裝,採用物件導向的方式 2...

三種設計模式分類

1 建立型模式作用 在建立者模式中,客戶端不再負責物件的建立與組裝,而是把這個物件建立的責任交給其具體的建立者類,把組裝的責任交給組裝類,客戶端只負責物件的呼叫,明確了各個類的職責。2 結構型模式結構型模式是解析類和物件的內部結構和外部組合,通過優化程式結構解決模組之間的耦合問題。3 行為型模式為型...