5

それはデザインパターン-再利用可能なオブジェクト指向ソフトウェアの本の要素で言われています：

実装が1つ（1対1）しかない状況では、抽象実装クラスを作成する必要はありません。これは、ブリッジパターンの縮退したケースです。AbstractionとImplementorの間には1対1の関係がありますが、クラスの実装の変更が既存のクライアントに影響を与えてはならない場合、つまり、再コンパイルする必要はなく、再リンクするだけでよい場合でも、この分離は役立ちます。

実装の変更によってスーパークラス（この場合は抽象）が再コンパイルされるJavaのケースを想像できないため、コンパイル時の利点については疑問があります。

たとえば、XがYを拡張し、クライアントが次のことを行う場合：

Y y = new X();

Xの変更は、Yの再コンパイルを意味するものではありません（もちろん、Xのメソッドシグネチャを変更したくない場合）

ブリッジパターンを使用する場合もまったく同じです。

YAbstraction yabstraction = new YRefinedAbstraction(new XImplementor());

XImplementorの変更は、YAbstractionの再コンパイルを意味するものではありません。

したがって、私によれば、この利点はJavaでは発生せず、1対1の場合=>ブリッジパターンは必要ありません。

おそらく、サブクラスの変更により、スーパークラスが他の言語で再コンパイルされるようになりますか？SmallTalkやC++のように？

あなたの意見は何ですか？

4

2 に答える 2

3

ブリッジパターンには、2つのクラス階層があります。1つは抽象化用（たとえば、DialogWindowやIconWindowなどの派生クラスを持つWindow）、もう1つは実装者用（たとえば、XWindowImplやPMWindowImplなどの派生クラスを持つWindowImpl）です。実装者のインターフェースは、抽象化のクライアントから隠されている必要があります。通常、Implementorは低レベルのプリミティブを提供し、Abstractionはそれらのプリミティブに関して高レベルの操作を構築します。したがって、適切に階層化されたシステムでは、クライアントはImplementorが提供する低レベルのインターフェースを確認する必要はありません。ある日、WindowImplによって提供されるインターフェイスが新しいXYZWindowImplに対応するのに十分一般的ではないことが判明した場合、WindowImplはクライアントによって直接使用されるべきではなく、Windowとそのサブクラスによってのみ使用されるため、変更の自由を保持します。したがって、WindowImplのインターフェイスの変更には、Windowの変更が必要になる場合がありますが、クライアントには反映されません。また、ブリッジの構成に使用される抽象ファクトリの背後に実装者を隠すことがよくあります。

説明したブリッジパターンの利点は、抽象化のクライアントから実装者のインターフェイスを隠すことに依存します。C ++では、ヘッダーファイルを提供しないだけで、Implementorのインターフェイスを簡単に非表示にできます。Javaでは、Implementorをパッケージプライベートメンバーを持つ抽象クラスにすることができます。

C ++では、抽象化のクライアントを再コンパイルする必要はなく、再リンクするだけです。Javaでは、リンクする代わりにクラスをロードするため、必要なのは、新しい設定と新しいjarファイルを使用してアプリケーションをリロードすることだけです。

たとえば、コマンドラインオプションまたは環境変数がAbstract Factoryによって使用され、適切な種類のConcreteImplementorでブリッジを構成する状況を想像してみてください。このような場合は、新しいコマンドライン/環境設定と新しいConcreteImplementorを含む新しいjarファイルを使用してアプリケーションをリロードする必要があります。これは、クライアントコードを再コンパイルせずに実行できます。

したがって、あなたの質問に直接答えることができます。Javaでも、ブリッジパターンには質問で説明されている利点があります。再リンクが行われないという事実を数えると、おそらくさらに大きくなります。

于 2011-12-04T00:01:22.983 に答える
0

Javaには、C /C++と同じように「リンク」がありません。ただし、この概念は引き続き適用されると思います。実装クラスが抽象化とは別のライブラリ（.jarファイル）にある場合は、抽象化を含む.jarファイルを再パッケージ化する必要はありません。これにより、複雑なシステムのメンテナンスを簡素化できます。

于 2011-12-03T23:54:07.850 に答える