んーー TemplateMethodPattern は乱用されがちな気がするなあ
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
Template Method Patternを使いたくなったときは一度引いて見てちゃんと解放閉鎖原則を満たすかどうかを考えて見てもたぶん損はないと思う
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
Template Method Patternは「継承で実装を再利用する」系のパターンなんで、密結合を産みがちですよね。フレームワークを実装するときにはすごくマッチするパターンなんだけど、アプリケーションコードで使いたくなったときには「ちょっとまてよ、これらはほんとうに"同じ処理"かな？」って考えたい
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
「変更する理由が異なる二つのクラス」の実装を共有したいがための Template Method Pattern はよくなくて、というのは「変更する理由が異なる二つのクラス」は別々に変化していき、そのときに「共通の親クラス」は足かせになる
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
じゃあどうするか、と考えたら、「継承よりも移譲」の精神で、同じ処理があったらそこを別クラスに任せてしまって移譲で再利用を実現するほうが筋が良い場合が多いのではないか
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
なんか普通に「継承で実装を再利用しようとすると事故りやすいよ」「移譲のほうがいい場合が多いよ」っていう話に落ち着いてしまった感がある
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
逆にじゃあどういうときにTemplate Method Patternを使うのがいいかと考えたら、様々なユースケースにとって共通の横断的関心としての前処理/後処理がある場合とかなのかな。たぶんマッチするケースとしてはユースケースレベルの抽象度のレイヤーになりそう
— しんぺい a.k.a. 猫型蓄音機 (@shinpei0213) 2019年1月11日
