07/03/31 15:13:25
>>365が僕の考えからは少し極端な意見だがいいこと言った。
まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに
とらわれないコードを書いたんだがね。
自分のレスの後だったんでよっぽど悔しかったんだろうｗ。
だが少しだけ付き合ってあげようｗ
＞ >>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
なりません。
＞ >>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
・・・・
＞ このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
＞ 挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
カプセル化を否定しているように聞こえるが？
そもそも鈴木君や田中君をドメインとして（まぁドメイン領域内のある部分ではあるが）時点で設計が
崩壊してるんだけどｗ
>>278の要件を分析してみると、
１．このケースの主処理は木版が作成プロセスである。
２．鈴木君や田中君は木版画作成プロセスのバリエーションである。
この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの？
で、
３．木版画作成プロセスから見た場合、鈴木君や田中君（、山田君、佐藤君・・・・）の役割は、
木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。
４．鈴木君や（略）画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君（ry)と独立するべき。
（そもそもの>>275の要件）
となるのが自然な設計だと思うけど？