フレームワークのコーディングでどのデザインオプションを使用する方が良いですか？

Question

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

私が持っているかもしれません：

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

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

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

「getter」メソッドをインターフェイスに作成し、フレームワークで返されたnullオブジェクトを慎重にチェックする方法があります。

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

これについてのあなたのアイデアは何ですか？これに対する実践的なアプローチは何ですか？

Answer 1

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

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

Answer 2

優れたフレームワークを構築するには、同時にアプリケーションを構築する必要があります。そうすれば、あなたのクライアントがそれに追われる前にあなたのクライアントが耐えられる苦痛を知り、理解するでしょう。

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

あなたは、最も簡単な方法で、彼らの視点から見れば、最高になることをすぐに認識します。

Answer 3

インターフェイスだけで動作することはできません。動作はありません。

私はFrameworkの防御プログラミングの哲学に同意し、開発者が間違いを避けるのを助けます。

あなたはファクトリオブジェクトを供給することができます：その後、少なくとも我々はいくつかのではなどのヌルのため

を確認することができます

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

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

は、それが開発者に助けを与えることは通常可能です思いました。場合によっては、エラーをトラップして朗報として報告することが最善の方法です。例えばここでは、完全に細かいIHelperをあなたの工場に渡すことができますが、後でそのクラスのアクションが不可能になる可能性があります。 （例えば、イメージであった場合、ファイルであり、後で副作用によってファイルが閉じられました。）その後、エラー状態をトラップし、どこかでエラーを記録し、例外をスローします。そして、少なくとも開発者は何を修正するかについての手掛かりを持っています。