???? 設計模式這個詞無論是從字面上還是從具體意義上看都有著一種與眾不同的氣質(zhì).單說設計和模式都是夠份量的詞.
?? 名詞解釋:引自百度知道
?? 設計:
?? 人類通過勞動改造世界，創(chuàng)造文明，創(chuàng)造物質(zhì)財富和精神財富，而最基礎、最主要的創(chuàng)造活動是造物。設計便是造物活動進行預先的計劃，可以把任何造物活動的計劃技術和計劃過程理解為設計.意指有目標和計劃的創(chuàng)作行為.
?? 模式:
?? 前人積累的經(jīng)驗的抽象和升華。簡單地說，就是從不斷重復出現(xiàn)的事件中發(fā)現(xiàn)和抽象出的規(guī)律，是解決問題的經(jīng)驗的總結。只要是一再重復出現(xiàn)的事物，就可能存在某種模式。
?? 一般一聽說別人是搞設計的都非常佩服,無論是否是IT行業(yè),覺的做設計的總是能從全局出發(fā),均衡的考慮問題,比起最底層的工作者來說總是高那么一點點.
?? 程序員都希望自己的程序?qū)懙拇a結構強壯,容易維護,擴展性強,而設計模式也許是實現(xiàn)這一想法的最好理論.所以很多程序員(包括本人)都希望有自己的程序中用上那么一點點的設計模式,即使作用并不那么明顯,也會有種成就感.但是并不是所有的程序員都能非常容易的找到這樣的機會,雖然清楚23種模式的定義,但在具體的項目中并不知道應該如何來用.
?? 還有一種情況是,當自己對設計模式的全部概念并不是特別清楚的時候,例如建造者模式,他們的程序中往往都應用到了某種模式,只是沒有太在意而已. .Net中的StringBuilder就是應用了建造者模式.
?? 這里以我的經(jīng)歷來說明一下,我以前在一個項目中開發(fā)了一個分頁控件. 但我是在學習了建造者模式后才發(fā)現(xiàn)是應用了模式.
?? 我們知道所有的控件,包括用戶控件和自定義控件它們都是繼承自Control類,在自定義控件中我重寫了它的如下些方法:
??Code
??//重寫服務器控件的輸出標記
??protected override HtmlTextWriterTag TagKey
?? {
?? get
?? {
?? return HtmlTextWriterTag.Div;
?? }
?? }
??//重寫服務器控件內(nèi)容輸出前的事件
?? protected override void OnPreRender(EventArgs e)
?? {
?? //分頁樣式表信息
?? if (!this.CustomPager .IsCustomStyle)
?? {
?? this.AddStyleFile();
?? }
?? base.OnPreRender(e);
?? }
??//重寫服務器控件輸出內(nèi)容的方法
?? 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=0;
?? if (this.CustomPager .UrlPaging==true &&!DesignMode )
?? {
?? if (!Page.IsPostBack)
?? {
?? int index;
?? int.TryParse(Page.Request.QueryString[this.CustomPager .UrlPageIndexName], out index);
?? if (index <= 0)
?? index = 1;
?? if(index >this .pageCount )
?? {index =1;}
?? PageChangingEventArgs args = new PageChangingEventArgs(index);
?? OnPageChanging(args);
?? }
?? }
?? if (!DesignMode)
?? {
?? inputPageIndex = Page.Request.Form[UniqueID + "_input"];
?? int .TryParse (inputPageIndex ,out i);
?? if (i < 1 || i > this.pageCount)
?? { i = 1; }
?? inputPageIndex = i.ToString();
?? }
?? base.OnLoad(e);
?? }
?? 上面幾個方法是控件固有的,所有的控件都會經(jīng)歷這樣的生命周期,這個過程相對來說是穩(wěn)定的,但是它的內(nèi)部實現(xiàn)卻是不固定而是可變的.這也是我們能寫出功能不同的控件的原因.
?? 為了說明方便,先帖個建造者模式的類圖:

?? 程序員就相當于建造模式類圖當中的Director,他的意圖決定了自定義控件如何實現(xiàn).例如我想做一個自定義的分面導航控件,Control類相當于Builder,它負責指引具體的生產(chǎn)者類(ConcreteBuilder)如果完成Director的意圖.具體的生產(chǎn)者當然就ConcreteBuilder了,它按照Control類的指示來完成控件具體的創(chuàng)建過程.
?? 這樣的程序在建造者模式中并不是標準的,它省略了抽象建造者角色及Director類.
?? 看來有時候你不想用模式都難,使用模式應該是一種順其自然的現(xiàn)象,設計模式它是用來解決問題的,并不是讓我們強行用它(強扭的瓜不甜)，否則會因為過度的設計給原本簡單的系統(tǒng)帶來維護上的困難。
?? 上面的分頁控件代碼中可以看出，所謂建造者模式，它內(nèi)容結構比較復雜，往往會包含非常多的方法等，但從整體上來說，創(chuàng)建過程相對穩(wěn)定，但是它的內(nèi)部成員不穩(wěn)定。每個控件都具備相同的生命同期，從初始化到呈現(xiàn)到最后的銷毀，但其中的實現(xiàn)過程又是不同的。
?? 針對這種情況就可以把相對復雜的創(chuàng)建過程抽象出來，讓創(chuàng)建過程與實現(xiàn)過程分離，從而達到相同的創(chuàng)建過程可以實現(xiàn)
??不同的表現(xiàn)方式的目的.
?? 創(chuàng)建者模式的特點:
?? 1:最終創(chuàng)建的產(chǎn)品(Product)內(nèi)部結構相對復雜
?? 2:Product的創(chuàng)建過程穩(wěn)定.
?? 3:Product的內(nèi)部對象的實現(xiàn)過程是可變動的。
?? 4:Product并不關心內(nèi)部子系統(tǒng)如何實現(xiàn)(只求結果不關心過程).
?? 5:Product的創(chuàng)建過程與實現(xiàn)部分分離。
?? 6:同樣的創(chuàng)建過程可以實現(xiàn)不同的表現(xiàn)結果.
?? 適用性：
?? 沒有唯一的標準,如果開發(fā)者感覺自己的項目適合創(chuàng)建者模式的特點，那么你就可以嘗試去用，否則還是少用。
?? 總結:
?? 設計模式離我們并不遠,其實就在我們身邊,就看你有沒有心去關注它的存在了. 一個善于應用OO的程序員總會有機會把設計模式當成解決問題最好的武器

總結

以上是生活随笔為你收集整理的设计模式到底离我们有多远的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。