## 8-2 [[🗃️多態性(ポリモーフィズム)]]を設計する ### [[🗃️Template Methodパターン]] - [[🗃️多態性(ポリモーフィズム)]]に関連する、象徴的なパターン。 - ポイント - [[🗃️継承]]による[[🗃️差分プログラミング]]になる。 - 前の章では、安易な[[🗃️差分プログラミング]]は避けるべきだといっていたが？ - 共通性をくくりだした親クラスを設けているため、追加される派生クラスが予想外のものになる未来があまり予測できないため、[[🗃️継承]]を使ってもいいのではないか。 - 抽象の詳細ブレークダウンを物語っている。 - [[🗃️具象クラス]]は穴埋め形式の問題になる。 - [[🗃️抽象クラス]]が思考のフレームワークになる。毎回全体像から考え直す必要はなくなる。 - 注意 - 抽象となるクラスの定義をクライアントコードが直接利用するのは避けたほうがいい。 - 変更がある際は、子クラスの追加修正だけに閉じるようにしておく。 ### [[🗃️Bridgeパターン]] - 単一継承を前提とすると、継承ではバリエーション表現力として不完全であることを示しているのが、[[🗃️Bridgeパターン]]。 - [[🗃️Template Methodパターン]]は簡単なので、使いやすいが、表現できるのは、単一の継承のみ。 - 複数のバリエーションの組み合わせで[[🗃️多態性(ポリモーフィズム)]]を表現するパターン。 - 例 - 金賞、銀賞のInterface -> PrizeItemInterface - NG1: メダルと、カップの子クラスをPrizeItemInterfaceから[[🗃️継承]]する - 金色、銀色の色の実装部分が、メダル、カップのクラスで重複してしまう。 - NG: 2 金色アイテム、銀色アイテムという子クラスをPrizeItemInterfaceから[[🗃️継承]]する - メダルと、カップの実装部分が、重複してしまう。 - 共通した特徴を[[🗃️is-a関係]]ではなく、[[🗃️has-a関係]]で再検討する - PrizeItemInterfaceを継承したPrizeItemクラスを作る。 - PrizeItemクラスは、PrizeMaterial(金、銀)と、PrizeShape(形)のインスタンスをconstructorで依存注入する -> [[🗃️has-a関係]] - → 橋渡し役となる、クラスを作り、AとBの要素を依存注入