07/03/26 22:00:25
木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？
280:デフォルトの名無しさん
07/03/26 22:44:58
差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。
もう一階層挟んだら綺麗にまとまったりしないかとか。
281:デフォルトの名無しさん
07/03/26 23:44:55
メモリが必要になったときに一度だけ生成されて、それ以降の記述では
必ず最初に確保されたメモリが使われるようなパターンは何というの？
C++風に描けば
if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る
aを使った処理…
全部グローバル変数にすればいいんだろうけど、使わない領域は
確保したくないって時にやる（a が不要になったときは回収してもOK）
282:デフォルトの名無しさん
07/03/26 23:46:53
>>281
しんぐるとんだろ？
283:デフォルトの名無しさん
07/03/26 23:49:00
>281
Singleton
284:275
07/03/27 12:17:40
>>279
>>275で書いた共通クラスというのはそういうイメージなのですが、
タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？
>>280
symfonyでモデルクラスをＤＢスキーマから自動生成後、
各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。
285:デフォルトの名無しさん
07/03/27 22:52:26
っていうか、そのモデルは何を表してるモデルなのよ？
DBから生成されたものに後付で持たせたい機能って言う意味がわからん
モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな
286:デフォルトの名無しさん
07/03/27 23:18:27
なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。
287:デフォルトの名無しさん
07/03/28 07:29:58
>>280
まず、モデルの定義を明確にしろ。
・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、
・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。
後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。
次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。
版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、
cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。
具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。
ここで、テンプレートパターンを使う。
ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass
ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass
となるようにする。
もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、
同じConcreteStrategyクラスを生成して呼び出せば良い。
違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。
それだけの話ではないか
288:２８７
07/03/28 07:36:24
>>280ではなく>>275
289:デフォルトの名無しさん
07/03/28 10:14:53
symfonyってのをちらっと眺めた感じだと
＞・DBエンティティをそのまま表したクラス(状態)
どうもこっちみたいだから、
そもそも適用するレイヤを間違ってる説が有力。
290:デフォルトの名無しさん
07/03/28 10:51:39
ODBMS屋乙。
> そもそも適用するレイヤを間違ってる説が有力。
それは前提を勝手に仮定した偏った意見に見える。
>>275の話が
・どのようなアプリケーション・アーキテクチャ～レイヤ構成を前提としているか
・一つのレイヤ限定の話なのか
・複数のレイヤにまたがった話なのか
によって、いくらでも回答の仕方があるだろう。
例えば、
下のレイヤで、オブジェクトの静的状態をDBMSに格納し、
上のレイヤで、オブジェクトの振る舞いをどう扱うか
という問題を仮定した場合にも、
・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法
・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態
を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法
の二通りが考えられる。
>>287は、後者の立場から説明した。
291:デフォルトの名無しさん
07/03/28 10:58:15
補足：
前者の立場でも
DBMSエンティティ＝静的状態＝ドメインオブジェクト
と呼ぶことがあるが、
オブジェクト指向本来のドメインオブジェクトは、後者。
292:275
07/03/28 12:42:19
symfonyは一つのテーブルから二つのクラスを生成する。
テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる）
問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。
なのでそのクラスにそのデータを使うメソッドを書こうかと。
今、>>287の方法でやっていますがこれで良さそうです。
ありがとうございました。
293:デフォルトの名無しさん
07/03/29 00:31:09
エンティティとデータアクセスオブジェクトが自動生成ってことか
データアクセスはデータアクセスに特化させる方がいいだろねー
クラスの「役割」のくくりを大きくすれば、計算からデータの編集、保存まで一緒くたに
するって考え方もアルンかもしレンガ、普通はもっと細分化するもんだ。
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 {
・・・
}
294:デフォルトの名無しさん
07/03/29 00:34:25
×；DrawProcessor drawProcessor = coodinator.getCutProcessor();
○：DrawProcessor drawProcessor = coodinator.getDrawProcessor();
w
295:デフォルトの名無しさん
07/03/29 12:59:19
>>293-294
> public void doWoodCutPrint(){
身元バレバレっすよ兄貴ぃ
閑話休題
他の言語、他のフレームワークを使っている人間に
余計なコメントをつけても混乱するだけだ。
もしアドバイスをつけたいなら、Javaではなく
PHP5+symfonyの例に即したアドバイスをしろ。
例えば、
・ データクラスの生成(検索、保存)
・ データクラスの処理(計算、処理)
はべき乗パターンに則って別クラスにすべきだ、などという説は
そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、
という観点で議論すべきである。
だが、俺はそこまで突っ込むつもりはない。
そんな事をいちいち調べるつもりはないし、
質問者も困惑するだけだからだ。
296:デフォルトの名無しさん
07/03/29 13:11:21
>>293
つか、今気付いた。
おまいは TemplateMethod Patternを共用したい
という質問に対して、全然別の回答をつけている。
特に、クラスの命名がデタラメだ。
×× public WoodCutPrintContext{ ... }
× public class WoodCutPrintContext{ ... }
○ public class WoodCutPrintProcess { ... }
297:デフォルトの名無しさん
07/03/29 14:58:49
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例
1. Interpreterパターン
URLﾘﾝｸ(www.hellohiro.com)
言語に対して、文法表現(Expressionクラス)と、
文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。
(注： Inerpreterクラスは付帯的に、言語の束縛～副作用を表す評価環境(Context)を持つ)
2. Stateパターン
URLﾘﾝｸ(www.hellohiro.com)
オブジェクトの内部状態が変化したときに
オブジェクトの処理内容を変えられるようにする。
(注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
----------------------------------------------------------------------------
>>293のクラス名 WoodCutPrintContext は、
クラスの役割を表現しておらず不適切な命名と言える。
298:デフォルトの名無しさん
07/03/29 15:32:52
----------------------------------------------------------------------------
デザインパターンにおける Contextの用例 【追加と訂正】
2. Stateパターン 【訂正】
× (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。 ←【訂正】
個々の内部状態とその処理内容をConcreteStateクラスとして実装する)
3. Strategyパターン 【追加】
URLﾘﾝｸ(www.hellohiro.com)
Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。
それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。
(注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。
個々のアルゴリズムは、個別のConcreteStrategyクラス (～A, ～B, ～C)に記述する。
個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。)
----------------------------------------------------------------------------
もしかして >>293は、
鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、
WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
と言いたかったのか？
だが、それでは
・鈴木と田中が同じ手順(Strategy)で版画を彫る
・鈴木が田中の手を借りて版画を彫る
が全く同じ表現になってしまう。これは不適切だ。
299:デフォルトの名無しさん
07/03/29 16:59:49
↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。
「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。
300:デフォルトの名無しさん
07/03/29 17:43:29
■>>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();
}
}
301:デフォルトの名無しさん
07/03/29 17:44:38
■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」
public class 鈴木君 {
// 鈴木君には版画を彫るスキルがある。
public WoodCutPrintStrategy getWoodCutPrintStrategy() {
// 鈴木君のスキルは、一般にAと呼ばれるスキルである。
return WoodCutPrintConcreteStrategyA.getInstance();
}
// 版画を彫る
public Hanzai createWoodCutPrint() {
// 鈴木君は自分のスキルで版画を彫り、成果を提出する。
return getWoodCutPrintStrategy().doWoodCutPrint();
}
}
302:デフォルトの名無しさん
07/03/29 18:00:19
>>300
バグを発見しますた。
鈴木君の一人プロジェクトが無限ループを起していて
いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ
/* 「手配師が鈴木君本人しか集められなかった場合」の *
* 等価コード */
public class 鈴木君 { // ConcreteStrategy
// 版画を彫る
public Hanzai createWoodCutPrint() {
// 鈴木君が自分を拉致る
鈴木君 agent = 鈴木君.getInstance();
// 鈴木君はいつものようにメンバーに強制労働をさせて、
// 成果だけ横取りするつもりだったが、
// 結局自分一人では何もできずに
// 貯え(VMスタック)を消費しつくして終了
return agent.createWoodCutPrint(); // 無限ループで throw RuntimeException("スタックオーバフロー")
}
}
303:デフォルトの名無しさん
07/03/29 18:38:56
エロゲで使われているパターン
Singleton
他なんかある？
304:300
07/03/29 18:52:15
>>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) { /* 何もしない */ } }
305:デフォルトの名無しさん
07/03/29 19:46:45
まとめると、
>>275＝>>284の質問(>>292で解決済)
テンプレートメソッドで、処理が同じものがある場合に、
(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明)
どのようなクラス設計をしたら良いか？
>>279-280、>>285-290の回答
TemplateMethod単位で同じものがあったら、
それをStrategyパターンで外出しして共用すれば良い。
※ここまではOK
>>293の回答
TemplateMethodの個々のメソッド単位で同じものがあったら、
それをStrategyパターンで外出しして共用すれば良い。
※>>293の実装コードは
ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割
Coordinatorインタフェースを割り付けている点がおかしい。
鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。
306:305
07/03/29 19:47:36
>>293の実装コードの問題点
分析/設計で得たモデルの特性として、
「手順を構成する複数の工程について、
各工程の処理方法にバリエーションがあり、
なおかつ、各処理方法は互いに交換可能」
な事が明らかならば、>>293の実装もありえる。
しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、
不吉な匂いがする。・・・数100人月のシステムで、
このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。
どのような場合にこの実装/設計が破綻するかと言うと、
設計/初期実装に見落としがあって、
Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合
である。この場合、Hanzaiインタフェースのバリエーションに関して、
各処理方法は互いに交換可能でなくなる。
正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは
なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ～
307:デフォルトの名無しさん
07/03/29 20:14:36
デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。
プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、
その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。
・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、
開発もバッチグーね？とお気楽モード。
ところが開発展開になってから、
「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、
「異なる版画には、異なるサイズや材質の版材が必要」な事とか
「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」
ってな事にも、おそまきながら気付く。
アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ
・・・いや、気付いてても気付かないフリしたんだろう、
アーキテクチャ設計のボンクラ共は。
じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・
幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。
その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ
共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。
それでは、正しい解決方法はどこにあるのか
それを私は知っているが、このレスにはもう余白がないので書けないｗ
308:鈴木
07/03/29 22:31:38
おまいら、俺の名前を気安く使うな、不愉快だぞ
続きは「佐藤クン」で
309:デフォルトの名無しさん
07/03/29 22:37:17
上がダメなら、下の名前ならおｋ？
例えばひろゆきとかゆきひろとかたかゆきとかあと
310:デフォルトの名無しさん
07/03/29 22:49:30
問題はドメイン・モデリングの欠落だなｗ
311:デフォルトの名無しさん
07/03/29 22:55:01
問題領域が「版画作成」なら、最終目的は「版画」だけど、
問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ～よなｗ
つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話
312:デフォルトの名無しさん
07/03/29 22:57:26
「業務処理」の目的は、DB更新と電文(w。
313:デフォルトの名無しさん
07/03/29 22:58:09
>>312
それはありえん
314:鈴木
07/03/29 22:59:24
>>309
それもダメだ、かすってる
鈴木の続きは「都築」でどうだ
315:デフォルトの名無しさん
07/03/29 23:03:13
>>314
じゃニックネームで手を打とうぜ。
例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ
316:デフォルトの名無しさん
07/03/29 23:05:28
>>309、>>315
見事なまでのプロダクトラインだなｗ
317:デフォルトの名無しさん
07/03/29 23:07:17
閑話休題
318:デフォルトの名無しさん
07/03/29 23:10:48
>>312
ある種の基幹系業務システムは、
構築難易度を下げて抽象化すると、
結局、マスタメンテ型アプリに帰着する。
すると、最終目的がマスタ更新ってのも
そんなにずれていない。
するとオブジェクト指向で書く必要ないんだな、これが。
（終了）
319:デフォルトの名無しさん
07/03/29 23:13:24
)再開(
320:デフォルトの名無しさん
07/03/29 23:17:09
GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ
321:デフォルトの名無しさん
07/03/29 23:17:18
ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。
322:デフォルトの名無しさん
07/03/29 23:22:56
>>321
M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。
CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、
所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ）
ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ
そんな事じゃいかん。俺はCMU/SEIはともかくとして、
日本のCMMI連中とは全然話が合わないんだったｗ
なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆
323:デフォルトの名無しさん
07/03/29 23:29:25
>>322
特に無い。
324:デフォルトの名無しさん
07/03/29 23:38:44
>>320
確かに飽きてきたのも事実
だが使いこなせてる奴が意外と少ないのも事実
325:デフォルトの名無しさん
07/03/29 23:45:29
だが使いこなせてる奴は１０年前から退屈してるのも事実
326:デフォルトの名無しさん
07/03/29 23:49:47
2PLoP (2ch Pattern Language of Programming)報告：
Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、
まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。
彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。
トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、
Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。
ｽﾚﾘﾝｸ(tech板)
327:デフォルトの名無しさん
07/03/29 23:56:05
糞コード放置してった >>293は
今どこで野垂れ死んでいることやら
328:デフォルトの名無しさん
07/03/30 00:05:24
>>326
Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。
大規模開発にはそもそも向いてないでしょ。
もしかしたら、オブジェクト指向すらいらないかもしれないし。
馬鹿にして言ってるのではなくて、住み分けがあるだろうと。
大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、
身近なユーティリティーを書くなら、軽量言語というか
perlででも書いた方がいいし。
大規模開発に向かん言語で、デザパタっていっても
そもそも意味がないと思うんだな。
329:デフォルトの名無しさん
07/03/30 00:14:09
>>328
常識的な意見ってツマンナイよ
rubyからrailが生まれたし、javascriptからAJAXが生まれた
そんなご時世なのだ
330:デフォルトの名無しさん
07/03/30 00:18:07
>>328
マジレスするぞ。
Pythonは関数言語的機能のほかに、
metaclassシステムやら、動的言語の性質をあちこち持ってるから、
C++やJavaよりよっぽどSmalltalk寄り。
そこにあろうことかJava版GoFを移植したってのが笑い所。
あと、後半部「ボトムアップでパターン抽出」
これは別に間違ってないだろ。
むしろ、将来Javaに取り入れるべき言語機能やパターンを
発見できるかもしれない(もう金脈は小さいと思うけどな)。
文句ばっか言って他をけなしてないで、
学ぶところは学びなさいってこったｗ
331:デフォルトの名無しさん
07/03/30 00:24:32
関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。
OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。
でも、Javaと同様なクラスライブラリ書き始めると、
あっちの方がよっぽど融通利いて手早く完成する。
さすが90年代のLispと呼ばれただけの事はあるな。
関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。
あれ一つでずいぶんJavascriptのコードが書きやすくなる。
問題はjavascriptエンジンのバグやエラー報告の不充分さ。
あれ使って10年程前にAJAX風アプリ書いてた時は、
試行運用中に山のように実行時エラーがでて閉口した。
今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら
万々歳なんだが。
パターン関係ないチラ裏ｽﾏｿ
332:デフォルトの名無しさん
07/03/30 00:26:57
>C++やJavaよりよっぽどSmalltalk寄り。
て言われても、Smalltalk てそんなにいいのか？
動的言語と言われた時点で、うーみとなりそうだけどなぁ。
型は、事前に論理的誤りを検出するためにあるんだぜ？
それを最初に省いたら、あとから泣きみるだろ。
それでデザパタが必要とされるような大規模開発に
向いてるといえるのだろうか？
333:デフォルトの名無しさん
07/03/30 00:27:09
> OOは大規模開発向け
だなんて地に足のついてない発言してる人が
まだ国内に居ると知って、ﾜﾛﾀ
済まないが、実績作ってから言ってくれ
おまいらの作ってるのはOOじゃねぇだろ
単にOO系言語でOOP風の事をしました（でも中身はCOBOLそっくり）
だろ
334:デフォルトの名無しさん
07/03/30 00:28:45
>>232
あぁーあ。今度はCS系関数言語厨房か。
マイクロソフトリサーチの人が
なんとかしてくれるだろ。
335:デフォルトの名無しさん
07/03/30 00:29:28
> デザパタが必要とされるような大規模開発
どっから出てきた妄想ですか？
336:デフォルトの名無しさん
07/03/30 00:31:22
すげぇずうずうしさだなコイツ
>>306-307, >>310-312, >>318で
大規模(自称)OO開発の失敗例
ケーススタディしたばっかだっつうのに、
解決策も出さずに「大規模OO開発」かよ。
337:デフォルトの名無しさん
07/03/30 00:32:59
なんだよ、Py厨だけじゃないのかよ。
てか、py厨が引っ掻き回してるのか？
ただな、デザパタなんてなくてもやれるし、あったらあったで
便利だし、ぐらいのところでいいだろ。
実際、それ以上でもそれ以下でもないし。
338:デフォルトの名無しさん
07/03/30 00:33:59
> 型は、事前に論理的誤りを検出するためにあるんだぜ？
そんなキミには、汎用純関数型言語Haskellを使って、
monadic programmingを駆使した通信ミドルウェア開発が
オヌヌメ。使用検証技術も必須だよ？jfitsの人がやってるような奴
339:デフォルトの名無しさん
07/03/30 00:36:05
大規模(自称)OO開発の失敗例 ケーススタディ >>306-307, >>310-312, >>318
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
に解決策提案するまで、
大規模OO開発へのデザインパターン適用の話題自粛で
お願いします。
340:デフォルトの名無しさん
07/03/30 00:36:10
何この盛り上がりようｗ
341:デフォルトの名無しさん
07/03/30 00:37:31
たかびー祭＋ﾋﾟﾁｮﾝﾊﾟﾀｰﾝ祭 合同イベント
342:デフォルトの名無しさん
07/03/30 00:40:04
おいおまいら騒ぐな
> 大規模OOにデザパタ必須
って言ってる人の大規模は、
せいぜい数千行～数万行ぽっちの事だぞ、きっと
343:333=336
07/03/30 00:42:56
>>328
どうぞご自由に個人～数人の範囲で
大規模開発しててくださいです。
いや、それくらいの規模が一番いいと思うよ。
がんばれー
火ぃ噴くのは、プログラムもろくにできないのが
数十人単位で集まっちゃうような地獄の話だからｗ
344:デフォルトの名無しさん
07/03/30 00:44:49
なんなんだよ、この盛り上がり。
そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の
素敵なコードの資産から、スマートなパターンを抽出して、
俺らをあっと言わせてくれよ。
もう、ずいぶん作業は進んでるんだろ？
ここで威張ってるぐらいなんだから。
345:デフォルトの名無しさん
07/03/30 00:46:34
>>344
/~ytakagi/ に直接言え。
もっとも連絡先も書いてねぇけどｗ
346:デフォルトの名無しさん
07/03/30 00:48:29
盛り上がってもいいけど、もっと具体的な話してくれ。
抽象論は聞き飽きた。
347:293
07/03/30 00:50:44
物凄いレス着いたｗ
>>295
PHP５＋symfonyなんてしらね
>>296-297
で座ﾊﾟﾀなんてクソ喰らえｗ
>>298
＞ WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス)
＞と言いたかったのか？
その意味も含んでるけど
＞だが、それでは
＞ ・鈴木と田中が同じ手順(Strategy)で版画を彫る
＞ ・鈴木が田中の手を借りて版画を彫る
＞が全く同じ表現になってしまう。これは不適切だ。
が意味不明。
どこをどうすれば鈴木君と田中君の接点が見えてくるのか？
>>300
勝手に解釈して話を進めないようにｗ
>>301-
目が疲れたから読めん
っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ
348:デフォルトの名無しさん
07/03/30 00:50:51
一体何を聞きたいんだ？
・ソフトウェア・プロダクトラインのための資産管理
・大規模開発へのOOおよびデザパタ適用の是非
・そのほか
349:デフォルトの名無しさん
07/03/30 00:54:30
とりあえず、>>293は
・話の発端(PHP5+symfony)も見えてないし
・クラス命名のセンスもないし
・クラス設計のセンスもないし
・等価コードの意味も理解できないし
・目が悪くて人の話も聞かない
奴である事だけはかろうじて理解できた
でなんか用かよタコ
350:デフォルトの名無しさん
07/03/30 00:59:16
> ＞だが、それでは
> ＞ ・鈴木と田中が同じ手順(Strategy)で版画を彫る
> ＞ ・鈴木が田中の手を借りて版画を彫る
> ＞が全く同じ表現になってしまう。これは不適切だ。
> が意味不明。
> どこをどうすれば鈴木君と田中君の接点が見えてくるのか？
お前はシャレも解せぬ不粋な人間だと理解した
351:デフォルトの名無しさん
07/03/30 01:00:00
> っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、
> ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ
はいはい釣れた釣れた
352:293
07/03/30 01:09:32
終わりか？
＞・クラス命名のセンスもないし
＞・クラス設計のセンスもないし
それは否定できんなｗ
ほいじゃーね
353:デフォルトの名無しさん
07/03/30 01:09:50
思い切り東陽町スタイルだな。あの糞コード
354:デフォルトの名無しさん
07/03/30 01:11:19
> public WoodCutPrintContext{
単にソースコード保守するだけの
運用チームじゃないかな、彼は
355:デフォルトの名無しさん
07/03/30 15:41:55
>>293の元設計の問題点
1. 詳細設計～実装の主眼を「コード再利用率の向上」に置いたのが誤り。
小手先のテクに走らず、分析～設計段階で一貫したドメインモデルを用い、
それを素直にコード化して、保守性・拡張性を高める事こそ重要である。
2. 継承や委譲を駆使した「差分コードプログラミング」は煩雑過ぎて人間の手に余る。
もし本気で「差分コード」を扱いたいなら、アスペクト指向開発方法論(AOSD)を取り入れ、
差分定義の組み込みはAOP言語のweaving機能に任せろ。人間の手でやるな。
・・・だが残念な事に、アスペクト指向言語はまだ底辺現場で使える段階にはない。
つづく
356:293
07/03/31 00:03:16
>>293から50レス以上あって
くだらない能書きは大量に吐き出されたが
もっと良い解決方法を提示するコードが出てこないとはｗ
所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなｗ
コリャデスマがなくならないわけだ
357:デフォルトの名無しさん
07/03/31 02:06:50
お前のコードの問題点は示しただろ？すずき
358:デフォルトの名無しさん
07/03/31 10:55:10
>>356
一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。
359:デフォルトの名無しさん
07/03/31 11:48:32
>>358
議論しているのをキチガイ呼ばわりする奴って
どこにでもわくのな
360:デフォルトの名無しさん
07/03/31 11:52:26
【ひろたかと２ちゃんの不思議な関係】
・ひろたかがかつて在籍していた会社は全て、ひろたかが去った直後に
２ちゃんでしつこく攻撃される。
・ひろたかの元仕事相手、脳内ライバル、
その他ひろたかが自分にとって脅威だと感じる対象は、
２ちゃんのあちこちのスレに中傷文が書かれる。
・ひろたかが出没するスレには
常に「キチガイ」「発狂」を連発する荒しが発生する。
・２ちゃんに居る頭も性格も悪い粘着に ← いまココ
噛んで含めるように高度な概念を教えてやると、
いつの間にかたかひろ本人も同じ意見を主張するようになるｗ
・ひろたかは論破されていても、それに気付かないフリをして勝利宣言をする。
・ひろたかは論破されると、他のスレで暴れる。
・ひろたかは成りすまし/匿名発言をよくするが、それが見破られると
「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。
さ～て、また荒しが発生するのかなｗ
361:293
07/03/31 12:56:20
>>358
そういわれるとちょっと寂しい気も・・・ｗ
>>357,359
議論になってな（ｒｙ
>>360
「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・ｗ
362:デフォルトの名無しさん
07/03/31 13:15:59
>>361
議論になっていないと考える低脳はお前だけだ
363:293
07/03/31 13:27:20
だってボク低脳ですから
364:デフォルトの名無しさん
07/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)は､その字面の単純さにもかかわらず､
挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
365:デフォルトの名無しさん
07/03/31 13:55:01
くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は
「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。
マッピング後のクラス設計以前の問題。
んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。
366:デフォルトの名無しさん
07/03/31 13:59:48
うっせぇぞ低脳。
お前はさっさとODBMS営業逝ってこいや
負け犬が
367:デフォルトの名無しさん
07/03/31 14:03:10
ODBMS（ｗ
ぷぷぷ
もう10年前にたかひろの子分に
「(製造業など一部の特殊分野を除いては)
仮想記憶方式のODBMSなんてもう売れねぇよ」
って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなｗ
368:デフォルトの名無しさん
07/03/31 14:10:47
そん時に提示した代替手段が、
・ ORマッピングによるRDBMSとの共存
・ Stonebreaker氏のORDBMSの発展
だったな。
369:デフォルトの名無しさん
07/03/31 14:41:39
>>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)を別々のクラスに分離記述した後、
関連するデータクラスと処理クラスを適切な方法で再カプセル化しなかったため、
オブジェクト指向のメリットが得られなくなっている。(非ＯＯ的コード)
370:デフォルトの名無しさん
07/03/31 14:59:40
>>355、>>364、>>369
その問題点を直したスケルトンコードを頼む
371:293
07/03/31 15:13:25
>>365が僕の考えからは少し極端な意見だがいいこと言った。
まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに
とらわれないコードを書いたんだがね。
自分のレスの後だったんでよっぽど悔しかったんだろうｗ。
だが少しだけ付き合ってあげようｗ
＞ >>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
なりません。
＞ >>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、
・・・・
＞ このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
＞ 挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
カプセル化を否定しているように聞こえるが？
そもそも鈴木君や田中君をドメインとして（まぁドメイン領域内のある部分ではあるが）時点で設計が
崩壊してるんだけどｗ
>>278の要件を分析してみると、
１．このケースの主処理は木版が作成プロセスである。
２．鈴木君や田中君は木版画作成プロセスのバリエーションである。
この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの？
で、
３．木版画作成プロセスから見た場合、鈴木君や田中君（、山田君、佐藤君・・・・）の役割は、
木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。
４．鈴木君や（略）画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君（ry)と独立するべき。
（そもそもの>>275の要件）
となるのが自然な設計だと思うけど？
372:365
07/03/31 15:25:41
>>371
キチガイにかまわないであげてください。
373:293
07/03/31 15:34:06
>>372
むむ・・・
スレが荒れてしまいますな・・・
まぁ彼が言うクラス粒度が細かくなりすぎると見通しが悪くなるのは事実だけどね
その辺の加減が難しい・・・
374:デフォルトの名無しさん
07/03/31 15:51:23
-- 引き続き、元質問者(>>275) の挙げた例題(>>278) を題材に､ --
-- デスマ現場で発生した問題 (>>306-307) を論じる｡ --
375:デフォルトの名無しさん
07/03/31 15:53:01
>>293の元設計の問題点(つづき２)
(2-1. Bridgeパターン・スパゲティ (クラスの過剰な分割によるOOモデルの崩壊))
原因(3-1)モデルや型の過度な単純化による、複雑な問題への適応能力低下。
現実の問題は、>>293のような単純な構造は持っていない。
まず、データにはバリエーションがある。
例えばデスマ事例(>>306-307)で指摘されているように、
操作対象となるオブジェクト/データ(Hanzai)は一種類ではなく、
実際には何種類ものバリエーションが存在する。(分析モデル)
Hanzai ＜─┬ 原料Hanzai ＜─┬ 木版＜─┬ 柔かい木版
│ │ └ 硬い木版
│ ├ ゴム版
│ ├ 芋版
│ └ 銅版
├ 加工中Hanzai＜─┬ 下絵中Hanzai
│ └ 切除中Hanzai
└ 完成した版画版
※ ここでHanzaiのサブクラスは、
工程進行に伴う状態変化 (原料→下絵中→切除中→完成) と見なせる。
ただし、後工程になるほどデータの内部構造は複雑になっていく。
次に、データはしばしば単純なモノシリック構造ではなく、
複数のデータを内部構造として持つComposite構造を持つ。
完成した
版画版 ◇┬ 背景部 ◇─(略)
(人物画) └人物部 ◇┬ 頭髪
├ 顔 ◇┬ 目
│ ├ 鼻
│ └ 口
├ 上着
376:デフォルトの名無しさん
07/03/31 15:59:12
当然のように、処理もこのComposite構造の対応している必要がある。
人物画のゴム版画の為の
切除処理 ◇┬ 背景部 ◇─(略)
└人物部 ◇┬ 頭髪パターン切除
├ 顔 ◇┬ 目をリアリスティックに表現する切除
│ ├ 鼻の膨らみを表現する切除
│ └ 口の生々しさを表現する切除
├ 毛皮パターン切除
それでは、切除工程の操作は、作成対象データ(人物画)と同じComposite構造を持ち、
素材×Compositeの要素数分必要になるのか？
そんな事はない。
例えば、頭髪パターン切除と、毛皮パターン切除には同じ切除テクニックが使える。
これが現実世界の共用だ。
377:デフォルトの名無しさん
07/03/31 16:11:43
御託はいらん
読む気も無い
378:デフォルトの名無しさん
07/03/31 16:12:41
【そして、現実の世界へ・・・】
それではここで、精神性疾患患者たかひろの設計でデスマ化した
デスマ事例(>>306-307)に戻ろう。
途中から読んでいる方には何の事やらサッパリ判らないだろうから
説明を加えると。
>>293のコードは、精神性疾患患者たかひろが、その劣悪なる知能で設計し
その結果デスマを巻き起こしたコードと極めて類似している。
したがって、>>293の詳細な分析は、デスマ事例コードへの解決策を与えるのである。
379:デフォルトの名無しさん
07/03/31 16:39:53
いまごろ解決しても、お前の頭がおかしくなったのはもとには戻らん。
あきらめろ。
380:ﾜﾛｽ
07/03/31 16:46:39
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング（・∀・）
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
【版画作成アプリ】 【マスタメンテ型基幹システム】
[主要ドメイン] 版画作成プロセス マスタ更新プロセス
[主要データ] 下絵、原料版材 入力 (画面入力,電文入力)
完成した版画版 出力 (ＤＢ更新,電文出力,)
(付帯的な画面出力)
[主要プロセス]版材取得 入力取得
下絵作成 入力取得
版材の品質チェック 入力チェック
下絵と切除テクのマッチング 業務チェック
切除処理 ＤＢ参照、演算処理、ＤＢ更新
印刷処理 出力処理 (画面出力,電文出力)
381:デフォルトの名無しさん
07/03/31 16:49:08
【たかひろと２ちゃんの不思議な関係】
・たかひろがかつて在籍していた会社は全て、たかひろが去った直後に
２ちゃんでしつこく攻撃される。
・たかひろの元仕事相手、脳内ライバル、
その他たかひろが自分にとって脅威だと感じる対象は、
２ちゃんのあちこちのスレに中傷文が書かれる。
・たかひろが出没するスレには ← いまココ （・∀・）>>358, >>371, >>379
常に「キチガイ」「発狂」を連発する荒しが発生する。
・２ちゃんに居る頭も性格も悪い粘着に
噛んで含めるように高度な概念を教えてやると、
いつの間にかたかひろ本人も同じ意見を主張するようになるｗ
・たかひろは論破されていても、それに気付かないフリをして勝利宣言をする。
・たかひろは論破されると、他のスレで暴れる。
・たかひろは成りすまし/匿名発言をよくするが、それが見破られると
「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。
さ～て、まだ荒しを続けるつもりかな？
382:デフォルトの名無しさん
07/03/31 16:51:04
またたかひろが暴れてるな
そう。お前自身の信仰は誰も問題にしていない。
例え神の存在を否定する信仰だろうと、
ここ日本では誰もメクジラなど立てない。
お前が問題なのは、
お前がお前自身の信仰を大切にしているのと同様に、
他人も自身の信念や大切なものを抱えながら生きている
という事を理解せずに、
・他人の信念を批判しまくったり、
・自分勝手で不合理な自己主張をおしつけたり、はたまた
匿名で 他人の名前を挙げて
執拗な人格批判/いやがらせを繰り返している
という事実にある。
お前と正式に顔を合わせて以来もう数年経つが
ある日突然ﾈｯﾄ上で名前を挙げて非難が開始され俺はとまどった。
俺は匿名で非難を浴びるような生き方は、これまで一切していない。
なのに、お前に会ってしばらくしてから突然攻撃が始まった。
最初はお前の周辺に異常者が居て、俺を攻撃してるのかと思った。
・・・でも結局お前がその異常者本人だと気付いた。
お前しか知りえない情報、お前しか感じ得ない感情で
キチガイじみた様相で攻撃してくる奴は、お前しかいないって。
悔い改めよ。そしてお前が迷惑をかけた人、一人一人に許しを乞え。
383:デフォルトの名無しさん
07/03/31 17:00:02
荒しはスルーするとして。
>>380
その概念マッピングは、>>375-376 と多少ズレている。
マスタメンテ型システムってのは、
システム開発の都合で業務処理を極端なまでに単純化して、
業務処理アプリ＝DBテーブル編集アプリ
と見なすもんだ。
すると主要ドメインはあくまで業務処理プロセスであって、
マスタ更新プロセスではない。
384:デフォルトの名無しさん
07/03/31 17:08:41
>>379
たかひろ、お前が壊れているのは最初から知っている。
お前が壊れた設計をしていたのにも、１週間と待たずに気付いた。
当然の事ながら、問題の解決策もすぐに判った。
ただ、お前がお前自身の精神状態の異常さに気がつかずに、
多くの人々に多大な迷惑をかけ続けた経緯には、
さすがの俺も心が痛んだ。
だから、あえてお前の古傷を持ち出し、
お前の行動を是正しようとしているんだ。
謙虚になれ、たかひろ。
お前はお前が思っているのの１/１００も有能ではない。
単なる空っぽの本棚だ。お前の頭は
385:375
07/03/31 17:16:39
>>375の分析モデルがズレたので、再投稿
------------------------------------------------------------
【版材の分析モデル】
Hanzai ＜─┬ 原料Hanzai ＜─┬ 木版＜─┬ 柔かい木版
│ │ └ 硬い木版
│ ├ ゴム版
│ ├ 芋版
│ └ 銅版
├ 加工中Hanzai＜─┬ 下絵中Hanzai
│ └ 切除中Hanzai
└ 完成した版画版
------------------------------------------------------------
386:375
07/03/31 17:17:57
あれ？まだずれてる。
>>375の分析モデル図差し替え
------------------------------------------------------------
【版材の分析モデル】
Hanzai ＜─┬ 原料Hanzai ＜─┬ 木版＜─┬ 柔かい木版
│ │ └ 硬い木版
│ ├ ゴム版
│ ├ 芋版
│ └ 銅版
├ 加工中Hanzai＜─┬ 下絵中Hanzai
│ └ 切除中Hanzai
└ 完成した版画版
------------------------------------------------------------
387:デフォルトの名無しさん
07/03/31 17:53:08
>>383
「マスタメンテ型アプリ」設計が導入されたのは、
今回ではなく、何世代も前の電算機導入の頃の話だろう。
それ以来業務処理は「マスタメンテ型アプリ」に合わせて変形し成長した。
だから今さら「マスタメンテ型アプリ」抜きの業務処理プロセスなど
存在しない。
業務処理プロセス(の一部) ∝ マスタメンテ型アプリのプロセス
としても大きな咀嚼はないだろう。
もし、新システム提案の初期に業務分析の専門家が入り、
提案を新しい業務プロセス設計の形で詳細に残していたら・・・
そこから正確なドメイン・モデルを作成できるのかもしれない。
だが今時の新システム構築なんて、大抵中身はマイグレーション。
COBOLプログラマがプログラムの動きを日本語で説明して「設計書でござい」
なんて言い出すおバカな世界だからなぁ・・・
388:デフォルトの名無しさん
07/03/31 17:54:57
>>365
さて、そろそろORマッピングスレを爆撃に行くかｗ
389:369
07/03/31 19:59:13
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。
なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。
Ａ．> >>365が僕の考えからは少し極端な意見だがいいこと言った。
ＯＲマッピングの話は、>>275の前提条件のスコープ外。
議論に直接関係ない話を持ち込んで、議論を撹乱するのは
詐欺師の常套手段なので、みなさん気を付けるように。
また、もしＯＲマッピングに興味を持った人が居たら、
まずはデータベース板の該当スレを参照すると良い。
Ｂ．> ＞ >>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1)
> なりません。
これは自分で補足コードを書いて見れば簡単に確認できる。
結果は>>304 のようなコードになるはずだ。
(但し>>364に説明してあるように、等価コード部 //{～}// 内は >>364※1と読み替える)
確認作業はコーディング能力のある人にしか実行できないが、
それは致し方ない所だろう。
390:369 (>>389つづき)
07/03/31 19:59:56
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。
なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。
Ｃ．> ＞ このコード(>>293, >>304)は､その字面の単純さにもかかわらず､
> ＞ 挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い)
> カプセル化を否定しているように聞こえるが？
はい、みなさん注目！！！
これが典型的な詐欺師の手口です。騙されないように。
元レス>>369は >>293-294のカプセル化破綻問題を指摘している。
自分の問題点を指摘された >>293は、逆上して事実と反対の事を言い出している。
１．システムの全体像が見えていない以上、
処理の動作主体をモデル化しておく必要がある。
ここで動作主体とは、「鈴木君」や「田中君」である。
２．動作主体が「鈴木君」や「田中君」であり、
プロセスは >>293の最初のクラス＝WoodCutPrintProcessクラスである。
391:369 (>>389つづき)
07/03/31 20:05:01
バカの相手をするのはつもりは一切ないが、
バカの勘違い/妄言を見て、他の人が間違った理解をするとよろしくないので
簡単に>>371 の間違いを指摘をしておく。
なおここで>>371とは、元レス>>369に対するバカの妄想であり、
ここでは引用符> を先頭に付けて示してある。
１．> このケースの主処理は木版が作成プロセスである。
このケースでは、システムの全体像が見えていない以上、
処理の動作主体をモデル化しておく必要がある。
ここで動作主体とは、「鈴木君」や「田中君」である。
２．> 鈴木君や田中君は木版画作成プロセスのバリエーションである。
前述のように、動作主体が「鈴木君」や「田中君」であり、
プロセスは >>293の最初のクラス＝WoodCutPrintContextクラスである。
(なおこのクラスの名称 "WoodCutPrintContext"は、内容を適切に表していない。
正しくは、"WoodCutPrintProcess"と命名するべきである。根拠は>>297 参照)
392:デフォルトの名無しさん
07/03/31 20:06:02
たかひろがバカなのは判ったから
とにかく sageを覚えろ
393:デフォルトの名無しさん
07/03/31 20:18:05
あらあら、よく見たらアイツ
またまた敗走宣言してるやん >>379
ﾜﾛｽ
394:デフォルトの名無しさん
07/03/31 20:19:51
>>380
GJ！
「版画作成プロセス」と「マスタメンテ・プロセス」は所詮は別物、
もともと厳密に１対１に対応するものではない。
そこで>>380の齟齬の悪そうな部分を若干修正してみた。
大きな変更点は｢版画作成プロセス｣でなく｢版画版作成プロセス｣とした点。
----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング part2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
【版画版作成アプリ】 【マスタメンテ型基幹システム】
[主要ドメイン] 版画版作成プロセス マスタメンテ・プロセス
[主要データ] 版材原料 入力 (画面入力データ)
下絵 ＤＢ参照データ
加工中の版画版
完成状態の版画版 出力 (ＤＢ更新データ)
刷り上がった版画 表示 (画面表示データ)
[主要プロセス] 版材原料取得 入力取得
版材作成 入力チェック
下絵取得＆下絵処理 業務チェック, ＤＢ参照
切除処理 演算処理, ＤＢ更新
印刷処理 画面表示
----------------------------------------------------------------------
修正結果を見ると、両者の対応関係はそんなには悪くない。
むしろ、別物にしてはずいぶん良い対応関係を持っている、と言える。
395:394 AAズレ修正
07/03/31 20:35:49
----------------------------------------------------------------------
｢版画の世界｣から、｢デスマ・システム｣への概念マッピング ver.2
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
【版画版作成アプリ】 【マスタメンテ型基幹システム】
[主要ドメイン] 版画版作成プロセス マスタメンテ・プロセス
[主要データ] 版材原料 入力 (画面入力データ)
下絵 ＤＢ参照データ
加工中の版画版
完成状態の版画版 出力 (ＤＢ更新データ)
刷り上がった版画 表示 (画面表示データ)
[主要プロセス]版材原料取得 入力取得
版材作成 入力チェック
下絵取得＆下絵処理 業務チェック, ＤＢ参照
切除処理 演算処理, ＤＢ更新
印刷処理 画面表示
----------------------------------------------------------------------
396:デフォルトの名無しさん
07/04/01 02:18:44
ある意味すごいなｗ
未だにコードが出てこないし解釈間違ってるけど、このエネルギーはスゴイ。
便所の１００ｗと比喩してはいけないｗ
397:396
07/04/01 05:00:48
スマソ 誤爆した
398:デフォルトの名無しさん
07/04/01 07:01:05
まあまあ
元々の質問はもうとっくにクローズしてるし、
>>293はjavaとよく似た擬似コードで記述されたクラス設計に過ぎんから、
代替コードを示す必要もない。
現在議論されているのは、>>293の背景にある設計理念の問題、
そして、それに類する設計を現実に適用した時のギャップね解決方法だろ。
理解できないなら結論が出るまで静観するがよろし
399:デフォルトの名無しさん
07/04/01 08:41:27
このスレ、爆発力はあるな
問題は火のつけ方
400:デフォルトの名無しさん
07/04/01 09:44:28
>>397
ﾅﾆｺﾚｗｗ
勝手に誤爆にするなよｗｗｗ
>>397-398
おまいウザイから別にスレ立て手やれよ
401:デフォルトの名無しさん
07/04/01 09:52:28
あとそんなに自分の主張に自信があるなら
コテつけてレスしろ
402:デフォルトの名無しさん
07/04/01 10:38:41
>>400-401 またスレ荒しか
403:デフォルトの名無しさん
07/04/01 10:40:13
おまぃはバカなんだから黙っとけ
404:デフォルトの名無しさん
07/04/01 16:38:31
いやさ、例の「精神性疾患の俗称連呼」の人、
別スレで暴れまくっててえらい騒ぎになってるわ。
どうも東京都在住の４４歳の人物らしい。
４４歳にもなって２ちゃん三昧とは幼いね。
405:デフォルトの名無しさん
07/04/01 16:50:51
リアルワールドが悲惨なんだよ、きっと
406:デフォルトの名無しさん
07/04/01 17:02:21
よしよし
407:デフォルトの名無しさん
07/04/01 18:05:17
NGワード推奨：キチガイ
408:デフォルトの名無しさん
07/04/01 19:09:37
某スレで、コーディング能力も設計能力も疑わしい４４歳の人が
「擬似コードを元にした議論はよくねぇ～」とか叫んでて笑えた。
「print文入れて動作を見ればいい」ってそれなんて名前のBASIC言語？ｗ
409:デフォルトの名無しさん
07/04/01 20:54:04
なんと言う春休み。
思わず読み飛ばしてしまった。
このスレはしばらく伸びる。
410:デフォルトの名無しさん
07/04/01 21:05:50
>>409
荒しに来たのなら、帰ってくれ。
411:デフォルトの名無しさん
07/04/04 02:42:25
こっちが平和になったと思ったら
今度はあっちで暴れてたんだな
ｽﾚﾘﾝｸ(tech板)
412:デフォルトの名無しさん
07/04/04 14:16:56
>>407
自分がそれだから、そうやって相手を封じたい訳ね。
ま、相手なんてお前の脳内にしか居ないんだけど（藁
413:デフォルトの名無しさん
07/04/04 14:25:05
誤爆？
414:デフォルトの名無しさん
07/04/05 14:50:04
>>412
おまえが自己の行動に無自覚な精神障害者である事はよくわかった。
415:デフォルトの名無しさん
07/04/06 14:56:12
ここのスレ主はそろそろ鉄格子付き個室病棟の中か。
頭も性格も悪いスレ主に意見すると
ひたすら泥沼に引きずり込もうとあがくから
始末が悪い。
416:デフォルトの名無しさん
07/04/06 15:56:32
スレ主は、ＯＯやデザパタに対して、狂信的な宗教感情を持っている。
その信仰はあまりにも愚かで盲目的であり、
自身の独自解釈とは異なる意見を持つ者に対して
狂信的信者の狂ったな正義感を持って攻撃と排除を試みる。
しかし、世の中に広く受け入れられる技術ノウハウというものは、
そのようなカルト的宗教活動とは一切無縁のものである。
417:デフォルトの名無しさん
07/04/06 16:08:13
個人的な技術ノウハウの蓄積は、
・日々の実践と経験を通じた、メンタルモデルの形成
・合理的思考による、メンタルモデルの検討と洗練
・明確な目的意識に基づく、合目的なノウハウの抽出と洗練
を通じて行われる。
そして世の中に広く受け入れられる技術ノウハウというものは、
個々人のノウハウを、他の専門家を交えた健全な議論に晒し、
目的と手段の合理性を詳細に検討し、
その過程で多くの人々が同意し共感する事を通じて、
初めて成立するものである。
418:デフォルトの名無しさん
07/04/06 16:28:04
注： 誤解のないように注記しておく。
ここでスレ主とは、今回のスレを立てた人物の事ではなく
関連スレのど真ん中に居座り、罵詈雑言を撒き散らしては議論妨害を繰り返す、
牢名主のような人物の事である。
419:デフォルトの名無しさん
07/04/06 19:28:31
GoFってなんて呼べばいいの？
個人的にはゴフって読んでるんだけど、公の場で使ったら笑われたりする？
420:デフォルトの名無しさん
07/04/06 19:37:48
>>419
情報処理用語の読み方を確認するスレ
ｽﾚﾘﾝｸ(tech板:670番)
670 ：デフォルトの名無しさん ：2005/05/16(月) 20:02:16
GOFはともかくGoFはゴフと読んでる。
421:デフォルトの名無しさん
07/04/06 20:33:32
ｺﾞﾌｺﾞﾌ
422:デフォルトの名無しさん
07/04/06 22:39:06
護符としての効能はあるんだろうか？
423:デフォルトの名無しさん
07/04/07 01:00:50
__
i＜´ }＼ , - 、
ヽ.._＼./ .ﾝく r-兮、 ＿_
∠｀ヽ.! / ヾﾆEｦぐ ,ゝ-＞ さすがGoFだ。
/＿｀ｼ'Ｋ-──‐-､l∠ イ ﾃﾞｽﾏくらっても
l´__,/l＼､_￣０¨0)ﾞ@Yﾍ, -┤ 何ともないぜ。
. l'___|⌒ヾ''ｰ＝=､ｰr='ｲ ｉ二|
/ .｣ i /./7r‐く lー!
. ｆ. ヽ‐ｉ人.∠'＜ ＿i. l,.-ゝ.
ﾄiﾍﾍ｢ﾄ〈 ｀X ﾄﾚi7__|
〉ﾄ:ﾄﾊj｀! i. / ﾄｰ┤lﾙj,ﾘ
/‐+----+‐l iｰ--i---ヾ'〃
. ｌ＿i＿＿__i__| |＿__i,＿＿i_|
424:デフォルトの名無しさん
07/04/07 01:57:18
荒らしは帰ってくれ
425:デフォルトの名無しさん
07/04/07 20:59:35
あっちの隔離スレ、すげぇ荒れようだな。
こっちであんまﾍﾀﾚな擬似コード出してくるから
ちょっとからかってやったらすぐキレ出して、
改めて問題点を７レス分ほど指摘しただけで
延々と一週間もこの騒ぎだ。
狂信者って本当に怖いね。
426:デフォルトの名無しさん
07/04/08 00:52:40
ｲﾀｲ････
427:デフォルトの名無しさん
07/04/08 00:56:10
ｽﾚﾘﾝｸ(tech板)
428:デフォルトの名無しさん
07/04/21 09:39:44
State パターンで相談です。各 State クラス間でコンテキストを共有したい
場合に、相互の依存度を下げるにはどういったイディオムが使えますか?
例えば、ウィザード形式のインストーラの画面を State と見なすと、
A 画面で設定した内容を次の B 画面でも使いたいとか、最終的には、
全ての画面で設定した内容をもとに処理を行いたい、など。
Context を各 State のコンストラクタに渡してあげれば目的は達成できる
のですが、各 State が興味があるのは Context の限られた一部分であり、
Context 全体を渡すのは不釣り合いな気がしています。
もう一つの悩みは、Context が受動的な「共有データクラス」の役割を
演じることになるというものです。どうもこの構造がしっくりこない
というか、オブジェクト指向っぽくないと思うのです。
あるいは、こういう場合にはそもそも State パターンは使わないとか、
そういった指摘でもかまいませんので、よろしくお願いします。
429:デフォルトの名無しさん
07/04/21 09:47:55
その前にStateパターンのクラスズをよく見て依存関係を
シッカリ把握しなさい
430:428
07/04/21 10:02:23
>>429
問題にしているのは以下のような依存関係です。
Controller has a State
Controller has a Context
StateA is a State
StateB is a State
431:デフォルトの名無しさん
07/04/21 10:13:33
>>430
私が問題にしているのは
＞各 State が興味があるのは Context の限られた一部分であり
です。
StateはContextに興味はありません。
432:デフォルトの名無しさん
07/04/21 10:26:13
ハッタリ業務コンサルのデザインパターン解釈はダメダメだな
433:デフォルトの名無しさん
07/04/21 10:42:32
まー独自解釈して苦しんでしまう事は初心者にはよくあることだから気にする必要は無いｗ
434:428
07/04/21 10:44:02
>>431
Context という言葉を使ったのがまずかったですね。ごめんなさい。
GoF では Context が State に処理を移譲することになっていたかと
思いますが、ここでは「共有データ」の意味で Context を使ってます。
つまり、Controller が State に処理を移譲していて、各 State は
Context を参照・更新するという構造です。
State が Controller に無関心だと言う点についてはもちろん同意です。
今回の悩みどころは、各 State の「成果物」を共有する時のうまい手段は
ないものか、というものです。
GoF に従うなら、
Context has a State
Context has a SharedData
StateA is a State
StateB is a State
で、StateA や StateB が SharedData を参照更新する、という感じです。
435:デフォルトの名無しさん
07/04/21 10:48:50
ContextがMediatorになるんじゃないの?
436:デフォルトの名無しさん
07/04/21 10:52:17
WebApplicationやStrutsと同じジャマイカ
437:デフォルトの名無しさん
07/04/21 11:07:11
扱うデータの型や処理の型を問題にせずSharedDataでひとくくりにするから
概要設計レベルではContextで解決したつもりになっていても
詳細設計レベルで一気に破綻するんだろ。
ハッタリコンサル(初心者)の典型だな
438:デフォルトの名無しさん
07/04/21 11:12:12
>>435
Mediatorで相互依存性を弱めるというのは正しい方向だが
それをContextと呼び続けるのは病気だ。
今ならDIだろ。
439:デフォルトの名無しさん
07/04/21 11:15:19
いまどき概要設計/詳細設計かよ
440:デフォルトの名無しさん
07/04/21 11:17:17
ハッタリコンサルはメーカ毎の工程名の相違に鈍感
OMGの工程名対応表でも見とけクズ
441:デフォルトの名無しさん
07/04/21 11:22:56
いまどき工程かよｗ
442:デフォルトの名無しさん
07/04/21 11:27:07
ハッタリが話題ずらしに必死だな
上空レベル、海面レベルとでも読み替えておけクズ
443:デフォルトの名無しさん
07/04/21 11:28:25
>>435
> ContextがMediatorになるんじゃないの?
ContextではなくMediatorだろうな、
古臭いデザパタ厨房の妄想に合わせてやれば
444:デフォルトの名無しさん
07/04/21 11:29:48
>>442
そりゃユースケースの話だろｗバーカｗ
445:デフォルトの名無しさん
07/04/21 11:31:11
ハッタリ必死すぎるぞ
カプサイシン摂取過多でそろそろ拳銃乱射事件かｗ
446:デフォルトの名無しさん
07/04/21 11:33:12
ハッタリコンサルの仕事：
奴隷コーダに一画面分のコードを書かせ、
それが複数画面で使いまわせると信じ込んで
詳細設計の雛形にする
447:デフォルトの名無しさん
07/04/21 11:35:53
ハッタリコンサルの仕事２：概要設計
一画面分のコードで、データ類がContextにまとめられているのを見て、
Contextというクラスを作れば複数画面にも対応できるとはずだ
という妄想設計をすること。
448:デフォルトの名無しさん
07/04/21 11:37:09
>>446
お、宗旨替えか？
そうだよSE/コンサルはコーダ以下なんだよｗやっと気づいたか
449:デフォルトの名無しさん
07/04/21 11:44:03
>>448
はぁ？
お前がダメ人間だからといって、
他もダメ扱いすんな。
中小企業のダメコンサルに比べたら
大企業のSEには中にはまともなのが居るよ。
例えば俺。
コーディングもできるし(あたりまえ)、
科学技術にも口出しできるし、
ダメコンサルを叩いて再起不能にする事もできる。
お前を今叩いているようにな
450:デフォルトの名無しさん
07/04/21 11:45:54
ここで叩かれてボロボロになってるハッタリコンサルって、誰なの？
451:デフォルトの名無しさん
07/04/21 11:50:20
＞コーディングもできるし(あたりまえ)
コンプまるだしｗ
452:デフォルトの名無しさん
07/04/21 11:53:19
＞例えば俺。
日中カキコしまくりのヒキコモリが大企業のSE？ｗ
453:デフォルトの名無しさん
07/04/21 11:54:03
>>450
各種情報を総合すると、こいつが本人らしい。
URLﾘﾝｸ(megalodon.jp)ｽﾚﾘﾝｸ(tech板:626番)&date=20070410182152
454:デフォルトの名無しさん
07/04/21 11:56:16
>>453
みっともねぇ～ないい歳こいた親父が
２ちゃんごときで必死になっちゃってｗ
仕事場でオナニー三昧２ちゃん三昧って
それなんていう引き篭もり部屋？
455:428
07/04/21 12:00:16
うーん。Mediator だとクラスの数が増えてしまうので、ちょっとおおげさ
かなという気がします。コストとメリットがバランスしないというか。
問題をうまく処理できることはもちろん大切なんですが、「やり過ぎ」も
避けたいなと。
データ共有型 State パターンは割とありがちなことかと思ったのですが、
検索してもあんまりピンとくるものがないんですよね。まあ、探し方が
悪い気もしますが、どちらかと言うと状態遷移の問題に着目したものが
多かった気がします。
C++ だし参照渡しでお茶を濁そうかなと思ったり。
456:デフォルトの名無しさん
07/04/21 12:06:18
>>454
おめえは気の利いたこといってるつもりなんだと思うけど、
とにかくセンスが無さすぎる
457:デフォルトの名無しさん
07/04/21 12:06:31
妄想に基づく独自解釈をGoogleで探しても、適切な例が出てくるわけない。
StateパターンにおけるContextクラスの役割は約一ヶ月前に書いた通り。
お前の負けだ。観念しろ
458:デフォルトの名無しさん
07/04/21 12:08:07
>>456
キチガイのセンスに合わせるのは難しいな
四流大学出はそういう会話が得意なんだろうけど。
459:デフォルトの名無しさん
07/04/21 13:21:07
>>446
手足として使った奴隷コーダに強烈な恨みを買っているのが
ハッタリコンサルのダメダメな所。
「勝手に引き抜いて、変な仕事ばかり回してきて
あのバカは一体何様のつもりだ？」
って泣いてたぜ、奴隷コーダちゃん
460:デフォルトの名無しさん
07/04/21 13:24:16
>>459
そうそうｗ
そういえばあのコーダも使えなかったよなｗ
Javaのクラスはオブジェクトじゃない！とかわけのわからないこといってたしｗ
461:デフォルトの名無しさん
07/04/21 13:25:40
>>460
そういえばあいつ、頭おかしくなって会社やめちゃったってなｗ
ヒキって２ｃｈばっかやってるらしい。
版画とかよばれてるしｗ
462:デフォルトの名無しさん
07/04/21 13:33:03
>>461
ああ、あのゴミか
ほんと死ねばいいのにな
463:デフォルトの名無しさん
07/04/21 13:34:23
>>462
同意ｗ
おれがあいつならとっくに吊ってるｗ
464:デフォルトの名無しさん
07/04/21 13:34:37
>>460
バカが発振し始めたな
デブのことだよハッタリ高弘ちゃん
465:デフォルトの名無しさん
07/04/21 13:36:25
>>464
版画ﾊｹｰﾝ（版画風ｒｙ
うわきもｗ
466:デフォルトの名無しさん
07/04/21 13:36:31
早速スレに晒しときましたｗ
467:デフォルトの名無しさん
07/04/21 13:39:24
おいおまいら、アドレナリンは俺専用のオモチャだ
勝手にアドレナリンをいじるな
暇つぶしに適当な書き込みをするとすぐ怒り出すのでとても面白い
468:デフォルトの名無しさん
07/04/21 13:42:11
>>467
強がりいってらｗあったまわりいｗ
469:デフォルトの名無しさん
07/04/21 13:42:51
>>467
カプサイシンの間違いじゃねぇの
半島人臭いし
470:デフォルトの名無しさん
07/04/21 13:43:53
ﾑｯｷｰ、ﾌｧﾋﾞｮｰﾝ(笑
471:デフォルトの名無しさん
07/04/21 13:45:29
おいハッタリをあんま構うな
あまり追い詰めると
出身校(四流大)で拳銃乱射事件起こすぞきっと
472:デフォルトの名無しさん
07/04/21 13:46:34
>>469
そうそうｗ
版画もちょっと煽るとすぐファビョるしなｗ
半島に帰れよｗ
473:デフォルトの名無しさん
07/04/21 13:47:38
ハッタリ高弘の好物
キムチ餃子
474:デフォルトの名無しさん
07/04/21 13:48:59
さぁーってと
昼休みのハッタリいじめはそろそろ飽きたし
四月の休日を満喫してくるか（←満喫に行くって意味じゃないよｗ
475:デフォルトの名無しさん
07/04/21 13:52:03
版画版画ってバカにすんな！！
Javaのクラスなんかオブジェクトのわけないだろ！
たしかにハッタリたかひろも俺も鮮人だが、それがどうした！
低脳どもが！
476:デフォルトの名無しさん
07/04/21 13:53:51
ハッタリの成りすましはクオリティが低くて萎える
477:デフォルトの名無しさん
07/04/21 13:54:42
GoF本って独習C++を一通りやった程度の知識で理解できますか？
478:デフォルトの名無しさん
07/04/21 13:54:51
メモ：ハッタリは半島人
479:デフォルトの名無しさん
07/04/21 13:56:31
>>478
半島人には関わらない方がよい。
480:デフォルトの名無しさん
07/04/21 21:03:15
>>477
基本的に経験則のまとめ本だから、必要な状況にならないと理解しにくいのが多い。
まあ理解出来る出来ないに関わらず一冊持っとくのは良いと思うよ。
481:デフォルトの名無しさん
07/04/21 21:15:36
こういうのには盛り上がるんだなｗ
482:デフォルトの名無しさん
07/04/21 21:18:22
ほら、宗教の人だから自作自演で信者獲得したフリしないと気が済まないんだろ
483:デフォルトの名無しさん
07/04/27 11:52:06
GoF本を今時会社の机にこれ見よがしに置いてあるの見ると笑える
484:デフォルトの名無しさん
07/04/27 14:49:27
キチガイって飽きないの？
485:デフォルトの名無しさん
07/04/29 00:50:15
>>484
自問自答は黙って答出せ
486:デフォルトの名無しさん
07/05/18 15:28:15
ここのObserverﾊﾟﾀｰﾝはわかりやすかった。
URLﾘﾝｸ(goodjob.boy.jp)
487:デフォルトの名無しさん
07/06/18 21:21:41
アーキテクチャパターンの質問で悪いんだけど、
MVCパターンにおいて、
｢押されたボタンに応じて新しいサブWindowをオープンする作業｣のような、
Window遷移を管理する人(実現する人)って誰になるの?
Model? View?
Window遷移もアプリケーションの中核処理になるから、
Modelの責務の範囲内なのかなとも思うんだけど、、実際どうなの?
488:デフォルトの名無しさん
07/06/26 23:59:02
どーでもねーよ
489:デフォルトの名無しさん
07/07/09 11:31:18
>>487
画面の制御なんてモロにViewだと思うんだけど。
490:デフォルトの名無しさん
07/07/09 22:41:24
ＵＩモデルだな
491:3年前
07/07/11 11:24:49
Domain-Driven Design
ｽﾚﾘﾝｸ(prog板)
1 名前： 仕様書無しさん 投稿日： 04/03/25 02:38
ドメイン駆動型デザインとは何か？
Download draft of book from
URLﾘﾝｸ(www.domaindrivendesign.org)
URLﾘﾝｸ(www.domaindrivendesign.org)
492:そして現在
07/07/11 11:26:36
Domain-Driven Designのエッセンス
「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。
しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関す
る解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無か
ったと言ってもいいでしょう。 Eric Evansの『Domain-Driven Design』（以降DDD）は、「ソフト
ウェアの真の複雑さに挑戦する」という副題からも分かるように、ドメインモデリングに正面
から取り組んだ待望の書籍です。
DDDは、海外では非常に評判の高い書籍です。本書の出版前からMartin Fowler氏により
「期待できる内容だ」と推薦されていたり、GoFの1人であるRalph Johnson氏は自身のブロ
グで本書を「4、5回は読み直した」と賛辞を送っています。Spring Frameworkの開発者Rod
Johnson氏も、最近のプレゼンテーションでDDDを紹介しながら、「Java EE開発者がこれ
から進むべき道はリッチなドメインモデルだ」と発表しています。また、MDAツールSculptor
のように、DDDを積極的に採用したツールやフレームワークも登場しつつあります。
しかし、日本では翻訳書がいまだに出版されていないこともあり、本書の出版から3年近く
経った今でも、まだまだ一部の通の人たちにしか広まっていないように筆者には思われます。
また、原書を読まれた方の中からも「本が分厚すぎて読みきれない・・・」という嘆きの声も
聞かれます（DDD難民という言葉もあるそうです）。
そこで本連載では、全3回に分けて、DDDの全貌を簡潔に紹介してみたいと思います。
DDDはタイトルからは一見分かりにくいのですが、いわゆるパターン本の1つです。
しかし、DDDは全体が読み物の体裁で編まれているため、パターンカタログが読み物から
独立しているもの（『デザインパターン』『J2EEパターン』『エンタープライズアプリケーション
アーキテクチャパターン』など）に比べ、パターンの閲覧性は良くありません。本連載では、
すでに一度読破された方にも有用な資料となるように、パターンカタログとしてDDDを再構成
してみます。
493:デフォルトの名無しさん
07/07/11 19:11:44
へー
494:デフォルトの名無しさん
07/10/08 17:41:42
ここって何も知らん人でも書いていいんだろうか・・・
一つのパターンを適用、っつーか使うっていうのなら何とかできるんだけど、複数のパターンを組み合わせるとなるといきなり手が止まる・・・
デザインパターンはいいコードを書いていれば自然に適用されている物、っていうことなの・・・？
495:デフォルトの名無しさん
07/10/08 18:57:21
一つ使うも複数使うも難易度に差はないだろ
理解しないでサンプルコード改変してるレベルと見える
496:デフォルトの名無しさん
07/10/10 23:46:07
デザインパターンって、「組み合わせて」使うような例ってほとんどないんじゃないかな。
一つのモジュールの別々の箇所で複数のデザインパターンを併用することはよくあるけどねー。
Java のクラスライブラリがいい例。
497:デフォルトの名無しさん
07/10/31 00:50:37
難しいことはいいからデザパタって
ホントに役に立つのかどうか教えろよ
498:デフォルトの名無しさん
07/10/31 00:51:49
>>497
OOPを一から自分で設計するのは骨が折れるぞ
バグも紛れ込むし
499:デフォルトの名無しさん
07/10/31 00:55:39
お前に使いこなせねえよバーカ
500:デフォルトの名無しさん
07/10/31 00:55:43
>>497
仕事なら役に立つよ
一単語だけで意図が伝わる
501:デフォルトの名無しさん
07/10/31 00:58:01
>>499
うるせーハナクソ
502:デフォルトの名無しさん
07/10/31 01:16:18
>>497
自分のそれまでの経験とセンスだけで、
後々のメンテとかになるべく困らないような
設計するのは難しいから、頭のいい先人たちが
編み出した有用なパターンを知っておいた方が楽。
ていうか知らないとかなり大変。
503:デフォルトの名無しさん
07/10/31 01:23:01
>>498
かなりできる人間が過半数超えてれば使えるし、
超えて無いとロスの方がでかい。
504:デフォルトの名無しさん
07/11/08 11:28:46
C++でのcrtpとか言語毎に形成されたイディオム的なパターンは実用性も高いし、初心者にも分かりやすいと思う
結局言語の所まで落とさないと使えないしね
というかC++だとそういうidiom使わないとたちどころに言語になるし
GoFで紹介されてる各パターンは役に立たないけど
そこで使われる考え方っていうのは言語ローカルなイディオムを理解するのに役立つかなぁと思ったけど、
もう少し勉強が進んだらまた違う感想になる気がする
505:デフォルトの名無しさん
07/11/14 02:08:15
デザインパターンを使わずにスマートに書く方法とかって
どんな感じなんになるんでしょうね？
たとえば、うどんをそばを作る場合なんかはほとんど
工程は一緒なのでテンプレートメソッドに使うんだろうけど
みなさんならどうやって書きますか？
ふと考えるといろいろあるけどどれもいまいちな気が。
1どんぶり用意
2うどんかそばを入れる
3だしをそそぐ
506:デフォルトの名無しさん
07/11/14 03:04:16
GoFが役に立たないとか、デザインパターンを使わずにスマートに書くとか・・・学生さんかね？
507:デフォルトの名無しさん
07/11/14 08:14:51
>>506
なんだか継承になれすぎて使わないパターンがあまりおもいつかなかったもので使わなかったらどうだろうかと思ったんですけど。
508:デフォルトの名無しさん
07/11/14 12:22:47
>>505
昔は仕様書を元に上から下へ逐次式に書いたものだよ。
仕様書がすべて、はじめに機能をすべて洗い出せることこそ能力。
これに慣れたままSEになり３０代を迎えると、もう補正が効かない。
あと、現場でやっている人は、GOFどうこうを意識している人はあまりいないとおもう。
509:デフォルトの名無しさん
07/11/15 02:57:13
>>508
>これに慣れたままSEになり３０代を迎えると、もう補正が効かない。
そういう人を一般的に才能がないという。
勉強する意欲がない人はいくら若くてもダメ。
転職するならお早めに。
510:デフォルトの名無しさん
07/11/15 03:47:08
>>508
ちょっと前にやったプロジェクトで、GOFに死ぬほど拘ってる
プロジェクトリーダーが居て困ったことがあるな。
最近、GOFを勉強したらしく、なんか頭がすごく良くなったカン違い
してるみたいで、設計がGOFのどれかのパターンになってないと、
全部NGにされて、直すのに苦労したよ・・・
511:デフォルトの名無しさん
07/11/15 03:50:05
>>508
GoFすら意識してなくて機能をイメージできるものか？出来てるつもりじゃないか？
512:デフォルトの名無しさん
07/11/15 09:22:08
設計なんて茨の道さ。
もんどりうってじたばたして、
痛い思いしながらGoFにしがみついたり、
手放したり、またGoF読み直したり、
もんどりうったり、じたばたしたり、
GoF読み直してピンときてみたり、
こなかったり、もんどりうって、ピンときたり。
513:デフォルトの名無しさん
07/11/15 13:56:27
全ての設計要素は何らかの秩序の上に存在すべき
だが設計要素や立脚する秩序をすべて表現する必要はないってこった
達人の書いたオプソのコード読んでも、凄さが伝わりくい理由がそこにある気がする
514:デフォルトの名無しさん
07/11/15 14:39:57
>>512
オッパイ揉んでピンときたり
が抜けてね？
515:デフォルトの名無しさん
07/12/28 16:51:17
ソースコードの見た目がかっこ良くなるので使ってます
516:デフォルトの名無しさん
08/01/07 21:48:54
開発環境のバージョンによって、含まれるライブラリが違うため、
どちらのバージョンでも動くように、実装を切り替えるということがしたいのです。
XMLのラッパーライブラリのエンジンの実装を切り替える、というようなことです。
Strategyパターンを使うのがよいのでしょうか？
最初は、Decoratorパターンと区別がつかなかったのですが、
GOF本のDecoratorのところにあるように、
・中身を取り換えるのが、Strategyで、
・外側を取り換えるのが、Decorator
ということで、
中のエンジンを取り換えるのは、Strategyパターンということでしょうか？
517:デフォルトの名無しさん
08/01/07 22:43:21
>516
あんまりパターンの名前にとらわれずにしたほうがいいと思われ。
518:デフォルトの名無しさん
08/01/08 00:19:40
うむ。
とりあえず作りたいように作って、似たパターンがあったらそれに合わせていく方向で。
519:デフォルトの名無しさん
08/01/09 03:33:32
>>517-518
ありがとう
過去レスででてたけど、作ってみてリファクタリングの時に考える方法やってみる
520:デフォルトの名無しさん
08/02/06 20:05:11
// Hoge.h
#ifndef HOGE_H
#define HOGE_H
class Hoge {
public:
static Hoge* New();
virtual void Foo() = 0;
virtual ~Hoge() { }
};
#endif
// Hoge.cpp
#include "Hoge.h"
#include <iostream>
class Hoge_ : public Hoge {
public:
virtual void Foo() { std::cout << "Hoge::Foo" << std::endl; }
};
Hoge* Hoge::New() {
return new Hoge_();
}
// main.cpp
#include "Hoge.h"
#include <boost/scoped_ptr.hpp>
int main() {
boost::scoped_ptr<Hoge> hoge(Hoge::New());
hoge->Foo();
}
こうやって実装を pimpl より隠蔽してるソースを見たんだけど、
このデザパタの名前って何？
521:デフォルトの名無しさん
08/02/06 23:46:55
これっしょ？よく見る普通のインターフェイスじゃないか。
URLﾘﾝｸ(boost.cppll.jp)
522:デフォルトの名無しさん
08/02/07 00:21:09
「～パターン」 とかの名前がついてるわけではないのね。
523:デフォルトの名無しさん
08/02/07 03:10:32
strategyじゃね
524:デフォルトの名無しさん
08/02/07 07:40:40
派生クラスを１つしか作らないこと前提で目的も違うから
strategy じゃないな。
525:デフォルトの名無しさん
08/02/14 22:04:23
質問させてください
Compositeパターンで作られたクラスに
インターフェースの拡張を施した新しいクラスを作りたいときは
Bridgeパターンを使いますか？
526:デフォルトの名無しさん
08/02/15 20:35:57
自己解決しました
527:デフォルトの名無しさん
08/02/16 03:47:22
自己解決したらできれば、解決法を書いていきましょう
後で見た人の参考になりますよ
528:デフォルトの名無しさん
08/02/27 09:21:02
フラグを１ビットではなくカウンターで持っておき、ＯＮ扱いを１より大きい
値（仮にＡ）とします。ＯＮしたい状況ではいきなりＡを代入するのではなく
１ずつ足していき、ＯＦＦしたい状況ではすぐにゼロを代入します。
こういう、ＯＮにするときだけショックアブソーバー付きな動作をする
フラグはデザパタではどういう名前が付けられてますか？
529:デフォルトの名無しさん
08/02/27 13:24:07
自家発電しました
530:デフォルトの名無しさん
08/02/27 19:14:49
>>525-526
自己解決パターン
531:デフォルトの名無しさん
08/02/28 01:50:40
アンチパターンだな
532:デフォルトの名無しさん
08/03/02 18:10:25
最近デザインパターンを勉強しだしたんですが
GoFの23個のうち2～3個組み合わせて何か簡単なものを作るとしたら
どんなものが思い浮かびますか？
533:デフォルトの名無しさん
08/03/02 18:27:07
STL
534:デフォルトの名無しさん
08/03/02 18:29:26
Template Method との組み合わせは結構考えられるかと。
535:デフォルトの名無しさん
08/03/02 22:56:35
コマンドパターンとなんかで、
GUIツールのアンドゥの練習
536:デフォルトの名無しさん
08/03/02 22:56:57
やっぱり、アンドゥ、リドゥの練習にしといて
537:デフォルトの名無しさん
08/03/02 23:13:23
Memento パターンと Command パターンの複合か。
538:デフォルトの名無しさん
08/03/03 01:22:59
わかりました
やってみます
539:デフォルトの名無しさん
08/03/04 18:26:09
ｃ++です
DecoratorパターンでConcrete ComponentとDecoratorを区別して
Concrete Componentの型を知る方法はdynamic_castを使うしかないですか？
540:デフォルトの名無しさん
08/03/04 18:53:21
>>539
型を知って何をするかによって方法が変わる気が。
RTTI(dynamic_castもその１つ)を使うか、Concrete Componentのメンバに型を示すIDのようなものを用意しておくか。
そもそもスレ違い。
541:デフォルトの名無しさん
08/05/09 11:50:43
鈴木高弘スレｗ
542:デフォルトの名無しさん
08/05/11 05:10:51
ゲーム作ろうと思い、デザインパターンの勉強をしてるんですが
Singletonをどんな風に使うのか今一ピントきません。
Singletonじゃないと困る場合。
Singletonだと助かる場合。
出来たら例を示して貰えないでしょうか。
543:デフォルトの名無しさん
08/05/11 07:57:27
>>542
ぜひ、こちらへどうぞ
ゲームにおけるデータ構造・クラス設計・パターン
ｽﾚﾘﾝｸ(gamedev板)
544:デフォルトの名無しさん
08/05/11 16:39:33
あちらで聞いてみます
545:デフォルトの名無しさん
08/05/11 17:47:41
やる夫がデザインパターンをやるようです
URLﾘﾝｸ(mojalog.com)
546:デフォルトの名無しさん
08/05/11 18:06:29
>>545
やる夫ｗｗｗｗめちゃめちゃ笑った
547:デフォルトの名無しさん
08/05/11 18:15:14
>>545
デザインパターンの考え方が分かりやすくて助かりました。
548:デフォルトの名無しさん
08/05/11 19:23:44
AA入ってるのって、一見とっつきやすそうだが…、
読みにくくもあったり…しかし微笑ましいのだけは確か。
549:デフォルトの名無しさん
08/05/11 21:11:22
例自体は具体的で読みやすいんじゃないか？
デザパタ本て(全部とは言わないが)ほとんどが
説明のための説明みたいな本になってるし。
550:デフォルトの名無しさん
08/05/12 02:47:40
シンプルファクトリーって始めて知った
ファクトリメソッドとアブストラクトファクトリしか知らなかった
デザインパターン的には常識なの？
551:デフォルトの名無しさん
08/05/12 02:56:07
この手のものは先に名付けたもん勝ちだから
あまり仔細にこだわろうとするな。
> ファクトリメソッドとアブストラクトファクトリしか知らなかった
知ったかどうかよりも理解できたかどうかが大事なんだが。
552:デフォルトの名無しさん
08/05/12 16:39:49
URLﾘﾝｸ(marupeke296.com)
個人的にここのデザインパターンの解説がゲームプログラミングを例にしているせいか
わかりやすいんだが、スレ住人的にはどう？
553:デフォルトの名無しさん
08/05/12 16:59:44
>>552
わかりやすいし、筆者の理解度は高いと思う。
自分の言葉で言いなおしてるところで、
的が外れていないので高感度アップ。
Abstract Factory 一塊のオブジェクト群を沢山の種類用意する
は、恥ずかしながら今までみたどの解説よりスッとくる一文だった。
554:デフォルトの名無しさん
08/05/12 22:57:03
例というなら、GoFの元ネタはウィジェットや言語の実装で現われたパターンだから、
自分でウィジェットや言語を書けば何を言ってるのかすぐわかる
555:デフォルトの名無しさん
08/05/12 23:10:08
うじぇー奴
556:デフォルトの名無しさん
08/05/13 00:53:16
>>552
FlyWeightってこのページで書かれているような感じなの？
557:デフォルトの名無しさん
08/05/13 09:31:42
zsh line editorのwidgetでも使えますか！？
558:デフォルトの名無しさん
08/06/14 11:28:21
実践UML 第3版 オブジェクト指向分析設計と反復型開発入門
URLﾘﾝｸ(www.amazon.co.jp)
この本とかどうだろうね？まだ自分は読み始めだけど。
559:デフォルトの名無しさん
08/06/14 19:02:26
だったら読み終わったときに評価書いてくれ
560:デフォルトの名無しさん
08/06/18 18:46:30
MVCモデルについて質問です。
javaであればModelでは描画するメソッドを一切実装せず、描画メソッドについてはすべてViewで実装するという事ですか？
例えば、Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思いますが、
そういう時もViewまで先送りにした方がいいですか？
561:デフォルトの名無しさん
08/06/19 00:31:36
描画はモデルじゃね？
562:デフォルトの名無しさん
08/06/19 02:05:46
>Modelのオブジェクトにdrawメソッドをdelegateしたい場合などもあると思います
例えばどんな時？
デザパタの本にありがちな、
Shape インタフェースに draw メソッドがあって
Circle でも Triangle でも draw 呼べば片付きますよ、
的な話って、いかにも説明のための説明って気がしてならん。
563:デフォルトの名無しさん
08/06/19 02:20:03
ここまで一切コントローラの話題が無い件
564:デフォルトの名無しさん
08/06/19 07:30:42
>>562
まさにそういう時。
アルゴリズムでdraw可能なオブジェクトをいくつかはじきだす。
その時にそいつにdrawメソッドを持たせておいた方が都合がいいのでそうしているが、
癒着してるようで気がかり。
565:デフォルトの名無しさん
08/06/19 19:37:43
ほれ、答えだ
URLﾘﾝｸ(www.fujigoko.tv)
566:デフォルトの名無しさん
08/06/19 20:07:01
長い；；
567:デフォルトの名無しさん
08/06/20 23:52:54
>>565
当たり前すぎるくらいに当たり前のこと書いてるな。
でも、この当たり前が理解できてないやつが殆どだ。
モデル自体が保存メソッド持ってるフレームワーク見せられて
「なんでこんな設計なの？」「便利だから」
意味不明の回答で泣きそうになった。
次の会社でも探すか。
568:デフォルトの名無しさん
08/06/21 00:25:48
データモデルと永続化は別か，そうかそうか
569:デフォルトの名無しさん
08/06/21 00:50:45
>>567
あたり前田のクラッカーってどうなったんだろう？
570:デフォルトの名無しさん
08/06/21 09:28:30
> モデル自体が保存メソッド持ってるフレームワーク見せられて
普通じゃん。
571:デフォルトの名無しさん
08/06/21 09:42:35
>>567
むしろ保存とか読み込んで再構築とかいう手間を見せ付けてはいけない
572:デフォルトの名無しさん
08/06/21 13:33:10
シリアライズ機能くらい普通じゃん
573:デフォルトの名無しさん
08/06/21 16:01:39
シリアライズを提供することと保存の主体であることは別じゃね？
574:デフォルトの名無しさん
08/06/21 16:06:23
Save(IOutputStream* stream)
Load(IInputStream* stream)
みたいに外部に保存主体があるわけじゃなくて、
まさか内部に保存主体があるのか？
575:デフォルトの名無しさん
08/06/21 16:12:35
dbの話じゃないの？