設計:
人類通過勞動改造世界創造文明創造物質財富和精神財富而最基礎最主要的創造活動是造物設計便是造物活動進行預先的計劃可以把任何造物活動的計劃技術和計劃過程理解為設計意指有目標和計劃的創作行為
模式:
前人積累的經驗的抽象和升華簡單地說就是從不斷重復出現的事件中發現和抽象出的規律是解決問題的經驗的總結只要是一再重復出現的事物就可能存在某種模式
一般一聽說別人是搞設計的都非常佩服無論是否是IT行業覺的做設計的總是能從全局出發均衡的考慮問題比起最底層的工作者來說總是高那麼一點點
程序員都希望自己的程序寫的代碼結構強壯容易維護擴展性強而設計模式也許是實現這一想法的最好理論所以很多程序員(包括本人)都希望有自己的程序中用上那麼一點點的設計模式即使作用並不那麼明顯也會有種成就感但是並不是所有的程序員都能非常容易的找到這樣的機會雖然清楚種模式的定義但在具體的項目中並不知道應該如何來用
還有一種情況是當自己對設計模式的全部概念並不是特別清楚的時候例如建造者模式他們的程序中往往都應用到了某種模式只是沒有太在意而已 Net中的StringBuilder就是應用了建造者模式
這裡以我的經歷來說明一下我以前在一個項目中開發了一個分頁控件 但我是在學習了建造者模式後才發現是應用了模式
我們知道所有的控件包括用戶控件和自定義控件它們都是繼承自Control類在自定義控件中我重寫了它的如下些方法:
Code
//重寫服務器控件的輸出標記
protected override HtmlTextWriterTag TagKey
{
get
{
return HtmlTextWriterTag
Div;
}
}
//重寫服務器控件內容輸出前的事件
protected override void OnPreRender(EventArgs e)
{
//分頁樣式表信息
if (!this
CustomPager
IsCustomStyle)
{
this
AddStyleFile();
}
base
OnPreRender(e);
}
//重寫服務器控件輸出內容的方法
protected override void RenderContents(HtmlTextWriter output)
{
//if (DesignMode)
//{ return; }
//寫入分頁信息
this
CSgetPagerHtml(this
CustomPager
iRecordCount
this
CustomPager
iRowsCount
output);
Page
VerifyRenderingInServerForm(this);
}
/**//// <summary>
/// 控件加載事件
/// </summary>
/// <param name=
e
></param>
protected override void OnLoad(EventArgs e)
{
queryString = Page
Request
ServerVariables[
Query_String
];
currentUrl = Page
Request
Path;
int i=
;
if (this
CustomPager
UrlPaging==true &&!DesignMode )
{
if (!Page
IsPostBack)
{
int index;
int
TryParse(Page
Request
QueryString[this
CustomPager
UrlPageIndexName]
out index);
if (index <=
)
index =
;
if(index >this
pageCount )
{index =
;}
PageChangingEventArgs args = new PageChangingEventArgs(index);
OnPageChanging(args);
}
}
if (!DesignMode)
{
inputPageIndex = Page
Request
Form[UniqueID +
_input
];
int
TryParse (inputPageIndex
out i);
if (i <
|| i > this
pageCount)
{ i =
; }
inputPageIndex = i
ToString();
}
base
OnLoad(e);
}
上面幾個方法是控件固有的所有的控件都會經歷這樣的生命周期這個過程相對來說是穩定的但是它的內部實現卻是不固定而是可變的這也是我們能寫出功能不同的控件的原因
為了說明方便先帖個建造者模式的類圖:
程序員就相當於建造模式類圖當中的Director他的意圖決定了自定義控件如何實現例如我想做一個自定義的分面導航控件Control類相當於Builder它負責指引具體的生產者類(ConcreteBuilder)如果完成Director的意圖具體的生產者當然就ConcreteBuilder了它按照Control類的指示來完成控件具體的創建過程
這樣的程序在建造者模式中並不是標准的它省略了抽象建造者角色及Director類
看來有時候你不想用模式都難使用模式應該是一種順其自然的現象設計模式它是用來解決問題的並不是讓我們強行用它(強扭的瓜不甜)否則會因為過度的設計給原本簡單的系統帶來維護上的困難
上面的分頁控件代碼中可以看出所謂建造者模式它內容結構比較復雜往往會包含非常多的方法等但從整體上來說創建過程相對穩定但是它的內部成員不穩定每個控件都具備相同的生命同期從初始化到呈現到最後的銷毀但其中的實現過程又是不同的
針對這種情況就可以把相對復雜的創建過程抽象出來讓創建過程與實現過程分離從而達到相同的創建過程可以實現
不同的表現方式的目的
創建者模式的特點:
:最終創建的產品(Product)內部結構相對復雜
:Product的創建過程穩定
:Product的內部對象的實現過程是可變動的
:Product並不關心內部子系統如何實現(只求結果不關心過程)
:Product的創建過程與實現部分分離
:同樣的創建過程可以實現不同的表現結果
適用性
沒有唯一的標准如果開發者感覺自己的項目適合創建者模式的特點那麼你就可以嘗試去用否則還是少用
總結:
設計模式離我們並不遠其實就在我們身邊就看你有沒有心去關注它的存在了 一個善於應用OO的程序員總會有機會把設計模式當成解決問題最好的武器
From:http://tw.wingwit.com/Article/program/net/201311/13278.html