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

賢者は歴史に学び、愚者は自分の経験に学ぶ

関連情報は >>2-10

過去スレ
デザインパターンの単純そうな質問 - (1)
http://piza.2ch.net/test/read.cgi?bbs=tech&key=994690114
リファクタリング、させてくれ
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]
デザインパターンあれこれ
http://www.dmz.hitachi-sk.co.jp/Java/Tech/pattern/
Javaプログラマのためのデザインパターン入門
http://objectclub.esm.co.jp/DPforJavaProgrammers/DPforJavaProgrammers.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
Smalltalkイディオム(GoF本のサンプルコードが読めない人のためのSmalltalk入門)
http://www.sra.co.jp/people/aoki/SmalltalkIdioms/index.htm
[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)

書籍
増補改訂版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/4894711877/
Javaの鉄則
http://www.amazon.co.jp/exec/obidos/ASIN/489471258X/
Effective Java
http://www.amazon.co.jp/exec/obidos/ASIN/4894714361/
オブジェクト指向における再利用のためのデザインパターン
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
リファクタリング
http://www.amazon.co.jp/exec/obidos/ASIN/4894712288/
アジャイルソフトウェア開発の奥義
http://www.amazon.co.jp/exec/obidos/ASIN/4797323361/

書籍一つ加えておきます。
「Ｃ＃デザインパターン」
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/

書籍
デザインパターンによる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/

信者ｳｻﾞｲ

デザパタ信者というよりJAVA厨の溜まり場なんだよ(だから低レベルで浮き世離れしてる)

POSA本とPLoP本もよろしくね！！！

官話九大

IBMのe-Business patternsって、
アメリカ合衆国のEA決める官庁でもネタにされてるくらい、
認知率が高くて、国内でもITなんたら推進室が寝たの孫引きしてる。
まぁ、飴ちゃんは「ベストプラクティス！！！」とか好きだし、
国内の馬鹿役人は飴理科追従が仕事みたいなもんだし、ぷぷぷ

それを真似して .NET pattern & practice とかやってるM$は、なんか哀れ

このスレの命題にも言えることだが
＞POSA本とPLoP本
無理やりこういう略しかたする必要あるのか？
頭悪すぎ

＞官話九大
使い方が間違ってるからわざと違う漢字にしてるのですね。

>>11
そのとおりですが、何か？

何とも言ってませんが？

>>9
すんません。まじで何のことを言っているのかさぱーりです。
わかるよーに説明希望

>>14 かまわないほうが...

痴呆老人がネガティブな粘着をしてるようだな

さっさと市ねよ

関係ないが前スレの976は俺でその後何にも書いてないのに
話が進んでるのはなぜだ…？

>>17
それは俺がレス番号の間違いに最後まで気づかなかったからだ
今気づいた
マジでｽﾏｿOTL

＞マジでｽﾏｿOTL
あ、イヘイヘ、面白かっただけなんで。

デザインパターンを使うと、メソッド1つだけのクラスやら
実質１つのクラスしか使っていないインターフェイスやらが
たくさん増えるんだがこれでいいのでしょうか？
クラスの数ばかりが増えてあまり意味が無いような気がしてしまいます。

>>20 お前デザパタまったく理解出来てない。そういう対策もデザパタに書いてある。ちゃんとデザパタ読んで勉強し直せ。

Ａ「ユダヤ人はどの民族よりも優れています。」
Ｂ「その根拠は？」
Ａ「ユダヤ教の教典にそう書かれています。」
Ｂ「・・・」

＞20
デザパタ本に書かれてるかはわすれたが、
そのクラスの役割にメソッドの数は関係ないし、インターフェースの本質は役割の規定だが、たまたまその役割を受け継ぐクラスがひとつだけだったのであって、その役割の規定が正しいのなら問題ない

>>21
そういうのはデザパタ本じゃなくてリファクタリング関係の本じゃないのか？

厨房隔離ｽﾚｗｗｗ

オブジェクト指向と同じで、厨がキモイな

デザインパターンやってみる
　↓
理解できない
　↓
やつ当たりで2chで暴れる

>>26
それは無理がある。デザパタを理解しないうちに2chで暴れると、かえって
手負いの傷を負う。叩きのめされるからなｗ

デザパタは勉強してるけど、
実際にコーディングで役に立つことは少ないかも・・・

decoratorパターンなんて、java.io以外で
有用な例を挙げられないのだから・・・

そうですか。

えぇぇぇ使いまくりですが．．．
そのままじゃないですけど

技術板でコテハンやめろ、ウザくてむしろ賛成したくなってくる
いや、それが狙いか？

同意、しかもつまらんレスばかりだし。

コテハンにします。

>>20
> メソッド1つだけのクラスやら実質１つのクラスしか使っていない
> インターフェイスやらがたくさん増えるんだがこれでいいのでしょうか？

ブロック／クロージャがない言語だとそうなってしまうのは仕方ないと思われ

>>32
何を期待しているのかと。

GoF の読み方は「ゴフ」

乙一の本は「ゴス」

classloaderもデコレータパターンに近い気がするけどどうだろ。

>>21
おまえ普及させる気あるのかこのやろう。
新参者にはやさしく愛撫しながらスマイルで答えてさしあげろ

いや別に普及させる気ないならいいんだけど。

>>38
振る舞いという意味ではChain of Responsibilityパターンのような気が。
どっちでもいいんだけどね。構造で分類するか振る舞いで分類するかの違いだけで。

たんなる再帰呼び出しと違う？

>>41
クラスやオブジェクトの構造に言及している点が違う。
再帰呼び出しといった場合、手続き内から同一手続きを呼び出すという
手続きの振る舞いを述べているだけだが、
DecoratorパターンやChain of Responsibilityパターンと言った場合、
クラスの静的構造（クラスローダが別のクラスローダへの参照を持っている、
全てのクラスローダはClassLoaderクラスのサブクラスである、など）についても
述べたことになる。
「オブジェクト指向で再帰呼び出しするなら普通そうするだろ」と思うかもしれないが、
DecoratorパターンやChain of Responsibilityパターンでない再帰呼び出しもあり得る
（メソッド引数に移譲先のオブジェクトを渡す場合）のでそうとも言えない。

>>42
下らないことにもったい付けてるだけ

ダメだよ、自分が不勉強だって認めなきゃ（ｸｽ

>>44 あんたレベル低すぎだよ・・・

ていどひくい

会社で何かいやな事でもあったのかと。

>>28
>decoratorパターンなんて、java.io以外で
>有用な例を挙げられないのだから・・・
デザパタで成果を挙げているのはライブラリやフレームワーク側だけで
フロントのアプリケーションでは使わない結論。

Java厨は自分のアプリをすべてデザインパターン化しようと必死だぞ

>>46
すぐにレベルが低いとかそういう事いうやつは
スネオ並って事ですね。

＞48
そこまでよく出来たフレームがあるとフロントは楽でいいですね

Java厨曰く
せっかく覚えたデザパタに従ってないライブラリは全て糞

デザインパターン通りかどうかが
判断基準の全てなんだよな
JAVA厨って
だから糞な物作って自己満足(以下自主規制

以上、テンプレ終了

腐った餌は放置の方向で

せっかく新スレになったんだから、Java厨批判で無駄に汚すの止めてくれ

てかJava厨消えてくれ

コテハンも一緒に消えてくれ

せめてデザパタの話をしれ

>>48
そこでサクッと
フレームワークを
ageれば
みんな
納得するんだけど

Singleton パターンを用いるシーンが思いつきません。
クラス変数をプロパティとして持ち、そのアクセサ・メソッドを持つクラスで、
事足りるのでは？と思ったのですが、どうなのでしょうか？

インスタンスが一つだけという目的ならクラス変数を使用するようにすれば
良いのでは、と。

Java 厨と呼ばれても仕方が無い質問かもしれませんが、分かりやすく
教えていただければ助かります。

＞Singleton パターンを用いるシーンが思いつきません。

無いから。

俺は FlyWeight を兼ねて１つのクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった

俺はログ出力用のクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった
今は反省している。

ここでJava厨のデザパタ鵜呑み発言↓

サブシステムとしてグローバル的に使うものに多用してまふ
スレッドマネージャーとかそういう奴

さすがJava厨のデザパタ鵜呑み発言↑

つーか、そろそろデザパタの話をしようぜ
もうこのスレじゃ無理っぽいけど。

＞66
ではそういうときにジャバ厨でない人のやり方をどうぞ
↓

1. Singletonのインスタンスを2つ以上に変更できる
2. Singletonのインスタンスの振る舞いを、継承により変更できる

1. は、正直言って利点とは思えん。GoF本にはそう書いてあるが
そんなシチュエーションに出会ったことがない。

2. は、インスタンスメソッドなので継承が使えるということ。staticメソッドだと無理だから。
これを行う場合、ちょっとした言語依存の小細工が必要になる。
Javaなら、JDBCドライバのようにstatic initializer使えば何とかなるけど、
言語によっては他のパターン（Abstract Factory）を併用する必要がある。

ちなみに2だが、Webサービスクライアントで、通常時とデバッグ時で
異なるSingletonを渡して振る舞いを変えるコードを書いたことがある。

いま開発中の会社のアプリは大半のクラスがSingletonになってる。
デザパタは分かりやすくていい。

>>70
ご愁傷様です。これだからSingletonパターンは危険なんだ。

>>71
いや、プロトタイプベースな言語ならば問題ない……と言ってみる

>>69
>1. Singletonのインスタンスを2つ以上に変更できる
>2. Singletonのインスタンスの振る舞いを、継承により変更できる
3.どこからでも参照できる。

一番の利点だね。

>>73
staticメソッドもどこからでも参照できますが。

それじゃ、
staticメソッドを使わず、あえてSingletonを使う意義というものを
まじめに議論して見ましょう。

FIGHT! ⊂(ﾟ(ｴ)ﾟ)⊃

コーディングしている全てのクラスがFacadeパターンと言えないか？

>>75
例えば ClassA を Singleton にしても ClassA のオブジェクトとしてつかえることに変わりは無い
Singleton な ClassA をある日突然 Singleton じゃなくしても何も問題は起きない

>>76
そうなればより正しい設計といえるんじゃないか？

>>77 の下部
別に俺はデザパタヽ(´ー｀)ノﾊﾞﾝｻﾞｰｲじゃないとは言っておく
ただし、ごちゃごちゃしたクラスの塊は扱いたくない

>>68
ごめんなさい。
ちょっと矢印ではさんでみたかっただけなんです。
悪気はなかったんです。
ごめんなさい。

思ったより反応があったので喜んでいるのですが、ふと疑問に感じたことがあります。

>>69
>2. Singletonのインスタンスの振る舞いを、継承により変更できる
継承する場合、親クラス (Singleton) のコンストラクタへのアクセスって、
どうするのでしょうか？

>>74
私もそう思いました。

>>77
>Singleton な ClassA をある日突然 Singleton じゃなくしても何も問題は起きない
って、ClassA を Singleton だという前提で使用しているクラスがあれば、問題になるのでは？

>>80
一段落目：コンストラクタはprotectedで公開するだろうしサブクラスからは問題なくアクセスできるんちゃう？
二段落目：staticメソッドでアクセスできてもインスタンス化してないんじゃ状態をもてないでしょ。
三段落目：Singletonインスタンスへのリファレンスが一意であるとしてsomeObj == otherObjとしたときは問題になるかも。
でも、そういうことを避けるために隠蔽をかけるわけで、someObj.equals(otherObj)とやらせて==使ったときの挙動は保障しませんよとする。
C++とかではグローバルなスコープに一個だけオブジェクトを作成して他からexternさせる形をとる変わりに、
ファクトリメソッド使わせて一個のインスタンスを共有させるとか。

>>60
>クラス変数をプロパティとして持ち、そのアクセサ・メソッドを持つクラスで、
>事足りるのでは？と思ったのですが、どうなのでしょうか？

それはMonostateパターンという名前が付いている。

>>80
んーと、Java依存の話だけどこう。
class Singleton{
　static protected Singleton instance;
　// Singletonインスタンスを取得する例のコード。略。
}

class SubSingletonA{
　static{
　　instance = new SubSingletonA();
　}
}

class SubSingletonB{
　static{
　　instance = new SubSingletonB();
　}
}

当時はこうやった。instanceがprotectedなところは、
Singletonのコンストラクタでセットすれば良かったかも。こんな感じ。
private Singleton(Singleton s){
　instance = s;
}
で、サブクラス側はこう。
private SubSingletonA(){
　super(this);
}
色々書いていて、もはやAbstract Factoryなんじゃないかと思ってきた。
実際このクラスは様々なDAOのFactoryだったわけで。

それから、上のSingletonを使う側のコードはこんな感じです。最初の１回目にこうやって、
if(Bを使いたい){
　Singleton instance = SubSingletonA.getInstance();
} else {
　Singleton instance = SubSingletonB.getInstance();
}
あとはAかBか気にせずに以下のように使用する。
Singleton instance = Singleton.getInstance();

JDBCみたいにClass#forName()でもいいんだけど。

ぶっちゃけ Java案件って保守性低いよね。
個人の趣味が出すぎる

フレームワークをつかえ

>>81
>一段落目：コンストラクタはprotectedで公開するだろうしサブクラスからは問題なくアクセスできるんちゃう？
protected で宣言している場合は継承できると思いますが、同一パッケージから
new 出来るっていうのは、Singleton パターンと呼べるのでしょうか？

>二段落目：staticメソッドでアクセスできてもインスタンス化してないんじゃ状態をもてないでしょ。
状態、と表現するのか分からないのですが、クラス変数で良いのでは？と思ったのです。

>>82
Monostate パターン....勉強不足でした。
これから調べてみます。

引き続き、この板は読みつづけますが、レス下さった皆さん
ありがとうございました。

フレームワーク使っててもなんだかんだで自己満足な美意識を存分に発揮して
おかしなコードを書くやつが出てくる。


Cの案件ではコーディングルールを一律化して車輪は厳禁にしてるんで
仕事は早いしPGの差し替えも利く。

ぐぐって引っかかった奴
ttp://www.sk-jp.com/java/pattern/singleton.html
ttp://www.hyuki.com/techinfo/singleton.html
http://www.hyuki.com/dp/dpinfo.html
ttp://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=12&topic=5000
ttp://homepage3.nifty.com/satoshis/oo/memo.html#singleton

設定ファイルごとにシングルトンのラッパークラスを書くのって変？

好きにすればいいと思うよ

設定ファイルはSingletonの用途の成功例だろうと思うが

百済ねー

デザパタつかってりゃ、みんな成功例なんだろ
JAVAのライブラリの〜は、〜パターンの成功例だしな(　＾∀＾)ｹﾞﾗ

なんか、

Javaを莫迦にする香具師は死んだほうがいい
http://pc5.2ch.net/test/read.cgi/tech/1092308415/

ここと雰囲気似すぎてる様な。






とりあえず、
Javaな人はGoFスレ出入り禁止にしよう！
このスレこないでね！

馬鹿はﾆﾔﾆﾔしながら放置
自演始めてもぐっとこらえて放置

> Javaな人はGoFスレ出入り禁止にしよう！
そうでもしないと
いつまでたっても建設的な話にならない悪寒

＞ぐっとこらえて放置
つまり貴方はJAVA厨ってことですね？

>>85
>>88
>>92
>>93
>>97
.dispose

>>93
「デザパタつかってりゃ、みんな成功例なんだろ」

「デザパタ使っていれば成功です。」
誰かに言われ言葉の返事？
このスレには全く書かれてない。
すると貴方の職場で言われた？
ではなぜこのスレに返事するので？
職場では返事できないから？

なんてね。

>>99 日本語勉強してから出直してこい

>>60
DBCP

ジブロモクロロプロパン・・・じゃないな
データーベースコネクションプール？

ドラゴンボール厨房パワー

>>10をもう一度読むこと

必死で覚えたデザパタを
使うことが目的なんだから
使ってあれば成功例なのは当然

Singletonの利点は、あくまでそれが生成のみに関るってことだと思う。
例えば基本クラスXと派生クラスXA・XBがあって、XAとXBのインスタンスを
それぞれひとつに制限したいとする。
でも、Monostateでは共通部分（特にクラス変数）をXに書くわけにはいかないよね？
（C++ならtemplate等で実装共有するって手もあるだろうけど）
Singletonは生成方法を制限しているだけで、XAとXBは独立したインスタンスだから
そういう問題は出ない。

あと、>>74の言うようにメソッドまでstaticにするとさらに問題が……。
俺は以前、高速化のためにSingletonをやめて変数／メソッドを全部staticに
したことがあるんだけど、二つのインスタンスを共通の方法でアクセスする方法が
なくなって難儀した（ｗ
（実装はtemplateやマクロで共有。C++の話ね）
そんときはアクセス用のクラスを作って、アダプタかませてしのいだけど。

>>106
正解

またJava厨の自演かよ

>>108
正解

>>108
不正解
106 と 107 は別人だ

どちらにしろ、言ってることはあってる

まだいってるよ
誰が見ても >>106 = >>107 = >>110 だよな
あんな見当はずれなレスに
正解とかいう奴本人しかいないって(稾

>>111
見当はずれだったか？　すまん。

でも俺、コードはC++で書く方が好きなんだけど……。
それでもJava厨なのか？　訳わかんなくなってきた。

放置

>>111
ま、真相は俺と 106 氏のみが知っているということでFA
おまえら、別に俺が 106 氏と同一人物じゃなくても構わないんだろ？
ならどっちだっていいじゃねーか


それから付け加えると、Singleton は“生成に関するパターン”だな。
コレくらい、感覚でわからないのか？


ちなみに俺は C++/C# だな。そもそも Java は遊びでしかやらん

>>108 = >>109 = >>111みたいな馬鹿へ丁寧にレスしなくていいよ。
荒れるだけだから。

これがJava厨って生き物ですか(；´Д｀)

さわるなよ〜

このスレには「Java厨」は居ないが「Java厨かよ」と書き込んで話題を止めるヤツが常駐しているな。

>>118
正解

またJava厨の自演かよ

ageで書いてるあたり120は本物の池沼くさいなｗ

>>120
正解

Java中とか言ってる奴







　　馬鹿じゃねーの

Java厨氏んで

>>123
荒らしは死ね
Ｒｂｕｙ１！！！！！！！！！！！！１１Ｒｂｕｙｓａｉｋｙｏｕ ！！！！！！！！！！
Ｒｕｂｙｓａｉｋｏｕｇｅｎｇｏ ！！！！！！
Ｒｕｂｕｙａｎｔｏａｐｏｊｎｔｅ４ｐ２２２２２２２２２２２２
Ｒｕｂｙ！！！！！！！！！！

もっともデザインパターンに向いている言語はマクロアセンブラ

もっともデザインパターンに向いている言語はひまわり

もっともデザインパターンに向いてる言語はHSP!!!

いいかげんJava厨ｷｴﾛ

C#の言語仕様はJavaの言語仕様を全て含んでいるので
Javaでできることは全てC#でそのままできる。
それなのに何故
｢デザインパターンに最も適した言語はJavaだ」
という言説が生まれるのか？
よく分からんな・・・
言語仕様がシンプルだからいい、とでも言うのか？？？

>>130
本がいっぱい出てるから。

いやまじでこれは大きいよ。

>>130
どの発言に対するレス？

＞｢デザインパターンに最も適した言語はJavaだ」
どこに書いてあるの？

デザインパターンに最も適した言語はＲｕｂｙ！

>>132
脳内のヒト。

>>130
(´∇｀)ｹﾗｹﾗ
C# に Java のような匿名クラスなんて無いよ
Java に C# のようなデリゲートなんて無いよ
C# と Java の内部クラスの挙動は激しく違うよ

というか>>130は｢デザインパターンに最も適した言語はJavaだ」 という言説をどこで読んだんだ？
このスレで話題に上がっていないことを、突然語られても困るんだが。

>135
匿名クラスも内部クラスもデザインパターンで使わないだろ？
そんな瑣末な例を挙げるなよ。

宗教戦争はもうたくさんだ

>>138
C ++字軍に参加しませんか

>>137
130 の上から２行に突っ込んだだけだが……
デザパタとは関係ない部分であるにしろ、間違った認識を持つのはマズいぞ？

>>136
このスレはこのパターンの繰り返し。

>>136

あー>>130は >>99 これだろ。

>>138
では戦争を終わらせる為の戦争に参加したまえ。
我々は全てを飲み込む。

ブビ廚なんぞハナっから相手ではないわ

デザインパターンくらい知ってることが基本の職場に転職した。
意思疎通が格段に違う。
設計やビジネスプロセスの検討においても、「いわゆるCompositeで」とか平気で使えるし。

相手にパターンの知識がないことを前提におけない前職よりははるかにやりやすい。

そらよかったね。

そういうとこは開発プロセスも
アジャイルとかいう奴なんでしょうか。

>>145
どこの会社か教えてくれ。

>>148
それは言えない。でも実在する会社だよ。嘘じゃないよ。

色んな所に疑問を投げかけてマルチっぽくて
恐縮なんだけど、誰も明確にレスつけてくれないんで
145にききたいんですが。

もしその会社が、開発手法もバリバリアジャイルだったら
どうやって顧客に見積りを提示して
受注したのかすんごく知りたいのです。
色んな本読んでもどこにもその事が書いてなくて
すんごい疑問で、アジャイル開発ってとてもよいと思うけど
現実感がちいともわかんのです。

>>150
見積もりは、最終的なかたちは人月計算にしてる。
ただ、見積もりの再計算の機会を何回か設けている。

要件を追加するごとにお金を要求するのは、現実的ではない。
経営としてGOがでれば、成功時利益の5%とかできるけど、リスクが激高でこれも現実的ではない

特段に変わったことはしてないよ。
「要件定義が終わった段階で再見積り」という提案書を書く企業は多いでしょ。
顧客が予算を確保しやすい形にしてあげないと、本末転倒だし。

アジャイルにやっていく上で必要な管理は、要件を可視化してあげること。
プロジェクトが火を噴きそうになったときに、要件に優先度ABCをつけたりするでしょ。
あれをプロジェクトの最初からやるのが必須。
要件ごとに属性として締め切り期日やステータスを明示しておく。


UsecasePointみたいな方法は、
それこそ相当数の母集団による統計値があってはじめて成立するし。

# >>149は自分じゃない

>要件を可視化してあげること
すげーうちのデザパタ厨管理者に見習わせてやりてー。
まともなところは流石だな・・・用件を可視化できないくせに
部下には妄想アジャイルを求めるから最悪だ

いいかげん自作自演やめて出て逝けよ

お前がなー

＞151
わー初めて現場の声がきけたうれしー。ありがとう。
ありがとうついでにもちょっと。

所謂ウォーターフォールでも途中で再見積りってのは
確かにありましたが、やっぱりお客さんは良い顔しないものです。

それがアジャイル本読むと、具体的には例えば「実践UML」なんですが
要件が全て明確にならない内にどんどんイテレーションが進んでて
一体何時の段階で顧客との合意をとるのかが全然判らない。
その「要件定義が終わった段階」ってのが全然見えない訳で、
逆にそれが売り文句だったりしてます。
最初は要件は10%もあがればいい、網羅しようと思うなとまで
書いてあります。

あ、要件定義ってのはユースケースの事を言ってます。

一体何時見積もり承認取るのか、何回再見積りするのか、不思議で不思議で。
アメリカと日本の商習慣の違いなのかなあとまで考えてました。

で、おっしゃるように、要件をしっかりと視覚化して、
優先順位をきっちりつけて（トリアージといいますね）、
となると見積りに関する疑問は全く湧きません。私もするでしょう。
ただそうなると、書籍などで説かれるアジャイル開発とはややズレも感じます。
これはけなしてるのではなくて、より実践力がある形になってるという意味です。

他にも、いやうちはユースケース定義もアジャイルでやって
見積りもその都度見直しで顧客を納得させたぜって方のお話も、
本当にあるんだったらききたいです。

いやー本当有難う御座います。

いいかげん自作自演やめて出て逝けよ

理解できず煽ることしか出来ない人のいるスレはここですか?

civ3スレ荒らした馬鹿はお前かね？

いいレスつけてもらって感謝すると
大概ジサクジエン。
まあ風物詩ですからそれもまた一興。

でもデザパタスレからすると
スレ違いも否めんですな。すまん。

＞158
自分に対してのレスですか?　civ3が何のことかわかりませんが．

＞159
スレ違いじゃない．もっとやってくれ。

どっちかって言うとこっちのスレのほうが適切
ttp://pc5.2ch.net/test/read.cgi/tech/1091773629

指定厨とクソコテがいる限りこのスレは駄目だろ

Java厨ってほんと見苦しいね
頼むから氏んで(・∀・)

なんか、脳内世界の発表会みたいなスレになってるね。

>>164
そうそう。会話になってないよな。

目を覆いたくなるような恥ずかしい自作自演だ
自分だったら首釣って氏んでるな

>>166
だからさぁ、誰に言ってんの？
脳内世界の語り手って言われちまうぞ

脳内世界の語り手登場

VB.NETでもC#.NETでもいいけど、MS系でデザインパターンしてるやついる？

MFCで　｡･ﾟ･(ﾉД‘)･ﾟ･｡

>>169
やってるよ

SDKで。

> わー初めて現場の声がきけたうれしー。ありがとう。
ﾜﾗﾀ

>>170
>>171
>>172
MFCとかSDKとかそういうんじゃなくてさ、 業務でよ。

業務でSDKだよ。
MSだろうがなんだろうが
関係ないだろ。

>>169
>>174
「デザインパターンしてる」って何よ。

デザパタってる。

＞174
それらのレスみたらMFCベースの開発でとか、SDKベースの開発でという意味でしょう.
そもそも、言語ならともかく、MS系でというのが何を指すのかよくわからんです...

モビルスーツか？

>>178
つまり実務でC#使っているやつは、デザインパターンを知らないどころか、自分でクラス作れるやついないってことだな

>>180
流石に C# でクラスを作れない奴は居ないだろう。
この場合引き合いに出されるのは　『クラスを使えるか』 もしくは 『クラスに使われるか』 だ。

実務でC#使っているが、俺のプロジェクト誰一人としてまともなクラス作れてない
C++/Java上がりの連中なんだがな、どうしたものか。

まともなクラスの定義はなんだよ。
C++/Java上がりの連中はCLRのクラス構成を熟知しているわけじゃないんだから
いきなり投げ込まれても正しく分析なんてできないだろ。

>>183
逆でしょ、CLRだなんだっての知ってても
それは実装レベルの話じゃん。

普通「まともなクラスが作れない」という場合は
設計レベルの話だよね。言語は関係ない。

他のオブジェクト指向言語経験者なら
出来ると思ってたのになって事でしょ、182は。

>>182
まず他人と会話してみるのがいいと思うよ

＞182
俺のプロジェクトが一人プロジェクトだったら面白い

デザインパターンしてる。
デザパタってる。
デザってる。
パタってる。
ザパってる。
タってる。

>>182
どれがいい？

デンパってる、がいい。

IT Pro 技術の広場
羽生田栄一の「オブジェクト論」
http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20040907/1/mokuji.jsp
羽生田栄一の「デザイン・パターン論」
http://itpro.nikkeibp.co.jp/members/NBY/techsquare/20041006/150890/mokuji.jsp

お気に入りの新着をすべて開くの動作が変わった?
新着あるものすべて開くんだけど、新茶区分を取得しに行かない.

とおもったら、その他のすべてを開くうんぬんで直った　
あと更新チェック５分の待機時間長すぎ

誤爆スマン

>>189
宣伝乙

安定したインタフェースを抽出できなくて困っている。
俺の頭が悪いのか？　･ﾟ･(ﾉД‘)･ﾟ･｡

対象としているもののアルゴリズムは安定しているんだけどな．．．
インタフェースを中心に据えなくちゃオブジェクト指向と言えないですよね？

>>193
最後の行に書いてるようなことを気にしすぎてはいけない。

これ読め、できれば本も。
ttp://www.ogis-ri.co.jp/otc/hiroba/technical/MPD/

マルチパラダイムデザインの中核となる概念は共通性と可変性だ。
お前のドメインでアルゴリズムが安定要素なのであれば、それに応じた
ソリューションがあるということ。

>>それに応じたソリューションがあるということ。

それがわからないから苦労してるんでしょ？
閉経

何も言ってないのと同じだよな。
断言すると叩かれる、だから曖昧にしておく。

ソリューションドメインの分析をしなきゃいけないようだけど
>>193の環境がわからないことには始まらない。C++だというなら
当てはまるのかも試練が。

俺も、マルチパラダイムデザインは白眉だと思う。

「共通性と可変性」だけに言及するとなんか当たり前っぽいけど、
凄い分析なのは「共通性と、正の可変性と、負の可変性」に分類したこと。
読め。おら読め。

マルチパラダイムデザインですかー
本自体は聞いたことあるけど読んでみることにします。

>>197 C++です。当てはまるというので期待してます。

現実の問題領域がシングルパラダイムでは表現できないなんて当然だよな。

インタフェースを中心に据えなくちゃ・・・
なんて風潮があるとしたらほんと有害。

マルチパラダイムデザイン・・・

売ってない　･ﾟ･(ﾉД‘)･ﾟ･｡

そこでマルチパラダイムして別の本を買え！

>>200
俺は据えても構わないと思うんだけど
周りを残しておけば

>>201
bk1 に残ってるみたい。今俺も注文した

>>203
> 俺は据えても構わないと思うんだけど
> 周りを残しておけば

なんかコワい雰囲気・・・
迂闊に近寄ると切られるかも

>>204
切らんよw

マルチパラダイム届いた。ざっと目を通してみたけど、
設計手法をパターン化し、『一歩離れたところから見て』まとめた
モノとして考えていいの？なにやらごちゃごちゃ書いてあるけど

読み終わったか？

読み終わった
理解にはもう少し時間かかると思う

すごいじゃないか！こんな短時間で読み終わるだなんて！！






実は半分しか読んでない俺にエッセンスを教えてくれ

マルチパラダイムに対する
『シングル』の方はどんなパラダイムなわけ？

独身パラダイム

マジレスまたは真面目な付き合いを望む

>>209
無理だ。内容が濃すぎて頭の端から抜けていく^-^;

>>212
とりあえず、全然理解できていない身で悪いが、

『シングルパラダイム』とは、今まで使用されてきたとおりの言語パラダイム
（例えばオブジェクト指向とか）を指すようだ

『マルチパラダイム』は、それらシングルパラダイムを全部ひっくるめて
さらに＋αしたものを考える手法を指っぽい

違うかも。っていうか例の本は生半可な気持ちで読むもんじゃない＝■○＿

逆に自然体だよなあ

△△を中心に据えよ！

．．．って気張るよりも

117ページ

オブジェクト指向パラダイムは、型と構造に共通性を仮定する。
そして、実装において可変性を表現する。ファミリの構成員を
この枠組みに溶かし込むことができるのであれば、オブジェク
トパラダイムはよくフィットしているということになる。

・・・やってみなきゃわからないってこと？

ポリモーフィズムうまく使えるようにモデリングできるかということはないのか？
ポリモーフィズム使えるということは汎化がうまくいって、共通の枠組みに押し込めてるということだから。

ポリモと言えばp114とp137にあるように広く見てるね

１　多重定義・・・つまりオーバーロード
２　パラメタライズド・・・クラステンプレートと関数テンプレート
３　キャストによる型変換
４　継承による普通の（せまい）意味でのポリモ

の４つをポリモと表現してる

それは広すぎるんでは？

キャストして他の型にしてからそっちの機能を使うっての
までポリモーフィズム？
テンプレートは「コンパイルタイムポリモーフィズム」と
呼ばれることもあるので違和感少ないが。

ポリモーフィズムといえば４のようなことを言うんだと思ってた
頭固いかな

キャストをポリモと解釈しているのは、キャストしても
もとのオブジェクトのアイデンティティが保たれている
と想定しているからだろ。
多態、すなわち同一のものがいろいろな側面を見せる
って意味ではキャストしようが何しようが構わんという
立場。

デザパタとはどんどん離れてないか？

RMIで扱うスタブを末端のオブジェクトに渡すのってあまりよくないですよね？
皆さんだったらどうしますか？
僕はADAPTERパターンがいいのかな？と感じました。

Gammaです・・・

ADAPTERパターンがいいと思ったらとりあえず実装してみては？

・・・Gammaです

>>223
Erich Gammaの事かな？
まだ皆さんの意見を聞きたいですが、早速実装してみます。

Gammaです・・・

ADAPTERパターンがダメだといっても、たぶんこの人は反論して使うとです。

・・・Gammaです

>>225
人がどのように行動するか不確かな根拠で予言するのはスレ違いだと思います。
でも一応意見を参考にさせていただくことにしました。
今後適応パターンの判断から実装まで弟に任せることにしました。
うちの弟はどうですか？

>>224
偽Gammaに負けずにがんがれ！

>>227
応援ありがとうございます。
でももう弟に任せたから、弟に頑張ってもらうつもりです。
弟もこのスレ利用するかもしれないので、そのときはよろしくお願いします。

＞228
弟
http://life5.2ch.net/test/read.cgi/jinsei/1097681554/

State パターン使う場面を見出せなかったが、ゲームの状態遷移に思いっきり使えると気づいた今日この頃
気づくの遅いなぁ orz

Stateパターンはものすごく参考になった。
switch文はほとんど出番なしなﾖｶｰｿ

＞229
何このスレ･･･
ねた?

State と Strategy の違いってどんなんだっけ？

>>233
どちらも委譲で挙動をごっそり替える点では同じ

State … クラスで状態を表す
Strategy … アルゴリズムを切り替える
という目的において異なる

ありがとう
でも、目的が異なるって説明はいろんなところで
見た覚えがある（State vs. Strategy に限らず)けど
それだけじゃ異なるパターンとして別にする程のこと？
って思いが残る．．．

>>235
デザインパターンが主とするオブジェクトパラダイムだと、
現実世界と如何に対応させるかが１つの焦点となるから、
ある意味でこれは自然な事だと思うけど……

目的が異なるってことだけなら、クラス図は多少違うけど
CommandとStrategyも似ているよね。
違いはサブクラスの許容量の違いだと認識しているんだけど
Strategy・・・何かしらの共通目的をもつ
Command・・・何でも良い。
違う？

とりあえず例の本を読み切った
『可変性』って言葉は、「仕様の変更に対処するための柔軟性」って読みかえてもいいものだろうか……



そんなことはどうでも良い

『Chain of Responsibility』パターンだけど、
各オブジェクトが「次のオブジェクト」を知っている必要があるのは何となく違和感があるような気もする
俺の場合、単純だが処理にかかわる全てのオブジェクトを保持するクラスを作り

foreach(Handler c in handle) {
    if (c.handleRequest()) {
        break;    // 処理できたら抜ける
    }
}

みたいな感じにすることが多いが、『CoR』パターンって使ったことある人いる？

構文木みたいのも一種のChain of Responibilityじゃないかな。
それなら何度も使ってる。

>>238
イメージ／オーディオ／ビデオのフィルタみたいなのもCoRじゃないのかな？
同型インターフェイスを持つオブジェクトを自由に接続して連鎖的に処理させるやつ。

> 各オブジェクトが「次のオブジェクト」を知っている必要があるのは何となく違和感があるような気もする
例えば、各オブジェクトが「次のオブジェクト」の持つ属性によって処理を変えたい場合とか。

>>239-240
あ〜何となく分かった
今まで CoR を「処理を行うオブジェクトを探す」用途としてしか見てなかったみたい

確かに処理のパイプラインみたいなのも、CoR の一種として考えられるような気がする
サンクス。参考になった

もうGoF本から外した方がいいパターンはないかね？

・・・投票の結果、4つのパターンが締め出された。
Factory Method、Bridge、Flyweight、そしてInterpreterだ。

ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?OOPSLA2004

BridgeはStateとStrategyがあるからもういいや、ってこと？

>>242
Bridgeは特定の言語以外では有効な使い道がないからじゃないですかね。
JavaやSmalltalkでBridgeの使い道ってありますか?

Flyweightは、富豪的プログラミングに反するからですよね:-)

用途が特化されすぎると「用途が限られるからパターンじゃない」と言われ
用途が一般的過ぎると「そんなのパターンと呼ばなくても普通に使うだろ」と言われる。
適度に用途が限定されたパターンというのはそんなに多くないかもね。
http://hp.vector.co.jp/authors/VA020635/system/dpattern.html

なんかいろんなスレで本文のない書き込みがあるんだが、誰かなんか作って変なテストしてるのか？

>246
クソスレ見すぎ

クソコテがクソスレをつくる

またチ（ｒｙ

糞スレを作るのは、コテハンをみると決まって過剰反応する厨房名無しだろ。

臆病者が伏せ字を使っていい気になってるスレはここですか？

>>250
同意
俺の場合246は透明あぼ〜んされている
これお薦め

>>244
ところでマジネタなんだが、パターンってつまり『クラス間の関係を表す』ものだと俺は認識してるから、
＞「そんなのパターンと呼ばなくても普通に使うだろ」
ってすごく変な感じがする。

デザパタって、困ったときの道具箱じゃないのにな〜

『アンケート』
実際に使ったことのあるデザインパターン
さぁどぞ

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

visitor

し、しんぐるとん…　にゃんにゃん

State

composit, iterate, visitor, builder, facade

Product Trader パターンについて詳しく書かれているサイト or 本ってないですか？

Singleton,Observer,state,Strategy,facade,Composite,Command,

Singleton, Mediator, Strategy, Composition, Visitor

卑怯な手段としての
Mediator

どんな場面で使ったとかコメントもあるとおもしろいかも
300取ったやつカウントよろしく
じゃ続き

↓↓↓↓↓↓↓↓↓↓↓↓↓

Mediatorっていうか今思うとFunctorだな。
Mediatorの抽象ベースクラスがあって、派生クラスはテンプレート。
Boostのファンクタみたいな感じ。
５年以上前にしちゃイケてたかな。。。

GoF 以外でどんなパターン使ってる？

アンチパターン

IoCってGoF？

表面上ファクトリー使うから関係はあるけど
パターン自体は入ってない、よな。

ぬるぽパターン

DIって、spring出るまで知らなかったけど
割と最近の手法なのかな。

>>269
ｶﾞｯ　パターン

ttp://patterns-wg.fuka.info.waseda.ac.jp/study/8th.html
最近ググって見つけたんだけど、ひがやすを氏の説明がわかりやすかった

Mediatorパターンと、Observerパターンの違いがよくわからないのですが、俺なりには、
同僚にイベントを通知されるのがMediatorパターン
非同僚にイベントを通知するのがObserverパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

>>273
解からないなら解かるようになるまで教典を読みましょう。

>>273
Mediatorは通知先を個体識別している。
Observerはしていない。
Mediatorは、なんかのイベント発生時に、どの通知先に何をすべきか知っている。
Obserberは、しらない。イベントが発生したことを知らせるだけ。通知を受けて何をするかは、Observable が決める。

>>273
ObserverとMediatorの比較ということなら，
Observerを適用した場合　通知相手のオブジェクトに関する情報が
各オブジェクトに分散して管理が難しくなることがある
Mediatorの場合はMediator役が通知の交通整理を一手に引き受けるので
Observerを適用した場合に比べ管理は簡単になる（が，クラス間の結合が若干強くなる）

どちらを使うかは状況次第
教典の適用可能性とか目的とかの項を読んで判断

…でいいのかな…自信ないけど

>>270
昔から「コールバック」という名前で知られていたのでは

>>277
コールバックとは違うようなが気がしないでもないが
勉強不足なのでよくわからない　だれか解説ｷﾎﾞﾝﾇ

パターンってのは熟練開発者の中に眠るノウハウに名前をつけて
明文化する手段だから「〜は昔からあった」という指摘は多いね
逆にそういう知識でないとパターンになりえないんだけど

>>278
『ノウハウ』というのは格好付け過ぎかと

よく見るクラス間の構造が『パターン』だと俺は認識してる
熟練とかそんなのは関係なかったり

一番最後の行には激しく同意
この行に疑問を持つ人は、一体どういう認識でデザパタを捉えているのか正直知りたい

Strategyパターンと、Observerパターンと、Stateパターンの違いがよくわからないのですが、俺なりには、
入れ替える中身が戦略だとStrategyパターン
入れ替える中身が観察者だとObserverパターン
入れ替える中身が状態だとStateパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

もくてきぜんぜんちゃうやん。
同じどうさせアルゴリズム変わってるのがストラテジーで
状態による動作の変化を隠蔽したのがState
相手のことを知らず通知したいときがObserver

>>279
278は，デザパタも含む，もっと広い意味でのパターンを
思い浮かべながら書いてた
デザパタスレだということをすっかり忘れてたorz　すまぬ

>一番最後の行には激しく同意
(･∀･)人(･∀･)

>>280
オブジェクトを互いに交換可能にして再利用しやすくする，
という目的なら共通している気がしないでもないけど，
それはデザインパターン全体で共通する目的でもある
教典の名前に入ってるくらいだし＞オブジェクト指向における再利用のための〜

>>280
形は似ているからね。特に Strategy と State は。
形が似ていても目的が違うときには、違う名前をつけるのが、
デザイン・パターン流みたいだね。>>281はそのことを言っている。

クラス図同じだしな

美しいソースコードを書いても給料は上がらないし会社は評価してくれない。
かなしいけどコレが現実。デザパタは知識としてはある程度有意義だけど
プログラムで一番重要なのは「ちゃんと動く」こと。次に手を抜くこと。
君たちは真面目すぎる。もういっぺん言おう
美しいソースコードを書いても

　会　社　は　評　価　し　て　く　れ　な　い

デザパタってコーディング技術じゃなくて設計技術だろ

そうすると「コーディング技術」とはなんだろう・・・。
キーボードを早く打てるぜ俺は、とかに
なっちゃうんだろうか・・・。

イディオムとかそういう類じゃないかな。
ファイルアクセス時のtry〜catchはこう書け、とか、文字列のNULLチェックはこうしろ、とか。

なるほど。言語依存な所な訳ね。

いや、そんなに言語依存でもないか。
リソースはちゃんと解放しようぜ、とかそういう話か。

そもそもデザインって設計って意味だよな。
そりゃ設計技術だよもちろん。

>>290
俺は『クラス関係のデザイン』やとおもとった
……っていうか設計と同じ意味か

>>285 は、もう一度デザパタを勉強しなおすこと

>291
そうそう、日本語カタカナでデザインていうと、
クリエーチブな業界のイメージだろうから
285みたいな意見が出るのだろうか。
考えすぎか。

とかいう俺もデザパタって言葉を知るまで
設計がデザインと訳されるとは知らなかったんだけどね。
おほほ。

285は、「なるべく簡単にちゃんと動く」こととデザパタを相反する概念と考えているみたいだけど、なんでだろ
。デザパタは、「なるべく簡単にちゃんと動く」ための工夫に他ならないのに。惜しいね。

>>285
自分が楽をするために学んでるだけだからね。
会社の評価なんてどうでもいいよ。
会社の評価のためにやってるんだったら無駄だから勉強しないほうがいいよ。

>>286
あれが設計技術か！？
思いっきりコーディング技術だと思うけど。

>>294
御前はクラス間設計をコーティング時にやってるのか？

正直、なんで御前がそんな見切り発進で生きてられるのか不思議でたまらん
（ちなみに、罵っているわけじゃなくて純粋な疑問）


悪いことは言わない。その考えはすぐに改めた方が身の為だと思う
クラス間設計はコーティング時じゃなくて設計時にやっとけ

デザインパターンだけど実装方法も定義してあるから
コーディング技術も含む設計技術なんじゃないですか？

>>296
どの本だよ実装方法なんて定義してあるのは

>>296
実装は例示されているだけです(教典だとSample Code)
一応Implementationに実装方法についての議論はあるけど，
あくまで付加情報だと思う

コーディングは技術ではなく技能だ
とか言ってみる

そうっすね定義っていう言い方は間違いでした。
ただ自分はプログラマーなので実装のために読んだ。
SEだと見方もかわるのではと思う。

本
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797311126/qid=1103803514/ref=sr_8_xs_ap_i1_xgl/249-8017190-9045969
ttp://www.amazon.co.jp/exec/obidos/ASIN/0201633612/249-8017190-9045969

>>300
とりあえず、一冊の本から何を学ぶかはその人の能力次第だから文句のつけようが無いが、
俺はデザパタは設計技術だと思った。


色々と偉そうな事言ってごめん。
俺、SE でも PG でも無いただの学生、しかも本は結城本 orz

>>285みたいな化石人間ってさ、自分がマトモな実装技術を理解できずに
スパゲッティコードを量産して「仕事ってのは芸術じゃなくて作業なんだよ！」
とか言って、部下に自分のダメコードのデバッグを押し付けるダメSEの
典型的な発想だよね。

ちなみに言うと、デザインパターンってのは、別に
「美しいソースコードを書いて自己陶酔や品評会をするための技術」じゃなくて
「実装やデバッグや仕様変更で可能な限り楽をするための技術」だから、
有能なプログラマであれば、GoF本を初めて読みながら
「これって俺が前に自分で考えた仕組みと同じじゃんｗ」って思えるもんだよ。

>>303
同感

俺は決して有能なわけじゃないが、知らず知らずの内にパターンに嵌る事って意外と多いよな
……Visitor が自然と組めたのにはビビッたよ

>303
>ちなみに言うと、デザインパターンってのは、別に
>「美しいソースコードを書いて自己陶酔や品評会をするための技術」じゃなくて
>「実装やデバッグや仕様変更で可能な限り楽をするための技術」だから、

ちなみに言うと、デザインパターンってのは、別に
「実装やデバッグや仕様変更で可能な限り楽をするための技術」じゃなくて
「既存の技術に覚え易い名前を付けてカタログ化した」だけのもの。

>>305
別に「GoFが全く新規に提案した」なんて前置きをつけてないし。

有能プログラマがGoF本を読む
→身に覚えがあるのですんなり理解

無能プログラマがGoF本を読む
→全く想像すらした事の無い発想ばかりで全く理解不能
→そして強烈なアンチGoFになり、GoF本を読む部下に嫌味を言いまくりｗ
→設計会議で「パターン」なんて言葉が出ようものなら「俺たちは芸術家じゃねーんだよ！」

その典型が>>285ｗ

だからさ･･･でざぱたはそれまでのプログラム経験の中で有効だと思えたものを選んで分類整理したものだろ？
それ考えればおのぞから答え出てくるかと･･･

しかし Bridge と FactoryMethod は有効だと思えない
俺の理解が浅いだけで、本当はいたるところで使われているのかもしれないが

>>308
その2つの用途が分からんってのは、
お前がマトモにプログラムを書いた経験がないってのが丸分かりだな。

恥ずかしすぎるｗｗ

>>309
すまぬ。俺の理解が浅かっただけらしい。

本だけで感じがつかめなかったから先ほどぐぐった。
どうやら、サブクラス関連で引っかかってたみたい。
過大解釈すれば、両方とも死ぬほど使ってる罠 orz

恥ずかしいので引っ込んでます |λ...

>>308
がんがれ

実装と振る舞いが分離されてりゃ全部 Bridge に分類されるのか？　素朴な疑問。

だから、べつにパターンに分類することないんだツーの。
そのパターンらしきもの使うことで分離の利点を得られるならそれでいいんじゃ。

>>295
ごめん。考え方の路線が違う意味でいった。

例えばシステムの要件を満たすのにどの言語が適してるのかとか、
過去のデータを集計したり、ソートしたりしたいとか言う奴がいたら、
んじゃ、ＣＳＶでデータ吐くからExcelかなんかでソートでも集計でもなんでもしてくれとか、
そういう視点の意味で言ってみた。

デザパタはたしかに設計ではあるけど「コーディングの設計」 だと思う。
コーディングをしない限り適用する場面はないわけだし。
そういう意味で、やっぱ「コーディング技術」なのではなかろか。

>>314
む〜考え方が違うのか

俺はコーティングするしないに関わらずデザパタ適用するけどな
コーティングするのはそっから後

>>312
ストラテジーとかいうのも実装と振る舞いが分離されているパターンだと思った。

というか、分類なぞどうでもいいと思われ。
StrategyもBridgeも「実装が容易に入れ替えられる」という
利点が得られればよい訳なのだから。

>>313
おお。激しく同意。

>>316 上段
たぶん　Strategy と Bridge は違うっしょ

オブジェクト指向の基本概念の1つに
・継承、委譲などでの差分プログラミング
ってのがあるけど、殆どのデザパタはそれを使うから……

317 の理由から、Strategy と Bridge に似ている部分があるのは当たり前
けど、この2つはぜんぜん違うと思う

>>317
基本概念を
・実装と振る舞いの分離
に訂正

……微妙に例が適切じゃなかった

>>315
クラス間設計をコーディング前にしっかりやるというは激しく同意。
いきなりコーディングからはじめるとわけのわからんものが出来あがって後で後悔するし。

すまぬ。漏れ設計っていわれちゃうと基本設計書とかそんなのが浮かんでしまうので。

>>320
＞漏れ設計っていわれちゃうと基本設計書とかそんなのが浮かんでしまうので。 
ああ、確かにそれならコーティングの設計というのはよく分かるわ

StrategyとBridgeなんてまったく違うだろ。

Strategyは
・実装種類にかかわらず呼び出し形式(=INパラメータおよび戻り値)は共通
・実装種類によって処理内容のみが異なる
・Strategyとしてまとめることで、実装種類を入れ替えられるようになる

Bridgeは
・実装種類にかかわらず処理内容は一緒
・実装種類によって呼び出し形式が異なる
・呼び出し形式を共通にしたBridgeを、実装種類ごとに用意する
・Bridgeを経由することで、実装種類を入れ替えられるようになる

俺が大雑把なのかも知らんが両方ともたたいの一種としてしか認識してません･･･

>>323
一言で多態でくくらずに、分類して名前をつけることに意味があるんだと思われ。

>>322
そうまとめられるとBridgeはadaptorに似てるな。
共通のIFを定義して、実装種類ごとに共通のIFに合うようにadaptorを用意すると。

ところでStrategyとTemplateって実現方法として委譲を使うか、継承をつかうか
しか違いが無いように思うんだけど、それ以外に違いってある？

>>324
デザインパターンは、適用後の姿をすべて見てしまうと「おんなじじゃん」となってしまう。
適用前の時点で何が分かっているのかに注目してみたらいいよ。

Strategy
なにかサービスを受け取るクライアントを作っている。
　ServiceResult result = serviceExecutor.execute(serviceStrategy);
サービスの実処理はいろいろある(もしくは、今は分からない)
→Strategyにして判断を後回しにしよう。

Template
何かサービスを実行するサーバーをいろいろと作っている。
前処理とか後始末とかあったりして、こいつら似てるな。
→Templateにしてまとめてしまおう。

パターンというからにはテンプレートとしていつでも使えるようにすべき。
素人にもパターンを使えるようにするには、
いちいちそのパターンを意識してコードを書く、という概念モデルの段階では無理。
素人はパターン実装に振り回されて終わる可能性がある。
リストボックスから選択するなりして目的に合致するパターンを、
テンプレートとして即座に使える様な配慮が必要。
よって今後はテンプレート化できないような概念モデルは淘汰されていくだろう。

>>326
お前は一生VBでトイプログラムでも作ってろｗ
もちろん、いっちょまえにシェアレジを利用してｗｗ

UMLツールでパターン名のステレオタイプを書けたりする訳だが

>>326
マジレスすると，
パターンは(素人でも使えることを目的にした)テンプレートではない．
知識を共有するための枠組み．(ソフトウェア設計への適用がデザパタ)
素人が素人から脱却する助けにはなりうるが，
素人がパターンを使っても良質なソフトウェアを作ることが出来るわけではない．

すまん，俺学生でトイプログラムレベルのものしか書いたことない・・・

>>329
なら偉そうな事を言うな。カス。

>>330
あんたよりはマトモに理解しているぞ、329は。

>>331
そうでもないよ。

ではがんばって プログラム オブ 女医トイ つくってください

>>333
寒すぎて忘年会の酔いもすっかり冷めた

カスとか、トイプログラムでも作ってろｗ とか
おまいらは小学生か。
反論するならもっとまともな発言しる。

カスはカスでいいじゃん。

そんなおまいらに
ttp://www.shos.info/develop/oo/dscsnptn.html

>>337
おもしろい！

保守age

Visitorパターンで、木構造（DOMツリーに毛がはえたようなもの）をたどる処理を書いています。
ここで、木構造を「たどる」という処理を、Visitor側で行うべきか、Acceptorとなる木のほうで行うべきか悩んでます。
今はVisitor側で行っているんだけど、Acceptor側の構造が変わったときにいちいち整合性をとるのが面倒になってきました。
みなさん、どっちに書いてます？

>>340
たどる処理って iterator がやるんじゃないのか？

>>340
各家を辿るのは訪問者の役目だから Visitor
Acceptor 側で違いが吸収できないくらい構造が変わったら、さっさと Visitor パターンを使うのを止めれ

どう考えてもvisitor

辿る側が Visitor で辿られる側が Acceptor
辿るクラスが入れ替わったら、Visitor も↑を満たすように入れ替わる

というか、>>340 は考え方が逆のような気がする
どちらかを Visitor と決めて辿るクラスをそれに合わせるわけじゃないよ

>>341-344
「たどる側がVisitor」って、いわれてみればそのとおり。だからVisitorという名前なんだよな。
どうもありがとう。めんどうでもがんばる。

つーかデザインパターンはさー
正しいOOPをするためのイディオム群という側面も確かにあるが、
それよりも重要なのは、開発者の間でFactoryとかStrategyっていう概念を
共有できることにあるんだろんー？
UMLと同じ勘違いをされてる気がするな。UMLも、あれは設計を記述することそのものより、
クラス設計を開発者間で共有することが重要なんだろー。

・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「・・・？」

・デザインパターンを知ってるＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、このクラスのインスタンスは二つ以上あるとまずいからSingletonを適用しよう。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、Strategyを使って柔軟に処理を選択できるようにしよう。」
Ａ「ＯＫ」

確かに、枠組みであるという点でパターンとUMLは似ているかもしれない。

>>346
だいたい同意。
パターン名がコミュニケーションの語彙となるということだな。
GoFの一人であるブリシデスが言ってるな。(「パターンハッチング」)

あと細かいけど、デザインパターン≠イディオム

ああ、確かにイディオムってのは違うな。
イディオムと言えるほど具体的なコードで表せるのはSingletonくらいか？ｽﾏｿ

お客さんが満足するのでデザパタを使っています

>>340
遅レスだがツリー構造を知る第３者がVisitorをAccepterに突っ込ませたほうがいいんじゃないのか?
自分ならそうするが。
なんでVisitorがAccepterのコンテナのデータ構造を知らなきゃいかんの?

>>350
ツリー構造を知る第３者 = >>341のいうiterator
かな？

>なんでVisitorがAccepterのコンテナのデータ構造を知らなきゃいかんの?
禿同。

>>348
イディオムは言語依存っていうイメージがあるなぁ。

>>351
＞ツリー構造を知る第３者 = >>341のいうiterator
＞かな？
”んーVisitorをAcceptorに突っ込ませる人”です。
南下のクラスかもしれないし、コマンド処理するところにじか書きかもしれないし。
Visitorが自分でAcceptorに入り込んでいくよりは誰かがVisitorを突っ込ませるイメージだったので

>>346
・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「ＯＫ」


だと思うぞ。言いたいことは分かるが。

・デザインパターンを知ってるＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「あ？これSingleton、こっちStrategy。」
Ａ「え〜っと、これをSingletonに、こっちをStrategyにするのは何故？」
Ｂ「（ﾟДﾟ）ﾊｧ? 駄目だオマエ（ ´,_ゝ｀）ﾌﾟｯ」

デザインパターンはコミュニケーションを阻害します！ｗ

デザインパターンとアンチパターンの融合か
美しいな

>>354
コミュニケーションを阻害しているのはBの態度だろうｗ

(1) Aは本当に分かっていない
(2) AはBの判断(2行目)が適切ではないと考え説明を求めた
Bが(2)の可能性を無視してるのが元凶ですな

って真面目にレスした私は釣られたのか？まぁいいや

空気嫁てないだけ

・デザインパターンを知らないＡ君とＢ君の場合
Ａ「おいＢ、ここどうやって実装する？」
Ｂ「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
Ａ「え〜っと、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにして、
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲するのはなぜ」
Ｂ「（ﾟДﾟ）ﾊｧ? 駄目だオマエ（ ´,_ゝ｀）ﾌﾟｯ」

問題はＢの態度と判明

こぶがひっこんじまったい

>>359
ﾜﾛﾀ

ファウラー氏のアナリシスパターンが意味分からん。

>>362
分析屋さん(?)が読むような本だからね…。
「責任関係」とか「観測」あたりは比較的分かりやすいと思われ
ｶﾞﾝｶﾞﾚ

>>362
だいじょうぶ、わからんのはおまえだけじゃない。みんなわかったふりしてるだけだ。

俺もわかんね

何でそういう風に分析する糧のを考えるのにはいいね。
覚えるもんじゃない。考え方を学ぶもの。

C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

MedieterとObserverの違いを普通に教えてください。
集中管理という目的では同じに見えるんですが。

>>368
前者は伝達経路に対するパターン。
後者は伝達方法に対するパターン。
両者はそもそも目的が違う。

>>369
やはり目的の違いですか。
statとstrategyの違いみたいな感じ？

>>368
このスレくらい嫁
>>273-276

http://www.ogis-ri.co.jp/otc/hiroba/technical/JPLoP/DPforRDB.html
数少ない日本発デザインパターンのひとつ

デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html

天麩羅追加きぼん（次スレがあれば）

最近DQ8をやっていて思ったこと。
1.
「さまようよろい」は、戦闘中に「ホイミスライム」を呼びます。
「じごくのよろい」は、戦闘中に「ベホマスライム」を呼びます。

・・・あ、これってある意味"Abstract Factory"じゃね？

2.
新しい街にやってきた主人公達御一行。
まずは民家・店・井戸の中など、入れる建物に片っ端から訪れて、
中にあるツボやタルやタンスなどを物色します。

・・・あ、Visitorパターンじゃん！

デザインパターンを知ってると、こういう些細なことに対して
思わずにやっとなってしまいます。

>>374
真性ｦﾀ

可愛いあの子をObserve

キモい>>376を Two-Phase Termination

>>376 はストーカーパターン

>>378
アンチパターンだよね

>>377
だけど私はImmutable

そいつぁItrator。

>>381
×Itrator
○Iterator

短時間でデザインパターンの全貌をなんとなくつかむには何がオススメですか？
「まずはこの Web（本） を読め！」というものを1つだけ選んで教えてください。

全貌があるのか否かイマイチ疑問だが、結城のデザパタ入門に一通り
目を通した後でJakarta CommonsのコンポーネントをEclipseUMLへぶ
ち込んでクラス図を出力して眺めて読んで追って舐め回せ。

Jakarta Commonsのソースは超実践的にして超膨大なデザパタのサ
ンプル集だ。

>>383
GoF

>>383
「Eclipseプラグイン開発」 Erich Gamma, Kent Beck
Erich GammaがデザインパターンをEclipseアーキテクチャでどう利用
したか解説してくれる。実際にパターンが現場でどう使われているか
実感できる。ただ全貌がわかるわけではないけど。GoF読んで「ふ〜ん、で、
それで?」とか思ったときに読むといいかも。

ちなみにKent Beckもなんか書いてるけど、
これは蛇足だからどうでもいい。

デザパタって何で賞賛されるんだ?

Templete MethodやFactory Methodのような
抽象クラスの作り方をアマのプログラマでも
やってきたんじゃないか？
煽りみたいな表現になってしまい、ｽﾏﾇ

手法に「名前を付けた」ことがデザパタの最大の功績。
手法自体はやってる人は昔からやっていること。

>>387
……馬鹿じゃないの？マジで。
一体どうしたらそんな発想が出てくるんだ？
デザパタをなんだと思ってるんだ。｢今まで誰も思いつかなかったオリジナリティあふれる設計｣か？

うぇあーお、やべーよ
おれはデザパタを読む前からテムプレートとかやてたーよ
おれってすげーよ

>387
セクハラって何で非難されるんだ?

女の尻触ったりシモネタ言ったり
女性に対するいたずらを一般人でも
やってきたんじゃないか？
煽りみたいな表現になってしまい、ｽﾏﾇ

>>390
貴方がやってきたテムプレートと、私がやってきたテンプレートは大なり小なりの違
いこそあれきっとどこかが違う。
だから、貴方が「ここはテムプレートな」と言い、私が「そうだな」と肯いても、出来上
がってみると思惑がズレてたりする。
そもそも、貴方がテムプレートと呼ぶやり方を、私は別の名で呼んでるかもしれない。
そうすると、前段の会話自体が成立しない事になる。

デザパタが何かを生み出したとしたら、それはcommonaltyなんじゃないかと俺は思う。

>>392
言う相手を間違えてない？
390は明らかに387に対する煽りか、きちがいだろ

>>393
そうか、そうかもな。

それじゃあ、public class 392 implements 390、て事にしとくｗ

暗黙知を形式知に変えることの重要性が分からない者には
何を言っても無駄。

>>390
>>373の17を嫁

>>388
そうですよね。
異様なまでに賛美されてるから
不思議に思ってしまって。

>>389
ひがみ根性ですね
もう少し国語の勉強しようね、僕

>>390
ばかでつね

>>391
ここはとってもつまらない
インターネッツですね

ANSIのC/C++のように規格化すればいいってか、くだらん。
案件にとりかかる前に仕様を統一しとけばｲｲだけだ。

言語の規格さえしっかりしていれば、それで十分。

シンタックス、イデォム、パターン

日経ソフトウエアでデザインパターンの連載が始まっていると聞いたのですが、
今までどんなパターンが解説されてきたのかを教えてください。

質問です。
interpreterパターンを使ってパーサを作っているのですが、
以下のような文法を扱う場合に、どのように構文解析すれば良いか分かりません。
構文<A>を読み込んだ時点では、その構文が<X>と<Y>のどちらに属するのか
分からないからです。
私が勉強した本(結城さんのデザインパターン入門)では、
「インタープリタパターンは、(E)BNF記法に忠実に従うべし」と書いてありましたが、
この場合、BNF記法に従って文法解析を行うことは可能なのでしょうか？

文法を <Root> ::= <A> <B> (<C> | <D>) と置き換えれば一応解析できるのですが、
この場合はBNF記法に忠実には従っていない気がします。

<Root> ::= <X> | <Y>
<X> ::= <A> <B> <C>
<Y> ::= <A> <B> <D>

RootNodeParse()で
SkipTokenを2回つかって、<A> <B> とすすんで、currentTokenで<C>または<D>をとってきて
XNodeParse()かYNodeParse()にとぶか（それともUnsupportでエラーにするか）をきめればいいのでは？

BNF は、文法の定義方法で、構文解析方法じゃないので、
「忠実に従う」といっても、プログラムの駆動が、
定義文をそのままトレースするという意味ではないんでは。

このへんはデザパタじゃなくて言語処理の話だな。

>>402
RootのBNF定義を変形するべしに1票。「BNFに忠実に」という意味は、BNFを変形してはいけないというわけではないと思う。

インタプリタパターンで普通にコードを書くと
最初 ノードXのつもりで解析を始める
A B と順に解析を始める
C の解析に失敗する
Xの解析に失敗したと分かる
Rootの|が発動する
Yの解析が始まる
A B Dと解析が進む

ってなりそうだが なんないの？

BNFに忠実にってのは、「書いた文法定義をそれに対応するコードに
置き換えましょう」という意味であって、
「文法定義に拡張BNFを使ってはいけない」という意味ではないと思う。

>>402
俺、インタプリタパターン書いたとき
そういうBNFもちゃんと処理できたよ。
何で困ったのか教えてクリ

StrategyとかCommandとかそこらへんの「振る舞いをまるごと変更や持ち運び」
っていうパターンって、クロージャひとつあれば解決するよな

>>410
まぁ、クロージャは道具で、デザインパターンは工法だから、
問題なかろう。

ちょっとGoogってみたけど、「クロージャ」ってどうもよく意味がわからん。
「オブジェクト指向でない言語で、
　オブジェクトのように扱えるように作ったコードの集まり」
のような意味しか読み取れないが、それだと、
>>410 の言ってることとちょっとかみ合わない感じだし。

>>412
クロージャという言葉には色々な意味・用途がある。
構文解析が話題となっている時に出てくるクロージャといえば、
多分、"（その時点で考えうる）遷移状態全てからなる閉包"
を指しているんだろうな。

閉包とかいわれてもわけわからん。

ヘイホー、ヘイホー。

レス遅くなってすみません。
みなさんレスありがとうございます。
個人的に、>>407のロジックに興味を覚えました。シンプルですね。
論理式の評価の手順にそっくりです。

そんな>>407に質問なのですが、
「Xの解析に失敗したと分かる」ためには、どうすれば良いのでしょうか。
個人的に以下の案を考えたのですが、

　　1:Xの解析に失敗したことによって生じる例外をキャッチする
　　2:Expression#interpret() の返り値を論理値にして、
　　　解析に成功したら「真」、それ以外は「偽」を返すようにする

1は、別にこの処理はエラー処理ではないので、
例外の利用を前提とするのが大げさだと思います。
2は、既存のソースの大幅な改ざんが必要となる場合があります。

他に何か良い方法はありますでしょうか？

>>407じゃないけどScheme的解決法として、
そのままRootのYの直前の継続を呼び出すというのが簡単なんだけど、
Cとかの手続き型言語に言い換えればただのバックトラッキングということかな。
>>407の意見を聞いてみたいね。

色々説明しようかと思ったけど、面倒くさいので
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/274.zip
こんなコードを書いてみた。勝手に使い回してかまわない。
つか、俺もデザインパターンは結城浩の本で勉強したよ。

SerialNode : BNFの、連続したノード
OrNode : BNFの、or( | )
EndNode : BNFの、末端のノード

これに繰り返しを表現するRepeatNodeや省略可能Nodeを追加すると
BNFのトレースが簡単になる。


解析されたBNF構文木全体にアクセスしたい時はVisitorかなんか、そういうので。

>>415
例外にすべきかエラーリターンにすべきかは俺には解らないが、
俺は、失敗したら、その旨を示す値を返すように設計したよ。
多分それが一番お手軽だと思う。
でも、例外にしても本質的に花にも変わらないと思う。

>>416
こういうの、バックトラックって言うのかな。
なんかよくわかんね。

まあ、俺はこのサンプルコードが俺の期待通りに動いたので、なんかちょっと嬉しい。

このサンプルコードは、
10進数か16進数とマッチするのを表現する、以下のBNFをコードに置き換えたもの。
num = d | h
d = ( "0" / "1" / ... / "9" ) "#"
h = ( "0" / "1" / ... / "9" / "a" / "b" / ... / "f" ) "%"

デザインパターンの前にオートマトンについて学習すべきでは?

オートマトンについて学んでいれば、417のコードは違ったものになっているってこと？
そうじゃなくて、字句解析にはオートマトンを使うべきだってこと？

1234#1234%
は
dに属するの？
dにもhにも属さないと判断するのが正しいのか

そもそもインタープリタパターンって構文解析が目的じゃないでしょ。
解析済みの結果に対してどう処理するかってもんじゃないの？

>>420
A　オートマトンって言ってみたかっただけ

あれ読んで、ためになったとかって奴、プログラマには向いてないよ。

オートマトン……ってか状態遷移は重要だと思うけど

>>423
低脳PGさんには、必要ない知識だな。

・Lex＆Yaccの字句解析＆文法解析
・制御系の開発
・ハードウェアの論理回路設計

なんかには必須だけどｗ

つか、釣り餌も、それに釣られてるのも、程度低いなぁ

ところで、「GoFのデザパタ本は入門書ではない。もっと詳しく知りたい人の本だ」
ってMartinFawlerさんが言ってるのを見つけたんだけど、皆さんはどう思いますか？

俺的には、経験積まないと共有知のありがたみなんて理解しようもないから、
GoF本だろうと結城本だろうと、ある程度進んでからやるべきだと考えてるけど。
(個人的学習経験としてそう思うし、また初心者に結城本教えるという無謀な試み(!)の経験で改めて実感したｗ

リファレンスはこのあたり
Swebok　http://www.martinfowler.com/bliki/Swebok.html

＞今月は IEEE による SWEBOK（ソフトウェアエンジニアリング知識体系） のレビュー月間である。
＞これは、我々の専門分野についての知識体系を定義しようという試みで、ライセンス化へ向けて
＞の土台となるものだ。
（中略）
＞さて、Swebok のどこがダメなのか？
（中略）
＞本の選出はひどくはなかった（GangOfFourを推薦図書にはリストアップしないよう私が警告したのだが）。
＞（GangOfFourはさらに理解を深めたい人用である。初心者用の「参考図書」ではない）

持っているの結城本だけど、初心者が丸暗記しそうなのが一番怖いと思う
そういう意味ではある程度経験積んだ人用の概念かもしんない

結城本はGoFパターンの雰囲気をわかりやすく伝えているのに対し
GoF本は個々のパターンの長所短所を分析しているような印象。

だから、デザパタ/OOP初心者に薦めるんだったら結城本。GoF本は薦めない。
>>426の初心者ってプログラミング初心者だよね？

初心者がGoF本を理解できるのなら、天才と呼んであげよう

>>429
天才と呼んでくれ。初心者だが、GoFの内容がスーッと頭に入ってきた。

>>429は早く天才と呼んであげるように

>>426
その訳文は、某所の超意訳だろｗ 釣られたなｗ

ファウラーは、そのblogにはそんなこと書いてないよ。
http://www.martinfowler.com/bliki/Swebok.html
The choice of books it came up with wasn't awful - although I was alarmed that GangOfFour didn't make it to the recommended list.
(It's in the secondary 'further readings' but not in the primary 'Recommended References' section.)
「(Swebokに)載ってる本の選択はそんなに悪くなかった -- GoF本が推薦リストには載らなかったけど。
　(GoF本は、重要度が高い『お勧め参考文献』の章じゃなくて、重要度が一段低い『もっと詳しく知りたい人のための参考文献』の章にあったｗ)」

GoF本良いけど難解つうてんのはこっちだなｗ
http://www.martinfowler.com/bliki/GangOfFour.html

http://www.martinfowler.com/bliki/GangOfFour.html

＞漏れの汁限り、GoF本はこれまで出たOO設計本の中で最高っす。
＞つか、たぶんどんなタイプの設計の本と比べても、最高！！！
＞ソフトウェア業界にも、無茶苦茶影響与えてるし。まぁJava /.NETのライブラリなんて、
＞GoFが作ったプールの中でパチャパチャ泳いでるようなもんだｗ
＞
＞なーんて褒めてみたけど、決して読み易い本ではない罠。
＞OO設計の基本原則わかって、「OOえぇなぁ〜♥」って感じるようになってから、初めて嫁。
＞そこらへん判ってからじゃないと、この本の真価を読み取るのは無理。つか無理して読んでも無駄。
＞つか、そこらへん判ってからなら、努力して読めば、努力に応じたごりやくの得られる良書っす。
＞
＞コード例はほとんどC＋＋だけど、C++判んないからって焦る必要はなっしんぐ。
＞コード例は、C++の判りにくい機能は使ってないから、C言語さえ理解できりゃ判るようになってるって。

>>428
プログラミング初心者、OO初心者、両方の意味っす。
結城本は、クリープを欠いたネスカフェって漢字。

>>433
それってファウラーの文章を翻訳したもの？
もしそうなら書いてる内容は２ちゃんねらと大してかわらないな。

何か言ってるようで何も言えてない。ていうか、要約すると３行
になるｗ

スゲー(・∀・)ｲｲ!!
でも、読み易くはない(´･ω･｀)ｼｮﾎﾞｰﾝ
コード例はC++だけどCが分かればダイジョウV

いや、ちゃねらー言葉にほんにゃくしただけだってばｗ

もうちょっとまともな訳でファウラー大先生のありがたい御託を読みたい方は、こちらへドゾー（他は多分に意訳が激しいけど、この項目はまとも）
　http://capsctrl.que.jp/kdmsnr/wiki/bliki/?GangOfFour

>>436
まともな翻訳でもやっぱり大したこと言ってない。
凄くいいけど読むには経験が要る。
サンプルはC++だけどCが読めれば大丈夫。
今度は２行で要約できちゃったよｗ

>>437
blogってふつー、そーゆーもんだろ。
もしかしておまいのblogは、受けを狙って書くのかｗ

つか、マーチンの追っかけやってるｱﾌｫもどうかと思うが、
脳みそが２ちゃんでいっぱいいっぱいの>>435-437みたいなのは論外の外だなｗ

つか、ここでレスしてる人って、マジ英語のblog読めないの？

それ、まずいよ。翻訳屋に騙されっぱなしじゃん。技術者としては、能力75%落ちって感じかｗ

遅くなってスマン
>>430
君は天才だ
馬鹿と紙一重だ

>>438
blog＝日記という意識ならそうかもね。
けれども、少しでも書評という意識があったとしたら、この人の
書評には読むべきところがないね。
まぁ、それだけのこと。俺が褒めなくても、他に褒めてくれる信
者を一杯持ってる人なんだから、どうでもいいんじゃね？

いやblogは日記だろ、リンク付きの
そこを否定は変だぞ

誰でも褒められりゃ少しはうれしいだろうけど、
blog ってかならずしも誰かに褒められるために書くわけじゃ無し。

まぁ、ﾌﾞﾛｶﾞｰは120％受け狙いで日記書くわけだがｗ

吉野家コピペとかって、多分最も受けた部類に入るんだろうけど、
書いた人間が狙ってたかどうかは・・・？

奈良のおばちゃんは、受け狙ってたわけではないが、
一部ではかなーり受けてる

ギャラリーを意識していない女の日記はギリギリ存在を許容できるが
ギャラリーを意識していないブログは存在自体が有害。
中身ないくせしてシャクレタ単語だけは入れたがるから、無駄に検索
に引っ掛かる。
読ませる気がないのなら、人目につかない場所でひっそりとやってほ
しいもんだ。

どうでもいいからデザパタについての話をしてほしい。

デザパタおんりーつうのはイマドキつらいもんがあるね。
ドメイン・パターンとか、いろいろ扱うべきテーマがあるでしょ

奈良のオバチャンは扱うべきテーマか？

Eriv Evansが Domain-Driven Design であげてる基本パターンは、
どうなんだろう？

頭が弱い人が見たら、あれ UMLとかOOの基本並べてるだけに見えちゃうんだろうなぁ。

今頃デザインパターン云々いってる奴　＝　今頃たまごっちに夢中になってる奴

バカはすぐ調子にのる

寒

以前、Interpreterパターンについて書き込みした人です。

本を書いた本人に聞いてみました。

>>402 のような場合では、BNFを変形するということで良いそうです。
文法どおりにコーディングすることが重要であって、
文法が変わらなければ、BNFを変形すること自体はオーケーだそうな。

良し悪しではなく、趣味の問題、最適化の問題じゃないか、と。
デザパタの話題とは丸きり関係ないじゃねぇか、と。

・再帰下降/LL文法でバックトラックするか、
・LR文法でトークン先読みして、当てはまるBNF式を選択
すりゃ解決・・・って言語処理系の教科書ネタだよな。

・状態がA、B、Cとあり、それぞれで振る舞いが変わる
・A、B、Cとも共通の変数を「たくさん」扱う
・振る舞いが変わると言っても、影響範囲は一つか二つの関数程度である

こんな時に、分かりやすくするための良い設計が有ったら教えて頂けないでしょうか

今やっているのは、stateパターンにして「たくさん」を一つの構造体にまとめ
各state->func()に引数として渡すやり方ですが、引数のためだけにまとめるのは、どうも妙な気がします。

こんな感じ？
派生クラスのdoProcessで状態別の違いを吸収。

class StateBase {
  int val1, val2, val3, val4;
public:
  virtual doProcess() = 0;
};

class StateA : public StateBase{ public: doProcess(){ 実装}:};
class StateB : public StateBase{ public: doProcess(){ 実装}:};
class StateC : public StateBase{ public: doProcess(){ 実装}: };

StateBaseが持ってる「たくさんの変数」はprotected:で。

あ、ごめん共通の変数ならstaticもつけなきゃだめだ。

>>459
申し訳ないです。そのやり方だと、val1〜val4が
StateA、StateB、StateCでそれぞれ独立して存在してしまい
「共通の変数」では無くなってしまいまして。

val1〜val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

とはいえ例付きでのレス、ありがとうございます。

書いているうちに内容がかぶってしまいました、すいません。

>val1〜val4をStateBaseでstaticにするほどじゃないのが、悩みどころで困っています。

Singletonでしか使えないな。ﾜﾗ

これ俺も良く似た状況に遭うけど難しいよな
クラスでの共通変数じゃなく、インスタンスのまとまり毎に扱いたい共通の変数な
464も言っているが、staticにしちゃうとSingletonでしか使えないし

その共通変数のまとまりを構造体なり、クラスなりにまとめて、
その「変数の塊クラス」のインスタンスを、それが必要なオブジェクトで共有させればいいんじゃないの？

> 引数のためだけにまとめるのは、どうも妙な気がします。

にループ

なんでメンバ変数がstaticだとシングルトン限定になるんだ？
普通に、インスタンスで共有できるんじゃないの？

>>468
Stateのクライアントとなるインスタンスが
2つ以上あるだけで破綻するから

>>466
俺も普通にそうしてる。
共有される変数を一つのオブジェクトとして扱うのは自然な事に
感じるんだが・・・・・・

でもそれって見事に実装の都合から設計しちゃってるよな

contextとかいう名前の変数にして引数で連れ回すか、
全体を統括するなんかクラスをもうけて連れ回さなくて済む
ようにするか。

stateパターンなら「共通の変数」は、
それを保持する為のクラスを作る。

で doProcess() の引数にする。

class Context {
public:
int val1, val2, val3, val4;
StateBase* currentState;
};
class StateBase {
public: virtual void doProcess( Context* ) const = 0;
};
class StateA : public StateBase {
public: void doProcess( Context* ) const;
};
class StateB : public StateBase {
public: void doProcess( Context* ) const;
};

staticなクラスメンバ( 本質的にグローバル変数 )なんて使うと、
「状態を持つもの」が2個3個と増えたときすげーこまる。

あれ？なんか、俺の周りだけ時空が遅れているようだ

stateオブジェクトの構築時にcontextを引数で渡してやれば
stateのメソッド呼び出しの時に渡してやる必要はないね。