「【GoF】デザインパターン 6

質問です。
テンプレートメソッドパターンを適用しようとして気になったのですが、
ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？
（内容が同じになるものが複数組あります）
内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、
このままでは冗長です。

ぱっと思いつくのは、組ごとに共通のクラスを作っておいて
各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか？

使っているのはPHP5なので多重継承はできません。

age!

ConcreteClassのユーザーから見て、
その「処理が同一だけど異なるクラス」とやらは
「全く同じクラス」にしてはいけないものなの？

微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。

例えば、
http://www.techscore.com/tech/DesignPattern/TemplateMethod.html
ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に
public class TanakasWoodCutPrint extends WoodCutPrint{}
と
public class SuzukisWoodCutPrint extends WoodCutPrint{}
の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。

木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？

差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。
もう一階層挟んだら綺麗にまとまったりしないかとか。

メモリが必要になったときに一度だけ生成されて、それ以降の記述では
必ず最初に確保されたメモリが使われるようなパターンは何というの？

C++風に描けば

if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る
aを使った処理…

全部グローバル変数にすればいいんだろうけど、使わない領域は
確保したくないって時にやる（a が不要になったときは回収してもOK）

>>281
しんぐるとんだろ？

>281
Singleton

>>279
>>275で書いた共通クラスというのはそういうイメージなのですが、
タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？

>>280
symfonyでモデルクラスをＤＢスキーマから自動生成後、
各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。

っていうか、そのモデルは何を表してるモデルなのよ？
DBから生成されたものに後付で持たせたい機能って言う意味がわからん
モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな

なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。

>>280
まず、モデルの定義を明確にしろ。
・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、
・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。
後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。

次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。
版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、
cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。
具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。

ここで、テンプレートパターンを使う。
　　ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass
　　ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass
となるようにする。

もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、
同じConcreteStrategyクラスを生成して呼び出せば良い。
違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。

それだけの話ではないか

>>280ではなく>>275

symfonyってのをちらっと眺めた感じだと
＞・DBエンティティをそのまま表したクラス(状態)
どうもこっちみたいだから、
そもそも適用するレイヤを間違ってる説が有力。

ODBMS屋乙。

> そもそも適用するレイヤを間違ってる説が有力。

それは前提を勝手に仮定した偏った意見に見える。
>>275の話が
　・どのようなアプリケーション・アーキテクチャ〜レイヤ構成を前提としているか
　・一つのレイヤ限定の話なのか
　・複数のレイヤにまたがった話なのか
によって、いくらでも回答の仕方があるだろう。

例えば、
下のレイヤで、オブジェクトの静的状態をDBMSに格納し、
上のレイヤで、オブジェクトの振る舞いをどう扱うか
という問題を仮定した場合にも、
・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法
・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態
　を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法
の二通りが考えられる。

>>287は、後者の立場から説明した。

補足：
前者の立場でも
　　DBMSエンティティ＝静的状態＝ドメインオブジェクト　
と呼ぶことがあるが、
オブジェクト指向本来のドメインオブジェクトは、後者。

symfonyは一つのテーブルから二つのクラスを生成する。
テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる）
問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。
なのでそのクラスにそのデータを使うメソッドを書こうかと。

今、>>287の方法でやっていますがこれで良さそうです。
ありがとうございました。

エンティティとデータアクセスオブジェクトが自動生成ってことか
データアクセスはデータアクセスに特化させる方がいいだろねー
クラスの「役割」のくくりを大きくすれば、計算からデータの編集、保存まで一緒くたに
するって考え方もアルンかもしレンガ、普通はもっと細分化するもんだ。

public　WoodCutPrintContext{

　　　public void doWoodCutPrint(){

　　　　　　Coodinator coodinator = getCoodinator();

　　　　　　Hanzai hanzai = coodinator.getHanzai();

　　　　　　DrawProcessor drawProcessor = coodinator.getCutProcessor();
　　　　　　hanzai = drawProcessor.draw(hanzai);

　　　　　　CutProcessor cutProcessor = coodinator.getCutProcessor();
　　　　　　hanzai = cutProcessor.cut(hanzai);

　　　　　　PrintProcessor printProcessor = coodinator.getPrintProcessor();
　　　　　　printProcessor.print(hanzai);
　　　}
}

public 田中君 implements Coodinator {
　・・・
}

public 鈴木君 implements Coodinator {
　・・・
}

×；DrawProcessor drawProcessor = coodinator.getCutProcessor();
○：DrawProcessor drawProcessor = coodinator.getDrawProcessor();

w

>>293-294
> 　　　public void doWoodCutPrint(){

身元バレバレっすよ兄貴ぃ

閑話休題

他の言語、他のフレームワークを使っている人間に
余計なコメントをつけても混乱するだけだ。
もしアドバイスをつけたいなら、Javaではなく
PHP5+symfonyの例に即したアドバイスをしろ。

例えば、
・ データクラスの生成(検索、保存)
・ データクラスの処理(計算、処理)
はべき乗パターンに則って別クラスにすべきだ、などという説は
そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、
という観点で議論すべきである。

だが、俺はそこまで突っ込むつもりはない。
そんな事をいちいち調べるつもりはないし、
質問者も困惑するだけだからだ。

>>293
つか、今気付いた。
おまいは TemplateMethod Patternを共用したい
という質問に対して、全然別の回答をつけている。
特に、クラスの命名がデタラメだ。

×× public　WoodCutPrintContext{ ... }
×　　public class WoodCutPrintContext{ ... }
○　　public class WoodCutPrintProcess { ... }

----------------------------------------------------------------------------
デザインパターンにおける Contextの用例

1. Interpreterパターン
　 http://www.hellohiro.com/pattern/interpreter.htm
　 言語に対して、文法表現(Expressionクラス)と、
　 文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。
　 (注： Inerpreterクラスは付帯的に、言語の束縛〜副作用を表す評価環境(Context)を持つ)

2. Stateパターン
　 http://www.hellohiro.com/pattern/state.htm
　 オブジェクトの内部状態が変化したときに
　 オブジェクトの処理内容を変えられるようにする。
　 (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する)

----------------------------------------------------------------------------
>>293のクラス名 WoodCutPrintContext は、
クラスの役割を表現しておらず不適切な命名と言える。

----------------------------------------------------------------------------
デザインパターンにおける Contextの用例 【追加と訂正】

2. Stateパターン 【訂正】
　 × (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
　 ○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。　←【訂正】
　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する)

3. Strategyパターン 【追加】
　 http://www.hellohiro.com/pattern/strategy.htm
　 Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。
　 それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。
　 (注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。
　　　　 個々のアルゴリズムは、個別のConcreteStrategyクラス (〜A, 〜B, 〜C)に記述する。
　　　　 個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。)

----------------------------------------------------------------------------
もしかして >>293は、
　　鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、
　　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
と言いたかったのか？
だが、それでは
　・鈴木と田中が同じ手順(Strategy)で版画を彫る　
　・鈴木が田中の手を借りて版画を彫る
が全く同じ表現になってしまう。これは不適切だ。

↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。
「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。

■>>293の表現　「鈴木が田中の手を借りて版画を彫る」

/* >>293のコード　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 { // ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 鈴木君はコンテキストを使って版画を彫る。
　　// 注：　鈴木君のコンテキストには手配師へのコネがあり、
　　//　　　　手配師は、仕事の各工程をメンバーに適当に割り振る。
　　WoodCutPrintContext context
　　　= WoodCutPrintContext.getinstance();
　　// 鈴木君は、寄せ集めメンバーがバラバラに各工程を担当した
　　//　ツギハギ細工を、自分の成果として公開する。
　　return context.doWoodCutPrint();
　}
}

　　　　　　　↓

/* 「手配師が田中君しか集められなかった場合」の *
　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 {　// ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 田中君を拉致る
　　田中君 agent = 田中君.getInstance();
　　// 田中君に強制労働させ、成果を横取りして提出する。
　　return agent.createWoodCutPrint();
　}
}

■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」

public class 鈴木君 {
　// 鈴木君には版画を彫るスキルがある。
　public WoodCutPrintStrategy getWoodCutPrintStrategy() {
　　// 鈴木君のスキルは、一般にAと呼ばれるスキルである。
　　return WoodCutPrintConcreteStrategyA.getInstance();
　}
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　// 鈴木君は自分のスキルで版画を彫り、成果を提出する。
　　return getWoodCutPrintStrategy().doWoodCutPrint();
　}
}

>>300
バグを発見しますた。
鈴木君の一人プロジェクトが無限ループを起していて
いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ

/* 「手配師が鈴木君本人しか集められなかった場合」の *
　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/
public class 鈴木君 {　// ConcreteStrategy

　// 版画を彫る
　public Hanzai createWoodCutPrint() {

　　// 鈴木君が自分を拉致る
　　鈴木君 agent = 鈴木君.getInstance();

　　// 鈴木君はいつものようにメンバーに強制労働をさせて、
　　// 成果だけ横取りするつもりだったが、
　　// 結局自分一人では何もできずに
　　// 貯え(VMスタック)を消費しつくして終了
　　return agent.createWoodCutPrint(); // 無限ループで　throw RuntimeException("スタックオーバフロー")
　}
}

エロゲで使われているパターン

Singleton

他なんかある？

>>302
バグｽﾏｿ( ; -_-)
>>294版鈴木君の等価コードはこうだ。

public class 鈴木君 {　// ConcreteStrategy
　// 版画を彫る
　public Hanzai createWoodCutPrint() {
　　/* 以下、手配師付き変形TemplateMethod(ｺﾝﾃｷｽト)内の等価ｺｰﾄﾞ */ //{
　　　// 鈴木君は手配師を呼ぶ。(メンバー一人の場合、自分が手配師になる)
　　　Coordinator slave = this;
　　　// 手配師に各工程担当者を集めさせて、
　　　// 版材を準備し、版材処理を実行する。
　　　Hanzai hanzai
　　　　= slave.getCutProcessor().cut(
　　　　　　slave.getDrawProcessor().draw(
　　　　　　　slave.getHanzai()));
　　　// 版材を刷る。
　　　slave.getPrintProcessor().print(hanzai);
　　//}
　　return hanzai;
　}
　public Hanzai getHanzai() { reuturn new Hanzai(); }
　public 切り方 getCutProcessor()　 { return 切れ方_0893D.getInstance(); }
　public 書き方 getDrawProcessor() { return 書き方_1919Z.getInstance(); }
　public 刷り方 getPrintProcessor()　{ return 刷り方_0212A.getInstance(); }
}
// Functorパターン
public class 切り方_0893D extends 切り方 { public Hanzai cut(Hanzai hanzai) { /* 何もしない */ } }
public class 書き方_1919Z extends 書き方 { public Hanzai draw(Hanzai hanzai) { /* 何もしない */ } }
public class 刷り方_0212A extends 刷り方 { public Hanzai print(Hanzai hanzai) { /* 何もしない */ } }

まとめると、

>>275＝>>284の質問(>>292で解決済)
　テンプレートメソッドで、処理が同じものがある場合に、
　(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明)
　どのようなクラス設計をしたら良いか？
>>279-280、>>285-290の回答
　TemplateMethod単位で同じものがあったら、
　それをStrategyパターンで外出しして共用すれば良い。

※ここまではOK

>>293の回答
　TemplateMethodの個々のメソッド単位で同じものがあったら、
　それをStrategyパターンで外出しして共用すれば良い。

※>>293の実装コードは
　　ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割
　　Coordinatorインタフェースを割り付けている点がおかしい。
　　鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。

>>293の実装コードの問題点

分析/設計で得たモデルの特性として、
「手順を構成する複数の工程について、
　各工程の処理方法にバリエーションがあり、
　なおかつ、各処理方法は互いに交換可能」
な事が明らかならば、>>293の実装もありえる。

しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、
不吉な匂いがする。・・・数100人月のシステムで、
このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。

どのような場合にこの実装/設計が破綻するかと言うと、
設計/初期実装に見落としがあって、
Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合
である。この場合、Hanzaiインタフェースのバリエーションに関して、
各処理方法は互いに交換可能でなくなる。

正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは
なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ〜

デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。

プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、
その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。
・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、
　　開発もバッチグーね？とお気楽モード。

ところが開発展開になってから、
「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、
「異なる版画には、異なるサイズや材質の版材が必要」な事とか
「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」
ってな事にも、おそまきながら気付く。
　　　　　　　　　　　　　　　　　　　　　　　　アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ
・・・いや、気付いてても気付かないフリしたんだろう、
　　アーキテクチャ設計のボンクラ共は。

じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・
幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。
その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ
共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。

それでは、正しい解決方法はどこにあるのか
それを私は知っているが、このレスにはもう余白がないので書けないｗ

おまいら、俺の名前を気安く使うな、不愉快だぞ
続きは「佐藤クン」で

上がダメなら、下の名前ならおｋ？

例えばひろゆきとかゆきひろとかたかゆきとかあと

問題はドメイン・モデリングの欠落だなｗ

問題領域が「版画作成」なら、最終目的は「版画」だけど、
問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ〜よなｗ
つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話

「業務処理」の目的は、DB更新と電文(w。

>>312
それはありえん

>>309
それもダメだ、かすってる

鈴木の続きは「都築」でどうだ

>>314
じゃニックネームで手を打とうぜ。

例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ

>>309、>>315
　見事なまでのプロダクトラインだなｗ

閑話休題

>>312
ある種の基幹系業務システムは、
構築難易度を下げて抽象化すると、
結局、マスタメンテ型アプリに帰着する。

すると、最終目的がマスタ更新ってのも
そんなにずれていない。
するとオブジェクト指向で書く必要ないんだな、これが。

（終了）

)再開(

GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ

ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。

>>321
M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。

CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、
所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ）
ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ

そんな事じゃいかん。俺はCMU/SEIはともかくとして、
日本のCMMI連中とは全然話が合わないんだったｗ

なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆

>>322
特に無い。

>>320
確かに飽きてきたのも事実
だが使いこなせてる奴が意外と少ないのも事実

だが使いこなせてる奴は１０年前から退屈してるのも事実

2PLoP (2ch Pattern Language of Programming)報告：
Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、
まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。
彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。
トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、
Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。

　　　　　http://pc11.2ch.net/test/read.cgi/tech/1172431242/

糞コード放置してった >>293は
今どこで野垂れ死んでいることやら

>>326
Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。
大規模開発にはそもそも向いてないでしょ。
もしかしたら、オブジェクト指向すらいらないかもしれないし。
馬鹿にして言ってるのではなくて、住み分けがあるだろうと。
大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、
身近なユーティリティーを書くなら、軽量言語というか
perlででも書いた方がいいし。
大規模開発に向かん言語で、デザパタっていっても
そもそも意味がないと思うんだな。

>>328
常識的な意見ってツマンナイよ
rubyからrailが生まれたし、javascriptからAJAXが生まれた
そんなご時世なのだ

>>328
マジレスするぞ。
Pythonは関数言語的機能のほかに、
metaclassシステムやら、動的言語の性質をあちこち持ってるから、
C++やJavaよりよっぽどSmalltalk寄り。

そこにあろうことかJava版GoFを移植したってのが笑い所。

あと、後半部「ボトムアップでパターン抽出」
これは別に間違ってないだろ。
むしろ、将来Javaに取り入れるべき言語機能やパターンを
発見できるかもしれない(もう金脈は小さいと思うけどな)。

文句ばっか言って他をけなしてないで、
学ぶところは学びなさいってこったｗ

関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。
OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。
でも、Javaと同様なクラスライブラリ書き始めると、
あっちの方がよっぽど融通利いて手早く完成する。
さすが90年代のLispと呼ばれただけの事はあるな。

関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。
あれ一つでずいぶんJavascriptのコードが書きやすくなる。
問題はjavascriptエンジンのバグやエラー報告の不充分さ。
あれ使って10年程前にAJAX風アプリ書いてた時は、
試行運用中に山のように実行時エラーがでて閉口した。
今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら
万々歳なんだが。

パターン関係ないチラ裏ｽﾏｿ

>C++やJavaよりよっぽどSmalltalk寄り。

て言われても、Smalltalk てそんなにいいのか？
動的言語と言われた時点で、うーみとなりそうだけどなぁ。
型は、事前に論理的誤りを検出するためにあるんだぜ？
それを最初に省いたら、あとから泣きみるだろ。
それでデザパタが必要とされるような大規模開発に
向いてるといえるのだろうか？

> OOは大規模開発向け

だなんて地に足のついてない発言してる人が
まだ国内に居ると知って、ﾜﾛﾀ

済まないが、実績作ってから言ってくれ
おまいらの作ってるのはOOじゃねぇだろ
単にOO系言語でOOP風の事をしました（でも中身はCOBOLそっくり）
だろ

>>232
あぁーあ。今度はCS系関数言語厨房か。
マイクロソフトリサーチの人が
なんとかしてくれるだろ。

> デザパタが必要とされるような大規模開発

どっから出てきた妄想ですか？

すげぇずうずうしさだなコイツ

>>306-307, >>310-312, >>318で
大規模(自称)OO開発の失敗例
ケーススタディしたばっかだっつうのに、
解決策も出さずに「大規模OO開発」かよ。

なんだよ、Py厨だけじゃないのかよ。
てか、py厨が引っ掻き回してるのか？

ただな、デザパタなんてなくてもやれるし、あったらあったで
便利だし、ぐらいのところでいいだろ。

実際、それ以上でもそれ以下でもないし。

> 型は、事前に論理的誤りを検出するためにあるんだぜ？

そんなキミには、汎用純関数型言語Haskellを使って、
monadic programmingを駆使した通信ミドルウェア開発が
オヌヌメ。使用検証技術も必須だよ？jfitsの人がやってるような奴

大規模(自称)OO開発の失敗例 ケーススタディ　　>>306-307, >>310-312, >>318
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

に解決策提案するまで、
大規模OO開発へのデザインパターン適用の話題自粛で
お願いします。

何この盛り上がりようｗ

たかびー祭＋ﾋﾟﾁｮﾝﾊﾟﾀｰﾝ祭　合同イベント

おいおまいら騒ぐな

> 大規模OOにデザパタ必須
って言ってる人の大規模は、
せいぜい数千行〜数万行ぽっちの事だぞ、きっと

>>328

どうぞご自由に個人〜数人の範囲で
大規模開発しててくださいです。
いや、それくらいの規模が一番いいと思うよ。
がんばれー

火ぃ噴くのは、プログラムもろくにできないのが
数十人単位で集まっちゃうような地獄の話だからｗ

なんなんだよ、この盛り上がり。
そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の
素敵なコードの資産から、スマートなパターンを抽出して、
俺らをあっと言わせてくれよ。
もう、ずいぶん作業は進んでるんだろ？
ここで威張ってるぐらいなんだから。

>>344
/~ytakagi/ に直接言え。
もっとも連絡先も書いてねぇけどｗ

盛り上がってもいいけど、もっと具体的な話してくれ。
抽象論は聞き飽きた。

物凄いレス着いたｗ

>>295
PHP５＋symfonyなんてしらね

>>296-297
で座ﾊﾟﾀなんてクソ喰らえｗ

>>298
＞　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
＞と言いたかったのか？
その意味も含んでるけど
＞だが、それでは
＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　
＞　・鈴木が田中の手を借りて版画を彫る
＞が全く同じ表現になってしまう。これは不適切だ。
が意味不明。
どこをどうすれば鈴木君と田中君の接点が見えてくるのか？

>>300
勝手に解釈して話を進めないようにｗ

>>301-
目が疲れたから読めん

っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ

一体何を聞きたいんだ？

・ソフトウェア・プロダクトラインのための資産管理
・大規模開発へのOOおよびデザパタ適用の是非
・そのほか

とりあえず、>>293は
・話の発端(PHP5+symfony)も見えてないし
・クラス命名のセンスもないし
・クラス設計のセンスもないし
・等価コードの意味も理解できないし
・目が悪くて人の話も聞かない
奴である事だけはかろうじて理解できた

でなんか用かよタコ

> ＞だが、それでは
> ＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　
> ＞　・鈴木が田中の手を借りて版画を彫る
> ＞が全く同じ表現になってしまう。これは不適切だ。
> が意味不明。
> どこをどうすれば鈴木君と田中君の接点が見えてくるのか？

お前はシャレも解せぬ不粋な人間だと理解した

>　っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
>　ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ

はいはい釣れた釣れた

終わりか？
＞・クラス命名のセンスもないし
＞・クラス設計のセンスもないし
それは否定できんなｗ
ほいじゃーね

思い切り東陽町スタイルだな。あの糞コード

> public　WoodCutPrintContext{

単にソースコード保守するだけの
運用チームじゃないかな、彼は

>>293の元設計の問題点

1. 詳細設計〜実装の主眼を「コード再利用率の向上」に置いたのが誤り。
　 小手先のテクに走らず、分析〜設計段階で一貫したドメインモデルを用い、
　 それを素直にコード化して、保守性・拡張性を高める事こそ重要である。

2. 継承や委譲を駆使した「差分コードプログラミング」は煩雑過ぎて人間の手に余る。
　 もし本気で「差分コード」を扱いたいなら、アスペクト指向開発方法論(AOSD)を取り入れ、
　 差分定義の組み込みはAOP言語のweaving機能に任せろ。人間の手でやるな。
　 ・・・だが残念な事に、アスペクト指向言語はまだ底辺現場で使える段階にはない。

つづく

>>293から50レス以上あって
くだらない能書きは大量に吐き出されたが
もっと良い解決方法を提示するコードが出てこないとはｗ
所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなｗ
コリャデスマがなくならないわけだ

お前のコードの問題点は示しただろ？すずき

>>356
一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。

>>358
議論しているのをキチガイ呼ばわりする奴って
どこにでもわくのな

【ひろたかと２ちゃんの不思議な関係】

・ひろたかがかつて在籍していた会社は全て、ひろたかが去った直後に
　２ちゃんでしつこく攻撃される。

・ひろたかの元仕事相手、脳内ライバル、
　その他ひろたかが自分にとって脅威だと感じる対象は、
　２ちゃんのあちこちのスレに中傷文が書かれる。

・ひろたかが出没するスレには
　常に「キチガイ」「発狂」を連発する荒しが発生する。

・２ちゃんに居る頭も性格も悪い粘着に　　　　　　　　　　　　　　　← いまココ
　噛んで含めるように高度な概念を教えてやると、
　いつの間にかたかひろ本人も同じ意見を主張するようになるｗ

・ひろたかは論破されていても、それに気付かないフリをして勝利宣言をする。
・ひろたかは論破されると、他のスレで暴れる。
・ひろたかは成りすまし/匿名発言をよくするが、それが見破られると
　「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。

さ〜て、また荒しが発生するのかなｗ

>>358
そういわれるとちょっと寂しい気も・・・ｗ
>>357,359
議論になってな（ｒｙ
>>360
「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・ｗ

>>361
議論になっていないと考える低脳はお前だけだ

だってボク低脳ですから

>>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)は､その字面の単純さにもかかわらず､
　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)

くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は
「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。
マッピング後のクラス設計以前の問題。

んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。

うっせぇぞ低脳。

お前はさっさとODBMS営業逝ってこいや
負け犬が

ODBMS（ｗ

ぷぷぷ

もう10年前にたかひろの子分に
「(製造業など一部の特殊分野を除いては)
　仮想記憶方式のODBMSなんてもう売れねぇよ」
って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなｗ

そん時に提示した代替手段が、
・ ORマッピングによるRDBMSとの共存
・ Stonebreaker氏のORDBMSの発展
だったな。

>>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

　>>293のコード(及び>>304の補足コード)は､その字面の単純さにもかかわらず､
　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)

　(1)挙動を読み取りにくくなる原因：
　　原因(1-1) データと処理の分離記述による、カプセル化の破壊。
　(2)保守性が悪い原因：
　　原因(2-1) カスタマイズ内容のハードコーディング。
　　　　 クラス選択の変更や、クラスの新規追加の度に、コード修正が必要になる。
　(2)前提条件の変化に対し柔軟性が低くなる原因：
　　原因(3-1) モデルの過剰な単純化により、現実世界の複雑な問題に適応できなくなる。

　以下では、その原因を探る。
　原因(1-1)データと処理の再分離による､カプセル化の破壊
　　　　オブジェクト指向では､データとその処理をカプセル化し、クラスを導入する事で
　　　　(1)データ操作の局所性
　　　　(2)外部操作インタフェースの限定、
　　　　(3)型システムによる安全性/信頼性の向上
　　　　が可能になり、それを利用してプログラムの信頼性/可読性/保守性の向上を図れる。

　　　　しかし>>293,>>304のコードでは、
　　　　データ(Hanzai及びﾊﾞﾘｴｰｼｮﾝ)と処理方法(〜Processor)を別々のクラスに分離記述した後、
　　　　関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、
　　　　オブジェクト指向のメリットが得られなくなっている。(非ＯＯ的コード)

>>355、>>364、>>369
その問題点を直したスケルトンコードを頼む

>>365が僕の考えからは少し極端な意見だがいいこと言った。
まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに
とらわれないコードを書いたんだがね。
自分のレスの後だったんでよっぽど悔しかったんだろうｗ。
だが少しだけ付き合ってあげようｗ

＞　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
なりません。

＞　>>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
・・・・
＞　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
＞　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
カプセル化を否定しているように聞こえるが？

そもそも鈴木君や田中君をドメインとして（まぁドメイン領域内のある部分ではあるが）時点で設計が
崩壊してるんだけどｗ
>>278の要件を分析してみると、

１．このケースの主処理は木版が作成プロセスである。
２．鈴木君や田中君は木版画作成プロセスのバリエーションである。

この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの？
で、

３．木版画作成プロセスから見た場合、鈴木君や田中君（、山田君、佐藤君・・・・）の役割は、
　　木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。
４．鈴木君や（略）画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君（ry)と独立するべき。
　　（そもそもの>>275の要件）

となるのが自然な設計だと思うけど？

>>371
キチガイにかまわないであげてください。

>>372
むむ・・・
スレが荒れてしまいますな・・・
まぁ彼が言うクラス粒度が細かくなりすぎると見通しが悪くなるのは事実だけどね
その辺の加減が難しい・・・

　-- 引き続き、元質問者(>>275) の挙げた例題(>>278) を題材に､ --
　-- デスマ現場で発生した問題 (>>306-307) を論じる｡　　　　　　　--

>>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))

　原因(3-1)モデルや型の過度な単純化による、複雑な問題への適応能力低下。
　　　　現実の問題は、>>293のような単純な構造は持っていない。

　　　　まず、データにはバリエーションがある。
　　　　例えばデスマ事例(>>306-307)で指摘されているように、
　　　　操作対象となるオブジェクト/データ(Hanzai)は一種類ではなく、
　　　　実際には何種類ものバリエーションが存在する。(分析モデル)
　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　 │　　　　　　　　 │　　　 └ 硬い木版
　　　　　　　　　　 │　　　　　　　　 ├ ゴム版
　　　　　　　　　　 │　　　　　　　　 ├ 芋版
　　　　　　　　　　 │　　　　　　　　 └ 銅版
　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　 └ 完成した版画版
　　　　　※ ここでHanzaiのサブクラスは、
　　　　　　工程進行に伴う状態変化 (原料→下絵中→切除中→完成) と見なせる。
　　　　　　ただし、後工程になるほどデータの内部構造は複雑になっていく。
　　　　
　　　　次に、データはしばしば単純なモノシリック構造ではなく、
　　　　複数のデータを内部構造として持つComposite構造を持つ。
　　　　　完成した
　　　　　　版画版 ◇┬ 背景部 ◇─(略)
　　　　　(人物画)　　└人物部 ◇┬ 頭髪
　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目
　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻
　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口
　　　　　　　　　　　　　　　　　　　　├ 上着

　　　　当然のように、処理もこのComposite構造の対応している必要がある。
　　　　　人物画のゴム版画の為の
　　　　　切除処理 ◇┬ 背景部 ◇─(略)
　　　　　　　　　　　　　└人物部 ◇┬ 頭髪パターン切除
　　　　　　　　　　　　　　　　　　　　　├ 顔　 ◇┬ 目をリアリスティックに表現する切除
　　　　　　　　　　　　　　　　　　　　　│　　　　　├ 鼻の膨らみを表現する切除
　　　　　　　　　　　　　　　　　　　　　│　　　　　└ 口の生々しさを表現する切除
　　　　　　　　　　　　　　　　　　　　　├ 毛皮パターン切除

　　　　それでは、切除工程の操作は、作成対象データ(人物画)と同じComposite構造を持ち、
　　　　素材×Compositeの要素数分必要になるのか？

　　　　そんな事はない。
　　　　例えば、頭髪パターン切除と、毛皮パターン切除には同じ切除テクニックが使える。

　　　　これが現実世界の共用だ。

御託はいらん
読む気も無い

【そして、現実の世界へ・・・】

それではここで、精神性疾患患者たかひろの設計でデスマ化した
デスマ事例(>>306-307)に戻ろう。
途中から読んでいる方には何の事やらサッパリ判らないだろうから
説明を加えると。

>>293のコードは、精神性疾患患者たかひろが、その劣悪なる知能で設計し
その結果デスマを巻き起こしたコードと極めて類似している。
したがって、>>293の詳細な分析は、デスマ事例コードへの解決策を与えるのである。

いまごろ解決しても、お前の頭がおかしくなったのはもとには戻らん。
あきらめろ。

｢版画の世界｣から、｢デスマ・システム｣への概念マッピング（・∀・）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　 　【版画作成アプリ】　　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン] 版画作成プロセス　　　　　　　マスタ更新プロセス
[主要データ]　下絵、原料版材　　　　　　　　 入力 (画面入力,電文入力)
　　　　　　　　　完成した版画版　　　　　　　　出力 (ＤＢ更新,電文出力,)
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 (付帯的な画面出力)
[主要プロセス]版材取得　　　　　　　　　　　　入力取得
　　　　　　　　　下絵作成　　　　　　　　　　　　入力取得
　　　　　　　　　版材の品質チェック　　　　　　入力チェック
　　　　　　　　　下絵と切除テクのマッチング　業務チェック
　　　　　　　　　切除処理　　　　　　　　　　　　ＤＢ参照、演算処理、ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　出力処理 (画面出力,電文出力)

【たかひろと２ちゃんの不思議な関係】

・たかひろがかつて在籍していた会社は全て、たかひろが去った直後に
　２ちゃんでしつこく攻撃される。

・たかひろの元仕事相手、脳内ライバル、
　その他たかひろが自分にとって脅威だと感じる対象は、
　２ちゃんのあちこちのスレに中傷文が書かれる。

・たかひろが出没するスレには 　　　　　　　　　　　　　　　　← いまココ （・∀・）>>358, >>371, >>379
　常に「キチガイ」「発狂」を連発する荒しが発生する。

・２ちゃんに居る頭も性格も悪い粘着に　　　　　　　　　　　　　　　
　噛んで含めるように高度な概念を教えてやると、
　いつの間にかたかひろ本人も同じ意見を主張するようになるｗ

・たかひろは論破されていても、それに気付かないフリをして勝利宣言をする。
・たかひろは論破されると、他のスレで暴れる。
・たかひろは成りすまし/匿名発言をよくするが、それが見破られると
　「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。

さ〜て、まだ荒しを続けるつもりかな？

またたかひろが暴れてるな
　
　そう。お前自身の信仰は誰も問題にしていない。
　例え神の存在を否定する信仰だろうと、
　ここ日本では誰もメクジラなど立てない。
　
　お前が問題なのは、
　お前がお前自身の信仰を大切にしているのと同様に、
　他人も自身の信念や大切なものを抱えながら生きている
　という事を理解せずに、
　・他人の信念を批判しまくったり、
　・自分勝手で不合理な自己主張をおしつけたり、はたまた　

　　　匿名で　他人の名前を挙げて
　　　執拗な人格批判/いやがらせを繰り返している

　という事実にある。

　お前と正式に顔を合わせて以来もう数年経つが
　ある日突然ﾈｯﾄ上で名前を挙げて非難が開始され俺はとまどった。

　俺は匿名で非難を浴びるような生き方は、これまで一切していない。
　なのに、お前に会ってしばらくしてから突然攻撃が始まった。
　最初はお前の周辺に異常者が居て、俺を攻撃してるのかと思った。
　・・・でも結局お前がその異常者本人だと気付いた。
　お前しか知りえない情報、お前しか感じ得ない感情で
　キチガイじみた様相で攻撃してくる奴は、お前しかいないって。

　悔い改めよ。そしてお前が迷惑をかけた人、一人一人に許しを乞え。

荒しはスルーするとして。

>>380
その概念マッピングは、>>375-376 と多少ズレている。
マスタメンテ型システムってのは、
システム開発の都合で業務処理を極端なまでに単純化して、
　　　　業務処理アプリ＝DBテーブル編集アプリ
と見なすもんだ。

すると主要ドメインはあくまで業務処理プロセスであって、
マスタ更新プロセスではない。

>>379
たかひろ、お前が壊れているのは最初から知っている。
お前が壊れた設計をしていたのにも、１週間と待たずに気付いた。
当然の事ながら、問題の解決策もすぐに判った。

ただ、お前がお前自身の精神状態の異常さに気がつかずに、
多くの人々に多大な迷惑をかけ続けた経緯には、
さすがの俺も心が痛んだ。
だから、あえてお前の古傷を持ち出し、
お前の行動を是正しようとしているんだ。

謙虚になれ、たかひろ。
お前はお前が思っているのの１/１００も有能ではない。
単なる空っぽの本棚だ。お前の頭は

>>375の分析モデルがズレたので、再投稿
------------------------------------------------------------
　　　【版材の分析モデル】

　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　 └ 硬い木版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版
　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　　　 └ 完成した版画版
------------------------------------------------------------

あれ？まだずれてる。

>>375の分析モデル図差し替え
------------------------------------------------------------
　　　【版材の分析モデル】

　　　　　Hanzai ＜─┬ 原料Hanzai　＜─┬ 木版＜─┬ 柔かい木版
　　　　　　　　　　　　 │　　　　　　　　　　　 │　　　　　　└ 硬い木版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ ゴム版
　　　　　　　　　　　　 │　　　　　　　　　　　 ├ 芋版
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 銅版
　　　　　　　　　　　　 ├ 加工中Hanzai＜─┬ 下絵中Hanzai
　　　　　　　　　　　　 │　　　　　　　　　　　 └ 切除中Hanzai
　　　　　　　　　　　　 └ 完成した版画版
------------------------------------------------------------

>>383

「マスタメンテ型アプリ」設計が導入されたのは、
今回ではなく、何世代も前の電算機導入の頃の話だろう。
それ以来業務処理は「マスタメンテ型アプリ」に合わせて変形し成長した。

だから今さら「マスタメンテ型アプリ」抜きの業務処理プロセスなど
存在しない。

　　業務処理プロセス(の一部)　∝ マスタメンテ型アプリのプロセス

としても大きな咀嚼はないだろう。

もし、新システム提案の初期に業務分析の専門家が入り、
提案を新しい業務プロセス設計の形で詳細に残していたら・・・
そこから正確なドメイン・モデルを作成できるのかもしれない。

だが今時の新システム構築なんて、大抵中身はマイグレーション。
COBOLプログラマがプログラムの動きを日本語で説明して「設計書でござい」
なんて言い出すおバカな世界だからなぁ・・・

>>365
さて、そろそろORマッピングスレを爆撃に行くかｗ

バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

Ａ．> >>365が僕の考えからは少し極端な意見だがいいこと言った。

　　ＯＲマッピングの話は、>>275の前提条件のスコープ外。

　　議論に直接関係ない話を持ち込んで、議論を撹乱するのは
　　詐欺師の常套手段なので、みなさん気を付けるように。

　　また、もしＯＲマッピングに興味を持った人が居たら、
　　まずはデータベース板の該当スレを参照すると良い。

Ｂ．> ＞　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
　　> なりません。

　　これは自分で補足コードを書いて見れば簡単に確認できる。
　　結果は>>304 のようなコードになるはずだ。
　　 (但し>>364に説明してあるように、等価コード部 //{〜}// 内は >>364※1と読み替える)

　　確認作業はコーディング能力のある人にしか実行できないが、
　　それは致し方ない所だろう。

バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

Ｃ．> ＞　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
　　> ＞　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
　　> カプセル化を否定しているように聞こえるが？

　　はい、みなさん注目！！！
　　これが典型的な詐欺師の手口です。騙されないように。

　　元レス>>369は >>293-294のカプセル化破綻問題を指摘している。
　　自分の問題点を指摘された >>293は、逆上して事実と反対の事を言い出している。

１．システムの全体像が見えていない以上、
　　処理の動作主体をモデル化しておく必要がある。
　　ここで動作主体とは、「鈴木君」や「田中君」である。

２．動作主体が「鈴木君」や「田中君」であり、
　　プロセスは >>293の最初のクラス＝WoodCutPrintProcessクラスである。

バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。

なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。

１．> このケースの主処理は木版が作成プロセスである。

　　このケースでは、システムの全体像が見えていない以上、
　　処理の動作主体をモデル化しておく必要がある。

　　ここで動作主体とは、「鈴木君」や「田中君」である。

２．> 鈴木君や田中君は木版画作成プロセスのバリエーションである。

　　前述のように、動作主体が「鈴木君」や「田中君」であり、
　　プロセスは >>293の最初のクラス＝WoodCutPrintContextクラスである。

　　(なおこのクラスの名称 "WoodCutPrintContext"は、内容を適切に表していない。
　　 正しくは、"WoodCutPrintProcess"と命名するべきである。根拠は>>297 参照)

たかひろがバカなのは判ったから
とにかく sageを覚えろ

あらあら、よく見たらアイツ
またまた敗走宣言してるやん >>379

ﾜﾛｽ

>>380
GJ！

「版画作成プロセス」と「マスタメンテ・プロセス」は所詮は別物、
もともと厳密に１対１に対応するものではない。

そこで>>380の齟齬の悪そうな部分を若干修正してみた。
大きな変更点は｢版画作成プロセス｣でなく｢版画版作成プロセス｣とした点。

----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング part2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　 　【版画版作成アプリ】　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン]　　版画版作成プロセス　　　　　　　マスタメンテ・プロセス
[主要データ]　　　版材原料　　　　　　　　　　　　入力 (画面入力データ)
　　　　　　　　　下絵　　　　　　　　　　　　　　ＤＢ参照データ
　　　　　　　　　加工中の版画版 　
　　　　　　　　　完成状態の版画版　　　　　　　　出力 (ＤＢ更新データ)
　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ)
[主要プロセス]　　版材原料取得　　　　　　　　　　入力取得
　　　　　　　　　版材作成　　　　　　　　　　　　入力チェック
　　　　　　　　　下絵取得＆下絵処理　　　　　　　業務チェック, ＤＢ参照
　　　　　　　　　切除処理　　　　　　　　　　　　演算処理, ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　画面表示
----------------------------------------------------------------------
修正結果を見ると、両者の対応関係はそんなには悪くない。
むしろ、別物にしてはずいぶん良い対応関係を持っている、と言える。

----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング ver.2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　 　【版画版作成アプリ】　　　　　　　【マスタメンテ型基幹システム】
[主要ドメイン] 版画版作成プロセス　　　　　　 マスタメンテ・プロセス
[主要データ]　 版材原料　　　　　　　　　　　　　入力 (画面入力データ)
　　　　　　　　　下絵　　　　　　　　　　　　　　　　ＤＢ参照データ
　　　　　　　　　加工中の版画版 　
　　　　　　　　　完成状態の版画版　　　　　　　出力 (ＤＢ更新データ)
　　　　　　　　　刷り上がった版画　　　　　　　　表示 (画面表示データ)
[主要プロセス]版材原料取得　　　　　　　　　　入力取得
　　　　　　　　　版材作成　　　　　　　　　　　　　入力チェック
　　　　　　　　　下絵取得＆下絵処理　　　　　　業務チェック, ＤＢ参照
　　　　　　　　　切除処理　　　　　　　　　　　　　演算処理, ＤＢ更新
　　　　　　　　　印刷処理　　　　　　　　　　　　　画面表示
----------------------------------------------------------------------

ある意味すごいなｗ
未だにコードが出てこないし解釈間違ってるけど、このエネルギーはスゴイ。
便所の１００ｗと比喩してはいけないｗ

スマソ　誤爆した

まあまあ
元々の質問はもうとっくにクローズしてるし、
>>293はjavaとよく似た擬似コードで記述されたクラス設計に過ぎんから、
代替コードを示す必要もない。

現在議論されているのは、>>293の背景にある設計理念の問題、
そして、それに類する設計を現実に適用した時のギャップね解決方法だろ。

理解できないなら結論が出るまで静観するがよろし