0

私は特定の API を備えた特注のフレームワークに取り組んでおり、現在はそのリファクタリングに取り組んでいます。

私が解決しなければならない問題の 1 つは、クエリの深さやその他の属性に基づいてクエリを別のクラスにリダイレクトするルートのようなアプローチを作成することです。以下は方法です：

class Blah {
public Object query1(){...}
public Object query2(){...}
}

そして、私はそれを次のようなものに変更する必要があります

class Blah implements BeforeFilter{
@Override
protected void filter()
{
//decide to call which query method
//then redirect the request to query
}
public Object query1(){...}
public Object query2(){...}
}

上記のアイデアを実行する非常に伝統的な方法は、各 query() メソッド内に if/else を追加して、先に進むかどうかを決定することです。

正直なところ、私はこのアプローチが好きではありません。そのため、よりエレガントなものを探しています。

PS : そうする理由は、パブリック API を変更するためではありません。プロキシ デザイン パターンを実装しましたが、そのパターンでは一部の API が変更されます。

4

1 に答える 1

2

これは、まさに「ルートのような」アプローチである責任の連鎖のように思えます。フィルターまたはチェーン要素は共通のインターフェイスに準拠し、リンクされたリストに似たさまざまな方法でそれらを組み立てます。クエリ/リクエストは最初のチェーン要素に渡され、次にリクエストを「次の」チェーン要素に渡します。各チェーン要素またはフィルターは、リクエスト/SQL などで何かを行うかどうかを決定します。

このようにして、各フィルター (またはチェーン要素) が他のフィルターから分離され、if-then-else はしごが不要になるフィルタリング メカニズムが得られます。

于 2012-12-05T15:24:33.460 に答える