天氣預報項目需求,具體要求如下：
1) 氣象站可以將每天測量到的溫度，溼度，氣壓等等以公告的形式發佈出去(比如發佈到自己的網站或第三方)。
2) 需要設計開放型API，便於其他第三方也能接入氣象站獲取數據。
3) 提供溫度、氣壓和溼度的接口
4) 測量數據更新時，要能實時的通知給第三方
天氣預報設計方案1-普通方案
WeatherData類
通過對氣象站項目的分析，我們可以初步設計出一個WeatherData類
說明:
1) 通過getXxx方法，可以讓第三方接入，並得到相關信息.
2) 當數據有更新時，氣象站通過調用dataChange() 去更新數據，當第三方再次獲取時，就能得到最新數據，當然也可以推送。
這種方案存在如下問題
1) 其他第三方接入氣象站獲取數據的問題
2) 無法在運行時動態的添加第三方 (新浪網站)
3) 違反ocp原則=>觀察者模式
//在WeatherData中，當增加一個第三方，都需要創建一個對應的第三方的公告板對象，並加入到dataChange, 不利於維護，也不是動態加入
public void dataChange() {
currentConditions.update(getTemperature(), getPressure(), getHumidity());
}
觀察者模式原理
觀察者模式類似訂牛奶業務
1) 奶站/氣象局：Subject
2) 用戶/第三方網站：Observer
Subject：登記註冊、移除和通知
1) registerObserver 註冊
2) removeObserver 移除
3) notifyObservers() 通知所有的註冊的用戶，根據不同需求，可以是更新數據，讓用戶來取，也可能是實施推送，看具體需求定
Observer：接收輸入
觀察者模式：對象之間多對一依賴的一種設計方案，被依賴的對象爲Subject，依賴的對象爲Observer，Subject通知Observer變化,比如這裏的奶站是Subject，是1的一方。用戶時Observer，是多的一方。
思路分析圖解(類圖)
觀察者模式的好處
1) 觀察者模式設計後，會以集合的方式來管理用戶(Observer)，包括註冊，移除和通知。
2) 這樣，我們增加觀察者(這裏可以理解成一個新的公告板)，就不需要去修改核心類WeatherData不會修改代碼，遵守了ocp原則。
核心代碼：
public class WeatherData implements Subject {
public void registerObserver(Observer o) {
// TODO Auto-generated method stub
observers.add(o);
}
public void removeObserver(Observer o) {
// TODO Auto-generated method stub
if(observers.contains(o)) {
observers.remove(o);
}
}
@Override
public void notifyObservers() {
// TODO Auto-generated method stub
for(int i = 0; i < observers.size(); i++) {
observers.get(i).update(this.temperatrue, this.pressure, this.humidity);
}
}
....