Head Firstデザインパターン 第2版 ―頭とからだで覚えるデザインパターンの基本

あなたがジョーの立場ならどうする？

 すべてのサブクラスが飛ぶ振る舞いや鳴き声をあげる振る舞いを持つべきではない

ことがわかっているので、継承は正しい解決策ではありません。しかし、サブクラスに

Flyable

や

Quackable

インタフェースを実装しても、問題は一部しか解決しません（ゴム

のアヒルが飛ぶことはなくなります）。これらの振る舞いに対してコードを全く再利用

できなくなるので、保守に関する別の悪夢が生じることになります。そしてもちろん、

飛ぶことのできるカモに関しても、飛ぶ振る舞いの種類が複数あるかもしれません。

 ここで、デザインパターンが白馬に乗って登場し窮地を救ってくれるのを待ってい

るかもしれません。しかし、それで面白いでしょうか？

いいえ、ここでは旧来のやり

方である適切なOOソフトウェア設計原則を適用するという方法で解決策を探しましょ

う。

これはまあ、 最も

愚かな思いつきね。「重複コー

ド」と言えるんじゃない。

2

、

3

個の

メソッドをオーバーライドしなければいけ

ないのがよくないと思うのなら、48 個の

飛ぶことのできるDuck サブクラス全部

の飛ぶ振る舞いを少し変更しなきゃいけ

ないときにはどう感じるの？

ソフトウェアの変更が必要な場合で

も、既存コードに最小限の影響しか与

えずに変更できるような、ソフトウェ

アの構築方法があれば夢のようだと思

わない？

そうすれば、コードの修正に

あまり時間をかけずにすみ、プログラ

ムを高機能にすることにもっと時間を

費やせるのに。

1

章 デザインパターン入門

you are ...