EffectiveJava項目14について

Question

effectiveJava項目14のサンプルコードが理解できませんのでどなたかご教授いただけますでしょうか。

継承の代わりにコンポジションを使用するとなっていますが結局Set<E>インターフェースをFowardingSet<E>が
継承しInstrumentedSet<E>がFowardingSet<E>を継承しているという三層構造になっていて継承の代わりにコンポジションを使用するという目的が達成されているように見えません。

サンプルコードの構造が理解できないのでどなたか教えていただけると幸いです。

Comments

[退会済みユーザー]

どの版のEfect Java だろう・・ どの出版会社発行のエフェクトジャバだろう・・・・途中から　項目16になってるようだし

[退会済みユーザー]

見つけた。。。。初版本「2001/12/3」・・・

Answer 1

この件は、簡単に言えば、「責任の負えないクラスを直接継承するな」ということになります。
通常はHashSetのソースコードなんて誰も読んでないですよね。（私は読んでるという方には失礼）
まさかaddAll()のなかでadd()が呼ばれているなんて、、、（まあ予想はつきますが、、）
この内部仕様を知らずに、手軽にカウンターなんてつけちゃうと誤動作するわけです。
そこで、わが所有のインスタンス変数の制御権を取り戻すために、HashSetから切り離すのがこの事例なんです。
よく知らない人クラスに振り回され、原因不明なバグに悩まされるクラスと、完全制御下に置いたクラスとの比較になっています。

Comments

[退会済みユーザー]

どうも質問の内容のは大きく改定している模様

項目ーー（第三版 2018年出版：予定）
項目１６（第二版 2014年出版）
項目１４（第一版 2001年出版）：質問者参考、古い言語仕様

[Attsu]

すいません、項目16でした。申し訳ございません。

[anndonut]

私は訳本を以前持っていましたが、今は持っていませんでしたので、うろ覚えと経験で回答しただけです。しかしそのような理由があったとは。うん、パターンとアンチパターンに理由を求めるのはあまりよろしくないですね。ライブラリのクラスでもfinalになっているものがあると「こんちくしょー」とか思ったりするんですけど何かしらの理由があるということですね。

Answer 2

Effective Javaのソースコードらしきものを見ましたが、確かにコンポジションを使用していますね。

https://github.com/marhan/effective-java-examples/tree/master/src/main/java/org/effectivejava/examples/chapter04/item16

まず、FowardingSetはSetを継承ではなく、実装しています。
ForwardingSetはコンストラクタでSetインターフェースの実装インスタンスをもらってますよね。で、保持してますよね。これはコンポジションです。

コンポジションしないで継承するやり方は、ForwardingSetクラスがコンストラクタにSetインターフェースの実装インスタンスを引数として取らずに、HashSetクラスやInstrumentedHashSetクラスを継承することです。このことにより、ForwardingSetクラスは間接的にSetインターフェースを実装することにもなります。

しかし、そうすると、ForwardingSetクラスは余計なメソッドやフィールドをもらってしまう訳なのです。それはForwardingSetクラスが本来やりたかったことでなく、ForwardingSetクラスのドキュメントも長大化します。

ForwardingSetクラスがやりたいことはSetインターフェースを実装しているクラスについて、Setインターフェース以外のメソッドやフィールドを隠すことです。その上で、InstrumentedSetクラスはカウント機能を追加しています。

なんでそんなことをするかというと、Setインターフェースの実装にはいろいろ種類があって、速度やメモリ使用に関する特性が異なるためです。だから、Setインターフェースの実装が具体的にどれなのかについては、あえて言及していない訳です。

Comments

[退会済みユーザー]

最新原版では項目16であるものを項目14といってるから著しく中古書籍を譲り受けたか買ったひとみたいだねぇ・・・

[Attsu]

丁寧なご回答ありがとうございます。ForwardingSetクラスの役割が見えてきました。
重ねての質問申し訳ないのですがそもそもこんな二段構えにせずにInstrumentedSetクラスが直接Setインターフェースを実装してしまえばよいのではないかと思いました。何か理由があるのでしょうか。個人的には別の方法のAddメソッドを持つクラスがForwardingSetを継承するためとかかなと考えたりしています。

[anndonut]

はい、いいのではないでしょうか。しかしボトムアップな考え方ではそれが簡潔でも、トップダウンな考え方だと可説明的でなくなるときがあります。そもそもForwardingSetとはなんでしょうか。私にはわかりません。AbstructSetでもないですものね。ForwardingSetとInstrumentedSetというのが雑です。
うーん、decorationパターンなのかな。違う気もするな。
http://itpro.nikkeibp.co.jp/article/COLUMN/20060113/227227/

一つ言えることはSetインターフェースにはコンストラクタを実装できませんが、ForwardingSetクラスにはコンストラクタを実装することができるということです。

ぱちっ、コンポジションを使えばsuperで買い物をするひつようがないのか。しかしHashSetのaddAllでaddを呼び出すと、それを継承したクラスでカウント機能を付けた時にバグりますかね？カウントはInstrumentedSetクラスのaddメソッドとaddAllメソッドで行っているので、HashSetの実装がどうなっていようと、InstrumentedSetクラスのaddAllメソッドでダブルカウントすることはないと思うのです。ちょっと実装していないので何とも言えないですが、InstrumentedSetクラスのaddCountフィールドが汚されることはないと思います。ただ、protectedされたメソッドやフィールドなんかが絡んでくると頭が爆発してくるかもしれません。

オブジェクト指向は関数型に比べて難しいと思います。ボトムアップとトップダウンという考え方が合流してしまって収拾がついてない感じがあります。とりあえず、品のよいプログラミングを目指されることをお勧めします。