這樣的解決方案，我認為在我們既有的附表三、附件七、附錄二的tag resolver當中可以拿來用， why ?
因為有些欄位是必要欄位，有些是非必要欄位，與其要透過很多個setter來逐步賦值，或者乾脆提供以static builder class概念來做，
這樣可以更為直覺，反正我有值得就塞值，沒有的就不額外再給。
Q1 : Builder Pattern的好處?
A1-1 : it permits you to vary an object's internal representation(有夠難翻譯)
A1-2 : 把建構過程跟實作品區隔開來(這算好處?)
A1-3 : 提供了建構過程中更良好的控制方式(應該說可以在建構過程加入更多的選擇處理作法)
Q2 : 適用的情境 ?
A2-1 : 在對於一個物件實體中，他的每個(或部分)組成零件是很複雜的，而且每個零組件都沒有相依性，這時候透過不同的組件安裝過程，可以去產出不同的物件實體。
下面這段文字是Head First Design pattern說的優點
1. 將複雜的建構過程封裝起來
2. 允許物件在多個步驟建立，並且可以改變順序
3. 將產品內部表現方式隱藏起來，讓客戶無法觸及
4. 產品的建構方式可以被替換，因為客戶只看的到抽象介面
5. 通常用於建立合成結構 (aggregation )
6. 和工廠模式相比之下，採用builder pattern因為較具彈性，所以也必須對知識領域更深入了解才能發揮效用，不然就不太需要使用這種可以產出不同產品的建構模式了。
在我的工作經驗中，到底有沒有哪些案例是適合使用Builder Pattern的?
雖然很多書上都說可以用點餐範例來說明，不同人點菜時要加辣或加大，就會產出不同的實作品來..
可是必須再深究一下到底Builder Pattern的圖是怎麼描述的!!
[caption id="attachment_145" align="alignnone" width="600" caption="Builder Pattern"]
[/caption]
沒有留言:
張貼留言