天気予報プロジェクトの具体的な要件は次のとおりです。
１）気象台は、毎日測定した気温、湿度、気圧等を公表（自社のウェブサイトや第三者への公表等）の形で公表することができます。
2) 他のサードパーティも気象観測所にアクセスしてデータを取得できるように、オープン API を設計する必要があります。
3) 温度、気圧、湿度のインターフェースを提供する
4) 測定データが更新された場合、リアルタイムで第三者に通知できること。
天気予報の設計スキーム 1 - 共通スキーム
WeatherData クラス
気象観測所プロジェクトの分析を通じて、最初に WeatherData クラスを設計できます。
例証します:
1) getXxx メソッドを通じて、第三者が関連情報にアクセスし、取得することができます。
2) データが更新されると、気象観測所は dataChange() を呼び出してデータを更新し、第三者が再度取得する際には最新のデータを取得することができ、もちろんプッシュすることも可能です。
この方式には次のような問題点がある
1) データを取得するためのその他の第三者による気象観測所へのアクセス
2) 実行時にサードパーティを動的に追加できない (Sina Web サイト)
3) ocp 原則の違反 => オブザーバー モード
//WeatherData では、サードパーティを追加するときに、対応するサードパーティ掲示板オブジェクトを作成して dataChange に追加する必要がありますが、これはメンテナンスに役立ちませんし、動的に追加されません
public void dataChange() {
currentConditions.update(getTemperature(), getPressure(), getHumidity());
}
オブザーバーパターンの原理
オブザーバーモードは牛乳の注文業務に似ています
1) ミルクステーション/気象庁: 件名
2) ユーザー/サードパーティの Web サイト: オブザーバー
件名: 登録、削除および通知
1) registerオブザーバー登録
2）removeオブザーバーが削除されました
3) NoticeObservers() すべての登録ユーザーに通知します。さまざまなニーズに応じて、ユーザーがフェッチするデータを更新したり、特定のニーズに応じてプッシュを実装したりできます。
オブザーバー: 入力を受信します
オブザーバー モード: オブジェクトが多対 1 で依存する設計スキームです。依存オブジェクトはサブジェクトであり、依存オブジェクトはオブザーバーです。サブジェクトはオブザーバーに変更を通知します。ユーザーがオブザーバーの場合は、それ以上のパーティになります。
アイデア分析図（クラス図）
オブザーバー パターンの利点
1) オブザーバーモードの設計後は、ユーザー（オブザーバー）の登録、削除、通知などを一括管理することになります。
2) このようにして、オブザーバー (ここでは新しい掲示板として理解できます) を追加すると、コア クラス WeatherData を変更する必要がなく、コードも変更されず、ocp 原則に準拠します。
コアコード:
public class WeatherDataimplements Subject { public void registerObserver(Observer o) { // TODO 自動生成メソッド スタブ observers.add(o); }
public void RemoveObserver(Observer o) { // TODO 自動生成メソッドスタブ if(observers.contains(o)) { observers.remove(o); } }
@Override
public void NoticeObservers() { // TODO 自動生成されたメソッド スタブ for(int i = 0; i < observers.size(); i++) { observers.get(i).update(this.temperatrue, this.pressure 、この.湿度); } } ....