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

1 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:27:58 ] 前すれ 〔隔離〕デザインパターンは本当に必要か？〔スレ〕 pc8.2ch.net/test/read.cgi/tech/1119348596/ 271 名前：269 mailto:sage [2007/03/14(水) 22:13:31 ] こんなスレ未だに見てる奴が居る事実に感動 元お豆のｓずきさんかな 272 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 02:19:28 ] たかひろくんのデザパタ幼稚園 273 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 10:43:46 ] >>33の発言は間違い。 274 名前：デフォルトの名無しさん mailto:sage [2007/03/21(水) 09:22:19 ] ごふっ 275 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:59:37 ] 質問です。 テンプレートメソッドパターンを適用しようとして気になったのですが、 ConcreteClassの方で内容が一緒になるものがいくつかある場合はどう書くべきでしょう？ （内容が同じになるものが複数組あります） 内容が異なるものもあるのでこのパターンを使う必要性自体は依然あるのですが、 このままでは冗長です。 ぱっと思いつくのは、組ごとに共通のクラスを作っておいて 各コンクリートクラスは共通クラスのただのラッパーになる、という設計ですがおかしいでしょうか？ 使っているのはPHP5なので多重継承はできません。 276 名前：デフォルトの名無しさん [2007/03/26(月) 18:21:23 ] age! 277 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:05:42 ] ConcreteClassのユーザーから見て、 その「処理が同一だけど異なるクラス」とやらは 「全く同じクラス」にしてはいけないものなの？ 278 名前：275 [2007/03/26(月) 19:18:30 ] 微妙なんですけど・・・全く同じクラスにしてしまう方法も有り得るのかもしれません。 例えば、 www.techscore.com/tech/DesignPattern/TemplateMethod.html ここの記事で言えば、たまたま鈴木君も田中君と同じ木版画を作ってしまった、という場合に public class TanakasWoodCutPrint extends WoodCutPrint{} と public class SuzukisWoodCutPrint extends WoodCutPrint{} の二つが同じ内容になってしまう、という場合にどうすれば良いのか？という事です。 279 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:00:25 ] 木を切る部分を別クラスにして田中君と鈴木君の両方で使えるようにスりゃいんじゃねーの？ 280 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 22:44:58 ] 差し障りが無ければどんな場面に使おうとしてるのか聞きたいです。 もう一階層挟んだら綺麗にまとまったりしないかとか。 281 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:44:55 ] メモリが必要になったときに一度だけ生成されて、それ以降の記述では 必ず最初に確保されたメモリが使われるようなパターンは何というの？ C++風に描けば if(a == 0)a = new HOGE; //aを使った処理の前にこれが必ず入る aを使った処理… 全部グローバル変数にすればいいんだろうけど、使わない領域は 確保したくないって時にやる（a が不要になったときは回収してもOK） 282 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:46:53 ] >>281 しんぐるとんだろ？ 283 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:49:00 ] >281 Singleton 284 名前：275 mailto:sage [2007/03/27(火) 12:17:40 ] >>279 >>275で書いた共通クラスというのはそういうイメージなのですが、 タイプＡクラス、タイプＢクラスみたいなのを作って各ConcreteClassがそれをメンバとして持つ様な感じですかね？ >>280 symfonyでモデルクラスをＤＢスキーマから自動生成後、 各モデルクラスに同じ機能を持たせたい（基本的にその機能の実装はモデルクラス毎に違うが、同じものもある）というケースです。 285 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 22:52:26 ] っていうか、そのモデルは何を表してるモデルなのよ？ DBから生成されたものに後付で持たせたい機能って言う意味がわからん モデル＝状態ならばそれ自体が処理するメソッドを持たすべきではないな 286 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 23:18:27 ] なんかモデル層がぶくぶく太っていく様が想像できて怖いんですが。 287 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 07:29:58 ] >>280 まず、モデルの定義を明確にしろ。 ・DBエンティティをそのまま表したクラス(状態)を「モデル」と呼ぶのか、 ・それとも問題領域に現れるクラス(状態＋振る舞い)を「モデル」と呼ぶのか、方針を決めろ。 後者であれば、>>278の例で言うと版画作成者 Tanaka, Suzuki 自体をモデル化しろ。 次にTanakaと Suzuki 振る舞いとして、版画作成処理 cutPrint()メソッドを追加する。 版画作成の手順はほぼ共通だが、手順の詳細が同じだったり違ったりするという話なので、 cutPrintの処理内容をストラテジーパターンにして外出し(委譲)する。 具体的な処理方法は、ストラテジーパターンのConcreteStrategyクラスに記述する。 ここで、テンプレートパターンを使う。 　　ストラテジーパターンの抽象Strategy＝＝テンプレートパターンのAbstractClass 　　ストラテジーパターンのConcreteStrategy＝＝テンプレートパターンのConcreteClass となるようにする。 もし、TanakaとSuzukiが全く同じ版画作成処理をするならば、 同じConcreteStrategyクラスを生成して呼び出せば良い。 違う処理をするなら、違うConcreteStrategyを生成して呼び出せば良い。 それだけの話ではないか 288 名前：２８７ mailto:sage [2007/03/28(水) 07:36:24 ] >>280ではなく>>275 289 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:14:53 ] symfonyってのをちらっと眺めた感じだと ＞・DBエンティティをそのまま表したクラス(状態) どうもこっちみたいだから、 そもそも適用するレイヤを間違ってる説が有力。 290 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:51:39 ] ODBMS屋乙。 > そもそも適用するレイヤを間違ってる説が有力。 それは前提を勝手に仮定した偏った意見に見える。 >>275の話が 　・どのようなアプリケーション・アーキテクチャ〜レイヤ構成を前提としているか 　・一つのレイヤ限定の話なのか 　・複数のレイヤにまたがった話なのか によって、いくらでも回答の仕方があるだろう。 例えば、 下のレイヤで、オブジェクトの静的状態をDBMSに格納し、 上のレイヤで、オブジェクトの振る舞いをどう扱うか という問題を仮定した場合にも、 ・上のレイヤのオブジェクトに、振る舞い(ロジック)のみ記述し、静的状態を含めない方法 ・上のレイヤのオブジェクトに、振る舞い(ロジック)と、下レイヤから持ってきた静的状態 　を兼ね備えた「ドメイン・オブジェクト」を当てはめる方法 の二通りが考えられる。 >>287は、後者の立場から説明した。 291 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 10:58:15 ] 補足： 前者の立場でも 　　DBMSエンティティ＝静的状態＝ドメインオブジェクト　 と呼ぶことがあるが、 オブジェクト指向本来のドメインオブジェクトは、後者。 292 名前：275 mailto:sage [2007/03/28(水) 12:42:19 ] symfonyは一つのテーブルから二つのクラスを生成する。 テーブルのレコードに相当するクラスと、テーブルに対して検索・書き込みなどを行うクラス。（後者にConcreteStrategyを持たせてる） 問題領域に現れるクラスが内部的な実装方法としてＤＢにデータを保存するようになっているだけ、と考えてる。 なのでそのクラスにそのデータを使うメソッドを書こうかと。 今、>>287の方法でやっていますがこれで良さそうです。 ありがとうございました。 293 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:34:25 ] ×；DrawProcessor drawProcessor = coodinator.getCutProcessor(); ○：DrawProcessor drawProcessor = coodinator.getDrawProcessor(); w 295 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 12:59:19 ] >>293-294 > 　　　public void doWoodCutPrint(){ 身元バレバレっすよ兄貴ぃ 閑話休題 他の言語、他のフレームワークを使っている人間に 余計なコメントをつけても混乱するだけだ。 もしアドバイスをつけたいなら、Javaではなく PHP5+symfonyの例に即したアドバイスをしろ。 例えば、 ・ データクラスの生成(検索、保存) ・ データクラスの処理(計算、処理) はべき乗パターンに則って別クラスにすべきだ、などという説は そのような冗長な設計が「PHP5＋symfony」に適しているかどうか、 という観点で議論すべきである。 だが、俺はそこまで突っ込むつもりはない。 そんな事をいちいち調べるつもりはないし、 質問者も困惑するだけだからだ。 296 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 13:11:21 ] >>293 つか、今気付いた。 おまいは TemplateMethod Patternを共用したい という質問に対して、全然別の回答をつけている。 特に、クラスの命名がデタラメだ。 ×× public　WoodCutPrintContext{ ... } ×　　public class WoodCutPrintContext{ ... } ○　　public class WoodCutPrintProcess { ... } 297 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 14:58:49 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 1. Interpreterパターン 　 www.hellohiro.com/pattern/interpreter.htm 　 言語に対して、文法表現(Expressionクラス)と、 　 文法表現に基づいて文を解釈するインタプリタ(Interpreterクラス)を定義する。 　 (注： Inerpreterクラスは付帯的に、言語の束縛〜副作用を表す評価環境(Context)を持つ) 2. Stateパターン 　 www.hellohiro.com/pattern/state.htm 　 オブジェクトの内部状態が変化したときに 　 オブジェクトの処理内容を変えられるようにする。 　 (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) ---------------------------------------------------------------------------- >>293のクラス名 WoodCutPrintContext は、 クラスの役割を表現しておらず不適切な命名と言える。 298 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 15:32:52 ] ---------------------------------------------------------------------------- デザインパターンにおける Contextの用例 【追加と訂正】 2. Stateパターン 【訂正】 　 × (注： オブジェクトの取り得る内部状態の集合をContextクラスにまとめ、 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 　 ○ (注： ここでは、複数の内部状態をとるオブジェクトを、仮にContextクラスと呼んでいる。　←【訂正】 　　　　　個々の内部状態とその処理内容をConcreteStateクラスとして実装する) 3. Strategyパターン 【追加】 　 www.hellohiro.com/pattern/strategy.htm 　 Strategyパターンはアルゴリズムを、それを利用するクライアントから独立に変更できるようにする。 　 それぞれのアルゴリズムをカプセル化(Strategyクラス)してそれらを交換可能にする。 　 (注： ここでは、アルゴリズムを使用するクライアントを、仮にContextクラスと呼んでいる。 　　　　 個々のアルゴリズムは、個別のConcreteStrategyクラス (〜A, 〜B, 〜C)に記述する。 　　　　 個々のアルゴリズムは、Strategyクラスとしてカプセル化され、交換使用可能になる。) ---------------------------------------------------------------------------- もしかして >>293は、 　　鈴木、田中 ＝＝ StrategyパターンのConcreteStrategyクラス、 　　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス) と言いたかったのか？ だが、それでは 　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 　・鈴木が田中の手を借りて版画を彫る が全く同じ表現になってしまう。これは不適切だ。 299 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 16:59:49 ] ↑「同じ手順」って言うと、まるで「抽象TemplateMethodクラス」の事言ってるみたいだな。 「全く同じやり方」って言い直せば「ConcreteStrategyクラス」の話だと判る。 300 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 17:44:38 ] ■正しい表現 「鈴木と田中が全く同じやり方で版画を彫る」 public class 鈴木君 { 　// 鈴木君には版画を彫るスキルがある。 　public WoodCutPrintStrategy getWoodCutPrintStrategy() { 　　// 鈴木君のスキルは、一般にAと呼ばれるスキルである。 　　return WoodCutPrintConcreteStrategyA.getInstance(); 　} 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君は自分のスキルで版画を彫り、成果を提出する。 　　return getWoodCutPrintStrategy().doWoodCutPrint(); 　} } 302 名前：デフォルトの名無しさん [2007/03/29(木) 18:00:19 ] >>300 バグを発見しますた。 鈴木君の一人プロジェクトが無限ループを起していて いつまで経っても成果が出てきません！鈴木君ﾊｻｰﾝ /* 「手配師が鈴木君本人しか集められなかった場合」の * 　* 等価コード　　　　　　　　　　　　　　　　　　　　　　　*/ public class 鈴木君 {　// ConcreteStrategy 　// 版画を彫る 　public Hanzai createWoodCutPrint() { 　　// 鈴木君が自分を拉致る 　　鈴木君 agent = 鈴木君.getInstance(); 　　// 鈴木君はいつものようにメンバーに強制労働をさせて、 　　// 成果だけ横取りするつもりだったが、 　　// 結局自分一人では何もできずに 　　// 貯え(VMスタック)を消費しつくして終了 　　return agent.createWoodCutPrint(); // 無限ループで　throw RuntimeException("スタックオーバフロー") 　} } 303 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 18:38:56 ] エロゲで使われているパターン Singleton 他なんかある？ 304 名前：300 mailto:sage [2007/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 名前：デフォルトの名無しさん [2007/03/29(木) 19:46:45 ] まとめると、 >>275＝>>284の質問(>>292で解決済) 　テンプレートメソッドで、処理が同じものがある場合に、 　(注： 同じなのは、TemplateMethod単位か、個々のメソッド単位か不明) 　どのようなクラス設計をしたら良いか？ >>279-280、>>285-290の回答 　TemplateMethod単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※ここまではOK >>293の回答 　TemplateMethodの個々のメソッド単位で同じものがあったら、 　それをStrategyパターンで外出しして共用すれば良い。 ※>>293の実装コードは 　　ドメインモデル(鈴木君, 田中君)に、その本来の責務と無関係な役割 　　Coordinatorインタフェースを割り付けている点がおかしい。 　　鈴木君、田中君と、Coordinatorは、明らかに分離すべきである。 306 名前：305 [2007/03/29(木) 19:47:36 ] >>293の実装コードの問題点 分析/設計で得たモデルの特性として、 「手順を構成する複数の工程について、 　各工程の処理方法にバリエーションがあり、 　なおかつ、各処理方法は互いに交換可能」 な事が明らかならば、>>293の実装もありえる。 しかし>>293の実装の根拠が、単なる「コード再利用目的」だったとしたら、 不吉な匂いがする。・・・数100人月のシステムで、 このように見通しの悪い設計をして、デスマーチ化したのを見た事がある。 どのような場合にこの実装/設計が破綻するかと言うと、 設計/初期実装に見落としがあって、 Hanzaiインタフェースに後からバリエーションを持たせる必要が生じた場合 である。この場合、Hanzaiインタフェースのバリエーションに関して、 各処理方法は互いに交換可能でなくなる。 正直に言おう、デスマーチ化したシステムにおけるHanzai相当の変化要素とは なんと「入出力とDBエンティティ」だった、という事を。バッカでぇ〜 307 名前：デフォルトの名無しさん [2007/03/29(木) 20:14:36 ] デスマーチ化したシステムにおける「完成した版画」相当の要素は「画面」ね。 プロトタイプ作成時は、「版画」は１種類だけ考えれば済むから、 その版画作成に使う版材も、処理手順も、詳細処理方法も１種類ずつで済む。 ・・・プロトタイプのやり方をアーキテクチャ設計文書として配って、 　　開発もバッチグーね？とお気楽モード。 ところが開発展開になってから、 「版画は一種類だけじゃなくて複数ある」って当たり前の事実に気付く。次いで、 「異なる版画には、異なるサイズや材質の版材が必要」な事とか 「異なるサイズや材質の版材には、異なる処理手順や詳細処理方法が必要」 ってな事にも、おそまきながら気付く。 　　　　　　　　　　　　　　　　　　　　　　　　アーキテクチャ設計ﾊﾀｰﾝｗｗｗｗ ・・・いや、気付いてても気付かないフリしたんだろう、 　　アーキテクチャ設計のボンクラ共は。 じゃ、互いに異なる処理手順や詳細処理方法を、どうやって共用すればいいか・・・ 幾多の戦場を潜り抜けてきたCOBOL上がりの現場連中は、その難題に気付く事もなく問題解決してた。 その問題解決とは「データ構造や処理は一切共用せず、画面毎に別々のデータ構造と処理を書く」だったｗｗｗ 共用しなけりゃTemplateMethodもStrategyも一切関係ねぇじゃん。バカかこいつら、と思った。 それでは、正しい解決方法はどこにあるのか それを私は知っているが、このレスにはもう余白がないので書けないｗ 308 名前：鈴木 [2007/03/29(木) 22:31:38 ] おまいら、俺の名前を気安く使うな、不愉快だぞ 続きは「佐藤クン」で 309 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:37:17 ] 上がダメなら、下の名前ならおｋ？ 例えばひろゆきとかゆきひろとかたかゆきとかあと 310 名前：デフォルトの名無しさん [2007/03/29(木) 22:49:30 ] 問題はドメイン・モデリングの欠落だなｗ 311 名前：デフォルトの名無しさん [2007/03/29(木) 22:55:01 ] 問題領域が「版画作成」なら、最終目的は「版画」だけど、 問題領域が「業務処理」なら、最終目的は「画面」じゃねぇ〜よなｗ つまり、画面中心で設計したら火ぃ噴くの当たり前っつう話 312 名前：デフォルトの名無しさん [2007/03/29(木) 22:57:26 ] 「業務処理」の目的は、DB更新と電文(w。 313 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 22:58:09 ] >>312 それはありえん 314 名前：鈴木 [2007/03/29(木) 22:59:24 ] >>309 それもダメだ、かすってる 鈴木の続きは「都築」でどうだ 315 名前：デフォルトの名無しさん [2007/03/29(木) 23:03:13 ] >>314 じゃニックネームで手を打とうぜ。 例えばPackard, Tinkerbell, 卓球、うーんRuecktくらいでどうだ 316 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:05:28 ] >>309、>>315 　見事なまでのプロダクトラインだなｗ 317 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:07:17 ] 閑話休題 318 名前：デフォルトの名無しさん [2007/03/29(木) 23:10:48 ] >>312 ある種の基幹系業務システムは、 構築難易度を下げて抽象化すると、 結局、マスタメンテ型アプリに帰着する。 すると、最終目的がマスタ更新ってのも そんなにずれていない。 するとオブジェクト指向で書く必要ないんだな、これが。 （終了） 319 名前：デフォルトの名無しさん [2007/03/29(木) 23:13:24 ] )再開( 320 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:17:09 ] GoFなんでカビの生えたパターンに未だにとらわれている初心者共乙ｗ 321 名前：デフォルトの名無しさん [2007/03/29(木) 23:17:18 ] ソフトウェア・プロダクトライン系の開発方法論の話しようぜ。 322 名前：デフォルトの名無しさん [2007/03/29(木) 23:22:56 ] >>321 M$のHﾜﾗ氏、ITアーキテクチャ誌に連載してたね、２年ほど前。 CMU/SEIのCMMIと、CMU/SEI近辺で定義されたプロダクトライン、 所詮は別物だけど、あの近辺は元々俺の領分だから(どこがだよ） ちょっと後悔（ｳﾂｳﾂｳﾂｳﾂｼｸｳﾂｳﾂｼｸｼｸｳﾂｳﾂｳﾂｳﾂｳﾂｼｸｼｸｼｸｼｸｳﾂｳﾂｳﾂ そんな事じゃいかん。俺はCMU/SEIはともかくとして、 日本のCMMI連中とは全然話が合わないんだったｗ なんか、プロダクトライン・アーキテクチャ周りでいい話ねぇの？（爆 323 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:29:25 ] >>322 特に無い。 324 名前：デフォルトの名無しさん [2007/03/29(木) 23:38:44 ] >>320 確かに飽きてきたのも事実 だが使いこなせてる奴が意外と少ないのも事実 325 名前：デフォルトの名無しさん [2007/03/29(木) 23:45:29 ] だが使いこなせてる奴は１０年前から退屈してるのも事実 326 名前：デフォルトの名無しさん [2007/03/29(木) 23:49:47 ] 2PLoP (2ch Pattern Language of Programming)報告： Python初心者の人が、Javaで書かれたGoFパターンをPythonに移植しようとしてて、 まあ判ってるPython関係者にはスルーされてたんだけど、こないだ中止宣言出してた。 彼に同情的な人が言うには、「PythonはGoFパターンサポートしてるけど、Javaとはやり方が違う。 トップダウンにJava版GoFをPythonに移植するような翻訳物するんじゃなくて、 Python書きが書いた膨大なコードからパターン抽出するほうがよっぽどためになる」つってた。 　　　　　pc11.2ch.net/test/read.cgi/tech/1172431242/ 327 名前：デフォルトの名無しさん mailto:sage [2007/03/29(木) 23:56:05 ] 糞コード放置してった >>293は 今どこで野垂れ死んでいることやら 328 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:05:24 ] >>326 Pythonというか、いわゆる軽量言語にデザパタはいらんのじゃないかなぁ。 大規模開発にはそもそも向いてないでしょ。 もしかしたら、オブジェクト指向すらいらないかもしれないし。 馬鹿にして言ってるのではなくて、住み分けがあるだろうと。 大規模開発は javaなり c++ なりでデザパタを使って書けばいいし、 身近なユーティリティーを書くなら、軽量言語というか perlででも書いた方がいいし。 大規模開発に向かん言語で、デザパタっていっても そもそも意味がないと思うんだな。 329 名前：デフォルトの名無しさん [2007/03/30(金) 00:14:09 ] >>328 常識的な意見ってツマンナイよ rubyからrailが生まれたし、javascriptからAJAXが生まれた そんなご時世なのだ 330 名前：デフォルトの名無しさん [2007/03/30(金) 00:18:07 ] >>328 マジレスするぞ。 Pythonは関数言語的機能のほかに、 metaclassシステムやら、動的言語の性質をあちこち持ってるから、 C++やJavaよりよっぽどSmalltalk寄り。 そこにあろうことかJava版GoFを移植したってのが笑い所。 あと、後半部「ボトムアップでパターン抽出」 これは別に間違ってないだろ。 むしろ、将来Javaに取り入れるべき言語機能やパターンを 発見できるかもしれない(もう金脈は小さいと思うけどな)。 文句ばっか言って他をけなしてないで、 学ぶところは学びなさいってこったｗ 331 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:24:32 ] 関連ないが、Perlのプロトタイプ系OO拡張、あれは結構糞だ。 OOの面倒くさい所と、Perlのいい加減な所がダブルで来る。 でも、Javaと同様なクラスライブラリ書き始めると、 あっちの方がよっぽど融通利いて手早く完成する。 さすが90年代のLispと呼ばれただけの事はあるな。 関連ないが、Javascriptのプロトタイプ系OO機能、あれは最高だ。 あれ一つでずいぶんJavascriptのコードが書きやすくなる。 問題はjavascriptエンジンのバグやエラー報告の不充分さ。 あれ使って10年程前にAJAX風アプリ書いてた時は、 試行運用中に山のように実行時エラーがでて閉口した。 今の連中は幸せだよなぁ。あれで、Netscapeがまだ生き残ってたら 万々歳なんだが。 パターン関係ないチラ裏ｽﾏｿ 332 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:26:57 ] >C++やJavaよりよっぽどSmalltalk寄り。 て言われても、Smalltalk てそんなにいいのか？ 動的言語と言われた時点で、うーみとなりそうだけどなぁ。 型は、事前に論理的誤りを検出するためにあるんだぜ？ それを最初に省いたら、あとから泣きみるだろ。 それでデザパタが必要とされるような大規模開発に 向いてるといえるのだろうか？ 333 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:27:09 ] > OOは大規模開発向け だなんて地に足のついてない発言してる人が まだ国内に居ると知って、ﾜﾛﾀ 済まないが、実績作ってから言ってくれ おまいらの作ってるのはOOじゃねぇだろ 単にOO系言語でOOP風の事をしました（でも中身はCOBOLそっくり） だろ 334 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:28:45 ] >>232 あぁーあ。今度はCS系関数言語厨房か。 マイクロソフトリサーチの人が なんとかしてくれるだろ。 335 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:29:28 ] > デザパタが必要とされるような大規模開発 どっから出てきた妄想ですか？ 336 名前：デフォルトの名無しさん [2007/03/30(金) 00:31:22 ] すげぇずうずうしさだなコイツ >>306-307, >>310-312, >>318で 大規模(自称)OO開発の失敗例 ケーススタディしたばっかだっつうのに、 解決策も出さずに「大規模OO開発」かよ。 337 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:32:59 ] なんだよ、Py厨だけじゃないのかよ。 てか、py厨が引っ掻き回してるのか？ ただな、デザパタなんてなくてもやれるし、あったらあったで 便利だし、ぐらいのところでいいだろ。 実際、それ以上でもそれ以下でもないし。 338 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:33:59 ] > 型は、事前に論理的誤りを検出するためにあるんだぜ？ そんなキミには、汎用純関数型言語Haskellを使って、 monadic programmingを駆使した通信ミドルウェア開発が オヌヌメ。使用検証技術も必須だよ？jfitsの人がやってるような奴 339 名前：デフォルトの名無しさん [2007/03/30(金) 00:36:05 ] 大規模(自称)OO開発の失敗例 ケーススタディ　　>>306-307, >>310-312, >>318 ￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣ に解決策提案するまで、 大規模OO開発へのデザインパターン適用の話題自粛で お願いします。 340 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:36:10 ] 何この盛り上がりようｗ 341 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:37:31 ] たかびー祭＋ﾋﾟﾁｮﾝﾊﾟﾀｰﾝ祭　合同イベント 342 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:40:04 ] おいおまいら騒ぐな > 大規模OOにデザパタ必須 って言ってる人の大規模は、 せいぜい数千行〜数万行ぽっちの事だぞ、きっと 343 名前：333=336 mailto:sage [2007/03/30(金) 00:42:56 ] >>328 どうぞご自由に個人〜数人の範囲で 大規模開発しててくださいです。 いや、それくらいの規模が一番いいと思うよ。 がんばれー 火ぃ噴くのは、プログラムもろくにできないのが 数十人単位で集まっちゃうような地獄の話だからｗ 344 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:44:49 ] なんなんだよ、この盛り上がり。 そんなにヒマがあるなら、その、なんだ、Pythonのその膨大な過去の 素敵なコードの資産から、スマートなパターンを抽出して、 俺らをあっと言わせてくれよ。 もう、ずいぶん作業は進んでるんだろ？ ここで威張ってるぐらいなんだから。 345 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:46:34 ] >>344 /~ytakagi/ に直接言え。 もっとも連絡先も書いてねぇけどｗ 346 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:48:29 ] 盛り上がってもいいけど、もっと具体的な話してくれ。 抽象論は聞き飽きた。 347 名前：293 mailto:sage [2007/03/30(金) 00:50:44 ] 物凄いレス着いたｗ >>295 PHP５＋symfonyなんてしらね >>296-297 で座ﾊﾟﾀなんてクソ喰らえｗ >>298 ＞　WoodCutPrintContext ＝＝ Strategyパターンのクライアント (Contextクラス) ＞と言いたかったのか？ その意味も含んでるけど ＞だが、それでは ＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 ＞　・鈴木が田中の手を借りて版画を彫る ＞が全く同じ表現になってしまう。これは不適切だ。 が意味不明。 どこをどうすれば鈴木君と田中君の接点が見えてくるのか？ >>300 勝手に解釈して話を進めないようにｗ >>301- 目が疲れたから読めん っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、 ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ 348 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:50:51 ] 一体何を聞きたいんだ？ ・ソフトウェア・プロダクトラインのための資産管理 ・大規模開発へのOOおよびデザパタ適用の是非 ・そのほか 349 名前：デフォルトの名無しさん [2007/03/30(金) 00:54:30 ] とりあえず、>>293は ・話の発端(PHP5+symfony)も見えてないし ・クラス命名のセンスもないし ・クラス設計のセンスもないし ・等価コードの意味も理解できないし ・目が悪くて人の話も聞かない 奴である事だけはかろうじて理解できた でなんか用かよタコ 350 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:59:16 ] > ＞だが、それでは > ＞　・鈴木と田中が同じ手順(Strategy)で版画を彫る　 > ＞　・鈴木が田中の手を借りて版画を彫る > ＞が全く同じ表現になってしまう。これは不適切だ。 > が意味不明。 > どこをどうすれば鈴木君と田中君の接点が見えてくるのか？ お前はシャレも解せぬ不粋な人間だと理解した 351 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:00:00 ] >　っていうか、どうしても「鈴木」や「田中」っていういかにもわかりやすい要素ががでてくると、 >　ソコを主体に考えてしまう悲しい性がﾜﾛｽｗ はいはい釣れた釣れた 352 名前：293 mailto:sage [2007/03/30(金) 01:09:32 ] 終わりか？ ＞・クラス命名のセンスもないし ＞・クラス設計のセンスもないし それは否定できんなｗ ほいじゃーね 353 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:09:50 ] 思い切り東陽町スタイルだな。あの糞コード 354 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 01:11:19 ] > public　WoodCutPrintContext{ 単にソースコード保守するだけの 運用チームじゃないかな、彼は 355 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 15:41:55 ] >>293の元設計の問題点 1. 詳細設計〜実装の主眼を「コード再利用率の向上」に置いたのが誤り。 　 小手先のテクに走らず、分析〜設計段階で一貫したドメインモデルを用い、 　 それを素直にコード化して、保守性・拡張性を高める事こそ重要である。 2. 継承や委譲を駆使した「差分コードプログラミング」は煩雑過ぎて人間の手に余る。 　 もし本気で「差分コード」を扱いたいなら、アスペクト指向開発方法論(AOSD)を取り入れ、 　 差分定義の組み込みはAOP言語のweaving機能に任せろ。人間の手でやるな。 　 ・・・だが残念な事に、アスペクト指向言語はまだ底辺現場で使える段階にはない。 つづく 356 名前：293 mailto:sage [2007/03/31(土) 00:03:16 ] >>293から50レス以上あって くだらない能書きは大量に吐き出されたが もっと良い解決方法を提示するコードが出てこないとはｗ 所詮は口だけ、本を読んだだけの頭でっかちで現場で使えん奴らばかりだなｗ コリャデスマがなくならないわけだ 357 名前：デフォルトの名無しさん [2007/03/31(土) 02:06:50 ] お前のコードの問題点は示しただろ？すずき 358 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:55:10 ] >>356 一応いっておくが、おまいに絡んでるのはキチガイ一人だけだ。 359 名前：デフォルトの名無しさん [2007/03/31(土) 11:48:32 ] >>358 議論しているのをキチガイ呼ばわりする奴って どこにでもわくのな 360 名前：デフォルトの名無しさん [2007/03/31(土) 11:52:26 ] 【ひろたかと２ちゃんの不思議な関係】 ・ひろたかがかつて在籍していた会社は全て、ひろたかが去った直後に 　２ちゃんでしつこく攻撃される。 ・ひろたかの元仕事相手、脳内ライバル、 　その他ひろたかが自分にとって脅威だと感じる対象は、 　２ちゃんのあちこちのスレに中傷文が書かれる。 ・ひろたかが出没するスレには 　常に「キチガイ」「発狂」を連発する荒しが発生する。 ・２ちゃんに居る頭も性格も悪い粘着に　　　　　　　　　　　　　　　← いまココ 　噛んで含めるように高度な概念を教えてやると、 　いつの間にかたかひろ本人も同じ意見を主張するようになるｗ ・ひろたかは論破されていても、それに気付かないフリをして勝利宣言をする。 ・ひろたかは論破されると、他のスレで暴れる。 ・ひろたかは成りすまし/匿名発言をよくするが、それが見破られると 　「あれは自分に悪意を持っている一味の仕業だ」と苦しい言い訳をする。 さ〜て、また荒しが発生するのかなｗ 361 名前：293 mailto:sage [2007/03/31(土) 12:56:20 ] >>358 そういわれるとちょっと寂しい気も・・・ｗ >>357,359 議論になってな（ｒｙ >>360 「いまココ」ってところで、「ひろたか」が「たかひろ」になってるってことか・・・ｗ 362 名前：デフォルトの名無しさん [2007/03/31(土) 13:15:59 ] >>361 議論になっていないと考える低脳はお前だけだ 363 名前：293 mailto:sage [2007/03/31(土) 13:27:20 ] だってボク低脳ですから 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)は､その字面の単純さにもかかわらず､ 　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) 365 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:55:01 ] くだらねえことをいつまでもグダグダ書いてるが、>>275の問題の本質は 「テーブルとクラスをどうやってマッピングするか」ってところにあることに気づけや。 マッピング後のクラス設計以前の問題。 んでhibrenateとか見る限り、今のところ碌なやり方は存在しない。 366 名前：デフォルトの名無しさん [2007/03/31(土) 13:59:48 ] うっせぇぞ低脳。 お前はさっさとODBMS営業逝ってこいや 負け犬が 367 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:03:10 ] ODBMS（ｗ ぷぷぷ もう10年前にたかひろの子分に 「(製造業など一部の特殊分野を除いては) 　仮想記憶方式のODBMSなんてもう売れねぇよ」 って伝えたはずだけど。まだ悪あがきしてたんか。おめでてぇなｗ 368 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:10:47 ] そん時に提示した代替手段が、 ・ ORマッピングによるRDBMSとの共存 ・ Stonebreaker氏のORDBMSの発展 だったな。 369 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 14:59:40 ] >>355、>>364、>>369 その問題点を直したスケルトンコードを頼む 371 名前：293 mailto:sage [2007/03/31(土) 15:13:25 ] >>365が僕の考えからは少し極端な意見だがいいこと言った。 まず「パターンありき」の考え方はそもそもおかしい。だから敢えてTemplateMedhodパターンに とらわれないコードを書いたんだがね。 自分のレスの後だったんでよっぽど悔しかったんだろうｗ。 だが少しだけ付き合ってあげようｗ ＞　>>293のコードで省略されているクラス/コードを補足すると､>>304 のようになる｡(※1) なりません。 ＞　>>293は、TemplateMethodの各工程の処理詳細 (draw(),cut(),print()) を共用するために、 ・・・・ ＞　このコード(>>293, >>304)は､その字面の単純さにもかかわらず､ ＞　挙動を読み取りにくく､保守性/拡張性が低い。(前提条件の変化に対し柔軟性が低い) カプセル化を否定しているように聞こえるが？ そもそも鈴木君や田中君をドメインとして（まぁドメイン領域内のある部分ではあるが）時点で設計が 崩壊してるんだけどｗ >>278の要件を分析してみると、 １．このケースの主処理は木版が作成プロセスである。 ２．鈴木君や田中君は木版画作成プロセスのバリエーションである。 この2点から、木版画作成プロセスを中心に考えて、どのように違いを吸収していくかを考えないと遺憾のとちゃうの？ で、 ３．木版画作成プロセスから見た場合、鈴木君や田中君（、山田君、佐藤君・・・・）の役割は、 　　木を塗ったり切ったり印刷したりの方法論を持っているオブジェクト。 ４．鈴木君や（略）画持っている方法論は、皆違う場合もあれば同じ場合もあるから、鈴木君や田中君（ry)と独立するべき。 　　（そもそもの>>275の要件） となるのが自然な設計だと思うけど？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef