【GoF】デザインパターン 4

形を真似て形に入り
形を極めて形から自由になる

関連情報は >>2-10

過去スレ
デザインパターンの単純そうな質問 - (1)
http://pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
http://pc5.2ch.net/test/read.cgi/tech/1087050664/
【GoF】デザインパターン 3
http://pc8.2ch.net/test/read.cgi/tech/1095388499/
関連スレ
デザインパターン
http://piza.2ch.net/tech/kako/976/976074878.html
リファクタリング、させてくれ
http://pc5.2ch.net/test/read.cgi/tech/1081863662/l50
【XP】Agile Process 第2イテレーション【UP】
http://pc5.2ch.net/test/read.cgi/tech/1091773629/l50
【綺麗】デザインパターンは美しい！【究極の美】＠プログラマー板
http://pc5.2ch.net/test/read.cgi/prog/1089077456/l50

Web Page [ja]
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.html
C++で読むデザインパターン
http://www.01-tec.com/document/cpp_design_pattern.html
Javaなページ
http://home.catv.ne.jp/dd/chiba/ken/Java/JavaMain.html
デザインパターン入門 (ちとわかりずらい…)
http://www.netlaputa.ne.jp/~hijk/study/oo/designpattern.html
Inversion of Control コンテナと Dependency Injection パターン
http://www.kakutani.com/trans/fowler/injection.html
Inversion of Control
http://wiki.bmedianode.com/Spring/?Inversion+of+Control
デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html
デザインパターンを読み解く
http://hp.vector.co.jp/authors/VA020635/system/dpattern.html
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm

Web Page [en]
Patterns Home Page
http://hillside.net/patterns/
Design pattern (computer science) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

書籍
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
増補改訂版Java言語で学ぶデザインパターン入門
http://www.hyuki.com/dp/index.html
Java言語で学ぶデザインパターン入門 マルチスレッド編
http://www.hyuki.com/dp/dp2.html
独習デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4798104450/
Javaデザインパターン徹底攻略 標準プログラマーズライブラリ
http://www.amazon.co.jp/exec/obidos/ASIN/4774115797/
デザインパターンによるJava実践プログラミング
http://www.amazon.co.jp/exec/obidos/ASIN/4756141552/
Java実践プログラムによるデザインパターン入門講座
- Swingプログラムで体得する23のパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4894712563/
J2EEデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4873111781/
C#デザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/

議論の際にあんまり他人を馬鹿にする人が多いので
以下をテンプレに追加。

981 名前： デフォルトの名無しさん 投稿日： 2005/05/15(日) 12:52:35
>>978
またでたよー。
「２ちゃんだから〜」発言。
あのさあ、君が人を馬鹿にする発言しなきゃそれで解決する問題なんじゃないの？
結局、自分が答えられなくなると他のサイトへのリンク貼ったり、
「本紹介しますから、読んで勉強してくださいね？ｗ
このままじゃあなたみたいな馬鹿と話なんてできないですよｗ」
的な発言するから荒れちゃうんだろ。

自分の言葉をもってないのがディスプレイ越しにわかるんだよ。
どう頑張ってもこういうの誤魔化すの無理だから。
同じような職場で似たような仕事してんじゃん。俺等。
思考回路も似たようなもんなのわかるんだよ。

デザインパターンの極意は「競合より協調」です。

このスレには、学習障害の荒しが常駐しています。
見かけても決して相手にせず、スルーして下さい。

【学習障害の特徴】

・気に入らないことがあると我慢できず、乱暴な行動をとる

・一つの話題にこだわり、同じ質問、同じ話題を繰り返す

・聞きもらしが多く、会話も一方的で話題がとびやすい

・文字や文章を正確に（意味をとらえて）読むことが困難

・（因果関係など）複雑な会話は理解困難

・問題を理解して論理的に解決する力が乏しい

・相手の思いや感情を考えて、行動することが困難
　状況判断が苦手
　（人の嫌がることを言ったり、わがままを言う)

>>6 乙。
頭悪いのが粘着してるみたいだから、
牽制のためにこっちも貼っとくよ。

デザインパターンというと、
かつては
　　・コンポーネント設計のための指針
　　・設計へのデザパタ・テンプレートの導入
　　・クラス間の相互作用に基づく自己組織化(w
などという工学的な視点から語られる事もあったが、

最近は
　　・教育カリキュラムとしてのデザパタ
　　・企業アプリ構築ノウハウとしてのパターン
に力点が移動してきている。

そういった世間の動向に沿って、このスレも工学的テーマが減って
「教育としてのデザインパターン」「デザインパターン学習法」
みたいなお子ちゃま向け内容に偏るのは、しようがない。

ただし企業システムのパターンのような
元々現場起源で、今実際、J2EEや.NETの現場で使われているパターン本流が
丸っきり無視しているあたり、とてっつもなく嘘っぽく感じる。

　　　　　　　　　　スレ荒しを叩くと、 >>6みたいなの事言い出すのが出てくる痛いスレ

　　　　　　　　　　御託並べる前に、パターン言語の議論汁

アンチパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797321385/
アナリシスパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4894716933/
ソフトウェアアーキテクチャ
http://www.amazon.co.jp/exec/obidos/ASIN/4764902834/
ソフトウェアパターン再考
http://www.amazon.co.jp/exec/obidos/ASIN/4817161310/
パターンハッチング
http://www.amazon.co.jp/exec/obidos/ASIN/4894711486/
ソフトウェアパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4320120159/
パターンとフレームワーク
http://www.amazon.co.jp/exec/obidos/ASIN/4320027744/
デザインパターンと契約
http://www.amazon.co.jp/exec/obidos/ASIN/4894715384/

読んでもいない本のリンクだけ並べる痛い香具師。

「パターンハッチング」「アンチパターン」は、今更読むまでもないだろう。
「パターンとフレームワーク」は、Ralph E. Johnsonがパターンについて書いているけど、
これも今更感がある。
「ソフトウェアパターン再考」は、いわゆるパターンブームにのっかった、ゾッキ本の類。

>>11
〜再考は、ソフトウェア品質研究会の本だし、
多少は読むべき所があったと思うよ。悪い本ではない

いい加減にリンク貼るだけで自分の言葉を持たない人間の参加は
俺も遠慮してほしいところではある。

自分の言葉っていっても
どこかのサイトや本で人が言ってたことを
まるで自分の意見のように述べてるだけだけどね。

相変わらず変なのが粘着してるな。
自分で書評書いてから他を叩けって。屑が

>>15
ほんとだよ。
なんでリンクだけ貼って逃げちゃうんだろうね。
読んで無いとしか思えないよ。

荒しうざ

テンプレに文句を言う馬鹿がいるスレはここですか

テンプレなら最初に「参考書籍追加」と書いておけ。

荒しがリンクだけ書いて、自作自演で叩いてるだけ。

そうかなあ

こういう知識を仕入れてこんないいことありましたという
プログラマの喜びの声の溢れているページってないの？

ｂｌｏｇ

amazonのレビュー

これって、周りも知ってなきゃ意味無いよね？
学生のうちに覚えても自己満になっちゃうか・・・

考え方自体は大事。憶えておいても良いんじゃない？

・オブジェクト生成を制御する方法 (AbstractFactory, FactoryMethod, Singleton, FryWeight, etc...)
・処理を切り替える方法 (Strategy, State, Command, TemplateMethod, etc...)
・任意の処理を追加する方法 (Composite, Decorator, etc...)
・その他オブジェクト間の関係にまつわる物 (Facade, Mediator, Observer, etc...)

とか、考え方主体でパターンを捉えた方が身になると俺は思う。

ん？ Command の位置が微妙だ罠

でもどうせすぐ古びちゃうんで
微妙なところだけどね

少なくとも Observer は古びないだろうに……

なるほど、学んどいて最悪無駄になることはあってもそんする事は無いって
事ですね。自己満にならない程度に覚えていこうと思います。

弁茶から理沙茶に出世しても、相変わらず自作自演かよｗ

・あまり利口でない人たちは、自分が理解できない事についてはなんでもけなす。
byラ・ロシュフーコー

>>31
単純にオブジェクト指向的に設計が糞でトリッキーなのにまだそんなこと言ってるのには笑えるｗ

ラ・ロシュフーコー = あまり利口でない人

>>32
んじゃ、オブジェクト指向的に正しい設計ってなんだろうか



……いや、煽るつもりじゃなくて素で思った

どんな馬鹿でも、あら探しをしたり、難くせをつけたり、苦情を言ったりできる。
ーーーーそしてたいていの馬鹿がそれをやる。

ベンジャミン・フランクリン

ベンジャミン・フランクリン ←たいていの馬鹿

メタ定義ですな。奥が深いです。

折角なんでスレをかき回す意味を含めてアンケート

======

↓当てはまる物に ◎ 付けてくれ

○ デザパタは 『コード・クラス構造』 がメインだと思っている
○ デザパタは 『設計思想』 がメインだと思っている
○ デザパタは 『コード・クラス構造に名前を付けた』 こと自体がメインだと思っている
○ その他

メインだけど糞だ、って言うアンチな人も、上のどれかに印をつけておくれ
複数回答可

◎ デザパタは 『コード・クラス構造に名前を付けた』 こと自体がメインだと思っている

やっぱ人と話すときに名前があると便利だしね

◎ その他
デザパタは;『コード・クラス構造のいくつかを抽出して名前を付けた』こと自体がメインだと思っている

何を選んでどういう名前を付けるかというのはセンスが要ると思う

＝＝＝＝＝　今日は天気が良くて、ゴミ虫の活動も活発だな　＝＝＝＝＝

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%22%E3%82%B3%E3%83%BC%E3%83%89%E3%83%BB%E3%82%AF%E3%83%A9%E3%82%B9%E6%A7%8B%E9%80%A0%22&num=50
"コード・クラス構造"に該当するページが見つかりませんでした。

検索のヒント
- キーワードに誤字・脱字がないか確かめてください。
- 違うキーワードを使ってみてください。
- より一般的な言葉を使ってみてください。

検索が下手な人だ
http://www.google.com/search?num=50&hl=ja&q=%E3%82%B3%E3%83%BC%E3%83%89%E3%80%80%E3%82%AF%E3%83%A9%E3%82%B9%E6%A7%8B%E9%80%A0&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja

「コード・クラス構造」などという単語も概念も、一般にはねぇよ。

>>38-40
自演乙

ついでに言っとくと、
デザパタはクラス/オブジェクトの協調パターンとでも呼ぶべきものであって、
「コード構造」「クラス構造」と呼ぶ香具師は普通居ない

◎『名前を付けた』こと自体がメインだと思っている

これ以外だと思っているアンチが多いんだよな

中身のないうんちくんだな

◎ その他
デザパタは『問題とその解決策を対にして名前を付けた』こと自体がメインだと思っている。
解決策や実装のみを取り出してデザインパターンを論じることに意味はない。

>>47　質問
問題と解決策(?)についてだけど
一対一／多対一　について少しコメントして欲しい

・・・多重度はデザパタ以前の基礎知識・・・

悪いｗ　『コード、クラス構造』 だわｗ

>>41-44 乙

アナパタの関係パターンの章読むといいかもな。説明書くのめんどいから自分で読め。

>>48
問題と解決策の多重度の話なのか？
どれくらいの粒度の問題を期待しているのか判らんが、、、
問題の粒度がGoF本の「動機」レベルであれば解決策は自ずと1つに絞れるはず（GoF本の解決策で、ある程度のバリエーションが残されているものは、それを1つとして数えると考えるという条件で）。
これはGoF本を鵜呑みにしているわけではなく、デザパタの定義自体が「その問題において過去に何度も採用されている優れた設計」となっており、実際にオブジェクト指向のメリットを最大限に活かした設計になっていることが客観的に見て取れるから。
それよりも大きな粒度の問題を考えているのであれば、デザパタによる解決策が複数になることもあり得る。

ちなみに、問題の粒度とは関係なく、デザパタによる解決策が存在しないこともあり得る。
なぜならデザパタの定義が上記のようなものである（何度も採用されている=優れていることが客観的に評価できる）以上、考えられ得るすべての問題領域に対する解決策をデザパタとして用意することは到底不可能なため。
それがデザパタの限界。

しかしだからといってデザパタが役に立たないわけではない。
結城氏は、GoF本の判りにくさが「実際に動作するコードがないため」と解釈してしまったようだが、それは大きな間違い。
その時点で日本のデザパタ界は大きく後退したと思う。

>>52
>実際にオブジェクト指向のメリットを最大限に活かした設計になっていることが客観的に見て取れるから。
毎度毎度この部分があいまいな表現で

「そういうことにしておいてくれ」

とばかりに話を進めてしまうのはどうかと思う。

デザパタなんてトリッキーコードの代表みたいなのを
「オブジェクト指向のメリットを最大限に活かした設計になってる」なんて言ったんだよｗ
しかも、客観的に見て取れるとか言ってるしｗ
少なくとも俺には全然見て取れねぇよ！

>>53
「開放/閉鎖原則」、「リスコフ互換原則」、「依存関係の逆転原則」くらいは理解してから吠えたらどうだ？

>>54
＞デザパタの定義自体が「その問題において過去に何度も採用されている優れた設計」

『オブジェクト指向の設計論そのまんま ≒ これってデザパタ？』 になっちゃってるから
必要があれば 『名前』 と 『実装』 を切り離して考えるべきかもしれんね

「設計が優れているかどうか」 は 「デザパタになっているか」 とは無関係だし、
そもそも全ての場合において優れている設計っていうのは無いし

=====

っていうか、Facade とか Strategy とか Observer とか、いかにもオブジェクト指向なパターンを
「トリッキー」って言っちゃう人は、これを機にオブジェクト指向以外の道に進むべきだと思う
オブジェクト指向は全ての場合において完全な物であるわけじゃないし

>>55
違うな。
そもそも

ある問題を決められたパターンに当てはめる

という思考回路自体がオブジェクト指向的でないと俺は考える。

>>56
パターン自体はオブジェクト指向とは直交した概念でしょ。
デザインパターンはオブジェクト指向を前提としているが。
あと、「決められたパターンに当てはめる」わけじゃなく、
「パターンを参考にして実際の問題解決を行う」。

>>57
デザインパターンとオブジェクト指向は密接に関係していない部分も多いと思う
Balking とかは俺はよく使うけど、アレはオブジェクト指向抜きでも (やる気になれば) 適応できるし

void Done() {
    if (nonReady)
        return;
    // 処理
}

>>52
おまえ日本語でしゃべれ
あと、訳わかんない癖に首突っ込むな。迷惑だ

バカが自作自演で煽りあってるのが、笑えた。

あの〜GoF本と結城本にいつまで粘着なさるおつもりですか＞All

>>61
俺は (自分の中では) 粘着してないつもり。つもりになっているだけ。

リアルで話題が乏しい奴って、ほっときゃ５年でも１０年でも同じ話題で自作自演嵐やるから、
つまんね

つまんね

>>!53
> 『オブジェクト指向の設計論そのまんま ≒ これってデザパタ？』 になっちゃってるから
> 必要があれば 『名前』 と 『実装』 を切り離して考えるべきかもしれんね

ここんところはちょっと意味不明。　名前というのはパターン名のこと？
そうであれば切り離すのではなく、セットで考えた方がよいと思う。
GoFのデザパタ自体がオブジェクト指向言語の使用を前提にして考えられてるから、実装とは切り離せない。

> 「設計が優れているかどうか」 は 「デザパタになっているか」 とは無関係だし、
> そもそも全ての場合において優れている設計っていうのは無いし

ここはその通りだと思う。　設計の優劣を決めるために件のオブジェクト指向原則が存在するわけだし。
ただGoFの評価基準、すなわち「変化する概念をどのようにカプセル化するか？」という視点は、かなりオブジェクト指向のメリットとかぶっていると思うが（判ってない奴大杉）。

つーかここにちゃんと読んでがんがん使ってるやつはいるのか？

つまんね煽り（ぷ

>>65
＞ここんところはちょっと意味不明

ああ、ごめんなさい。
そのまま↓の「設計が〜」の下りに繋がっています。

「デザパタ (≒パターン名) が優れているんじゃなくて、設計が優れている (優れてないかもしれないけど)」
ってことなんで、そこを混同しちゃマズイかもって俺は思っています。

横から失礼
>>54=47さん、
「依存関係の逆転原則」が常識であるとの事ですが、
これどっから出てきた話ですか？俺は覚えがないです。
国内では平鍋さんの、判りにくいレトリックの文章しかみあたりませんでした

>>69
中身確認してないけど、いっぱい出てきた
ttp://www.google.com/search?num=50&hl=ja&inlang=ja&ie=Shift_JIS&oe=Shift_JIS&safe=off&c2coff=1&q=%88%CB%91%B6%8A%D6%8CW+%8Bt%93%5D%8C%B4%91%A5+%83I%83u%83W%83F%83N%83g&lr=lang_ja

ああ、デザパタMLでやってた話題ね。

http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/
「アジャイルソフトウェア開発の奥義」の「ソフトウェア原則」

単一責任の原則(SRP)
オープン・クローズドの原則(OCP)
リスコフの置換原則(LSP)
依存関係逆転の原則(DIP)
インタフェース分離の原則(ISP)
再利用・リリース等価の原則(REP)
全再利用の原則(CRP)
閉鎖性共通の原則(CCP)
非循環依存関係の原則(ADP)
安定依存の原則(SDP)
安定度・抽象度等価の原則(SAP)

俺はこの本買った覚えもないし、原書も読んでないはずなんだが、
ソフトウェア原則は覚えてる。どこで見たんだろう？アジャイル本？

いろんな本やサイトで
引用されまくりだからねぇ。

引用元明記しなくても誰も文句いわないくらい
流通しとりますな。

で、不毛な自作自演の続きは？

あとデザパタスレで、ソフトウェア原則を出典不明なまま出してきた理由も知りたいなｗ

自分の知らない原則を持ち出されたんでわめきたててる人がいるスレってここのことですか？

どこのどいつだ、その馬鹿は。
>>47さん、お話の続きをどうぞ

>>47
解決策じゃなくて 『解決の為の選択肢の１つ』 じゃないかな〜ニュアンス的に

小学校こくごのもんだいのようなきがしました(１年１組 >>1)

"Before I started studying martial arts, a punch was just a punch;
a kick was just a kick. After I started practicing martial arts,
a punch was more than a punch and a kick was more than a kick.
After I understood martial arts, a punch was a punch
and a kick was a kick."
Bruce Lee, Tao of Jeet Kune Do

http://c2.com/cgi/wiki?ThreeStagesInJeetKuneDo
http://c2.com/cgi/wiki?MartialArtsAsSoftwareDevelopmentMetaphor

理屈が身体に染み込むまで訓練しろ、
正しい道は、理屈と脊髄反射の中間にある

てな感じ？

「私がマーシャルアーツを学ぶ以前は、パンチはただのパンチであり、キックはただのキックでした。
マーシャルアーツの練習を始めたあとは、パンチはパンチ以上の何物かであり、キックはキック以上の何物かでした。
マーシャルアーツを極めたとき、パンチはパンチであり、キックはキックでした。」

何が言いたいのかさっぱり判りません。

ところでちょっと気になった事を一つ。
このスレ、Part1あたりと、Part３あたりから後、大体見たんだが、
このスレではもう「パターン・ランゲージ」の概念を主張すべきではない、ってな話になったんですか？

パターンランゲージでは、
・パターンは相互に関係があって、
・パターンだけを組み合わせても、ある程度、実用的な構築物 (建物、街)ができる
から「ランゲージ」なのだ、という理念もあったような気がしますが。

>>83は、>>84を読んだ方がいい。
英語が読めないならご愁傷様

スマソ、アンカーミスだ
>>83は、>>81を読んだ方がいい。
英語が読めないならご愁傷様

>>86
いま読んだよ。
スキルによってモノの相が変わって見えてくるのは当然ですが、なにか特別な含蓄があるんでしょうか？

>スキルによって
スキルじゃなくて“本質の理解”によって捉え方が変わってくるつうことな。

つーか、下手な東洋哲学（風）なんかひっぱってきてZENとかにかけて薀蓄たれている外人って、めちゃ薄っぺら。

>>87
自分がよくわかる分野に当てはめると、

勉強前：コーディングはただのコーディング
勉強中：コーティングはコーディング以上の何か
習得後：コーディングはコーディング

俺はなんとなく意味がわかるような気がするぞ。

釣はフナに始まり、フナに終わる・・・だっけ、釣り人の格言。

・・・釣られますた

つか、c2.comってpc8.2ch.net/techなみに逝かれた連中のスクツだな

>>90
勉強前：ｺｰﾄﾞはｺｰﾄﾞ
勉強中：ｺｰﾄﾞの背景にﾊﾟﾀｰﾝがある
勉強後：ｺｰﾄﾞとは、(ﾊﾟﾀｰﾝ織り込み済みの)ｺｰﾄﾞ

どうもちゃんと読んでがんがん使ってるやつはいないようだな

>90
そこがコーダーとハッカーの違いなんだろうね

お前等、まだこんな糞パターン使ってんのか？ｗ
もう誰も更新してないって言ってるだろｗ

で、不毛な自作自演の続きは？

まあ、誰も更新してないのは事実だからね。

単純馬鹿、最低これ読んどけ

デザインパターンと契約
ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
ソフトウェアアーキテクチャ -- ソフトウェア開発のためのパターン体系
Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects
プログラムデザインのためのパターン言語―Pattern Languages of Program Design選集
Pattern Languages of Program Design (Pattern Languages of Program Design)
Pattern Languages of Program Design 2 (Pattern Languages of Program Design)
Pattern Languages of Program Design 3 (Software Patterns Series)
Pattern Languages of Program Design 4 (Software Patterns Series)
アナリシスパターン―再利用可能なオブジェクトモデル
Enterprise Integration Patterns
Pattern of Enterprise Application Architecture
Refactoring to Pattern
Domain-Driven Design

またアンチの自演が始まるのか

おい>>98。
てめぇ文句は一人前だが、>>99のリストのうち何冊くらい目を通した？

２ちゃん煽り専従者風情がデカイ口を叩くなよ。屑

>>99
>ソフトウェアアーキテクチャ -- ソフトウェア開発のためのパターン体系
>アナリシスパターン―再利用可能なオブジェクトモデル
この２つ、ウンコ。
買ってから電車の中で読んで降りるときにゴミ箱に捨ててったぐらい。

ああそれ難しいからキミにはまだ理解できないんだな。
将来仕事を始めたら、良いﾊﾟﾀｰﾝ集として使えるから、
ゴミ箱から拾っておけ

>>103
あんなの社内に浸透するわけないじゃん。
こういうのは誰にでも理解できるようなものじゃなきゃ覚える意味無いんだよ。
みんなに普及しない。
これが致命的。
これだけで駄目だと言える。
他人の不勉強を指摘してプロジェクトが上手くいくならとっくにデスマーチなんてなくなってる。
そんなことはとっくに理解できてなきゃ駄目。
いい加減に大人になれ。
現実をみろ。
こういう本は駄目だろ。
わかりずらい。
それだけで駄目と言える。
そういう分野なんだよ。

ああ判ったから、学校ちゃんと卒業して、就職するまで取っとけ。

>>105
社会出てからレスかけよｗ

>>105
２ちゃんの職業煽り相手にマジレスｶｺｲｲ

>>105
知能低いの相手にすんな。どうせもしこんなのが職場に来ても、
適当に雑用頼んで最終的には追い出されるだけだろ？
>>104の文章のつたなさから見て、コイツはこの業界に入った事がないニートかフリータだ

>>108
現実みろ。
毎日９時から終電まで仕事してる奴にこんなもん勉強してる暇があるかアホ。
上流工程でのみ必要なんてアホなこといってるけど、こいつらはこいつらで書類書いて下流にまるなげするので精一杯だぞ。
全体に浸透しなきゃ使えない物なのに一部の人間しか理解できない。
こんなに使えない要素が詰まってるのにこんなもののどこに未来をみてるんだ？

なんだ、土方か。
相手して損した。
てめぇの生活が苦しいのはてめぇのせいだ。
がんばれ。じゃあな

>>110
はぁ〜仕事したことねぇのに開発手法なんて手出すなよｗ
何が正しいかわかんねぇだろ。

自作自演で荒らしてる馬鹿が居るな。

正直、方式設計も詳細設計もしないコーダーは、
設計や分析のためのﾊﾟﾀｰﾝなど、現場で使う必要ないかもしれない。
だから、特に向上心もなく一生コーダーやってくつもりなら、
上記の本読む必要はない。ただし、上記の分野にも口ばしつっこむな。迷惑だ。

もし向上心があるならば、目を通してみる事を薦める。
もし今読んで理解できないなら、それは修行不足だ。
現場なり、トレーニングなりで経験値をつんで、それからもう一度目を通してみろ。

お前ら全員マ板へ移動しろ、既に板違いだ。

>>111
きもい。一生ROMってろ

>>109
オブジェクト指向も構造化プログラミングもドキュメント自動生成もテスト自動化もリファクタリングも
コードの再利用もバージョン管理も、そもそもプログラミング言語すら否定する発言ですね。

>>112
当方ゲームＰＧですが、業務系のＰＧの実力は話になりませんなｗ
よろしければこちらの開発手法をお教えいたしましょうか？（笑）

>>115
そうだね。
現状をみる限り全く意味が無い。
やればやるだけクオリティが落ちてってるのが現状なんじゃないの？

>>117
さすが実務経験者の言葉は重みが違いますね。
もしよろしければ、>>109みたいな環境で有効な開発手法について
この若輩者にご教示頂けないでしょうか？

例えばアナパタ。
書いた本人も「多少偏執狂的で、後から見ると判りにくいﾊﾟﾀｰﾝかもしれない」
と言っている。

現場であんなの考える暇はない、と俺も思っていた。
ところがどっこい。世の中には暇もてあまして
際限のない桃源郷みたいな開発設計理念を持っちゃう
ユーザー企業担当者というのが居る。
その手のマニア相手する機会がきて、はじめてアナパタを読む気になった。

そしてアナパタについて、企業システムや計測システムといった分野で
同じような仕事を何年も繰り返し、なおかつオブジェクト指向的な分析設計を
真面目に考えると、あのような考え方が出てくるのだろうな、という結論を得た。

>>118
てめぇがまず意見だせ。

>>120は偽者だ。

私は社会経験もない未熟者なので、この時代にC++とかJavaとか
やってるのにデザパタすら理解できないバカしかいない糞会社つぶれてもいいんじゃねーの(ﾜﾗ
といった未熟な意見しか出せません(^^;

>>121
頭おかしいんじゃないの？自作自演嵐さん

>>123
そうですか。参考になります。
俺もアナパタはそんなに悪い本ではないと思いますが、
問題意識が特殊過ぎてついていくのが難しいと感じました。
きっと、関連する分野の仕事では、役立つのでしょうね。

ところで、NGワードに
　　ｗ
　　（笑）
　　^^;
　　お前ら
あたりを追加すればノイズを除去できます。ご参考まで

>>122
現場で仕事してから言ったほうがいいよ。
そんなの使ってる場合じゃないほどレベル低いところのが多いから。

>>124
ごめんなさい

>>125
それはバカが悪いんであってデザパタは悪くないのでは？
まあ理解できないからデザパタ使わないってのは、
無理にデザパタ押し付けて大変なことになるよりは賢明な判断ではあるが・・・・ｲｲﾉｶｿﾚﾃﾞ

>>125
さすが自称コンサルさんの言葉は重いな。
つーか、いい年こいてこれまでそんな事も知らなかったアンタ、恥ずかし過ぎ。

>>125
まったくそのとおりだぜ。

>>118
会社は選べよ。

>>112
同意。プログラムも仕事もした事ないようなのが大口叩き過ぎ

>>126
じゃあ、聞くけど。
一体どこの集団でデザパタなんて役に立つの？
前にもいったけど他人の勉強不足を指摘してそれでプロジェクトが成功するの？
ゲームＰＧだったとき３Ｄのプログラムが組めない奴が結構たくさんいたけど
そいつらに
「ゲームＰＧだったら３Ｄのプログラムぐらい組めるようになっとかなきゃ駄目でしょ」
って正論を叩きつけたところでプロジェクトは上手くいくの？
デザパタを知ってるのが当然みたいにいうけど、それを同僚に押し付けて上手くいった？
絶対、上手くいかないと思うよ。

頑張ってチャットプログラム作れ。じゃあな

>>130
ま、漏れは単なる学生なんで理想論になりがちなんだけど・・・・

>って正論を叩きつけたところでプロジェクトは上手くいくの？
いかないんだろうな、たぶん。じゃあそのかわりにどうすればいいんだ?
OOも構造化もポインタも構造体も使用禁止にする？

>>130
そういう場合どうしてる？
俺はさり気なく本を薦めたりしてるんだが、そもそも使ってる言語の仕様も理解してないやつがほとんどだからどうにもならん。

>>130
ここはプロジェクトではない。
ここは、ソフトウェアパターンに関心を持ち、自ら勉強しようという意志を持ったものが
意見交換する場だ。
「相手が何とかしてくれない」とか言い出すクレナイ厨は、遠慮がちに物をしゃべれ。

　　　　　　　　　　で、不毛な自作自演の続きは？

>>134
だから、如何に布教するか（あるいはそれ以外の方法）を話し合うのもありではないだろうか？
全否定は問題外だが。
自分ひとりが興味を持っても、周りが無関心じゃあ使いようが無いだろう。

>>136
貴方が信念を持って布教活動をしたいなら、どうぞ。
俺は、勉強会と意見交換で充分だと思う。
必要性を理解できない奴に押し売りしても、荒れるだけだ。例えば結城本。

>>136
ソフトウェア開発という分野でステータスを確立しながら(社長業じゃないよ)、
ML、勉強会、blogを通して進んだ考えの普及を図る。
付いてこない香具師や、誰も付いていかないリーダは、敗残者。

>>138
学会/業界の研究会活動や、コンテスト主催、OSSイベント通して布教活動やってる香具師が多いもなー

>>137-138
時間が無いっていってるのに時間が必要な提案するんですね。

とりあえず >>2-5, >>9, >>99に上がっている情報源を、
単にリンクとしてあげるだけじゃなく、初心者が読むべき順番とか、
あるいはそこで得られる情報の概要、感想なんかをまとめていってはどう？

ある程度分量が溜まったら、Wikiにうｐするという方向で

>>140 誤爆？つかキミは知らんかもしれんが、今日は日曜日だよん

>>141 賛成。

>>142
きっとそのお方は馬車馬のように消耗するだけの労働に従事されている方なんだ。
勉強する時間がない哀れな底辺労働者は放置しとけって

>>142
いまのギャグちょっとよくわからなかった。
もっと、文章にチンコとかマンコとか散りばめたほうがよく釣れると思う。

>>141
このスレの進め方は、それでいいと思う。

>>141
そだね。
102のように、未熟な状態で読んでもためにならないことってよくある。
読む順番を間違えるとお金と時間の無駄だ。
俺も最初に読んだときは糞本だと思ったのに1年後に読んだら良本だったって経験が。

じゃ誰か、とりあえず>>2-5, >>9, >>99について説明を書いていってくれ。
ネガティブな感想はとりあえず要らない。ポジティブに、ここがイイという売りがあるもんを優先的に・・・

>>9に何の情報があるってんだ？

じゃ誰か、とりあえず>>2-5, >>10, >>99について説明を書いていってくれ。
ネガティブな感想はとりあえず要らない。ポジティブに、ここがイイという売りがあるもんを優先的に・・・

まあ、読んで無いのがリンク貼ってるから出てこないと思うが少し待ってみるか・・・ｗ

>>150
本の良し悪しって、他の本も読んで読み比べたときに初めてわかるんじゃないだろうか。
俺はまだ感想が言えるほどの域には達しておりませむ・・・。

>>10
この中で読み物系(直ぐに理解できてなくても、何らかの示唆を与えて
くれる類の書籍)として楽しめる本てある？

アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/
アジャイルに関してはとりあえず興味ないんで、原則部分にどれくらい
ページが割かれてるか知りたいんだけど、その部分に絞ったレビュー
をしてくれる人は居ないかな？

>>153
その本、タイトルに偽りあり。
アジャイルなんて、ボーリングスコアプログラムの章くらいじゃない？
あとは原則と設計の話が殆ど。
だからアジャイルに興味ない人にはオススメ。

これと全く逆のバージョンが実践UMLな。
UMLうんぬんの設計ってより、RUPの話が主。

>>153-154
買います

>>153
原則部分のページの割合は計測不可能だなあ。

デザインパターンが出てくる所で
所謂パターン本と違って、コードを段階的に洗練させていって
その結果、このパターン使うといいぜ、みたいな感じで書いてあって
とても勉強になる。

その洗練させていく時に、そこここに原則が顔を出してるので
原則部分は全体に偏在してるといってよいです。

原則にしろパターンにしろ、カタログ的に紹介する本より
全然面白いです。ほんとおすすめ。値段も内容からすると安いと思うよ。
重いのが欠点。

>>154
ナイス！希望通りです。
読みこなせるかが多少不安ですが、実利より厚みのつもりで
読んでみようと思います。

>>156
願ったり叶ったりです。
問題と答え型の書籍だと、賢くなった気分だけは得られるん
ですが、実務ではちっとも活きてないって事になりがちなんでorz
解決していく過程、それも段階的に問題をクリアしていく型の
書籍は大好物ですｗ

重いのも欠点だけど、
書いた時期がバラバラだったらしく
章単位でJavaとC++が混在してるのが
ちょっちじゃまくさい。

>>69-73　masarl氏に感謝しなくっちゃだね。

> Robert C. Martinのオブジェクト指向の原則を、彼自身の本に先立って C++ Report 誌の記事からまとめたり、
> Bertrand Meyer のOCP(開放閉鎖原則) を使ってデザインパターンの本質を見極めたり、
> さらに、Kent Beck の JUnit Testing Framework の内部構造を紹介したり、という記事を
> 1999 年という非常に早い時期に行っています。
> まさに、日本のOOのアンテナであるとともに、その分かりやすく創意に満ちた文章で、日本には彼のファンが多く存在しています。

>>159
まさーるのページは消えましたがミラーがあるのでリンクします。
アジャイルソフトウェア開発の奥義日本語版に先立つこと５年ですか。
ある考え方が広まるのには時間がかかるんですね。

故　石井勝氏のWebページについて
http://www.morijp.com/aboutishii.html
まさーるのページ (ミラー)
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/index.html
デザインパターンとOpen-Closed Principle (1999/06/11更新)
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/dp-ocp.html
オブジェクト指向の法則集 (1999/07/07更新)
http://www.morijp.com/masarl/homepage3.nifty.com/masarl/article/oo-principles.html
Quick JUnit Plugin for Eclipse
http://quick-junit.sourceforge.jp/

GoFパターンの一部はDependncy Injectionパターンにする方が
テストしやすいだけでなく保守性も優れている事を
Seasar作者が指摘していますが、これもいずれ常識になって
生成に関するGoFパターンは古い設計とされるようになるでしょうか？

DIコンテナとデザインパターン
http://patterns-wg.fuka.info.waseda.ac.jp/study/8th-higa.pdf

masarlさんの訃報が届いてから、慌てて全ページを保存したのは私だけじゃないはず

どの本がお薦め？

同じプロジェクトチームのデザインパターン厨がウザイです。
最近、勉強したらしくて、うれしくてしょうがないみたいです。

同じプロジェクトチームのアンチデザインパターン厨がウザイです。 
最近、遅れをとったらしくて、うらやましがってしょうがないみたいです。

デザパタってよくある設計をカタログ化しただけだろ。
なんで優越感を持ったり嫌悪したりする必要があるんだ？

ザビエルは日本をマリアに捧げたらしい
勝手だと思わないか？
アメリカインディアンはインディアンと名付けられたらしい
勝手だと思わないか？
アメリカ大陸は新大陸らしい
勝手だと思わないか？
エスキモーもアイヌも自称じゃないらしい
勝手だと思わないか？
日本人は背が低くてぺこぺこするので倭なのだそうだ
勝手だと思わないか？

>>160
> GoFパターンの一部はDependncy Injectionパターンにする方が
> テストしやすいだけでなく保守性も優れている事を
> Seasar作者が指摘していますが、これもいずれ常識になって
> 生成に関するGoFパターンは古い設計とされるようになるでしょうか？
>
> DIコンテナとデザインパターン
> http://patterns-wg.fuka.info.waseda.ac.jp/study/8th-higa.pdf

ああ。それは最初にGoF読んだ時から気になってた。
型システムに対して敏感な人間は、
GoF生成パターンは単なる基礎と認識して
最初からDIっぽいコードを書くと思う。

相変わらずリンクを貼るだけ貼って、一言もコメントを書かない無能ばっかりだな。
意味が無いのがわからないのか？

朝から構ってクンとは悲惨だな

DIコンテナってリフレクションが使えないと無理なんじゃないの？

Erich Gamma on Flexibility and Reuse
    A Conversation with Erich Gamma, Part II   by Bill Venners (May 30, 2005)
    http://www.artima.com/lejava/articles/reuse.html

Summary:開発者はしばしば、ソフトウェアに対してどれくらいの柔軟性を与えるべきか、
　　　　　　という決断を迫られる。本インタビューは、画期的な著作「Design Patterns」の
　　　　　　共著者であるErich Gammaが、「開発者は柔軟性と再利用性に適応すべきである」
　　　　　　という彼の信念を語る。

How to Use Design Patterns
    A Conversation with Erich Gamma, Part I   by Bill Venners (May 23, 2005)
    http://www.artima.com/lejava/articles/gammadp.html

Summary:開発者が設計を考える時、デザインパターンはとてもポピュラーな手段である。
　　　　　　ところで、デザインパターンの正しい考え方とは、一体どのようなものだろうか？
　　　　　　本インタビューでは、画期的な著作「Design Patterns」の共著者 Erich Gammaが、
　　　　　　デザインパターンの正しい考え方、正しい使い方を語る。

Erich Gammaは1995年に、よく売れている本「Design Patterns: Elements of Reusable
Object-Oriented Software」(Addison-Wesley, 1995)の共著者として、
ソフトウェアの世界の舞台に登場した。
この画期的な成果は、Gang of Four (GoF)本としてよく参照されており、
設計上よくある問題に対する23種類のソリューションを、カタログとして提供している。
1998年には、Kent Beckと共同作業をしてJUnitを開発し、それはJavaコミュニティーの
標準的なユニットテスト・ツールとなった。
現在彼は IBM Distinguished Engineerとして、スイスのチューリッヒにある
IBM国際オブジェクト技術研究所 (OTI)に居る。彼は Eclipseコミュニティーでリーダーシップ
を発揮しており、EclipseプラットフォームのJava開発作業について責任のある地位にいる。

>>171
てか、君が読んでどう思ったのかを聞きたいんだけど？
それってただの宣伝文句ならべただけじゃないの？

技術本を読んだ感想ってのは、この問題について、
自分はこう考える（orこう考えていた）が著者はこう書いている。
また、それが良かったのか悪かったのか。
良かったらどうよかったのか？悪かったらどう悪かったのか？
を書くのであって、著者の実績だけをずらずら並べるものじゃないよ。

"Modern C++ Design"って何がいいたいんだかさっぱり判らないんですけど。
特に、ファンクタの解説。
原書が悪いのか訳が悪いのか俺のアタマが悪いのか？

「Command パターンの目的はオブジェクト中に要求をカプセル化することであるとされています。
Commandオブジェクトとは，そのコマンドを実際に実行する場所から遠く離れた所で用意されるものです。」

はぁ？

>>173
俺もわかんね。
俺からするとすげー無駄なことをやってる本に見える。

>>174
そういう文章が延々と続くのなｗ
俺には「つまりどういいのよ？」っておもっちゃうんだが。

>>172
自分で読んで感想書け。そしたら相手してやるから

わざわざデザパタ・スレを開いた人間が、
デザパタ共著者のインタビュー紹介に
「リンクだけ張るな。感想書け」なんて
キチガイじみた噛み付き方をするとは考えにくい。

従って、>>172は何にでも噛み付きゃウケルと思っている痛い人と判定。

あと>>173-176はいい加減、C++〜テンプレスレに移動したらどう？
みな迷惑にしか感じていないよ。

>>178
>みな迷惑にしか感じていないよ
２ちゃんでこれがわかるのは管理者ぐらいなわけだが、
どうしてそういう嘘を吐くのが当たり前になっちゃったの？

それにこっちがデザインパターンの話をしてるのに邪魔することないじゃん。
人に自分の技術を伝える術もないくせに出てこなくていいんだよ。
こっちはこっちで勝手にやるから、そっちも勝手にやってればいいじゃない。
なんでつっかかってくるんだよ。

いや、それ言っちゃかわいそうだよ。
>>172は英語を読めない人だから。
もし英語を読めてたら >>172のような
頓珍漢なレスは付けない筈。

可哀想だなぁ

>172
そりゃ、あんたがまだ読み込めるレベルに到達していないんじゃ……
確かに、Commandパターンがどんなものか知らないと>174は理解できないけどね。

>>179　
どうしたんだ？何か嫌な事でもあったのか？
頭がおかしい人間の書き込みに見えるぞ、お前の発言は。

>>179,>>181
お前のレスなんて読んでもねぇけど、
お前がカンカンになってる様子がわかって、面白い。

つまんねぇレス付けえてる暇があったら、さっさとErich Gammaのインタビューを
自動翻訳にでもかけてろ。中卒？

ひさびさに普通の、それもわりと頭の良い、知的労働に従事する人と
話をしたり食事をする機会があったのだが、やはり２ｃｈ的思考で現実を
みつめているいるようなおれとは全然ちがうね、余裕があるし、他者への
寛容があるよ。おれなんて攻撃性むきだしで、野良犬みたいな感じでくってかかって
たのに、彼らはそんなおれの頭もやさしくなでてくれたね。
やっぱもつべきものは金持ちの勝ち組ともだちだな！！！

>>181
判ったからさっさと消えろ。
Commandパターンを理解したいなら、さっさとギコ猫パターンでも探しとけ

>>174
一応ﾏｼﾞﾚｽしといてやろう。

デザパタ本嫁。

以上。

>184
いや、そんなの要らないけど……

>185
これ？ http://www.hyuki.com/dp/cat_Command.html
こっちの方がわけわからん……

「「今までに書いたコードの中で、この５行のヤツが最もイケてるな」ーC++はしばしばユーザーにそんなことを感じさせる言語です。」"Modern C++ Design"より

おれはお前の文章の中に１行でも理解できるヤツがあって欲しいと思っている。

おれ物凄く本読むの好きだし、学生時代はフッサールやハイデッガーなどの難解な書物も
それなりに理解できる方だったと思う。技術本だって英文だろうが日本文だろうがすらすら頭に入る。
しかし、"Modern C++ Design"(日本語版）は読めない。これは原書が悪いの？
訳書の問題であるならば、原書を買おうかと思うんだが。

> おれ物凄く本読むの好きだし、学生時代はフッサールやハイデッガーなどの難解な書物も
> それなりに理解できる方だったと思う。技術本だって英文だろうが日本文だろうがすらすら頭に入る。

>>189
ﾏｼﾞﾚｽすると、原書は知らんが訳書に問題は感じないぞ。
問題があるとすれば、それは読み手のレベルの問題だろうて。
フッサールやハイデッガーを引き合いに出してる時点でｱﾚだと思うがな。
C++を理解している哲学者がいるとは思えん。

>>191
>訳書に問題は感じないぞ。

見栄はるなって。

>>174
俺はその本読んでないんだが、そこだけ読むと確かに意味ワカンネだなｗ
多分、「依存や相関が限りなくゼロに近い＝遠く離れた所」という意味だと
は思うけど・・・・・・

>>178
何かに答えるでなし、単なるレス叩きなら要らない。
寧ろそういうレスの方を俺は迷惑に感じてる。

>>179
そっちはそっちで、こっちはこっちでという意見には賛成だが、それが分
かっているのなら、何故スルーしなのか？
ある文章を要約した時に、その主文が「お前は馬鹿」であるなら、もうそ
の文章について考える必要も反応する必要もないと思う。
流すとこは流して、淡々と勧めるの良さ気に感じるが、どうか？

原文はこれだな。
The Command pattern's intent is to encapsulate a request in an object.
A Command object is a piece of work that is stored away from its actual executor.

Commandパターンを理解できず、
またそれを勉強しようという意図もない人間が、
何故、書籍の一行にこだわり続けるのか？

意味不明だな。

Command パターンとは、
　　　　(例えばUndo処理のように、一連の処理手順を記録したり操作する目的で、
　　　　 最終的には処理オブジェクトへのメソッド呼出として実行される)
処理要求の内容を、一つのオブジェクト
　　　　(Commandオブジェクト)
の中にカプセル化したものです。

一つのCommandオブジェクトは、
実際の処理を行うオブジェクトから離れた所
　　　　(＝依存関係のないオブジェクト)
に格納された、
　　　　(一連の処理手順のうちの)
ひとかたまりの処理です
　　　　(＝ひとかたまりの処理に対応します)

デザパタに関して、一文だけを取り出して
・理解できる/できない、
・翻訳が良い悪い言い出すのは、
ナンセンスだと思う。

何故なら、その一文の前後には、おそらく
・何故そのパターンを説明するに至ったか(目的・動機)、
・そのパターンで何が得られるか(動機〜結果)、
・そのパターンの問題は何か(適用可能性)
・他にどのようなソリューションがあるか(関連するパターン)
が説明されているはずだから、である。

もし動機付けもなしに、いきなりパターンについて判りにくい短文が書かれているとしたら、
それは著者が対象とする読者は、GoF程度読んで理解している、という前提で書かれているのだろう。

ってこと。

>>193
「お前は馬鹿だ」という一文をきちんと受け止める事のできない奴は伸びないよ。

威勢はいいけどナイーブな>>193はどこへ逝った？

>>199
不勉強な割にナイーブなので、引きこもってます。

>>200
俺の周りにもいるよ。
大して努力してないのに、突っ込まれると凹むやつ。欝陶しいったらありゃしない。

あまりに馬鹿な発言をして、周りから引かれているのに気付かない >>201が悲惨

よく使うパターン、気に入っているパターンの使用例は何ですか？

>>197
たった１つのパターンで、
そんなのわざわざ覚えなきゃいけないの面倒臭いよ。
オブジェクト指向１つ覚えればいいほうがいいじゃん。

>>196
余計意味がわからなくなった。

>例えばUndo処理のように、一連の処理手順を記録したり操作する目的で、
この文から、もやもやする。
Undo処理で記録はわかるけど、操作って例えばどんなことを言ってるの？

>最終的には処理オブジェクトへのメソッド呼出として実行される
最終的ってのは何をはじめとしての最終的なの？
処理オブジェクト？処理オブジェクトとか勝手に出てきてるけどそれって何？
メソッドはわかるけどメソッド呼出がなんなのかわからない。
「処理オブジェクトへのメソッド呼出」って意味がわからない。

>依存関係のないオブジェクトに格納された、
何？依存関係の無いオブジェクトって？
例えばどんなもの？STLのstringとかって依存関係ない？

>一連の処理手順のうちの、
一連の処理手順ってなにを指すの？
Undo処理の個々の内容のこと？

>ひとかたまりの処理に対応します。
上がわからないと芋蔓式にまったくわからない内容だと思う。

>>203
趣味グラムだけど、最近はファクトリ(てか、DI)をメチャクチャ多用してる。
なにせ趣味グラムだから、予め決定してる部分が殆どない。更にこれで
完成という状態すら存在しないｗ
とにかく出来た部分から動かしたいし、何か要求が生まれた時にできる
だけ少ない手数でそれを叶えたい。
とか考えると、差分プログラミング的に適当な機能単位で接いだり外した
りできるDIの仕掛けが凄く便利。

>>205
お前もういいよ。才能ないから

わざとだろ
つまりただの構ってちゃん

>>205
例えばフォトレタッチツールで「イメージのリサイズ」「キャンバスの
リサイズ」なんていう機能単位をコマンドパターンで実装しておけば
各コマンドを担当するオブジェクトのインスタンスをスタックに積ん
でいくだけでUndoが実装できる。
あとGUIなメニューから適当なコマンドを実行するという実装も、そ
れを担当するオブジェクトをコールバックで突っ込めば済む。

>>205
196ではないが、
処理オブジェクトっていうのが
要するにパターンの名前になっているコマンドのことで
簡単に言うと
interface コマンド {
　何かする（）
　元に戻す（）
}
こんな感じのインターフェースを実装したオブジェクトのこと。
このインターフェースは、具体的に行われる作業には
全く依存していないというのが依存関係がないっていうことじゃない？

依存関係がないということがどれだけ素晴らしいことであるかは
多分他の人が説明してくれます。

相変わらず頭悪いのが粘着してるな。
頭悪い奴って、話題が10あったら、そのうち一つに粘着しだすから
本当に迷惑だ

デザパタに関して、一文だけを取り出して
・理解できる/できない、
・翻訳が良い/悪い
とか言い出すのは、 極めてナンセンスな行為だと思う。

何故なら、その一文の前後には、おそらく
・何故そのパターンを説明するに至ったか(目的・動機)、
・そのパターンで何が得られるか(動機〜結果)、
・そのパターンの問題は何か(適用可能性)
・他にどのようなソリューションがあるか(関連するパターン)
が説明されているはずだから、である。

もし動機付けもなしに、いきなりパターンについて判りにくい短文が書かれているとしたら、
それは著者が対象とする読者は、GoF程度読んで理解している、という前提で書かれているのだろう。

>>212
そう、それがデザパタの本質。

>>210
それって俺の普段の設計のやり方だとオブジェクトになるのって、
ずいぶん下流工程の話なんだけど、そんな下流工程の話をしているの？
デザパタって。

>>214
デザパタそのものが上流下流かなんて話は無意味。
まず適用範囲があって、そこに適用する。
その範囲がたまたま上流だったり下流だったりする。
GoFの裏表紙をぱらっと見ただけでも半分以上が下流のパターンで、
中にはそうでないのも混ざってる。

>>214-215　しりめつれつ

>>214
大粒度のコマンドパターンって存在できないと思うが・・・・・・
メメントやイテレータもそうだな。

シェルのコマンド一つ一つが実行可能モジュールになっているのは大粒度のコマンドパターンじゃないか？

あんたも Commandパターン好きだなぁ。

Commandパターンなんて、言語処理系の勉強した奴にとっては
随分粗雑な議論に過ぎないんだが。

>>218
なるほど、そういう視点はなかった。

オブジェクト指向で設計を考える人間にとっては邪魔だな
このパターンは。

オブジェクト指向がさっぱり分からなかったときに
本なんか片っ端から読み漁って
たまたまInterpreterパターンの実装を自分でやってみた時に
ピキーン！！
ときたわけ
つまりデザパタがオブジェクト指向の取っ掛かりになったんだけど
そーいう人って他にもいるじゃないかな？
みんなのピキーンを教えてくらさい

　　　　　　　　　　質問のフリ荒らし：書くことはないがスレの流れが気になって仕方なく
　　　　　　　　　　とりあえずスレ違いにはならないとおもわれる範囲で
　　　　　　　　　　質問・同意を得る形式でレスをすること。
　　　　　　　　　　答えがどうあろうとレス稼ぎが問題なので単発で終わることが多い。

適切なデザパタがあったら教えてくれ。

ＤＢにアクセスする部分をアプリから分離させ、１つのクラス(dao)にしてシングルトンにしている。
そのアプリがシンプルならそれでよかったんだけど、それなりの機能があるとそのdaoクラスがやたらめったらメソッドだらけになって肥大化してしまう。
なんとかしたい。

　　　　　　　　　　質問のフリ荒らし：書くことはないがスレの流れが気になって仕方なく
　　　　　　　　　　とりあえずスレ違いにはならないとおもわれる範囲で
　　　　　　　　　　質問・同意を得る形式でレスをすること。
　　　　　　　　　　答えがどうあろうとレス稼ぎが問題なので単発で終わることが多い。

>>224
つS2DAO

>>224
＞それなりの機能があるとそのdaoクラスがやたらめったらメソッドだらけになって肥大化してしまう

Facade と Command の折半を提案してみる
DB のアクセスレベルを高低２つに分けて、アクセスは 『アプリ → 高レベル → 低レベル → DB本体』 に
んで高レベルでは Command も併用してみるとか

高レベル側は Singleton じゃなくても別にいいでしょ

なんか知ってるパターンを並べただけで、
DAOすらよく知らないのが適当書いてるように見えるな。

・・・Singleton？はぁ？

高機能なDAOというのは、DAOではない。というあたりがキモだな

>>228
俺か？

そもそもパターンに当てはめるって考えるアプローチが、オブジェクト指向じゃないよね。
デザパタって。
デザパタはデザパタだな。
こんなミクロな部分なんて、正直、テキトーにやったっていいと思うよ。

ま、もちろん、悪いってことじゃないけど。

テキトーにやるのもめんどくさいからどっかの誰かが考えたパターンをそのまま適用するんだろうに。

ん？

>>そもそもパターンに当てはめるって考えるアプローチが、オブジェクト指向じゃないよね。

このスレでは、オブジェクト指向って一体何を意味しているんだ？

分からない人には何言っても無駄かと

>>234
対象物に則した実装を施すのがオブジェクト指向のはずだが？
パターンに当てはめるのとは明らかに違う。

>>236
＞対象物に則した実装を施すのがオブジェクト指向のはずだが？ 
かなり混同されやすいんだけど、オブジェクト指向には 『そういう一面もある』

>>236 の定義に則ると，Strategy パターンは オブジェクト指向で
State パターンはオブジェクト指向ではないと言う事か．

>>237
なにいってんの？
それ以外はないよ。

>>239
いや、それ以外が無くても別に良いんだけどさ

『対象物に則した実装を施す“ことが出来る”のがオブジェクト指向』 ってわけで
オブジェクト指向ってのは、詰まるところ 『構造体＋関数』 でしかないわけで


>>238
236 は、『オブジェクト指向に沿ったパターンはもちろんあるけど、パターンにはめて考えるのがオブジェクト指向ではない』
って言いたいのでは？
これには同意するけど

>　オブジェクト指向ってのは、詰まるところ『構造体＋関数』でしかないわけで
その認識はすごいと思った

>>241
余計なものを全廃すればの話ね。普段からこんな風に考えているわけじゃないです。

何でこのすれってこんな荒れてんの？

元々荒らしが立てたアンチスレだから

>>240
>236�は、『オブジェクト指向に沿ったパターンはもちろんあるけど、パターンにはめて考えるのがオブジェクト指向ではない』
>って言いたいのでは？
>これには同意するけど

そうだね．スマソ．
>>236 の
> パターンに当てはめるのとは明らかに違う。
はおいらも同意．



で，スレの流れが >>225 が予言した通りになってるわけだが（´･ω･`）

また頭悪い奴が荒らしてるな

誰が頭悪いのか分からない俺はもっと頭悪いですか？

腋臭の女の子とのセックスは極上に燃えるといっておこう。

誤爆

===============================================
注意！！！！頭おかしいのが粘着中
===============================================

>>240
> オブジェクト指向ってのは、詰まるところ 『構造体＋関数』 でしかないわけで

すごいな。お前。
じゃあ俺も言ってやろう。

オブジェクト指向ってのは、詰まるところ 『０と１で表現される２進数』 でしかないわけで

>>227
自分の作ったdaoからiBatis使っている（iBatisの部分をここに集めている）からそれと同じイメージだと思う。
自分のdaoを２階層にしてさらに階層を増やせばいいのかな。
参考になった。ありがと。

>>231
パターンに当てはめたいわけじゃなくて、俺が今かかえている問題の解決策として、
オブジェクト指向としてどう設計するのがいいのかが知りたかったわけ。
別にデザパタ名じゃなくても、お前でも誰でもわかりやすくソース書いて示してくれてもいいんだけど。

>>240
本とは、詰まるところ、紙とインクをたばねた物に過ぎないわけで。
人間とは、詰まるところ、飯食って大小便を出すに過ぎないわけで。

なんか知ってるパターンを並べただけで、
DAOすらよく知らないのが適当書いてるように見えるな。

・・・Singleton？はぁ？

>>254
分かった分かった。聞いてやるから。
で、DAOって何だよ。何を間違っているって？

その代わり、マイクロソフトのADOとかDAOとかの話をし出すなよ。

>>252
>パターンに当てはめたいわけじゃなくて、俺が今かかえている問題の解決策として、
>オブジェクト指向としてどう設計するのがいいのかが知りたかったわけ。
問題の解決策ってなに？
要するにどう設計したらいいのかわからんってことでしょ？

別にそういうのってマニュアルがあるわけじゃないよ。
パターンにあてはめたからってそれが正しいわけでもない。
とくにデザパタは俺からすればトリッキーな設計だと思う。

なんでトリッキーかというと中間的なオブジェクトが無駄に多い。
対象物の構造を素直にクラスで表現するのが一番いいと思うけどね。

そして、それってゆーのはその問題についてよく知ってる人じゃないとわからないよね。
結果的にパターンを一緒になることはあってもその逆のアプローチはまずいよ。

再利用性を高めよう、より一般的な形にしようとするほど
中間的なものが増えるのは仕方が無い。

>>257
設計するときに再利用を考えちゃ駄目。
再利用はオブジェクト指向で組んだときの結果でしかない。

＞ とくにデザパタは俺からすればトリッキーな設計だと思う。

とは言ってもおまえ流の設計よりみんなに知られているデザパタ
使った方が他人に易しいコードになる。

>>259
>とは言ってもおまえ流の設計よりみんなに知られているデザパタ
俺は転職多い方だけどデザパタを現場で使ってるところみたことないや。

それにそういう問題じゃなくて、
このアプローチってオブジェクト指向じゃないよね？

>>258
設計のときはそうかもしれんが、デザインパターンをまとめようとするときは再利用性や一般性を考えなきゃだめだろ。

OR-mappingとDAOを同一視してるアフォが常駐してるな。

そーゆー議論なら、それ用のスレでやれ
　Java⇔RDBのMapping-Frameworkを語るThre Vol.3
　http://pc8.2ch.net/test/read.cgi/tech/1090653286/

＞ 俺は転職多い方だけどデザパタを現場で使ってるところみたことないや。

ご愁傷様。

>>256
あー、いるよね。お前みたいなやつ。むかつくんだよ。
だからデザインパターン嫌いなら、ソースででも解決策しめせばいいのにさ。
それすらせずに

>そして、それってゆーのはその問題についてよく知ってる人じゃないとわからないよね。

だと？　ばかじゃねえの？

うんうん。とにかくお前がバカな事だけは分かったから。他のやつもそうだと思うな。
お前が他人の能力だとか才能だとか実力だとかを判断できねえだけじゃん。

おまえ、肩書きに弱いだろ。有名なメーカーの肩書き＝よく知っている人っていう固定観念でしか判断できない可哀想なやつだな。

読んでてよくわからんのだが、デザパタって「お約束の設計」じゃないの？
うまくいえないけど、「あー、あのやり方だよねぇ」って奴に共通の名詞を与えただけじゃないの？

「幽霊の、正体見たり、枯れ尾花」と一緒であやふやなものに名前をつけて理解の助けにしてるの
おいらたち凡人は毎回オリジナルの設計で悩むより「お約束」の設計メニューから使いやすい物をトッピングして使うほうが楽だし・・・

そうそう。>>265 に同意。

>>265
だから、それってオブジェクト指向じゃないじゃん。
オブジェクト指向で組むと毎回オリジナルなんだよ。
ただ、毎回オブジェクト指向の方針にのっとって設計をする。
そうすれば上手くいくっていう設計方針なんだから。

グリーンスパンの第10法則

　　すべての充分に複雑なCもしくはFortranのプログラムは、
　　後付けの、不完全な仕様とバグを持ち遅い、
　　CommonLispの半分の実装を含んでいる。

　一般に、難しい問題を説く必要があるなら、
　(a) パワフルな言語を使う
　(b) パワフルな言語と等価なインタプリタを書く
　(c) 自らがパワフルな言語の人間コンパイラとなる
という選択肢がある。
　ここで(c)コンパイラがやるべきことを人間がシミュレートするという習慣は
広範囲で行われている上、人間の思考を型にはめてしまう副作用がある。

　例えば、オブジェクト指向の世界では、非常によく「パターン」というのを耳にするだろう。
この「パターン」は多くの場合(c)のケース＝人間コンパイラが実際に動作している証拠
なんじゃないかと思う。

　もし自分のプログラムにパターンを見つけたら、それはどこかがおかしいというサインだ。
プログラムの形は、それが解く問題のみを反映すべきだ。
その他のシーケンスがコード中に現れるのは、
(a)(b)の立場からすれば、抽象化を行う言語レイヤーが不足しているということを意味する。
たいていの場合、それはマクロで書くべきコードを手で拡張している事になる。※

※学者が研究する言語はたいてい、静的型付けを基礎としているが、
　静的型付言語はマクロを排除する傾向がある。

>>265
>おいらたち凡人は毎回オリジナルの設計で悩むより「お約束」の設計メニューから使いやすい物をトッピングして使うほうが楽だし・・・
ところで、これホントに楽か？
例えば、君が俺のいる職場にきて仕事をするとして、
この仕事の仕方で始めにやらなきゃいけないことを想像してみろっての。

まず俺等が使ってる「お約束」を君は覚えなきゃいけないんだよ？
それは楽なことなの？
「お約束」の項目が２０００項目ありますので１週間で目を通してください。
って人がくるたびに毎回やるの？
不便じゃない？
取り決めがオブジェクト指向１つで済むならそのほうがすばらしいことだと思わないの？

デザパタはここですでに止まっている。
確かにデザパタを覚えたもの同士ならいいかもしれないが、
そうでない人と仕事をするときに全く役に立たない。

オブジェクト指向が流行りだしたのはそのお手軽さだと思うんだよね俺は。
パターンを覚えるのってどうなのかな。
パターンの当てはめ方も人によるところが大きいだろうし、その当てはめた結果が
正しいかどうかをオブジェクト指向から見て正しいかどうかを考えたとき大抵の場合
あんまり上手くないんじゃないかな。

>>270
パターン名だけで憶えて、パターン名だけでコミュニケーションを図るのもどうかと思う
１人がパターンを知っていれば、オブジェクト指向の範疇である構造は、他人とも共有できるし

アレですよ。デザパタは「構造」無しには語れないのですよ？

>>270
このスレで語るデザパタはGoFの23のパターンだろ。
おまいオリジナルの2000のパターンなんて覚えるだけムダ。

・・・デザパタは、さっさと言語仕様に吸収されるべき代物である

ただしここで言う「言語」は、JavaだC++だという汎用言語ではなく、
DBメンテ・アプリ言語とか、Webアプリケーション構築言語といった、
業務固有アプリと　汎用言語の間にある、フレームワーク相等の言語のこと。

>>270,>>272
まぁ、まともな開発者が到底受け入れない駄目開発規約を大量に作成する駄目プロジェクトや、
最低限のコーディングルールの主旨すら理解できず、頭の悪そうな規則遵守をしてくる駄目コーダも、
世の中には多いわけだがｗ

>そうすれば上手くいくっていう設計方針なんだから。
すげぇ。ドラえもんみたいだ。

なんだ、自作自演中か。

今回は流すとして、後でまともな議論ができるチャンスを探すわ。
アディオス・アミーゴ！！！！

>>277が会話に参加できないほどレベルが高かったかどうかについて

デザパタ主義者として他人の事なんて考えてもいませんわ

>>269
すばらしいことを言った。

>>279
それはつまりどういうことですか？

23のパターンが適用されているスレはここですか？

オブジェクト指向1つですむって？？？
オブジェクト指向は前提として成立してるんじゃないの？
デザパタってのはそのオブジェクトの作り方、組み合わせ方、並べ方じゃないの？

2000も「お約束」があるってそんなたくさん自分らで守ってるの？すっげーよ

>>283
オブジェクト指向使ってプログラム組んだことないっしょ？

みんなには
金儲けパターンを開発して欲しい

相変わらず頭おかしいのと、世界の中心でずれまくってるのが居付いてるな

きっとあれだよ。JavaかC++で簡単なプログラム作ってオブジェクト指向とか言っているんだよ。

例えばここにあるような会計ビッグバンの減損会計システムみたいな。
ttp://aransk.cocolog-nifty.com/whypro/cat2080136/index.html

>>265
最後の２行以外は同意するけど。

>>287
減損会計って言葉でキチガイのホムペ持ち出すとは、
あんた全然仕事できないバカだろう

なんだかオブジェクト指向を使ってオブジェクト指向を使ってとわめくオブジェクト指向をまったく理解してなさそうな奴が居る気がするんだが

ふと考えると、
オブジェクト指向を使うって
なんかヘンな気分だ

キチガイの人は、いつになったら無駄口叩くのやめるのかな

>>278は、もっと勉強したほうがいいよ

使えねースレだなおい

>>290
「毎回クラスを作るのがOOPなのでパターンなんて不要」な人の事かな？

>>290
大工の人が、「金槌を使って家を作った」とか「のこぎりを使って家を作った」とか言う姿を想像できん。
確かに使っているはずなんだけど、オブジェクト指向もそういう道具的な意味合いだと思っているので同意。

デザインパターンがオブジェクト指向に従ってない点については同意。

>>297
というよりも、オブジェクト指向に関わらないデザインパターンがあることは事実
デザインパターンの実装方法のひとつとしてオブジェクト指向が使われていると思っているので同意

　　　　　　　で、レスは一杯するけど頭が空っぽの彼は、



　　　　　　　いつになったら皆が引いてるのに気付くのかな。

もう気づいております orz

>>299
君はいつになったらオブジェクト指向が理解できるようになるのかなｗ
理解できないからこんなもんに妄信してるんでしょ？
オブジェクト指向が理解できていたら、デザパタなんて覚えないよ。

>>301
オブジェクト指向を妄信するのも如何なものかと

Strategyパターンと生成系パターンてさ、
コードの見易さはUPするけど、
「ifで条件判断して、適用するものを変化させる」
ってこと？
実装したメソッドやクラスを作成したら、それようの条件判断材料を容易して、
根っこの部分にif文追加。
って感じでつかんでOK?

よくわからんがな(´･ω･`)

>>302
オブジェクト指向言語を使ってるうちは妄信しとくよｗ

　　　　　　　で、レスは一杯するけど頭が空っぽの彼は、



　　　　　　　いつになったら皆が引いてるのに気付くのかな。

>>306
無駄な改行うざいよｗ

>>304
ごめ・・・Cやってた流れモノなんだけど、Cって関数(メソッド)ポインタ
ってのがあって、戻り値と引数を決めれば、メソッドを保持する変数(インターフェース？)
が作れるんだけど、イメージとしては　↓
ImageCollector　collector[][]　＝　//グローバル
｛
　　｛BMPからJPG作成、BMPからPNG作成、BMPから・・・｝//BMPから他のFORMATへ
　　｛JPGからBMP、JPGから・・・｝　　　　　　　　　　//JPGから・・・
｝；
みたいな感じでコレクションしてて、使いたい奴はそいつらをMAPで扱う
やり方ができるのね。
もしこんなリクエストきたら、[0][0]で。アレだったら[1][3]で
みたいな感じで切り替えできる。
似た感じ？
どこを修正すればいいのかを、分かりやすくしてるとか。。。

>>303
書いてることはわからんけど言いたいことはわかる。
俺、デザパタを感覚的にしか理解してない人間だけどそれでいいんじゃね？
入れ替えを容易にするのが利点だとおもう。

>>308
うん。まさにそんな感じ。
if とか switch 文を書かずに、参照の繋ぎ替えで解決するって感じで。

>>308
ごめ、よくわからん(´･ω･`)

>310
ｱﾙｪ！？わかるの？(´･ω･`)
僕のことはほっといていいです。

掲示板の仕組みよくわからんから両方sageっといた303．
みんなありがとう。ダッシュでJAVA本読んでコンパイルしまくってたら
interfaceって予約語見つけて、感動した(´・ω・｀)
やっぱオブジェクト指向の言葉知ってた方が理解も早いのかな。
でもデザインパターンて言語依存じゃないんだよね。実装はイロイロだし。
おっし、がんばろう。ありがとう(⊃д⊂)

ごめん。微妙にニュアンスが違っている気がする。


とりあえず、関数ポインタを繋ぎ変えて処理をカスタマイズするのは Strategy に似ている考え方です。
けど、

＞もしこんなリクエストきたら、[0][0]で。アレだったら[1][3]でみたいな感じで切り替えできる

ってのは、ちょっと違うかも。それは単に配列で処理を纏めただけで、結局は関数を直書きするのと変わらないですし。

mailにsageなのね。
＞＞もしこんなリクエストきたら、[0][0]で。アレだったら[1][3]でみたいな感じで切り替えできる
＞ってのは、ちょっと違うかも。それは単に配列で処理を纏めただけで、結局は関数を直書きするのと変わらないですし。
思いました。
で、
＞if とか switch 文を書かずに、参照の繋ぎ替えで解決するって感じで。
を読み返して、ガツーンと頭に反応ありました。
ありがとう(⊃д⊂)

C で Strategy の例を挙げるとしたら、コレが良いかもしれない。
    void qsort(void *base, size_t nelem, size_t width, int (*fcmp)(void *elem1, void *elem2));
この fcmp に色々な関数を繋げて処理を行うっていう感じで。

OOじゃない言語であえてデザパタを語ろうとする意図が不明。

>>313
俺もおまえの名前欄にも「sage」を入れるひた向きさに感動した。
がんばれ。いや、がんばろうぜ。うむ。interfaceはｽ的だよね。
汎用性を高めるのにも、多人数とかで開発するのにも使えて、かなり便利。

(´･ω･`)
Strategyは、実装する場所と実行する内容を切り離すのが肝なんだよぅ
ifとかswitchを無くすのが重要じゃなくて……

http://www.01-tec.com/document/cpp_design_pattern.html#Strategy
つか、正直わかりずらい。
何度読んでもやっぱり意図がつかめないのは俺が馬鹿だからじゃなくて
クラスの関連構造から意味がまったく見えてこないのが原因だと思う。
俺は分岐をするならするでしっかりifがあったほうが可読性が上がると思う。
こういう奇術を使うことになんの意味があるのか知りたい。

>>320
その例をStrategy使わずにifとswitchで書いてみ？

>>321
普通にかけるし。
どんな懸念事項があるっていうの？
少なくともこんなコードより可読性はグッと上がるよ。

>>322
> 普通にかけるし。
とりあえず、具体的にどんな感じになるのかきぼんぬ。

>>323
何がいいたいのかわからない。
こんなソースなんてそこまで重要な問題なの？
ifやswitchを使うほうがわかりやすいってそれだけじゃ駄目なの？

どうせならifやswitchで作るとこんな問題が出るはずだけど
これをわずらわしいとは思わない？

とかこんな感じで聞いてくれるといいんだけど？

？？？？

> ifやswitchを使うほうがわかりやすいってそれだけじゃ駄目なの？
そのほうがわかりにくい。

ということを説明しようと思って、まずはそっちのいう「わかりやすい」ソースに突っ込みを入れようかと思ったんだが
おまいが変な噛み付き方をするからするから

たとえばStrategy使わないとこんな感じか？

enum Strategy {Honjo,Hirosue}

class Apple {
　Strategy m_strategy;
　Apple(Strategy s) : m_strategy(s) {}
　void Answer_Put() {
　　switch(m_strategy) {
　　case Honjo:
　　　//なんとか
　　case Hirosue:
　　　//かんとか
　　}
　}
}
class Orange ....(以下同文)

と、ここまでに異論はないですか＞324

規模によりけりでしょ。
ifやswitchの方が読みやすい事もあるよそりゃ。
サンプルコードだと簡単すぎてメリットが判り難いんじゃない？

って俺も便利だから使おうなんて思うような局面ってないんだけど。

ってしらけることいってますかすみません。

重要なのは、新しいStrategyを追加する時に、
Appleクラスの中身を書き換える必要があるかないかだと思うのだが。

この辺が問題にならないようであればStrategyパターンを使う必要は特にない。と思う。

| ◎適用可能性
|
| Strategy パターンは次のような場合に利用する。
|
: snip
|
| ・クラスが多くの振る舞いを定義しており、これらがオペレーション内で
|　 複数の条件文として現れている場合。このとき、多くの条件文を利用
|　 する代わりに、条件分岐後の処理を Strategy クラスに移し換える。

>>330
なんで処理をクラスにしちゃうのかわからんね。
そういうクラスの作り方ってしたことないし、わかりにくいよ。
デザパタってオブジェクト指向完全無視ってクラスの作り方が気にいらねぇ。

age

夜の俺は昼の俺とは別人なのさ

ってのが state pattern

>>331
意味不明

>>334
なんで意味不明なんだよ。

| ・クラスが多くの振る舞いを定義しており、これらがオペレーション内で
|　 複数の条件文として現れている場合。このとき、多くの条件文を利用
|　 する代わりに、条件分岐後の処理を Strategy クラスに移し換える。

このアプローチ自体がおかしいと思わないのか？
完全に処理で見て、処理をまとめよう（整理しよう）としているじゃないか？
これのどこにオブジェクトがあるんだ？

これは誰が見ても完全にオブジェクト指向のアプローチでは無い。

interface Sort{
　　void sort();
}
class QuickSort implements Sort{ /* クイックソートで実装 */ }
class OrenoSort implements Sort{ /* あなたが考えた天才的なソート方法で実装 */ }

Sort s = new QuickSort(); //new OrenoSort();

とか作っておいて実装を切り替えやすくするのが利点なんじゃないの？
これも簡単すぎるから例が悪いけど。

あっ、Sortのインターフェースは適当ね。突っ込みどころ満載だから。

>>331
あー、つーかその前に処理をクラスにするのが気に入らないと。
よく読んでなかった。まあ、その手のいいソースみれば考え変わるかと。
Strategyほどいい手法はなかなかないと思うよ。

例えば、オセロのCPU作るとして、まず先にインターフェースだけ決めといて、
５人ぐらいでOrenoOseroCPUとかTanakaOseroCPUとかのクラスを実装して、
あとは new するところでOrenoOseroCPUとかTanakaOseroCPUとか切り替えるだけで
実装が入れ替わるとか。

>>337
設計が下手なんじゃね？
オセロって出てきたら、次にいきなりインターフェースなんて決めるところからは
始めないぜ。普通。
まず、どんなクラスが必要か？ってところから考えるだろ？
パターンに当てはめるって脳みそしかないからそんな変な方向へ曲がっていっちゃうんだよ。
いいソースもなにも処理から起こしたクラスにいいクラスもなにもないんだよ。
オブジェクト指向言語なんだから、少なくとも使い方は間違ってるだろ。

>>337
そこで、ストラテジーの生成はファクトリーパターンにすべきではないか？
いや、DIコンテナでIoCした方がより柔軟だ！
という話になって、>>335は更にぶちギレですよｗ

やっぱり、

デザパタ信者＝オブジェクト指向が理解できなかった奴

って俺の考えは正しいようだな。
まあ、自分には素質がねぇって諦めるのもいいかもしれんけど、
もうちょっと頑張ってみるべきだと思うよ。
でも、初見で理解できない奴には無理なのかなぁ・・・。

>>340
デザパタって一般にGOFのあの本の事でそ
あれ全部OOPなんだけど・・・なんか矛盾して無い？
も少し詳しくお願いしたい

>>340
主張の源は反転してるが、同じ事を>>335に対して感じたｗ

それはそれとして、どんどん具体性がなくなっていくのだけは
何とかならんか？
>>337の例に対して、本当のオブジェクト指向とやらではどう
実装するのが正しいと思う？
それを君が例示できるなら、両者を比較して利点と難点を話
し合う事もできる。
例示できるほどの引き出しがアレばだが･･････

>>341
ＯＯＰなんだけどもなにもアプローチが
基本から脱線しまくってるじゃねーか。
どんなに複雑だろうとなんだろうと、オブジェクト指向はオブジェクト指向だ。
基本理念は

現実にあるものの構造をそのままプログラムに反映することで
誰がみてもその構造を把握できやすいようにすること

だったはずだ。
要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
この基本は絶対に変わらない。
プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
無かったら真っ先に担当者を問い詰めることができる。
これがオブジェクト指向の単純な利点だ。

>>341
本来の意味での「オブジェクト指向」と
「オブジェクト指向言語の機能を利用した設計手法」がずれてきているんだよな。
俺には理想と現実のギャップとも感じられる。

GoFパターンとかJ2EEパターンはどちらかというと後者じゃないの？

>>335
処理をクラスにまとめなかったらどうするつもりよ？
クラスにまとめることで>>336みたいな切り替えが可能になると思うんだが。

>>342
実装はほとんど関係ないといっていいでしょ？
クラスさえ出しちゃえば後はだいたい誰が作っても同じ内容になるよ。
オセロを作るときにまずどんなクラスが必要になるかを考えるこれがオブジェクト指向の
正しいアプローチ。
この方向でならやるけど？

現実世界での物を設計でのオブジェクトにする第一世代のオブジェクト指向と、
オブジェクトをデータと処理の塊として設計の道具に使う第二世代以降の派閥が
あるってどっかで読んだ。

前者には後者はトリッキーで不純に見えるんだろうし、後者には前者は頭が
固いとしかみえんのだろう。

>>343-344
有難うございました。最近読んだ
http://www.amazon.co.jp/exec/obidos/ASIN/4822206653/249-3981734-3576308
に同様な見解がありました。自己無能再認識orz

とりあえずぐぐってみた。
ttp://www.rescomp.berkeley.edu/~hossman/cs263/paper.html
`` The first principle of object oriented programming might be called
intelligence encapsulation: view objects from outside to provide a natural metaphor of intrinsic behavior. ...
It follows that there is no way of opening up an object and looking at it's insides, or updating (``smashing'') its state.
What is more important is that the concept of opening up an object does not exist in the language.'' [Rentsch82]
この人的にはカプセル化が主眼のようですね。

>>349
そんな部分きちんとオブジェクト指向にのっとってクラス作れば
自然とうまくいっちまうのにな。

>>338
着手という処理はプレーヤーというオブジェクトとして定義できる。
そして、プレーヤーオブジェクトの変更余地は、他の何よりも大きいだろ
う事は直感で分かる。
だから、オセロというシステムに対して、プレーヤーオブジェクトの依存
性を下げておきたいと考えるのは自然。

>>346
どんな形でもどんな方向でも構わんよ。
今、覗きたいのは君が持ってる引き出しの中身だから、それが見えるだけ
の具体性があれば十分。

>完全に処理で見て、処理をまとめよう（整理しよう）としているじゃないか？
>これのどこにオブジェクトがあるんだ？
この前提は崩さずに例示してくれな。もしそれができるなら、それはそれ
で非常に興味深い方法論に成り得る。

>>351
おまい、本気でオブジェクト指向理解できない奴なのなｗ
じゃ、やりましょう。
ただし、明日ね。
今日はもう寝るｗ

まさに>>347だな。
デザパタはトリッキーだとか言われてる意味がようやく理解できた。

> 要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
> そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
> この基本は絶対に変わらない。
つまり、そもそもの「OOとは何か」という定義から違っているので、議論が平行線をたどるのは当然。

ただ、>>352にはぜひ具体的な例を示してもらいたい。
オセロの例でもなんでもいいんだが、デザパタといった｢間違った｣手法を使わない場合の設計とはいかなるのもなのか。

誰が誰だかわからんｗｗｗｗＩＤ導入してほしいｗｗ

>>338
うーん、確かに『オブジェクト指向は現実と当てはめる物』っていう考え方の場合、
デザパタはおかしなことを言っていると思う。

デザパタは、オブジェクト指向のための考え方というよりは、
プログラムを綺麗に設計するための道具と考えるほうがいいかもしれない。
なので、オブジェクト指向だからこうでなくてはいけないという前提で、
話合いをすると、いつまでたっても平行線なのでとりあえず今は忘れてもらえないだろうか。

>>353
＞つまり、そもそもの「OOとは何か」という定義から違っているので
うーん、というか言葉の定義を増やしてほしいよね。
「現実世界の物を設計でのオブジェクトにする」
↑これはもうOOでいいと思う。

「オブジェクトをデータと処理の塊として設計の道具に使う」
↑この考え方にまた新しい言葉の定義がほしい。

漏れも最初、オブジェクト指向とは、
「現実世界の物を設計でのオブジェクトにする」で覚えて、
後から「オブジェクトをデータと処理の塊として設計の道具に使う」を覚えたくちなので、
デザパタが「オブジェクト指向」って言われるとなんか違和感ある。

「これもオブジェクト指向なの？」って感じで。言葉の定義を増やしてほしい。

また変な人がしつこい自作自演をしてるな。

あのさ、ここはオブジェクト指向も判らんしデザパタも判らん初心者向けスレじゃないんだ。
あんたが「デザパタを理解してる人はオブジェクト指向を理解していない」とかいう変な信念を証明したいなら、
あんたのblogでやればいいだろ。

バカみたいな話を「デザパタ」スレで読まされる迷惑を考えろ！！！！！

>>355
>「オブジェクトをデータと処理の塊として設計の道具に使う」

デザイン指向と呼ぼう。

↓詭弁のガイドライン

>>347
なるほどね。結構当たっていると思うよ。
以前、（デザパタとは全く関係のないところで）同じような議論をした事がある。
前者は学者タイプで、後者がソフトウェア技術者ってことになった。

確かに自然界を見て、そこにオブジェクトを見いだすのは別にいいんだけど
（人間はほ乳類だー、ほ乳類は動物だーって感じで。）、
ソフトウェアを作る（システム設計をする）際にどうオブジェクト分析をして、どう設計していくかというのはまた別の話なわけです。
一言で言うと、視点が異なるから。同じようなものを作るのでも、その目的によって何をどういうようなオブジェクト（クラス）にするかが全く変わってくるのは当然な事ですから。
おもちゃ会社の販売管理システムを作るのにオセロの石クラスだとかはいらないし。

>>354
>デザパタは、オブジェクト指向のための考え方というよりは、
>プログラムを綺麗に設計するための道具と考えるほうがいいかもしれない。

そうだね。
オブジェクト指向言語でオブジェクト指向設計をする際の手法の１つというか、
オブジェクト指向を活用するための考え方というか。


デザパタ＝オブジェクト指向　じゃないからね。

オブジェクト指向が理解できていない＝＞デザパタを理解できない。　は正しい。

ただし、ここでいうオブジェクト指向は大学の学者のレポートにあるようなものとは違うって事に注意されたし。
ソフトウェア業界の用語だから。

理学と工学みたいなもんか。

おめぇら、素人議論はもうたくさんですよ

>>338
>オセロって出てきたら、次にいきなりインターフェースなんて
>決めるところからは始めないぜ。普通。
私ならまず大きな役割分担を考え、各役割についてさらに分割します。
オセロならゲームマスターとプレイヤーに分割、
ゲームマスターをルール判定とゲーム進行に分割、
プレイヤーを人間用UIとCPU思考ルーチンに種類分けします。
ゲームマスターとプレイヤー間のインタフェースは最初に決まります。

>>343
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。
そこでゲームフィールドとその中の物体という抽象化を思いつくと
コードを整理できます。

>>355
>「現実世界の物を設計でのオブジェクトにする」
具象オブジェクト指向
>「オブジェクトをデータと処理の塊として設計の道具に使う」
抽象オブジェクト指向

人同士のオセロ対戦ではゲームマスターはいませんが
ソフトウェアを設計するときにゲームマスターという
抽象化を行うことによってコードをきれいに分割できます。
抽象オブジェクト指向も現実を反映しているのですが、
抽象化による整理が行われているところが違います。

デザインパターンはクラスレベルの抽象化であり、
オブジェクト指向とは矛盾しないと考えます。

要は、オブジェクト指向原理主義者が提唱しているOOが
現実の物を投影した、まさに「オブジェクト」に主眼を置いているのに対し、

現在主流になっているソフトウェア技術者のいうOOが
「オブジェクト」から一段抽象化の度合いを上げ、
抽出した「役割／債務」を主眼に置いているってことだよな？

オセロの例で行くと、
前者が「オセロにはプレイヤーがいて、盤があり、石がある」
と設計していくのに対して、

後者は「戦略を考える役割、石を置く役割、勝敗を判定する役割がいるよね」
などと設計すると。

役割（振る舞い）主眼で設計していくから、「オマエラ馬鹿か？そんな処理（振る舞い）をクラスにまとめるなよ（プ」
って言われるんじゃまいか？

現在後者が流行っているのは、より抽象化度合いの高い「役割／債務」の方が再利用しやすいからだろう。
そして１０年前ですら「オブジェクト指向は"物事の本質"を設計／実装するものだ」と言われていたもんだ。


なのに未だに
> 基本理念は
>
> 現実にあるものの構造をそのままプログラムに反映することで
> 誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ
などと言い出してくる原理主義者は、
単に勉強することを忘れた頭の固い人間と言われても仕方がない罠。

なんだここ？
疾りお経病患者の巣窟？？

あぁぁぁぁぁ。なんか撚れた意見だな。
債務って・・・借金してるオブジェクトかよ！

・「役割／責務」を主眼に置いたOO：
　並列オブジェクト、Actor理論〜エージェント指向っぽい考え方だと思う。

・「なんでもオブジェクト」のOO：
　現実世界に存在する物理的実体や、
　役割/責務に限定せず、
　広く「概念」そのものもオブジェクトと考える。
　例：　Stateパターン・・・・・状態
　　　　Strategyパターン・・・戦略
　　　　Facadeパターン・・・・概念や機能の集約を通じた抽象化

後者にこそ、現在のオブジェクト指向の特徴が現れていると思う。

個人的意見としては、後者は物理的実態と各種の概念を、
全て同一の平面上に並べた混乱の極みだと感じることもある。
異なるレベルの概念を、型システムみたいなもので区別して扱うべきかなぁ、と。

ところで・・・
俺はもういいんだなｗ

やりたいならどうぞ。具体的なネタがあった方が面白いだろうし。

>364
＞>「現実世界の物を設計でのオブジェクトにする」
＞具象オブジェクト指向
＞>「オブジェクトをデータと処理の塊として設計の道具に使う」
＞抽象オブジェクト指向

m9('A') == "ｿﾚﾀﾞ";


＞デザインパターンはクラスレベルの抽象化であり、
＞オブジェクト指向とは矛盾しないと考えます。
なんかめっちゃ納得しました。
心のもやもやが取れました。ありがとう。

>>370
>「オブジェクトをデータと処理の塊として設計の道具に使う」
>抽象オブジェクト指向
これさ、もう、オブジェクト指向じゃないよなぁ。
なんか別の表現が必要だよな。

>>368
いいわけないだろ？具体的に語れ、て言うか逃げるなｗ

>>372
べつにいいけど、
なんか別の流れで進んでるし、
今出てくるのは場違いじゃね？
空気嫁ｗとかいわれそうだよｗ

>>373
いまこそ具体的なものを出す空気だ。

>>364
役割とか、そういうのに拘りすぎているような気がする

オセロをする人

　・1 Player
　・2 Player
　・COM Player (Low-Level)
　・COM Player (Medium-Level)
　・COM Player (High-Level)

んで、こいつらは全部 Player クラスのサブクラス

……これが Strategy だ


>>370
両方のアプローチを取らないと、設計できなさそうな罠
現実世界と抽象世界の仲介が、オブジェクト指向の使命ですから

>>371
確かになｗ。同じ『オブジェクト指向』という括りでも３６０度意味合いが違う。
って３６０度じゃ一緒じゃん。１８０度違う。

>>372
こっちから良い具体例が出せるといいんだけど。
俺としては、デザパタはいいものだと思っているから理解してもらいたいし、広く知ってもらいたいと思ってる。
お互いで理解しあえず馬鹿にし合ってもつまらんし。

ここはデザパタスレ。自作自演屑は去れ

>>376
構造化OO（pu

OOP と OOD を 混同している人がいるスレはここですか？
デザパタは OOP よりだと俺は思うけど

>>375
…わかりやすい例だね。↓の感じになるわけだ。

Player com;
if( 初心者レベル選択時 ){
　　com = new LowLevelComPlayer();
}else if( 中級者レベル選択時 ){
　　com = new MediumLevelComPlayer();
}else if( 上級者レベル選択時 ){
　　com = new HighLevelComPlayer();
}
//ここ以降はPlayerのメソッドだけ使うようにしてれば、ここ以降のソースの修正は不要になる
//『超上級者レベル』を追加したかったらPlayerのインターフェースを実装したクラスを作ってif文に追加すればいい
//また『超上級者レベル』のロジックを作成する人がここ以降のソースを意識しなくてもよくなる

これを普通に書くと
if( 初心者レベル選択時 ){
　　//初心者レベルの処理
}else if( 中級者レベル選択時 ){
　　//中級者レベルの処理
}else if( 上級者レベル選択時 ){
　　//上級者レベルの処理
}

・・・って、うーんあんま変わらんなぁ。この例だとうまく利点が説明できんｗｗｗごめｗｗｗ
まあ、ソースの見る範囲を限定することはできるかな。
あとロジックを修正する箇所がnewする部分だけでいいってところかな。

>>375,379
うわｗだっせー設計ｗ
はずかしくねぇのか？ｗ

>>380
うん。恥ずかしくない。

ちなみに、Player クラスは盤面情報を渡すと次コマを置く所を返してくる。

>>380
で、対案は？

>>381
はい、よくまとめました。
でもさ、よく考えろよ。
その数しかねぇんだぞ。
これ以上、バリエーションが増える予定が無いならなんでそんなところ
継承まで使って数の増える方向の汎用性を加える作り方をしてるんだ？
よしんば増えても５？１０？どっちにしろ大した数じゃないと思う。
汎用性の付け方が間違ってると思う。

やっぱり、クラスの意味を考えずにやたらめったらパターンに当てはめるのはよくないと思う。

>>383
＞その数しかねぇんだぞ

そうだな。Strategy を使うと実質上考えるべきクラスは親クラスである Player の１個だけだ。
これ以上減らせないし、これ以上増やしたくない。


＞やたらめったらパターンに当てはめるのはよくないと思う

同感。

>>383
そうだな。今回示した例の場合は、↓の程度。あまり例が良くなかった。
　・COM Player (Low-Level)
　・COM Player (Medium-Level)
　・COM Player (High-Level)
では、最強のオセロのCOMを作るといった理由で、
COMのロジックを世界中から募集するといった場合はどうだ？
こういう設計のほうがよくないか？
世界中の人間はPlayerというインターフェースを実装してメールで送ればいいわけだ。
それとももっと汎用的な案があるかな？


＞やっぱり、クラスの意味を考えずにやたらめったらパターンに当てはめるのはよくないと思う。
これについては同意。

>>383
Playerレベルで抽象化して同一のインタフェースを使うこで
振る舞いの追加・変更も非常に楽なんだが
そっち方向の有用性は無視？

＞やたらめったらパターンに当てはめるのはよくないと思う
これは同意

>>368
なんだ、ただの煽りだったのか。
反・デザパタの人がどんな設計をするのかははかなり興味があったんだが、
結局具体案は出ずじまい。「じゃ、やりましょう。ただし、明日ね。」(笑)
「俺はもういいんだな」(笑)。
なんで対案を出すのがそんなに嫌なんだ？

>>383
> やっぱり、クラスの意味を考えずにやたらめったらパターンに当てはめるのはよくないと思う。
これに反対する人間はいないだろう、どう考えても。

> これ以上、バリエーションが増える予定が無いならなんでそんなところ
> 継承まで使って数の増える方向の汎用性を加える作り方をしてるんだ？
> よしんば増えても５？１０？どっちにしろ大した数じゃないと思う。
だから増える予定なんだってば。
たとえそうじゃなくたって、ロジックはかえってシンプルになると思うんだが。
この設計がだめだというなら、どんな設計にすればいいと思う？

>>385
>COMのロジックを世界中から募集するといった場合はどうだ？
そんな場合にしか役に立たない設計が>>375,379だったわけだよｗ

>>388
あなたなら、どのような設計にしますか？

>>387
>反・デザパタの人がどんな設計をするのかははかなり興味があったんだが
ほいじゃあ、ちょっくらかこうか？
オセロでいいね？

……あのさ、Strategy って 「戦術を闇雲に増やす」 ってのが理想じゃないと思うんだ

今用意されている戦術のインターフェイス上の共通性を見つけ、「Strategy クラス」 を作成して、
「今用意されている戦術を切り替える」 のが目的じゃないのかと……

たしかに、新しい戦術を何時でも追加できるけどさ、
渡される情報以上の何かを要求する戦術を作りたい場合、要らぬ修正を被るじゃん

正直な感想だと、Strategy パターンを使わない方が簡潔に記述できる事の方が多いと思う。
簡単な条件分岐に、わざわざクラスを作成するまでも無いかと。

俺は、分岐した先に、個々のクラスを作成する価値を見出せたら Strategy を作ってますし。

>>388
つまり、世界中から募集するという名目では、
君でもあの設計は良い設計だと思うってことかな？
それとも、まだ君からしたらダサイ設計かな？

なんて低レベルなスレなんだ・・・

低レベル、っていうとハード寄りみたいな表現になっちゃいますね

>>393
それは設計の話をする場合としてはＮＧだろ？
設計なんてまともにできてりゃ後はトレードオフが重要なんだから。
この場面で世界中の〜っていう話を持ち出す時点でアウトでしょ？

ところで・・・
やっぱり俺はおよびじゃないんだなｗ

設計のマトモさは一概には決まらない。顧客の要求に応じて決まる。

http://sylphys.ddo.jp/upld2nd/news/img-box/img20050611151719.gif

誰が誰だかわからんｗｗｗｗｗ

>>396
つかね。デザインパターンって、
汎用的に設計しなくちゃいけない状況でしか効果を発揮しないんよ。
逆に使い捨てプログラムみたいなものを書くときにはデザパタなんて害にしかならない。

だから、『汎用的に設計しなくちゃいけない状況』を前提に話を進めないと意味がないんよ。

>>399
ﾃﾗﾜﾛｽｗｗｗｗｗｗｗ

>>397
対案が出せないんなら帰っていいよ。

つか、オセロのプログラムを組むっていう例が悪いとおもう。
デザパタなんてほとんど共通ライブラリを開発する技術みたいなもんだから、
オセロっていう具体的すぎるプログラムを書くときにはあまり必要ない気がする。


いや、オセロの話題を最初に振ったの俺なんだけどさ。

デザパタのまずいところは、パターンにあてはめようとしちゃうところだね。
最終的にできる設計は同じかもしれないけど、
そのアプローチのまずさはもっと認識されるべきだと思うね。

誰が誰だか本当に分からんな

>>400
＞汎用的に設計しなくちゃいけない状況でしか効果を発揮しない

それは違うと思う。汎用的な設計が望まれるのは低レベルのライブラリが精一杯。
高レベルにおいても、「ココは使った方が良いんじゃないか？」って場所で、積極的に使うべきでは？

……個人の気分と自己満足において

>>404
＞デザパタのまずいところは、パターンにあてはめようとしちゃうところだね
たしかに陥りやすい穴ですな。

デザパタが 『全ての場合において』 優れているのならば、
それこそホームページビルダーのテンプレートの如く、様々なパターンのテンプレートが用意されている筈であろうに。
用意されていない以上、これは成り立っていないと俺は認識している。

>>404
それはデザパタが悪いんじゃなくてデザパタを間違った場所に適用することに問題があるのでは？
「この場合はどういう設計をすればいいんだろう？｣「そうだ、このパターンを使える｣ってのがデザパタの目的であって、
｢この場合は何パターンを使えばいいんだろう？｣なんて言い出したら明らかに踏み外している。
というのが俺の理解なんですがどうですか。

>>407
じゃあ、なんのためのパターンなんですか？
って話にならない？

>405
＞……個人の気分と自己満足において
m9('A') == "ｿﾚﾀﾞ!!";
そこ重要。

>>407
＞｢この場合は何パターンを使えばいいんだろう？｣なんて言い出したら明らかに踏み外している。
m9('A') == "ﾅﾝｶ感動ｼﾀ";

やっぱりデザパタは駄目だな

>>407
＞｢この場合は何パターンを使えばいいんだろう？｣なんて言い出したら明らかに踏み外している。 

いや、この場合はコレを使った方が簡単になる「場合がある」って言うのならば良いんじゃないか？
かなり言い訳がましいが

>>408
> じゃあ、なんのためのパターンなんですか？
よく使われる設計をカタログ化しとくことに意味がないと？

オセロの話題だけど・・・（ゲーム全般？）
いきなり最初っからプレイヤーって変だと思う。
プレイヤーはあくまでひとつ。
COMの場合、自駒の数によっては「反撃」てな感じで使わないといけなくない？
observer←Strategyと　、command　←　State　←　Mementoを取り入れれば、
駒のひっくり返しと、1ターンの複数アルゴリズム適用って切り替えられるよね。

ってゲーム学校でCやってたときに作った、カードゲーム系で似たような処理書いた
覚えがある。
今は就職して業務系しかしてないけど、業務はそれなりにお客さんの要望をシステム化
（デザパタとか？）するのがおもしろいと感じてる

もう、パターンがある時点でパターンに当てはめるって思考回路しか育たないんだよ！

結論：デザパタ信者は糞

>>412
ないな。
だってよく使われる設計と本当に同じになるか検証する手間が
対象物の分析・設計をする手間と大して変わらないもの。

>>414
ふと思ったんだけど、「デザパタ最高！」 って思っている奴は居るのか？

>>415
本番になって初めてカタログを引くのではなく……考え方だけ憶えておいて流用汁

￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣｣
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |
　　　　　|　 　 　 　 | 　 　 　 　|　　 |
　　　　　|　 　 　 　 | ∧＿∧　|　　 |
　　　　　|　 　 　 　 |（　´∀｀）つ ミ |
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 | 　[デザパタ]
　 　 　 　￣￣￣￣'￣￣￣￣　 　 |
　 　 　 　 　 　 　 　　　　　　　　　　|
　　　　　　　　　　　　　こんなもんすてちまえ！

>>413
結局、COM である無しに関わらず Player は
　・現在の状況から、次にコマを置く場所を決め、盤面に通知する
ことしかしないし

COM で反撃とか入れるのは、個々のサブクラス内に隠しとけ

>>416
人に説明する共通言語としては便利だと思うけど、そのためにはGOFくらい有名じゃないと使えない。

とりあえず、デザパタを語るやつは使えない、これだけは確かだ。

>>416-417
＞「デザパタ最高！」 って思っている奴は居るのか？
俺、思ってないｗｗｗ
一部のパターン以外は、わけわかんねえもんｗｗｗ

一部のパターンは理解してるつもりだけど、
それらのパターンも、完全一致させてプログラム書いてるわけでもない。
良い考え方の部分だけ取り入れて書いてる。
なので↓の意見に激しく同意
＞考え方だけ憶えておいて流用汁

なんか話が散逸してきたな。

・デザパタは糞だよ派
　・考え方がパターン化されるよ派
　・あのパターンどもはオブジェクト指向に反しているよ派(トリッキー派)
　・普通のプログラマの知能ではデザパタは理解できないよ(だからデザパタは無駄だよ)派
・デザパタ便利だよ派
　・カタログ化されてると便利だよ派
　・名前をつけることに意味があるよ派

このスレで出てきたのは大体こんな感じか？

>>423
散逸しているのは昔から

ところで、「中立派」 も居れて欲しい。
「使えれば便利、けど使えなくても別にどうってことないし」 派みたいなのを。

>>424
「中立派２」 も居れて欲しい。
「デザパタなんて知らんけど、煽ると顔真っ赤にして反論してきておもしろい」 派みたいなのを。

>>425
｢低能な人｣カテゴリに分類しときました。

>>379
S2Container container = S2ContainerFactory.create(waste.dicon);
Player p1 = (Player)container.getComponent(p1Strategy);
Player p2 = (Player)container.getComponent(p2Strategy);
この部分はこれでPlayerの増加とは無関係に固定。

こんな実装してたら一部の人は劣化の如く怒り狂うんだろうなｗ
public interface Observer {
　public abstract void update(Board state);
　//Board stateはあまりにもな実装だが･･････
}
public class windowUI implements Observer {...}
public class consoleUI implements Observer {...}
public class networkUI implements Observer {...}
---
Observer observer = (Observer)container.getComponent("anyUI");

>>425
「中立派３」 も居れて欲しい。
「なんか最近太ってきてやせようとしたら、よけい太っちゃったｶﾜｲｿｽな人」 派みたいなのを。

既存クラス：public class AnotherAI {}
プレーヤーインターフェイス：public interface Player {}
アダプターパターン：public class AIPlayer extends AnotherAI implements Player {}
でも、実際には継承によるアダプターパターンてあまり使わないよな。
助長な気もするが実際ならこうしとくかな？
public interface Player {}
public abstract PlayerImpl implements Player {}
PlayerImplをテンプレートパターンにしとくと組み易そうだし？
アダプターパターンを使う際にはこうかな？
public class AIPlayer extends PlayerImpl {
　private AnotherAI ai;
　public AIPlayer() {
　　this.ai = new AnotherAI();
　}
}
別に無理やりデザパタに当て嵌めようとかじゃなくて、自然にこうなる気がするけど？

今日もキチガイが荒らしまくってるな。
もうプログラム技術板まるごと削除したらどうよ

Strategy一個で何百スレも費やす、荒らしのアホさ加減にはもううんざり。
こいつ絶対プログラムできねぇ奴だろ、こんなアホアホ議論に時間費やすようなバカなんだから

>>430-431
まあ少し落ち着け。そんなイライラしてるとハゲちゃうぞ。
誰かを叩くより、建設的に議論しようぜ。

>>429
・・・（´д｀；）？

>>429
ｱ━━━━(・∀・)━━━━!!
すでに AnotherAI という思考ルーチンを独自に作ってしまった場合に、
Playerインターフェースに適応させるためのことを言ってるのね。
なんのことかとおもた。

もうちょっとシンプルに↓でいいじゃね？テンプレパターン使ってそこまで汎用的にすることはないと思う。
public class AnotherAIPlayer implements Player {
　private AnotherAI ai;
　public AnotherAIPlayer() {
　　this.ai = new AnotherAI();
　}
}

>>431
デザパタ＝トリッキー論者が発狂中ｗ

荒らしは死ねよリアルで

>>435
でも、図星でしょ？そして、430=431だよね？ｗ

いやお前本当にキチガイみたいだから
早く病院戻れって。迷惑なんだよ

これでデザパタが全く役に立たないということが証明されたなｗ

http://www.google.com/url?sa=U&start=1&q=http://z-temp.hp.infoseek.co.jp/2ch/Prescott699-.html&e=10431

衝撃！！！！！(でもなんでもないけど)
年収４5００万プログラマーを自称し、
自作ＰＣ板を中心に活躍する、
人気のコメンテーター「◆Rb.XJ8VXow 」こと、
通称「録音」氏は Ｃ言語プログラミングは
おろかSIMD(MMX,SSEなどの処理系)を
SIMMと書き続け、 超超超初級
プログラム問題さえも解けない、
完全なプログラミング素人だった

これは自作板で録音氏が立てた、氏の愛するＣＰＵ、
Pentium4の新コアPrescottベタ誉めスレでその録音氏のつづる、
ハッタリとおとぼけのストーリーだ

とりあえずお前ら黙れ。
折角少しはまともになってきたとこなんだから、罵倒で流すな。
それとも流すのが目的か？

　700 ： ◆Rb.XJ8VXow ：04/04/18 01:08 ID:CE6MO5Gj
非常に高価なGUPでSIMM系の一部処理をする機能が付加されるからCPUではSIMM系の性能は不要だとする
アフォな意見があるのには驚かされる。
そもそも、導入コストを考えても両者は別の価値を持つ。
3Ｄ性能を追求する一部のゲームオタクの為だけに高価なGPUが存在しているとも言える状況下で
一般利用者には殆ど縁の無い高価なGPUを必須とするかのような論調はバカらしくもあり愚かだ。
そして、GPUそのものがそれにより高消費電力＆高発熱であるのならば尚更、特殊な人だけの為に存在し、
一般利用者には縁遠い存在であり続けていて欲しい。
その意味においてもCPUでのSIMM系能力とGPUのそれとは別価値であり同列に扱うものではないと言える。

706 ： ◆Rb.XJ8VXow ：04/04/18 01:41 ID:CE6MO5Gj
　>>705
　そういうこと。
　彼はＰ4（NetNetBurst）アーキテクチャをニッチだと言い切った御仁ですからね。
　SIMM系にシフトし、IPCを落としつつも時代の要請となっているメディア系処理へ最適化したアーキテクチャを
　ニッチだと称するのには衝撃を覚えた。
　Ｐ4発表以来、INTELの業績は好調でありＰＣも様々な進化を遂げた事実を無視するかのような意見が飛び出したわけだ。
　まぁ、確かに彼のようなプログラマにとってみればスカラ系の性能を犠牲にしたかのようなアーキテクチャを受け入れたくも
　無かったのであろうが、それにしても・・・であるな（笑

707 ：Socket774 ：04/04/18 01:47 ID:7pVk8vmJ
　>>700 あの、GPUをGUPと書いてるのは一回だけだからまだ間違いともとれるんですが
　SIMM処理って何度も書いてますけどなんスか。
　MMX SSE やなんかの複数データ処理のことなら
　SIMD(Single Instruction Multiple Data)スよね？

　ほかにもSISDとか言ったりはするけど
　SIMMと言うのは聞いたことないス。
　ちょっと前のメモリじゃないんだから。

708 ：Socket774 ：04/04/18 01:51 ID:m44rvYKP
　まぁ、彼の知能ではその辺が限界なんで、許してやれ

　

ID制てか強制フシアナ制キボーソ｡･ﾟ･(ﾉД`)･ﾟ･｡

つーかデザパタなんて頭悪過ぎるもん使うなよｗ

新しいスレを建てて、そこでその不毛な議論の続きをやってはどう？
そうすれば、誰も文句は言わないと思うよ。

>>447
不毛な議論っていうのはレス番の何番〜何番のことを言ってるの？

>>447
不毛でない議論のネタ振りをよろ

>>448
お前が関わってる話題全てだよ。

>>449
とにかく別スレ立ててそこでアンタの主張を書きゃええやん。
それで問題ナッシング

>>450
>お前が関わってる話題全てだよ。
じゃあ、このスレの８０％の話題がそうじゃん。
お前が出てった方が早いよ。
だいたい、デザパタ否定派だって肯定派だって
自分の設計スタイルを見直すいい議論になってると思うけどね。
本当に興味が無ければそもそもレスを付けない。

こういう議論を嫌がる奴ってのはそもそも他の人間の意見を受け入れる
心算が無いから人がなにやっててもうざったく感じるんだろうな。

はぁ？
このスレの50%の話題は俺が書いてるけど。
お前はハッタリばっかだな

デザインパターンとかにマジになってるやつ見ると、
ほんとこいつ頭悪いんだローなって思うよ。
「ここは＊＊＊パターンをつかうんだよ！とかいってるやつ」
ばっかじゃないｗ
だいたいその＊＊＊パターンの根拠はナンなんだよ、
俺が新しいパターンを作ってやるよっていうか
俺が書いたプログラムをパターンにすればいいだけジャン。
ばっかじゃね。

ヤバくなるとすぐに話題を逸らす
負け犬厨って >>453の事かね？

２ちゃん中で笑いものになってるらしいけどｗ

>>450
俺は何も主張していない。
ただ、君の不毛でない議論というのに興味があるだけ

まあ、みんな落ち着けよ。(-ω-)

>>446
ここはデザパタの議論をするために集まってるスレだと思うから、
文句いいたいだけで、議論する気がないなら去ったほうがいいと思うよ。

相手を中傷しても、中傷し返されるだけ、つーのはわかるだろ。
で言われたから、また言い返すの永久ループ。
そんな中傷言葉ばかり考える人生なんてつまらんだろ。
もっと建設的な人生を歩もうぜ。

うはｗｗ俺ｸｻｽｗｗｗ

デザインパターンは開発手法ではなく、設計手法の部類だろ。
それをわからずに煽ってる奴が多すぎる。
たぶんいままで設計なんて一度もやったことが無いんだろうな。

デザインパターンってさゴミだよ。
こんなので必死になってるバカはマジ笑える。
っていうかこれほどわらチャうコとってそうないよｗ

まあ、一生、相手を罵倒して生きていきたい！っていうならもう止めがな。



ファイ！（乂ﾟДﾟ）

>>457
少なくとも設計じゃねぇよ。
オブジェクト指向とも言い難いよ。
どっちかっていうと実装技術かなぁ・・・

デザパタが設計？？
これくらいわらチャうｺとってそう聞けないよｗｗ

うーん、設計は違うと思う。
かなり、コーディングよりな設計。
漏れも>>460の言う通り実装技術だと思うね。

お前さぁ、冷静に己を振り返ってみろ。
平日昼間から２ちゃんに居座って駄法螺を書き連ねたり、
3分間に4っつもレスを連投して自作自演したり(>>455-458)、
はたまた良スレと呼ばれるスレに居座って駄目スレにしまくったりする
キチガイはお前 >>459しか居ねぇだろ？

恥を知れ。
反省したら、もう二度とこのスレに粘着して荒らすな。

デザパタの正体をおしえてあげると。
つまり、理論にもうとければ、実装技術もないへたれが無理やり見出した
インチキ領域なんだよｗ

>>463
俺ッスカ（；´Д｀）
全部俺の自作自演デスカ（；´Д｀）

>>455,457,458
こんにちは。別人格の俺。

デザインパターンを利用したプログラミングと
オブジェクト指向に従ったプログラミングは一致しないのは同意。

でも、オブジェクト指向に則っていないからデザインパターンはダメっていうのはどうなの？
それってデザインパターンを否定する理由になるのかな？

いや、このスレ結構人いるよｗ
俺がちょっと他のスレ見にいってる間に結構レス増えてるしｗ

>>467
俺もｗｗｗ。Vipに言ってたら１６レスもついててびっくりしたよ。

>>466
オブジェクト指向言語（オブジェクト指向を実現するためにできた言語）での話だからなぁ。

>>465 ヨウ！ｗ
>>463
そりゃお前だ。
てか、お前は尻尾を出しすぎるから、直ぐに誰だか分かる。
デザパタ＝トリッキー論者君ｗ

はぁあ。
キチガイの自作自演ご苦労なこった。
この板もますます廃墟化が促進されているな

>>471
ここはキチガイ専用スレって事にして
別の名前でpart4立て直したらどうよ？
って、part3あたりから後全部廃棄して
part3からやり直した方がいいかｗ

私のために喧嘩はやめて！

デザパタこそ、プログラム分野におけるｷﾁｶﾞｲ荒らしであることに
気づいていないのかなｗ

>>472
その行動になんの意味が・・・？

>>466
でもなぁ...
実際には、オブジェクト指向言語っていっても、
オブジェクト指向に従うことを強制しない言語もたくさんあるよね。
そういう言語は邪道ってこと？

キチガイの隔離スレ

言語としては邪道どころか正道。

間違った orz
>>469ね

>>476
クラスがありゃ、一応オブジェクト指向言語になんじゃないの？
定義はようしらんけど。

信者って一切の反論を許さないから怖いよね

>>480
VBScriptはクラスあるけど厳しいのですよこれが。
継承とかないし。まあ、がんばれば多態性もできるけどちょとつらい。

まあ、VBScriptが世の中で使われているかどうかは置いといてですけど。

議論がますます低レベルになって参りました・・・

やっぱ中身のない人間が、ためにする議論してもやっぱ駄目だな（大笑

だからデザパタっていうのはへたれが作り出したインチキ領域で
同じようなへたれがそこに移りすんできてるだけｗ

>>481
反論に具体性がないから、結局は信者同士の会話になってしまい
最後には疎外感を感じた奴が暴れて有耶無耶になる。
いつものパターンじゃないか？

あれだな。
自分が理解できない、使いこなせない考え方はすべてクソといいたいんだな。

>>485　それはＧＯＦの何番目のパターンなの？

いやホント、デザパタ/OO叩き相手にマジレスしても不毛だよ。

ヤツはマジでCプログラムもできない屑だから。

デザインパターンが全ての人間にとって有益であるとは限らないことは分かったよ。
実際、このスレにはアンチ・デザインパターン論者もいるしね。

一方で、@ITみたいにデザインパターンの有効な利用方法とか紹介している技術系のサイトって結構あるよね。

で、デザインパターンそのものを否定する技術系サイトってあるかな？
もしあるなら何故デザインパターンがダメなのか勉強したい。

そんなん誰でもパターンなんか作れるだろ。
それなのにさ、「ここは＊＊＊パターンでしょ!」
っていうのを聞いてるともう噴出しそうになるよｗ

もう充分だよ、お前が顔真っ赤にして息荒くして、
涙すすりながらレス連投してるのが垣間見えてるよ。
だってお前のレス、中身ないじゃん。本当に可哀想なヤツだな

狂犬病みたいで、やぁねぇ

おやおやｗ

>>493
消えろクズ

おやおや、発狂しちゃたのかなｗ

減らず口しつけぇぞクズ

ﾜﾗﾜﾗ

おまえさぁ、煽りでは負けたことねぇとか言ってたけど
おまえが破綻しても破綻しても減らず口きき続けるから、
みんな呆れて放置しているだけなんだよ。

負け犬厨房さっさと死ねよ

理論になるほど形式化されているわけでもない、
かといって
実装に使える技術ってわけじゃない
単なるこういうパターンを（私は）見つけましたよ。
ってだけｗ
で、プログラムのﾌﾟの字も知らない連中が、これなら
おいらもわかるって感じで飛びついてるだけｗ

ツリー状のデータ構造を実現するにはどうすればいいか？

・OOデザパタ馬鹿

それはねえ、典型的なCompositeパターンでねえ、
抽象クラスを1つ定義して、それを派生して2つの具象クラスを定義して、、、(以下延々能書き続く)

・簡単なものは簡単に実現する普通のプログラマ

そんなもん、1行でできるよ。

type 'a tree = Leaf of 'a | Tree of 'a tree * 'a tree

実装完了。

>>498　誰かと間違えてるよｗ
いつもこんな調子で発狂させられてるのか・・・

Comparator って Strategy パターンですか？

ＭＬｷﾀｰｗ

学部で習うMLのコードが自慢とは痛いな。
プログラム板はいつ来ても、
低レベルな議論と、煽り厨房ばっかだな。
ホント呆れるよ。

夜中の２時３時まで
無意味なレスを書き続けるキチガイ、
数年前から常駐してたけど、
未だに居るんだな。寂しい人生だな（ﾌﾟｹﾞﾗｯﾁｮ

>>500
確かに、簡単に済ますことができればそれに勝るものはないよね。

でも実際は単純にツリー構造のみを作ればそれでよし！みたいな事はめったに無いし、
「ここは○○パターンを使うべきだ！」なんて偉そうなことを誰かが言ったからって、
デザインパターン自体の有益性が失われるわけではないよね？

勘違ド
１：デザパタ厨
２：ＭＬ厨
３：ＪＡＶＡ厨

>>500
仕事の現場だったら即動くもん作った後者の圧倒的勝利だよな。
口だけ馬鹿は現場に不要。とっととクビにすべし。

>>499
過去に一度でも具体的なコード例を示した事があるか？
あるならレス番晒してみ。
それどころか、>>321の問いにすらコードを例示できなかったろ？
もうその時点でプログラムのプの字も知らないのが誰かはハッキリしてる。

>>506
詭弁ｷﾀｰ
設定がそもそも間違えてる、ってか。ｗｗｗ

>>509
ﾏｼﾞﾚｽすると、ここで昨日一日煽ってたバカは、
>>439に書かれている通りの可哀想な人だから。
相手にするだけ時間の無駄、
正直あんたの粘着っぷりはスレ荒らしと同じ。

　　　　　デザパタ厨　←--互いに批判--→　ＭＬ厨
　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　JAVA厨（どっちつかずの立場）

　

>>509　>>453がはじめてだけどこのスレは？
いつもからかわれているんだねｗ

まぁ、MLとDPの対立なんて戯けた図式を描くのは、
本当に何も判ってない厨房なんだが

蛇どういう関係なんですか？

あれだろ、MLってメーリングリストのことだろ？

デザインパターンを否定すること自体は、ソース
(urlとか書籍、論文などオレサマ否定論以外なら何でもいい）
さえ示してくれれば素直にそれを読んで勉強するよ。

はっきりいってここのアンチ・デザインパターン論者は、

１．デザインパターンを理解できないから嫌い。
２．オレサマが理解できないものを常識のように使用しているヤツが嫌い

なだけだと思ったよ。

これを否定したいならソースを示してくれ。

DesignPは設計論の一部
MLは言語
対立も何もないだろ。

デザパタ馬鹿って能書きたれるか、きちんと動くものを作る人を「お前は何もわかってない馬鹿だ」と罵るしか能がないんだ。
これじゃあ現場で煙たがれるのも無理ないね。ｗ

だいたい、人の(正しく動く）実装もってきて、
これは設計がおかしい！
なんて平気な顔でいうのはデザパタ信者くらいだよｗ

>>517
つーか、お前は設計の話するのにいちいちソースが必要なのかとｗ

>>519
要するにソースを示すことすら出来ないと理解してよろしいですね？

>>522
なんで設計の話するのにソースが必要なんだ？
すっげー疑問。

普通のプログラマ → 言語や方法論なんて所詮は手段。目的はきちんと要求されたことを実現することだね。

自称アーキテクトOOデザパタ馬鹿 → OOにすること自体が目的。デザパタを使わなければならないと確信して疑わない。

あれだよ一種の創価学会みたいなもん。
みんなインチキだってことはわかってるけど、
うかつにはいえないってことだろ？

夜中の3時4時まで













　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　妄想議論乙


明日の朝はまた9時から煽るのかなｗ

ここは深夜もアツイデスネ

中身は空っぽだけどな

>>526
頼むから空白改行の連発レスはやめてくれ。
みんながみんな携帯でみてるわけじゃないんだよ。

設計を重視しないプログラマはこれから生き残れないよ。

わかった、プログラムのプの字も知らないやからに説明するための言語がＵＭＬなんだ！

>>524 言語や方法論なんて所詮は手段。

同意。
でも、その手段の選択肢のうちにオブジェクト指向やデザインパターンが含まれる人もいます。
その人がデザインパターンを使用して目的を達成することを否定はしませんよね？

何が手段で何が目的化なんて相対的なもの。
どのような物だって手段になりうる。
無駄な議論

>>532
自転車で海を渡るつもりか？ｗ

>>533
問題に適した方法を選択せよということですね？

それは、問題の解決方法としてオブジェクト指向やデザインパターンを選択するのは愚かなことだと
決め付けることも無駄な議論であるということですよね？

>>534
それはあなたがやってください。

>>535
まあ、似たようなことをあなたがやるというので止めはしませんよｗ

>>534
public class Bicycle implements Swim {}
うむ、なんの問題もないな。

て言うか、こういうハチャメチャなインターフェイスの
利用例は実在する＿|￣|○||| 冗談になってない･･････

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　夜中の3時4時まで













　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　妄想議論乙







　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　明日の朝はまた9時から煽るのかなｗ

>>538
予定通りはじまらなかったからって心配するなよｗ

>>476
それ普通でしょ。
Cなんかの構造化言語でも、構造化せずにプログラミングしようと思えばできるし、
別の言語であろうと自分でサブルーチンとか関数とかつくらずにだらだらと書こうと思えばかける。

構造化とかまともに理解できていないやつが書けばそうなる。
オブジェクト指向もデザパタも一緒だと思う。

構造化言語は構造化がサポートされた言語で、オブジェクト指向言語はオブジェクト指向化がサポートされた言語にすぎない。

>>520
> だいたい、人の(正しく動く）実装もってきて、
> これは設計がおかしい！
> なんて平気な顔でいうのはデザパタ信者くらいだよｗ

俺は「これは設計がおかしい！」ってよく言う人間だなあ。
拡張できない融通の利かない設計は間違っているね。

例えばじゃんけんで、ぐーちょきぱーしかないという前提で設計・実装するのはいいんだけど、
右手でしかじゃんけんしないっていう前提で設計・実装されていると、こいつはバカが設計したんだなと思う。
その場だけ正しく動くんで満足してるだけじゃあ、しろうとレベル。デザパタどうこうは関係ない。

結論：｢愚かさに限界はない｣｢バカと議論が成立すると思っている人間はバカ」

>>541
>ぐーちょきぱーしかないという前提で設計・実装するのはいいんだけど
俺の作ったジャンケンゲームのいなかチョキに攻撃力＋１が入ってることはみんなにはナイショだｗ

結局キチガイの起床時間は9:30と。

あぁ〜キチガイキチガイ

デザパタって要は厨の自己満足のためにあるんでしょ？

----------------------終了----------------------

>>546
そろそろこの荒らし野郎通報していいか？

>>547
いいよ。通報したらしたで、またくだらない会話が続くだけだろ。
あんま煽るなよ。子供のケンカみたいだぞ。

>>548
つーか、この改行がうぜぇ。
さっさとアク禁にしちまった方が楽でいいような気がする。
まあ、プロバイダ解約ぐらいじゃ荒らしなんて辞めないだろうが
次のプロバイダと契約手続きしてる間ぐらいなら止むだろ。

荒らすな

ここでデザパタ叩きやってるやつは最低でも
・GoF本
・リファクタリング
・CODE COMPLETE
くらいは読んでるんだろーな？
（擁護派でも読んだことなさそうな人もいるけど…）

Code Completeは無関係だと思うけど

>517
>521-523
「ソース」を双方別の意味で使ってるように思う。
517,522が言ってる「ソース」は「情報源」
521,523が言ってる「ソース」は「ソースコード」って意味じゃない？

それだったらこのやり取りも納得できるんだけど。
確かにデザパタがそれ以前の手法より優れていることを説明する文献は多いけど、
デザインパターンが他の手法より劣っていることを説明するものは聞いたことが無いからね。

>552
デザパタそのものを説明した本ではないけど、
本文中に触れているところはあるよ。

持ってたら2部5章の5.3.8(P.125)に書いてあるから。あ、第2版（上）ね。

>>553
情報源が多い方が完全に正しいと？
君がいいたいことはそういうこと？

俺はこの手の話は学会の奴等より、２ちゃんの方が進んでるぐらいだと思う。
デザパタなんて所詮エセ研究者どもが論文として書き易いだけの代物だっただけ。

そもそもデザパタを書いた集団とやらは、
根本のオブジェクト指向の理解さえ怪しいってのが俺の考え。

＃これ↓は偏見だがｗ
＃傾向としてな、昔っから組んでる奴ってのはオブジェクト指向を理解できない奴のが多い。
＃大学（日本の）の研究者どもでオブジェクト指向を理解できてる奴なんて０だといいきれるｗ（体質だからね）

デザインパターンに関する技術的な話題と、
プロジェクトにデザインパターンを導入するときのプロジェクト・マネジメントに
関する話題がごっちゃになっているような気がします。

おそらく、ここのアンチ・デザパタ派はプロジェクトリーダーに恵まれていないのでしょう。
デザパタを理解していない人に対し、それを常識のごとく要求し、
それが理解出来ないと馬鹿にするような人はたまに見かけます。

しかしだからといってデザインパターン自体に罪は無い。
デザパタ使うヤツは嫌なヤツしかいないと思い込んでるのかもしれないけど、
それはデザインパターン自体を否定する理由にはなりえません。

で、プロジェクトにデザインパターンを導入する際のマネジメント上の問題も重要なんだけど、
このスレでは技術的な話題に限定した議論をしたいと思うんだけど、どう？

>>555
>　根本のオブジェクト指向の理解さえ怪しいってのが俺の考え。
>>347　>>353　>>359　>>365

>>557
俺もかー。
俺の理解がどう間違っているのか説明希望。

>>556
>しかしだからといってデザインパターン自体に罪は無い。
俺は人が理解しずらいものを共通認識物にする事自体が無謀だと思うんだけどな。
共通認識物に５００ページってどうよ？

>>553
> 情報源が多い方が完全に正しいと？ 
> 君がいいたいことはそういうこと？ 
全然違います。
「デザパタなんて只の紛い物」という主張を納得させてくれるものであれば
何でも構わないんだって。それこそ君が熱弁を揮ってくれてもいい。

あ、感情的な言葉を使うのは勘弁してくれ。
「デザパタなんて」「所詮」「エセ研究者ども」「書き易いだけの代物」
どう考えても相手を説得する言葉ではないな。ただ反発してるだけ。

間違えた…orz

>>555
だったな。

>>558
いや、この辺嫁って意味であってこいつらが間違ってるぜーって意味じゃないヨー

>>559
でも理解できる人もいるわけですし...
それにGoFの人たちも万人向けに書籍を書いたわけでもないでしょう。

また少々古い情報ですが、実際のプロジェクトでも利用されていますよ。
ttp://www.atmarkit.co.jp/fjava/devs/survey/survey0305/survey0305.html

>>563
>現在最も使われているのは「Singleton」パターンだった
もう駄目かもしれんね

>>563
使われてる例だけとってきてだから何？って感じ。
この業界、適用実績なんて意味ねぇんだよ。
デザパタ肯定派の人ってこういう馬鹿なの多いね。
自分の言葉で語れないならレスつけんなよ。
２ちゃんこなくていいからｗ

>>564
まぁ少々古い統計ですし...
でもSingletonが一番理解しやすいせいもあるでしょうね。

Singletonをグローバル変数と全く同一視している人には、
グローバル変数を使うなんて設計が悪い！みたいに言われてしまいますが、
グローバル変数に問題があるからこそSingletonパターンが作られたともいえるわけですから、
Singletonが一番使われていることを問題視することも無いでしょう。

シングルトンとFWパターンとの関係を考えよう

>>565
自分の言葉で語ってその文章なのであれば、
もうちょっと丸くなることをお勧めしますｗ

いや確かに、適用実績見せられただけで納得するようであれば
それはそれで技術者としては問題ありだと思うけども。
そういう意味では同意。

>>566
意味わかんないだけど？
どういうこと？
Singleton自体がグローバル変数みたいにしか使い道ないじゃん。

こんなやるべきでない悪しき実装を広めたデザパタは糞。
ほんっと糞。わけわかんない。いいと思ってんのかコレ？
このパターン考えた奴、相当な馬鹿だろ。

なんでグローバル変数がやるべきではないこと？

＞ Singleton自体がグローバル変数みたいにしか使い道ないじゃん。
アフォ発見。
ビジネスロジックの実装に普通に使ってるが？

Stateless SessionBeanの実装やSpringなどのDIコンテナも
シングルトンオブジェクトを生成するパターンだ。

>>571
>ビジネスロジックの実装に普通に使ってるが？
使ってるからどうしたの？ん？
日本語で会話してるのか不思議になるよｗ

>>572
そんな詰まらんところつついていないで
議論の中枢を語れよ
語れない？負けだ

>>571
とりあえず、Singleton使ってるってだけで馬鹿だと
気が付けないような馬鹿が俺と同じ立場で会話してること自体がスゲーむかつく。

>>574
だからさ、「シングルトンとFWパターンとの関係を考えよう 」に答えてよ
コレで君の理解度が分かる

ホント、なんのためのオブジェクト指向なのかとか全て吹き飛ばしてくれる馬鹿っぷりだよ。
すべての設計手法はグローバル変数は悪ということが前提にある。
なんでかわからないか？説明してやろうか？ん？

singletonを使うと変数のアクセスに対して制限かけれるじゃん。
アクセサのところでどのように使われてるかログを簡単に仕込めるし。
グローバル変数と比べればずっとマシ。
まぁグローバル変数の替わりに乱用するのは確かに良くないけど。

…ていうか、適用実績で語らず、利点で語ってくれ。

>>576
だからさ、「シングルトンとFWパターンとの関係を考えよう 」に答えてよ
コレで君の理解度が分かる

シングルトンを多用するとグローバル変数の弊害ばかりがでるというのは正しい。
だから使わなくてすむものなら使わないほうがいい。

でも、唯一のグローバル変数を、多数のインスタンスで共有しなければならない
状況というのは、多かれ少なかれ避けられないわけで、そういう場合にやむを得
ず使うのがシングルトンパターン。

> Singleton自体がグローバル変数みたいにしか使い道ないじゃん。
継承できるのが最大の利点なんだが

だれも、シングルトンとFWの両パターンに継承関係があることを知らないようだな
否定する奴もそうでない奴も・・・
分かる奴なら話出た時点で即語るんだけどな
所詮その程度の知識でしか語っていないんだなおまえらって
つーか2chのレベルはやっぱ低い

真上に出てるような

継承は利点だけど、本質的な欠点は残るわけで････

>>582
その継承ってソース中に出てくる『extends』のことだろ

妙なやつが沸いたな。

シングルトン駄目っていう人はDBのデータソース引っ張って来るコードどうやって書いているんだろう・・・
毎回lookupなんて明らかにおかしいですよね？

pattern Singleton extends FlyWeightってことですわ

だから、SingletonとFlyWeightを別のページで解説している本は捨てろ
そんな著者は本質を理解していないからな

GOFも破棄？

デザパタ自体を放棄だよｗ

>>581
なんで初っ端から煽り口調なの？凄く興味深い話なだけに、もそっと
丁寧に語ってほしい(´･ω･｀)ｼｮﾎﾞｰﾝ

あるハードウェア郡の状態を保持する為に、シングルトンオブジェク
トを生成するファクトリを書いた事があるんだけど、もしかしてこれっ
てフライウェイトパターンになってる？
今の今までフライウェイトパターンを意識して使った事は一度もない
んで、なにか面白いTIPSがあるならぜひ聞きたい。

シングルトンダメな人は、値を保持しない、処理のみのオブジェクトも
毎回インスタンス生成するの？

>>591
群をまとめたことについてはおいといて。

フライトウェイトは、リソースの大きなものや、いちいちインスタンス化すると
オーバヘッドが大きいソフトウェアリソースを共有するためのパターン。
シングルトンの一種ではあるけど、目的が明確化されている。

＞＞592おれもそれが聞きたいんだよ

＞シングルトン駄目っていう人はDBのデータソース引っ張って来るコードどうやって書いているんだろう・・・
＞毎回lookupなんて明らかにおかしいですよね？

>>591 の例は、リソースの節約が目的ではなく、唯一のリソースを
共有する手段としてのシングルトンなのでフライトウェイトとは言わない。

>>592>>594
あれだな。ひとづてに「Singletonはよくないよ〜」とか聞いて
それを鵜呑みにしてるんだろ。

1.Singletonは取得が楽
2.馬鹿が多用する
3.良くないコード氾濫（良くないコードがいまいち思いつかないけど・・・）
4.それを見てSingletonダメダメ説

つまり、分かっていない人に使わせると良くないという意味があるのかな

>>595(593)
なるほど、フライウェイトという命名から言っても確かにそうですね。
え〜っと、それでなんですが、フライウェイトの主眼はシングルトンを生成する
ファクトリという構造部分にではなく、シングルトンの生成に対するルール(リソ
ースの削減)の方にあるって理解で合ってます？

>>598
多分あってる。

シングルトンは手段に注目
フライトウェイトは目的に注目

大体情報工学なんてものは理系のフリした文系のための学問であって、理論もクソもない。
デザパタもそういう負の産物。

情報科学、計算機科学→数理系
計算機工学→工学系
情報工学→工学系
--------------------------------
ソフトウエア工学→文系

書籍スレ荒らしてたのと同一人物だったのか

ソフトウェア工学(笑)

>>569
> Singleton自体がグローバル変数みたいにしか使い道ないじゃん。

それはあんたが無知なだけ。
例えばDBCP（コネクションプーリング）の実装とかを考えてみな。

>>604
馬鹿？
考えてみなもなにもグローバル変数みたいな使い方が出来ちゃう時点で糞と認識しろよ。
これができる時点で糞。
他のことは関係ない。

>>600-601
そこまでいうなら、プログラミングすること自体をやめればいいのに...

クラスタリングしてる環境でSingleton使ってたJava馬鹿がいたなあ。
パターンに当てはめるしか能のないデザパタ崇拝厨の哀れな姿。ｗ

>>605
マジレスさせてくれ
お前の考えは

・グローバル変数 ＝ 絶対悪
・Singleton ＝ グローバル変数
・つまり、Singleton ＝ 絶対悪

で良いんか？

っていうか

＞・グローバル変数 ＝ 絶対悪 
＞・Singleton ＝ グローバル変数 

のどちらも間違っているし
仮に上の行が間違っているとしたら、Application 変数とか System クラスとかも絶対悪になっちまうで

それから、下の行を正しいと言っちゃうのは正直言って勉強不足
Singleton は「生成に関するパターン」ですよ？
それ以外のことには無頓着なのです

>>607
それからもう１つ

＞パターンに当てはめるしか能のないデザパタ崇拝厨の哀れな姿
そんな奴は居ないｗ
当てはめようとした時点で自己崩壊するｗ

ついでに一言だけ言わせてくれ

『 使いたいなら使え。使いたくないなら使うな 』

>>609
はぁ？なにいってんの？
Singletonはグローバル変数と同じだって。
同じ問題をおこすよ。
君がいくら違うっていったって同じなんだよ。
実装でそうなってんだから。
これは前提で話してくれよ。

>>612
いや、超必死なのはよくわかったｗ

・int a = 0; っていうグローバル変数 a は、値が自由に書き換えられる
・けど、Singleton で取得するクラスは常に１つ ⇒ 書き換わらない

で、Application 変数とかは絶対悪なのでしょうか
あとは static なメンバ変数とか

っていうか、よく考えてみれば Singleton にしたクラスの設計が悪いだけの予感
心配ならば変化しないように設計すればいいだけなのに

グローバル変数にも同じことが言えますが

結論：キチガイの自作自演

>>613
>・けど、Singleton で取得するクラスは常に１つ ⇒ 書き換わらない
はぁ？
インスタンスの内容が書き換わるだろ？
この人何馬鹿なこといってるのかね？

一度もソフトを作ったことが無い人が、理想論振りかざしている感じだな

>>617
悪いけど俺のいるところみたいな弱小環境でも
グローバル変数禁止ぐらいの取り決めはあるｗ

>>616
書き換わらないようにしとけ
getter でも setter でも property でも readonly でも const でも final でも使ってｗ



「一度もソフトを作ったことが無い人」が俺を指していませぬように (-人- ﾅﾑ

「副作用がある言語は全部タコ」とかｗ

っていうか今まで Singleton を作った試しはないがなｗ

今時どこの大学でも、
　『 副作用のデメリットよりも、問題が簡潔になるメリットの方が高ければ使う価値がある 』
ってのは教えていると思ったが

>>619
俺からすればそれも駄目。
そういうのさえ作らなきゃ。

関数内で使う変数や関数はローカル変数と、メンバ変数、引数からの値に
絞れるからプログラムが追いやすくなってバグの箇所がぐっと減らせる。
これは絶対に守れってわけじゃないけど（Win32とかあるからね）
できるだけ守るようにすることでかなりプログラムが理解しやすくなる。

Singletonはヘッダーファイルさえ読んどけばどこでも出現可能な
グローバル変数と同じだ。
これを使わずに、面倒でも引数から読んでやることでプログラムを頭から調べるとき、
内容がどこで変化してるのかわかりやすくなる。

メリットとデメリットを理解したうえで、適材適所に亜qwせｄｒｆｔｇｙふじこｌｐ；＠：

>>623
ふむ。正直に同感。
一般的な場合では Singleton にするメリットは殆ど無いと俺も考えてますし。

Singletonがダメな人には、次の具体策を教えて欲しい
・JNDIリソースを毎回Lookupしない方法
・状態を持たず、処理のみを実装したクラスのインスタンスを毎回生成しない方法
馬鹿・糞・駄目って繰り返すだけじゃわからんよ

引数なら分かりやすい･･･本当か？

>>626
プログラムのエントリポイントでインスタンスを作っておいて、
それを引数でたらいまわししろってことじゃないの？

状態や副作用と戯れて悦に入ってる人っておめでたいなあ、と思う関数型言語使い達

>>626
俺は Singleton がダメってわけじゃないが

＞・状態を持たず、処理のみを実装したクラスのインスタンスを毎回生成しない方法 

これは java.lang.Math とか System.Math みたいに仕立て上げられるんなら、それで良いんじゃない？
Strategy みたいなこと考えているんでも、無理に Singleton にして難しくする必要は無いと思う

クラスタリング時にシングルトーンするバカがいたとか
上部に話あったけど、、、
駄目なの？(⊃д⊂)
シングルトーンて枠組みじゃなくて、「このクラスはシングルトーン」
って話題じゃないと意味がない気がするー

>>626
んで、上の方だけど、

　・アプリケーションを木構造にする
　・木の根で JNDI 扱うインスタンスを作成
　・木の葉にそのインスタンスを配布

でも解決しちゃうんだよな

「１つのアプリケーションドメインにつき１つのインスタンス = Singleton」 である以上、
本当にこのドメイン上に１つしか必要としないのか、が分かり難い場合が多くて困る

エラーログみたいなんはシングルトンにすべきだろ。

>>630
staticにするってこと？

>>633
そうっスね。同意

>>634
それが可能 and 適切 and 簡潔であれば

staticにすると継承使えないんだけど。

>>633
駄目。
呼び出し履歴が作れなくなる

>>632
それでも、Webアプリケーションなどの場合に
木の根ではリクエストごとにJNDIリソースを取得することにならない？

>>636
んじゃインスタンスメソッドから静的メソッド呼び出すとか、そもそも気にしないとか、方法はいろいろある
もちろん Singleton にするというのも１つの方法で

>>638
そう？
葉に伝わるインスタンスは根で生成したインスタンスだから、インスタンスの数は根の数に等しい筈です

複数の根で共通のインスタンスを使いたい場合は、それらの根を纏める大根を作ることが出来ればそれでも良いし
……って、大根っていうか親根っていうか

そういやあったなー

Singleton なクラスを Serialize ⇒ DeSerialize しちゃったこと orz

>637
むっ、興味深い。漏れも>633には同意なんだが、
>637の言う呼び出し履歴とは？

あっ、名前残ってた。
確かTomcatでサーブレット作る場合でログ吐くときには
シングルトンっぽいの使ってた気がするけど。

>>642
ＶＣにあるじゃん。
組み込みとかだとないとデバッグ使用が無いよ。
ＶＣ使ってるならデバッグするときに、コールスタックとか呼び出し履歴とかいうウィンドウ開いてみ。

>>644
ｺﾞﾒｽｗｗｗ今ＶＣ持ってないｗｗｗ

ログ処理でシングル�d使わないとなると、
代替案はどん感じなの？コードが読みにくくならない？

なんというか……その 『エラーログ』 が 『どこまでを必要』 としているかで変わるんだよな
それを言わずして 『Singleton にしてはいけない』 とは言っちゃダメのような希ガス

個人的には、デバッグ目的だと単なる文字の出力があればいいとかおもってる

>>644　(ﾟдﾟ)ハァ？

>>645
デバッグモードだと全ソースに変換かけて、
関数内でデバッグ関数の呼び出しがあると引数のしょっぱなとヘッダに細工しちゃう。
半日ぐらいの手間だったけど、一度作るとすげー楽。
これで呼び出し履歴が作れる。俺、オススメローテク。
ＶＣだといらないけどね。

(ﾟдﾟ)ﾊｧ？ｽﾚ違いｼﾞｬﾈｪｰｶ

javaでもeclipseあるからいらんのだが。

デザパタ馬鹿は具体的な言語の話になるとついて行けません。

また顔真っ赤にして自作自演してるのか。悲惨な日曜日だな（ぷ

>>648
むっ？それはログ出力を、プログラムのデバッグに利用する場合の話？

普通に処理の実行履歴ログをとる場合などのログ出力は、
シングル�d使ってもいいってことだよね？

CMの後もどんどｎ自作自演が続くよ！楽しみにしてね！

ぷ。Singletonで全呼出履歴を記録するという枝葉な話が、
VCのデバッガーが表示する呼出履歴の話にすり替わって、
挙句にデバッグ関数呼出の話になってやんの。

馬鹿じゃねぇの

今日の自作自演は午前４時まで延々続くﾖｶｰﾝ
明日は昼から午後一杯続くﾖｶｰﾝ

>>653
最後に完全消滅するなら別にいいんじゃない？
でも、そのログだと一瞬値みれればそれでいいんでしょ？
それだったら俺のローテクを使えば全て解決するはずなんだけど。どう？
１回デバッグ環境をしっかり作っちゃうのがいいと思うんだけどな。
結局ないと困るでしょ？＞呼び出し履歴。

あと、客先に納品するときに製品版にも残しておきたいエラーログとか
ならSingletonはオススメできない。（てゆうかいい加減に作ること自体駄目）

戯言万歳

>657
＞あと、客先に納品するときに製品版にも残しておきたいエラーログとか
＞ならSingletonはオススメできない。（てゆうかいい加減に作ること自体駄目）

ごめん。何度も質問することになっちゃうけど、
オススメできないという、その理由は？

解説が長いようだったら返答はいいや。

>>659-660
ふと思ったんだけど、何でそんなに Singleton 使いたいの？

使えないと思ったら使わなくていいじゃん
あと、人の設計に不用意に手を出すと氏ぬことを忠告しとく

>>661
すまん。単にSingletonを使ってはいけない理由が知りたかった。
短所をしることもまた重要かなと。
漏れはまだデザパタの理解が不十分なので。

>>659
前にひたすら書いたじゃん＞理由。

>>662
大きな理由としてはグローバル変数と同じような性質だからかな。

　　　　CMの後もどんどん自作自演が続くよ！楽しみにしてね！

>>662
Singleton の目的
……アプリケーションドメイン内にインスタンスが１つしかない事を保証する

Singleton の適応個所
……アプリケーションドメイン内にインスタンスが１つしかない事を保証したい

Singleton の長所
……アプリケーションドメイン内にインスタンスが１つしかない事が保証されている

Singleton の短所
……アプリケーションドメイン内にインスタンスが１つしか作成できない


まあ、正直こんなもんなんだ
１つしかない、ってのは、改造すれば任意の個数のインスタンスが作成できるようにさせられるけど

Singleton ってのは、つまり >>666 が

　自分の設計に合う時 …… 適する
　自分の設計に会わない時 …… 適しない

ってだけだし。具体的な案件を持ち出さないで議論するのはちとナンセンス

>>666-667
結論を出しちゃったから、アンチも信者もおとなしくなった。
乙。

>>667
ありがとう。今後、漏れがシングルトンつかってログ出力するたびに、
何で駄目なんだろう、何がいけなかったんだろうとか、思いながら夜も熟睡するところでした。


つまり、あれか。
自分を信じろと。

フォースを信じろと。

>>668
悪い。さっそくだがネタを投下するｗ


言わせて貰うと、「デザパタ使って共通認識……」ってのは危険性を含んでいると思う

======

昨日、メッセで話したんだけど

　俺「どんな風に作った？」
　奴「Command と Composite を併用させた」

ってな感じの会話になった。
デザパタを熟知した人ですら、『奴』 が何をやったのか分からない筈だ。

彼は、どうやら問題中の幾つかの動作を Command と見なし、while ループは Composite にしたらしいが……
……その動作を Command と見なすことを俺は想像していなかったから、混乱したんだな

======

「Command」 やら 「Composite」 やらの 『一言』 で纏めても、簡潔に伝わらない場合は多い筈
共通認識をもつことで情報量は削減できるかもしれないが、それで安心するときっと痛い目を……

っていうか、各パターンが表す 『共通認識』 って言っても、>>25 に書いた程度しかないような気がする
この程度の情報量で 『簡潔になった』 って言うのはマズイかも

……ま、デザパタやっておけば「パターンに対する１解法」は分かるから、
相手が言っている事もなんとなく推測できるだろうが

とりあえず、オブジェクト指向にはしっかり目を向けよう。

異なる２人の人間の○○○パターンに関する認識が完全に一致するのか？
というと疑問の余地ありですね。

コミュニケーションツールとしてデザインパターンを使用するときは注意が必要でしょうね。

　　　　CMの後もどんどん自作自演が続くよ！楽しみにしてね！

コミュニケーションの失敗がアンチを生み出す一つの要因かも。

「オブジェクト指向」って言葉も要注意だな。このスレでは特に。

このスレは、２スレ目からいるんだが、アンチが増える理由は、
デザパタを知ってる奴が、知らない奴に対しての態度が悪いんじゃないかと思う。
「おまえ、デザパタ知らないの？馬鹿じゃねーの」と煽る奴が多い気がする。
というか前スレからそういう奴が多かった。

おそらく、こういう態度を２ちゃん以外でもする奴がいて、
元々デザパタを知らない奴が、気分を害してアンチになるのではないかと。

知識をひけらかしたいのはわかるんだが、ちょっと自重してほしいとも思う。

嫌な話題ですまんが。

>>673
実装の詳細まで降りると、一致しないという前提に立つ方が無難。
ただ、特定の部分を指して「〜をストラテジパターンで実装しとい
て」と言われれば、その部分に変更余地があるんだなって事は
分かる。

>>670
パターン名だけでは会話が成立しないのは当たり前。
どの部分をコマンドパターンにし、何と何をコンポサイトにしたのか
それを口にしなければ発言者の脳内は誰にも分からない。

ああ、そいつがアンチデザパタと、
くだらねぇデザパタ・フレームを自作自演してる
頭からっぽの荒らしだよ。

奴の情報源は２ちゃんオンリーだから、
馬鹿な質問に丁寧に答えてやると、
早速他のスレに行って「そんなことも知らねぇのか」
とか煽り出す・・・どうしようもない性悪だ。

デザパタスレに関しては、part2の頃から荒らしが出没しているんで、
もうほとんどあきらめている。

失礼、名前欄の677は、
>>677 の間違い

でも実際のところ、デザパタこそ、プログラム界の荒らしそのものなんだろ？

当たり前かもしれないけど、デザインパターンを使って会話するときは、
会話中でデザインパターンを使用することが適切かどうか
というところから考慮してからでないとコミュニケーションの失敗につながるかもしれませんね。

　　　　　　.-‐''＾＾'''‐- ...,
　　　　; '　　　　　　　 　 ' ,
　　　.;'　　　　uvnuvnuvn ;
　 　 ;　　　　j 　　　　　　　i
　 　 ;　.,, 　ﾉ　,.==- 　 　=;　　　　　ククク…
　　　( r|　 j. 　ｰo 、　 ,..of
　　　 ': ヽT 　 　￣ 　i ￣｝ 　　　　　もめろ　もめろ・・・
　　 　': . i ! 　 　　.r _ j　/
　　　　'; |　＼　 'ｰ-=ゝ/
　　　　 人、　＼ 　￣ﾉ
-‐　￣　　　 ' ーｲ￣ー-- 、
　　　　　　　　ヽ | ;'　　　　　ヽ

もう一度引用したろ
"Before I started studying martial arts, a punch was just a punch;
a kick was just a kick. After I started practicing martial arts,
a punch was more than a punch and a kick was more than a kick.
After I understood martial arts, a punch was a punch
and a kick was a kick."
Bruce Lee, Tao of Jeet Kune Do

デザパタもしょせん守破離の“守”の部分でしかないんだけど、ここでデザパタを
否定しているヤツらが“破”“離”の境地に到達しているとは到底思えん。

唐突な自己流解釈に唖然

いや、ただ頭の悪い人にもわかるレベルのインチキだったってだけ、
頭の悪い人にはわからないインチキははやらないけど、
頭の悪い人にわかるインチキってのは持ち上げられるんだよ。
まさにデザパタみたいにさ。

デザインパターンを”インチキ”とか言ってる時点で、そいつの頭の悪さがわかるな

頭イイ人　　　　　　　　　　　　　　→デザパタなんてインチキ
頭悪いけど頭イイのを気取ってる人　　→デザパタはすごい
頭悪いけど開き直っている人　　　　　→デザパタはインチキ

　　　　夜はこれから！午前５時まで自作自演がまだまだまだまだしつこく続くよ！

>>687
オブジェクト指向じゃないってところがなんともねｗ
デザパタがオブジェクト指向にのっとってないってのはもう周知の事実でいいと思うけど。
オブジェクト指向言語でそれってインチキじゃねぇ？

まあ、デザパタはすべての人に受けいられる考え方ではないわな。
正直、一部のパターンは複雑すぎる。シンプルなものは、ものすごくシンプルで良いのだが。
今後、少しずつ悪い部分は見直しされて、いいものができるのではないかと。
現状のデザパタはすべてにおいて良いとは言い切れないと思う。

今後に期待。

>>691
もう、更新止まってるよｗ

書き忘れた。正直、今、存在する本は利点をうまく表現できてないと思うので、
「インチキ」とか「おかしい」とか呼ばれても仕方がないとは思う。
今後、利点をうまく説明した本がでれば受け入れられるのではないかと。

>>692
ﾅﾆ!! ｿｳﾅﾉ!!!?
「GOFは」ってことでそ？

＞１つしかない、ってのは、改造すれば任意の個数のインスタンスが作成できるようにさせられるけど
だからそれが、SとFWが継承関係にある理由の一つだと何度

>>690
デザパタがオブジェクト指向じゃないって騒ぐ人(たち)は
ドメインクラスしか作らないの？
設計の話をしてるの？

あ〜まず「オブジェクト指向」ってなんだよ？

>>694
そんなのは関係無いよ。
ヘッダさえ呼べばどこでも呼び出せちゃうのがまず駄目だって
何回言えばわかるんだ。このタコｗ

誰でも自分のデザパタを心の中に持ってるだけさｗ

>>695
>あ〜まず「オブジェクト指向」ってなんだよ？
とりあえず>>343-347←こんな感じでまとまった。

>>696
フライウェイトに限りゃしないが、シングルトンの肝は唯一のインスタンス
である事を保証するという１点に尽きる。
ファクトリ＋適当なコレクション(ても、大概はハッシュテーブルを利用す
るが･･･)でもシングルトンは満たせる。
この場合、君の懸念は問題にならない。

>>698
それ結局オチてない。
そもそも、ストラテジの代替１つ例示できない人間の語る言に価値はない。
反論があるなら真のオブジェクト指向とやらでストラテジの代替を例示し
てみてくれ。

>>699
何、妄想くっちゃべってんだ。
どこでも呼べちまうのが問題だっつってんだろ。
中身が定数だろうと変数だろうとこんな問題のあるクラス人に薦めんなよ。
ヘッダを全部まとめてインクルードしてるようなウンコプロジェクトだと、
どこからアクセスしてどこで使ってんのかマジでわからんぞ。

>>698　サンクスこ
まずドメインクラスありきなのが「オブジェクト指向」であるように読めた
これには同意

でもそれ以外のクラス(これもオブジェクトと見なせる)もあった方が
柔軟性・保守性を上げることができるし
デザパタはその範疇だと思う

すべて含めて俺は「オブジェクト指向」だと思っていたのだが…

オブジェクト指向っていうのはいわゆるオブジェクトがfirstclass object
な言語のことだろ？

>696
>ヘッダさえ呼べばどこでも呼び出せちゃうのがまず駄目だって

Singletonに対してアクセス制御すればいいだけでは？
C++ならクラスのprotect/private なstaticメンバにするとか。

>>700
それって実装レベルの話でしょ？
設計レベルでそんなの無理だと思うけど。
デザパタってまずコードレベルなのが誤解の元だよね。

前話してた奴が何いったのか知らないけど、
オブジェクト指向でそれを表現するのは不可能だと思う。

シングルトンだけでご飯を241杯食べる変態が粘着してるスレ

>>705
ストラテジの肝は特定の処理部分を括りだし、代替性を持たせる
というだけのものだ。なぜオブジェクト指向で表現できない？

>>707
オブジェクト指向にそんな概念はないから。
結局、分析をしてクラスを導きだすぐらいしかねぇんだよ。

〜パターンとかすでに型があるのとは違う。
あくまでも対象物をみてそれをクラスという形でソースに反映するところまでがオブジェクト指向。
パターンも糞もない。
根本的に勘違いをしてると思われ。

シングルトンだけでご飯を244杯食べる変態が粘着するスレ

>>708
だから具象には触れてないだろ？
特定の処理部分を括りだし、代替性を持たせる。

再利用と共通化、オブジェクト指向が持つお題目のうちの一つだ。
いや、２つだけどなｗ
って話は置いとくとして、これをオブジェクト指向で表現できない
と思ってるのなら、それこそ根本的な勘違いをしてると思われ。

>>710
再利用と共通化なんてオブジェクト指向を適用した結果であって
それを狙って設計をしちゃ駄目だよ。

何度もいうけど、
オブジェクト指向は対象物をクラスという形で
ソースに反映するぐらいの概念しか無い。

特定の処理の部分を括りだし、代替性を持たせるなんて無いから。

まず、一番大事なのは対象物を素直にソースに反映させること。

同じズリネタでしつこくオナーニし続ける猿粘着

>>712
だってこれしかないのに余計なオプション付けて話すんだもん。
何度も同じこというしか無いよ。

知性のある人間の会話とは、到底信じられない。

てか、簡単なことを難しく話す人ってプログラムも下手糞じゃない？
物事を考えるときはできるだけシンプルな形にして考えなさいって
アインシュタインも入ってたよｗ

デザパタ肯定派の人っていちいち有名人の名前出してあげないと信用しないんだよね。
これでよく技術職やってられるよと思うけどね。

Ｘ入ってたよ
○言ってたよ
変換ミスｗ

まあ、ファウラー信者とかに比べれば、まだまだ胡散臭さ・ハッタリ度が足りないな。> デザパタ信者

パターンじゃなくて基本がしっかりできているかどうかのが
重要な問題のような気が思いっきりするけどね。＞ファウラー
所詮パターンを覚えたところでVBerは所詮VBerだということを知るべき。＞ファウラー

何これ？

昨日、エラーログ云々でもめてたようだけど、別にデバッグとかそういう用途でなくて
たんにソケットやらデバイスコンテキスト取得の失敗やら、ファイルが無いとかを
例外処理ひろってシングルトンに流し込んで、失敗したうんぬんを
画面のすみっこにバーッとログ表示するようなよくあるかんじのやつな。
いやデバッグ用のエラーログなんてふつうは自作しないから。

>>718
何だかよく分からんが、意見があるなら本人に言いたまえ。

どこからでも呼び出せるからSingletonは×って言っている人がいたけど、
それってどうなの？

どこからでも呼び出せるって便利なことでもあるでしょ？
もちろん便利さの裏には危険もあるけど、
Singletonとして使用されることを考慮してクラスを設計すれば
（つまりどっから呼び出されても安全なように設計すれば）
問題ないのでは？

「グローバル変数の使用はよくないと言われたので、グローバル変数をSingletonに置き換えました」
っていうのは違うだろって思うけどさ。

便利っていうか出来ないと困るときがあるんだよなぁ。
>>720 のエラーログみたいに。

こんなことをいいつつも、
singleton使わずにエラーログを記録する方法があるなら興味がある。

Singletonの話、この週末で250レスも付いてるけど、
ほとんど同じ話がループしてるだけだな。

>724
完全に同じ話が廻ってるってわけでもないだろ。
少しずつ議論に具体性が出てきていると思う。

Singletonってログみたいなデータの垂れ流しか、
オペレータから指定されたコマンドラインオプションなどの、
不変なデータの参照とかの取り扱いで便利だな。

エラーはいろんなところで発生しますし、しかもそのエラー情報の記録先が単一となると、
ここはやっぱりSingletonの出番でしょう。

わざわざオブジェクトを1つしか作れないように細工しなくったって
全部クラス関数やクラス変数にしちゃえば嫌でもシングルトンになるのにね

と空気や過去レスを読まずに書いてみるテスト

あげ足とりが来る前に訂正
クラス関数、クラス変数はクラスメソッド、クラスフィールドに置き換えておいてくれ

>>727
継承が使えないだろ

>>729
委譲すればいい

>>727
でもなぁ...C++だとクラスフィールドにPODでない型の変数をおいてしまうと、
コンストラクタがいつ呼ばれる分からんからなぁ...

×コンストラクタがいつ呼ばれる分からんからなぁ...
○コンストラクタがいつ呼ばれるか分からんからなぁ...

スマン orz

>>727
空気や過去ﾚｽはともかく、GoFは読もうよ…
「なんでそういう糞面倒な事してるか」が書いてあるんだから。
それ読んだ上で「そんな必要ねーよ！」って人は
それこそ (注意を払いつつ) グローバルにしてしまえば
いいんだしさ。

>>727
クラスメソッド、クラスフィールドにしてしまうと、実装がむき出しになって変更に弱くなる気がする。

ログ出力処理をクラスメソッドにすると↓の感じなわけだ。
　Logger.write("今食べてるチョトスがマジうまいんですけど。");
↓シングル�dにしておけばこんな感じなわけだ。
　Logger log = Logger.getInstance();
　log.write("今食べてるチョトスがマジうまいんですけど。");

でログフォーマットを変更したいときに、シングル�dつかっていた場合では、
デコレータとかで日付とスレッドＩＤとかつけるよう拡張できるし、なかなかいいんじゃないかと。
Logger log = Logger.getInstance();
log = new FormatKakuchoLogger(log); //ここを付け加えた。
log.write("今食べてるチョトスがマジうまいんですけど。");
# 出力例=> 2005/06/13 19:03 threadid:xxxxx 今食べてるチョトスがマジうまいんですけど。

まあ、クラスメソッド方式の方でもクラスメソッドの中身書き換えればいいだけなんですけど、
このログ出力処理を他システムでも流用したいとか思ったときに、
ログフォーマット変えるのに根本のクラス(この例の場合Loggerクラス)の処理を
直接、書き換えないといけない設計になっているんじゃあんまよくないかなと。


まあ、今まで長々と書いてみたけど正直どっちでもいいじゃないかと思えてきたＮＥ。（´Д⊂ヽ

＜結論＞

Singletonをグローバル変数の代わりに使おうとするやつが糞。

それをみて「Singletonなんていうものがあるデザパタが糞」といっているやつも糞。

別にSingletonが悪いわけではない。正しく使えないやつが悪いだけ。


GOTO分があるからC言語は糞とか、交通事故があるから自動車は糞とか、墜落するから飛行機は糞とか言っているのと同じだってことに気づけ。

デザパタがオブジェクト指向にのっとってないことが一番問題なんだけどなｗ

狂人？

もう相手するな、俺もこれを最後に以後スルーする。

>>738
デザパタ信者ってこんなのばっかだな。
いつもリンク貼ってデザパタの実績一覧だけ載せて説明無しで終了。
ＩＴ業界の実績なんてでっちあげばっかりじゃねぇか。
そんなもの妄信してるからオブジェクト指向も理解できないんだよ。
あの有名なデザパタ。
あの有名なGoF本。
あの有名な・・・。
俺はデザパタっていったらこんな話題しか聞いた事ないよ。
誰も本質の話題に触れることは無い。
オブジェクト指向の理解できなかった奴の可愛そうな隠れ蓑。アホか。
もう、プログラムなんて組むの止めて論文でも書いてりゃいいじゃないか。
本出して有名になりたいんだろ？ｗ

あー、すっきりした。

>>738
>>もう相手するな、俺もこれを最後に以後スルーする。
あ、自分の言葉に責任をもってね。

ちなみに>>739は誰が見てもわかる一本釣りだからスルーでいいよｗ

ところで、みんな語尾に付けてるｗって何なの？

このスレには、学習障害の荒しが常駐しています。
見かけても決して相手にせず、スルーして下さい。

【学習障害の特徴】

◎気に入らないことがあると我慢できず、乱暴な行動をとる

◎一つの話題にこだわり、同じ質問、同じ話題を繰り返す

◎聞きもらしが多く、会話も一方的で話題がとびやすい

◎文字や文章を正確に（意味をとらえて）読むことが困難

◎（因果関係など）複雑な会話は理解困難

◎問題を理解して論理的に解決する力が乏しい

◎相手の思いや感情を考えて、行動することが困難 状況判断が苦手
　（人の嫌がることを言ったり、わがままを言う)

>>741-742
あれあれ？
>>738で最後じゃなかったの？ぷｗ
自分の言ったことぐらいは守ろうよｗ

>>741
馬鹿の印に決まってるだろ

>742 >744
あははは。もう相手にするなよ。
なに言ってもお互い何か得られるわけでもあるまいし。

>741 （笑 を省略してった最終形態。笑→ﾜﾗ→ﾜ→ｗ。どっかの板に行けばみんな普通に使ってる。
>744 やべｗｗ おれよく使うんだけどｗｗｗ

…………………………　き　り　と　り　せ　ん　…………………………

>>745
自作自演乙

>>694
＞＞１つしかない、ってのは、改造すれば任意の個数のインスタンスが作成できるようにさせられるけど 
＞だからそれが、SとFWが継承関係にある理由の一つだと何度 

継承関係……っていうか、Singleton も FlyWeight も 『インスタンス生成を制御するパターンである』 ってコトだし。

こういうプログラム開発技法って海外が優れてるよな。
海外では、今でもそれぞれのパターンの良さ、悪さについての見直しの議論がされているのだろう。
日本人はパターンを理解するだけで精一杯。

うむ。英語習いたい。


って書いておいて、海外でも「デザパタは糞」とかいう意見でいっぱいだったら笑える。

妄想意見乙。

実際のところ、日本ってソフトウェア業界では確実に遅れてるよね。

根拠もへったくれもないな

エンタープライズ・ソフトウェア・パターン
http://martinfowler.com/articles/enterprisePatterns.html

企業向けソフトウェア開発のためのパターンのカタログ化に関する個人的調査結果。

近年、企業システム開発のためのパターンの記述が、わずかではあるが有意に成長している。
本ページでは、それらパターンのうち特筆すべきカタログ・リストと、
それらパターン間にある広い意味での相互関連に関する考えを、メンテナンスしていく。

個々のパターンの詳細や、カタログ中での見せ方については、
PatternShare[ http://patternshare.org/ ]を調べると良いだろう。
PatternShareの成果は、マイクロソフトのパターン・グループが作成したものであり、
各種のパターン・カタログがどのように構成されているかに関して、
PatternShareの解釈に則っている。

>>752
根拠はないけどなｗｗｗｗ

でも、世の中見てると日本人が作ったもの、取り決めたものでメジャーになったものは少ない。
言語ではCやC++に始まり、今はJavaとか。あと言語に付随する統合開発ツールとか。
開発手法やデータの取り決めにおいてはデザパタとかＸＭＬとか。
日本発のアイデア・開発物はほとんどない。
日本人は海外で編み出されたものを使わされてるかんじ。

>>754
ぱっと思い浮かべただけでこれぐらいはいる。
・川原氏が作ったLooking Glass 3D
・Servlet仕様の現Spec Lead（仕様とりまとめ役）は吉田豊氏
・J2SE実装の開発にはSunの日本人エンジニア（神谷氏など）が参加
・Apache AXISの開発メンバーに木村さん
ちゃんとやっている人は取り立てて「日本人」「日本発」を騒ぎ立てないだけ。
本人たちは完全にボーダレス感覚なんだよ。

エンタープライズ・ソフトウェア・パターン
http://martinfowler.com/articles/enterprisePatterns.html

企業向けソフトウェア開発のためのパターンのカタログ化に関する個人的調査結果。

近年、企業システム開発のためのパターンの記述が、わずかではあるが有意に成長している。
本ページでは、それらパターンのうち特筆すべきカタログ・リストと、
それらパターン間にある広い意味での相互関連に関する考えを、メンテナンスしていく。

個々のパターンの詳細や、カタログ中での見せ方については、
PatternShare[ http://patternshare.org/ ]を参照すると良いだろう。
PatternShareの成果は、マイクロソフトのパターン・グループが作成したものであり、
各種のパターン・カタログの構成方法について、一定の見解を示している。

パターンカタログ著作者が、協同作業を試みる組織など正式には存在しないが、
わたしたちは非公式の強いつながり -- 例えば互いの著作を頻繁にレビューし合う -- を維持している。
わたしたちは、何かもっと組織化されたグループを作った方が良いのではないかと度々思うが、
実際に実現するためのエネルギーを奮い立たせる事はなかった。
自身のパターンの著作を書くだけでも、充分すぎるほど大変なんだ。。。

どのパターンを適用すれば良いか、何故あるパターンが興味深いのか・・・については、
人によって異なる期待をする傾向がある。この件に関する私の意見は、
colum for IEEE Software [ http://martinfowler.com/ieeeSoftware/patterns.pdf ]に述べた。

ただ私が比較的良いと考え、同時に満足しているパターン・カタログを、ここにリストする。
ここに挙げるパターン・カタログが完璧なリストであるように意図するわけではない。

Rubyは入れてくれないのか・・・・

>>757
俺も思った・・・。むしろそれしか思い浮かばなかったのに・・・。まつもとさんｶﾜｲｿｽ・・・。

信者や信者のフリした荒らしがうざいからRubyの話は不要

ジャレ合いばっかで痛いスレだな

>日本人はパターンを理解するだけで精一杯。

精一杯でも理解できりゃいいじゃん。
C++ template使用だけど、異様にむずいんですけど。
特殊化によるメタレベルでの条件分岐とか、テンプレートの入れ子とか、
読みにくいったらありゃしない。

>>761
それならわざわざコードを読まないで使えばいい。
ドキュメントを読んでもコードを読まなきゃ
使えない代物だったら作ったやつが悪いが。

>>761
プログラムに限って言えば

読み難い＝組んだ奴が下手糞

と思っていいと思うよ。
ただ、C++のソース見るのにオブジェクト指向知らないとかいうのは無しね。

>>761
それはどう考えてもデザパタと関係ない。
そもそも、デザパタ以外で使われるC++＋templateは読みにくくないのか？

>>764
テンプレートって使ってる時点でかなり汚いコードになるな。
多用してるデザパタもやっぱりキタネェコードだと思うｗ

自分でパターン考えられない初心者ばっかだな

デザパタとテンプレートって関係あるのか？

>>766
すごいねェ。ぜひとも766様のパターンを聞かせてほしい。

>>767
うーん、まったくといっていいほど、ないかと。

>>766
こういうやつは、間違いなくデザインパターンを理解していない。

オブジェクト指向理解できるといいなｗ＞デザパタ信者

>>770
おぶじぇくとしこうのなにがむずかしいのでちゅか？
IQ90いじょうならおぶじぇくとしこうをりかいできます。

煽りばっかで本当に中身が空っぽの奴らだな

>>772
それがデザパタの本質だからなｗ

頭がおかしい奴がすっかり居着いてるな。悲惨な板だ

本当にRuby信者にはろくなやつがいないなぁ

>>775
スレにそった話題も振れないクズは
さっさと消滅しろ。

>>772
>>766のことでしょ。
そうじゃないなら、はやくその自分で考えたパターンとやらを見せて欲しいなｗ

いや、頭悪い奴には話通じないからここではスルーしとくよ。
頭良くなったらここ以外のどっかで紹介してあげよう（ﾜﾗ

こりゃまた酷い逃亡宣言がｗ

なんだ、ここには英語もろくっすぽ翻訳できない池沼しか居ねぇのか

アンチって所詮この程度（>>778）なの？

>>781
なんだ、本当の池沼か。相手にして時間を損した。

ちょっと目を離してる間にこんなにレスが増えててビックリしたｗ
やっぱりデザパタ信者には効くんだろうなｗ

キチガイが粘着中です

　　　　　　　　　　　　　　まともな人はしばらくお待ち下さい

>>784
「オブジェクト指向」ってキーワードに反応して出てくるのが
日課なのか？お前？
もう過去ログからもお前がオブジェクト指向が理解できてる人間に嫉妬心を
抱いていることはマルワカリなんだよ。
デザパタが貶されたり、オブジェクト指向の話題が出てくるところでばっかり
荒らしのフリして定型文コピペしやがってワンパターンなんだよｗ
みんなｶﾜｲｿｳだと気を使ってそのことに触れないでいてあげたようだけど
お前、あまりにもミジメすぎｗ

>>756
PatternShareか。面白そうだと思いながら、
まだサイト全体をちゃんと読んでいない。
Martin Fowlerの翻訳の続き読みたいから、
翻訳してアップするよ。ちょっと待ってて。

さらに過去ログの傾向から

>>784＝>>786

であることも明記しておくｗ
おもしろいほど似たようなパターンばっかりだよｗ
終わった話題のレス番穿り返して話そらそうと必死なところが笑えるｗ

なに、人の役にも立たないキチガイがまだ粘着してるのか。
人の嫌がる事しかできないカワイソウな奴だな。
おまえ友達いねぇだろ（爆笑

>>788
図星突かれて認める素直さがあるなら自演なんてしないで普通に話題振れよｗ
極ﾜﾛｽｗ

哀れな奴

>>780
あたりめえだばっかやろう。
英語よめたらこんなスレにはきてないさ。はははっは。ちっきしょー

ところでhttp://martinfowler.com/のmartin fowlerって人は有名な人なん？
なんか勉強してるとよくこのページに行き着くようなｷｶﾞｽ。

エンタープライズ・ソフトウェア・パターン
http://martinfowler.com/articles/enterprisePatterns.html
【カタログ】

以下に、私が役に立つと思う主要なパターン・カタログ一覧を示す。

■Patterns of Enterprise Application Architecture (Fowler)
　[ http://martinfowler.com/eaaCatalog/ ]
階層(Layered)アーキテクチャの文脈で、企業アプリケーション・アーキテクチャに力点を置いた本。
章立てとしては、ドメイン・ロジック、Ｗｅｂプレゼンテーション、ＤＢインタラクション、オフライン時の並行(一貫性)管理(David Riceによる)、そして分散処理、をカバーしている。
ＤＢインタラクションは最も大きな章であり、ＯＲマッピングに関する多くのパターンを含んでいる。

■Core J2EE Patterns (Alur, Crupi, and Malks)
　[ http://www.corej2eepatterns.com/ ]
Java J2EEプラットフォームの文脈で、企業アプリケーション・アーキテクチャ・パターンを扱った本。
載っているパターンは、J2EEプラットフォームに焦点を当てているが、大抵は
他の企業アプリケーション・プラットフォームにも(多少ヒネれば)同様に適用可能である。

■Enterprise Integration Patterns (Trowbridge, Mancini, Quick, Hohpe, Newkirk, and Lavigne)
　[ http://www.enterpriseintegrationpatterns.com/ ]
私は、異なる種類の企業アプリケーションの統合には、非同期メッセージング・システムを使うアプローチが最も効果的だ、という意見に到達した。
ＥＩＰ(この本)は、このアプローチのパターン集の基盤である。

■Microsoft Enterprise Solution Patterns (Teale, Etx, Kiel and Zeitz)
　[ http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/esp.asp ]
マイクロソフトによる最初のエンタープライズ・ソフトウェア・パターン集。
章立てには、Ｗｅｂプレゼンテーション、デプロイメント(アプリケーションの配置)、分散システム、が含まれる。

■Microsoft Data Patterns (Teale, Etx, Kiel and Zeitz)
　[ http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/dp.asp ]
データ移動: すなわちリプリケーションとデータ同期、に関するパターン集。

■Microsoft Integration Patterns (Trowbridge, Roxburgh, Hohpe, Manolescu and Nadhan)
　[ http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpag/html/intpatt.asp ]
マイクロソフトも(企業システム)統合パターンをやっている。
章立てには、統合レイヤーの戦略、システム間接続の種々のやり方、統合のトポロジー(配置＆接続の構造)、を含んでいる。

■Domain Driven Design (Evans)
　[ http://domainlanguage.com/ ]
オブジェクト指向ドメイン・モデルの構築は、ドメイン・ロジックを組織化するポピュラーなやり方である。
特に、複雑なドメインではこのやり方が良い。問題は、このやり方を充分に行うのは難しいという点である。
この本のパターンは、リッチなドメイン・モデルの構築と組織化に関する考え方を説明しているだけでなく、
人々がモデリング原則を知ってはいるが、ほとんど大抵その原則を活用しないという、実世界の障害の、認識方法と克服方法も説明している。

■Analysis Patterns (Fowler)
　[ http://martinfowler.com/books.html#ap ]
ちゃんとしたドメイン・モデル(というもの)を見よ(見つけよ)、そして貴方はある種の構造を繰り返し見かける(ことになる)。
この本は、複数のパターンが形作る形態の共通点を捉えようとする、私なりの試みである。
多くの点でいろいろ改善すべき点が多数あるが、基本的なアイデアは以前として健全なものである。
このパターン素材が役に立つと思った時は、より新しい補足材料がこのサイト[ http://martinfowler.com/ ]にある事を確認して欲しい。

■Data Model Patterns (Hay)
　[ http://www.amazon.com/exec/obidos/ASIN/0932633293 ]
データ・モデルにおける共通パターン。
これらのパターンは、とても概念的なやり方で開発されたので、データ・モデリングだけでなくオブジェクト・モデリングでも同様に使える。

■Gang of Four (Gamma, Helm, Johnson, and Vlissides)
　[ http://www.amazon.com/exec/obidos/ASIN/0201633612/ ]
最初の、そして最も使われているパターン本。
これらのパターンは、企業ソフトウェア開発に特化してはいないが、エンタープライズ・パターンが広範に参照している、極めて基礎的なパターンである。

■POSA (Buschmann, Meunier, Rohnert, Sommerlad, and Stal)
　[ http://www.amazon.com/exec/obidos/ASIN/0471958697 ]
このパターン集のアーキテクチャ学的パターンは、特に影響力が大きい。
(企業アプリケーションのための)階層、パイプ、(メッセージング・システムのための)フィルター、は多くのエンタープライズ・パターンの著作の基盤である。


　　次は Aspects of Enterprise Software の章だ・・・

Martin Fowlerのパターン・カタログ・リストって、
俺のセレクトとほぼ一緒だｗ　ｽｹﾞｰ笑える

>>795
So what?

エンタープライズ・ソフトウェア・パターン
http://martinfowler.com/articles/enterprisePatterns.html
【２．エンタープライズ・ソフトウェアのいろいろな側面】

パターン・カタログは、エンタープライズ・ソフトウェア開発のさまざまな側面(aspects)をカバーしている。
さまざまな側面(aspects)を出発点に、パターン・カタログを分類しなおしたもの(another view)をここに示す。


【２−１．エンタープライズ・アプリケーション・アーキテクチャ(ＥＡＡ)】
「エンタープライズ・アプリケーション(企業アプリケーション)」は私の命名であり、ある種のソフトウェア・システム：「非常に多くのビジネスが稼動している、データを徹底活用したソフトウェア・システム」を指します。
より良い別の名前としては「情報システム (Information System)」とも呼ばれているアレです。なんつか、情報を処理し操作するシステムだから情報システムって（ｗ ﾁｮｰｳｹﾙ

ＥＡＡを扱う書籍は大抵、まずエンタープライズ・アプリケーションを論理的階層で分割する所から始まります。この階層構造が、一つの階層内部や、異なる階層間で、設計上の判断を促します(ある種の制約を与えます)。
そんなわけで、階層間で類似した構成のパターンになりがちなのは、驚くこっちゃないです。
各著作者は、彼ら独自の階層構造に基づいていますが、それら階層構造間には認識可能な類似性があるのです。

また人々が「エンタープライズ・アーキテクチャ(ＥＡ)」という用語を、「エンタープライズ・アプリケーション・アーキテクチャ(ＥＡＡ)」という用語と間違えるのも、驚くほどありがちな事です。
２番目に挟まってるＡ始まりの単語「アプリケーション」が、全くもって重要なんですぅぅぅ！！！
ＥＡＡ(エンタープライズ・アプリケーション・アーキテクチャ)つうのは、一つのアプリケーションの構築に関する事です。
ＥＡ(エンタープライズ・アーキテクチャ)っつうのは、ぜんぜん別のいきものなんでつよ〜！！！

■Patterns of Enterprise Application Architecture
　[ http://martinfowler.com/eaaCatalog/ ]
　ＥＡＡを、技術に非依存な観点から見たもの

■Core J2EE Patterns
　[ http://www.corej2eepatterns.com/ ]
　この本は、ＥＡＡに力点を置いた最初の本であり、
　Ｊ２ＥＥプラットフォームの文脈からＥＡＡを扱った。

■Microsoft Enterprise Solution Patterns
　[ http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/esp.asp ]
　ＥＡＡを.ＮＥＴの観点から見たもの。角度とか

【２−２．エンタープライズ・インテグレーション (ＥＩ)】
【２−３．ドメイン・ロジック】

の訳は蜜柑・・・ちかれたよぉ〜

>>796
いや、単に取捨選択するセンスが良い、つうだけの話。
センス悪かったり、知識が限定されてる人間には何の事かわかねえだろうけど（ぷ

ゴフッゴフッ　ゴフゥッ！

>>800
また馬鹿が粘着してるのか。

>>801
Peter Coadの一連のビジネスオブジェクト本(含: Java Enterprise Component)や、
PLoPD本(1〜4)、そしてPoEAAと結構かぶるPOSA2を
思いっきり無視しているのがアレだな。

>>801
ファウラーに限らず、ピーター・コードの著作やCoad Seriesって無視される
傾向にあるように思う。特に分析モデリングに関しては、ファウラーより遥かに
いい仕事をしていると思うのだけど、なんか含みがあるのかな。

PLoP本なんかはEAAの参考文献だか関連文献のリストに挙がっていたような気がする。

コードのないスレは伸びる。
いい加減パターン化なぞ不可能なことに気づけアフォども

また池沼か

GoF以外にもPOSAとかMFとかDDDとかHWとか色々あるんだね。知らんかった
http://patternshare.org/default.aspx/Home.AllPatterns

そして派閥争いへ

>>805
そりゃ、ソフトウェアパターンの一つとしてデザインパターンがあるのと同様、
デザインパターンの一つとして GoF があるわけで。

やっちゃった・・・ｗ
http://pc8.2ch.net/test/read.cgi/tech/1118944895/13

>>791-798
>>784-789の流れでファビョッ（火病）た厨房が怒りにまかせて、
宣伝文のコピペで読んでもいない本のリンク貼りまくったようにしか見えないｗ

結局、〜パターンが紹介されているすばらしい本止まりの紹介文しか書いて無い（まあ、実際は読んでないから書けないｗ）
アーキテクチャー、エンタープライズ、モデリング、ドメインモデル・・・
PLoP、EAA、PoEAA、POSA2、J2EE、MF、DDD、HW・・・
相変わらず、変換なんてしなくていいような横文字を並べるのが大好きなアフォｗ
オブジェクト指向での設計にパターンなんて　で　て　こ　ね　ぇ　よ　ｗ
アイドルプログラマに騙されすぎ。
本なんて何冊も書いてる暇のある奴なんて実際に開発なんか携わったことねぇよｗ

まあ、煽りはこれぐらいにして・・・
ずいぶんたくさんのパターンがありますねぇｗ
つーか、マジな話、新規参入する奴もこれ全部覚えろってのがお前等の仕事のやり方なの？
はぁ〜、デザパタ信者のいる職場なんていままであたったことないけど、
こんな奴等ばっかりと仕事するハメになったら、俺、絶対に辞めるわｗ
パターンもこれだけあると事典が必要になるよ。
まあ、そうやって隙間産業増やしてくのもいいけどさ。

　オ　ブ　ジ　ェ　ク　ト　指　向　は　覚　え　よ　う　よ　

>>809
>オブジェクト指向での設計にパターンなんて　で　て　こ　ね　ぇ　よ　ｗ 

デザパタは実装よりでは？

809に質問
1.おまいの「オブジェクト指向」とは設計なのか？実装なのか？あるいは両方なのか？
2.おまいの「デザパタ」とは設計なのか？実装なのか？あるいは両方なのか？
3.おまいにとってオブジェクト指向とデザパタは相反するものなのか？

ちなみに素人の俺は
1. 両方。その時によって使い分ける
2.実装より
3.オブジェクト指向の中にデザパタも含まれる

せっかく結構前でオブジェクト指向にも
２つの意味合いがあるって誰かが言ってくれていたのに。
賛同者も結構多かったように見えたんだけどなあ。

>>811
>２つの意味合いがあるって誰かが言ってくれていたのに。
都合のいいように勝手に作らないでください

>>808君>>811に答えなさい (ﾌﾟ

>>813
>>808なんかに何を求めているんだろうか？

>>812
黙殺されているみたいだけど。>>557

>>815
違うよ。
２つの意味合いなんて無いの。
あるわけないだろ。
オブジェクト指向はもとはシミュレーター作ってる奴等から
考案されたであろうものなんだから。
どう使うべきものであるかなんて簡単に想像できるだろ？

>>816
僕は馬鹿なのでおっしゃることがよくわかりません。
わからないことを馬鹿なりにまとめてみました。

1. 後半部分の根拠が弱すぎる。
「・・・”であろう”ものなんだから」「想像できるだろ？」
というような言葉的なこともありますが、それを抜きにしても
この説明だと、表面的な連想でしかないのでは？
深い意味があるのならそれをはっきり示してほしいです。

2. そもそも後半部分が「２つの意味合いなんて無いの」の根拠に全くなっていない
「２つの意味合い」説は新しい派閥が生まれたという説なのではないでしょうか。

はっきり言って、デザパタは一人でお遊びで浸ってるぶんにはかまわないけど
本気で周りを巻き込みだすと大迷惑。
っていっても、
デザパタみたいないい加減なものじゃアカデミックにもならないだろうし
すくいようがないよデザパタってさｗ

>>816
まさに原理主義者の言い分。

>>817
そんなら違う言語作った方がはやいじゃん。
元はシミュレーター向けに作られた言語だもん。
パターン主体でまわす言語作った方がはやいんじゃない？

なんか一人(age厨)が荒らしている悪寒

ちなみにそういうの作るなら作るで燃えるけどね。
ＶＢやＭＦＣみたいなのはむしろそういうパターン主体の言語のが
向いてるんじゃないかと思う。

>>816
発明された道具（＝オブジェクト指向）を、当初の使用目的とは異なる
使い方をしている人間がいるといいたいわけか....

でも、それって普通では？

>>821
議論するのが嫌いなら出てった方がいいよ。

>>820
なぜ急に言語の話に？
しかも>>817 へのレスになってない。

そしてデザインパターンって
もともとはsmalltalkで育ったものじゃなかったっけ？記憶違い？

>>823
別にいいけど。
それだとクラスの意味がかなり不明。
よしんば構造体＋関数として使っても始めの概念が無いからそうする意味（わざわざくくりつける意味）から不明。

>>825
simulaが最初

デザパタがソフトウエア開発の現場で役に立つと思ってるやつは
アカデミックよりの人間。
デザパタがアカデミックなわだいだとおもっているやつは
開発よりの人間。
実際は、どっちにとってもお荷物以外の何者でもありえない。

いまいち良く分からないんだけど、
オブジェクト指向とデザインパターンってケンカするのか？
次元の異なる話のような気がするんだけど...

>>829
このスレッドを少しでも読めば、何が起きているか大体のことはわかる。

>>829
過去ログ読めばわかるけど。
簡易的にいうとオブジェクト指向で設計するとデザインパターンがでる幕は無い。
パターン云々の前にクラスが完璧に決まってしまう。

クラスが完璧に決まる？
もまいはすごいね。ね。

>>832
ああ、だからデザパタを読んだときは違和感ありまくりだった。
オブジェクト指向で設計をし始めのときは無くていいような中間オブジェクトをたくさん作ったけど
慣れていくうちにそんなもの無くなる。
ていうか、無い方がいいことに気づく。

またキチガイが祭やってんのか。

馬鹿は早く寝ろよｗ

なんかすっげー低レベルｗ