> 機能A,Bを持っているクラスに機能Cを追加したクラスと、
> 機能Aのみを持っているクラスに機能Cを追加したクラス、
> というようように、機能を全て持ったクラスと、機能を限ったクラスというように、
> 作り分けたいのです。大に小を兼ねさせたくないというか。
機能と実装を分けるBridgeパターンに解決策のヒントがありそうです。
(詳しくは↓を見てください。)
http://itpro.nikkeibp.co.jp/article/COL ... 13/227227/
http://www.techscore.com/tech/DesignPattern/Bridge.html
http://www.hellohiro.com/pattern/bridge.htm
つまり、機能A,B,Cなどをインターフェイスで表現し、それを継承して具体的な処理内容を記述するクラス(実装側)と、インターフェイスを組み合わせて提供する機能を定義するクラス(機能側)に分けるといったイメージです。
(わかりづらいですねw。↑のサイトにあるクラス図の方がわかりやすいと思います。)
> もっとも、これはコード作成側の希望であって、
> 利用側にとっては大が小を兼ねていれば十分という気はします。
うーん…。利用側が使いやすいように、というのがオブジェクト指向の思想のようです。(と思っています)
あまりにも機能が多いと使うのも大変なので、利用側のメリットも無きにしもあらず、な気はしますが。
> う~む。見ていると、継承よりもインスタンスを生成する方が
> (この手法をコンポジションって呼ぶのですか?)好まれているみたいですね。
インスタンスを生成することではなく、「フィールドにインスタンスを持つ」ことがコンポジションであると理解してます。
オブジェクト指向のツボ ~Vol6. コンポジション~
インスタンスを生成するのは、「処理をほかのクラスに任せる」ということで委譲というみたいです。
またコンポジションのことをhas-a関連や集約と呼ぶこともあるようです。
> インターフェースの内容は分かりましたが・・・便利さがイマイチ実感できません^^;
> オーバーライドと同類っぽい?
> まぁ、そこは使っていく中で覚えるものだと思いますけど。
インターフェイスは継承元の中身がないだけでオーバーライドと変わりない仕組みですよね。
違いはインターフェイスを継承してオーバーライドすることは中身のないメソッドの処理の中身を作ることというわけで「実装」と呼ぶ程度のものです。
「便利さ」ですか…。
インターフェイスを使うとクラス間の結びつきが緩くなり、部品として再利用しやすくなるというのがメリットだといわれています。
こちらもまだまだ勉強不足で実践的にインターフェイスを使ったことはありません。
なのでプログラムとしての動作がわかる程度ですし、実際どのような場面で使うと効果的なのかといったことはわかりません。
とりあえずデザイン・パターンの理解がインターフェイスの理解の早道だと思っています。