常用設計模式 深入理解模板模式

2021-09-12 17:58:36 字數 2601 閱讀 1399

定義:定義乙個操作中的演算法的框架,而將一些步驟延遲到子類中,使得子類可以不改變乙個演算法的結構即可重定義該演算法的某些特定步驟。

說到步驟,我想對於我們程式設計師來說,最熟悉的當然是乙個需求的乙個開發流程了,下面我們就從開發流程來了解模板模式。

那麼開發流程具體有哪些步驟,請看:

1. 需求評審(產品,開發,測試參與)

2. 開始開發

3. 提交測試

4. 功能上線

當然這是開發過程中沒有修改需求的情況,然後我們定義乙個演算法步驟:

public abstract class developmentprocess 

}

寫了這麼多方法,然後我們再定義個子類,來繼承它:

public class developmentprocesstest extends developmentprocess

@override

protected void development()

@override

protected void submittest()

@override

protected void goonline()

public static void main(string args)

}

然後我們執行一下**,將會得到如下結果:

需求評審

開始開發

提交測試

功能上線

這就是乙個簡單的模板模式,在此你有沒有很奇怪,你為什麼定義方法的時候,全是protected型別的方法,目的是為了什麼,那麼在使用模板模式的時候需要注意一下:

1. 抽象模板中的基本方法盡量設定為 protected型別

2. 符合迪公尺特法則(如果不清楚則請翻看鄙人的設計模式七大原則)

3. 不暴露的屬性和方法盡量不要設定為 protected 型別,如果不是必須訪問,盡量不要擴帶其他的訪問許可權。

模板優化:

如果類似上面這種寫法,大家覺不覺得有些問題,就是具體的實現交給了子類,子類想怎麼玩就怎麼玩,為了防止惡意操作呢,一般模板方法上都加上final關鍵字,不允許被覆蓋。

public abstract class developmentprocess 

//開始開發

protected final void development()

//提交測試

protected final void submittest()

//功能上線

protected final void goonline()

//完整開發流程

final public void run()

}

再一次執行,則還是得到剛才執行的結果,但是這樣做的好處,具體過程封裝在父類,子類是不知道過程的。

突然有一天,部門不小心招來了一位小明同學,開發老是出問題,讓他開發乙個功能,老是把之前好的**修改了,對於測試來說,乙個功能要反覆測試幾遍,非常鬧心。(一般開發過程都需要回歸測試,因為開發過程中有bug,修改後總得在測試一遍吧,這裡便於理解,出此下策,對不起了,小明同學)

怎麼辦呢?對於我們剛才的流程好像不管用了,需要做回歸測試,新增乙個步驟?no no no ,如果你的模板方法比較複雜,一修改,可能子類就需要跟著改了,這不就違背了開閉原則。

那麼怎麼辦呢?一思考,並不是所有的開發人員都需要 回歸測試,可以加乙個判斷,針對不同開發人員,處理方式不一致。

鉤子方法

修改後的模板方法類:

public abstract class developmentprocess 

//開始開發

protected final void development()

//提交測試

protected final void submittest()

//功能上線

protected final void goonline()

//完整開發流程

final public void run()

this.goonline();

}//鉤子方法

protected abstract boolean isrepeattest();

}

修改測試類:

public class developmentprocesstest extends developmentprocess

}

我們來測試一下效果:

public static void main(string args)
最終得到如下結果:

需求評審

開始開發

提交測試

進行回歸測試

功能上線

這就是模板模式,是不是很簡單,在開發過程中,你是不是也常常使用到過,但是並不知道這叫模板模式。

深入理解設計模式(十) 命令模式

命令模式 command pattern 是一種資料驅動的設計模式,它屬於行為型模式。請求以命令的形式包裹在物件中,並傳給呼叫物件。呼叫物件尋找可以處理該命令的合適的物件,並把該命令傳給相應的物件,該物件執行命令。命令模式是乙個高內聚的模式,其定義為 將乙個請求封裝成乙個物件,從而讓你使用不同的請求...

深入理解設計模式(七) 建造者模式

建造者模式也稱生成器模式 定義 將乙個複雜物件的構建與它的表示分離,使得同樣的構建過程可以建立不同的表示 依賴倒轉 產品類 一般是乙個較為複雜的物件,也就是說建立物件的過程比較複雜,一般會有比較多的 量。在本類圖中,產品類是乙個具體的類,而非抽象類。實際程式設計中,產品類可以是由乙個抽象類與它的不同...

深入理解設計模式(一) 單例模式

本文首先概述了單例模式,揭示了單例模式的應用場景和優缺點,最後我們給出了單例模式的幾種實現方式及注意事項。單例模式是一種常用的軟體設計模式,其定義是單例物件的類只能允許乙個例項存在。許多時候整個系統只需要擁有乙個的全域性物件,這樣有利於我們協調系統整體的行為。比如在某個伺服器程式中,該伺服器的配置資...