從設計模式Observer的實現看OOD的設計——淺談“多態”的設計原則

Subject.java

 

WeatherData.java

 

Observer.java

 

UserA.java

 

UserB.java

 

demo.java

 

運行結果：

 

 在這個簡單的Observer設計模式的實現中，我們主要分析demo.java這個檔案。在demo類的應用中，我們不難看出，我們在執行個體化對象weatherData，userA，userB的時候，類型選用的是介面類和抽象類別。為什麼不用實體類來定義呢？這就是多態的意義所在。其實，如果用實體類來定義這些執行個體化對象，結果是完全一樣的。這個差別從userA和userB的定義可以找到答案。對於demo類的應用者來說，我們只需要關心Observer類的抽象定義就知道如何調用userA和userB的功能，而不用去關心UserA和UserB這兩個類的具體實現，也許還有UserC，UserD等等很多種不同形態的類。對於程式設計而言，如果我們要一一關注這些具體類的實現，那麼無疑增加了開發人員的工作量。還有一點，當UserA、UserB……等子類的實現發生改變的時候，其他部分的代碼都可以不用改變。譬如UserA改變inform函數的實現：

    @Override

    public
void
inform(String msg){

       System.out.println(“This
is new york city.”);

       System.out.println(“UserA
have got weather message: “
+ msg);

    }

也許採用Observer這個模式來解釋多態的優異特性不是很適合。下次我再用一個更能說明多態的優點的設計來談一下（不套用設計模式了，呵呵）。在這裡專門用到Observer這個模式，算是對設計模式的一個引子，拋磚引玉，希望大家以後能多多的探討這個方面的問題。