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

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

不相容結構的協調——適配器模式(一)

      我的筆記本電腦的工作電壓是20V,而我國的家庭用電是220V,如何讓20V的膝上型電腦能夠在220V的電壓下工作?答案是引入一個電來源配接器(AC Adapter),俗稱充電器或變壓器,有了這個電來源配接器,生活用電和膝上型電腦即可相容,9-1所示:圖9-1 電來源配接器      在軟體開發中,有時也存在類似這種不相容的情況,我們也可以像引入一個電來源配接器一樣引入一個稱之為適配器的角色來協調這些存在不相容的結構,這種設計方案即為適配器模式。 9.1 沒有源碼的演算法庫      

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

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

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

3 完整解決方案       為了將Chart類的職責分離,同時將Chart對象的建立和使用分離,Sunny軟體公司開發人員決定使用簡單原廠模式對圖表庫進行重構,重構後的結構2所示:圖2 圖表庫結構圖       在圖2中,Chart介面充當抽象產品類,其子類HistogramChart、PieChart和LineChart充當具體產品類,ChartFactory充當工廠類。完整代碼如下所示://抽象圖表介面:抽象產品類interface Chart {public void display()

UML的結構

UML——Unified Modeling Language,整合模組化語言,是一種定義良好、易於表達、功能強大且普遍使用的可視化建模的一種語言。它溶入了軟體工程領域的新思想、新方法和新技術。它的範圍不限於支援物件導向的分析與設計,還支援從需求分析開始的軟體開發的全過程。UML中最重要的就是闡述了系統建模的九種圖:使用案例圖、類圖、對象圖、狀態圖、活動圖表、順序圖表、協同圖、元件圖表、部署圖。下面是我總結的MUL的大體結構圖: (清晰的大圖)

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

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

兩道與移動開發相關的英文設計模式題

(1) Instagram Instagram is a free photo sharing program and social network that was launched in 2010 and had a tremendous success since then. On  April 2012, Facebook has acquired Instagram for approximately $1 billion dollars in cash and stock.

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

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

不相容結構的協調——適配器模式(四)

9.6 預設適配器              預設適配器模式是適配器模式的一種變體,其應用也較為廣泛。預設適配器模式的定義如下:預設適配器模式(Default Adapter Pattern):當不需要實現一個介面所提供的所有方法時,可先設計一個抽象類別實現該介面,並為介面中每個方法提供一個預設實現(空方法),那麼該抽象類別的子類可以選擇性地覆蓋父類的某些方法來實現需求,它適用於不想使用一個介面中的所有方法的情況,又稱為單介面適配器模式。       預設適配器模式結構9-7所示: 圖9-7 

組件設計原則之概念篇(四)

      穩定抽象原則SAP是六個組件設計原則中的最後一個,它通常與穩定依賴原則SDP結合在一起,用於建立具有較高品質的組件依賴結構。終於是最後一個了,。 穩定抽象原則(The Stable-Abstractions Principle, SAP)A component should be as abstract as it is stable.組件的抽象程度應該與其穩定程度一致。      

不相容結構的協調——適配器模式(二)

9.3 完整解決方案      Sunny軟體公司開發人員決定使用適配器模式來重用演算法庫中的演算法,其基本結構9-4所示:圖9-4  演算法庫重用結構圖       在圖9-4中,ScoreOperation介面充當抽象目標,QuickSort和BinarySearch類充當適配者,OperationAdapter充當適配器。完整代碼如下所示://抽象成績操作類:目標介面interface ScoreOperation {public int[] sort(int array[]);

擴充系統功能——裝飾模式(一)

      儘管目前樓價依舊很高,但還是阻止不了大家對新房的渴望和買房的熱情。如果大家買的是毛坯房,無疑還有一項艱巨的任務要面對,那就是裝修。對新房進行裝修並沒有改變房屋用於居住的本質,但它可以讓房子變得更漂亮、更溫馨、更實用、更能滿足居家的需求。在軟體設計中,我們也有一種類似新房裝修的技術可以對已有對象(新房)的功能進行擴充(裝修),以獲得更加符合使用者需求的對象,使得對象具有更加強大的功能。這種技術對應於一種被稱之為裝飾模式的設計模式,本章將介紹用於擴充系統功能的裝飾模式。12.1

撰寫畢業論文中word方程式編輯器的學習使用(二)——方程式編輯器

接上篇:撰寫畢業論文中word方程式編輯器的學習使用(二)——錄製宏方程式編輯器能夠在文檔中輸入一些複雜的數學公式和符號,比如我們高考時做的數學試卷,都是使用方程式編輯器(可能是word編輯器,也可能是比較專業的編輯器,不得而知)完成的。比如下面的式子:上面的矩陣、運算式,都能使用word中的方程式編輯器輕鬆實現,下面我們先來看下方程式編輯器的介面:“公式”彈出框上面的符號是對數學公式的分類,我們可以點擊相應的類別選擇相應的符號或者運算,然後我們就可以向word中的編輯視窗中嵌入我們想要輸出結果

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

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

百米倒計時小例子

在研究類這塊,有個小例子對我的協助特別大。在這裡跟大家分享一下。本例中,主要講的百米賽跑中的計時。下面是TimerTask類別模組中代碼:Option ExplicitPublic Event UpdateTime(ByVal dblJump As Double)Public Event ChangeText()Public Sub TimerTask(ByVal Duration As Double) Dim dblStart As Double Dim dblSecond As

請求的鏈式處理——職責鏈模式(一)

      “一對二”,“過”,“過”……這聲音熟悉嗎?你會想到什嗎?對!紙牌。在類似“鬥地主”這樣的紙牌遊戲中,某人出牌給他的下家,下家看看手中的牌,如果要不起上家的牌則將出牌請求再轉寄給他的下家,其下家再進行判斷。一個迴圈下來,如果其他人都要不起該牌,則最初的出牌者可以打出新的牌。在這個過程中,牌作為一個請求沿著一條鏈在傳遞,每一位紙牌的玩家都可以處理該請求。在設計模式中,我們也有一種專門用於處理這種請求鏈式傳遞的模式,它就是本章將要介紹的職責鏈模式。 16.1 採購單的分級審批     

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

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

設計模式面試與筆試題剖析(三)

 Windows Media Player和RealPlayer是兩種常用的媒體播放器,它們的API結構和調用方法存在區別。現在你的應用程式需要支援這兩種播放器API,而且在將來可能還需要支援新的媒體播放器,請問如何設計該應用程式?       參考解答:【個人觀點】      本題可使用適配器模式和抽象原廠模式,參考類圖如下所示:     

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

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

對象的複製——原型模式(四)

7.5 原型管理器的引入和實現      原型管理器(Prototype Manager)是將多個原型Object Storage Service在一個集合中供用戶端使用,它是一個專門負責複製對象的工廠,其中定義了一個集合用於儲存原型對象,如果需要某個原型對象的一個複製,可以通過複製集合中對應的原型對象來獲得。在原型管理器中針對抽象原型類進行編程,以便擴充。其結構7-8所示:                             圖7-8 帶原型管理器的原型模式     

總頁數: 61357 1 .... 18719 18720 18721 18722 18723 .... 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.