模式與重構(gòu)
設計模式總結(jié)－Visitor模式
摘要: Visitor模式的一個優(yōu)點體現(xiàn)在對集合元素的訪問中：由于集合中的可訪問元素都實現(xiàn)了Visitable接口，所以在迭代集合的過程中，我們可以將每個元素都看成是接口類型。
其次由于JAVA語言的多態(tài)性，雖然每個元素都是接口類型(Visitable)，但每個元素的實現(xiàn)類不同，所以在調(diào)用accept方法時，虛擬機“知道”應該調(diào)起那個正確的方法(例如：集合中的一個String元素，會調(diào)用StringElement的accept方法)
閱讀全文
posted @
2008-04-15 17:38 Paul Lin 閱讀(4482) |
評論 (2) 編輯
設計模式總結(jié)－Strategy模式
摘要: 策略操作定義了策略的輸入和輸出，而把策略的實現(xiàn)工作留給了各個類。這些類以不同的方案來實現(xiàn)同一操作，它們?yōu)橛脩籼峁┙y(tǒng)一的接口，因而這些類可以相互替換。
Strategy模式允許多種策略共存，而代碼不會混亂。策略模式也可以實現(xiàn)模式選擇邏輯和策略本身相分離。
Strategy模式的意圖在于把可選的策略或方案封裝在不同的類中，并在這些類中實現(xiàn)一個共同的操作。
閱讀全文
posted @
2008-04-08 11:52 Paul Lin 閱讀(5373) |
評論 (2) 編輯
設計模式總結(jié)－State模式
摘要: 使用狀態(tài)模式后，客戶端外界可以直接使用事件Event實現(xiàn)，根本不必關心該事件導致如何狀態(tài)變化，這些是由狀態(tài)機等內(nèi)部實現(xiàn)。這是一種Event-condition-State，狀態(tài)模式封裝了condition-State部分。
每個狀態(tài)形成一個子類，每個狀態(tài)只關心它的下一個可能狀態(tài)，從而無形中形成了狀態(tài)轉(zhuǎn)換的規(guī)則。如果新的狀態(tài)加入，只涉及它的前一個狀態(tài)修改和定義。
閱讀全文
posted @
2008-04-07 18:02 Paul Lin 閱讀(7623) |
評論 (2) 編輯
設計模式總結(jié)－Command模式
摘要: 讓方法運行最常見的方式是調(diào)用之，但是在很多情況下，我們不能控制和提供方法執(zhí)行的上下文和時機。這種情況下，可以把方法封裝在對象中。通過在對象中存儲調(diào)用方法所需的信息，就可以讓客戶端或者服務決定何時調(diào)用這個方法。
Command模式的意圖是把請求封裝在對象中。
--摘自《Java設計模式》第24章：Command(命令)模式
閱讀全文
posted @
2008-04-07 15:13 Paul Lin 閱讀(3480) |
評論 (0) 編輯
設計模式總結(jié)－Memento模式(二)
摘要: Memento模式和其它模式的結(jié)合應用：
一、“Mementor”模式和“堆棧”的結(jié)合－“GUI界面撤銷功能”的實現(xiàn)
二、“Mementor”模式和“Observer”模式的結(jié)合－“通知式恢復”
三、“Mementor”模式和“Observer”模式、“責任鏈”模式的結(jié)合－“鏈式通知恢復”
四、“Mementor”模式和“Flyweight”模式的結(jié)合：減少相同對象的拷貝
閱讀全文
posted @
2008-03-22 17:59 Paul Lin 閱讀(1746) |
評論 (1) 編輯
設計模式總結(jié)－Memento模式(一)
摘要: Memento模式的特點：
在需要提供保存、恢復對象狀態(tài)的類中，必須提供兩個方法：
.保存對象當前狀態(tài)方法：將對象自身(this)作為參數(shù)傳入，創(chuàng)建備忘錄。
.恢復對象之前狀態(tài)的方法：取出備忘錄/接收一個備忘錄對象，從中獲取對象之前的狀態(tài)
模式的缺點是耗費大,如果內(nèi)部狀態(tài)很多,再保存一份,無意要浪費大量內(nèi)存.
注意：Memento模式保存的是操作前對象的狀態(tài)，而不是操作后對象的狀態(tài)；否則就沒辦法做恢復了
閱讀全文
posted @
2008-03-22 17:56 Paul Lin 閱讀(2215) |
評論 (0) 編輯
設計模式總結(jié)－Observer模式
摘要: 下面是Observer模式的實現(xiàn)過程：
·創(chuàng)建一個被觀察者，繼承java.util.Observable
·創(chuàng)建一個觀察者，實現(xiàn)java.util.Observer接口
·注冊觀察著，調(diào)用addObserver(Observer observer)
·在被觀察者改變對象內(nèi)部狀態(tài)的地方，調(diào)用setChanged()方法，然后調(diào)用notifyObservers(Object)方法，通知被觀察者
·在觀察者的update(Object)方法中，對改變做出響應。
閱讀全文
posted @
2008-03-07 13:55 Paul Lin 閱讀(3093) |
評論 (0) 編輯
設計模式總結(jié)－Flyweight模式
摘要: Flyweight模式一般由幾個部分組成：
·Flyweight接口(抽象類) ：定義了一個可共享的元類
·Flyweight實現(xiàn)類：實現(xiàn)了元類中的操作，而且可能會提供一個用于保存內(nèi)部狀態(tài)(共享屬性)的空間
·Flyweight Factory：創(chuàng)建Flyweight的工廠類，創(chuàng)建后將其保存到Flyweight Pool中
·Flyweight Pool：緩沖Flyweight對象的池，通常包含在工廠類中
閱讀全文
posted @
2008-03-05 14:33 Paul Lin 閱讀(2985) |
評論 (0) 編輯
設計模式總結(jié)－Bridge模式
摘要: ·在抽象接口中包含了一個對行為接口的引用，這樣的話行為的操作將完全委托給行為接口完成，抽象類無需關心。
·在抽象類的繼承子類中，調(diào)用了行為類的子類來實現(xiàn)不同的行為。此時抽象類的子類中只知道屬性，但不知道具體的行為實現(xiàn)，實現(xiàn)了概念與行為的分離
·在行為類的繼承子類中，只知道執(zhí)行相應的動作，但不知道具體的屬性，實現(xiàn)了行為和概念的分離
閱讀全文
posted @
2008-02-26 21:48 Paul Lin 閱讀(2091) |
評論 (0) 編輯
設計模式總結(jié)－Decorator模式(二)
摘要: Decorator模式的實際應用--動態(tài)黑名單過濾
閱讀全文
posted @
2008-02-19 18:31 Paul Lin 閱讀(1781) |
評論 (0) 編輯
設計模式總結(jié)－Decorator模式
摘要: Decrator模式的適用場合：
1).在運行時刻由用戶動態(tài)決定加入的方式和時機，無法在編譯期間決定
2).需要改變的行為太多，用繼承會導致復雜性的增加
閱讀全文
posted @
2008-02-19 16:33 Paul Lin 閱讀(2099) |
評論 (0) 編輯
設計模式總結(jié)-Composite模式(一)
摘要: Composite模式的特點：
·Composite模式一般都有一個抽象類或接口來表示最基本的構(gòu)件。
·Composite模式一般都由兩類對象構(gòu)成：表示單個元素的對象(Primitive)和表示多個元素組合的對象(Composite)
·Composite模式下Primitive和Composite對象都繼承或?qū)崿F(xiàn)上層接口或父類
·Composite模式下每個構(gòu)件都含有三個基礎方法：add(構(gòu)件)、remove(構(gòu)件)、iterator()
·Composite對象含有一個用來保存其下所有基礎元素的的集合，例如：Vector，ArrayList，HashMap
·Composite對象的方法被調(diào)用時一般都會引起其下所有基礎元素相同方法的調(diào)用，即遞歸調(diào)用。
閱讀全文
posted @
2008-01-21 09:55 Paul Lin 閱讀(3143) |
評論 (0) 編輯
設計模式總結(jié)－Adapter模式
摘要: 從上面的四種方式來看，方式二最簡單也最常用，方式三最靈活，方式一和四有相同的地方就是都繼承了其中的某一個類，這樣就限制了適配器的子類不能再繼承其它的功能父類了，不同的地方是方式一使用委托的方式來完成類B的功能，而方式四則自己實現(xiàn)了接口的方法。
閱讀全文
posted @
2008-01-14 17:50 Paul Lin 閱讀(1446) |
評論 (0) 編輯
設計模式總結(jié)－Proxy模式
摘要: Proxy類具有幾個特點
·Proxy類一般都實現(xiàn)或繼承了后臺對象接口或抽象類，在其中實現(xiàn)了后臺對象接口的方法，這樣外界和代理類打交道的客戶端看到的是和后臺對象一樣的接口。根本不知道自己在和代理對象打交道。
·Proxy類一般都含有一個后臺對象作為其成員，因為代理類需要在其實現(xiàn)接口的方法中調(diào)用后臺對象的真正方法來實現(xiàn)業(yè)務邏輯。
·Proxy類一般都需要包含一個能夠驗證用戶請求是否合法的對象，如上例中的ForumPermisssions類，作為轉(zhuǎn)發(fā)或拒絕用戶請求的判斷依據(jù)
閱讀全文
posted @
2008-01-14 17:40 Paul Lin 閱讀(1517) |
評論 (0) 編輯
設計模式總結(jié)－單例模式
摘要: 在多線程環(huán)境下，我們無法保證一個方法能夠持續(xù)運行到結(jié)束，其他線程的方法才開始運行。因而可能存在這樣一種情形：兩個線程幾乎同時嘗試初始化單例類。假設第一個方法發(fā)現(xiàn)單例為空，而第二個方法在此刻開始運行，它也會發(fā)現(xiàn)該單例為空。接下來，這兩個方法都將對該單例進行初始化
閱讀全文
posted @
2008-01-03 22:31 Paul Lin 閱讀(1231) |
評論 (0) 編輯
設計模式總結(jié)－Builder模式(二)
摘要: 使用Builder模式的最佳場合應該是：對象的構(gòu)建過程長或復雜、構(gòu)建對象所需的全部參數(shù)無法在一開始就完全獲得，必須通過一步步的交互過程來獲取。例如：通過Web頁面的輸入或用戶選擇來構(gòu)建所需對象
閱讀全文
posted @
2008-01-02 23:51 Paul Lin 閱讀(1624) |
評論 (2) 編輯
設計模式總結(jié)－Builder模式
摘要: 所以我們可以將Builder模式分成四個組成部分：·產(chǎn)品：public interface Product·零件：Public interface Part·生產(chǎn)零件的過程：public interfact Builder·組裝零件的過程：public class Director
閱讀全文
posted @
2008-01-02 23:01 Paul Lin 閱讀(528) |
評論 (0) 編輯
設計模式總結(jié)－Prototype模式
摘要: Prototype模式最適用的場合應該是：當幾個對象的類僅在屬性上存在一點差異，而行為上完全相同時。可以在復制一個原型對象后，對其屬性進行細小的微調(diào)，從而實現(xiàn)定制化的目的。
閱讀全文
posted @
2008-01-02 22:59 Paul Lin 閱讀(2045) |
評論 (0) 編輯
設計模式總結(jié)－工廠模式
摘要: 從上面的4種方式來看，方式1～3適合于工廠所產(chǎn)生的對象都是屬于同一個父類型的，而方式4則適合于工廠需要產(chǎn)生多種類型的產(chǎn)品，而每一種類型的產(chǎn)品下面又有多個子類型的情況。
閱讀全文
posted @
2008-01-02 22:54 Paul Lin 閱讀(460) |
評論 (0) 編輯