カットの下で、両方のアプローチの議論を見つけるでしょう。
そのため、最近、プロパティを返す（キー値をマップする）サービス用の動的（実行時）接続メカニズムを備えたフレームワークを実装する必要がありました。 しかし、問題は、このフレームワークのユーザーにとって、このマップを作成するのに1つのメソッドのみを使用するのは便利ではない可能性があることです。可能なシナリオは、オブジェクトをカーネルに渡すことや、最終的なマップに自動的に追加されるプリミティブ値を渡すことです。
1つの解決策は、各シナリオのメソッドを持つインターフェース、またはすべての可能なメソッドを持つ1つのインターフェースを作成することでした。 このアプローチには欠点があります-そのようなコードの読みやすさと過度の複雑さ、フレームワークの多くの詳細を覚える必要性、すべての必要な情報をカーネルに送信するための1つのクラスを作成できないことです。
別の解決策は、プログラマーに完全な行動の自由を与えることです。 インターフェイスを実装する必要性を軽減し、メソッドに自由なスタイルで名前を付ける機能を提供し、戻り値の型を規制しません。 そして、メソッドの呼び出しとデータの受信は、リフレクションによって行われます。
そのため、ここにいくつかの例を示します。
1.最初のアプローチを使用した実装。
実装のためのインターフェース：
public interface ServiceAsMap { Map<String, Object> getValue(); } public interface ServiceAsObject { Object getValue(); }
そして実装例：
public class UserData implements ServiceAsMap { public Map<String, Object> getValue() { Map<String, Object> result = new HashMap<String, Object>(); result.put("user.home", "/home/dev"); result.put("user.name", "dev"); return result; } } public class UserDataObj implements ServiceAsObject { public Object getValue() { return context.getUser(); } }
例でわかるように、これはあまり便利な方法ではなく、直感的でもありません。
次に、2番目の実装例を考えます（インターフェイスを実装する必要はないことを思い出します）。
@Service public class UserData { public User getUser() { return context.getUser(); } public Map<String, String> getProperties() { Map<String, Object> result = new HashMap<String, Object>(); result.put("user.home", "/home/dev"); result.put("user.name", "dev"); return result; } @PropertyName("age") public int getUserAge() { return 25; } }
例からわかるように、メソッド名は任意のメソッドのクラスで実行されるアクションを説明します。これにより、必要なものをすべて1か所に実装できます。
この例では、カーネルの追加情報を伝える注釈を使用しました。
このアプローチの唯一の欠点は、リフレクションを使用することです。リフレクションは非常に高速ではありません。また、このような構造からデータを実行および取得するための2番目のコードはかなり扱いにくいため、より多くのエラーが発生する可能性があります（テストを適切に記述しない場合）。
親愛なるハラジテリ、私はあなたに、第2のアプローチの適用分野と、一般にそのような状況のあなたのビジョンが起こるかもしれない他のニュアンスについてこの質問を議論することに興味があります。
私は決定を通してのみ自由を使用することを主張しません。インターフェースからの継承が唯一の正しい決定であり、反映が干渉するだけである多くの例があります。
ご清聴ありがとうございました。