4

ブリッジ パターンに精通している人は、構成を使用して具体的な実装者を洗練された抽象化の一部として含めることを知っています。基本的に、このパターンのクライアントとして抽象化を使用することが期待されます。 ここに画像の説明を入力 / --Implementer-- / Interface Implementer extends AutoClosable { public void open(); } 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 であるという問題に遭遇しました。私の場合、クライアント側で抽象化を直接使用し、コンストラクターのパラメーターとして文字列を使用して、使用する具体的な実装を決定します。しかし、これにより、try-with-resources(Abstraction ab = new RefinedAbstraction("implementorA")) を使用できない状況が発生します。これは、Complier が私の抽象化が AutoCloseable ではないと文句を言うからです。実際にここで必要な抽象化インターフェイスのメソッドであるため、concreteImplementor インスタンスを try-with-resouces ブロックに配置することは意味がありません。

これを回避する唯一の方法は、try-with-resources を使用する代わりに、finally ブロックで try/catch を使用して、Abstraction.implementer を明示的に閉じることです。しかし、これを行うと、実装者の可視性を保護されたものから公開するように増やす必要があり、これは良くありません。

何かご意見は？またはこれのためのより良いアプローチ？

4

1 に答える 1

1

Abstractionそれ自体を にして、空のAutoCloseableままにすることができます。close()次に、autocloseables を構成するサブクラスをオーバーライドcloseして、構成されたオブジェクトへの呼び出しをデリゲートします。その後、クライアントはすべてAbstractionの を autocloseable として扱い、try-with-resources を使用してそれらと一貫して対話できます。

于 2012-04-10T16:40:30.570 に答える