builder模式主要用於以下場景:
需要建立乙個較複雜的大物件例項，並且構成該物件的子物件可能經常會發生變化，但是組成大物件的演算法卻相對穩定。
比如：我們做b/s開發時，經常會遇到一些系統要求支援模板/**切換，乙個完整的頁面由若干子模組組成，不管模板如何變換，子模組的內容/位置如何變化，但組成頁面的演算法即相對固定。
我們假定每個頁面由header,body,footer三個基本模組組成，先抽象出來：
#region
把不依賴具體細節的部分（即相當穩定，不變的部分）抽象出來
public
inte***ce
ishow
//////
頁面頭部 抽象類
///
public
abstract
class
header : ishow
//////
頁面主體 抽象類
///
public
abstract
class
body : ishow
//////
頁面底部 抽象類
///
public
abstract
class
footer : ishow
//////
頁面基類 抽象類
///
public
class
mainpage
getreturn
_lstparts;}}
public
void
show()
console.write(
"頁面構建完畢!");
}}//////
建立器 抽象類
///
public
abstract
class
builder
#endregion
客戶端程式依賴於上面的抽象：
//////
客戶程式
///
public
class
pagemanager
public
void
show()}
最後完成具體模板的實現 :
#region
spring風格的具體頁面及建立器
public
class
springheader : header
}public
class
springbody : body
}public
class
springfooter : footer
}public
class
springbuilder : builder
public
override
void
buildheader()
public
override
void
buildbody()
public
override
void
buildfooter()
public
override
mainpage getpage()
}#endregion
#region
summer風格的具體頁面及建立器
public
class
summerheader : header
}public
class
summerbody : body
}public
class
summerfooter : footer
}public
class
summerbuilder : builder
public
override
void
buildheader()
public
override
void
buildbody()
public
override
void
buildfooter()
public
override
mainpage getpage()
}#endregion
我們還是利用反射來解除最終具體型別的依賴:
xml version="1.0" encoding="utf-8"
?>
<
configuration
>
<
>
<
add
key="assemblyname"
value
="builder"
/>
<
add
key="buildertype"
value
="builder.springbuilder"
/>
>
configuration
>
主程式using
設計模式之組合模式，溫故而知新。
概述 組合模式有時候又叫做部分 整體模式，它使我們樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程式可以向處理簡單元素一樣來處理複雜元素,從而使得客戶程式與複雜元素的內部結構解耦。將物件組合成樹形結構以表示 部分 整體 的層次結構。composite模式使得使用者對單個物件和組合物件的使用具...
溫故而知新篇
2017年7 21日 問題 1 今天想到中興演算法大賽的乙個問題，鏈結在此 賽題主要針對尋找最優路徑，本人採用迪傑斯特拉演算法來做的，但是針對尋找最優路徑時，迪傑斯特拉演算法其實是有漏洞的，它採用類似貪心演算法的意思，每次都通過比較下乙個可達節點之間的權值大小來決定下一步的路徑，正常情況下，採用這樣...
溫故而知新
堆排 建立堆，維護堆的屬性 一次拿掉乙個，然後維護屬性，二分的結構 使得維護屬性只要logn的時間 冒泡也是一次拿走乙個 但是線性的結構 每次沒有節省時間 快排 一次確定 乙個值的位置，然後二分，縮小問題的範圍。floyd找最短 一次更新 將狀態改為經過固定點的 最短距離 迴圈 遍歷每個點，則結果為...