2

私は、クライアントが実装するための一連のインターフェースを提供するフレームワーク（Javaで、しかし質問は一般的です）をコーディングしています。フレームワークの関数は、実装クラスがどのように構築されるかに依存します。つまり、インターフェイスの他のインスタンスを提供するためにそれらの実装に依存します。

たとえば、私は持っているかもしれません：

Interface IContribution {
   public IMyStuff getMyStuff();
   public IHelper getHelper();
}

Interface IMyStuff {
     public void doSomeMethod(IHelper helper);
}

IMyStuffとIHelperのこれらのインスタンスが使用可能であることを確認するにはどうすればよいですか？

1つの方法は、インターフェースで「getter」メソッドを作成し、私のフレームワークで、返されたnullオブジェクトを入念にチェックすることです。

もう1つのオプションは、実装するインターフェイスメソッドを（戦略パターンを使用して）呼び出すファクトリを実装する抽象クラスを作成することです。しかし、これは私がそもそもインターフェースを持っているという事実に反しています。その後、クライアントは抽象クラスを使用する必要があります。しかし、抽象クラスの代わりにインターフェースを使用することで、これを回避することができます。したがって、インターフェイスを提供するのではなく、抽象クラスのみを提供する必要があります...

それで、これについてのあなたの考えは何ですか、これへの実用的なアプローチは何ですか？

4

3 に答える 3

2

IMyStuff と IHelper のこれらのインスタンスが利用可能であることを確認するにはどうすればよいですか?

クライアントがインターフェイスとクラス自体を実装する責任がある場合、それらのインスタンスが利用可能であることを確認するのはクライアントの責任であると言えます。それを自分のコードに入れることには関心がありません。

于 2009-06-25T19:56:27.973 に答える
1

優れたフレームワークを構築するには、同時にその周りにアプリケーションを構築する必要があります。そうすれば、クライアントが押し付けられる前に、クライアントが耐える痛みを知り、理解することができます.

つまり、クライアントはこのアプリケーションでどのように動作するでしょうか? 彼らはそれをどのように扱う必要がありますか？

彼らの観点からすると、最も単純な方法が最善であることがすぐにわかります。

于 2009-06-25T20:10:55.310 に答える
0

インターフェイスだけでは保証できません。動作はありません。

フレームワークの防御的プログラミングの哲学に同意し、開発者が間違いを犯さないようにします。

ファクトリ オブジェクトを指定できます。

public class MyPoliceman {
    public IContribution makeContributor( IMyStuff stuffer, IHelper helper)
                    throws BadAssociatesException {

     // check validity of stuffer and helper here, throw exceptions if null
    }
}

次に、少なくともヌルなどを確認できます。

少し考えれば、開発者に助けを与えることは通常可能です。場合によっては、エラーをトラップして慎重に報告するのが最善の方法です。たとえば、ここでは完全に適切な IHelper をファクトリに渡すことができますが、クラスに対するその後のアクションによって、それが機能しなくなる可能性があります。(例: イメージはファイルであり、副作用により後でファイルが閉じられた。) その後、できることは、結果のエラー状態をトラップし、どこかにエラーを記録し、(おそらく) 例外をスローすることだけです。そうすれば、少なくとも開発者は何を修正すべきかの手がかりを得ることができます。

于 2009-07-05T16:06:08.177 に答える