《設計模式的藝術》正式完工

      終於藉著這個五一小長假,將《設計模式的藝術》一書全部寫完了,從去年5月份到今年4月份,前後寫了整整一年,經常熬到晚上兩三點,頭髮都白了不少,還常常自嘲式的發出“江郎才盡”的感慨,不過看著近400頁的“新作”,還是挺有成就感的。      為了取個好一點的書名,我糾結了很久(因為貌似很多好書名都被大家用完了,),在多位業內朋友的建議下,最終命名為《設計模式的藝術——軟體開發人員內功修鍊之道》,外加一行小字:“執行個體驅動設計模式實踐指南”,呵呵。感謝那些為我的書名而爭論的朋友們,謝謝!

工廠三兄弟之簡單原廠模式(二)

2 簡單原廠模式概述       簡單原廠模式並不屬於GoF 23個經典設計模式,但通常將它作為學習其他原廠模式的基礎,它的設計思想很簡單,其基本流程如下:       首先將需要建立的各種不同對象(例如各種不同的Chart對象)的相關代碼封裝到不同的類中,這些類稱為具體產品類,而將它們公用的代碼進行抽象和提取後封裝在一個抽象產品類中,每一個具體產品類都是抽象產品類的子類;然後提供一個工廠類用於建立各種產品,在工廠類中提供一個建立產品的Factory

操作複雜物件結構——訪問者模式(一)

        想必大家都去過醫院,雖然沒有人喜歡去醫院(愛崗敬業的醫務工作人員除外,)。在醫生開具處方單(藥單)後,很多醫院都存在如下處理流程:劃價人員拿到處方單之後根據藥品名稱和數量計算總價,藥房工作人員根據藥品名稱和數量準備藥品,26-1所示:      在圖26-1中,我們可以將處方單看成一個藥品資訊的集合,裡麵包含了一種或多種不同類型的藥品資訊,不同類型的工作人員(如劃價人員和藥房工作人員)在操作同一個藥品資訊集合時將提供不同的處理方式,而且可能還會增加新類型的工作人員來操作處方單。 

樹形結構的處理——組合模式(五)

11.5 公司組織圖       在學習和使用組合模式時,Sunny軟體公司開發人員發現樹形結構其實隨處可見,例如Sunny公司的組織圖就是“一棵標準的樹”,11-8所示:圖11-8  Sunny公司組織圖      在Sunny軟體公司的內部辦公系統Sunny

對象間的聯動——觀察者模式(二)

22.2  觀察者模式概述      觀察者模式是使用頻率最高的設計模式之一,它用於建立一種對象與對象之間的依賴關係,一個對象發生改變時將自動通知其他對象,其他對象將相應作出反應。在觀察者模式中,發生改變的對象稱為觀察目標,而被通知的對象稱為觀察者,一個觀察目標可以對應多個觀察者,而且這些觀察者之間可以沒有任何相互聯絡,可以根據需要增加和刪除觀察者,使得系統更易於擴充。      觀察者模式定義如下:觀察者模式(Observer

多人聯機射擊遊戲中的設計模式應用(一)

     為了方便大家更加系統地學習和掌握各種常用的設計模式,下面通過一個綜合執行個體——“多人聯機射擊遊戲”來學習如何在實際開發中綜合使用設計模式。       反恐精英(Counter-Strike, CS)、三角洲部隊、戰地等多人聯機射擊遊戲廣受玩家歡迎,在多人聯機射擊遊戲的設計中,可以使用多種設計模式。下面我選取一些較為常用的設計模式進行分析:       (1) 抽象原廠模式     

自訂語言的實現——解譯器模式(三)

18.3 解譯器模式概述       解譯器模式是一種使用頻率相對較低但學習難度較大的設計模式,它用於描述如何使用物件導向語言構成一個簡單的語言解譯器。在某些情況下,為了更好地描述某一些特定類型的問題,我們可以建立一種新的語言,這種語言擁有自己的運算式和結構,即文法規則,這些問題的執行個體將對應為該語言中的句子。此時,可以使用解譯器模式來設計這種新的語言。對解譯器模式的學習能夠加深我們對物件導向思想的理解,並且掌握程式設計語言中文法規則的解釋過程。      

對象間的聯動——觀察者模式(六)

22.6 觀察者模式與MVC      在當前流行的MVC(Model-View-Controller)架構中也應用了觀察者模式,MVC是一種架構模式,它包含三個角色:模型(Model),視圖(View)和控制器(Controller)。其中模型可對應於觀察者模式中的觀察目標,而視圖對應於觀察者,控制器可充當兩者之間的中介者。當模型層的資料發生改變時,視圖層將自動改變其顯示內容。22-7所示:圖22-7 MVC結構     

面板模式及其改進(一):面板模式概述

      面板模式是使用頻率最高的結構型設計模式之一,無論是在Web應用軟體或是案頭應用軟體,還是在行動裝置 App軟體中,面板模式都得到了廣泛的應用。     

撤銷功能的實現——備忘錄模式(一)

      每個人都有過後悔的時候,但人生並無後悔藥,有些錯誤一旦發生就無法再挽回,有些人一旦錯過就不會再回來,有些話一旦說出口就不可能再收回,這就是人生。為了不後悔,凡事我們都需要三思而後行。說了這麼多,大家可能已經暈了,不是在學設計模式嗎?為什麼弄出這麼一堆人生感悟來,呵呵,別著急,本章將介紹一種讓我們可以在軟體中實現後悔機制的設計模式——備忘錄模式,它是軟體中的“後悔藥”,是軟體中的“月光寶盒”。話不多說,下面就讓我們進入備忘錄模式的學習。 21.1 可悔棋的中國象棋      

請求寄件者與接收者解耦——命令模式(五)

6 請求日誌       請求日誌就是將請求的記錄儲存下來,通常以記錄檔(Log File)的形式永久儲存在電腦中。很多系統都提供了記錄檔,例如Windows記錄檔、Oracle記錄檔等,記錄檔可以記錄使用者對系統的一些操作(例如對資料的更改)。請求記錄檔可以實現很多功能,常用功能如下:       (1) “天有不測風雲”,一旦系統發生故障,記錄檔可以為系統提供一種恢複機制,在請求記錄檔中可以記錄使用者對系統的每一步操作,從而讓系統能夠順利恢複到某一個特定的狀態;       (2)

請求寄件者與接收者解耦——命令模式(六)

7 宏命令       宏命令(Macro Command)又稱為組合命令,它是組合模式和命令模式聯用的產物。宏命令是一個具體命令類,它擁有一個集合屬性,在該集合中包含了對其他命令對象的引用。通常宏命令不直接與請求接收者互動,而是通過它的成員來調用接收者的方法。當調用宏命令的execute()方法時,將遞迴調用它所包含的每個成員命令的execute()方法,一個宏命令的成員可以是簡單命令,還可以繼續是宏命令。執行一個宏命令將觸發多個具體命令的執行,從而實現對命令的批處理,其結構7所示:圖7 

樹形結構的處理——組合模式(一)

      樹形結構在軟體中隨處可見,例如作業系統中的目錄結構、應用軟體中的菜單、辦公系統中的公司組織圖等等,如何運用物件導向的方式來處理這種樹形結構是組合模式需要解決的問題,組合模式通過一種巧妙的設計方案使得使用者可以一致性地處理整個樹形結構或者樹形結構的一部分,也可以一致性地處理樹形結構中的葉子節點(不包含子節點的節點)和容器節點(包含子節點的節點)。下面將學習這種用於處理樹形結構的組合模式。 11.1 設計殺毒軟體的架構結構      Sunny軟體公司欲開發一個殺毒(AntiVirus)

撤銷功能的實現——備忘錄模式(二)

21.2 備忘錄模式概述      備忘錄模式提供了一種狀態恢複的實現機制,使得使用者可以方便地回到一個特定的曆史步驟,當新的狀態無效或者存在問題時,可以使用暫時儲存起來的備忘錄將狀態複原,當前很多軟體都提供了撤銷(Undo)操作,其中就使用了備忘錄模式。      備忘錄模式定義如下:備忘錄模式(Memento Pattern):在不破壞封裝的前提下,捕獲一個對象的內部狀態,並在該對象之外儲存這個狀態,這樣可以在以後將對象恢複到原先儲存的狀態。它是一種對象行為型模式,其別名為Token。   

處理對象的多種狀態及其相互轉換——狀態模式(六)

6 狀態模式總結       狀態模式將一個對象在不同狀態下的不同行為封裝在一個個狀態類中,通過設定不同的狀態物件可以讓環境對象擁有不同的行為,而狀態轉換的細節對於用戶端而言是透明的,方便了用戶端的使用。在實際開發中,狀態模式具有較高的使用頻率,在工作流程和遊戲開發中狀態模式都得到了廣泛的應用,例如公文狀態的轉換、遊戲中角色的升級等。        1. 主要優點       狀態模式的主要優點如下:       (1)

處理對象的多種狀態及其相互轉換——狀態模式(一)

       “人有悲歡離合,月有陰晴圓缺”,包括人在內,很多事物都具有多種狀態,而且在不同狀態下會具有不同的行為,這些狀態在特定條件下還將發生相互轉換。就像水,它可以凝固成冰,也可以受熱蒸發後變成水蒸汽,水可以流動,冰可以雕刻,蒸汽可以擴散。我們可以用UML狀態圖來描述H2O的三種狀態,1所示:圖1 H2O的三種狀態(未考慮臨界點)      

工廠三兄弟之Factory 方法模式(一)

       簡單原廠模式雖然簡單,但存在一個很嚴重的問題。當系統中需要引入新產品時,由於靜態Factory 方法通過所傳入參數的不同來建立不同的產品,這必定要修改工廠類的原始碼,將違背“開閉原則”,如何?增加新產品而不影響已有代碼?Factory 方法模式應運而生,本文將介紹第二種原廠模式——Factory 方法模式。 1 日誌記錄器的設計      

工廠三兄弟之Factory 方法模式(二)

2 Factory 方法模式概述       在簡單原廠模式中只提供一個工廠類,該工廠類處於對產品類進行執行個體化的中心位置,它需要知道每一個產品對象的建立細節,並決定何時執行個體化哪一個產品類。簡單原廠模式最大的缺點是當有新產品要加入到系統中時,必須修改工廠類,需要在其中加入必要的商務邏輯,這違背了“開閉原則”。此外,在簡單原廠模式中,所有的產品都由同一個工廠建立,工廠類職責較重,商務邏輯較為複雜,具體產品與工廠類之間的耦合度高,嚴重影響了系統的靈活性和擴充性,而Factory

技術交流大會總結

大家手裡負責的項目都差不多OK了,前些天,大家在一起大概花了一整天的時間,對自己開發項目中的業務、問題、技術等,進行了交流。大家做項目的時間大概都是在3到4個月之間。記憶較為深刻的教務系統。它分為四個子系統:基礎、選課、評教、考試。這是大家做的項目中,規模最大、涉及人員最多的項目。教務——基礎部分設計:資料庫不要設定外鍵約束,所有的關係使用第三張表來維護。也就是說,只要兩張表有關係,就需要加一張表來維護它們的關係。目的就是通過降低效率,增加基礎資料表的靈活度;採用主鍵產生器,保證產生的主鍵不會重

控制項(七)——GridView控制項以SqlDataSource控制項為資料來源顯示資料

GridView控制項與SqlDataSource控制項就不做詳細介紹了,大家都比較熟悉,而且也比較好理解。下面直接進入例子:本例子中首先拖一個GridView控制項GridView1,配置一下它的資料來源SqlDataSource1,簡單配置一下就可以。然後再為控制項選擇一個合適的樣式。然後在添加一個GridView控制項Gridview2,配置一下他的資料來源SqlDataSource2,然後為控制項選擇一個合適的樣式,關鍵的一步是:設定GridView2控制項的DataKeyNames屬性

總頁數: 61357 1 .... 8557 8558 8559 8560 8561 .... 61357 Go to: 前往

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.