Effective C 讀書筆記 小話設計模式

2021-06-04 12:02:15 字數 1488 閱讀 9125

「effective c++」中第六部分「繼承與物件導向設計中」,scott meyers談論了許多c++物件導向設計中的技巧,其對is-a與has-a、繼承還是符合的論述都頗為精彩,值得一看。在條款35:「考慮virtual以外的其它選擇」中,scott meyers提到兩種考慮的技巧——nvi手法與strategy模式。這裡,nvi手法就是模板方法設計模式,這個模式貌似不在那經典的gof設計模式中,不過在框架的設計中可是隨處可見,例如:spring的設計、hibernate的設計、android中的binder的設計等等。以android中binder的bbinder物件為例:

class bbinder : public ibinder

;

如果了解過binder機制的實現,便知當有服務請求到來時,binder驅動便會呼叫transact處理請求,從bbinder的transact函式的實現可以看出,其真正的實現是在ontransact中,ontransact是protected的,所以service的實現類只需要實現ontransact,在其中實現自己的應用邏輯即可。

status_t bbinder::transact(

uint32_t code, const parcel& data, parcel* reply, uint32_t flags)

if (reply != null)

return err;

}

這個設計模式的使用一方面使得可以在ontransact的前後可以做一些事情,上面的**可以看出,這有點類似「裝飾模式「——之前有寫過其作用,看到這裡的時候還特意回去比較了下兩者的區別=。=,我的看法是「裝飾模式」更像是兩個繼承體系下的情況,它是基於組合的,裝飾者作為component中的乙個物件,當採用不同的裝飾時,便能實現不同的組合。而方法模板設計模式更像是在乙個繼承體系中,如果研究過spring等的原始碼實現會深有體會,public的函式transact只是決定了什麼時候呼叫ontransact,而ontransact的具體技術實現則是交給其繼承者實現。這可能就是其優勢的地方。

「策略模式」

情景:在某個功能模組中,我們需要計算物體的體積,但不同物體的體積計算方式是不一樣的,而且將來可能會有新的物體會新增到系統中,因此我們也希望能保證在不改變原來系統功能的情況下,擴充套件系統。

也即是要求要符合ocp原則,ocp原則就是「開-閉原則」,乙個軟體應該對擴充套件開放,對修改關閉。

解釋:在設計乙個模組的時候,應當使得這個模組可以在不被修改的前提下被擴充套件。換言之,應該在不必修改源**的情況下改變這個模組的行為。

策略模式是最符合ocp原則的設計模式之一,在這個場景中,假設計算體積的功能類為context,其有計算物體體積的功能函式compute,它呼叫具體物體的體積計算函式並返回結果,功能類的使用者ds,然後是從同一介面istrategy繼承而來的各種物體,其類圖如下所示(用staruml,ea):

《effective C 》讀書筆記

1,c 關鍵字explicit c 中,乙個引數的 建構函式 或者除了第乙個引數外其餘引數都有預設值的多參建構函式 承擔了兩個角色。1 是個 構造器,2 是個預設且隱含的型別轉換操作符 所以,有時候在我們寫下如 aaa 這樣的 且恰好 的型別正好是aaa單引數構造器的引數型別,這時候 編譯器就自動呼...

Effective C 讀書筆記

一 讓自己習慣c 1 條款01 視c 為聯邦語言 c 的組成可分為四部分 1.c c 仍然以c語言為基礎。區塊 語句 預處理 內建資料型別 陣列 指標等都來自c。2.object oriented c c with classes所訴說的 classes 包括構造和析構 封裝 繼承 多型 virtu...

讀書筆記 Effective C

部分條款過於深奧,部分條款已了然於心,僅記錄當下所識所學 對於常量巨集定義,最好用const代替 define 對於函式巨集定義,最好用inline代替 define include ifdef ifndef仍被需要 內建物件記得手動初始化 使用成員初始列替換賦值操作 以local static替換...