継承よりコンポジションを
継承はカプセル化を破る(???)
- サブクラスはスーパークラスの実装に依存する
- スーパークラスの実装が変わればサブクラスが破壊されるかもしれない
- スーパークラスが継承されることを前提に設計されていない場合、リリース毎にスーパークラスの実装を確認してサブクラスの実装を修正する必要がある
- だるい
次のリリースでスーパークラスに新しいメソッドが増える可能性がある
- プログラムは、(すべてのエレメントは、[いくつかの述語を満たすいくつかのコレクション]に挿入されるという事実に基づいたセキュリティ)に依存する、と考えなさい???????????
- とりあえずスーパークラスのメソッドがスーパークラスの違うメソッドを呼び出してるかも的な
- スーパークラスのメソッドをオーバーライドしなければいいんじゃないっすか
- スーパークラスに新しく追加されたメソッドがサブクラスのメソッドとシグネチャ被ってたらやばくね
- 戻り値違ったらコンパイルできないしたまたま同じだったとしてもちゃんと動くかあやしくね
コンポジション
- 継承の代わりに拡張したいクラスをフィールドにもってるクラスつくればいいんじゃね
- 普通にクラス使ってるだけだし拡張元の実装どうなってるかとか関係ないじゃん???
- 拡張元のクラスにメソッド増えても関係ないじゃん???
ラッパークラスの欠点
- コールバックフレームワークを使ってると適さない
- SELF問題のため(これわかんねえ)
コールバックてなんだ
Javaでいうと処理を持っているインスタンスのこと?
そいつを引数として渡す→受け取ったメソッドが処理を実行する的な?
Java コールバック関数 | Ruby CShrap JavaScript – WEBYA.IN
コールバック関数とは|「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
【Java】interface を使って簡単なコールバック機能を作る - ヽ|∵|ゝ(Fantom) の 開発blog?
継承が適切なのはサブクラスが本当にスーパークラスのサブタイプである場合だけ
- is a関係の時だけ
- Aクラスの拡張としてBクラスを作る場合に、Bが常にAであるかどうか考えてから拡張するべき
Predicate(述語)とはなんぞや - おっぱい大魔神の日記
まとめ
- 最初っから継承を前提としてデザインされたクラスでない場合は継承よりもコンポジションを(雑?)
- SELF問題わからん