2

この一連のコードを受け取ったので、コードの結合とクラスの結合を改善する方法を提案する必要があります。しかし、これらのクラスはイベントを利用しているように見えるので、非常にうまく分離されていると思いました。結束に関しては、すべての init() 呼び出しが一緒に配置され、すべてがまったく問題ないように思えます。

public class A
{
    private C t;
    private B g;
    public static void main(String args[]) {
        // Creates t and g.
        t = new C();
        t.init();
        g = new B();
        g.init();
        g.start(this);
    }
    pubic void update (Event e)
    {
        // Performs updating of t based on event
    }
}

public class C
{
    public C() { ... }
    public void init() { ... }
}

public class B
{
    public B() { ... }

    public void init() { ... }

    public void start(A s) {
        e = getNextEvent();
        while (e. type != Quit)
            if (e.type == updateB)
                update(e) ;
            else
                s.update(e) ;
        e = getNextEvent();
    }

    public void update(Event e) { ... }
    }
}

クラスの結束と結合を改善する方法はまだありますか? 私には問題ないように見えますが、何かが欠けていると思います。

これに関する提案をありがとう。

4

4 に答える 4

1

単体テストの作成を開始します (できればTDDを実行してください)。カップリング (および、それほどではありませんが、結合またはその欠如) はすぐに明らかになります。

たとえば、クラス B の start メソッドには型 A のパラメーターがあります。あなたの例では、A をインスタンス化するだけで済みますが、A に他の依存関係がある場合はどうでしょうか? おそらく、最初に必要なのは、A が (更新メソッドを使用して) 実装するインターフェースだけです。

そして getNextEvent は何をしますか? 他の依存関係を使用する場合、テスト ハーネスで B を取得するのは難しい場合があります。

テストは、設計の検証に役立ちます。

于 2011-06-17T03:24:41.363 に答える
0

元の設計が将来別の機能またはクラスを組み込むことである場合、イベントハンドラーを使用して、あなたが言ったように、それが使用されている場合は、実装の戦略パターンとクラスまたはインターフェイスの最適化に集中してください。

于 2011-06-17T03:03:23.253 に答える
0

1 つの提案は、イベント処理ロジックをコントローラー ロジック (クラス A) から分離することです。

したがって、4 種類のクラスがあります。

  • 「サーバー」を実行するために使用されるメイン クラス (A)
  • イベントをリッスンするスレッド (B)
  • 更新されるモデルレイヤー (C)
  • イベントに対する操作をサポートするイベント ハンドラ クラス (D)

次のようになります。

public class Main {
  private Model m;
  private EventListener listener;

  ... main() {
    m = new Model();
    listener = new EventListener();

    EventHandler eventHandler = new MyEventHandler();

    // set the event handler
    listener.setEventHandler(eventHandler);

    listener.start(m);
}

public class Model {
  // nothing to see here
}

public class EventListener() {

  private EventHandler handler = new DefaultEventHandler();

  public void start(final Model m) {
    // startup
    while (event.type != Event.Quit) {
      // get event
      handler.handleEvent(event, m);
    }
    // shutdown
  }

  public void setEventHandler(EventHandler eh) { this.handler = eh }
}

public class MyEventHandler implements EventHandler {

  public void handleEvent(Event e, Model m) {
    // update the model
  }

}

この新しい設計では、モデルを更新するビジネス ロジック (この例では C) が、「Runner」クラスではなく外部クラスに移動したことに注意してください。Main クラスはイベントとは何か、およびそれらの処理方法についての知識を持っている必要がないため、これは少しすっきりしています。

もう 1 つの利点は、これを使用すると、チェーンされたイベント ハンドラーまたは複数のシリアル イベント ハンドラーを使用して、複雑なイベント処理を簡単にコーディングできることです。B はハンドラーの呼び出しのみを担当し、イベントの種類を理解する必要がないため、非同期イベント処理の実装も非常に簡単です。これはパブリッシュ/サブスクライブと呼ばれることもあり、リスナー (B) とハンドラー (update(e) メソッド) を疎結合に保ちます。

于 2011-06-17T03:44:55.950 に答える
0

コードを詳しく見ないと、コードがどの程度分離されているかを判断するのは困難です。イベントはコードを分離する 1 つの方法ですが、コードの理解とデバッグをより困難にする可能性もあります。

クラスを設計する場合、凝集度が高いということは、多くのメソッドが相互に再利用することを意味し、結合度が低いということは、少数のパブリック メソッドのみを公開する必要があることを意味します。

パッケージを設計する場合、凝集度が高いとは、パッケージ内の多くのクラスが相互に依存していることを意味し、結合度が低いとは、パブリック スコープまたはインターフェイスを介した他のクラスとのメッセージがごくわずかであることを意味します。

結束力が高くカップリングが低いことの利点は、特に変化への対応に関しては、痛みが少ないことです。痛みが軽減されない場合は、最適化に多くの時間を費やさないでください。ここで陳腐なことを言っているように聞こえるかもしれませんが、結束力が高く結合力が低いことが「十分」であるかどうかを測定するときは、必ずしもその理論を理解していない人々の意見に頼るのではなく、独自の測定基準を念頭に置いてください。あなたが解決しようとしている問題。

于 2011-06-16T19:08:04.443 に答える