ブリッジパターンの場合、抽象化にオートクローズ可能な実装者がある場合

Question

ブリッジパターンに精通している人にとって、具体的な実装者を洗練された抽象化の一部として含めることがわかっています。基本的には、このパターンのクライアントとして抽象化を使用することが期待されます。 /--Implementer--/ インタフェース実装者は{ 公共ボイドオープン（）AutoClosableを拡張します。 public void close（）; }上記のコードのよう

/**--Concrete ImplementerA--**/ 
ImplementerA implements Implementer { 
    public void open(){....}; 
    public void close(){......}; 
} 
/**--Abstration--**/ 
public abstract class Abstraction { 
    protected Implementer implementer; 
    public methodAIwant2use(); 
    public methodBIwant2use(); 
} 
/**--Refined Abstration--**/ 
public class RefinedAbstraction { 
    public RefinedAbstraction(String Implementer) { 
     this.implementer=Implementer; 
    } 
    public methodAIwant2use(); 
    public methodBIwant2use(); 
} 

は、私は私の実装はAutoClosableであることを起こる問題をヒットしました。私の場合は、クライアント側でAbstractionを直接使用し、コンストラクタパラメータとして文字列を使用して、どの具体的な実装者を使用するかを決定します。しかし、これは、私の抽象化がAutoCloseableではないことをコンプライアントが訴えるので、私はtry-with-resources（Abstraction ab = new RefinedAbstraction（ "implementorA"））を使用できない状況に陥ります。 concreteImplementorインスタンスをtry-with-resoucesブロックに配置するのは理にかなっていません。これは実際にここで求められている抽象インタフェースのメソッドだからです。

これを回避する唯一の方法は、try-with-resourcesを使用するのではなく、Abstraction.implementerを明示的に閉じるためにtry/catchをfinallyブロックで使用できることです。しかし、これは、実装者の可視性を保護から公共に高める必要があることを意味しています。

どのような考えですか？それともより良いアプローチですか？

Answer 1

Abstraction自体をAutoCloseableにして、close()を空のままにすることができます。オートクローゼブルを構成するサブクラスは、closeをオーバーライドして、呼び出しをコンストラクトオブジェクトに委譲します。クライアントはAbstractionのすべてを自動クローゼブルとして扱い、try-with-resourcesを使って一貫して対話することができます。