項目16 「継承よりコンポジションを選ぶ」

Effective Java 第2版 (The Java Series)

• 作者: Joshua Bloch
• 出版社/メーカー: ピアソンエデュケーション
• 発売日: 2008/11/27
• メディア: 単行本（ソフトカバー）

1990年代前半から中頃（？）までは、オブジェクト指向と言えば、継承というはやりがありました。特にC++ではインタフェースの概念が言語仕様上なく、すべてをクラスの継承で表現しなければなりませんでした。その結果、すべてを継承で設計し、いわゆる差分プログラミングが良いという考えもあったりしました。

項目16 「継承よりコンポジションを選ぶ」では、次のように述べられています。

メソッド呼び出しと異なり、継承はカプセル化を破ります[Snyder86] 。言い換えれば、サブクラス は適切に機能するために、スーパークラスの実装の詳細に依存します。スーパークラスの実装はリリー スごとに変更されるかもしれませんし、もし変更されたら、サブクラスはコードが一切変更されていな くても、機能しなくなるかもしれません。結果として、スーパークラスの作成者が特に拡張される目的 で設計および文書化を行っていない限り、サブクラスはスーパークラスと一緒に変わっていかなければ なりません。

そして、最後に次のようにまとめられています。

まとめると、継承は強力ですが、カプセル化を破ってしまうので問題があります。サブクラスとスーパークラス間に本当のサブタイプ関係がある場合にだけ、継承は適切です。そうであっても、サブクラ スがスーパークラスと異なるパッケージにあり、スーパークラスが拡張されるように設計されていなけ れば、継承はもろさへと結び付いてしまうかもしれません。このもろさを回避するためには、継承の代 わりに、コンポジションと転送を使用してください。特にラッパークラスを実装するための適切なイン タフェースが存在している場合にはそうです。ラッパークラスは、サブクラスより頑強なだけでなく、 より強力でもあります。

継承ベースで設計されているソフトウェアは、非常に可読性が低いものとなってしまったりします。さらに、単にサブクラスで共通だからと、処理をスーパークラスへ移動させたりすると、徐々にもろくなったりします。同様なことが荒井さんの書籍（p.83）にも述べられています。

ソフトウェア開発で伸びる人、伸びない人 【第二版】 (技評SE選書)

• 作者: 荒井 玲子
• 出版社/メーカー: 技術評論社
• 発売日: 2009/10/21
• メディア: 単行本（ソフトカバー）

オブジェクト指向分析設計は、抽象概念を強要します。本質を定義する抽象クラスと、複数箇所で使用されるユーティリティクラスを区別して扱うことで、システム品質に差をもたらします。いろいろなところで使われる処理ロジックをまとめて「共通クラス」としてスーパークラスにおいたりする設計をよく見かけますが、これなどは抽象クラスの定義の典型的な失敗例です。「共通クラス」は、単体でなにかの本質を表したクラスではないからです。