- 364 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:39:50 ]
- >>293の元設計の問題点 (つづき)
2-1. Bridgeパターン・スパゲティ (クラスの過剰分割によるOOモデルの崩壊)
>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
※1.createWoodCutPrint() の //{ ... //} 内は､下記の等価コード｡
WoodCutPrintContext.getInstance().doWoodCutPrint()
>>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
｢Coordinatorパターン｣とでも呼ぶべき｢変形Bridgeパターン｣を導入し、
Coordinatorで処理詳細の選択できるようにした。
(注:蛇足だがこの種のカスタマイズには、
古くから使われている DI (Dependency Injection)パターンの方が適している。
更に蛇足だが、カスタマイズ内容はコード中に直接記述したりはせずに、
外部ファイル(XML形式)に分離記述して後から変更可能にするのがマナーである。
このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
|
 |
