5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :1:04/09/17 11:34:59
賢者は歴史に学び、愚者は自分の経験に学ぶ

関連情報は >>2-10


2 :デフォルトの名無しさん:04/09/17 11:35:49
過去スレ
デザインパターンの単純そうな質問 - (1)
http://pc5.2ch.net/test/read.cgi/tech/994836140/
【GOF】デザインパターン - (2)
http://pc5.2ch.net/test/read.cgi/tech/1087050664/

関連スレ
デザインパターン
http://piza.2ch.net/tech/kako/976/976074878.html
「デザインパターンって、○○のようなもんだよ」
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


3 :デフォルトの名無しさん:04/09/17 11:36:23
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)


4 :デフォルトの名無しさん:04/09/17 11:36:50
書籍
増補改訂版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/


5 :デフォルトの名無しさん:04/09/17 12:24:14
書籍一つ加えておきます。
「C#デザインパターン」
http://www.amazon.co.jp/exec/obidos/ASIN/4822281698/


6 :デフォルトの名無しさん:04/09/17 14:14:05
書籍
デザインパターンによる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/


7 :デフォルトの名無しさん:04/09/17 14:25:39
信者ウザイ

8 :デフォルトの名無しさん:04/09/17 14:30:28
デザパタ信者というよりJAVA厨の溜まり場なんだよ(だから低レベルで浮き世離れしてる)

9 :ぱたんまんせ:04/09/17 20:43:03
POSA本とPLoP本もよろしくね!!!

官話九大

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

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

10 :デフォルトの名無しさん:04/09/17 21:03:48
このスレの命題にも言えることだが
>POSA本とPLoP本
無理やりこういう略しかたする必要あるのか?
頭悪すぎ

11 :デフォルトの名無しさん:04/09/17 21:49:07
>官話九大
使い方が間違ってるからわざと違う漢字にしてるのですね。

12 :デフォルトの名無しさん:04/09/17 22:01:40
>>11
そのとおりですが、何か?

13 :デフォルトの名無しさん:04/09/17 22:39:55
何とも言ってませんが?

14 :デフォルトの名無しさん:04/09/17 22:56:45
>>9
すんません。まじで何のことを言っているのかさぱーりです。
わかるよーに説明希望

15 :デフォルトの名無しさん:04/09/18 00:13:10
>>14 かまわないほうが...

16 :デフォルトの名無しさん:04/09/18 12:38:21
痴呆老人がネガティブな粘着をしてるようだな

さっさと市ねよ

17 :デフォルトの名無しさん:04/09/18 19:02:30
関係ないが前スレの976は俺でその後何にも書いてないのに
話が進んでるのはなぜだ…?

18 :デフォルトの名無しさん:04/09/18 19:10:33
>>17
それは俺がレス番号の間違いに最後まで気づかなかったからだ
今気づいた
マジでスマソOTL

19 :デフォルトの名無しさん:04/09/18 20:35:25
>マジでスマソOTL
あ、イヘイヘ、面白かっただけなんで。

20 :デフォルトの名無しさん:04/09/19 05:37:45
デザインパターンを使うと、メソッド1つだけのクラスやら
実質1つのクラスしか使っていないインターフェイスやらが
たくさん増えるんだがこれでいいのでしょうか?
クラスの数ばかりが増えてあまり意味が無いような気がしてしまいます。

21 :デフォルトの名無しさん:04/09/19 06:46:10
>>20 お前デザパタまったく理解出来てない。そういう対策もデザパタに書いてある。ちゃんとデザパタ読んで勉強し直せ。

22 :デフォルトの名無しさん:04/09/19 09:41:58
A「ユダヤ人はどの民族よりも優れています。」
B「その根拠は?」
A「ユダヤ教の教典にそう書かれています。」
B「・・・」

23 :在日参政権反対:04/09/19 11:14:46
>20
デザパタ本に書かれてるかはわすれたが、
そのクラスの役割にメソッドの数は関係ないし、インターフェースの本質は役割の規定だが、たまたまその役割を受け継ぐクラスがひとつだけだったのであって、その役割の規定が正しいのなら問題ない

24 :デフォルトの名無しさん:04/09/19 11:15:50
>>21
そういうのはデザパタ本じゃなくてリファクタリング関係の本じゃないのか?

25 :デフォルトの名無しさん:04/09/19 11:27:16
厨房隔離スレwww

26 :デフォルトの名無しさん:04/09/19 12:03:21
オブジェクト指向と同じで、厨がキモイな

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

27 :デフォルトの名無しさん:04/09/19 13:08:29
>>26
それは無理がある。デザパタを理解しないうちに2chで暴れると、かえって
手負いの傷を負う。叩きのめされるからなw

28 :デフォルトの名無しさん:04/09/19 13:50:12
デザパタは勉強してるけど、
実際にコーディングで役に立つことは少ないかも・・・

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


29 :デフォルトの名無しさん:04/09/19 14:39:20
そうですか。

30 :在日参政権反対:04/09/19 14:47:34
えぇぇぇ使いまくりですが...
そのままじゃないですけど

31 :デフォルトの名無しさん:04/09/19 15:07:01
技術板でコテハンやめろ、ウザくてむしろ賛成したくなってくる
いや、それが狙いか?

32 :デフォルトの名無しさん:04/09/19 16:21:09
同意、しかもつまらんレスばかりだし。

33 :乾燥者:04/09/19 16:47:45
コテハンにします。

34 :デフォルトの名無しさん:04/09/19 19:26:22
>>20
> メソッド1つだけのクラスやら実質1つのクラスしか使っていない
> インターフェイスやらがたくさん増えるんだがこれでいいのでしょうか?

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


35 :デフォルトの名無しさん:04/09/19 19:38:11
>>32
何を期待しているのかと。

36 :デフォルトの名無しさん:04/09/19 21:22:31
GoF の読み方は「ゴフ」

37 :デフォルトの名無しさん:04/09/19 23:26:02
乙一の本は「ゴス」

38 :デフォルトの名無しさん:04/09/20 08:43:15
classloaderもデコレータパターンに近い気がするけどどうだろ。

39 :デフォルトの名無しさん:04/09/20 10:07:09
>>21
おまえ普及させる気あるのかこのやろう。
新参者にはやさしく愛撫しながらスマイルで答えてさしあげろ

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

40 :デフォルトの名無しさん:04/09/20 10:35:11
>>38
振る舞いという意味ではChain of Responsibilityパターンのような気が。
どっちでもいいんだけどね。構造で分類するか振る舞いで分類するかの違いだけで。

41 :デフォルトの名無しさん:04/09/20 11:03:18
たんなる再帰呼び出しと違う?

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

43 :デフォルトの名無しさん:04/09/20 13:11:32
>>42
下らないことにもったい付けてるだけ

44 :デフォルトの名無しさん:04/09/20 13:37:11
ダメだよ、自分が不勉強だって認めなきゃ(クス

45 :デフォルトの名無しさん:04/09/21 07:22:37
>>44 あんたレベル低すぎだよ・・・

46 :デフォルトの名無しさん:04/09/22 00:14:02
ていどひくい

47 :デフォルトの名無しさん:04/09/22 07:47:20
会社で何かいやな事でもあったのかと。

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

49 :デフォルトの名無しさん:04/09/22 09:47:13
Java厨は自分のアプリをすべてデザインパターン化しようと必死だぞ

50 :デフォルトの名無しさん:04/09/22 10:48:49
>>46
すぐにレベルが低いとかそういう事いうやつは
スネオ並って事ですね。

51 :在日外国人参政権反対:04/09/22 11:23:18
>48
そこまでよく出来たフレームがあるとフロントは楽でいいですね

52 :デフォルトの名無しさん:04/09/22 11:47:59
Java厨曰く
せっかく覚えたデザパタに従ってないライブラリは全て糞

53 :デフォルトの名無しさん:04/09/22 13:45:47
デザインパターン通りかどうかが
判断基準の全てなんだよな
JAVA厨って
だから糞な物作って自己満足(以下自主規制

54 :デフォルトの名無しさん:04/09/22 14:47:26
以上、テンプレ終了

腐った餌は放置の方向で

55 :在日外国人参政権反対:04/09/22 14:50:08
せっかく新スレになったんだから、Java厨批判で無駄に汚すの止めてくれ

56 :デフォルトの名無しさん:04/09/22 16:27:34
てかJava厨消えてくれ

57 :デフォルトの名無しさん:04/09/22 17:46:03
コテハンも一緒に消えてくれ

58 :デフォルトの名無しさん:04/09/22 17:51:33
せめてデザパタの話をしれ

59 :デフォルトの名無しさん:04/09/22 20:29:34
>>48
そこでサクッと
フレームワークを
ageれば
みんな
納得するんだけど

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

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

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

61 :デフォルトの名無しさん:04/09/22 23:14:01
>Singleton パターンを用いるシーンが思いつきません。

無いから。

62 :デフォルトの名無しさん:04/09/22 23:19:30
俺は FlyWeight を兼ねて1つのクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった

63 :デフォルトの名無しさん:04/09/22 23:28:16
俺はログ出力用のクラスを Singleton にしたことがある
あまり意味のあることだとは思えなかったが、とりあえずやってみて結局意味無かった
今は反省している。

64 :デフォルトの名無しさん:04/09/22 23:29:59
ここでJava厨のデザパタ鵜呑み発言↓

65 :在日外国人参政権反対:04/09/22 23:30:51
サブシステムとしてグローバル的に使うものに多用してまふ
スレッドマネージャーとかそういう奴

66 :デフォルトの名無しさん:04/09/22 23:40:55
さすがJava厨のデザパタ鵜呑み発言↑

67 :63=66:04/09/22 23:43:51
つーか、そろそろデザパタの話をしようぜ
もうこのスレじゃ無理っぽいけど。

68 :在日外国人参政権反対:04/09/22 23:50:02
>66
ではそういうときにジャバ厨でない人のやり方をどうぞ


69 :デフォルトの名無しさん:04/09/22 23:50:44
1. Singletonのインスタンスを2つ以上に変更できる
2. Singletonのインスタンスの振る舞いを、継承により変更できる

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

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

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

70 :デフォルトの名無しさん:04/09/22 23:52:48
いま開発中の会社のアプリは大半のクラスがSingletonになってる。
デザパタは分かりやすくていい。

71 :デフォルトの名無しさん:04/09/22 23:56:21
>>70
ご愁傷様です。これだからSingletonパターンは危険なんだ。

72 :デフォルトの名無しさん:04/09/23 00:06:15
>>71
いや、プロトタイプベースな言語ならば問題ない……と言ってみる

73 :デフォルトの名無しさん:04/09/23 00:07:32
>>69
>1. Singletonのインスタンスを2つ以上に変更できる
>2. Singletonのインスタンスの振る舞いを、継承により変更できる
3.どこからでも参照できる。

一番の利点だね。

74 :デフォルトの名無しさん:04/09/23 00:10:23
>>73
staticメソッドもどこからでも参照できますが。

75 :デフォルトの名無しさん:04/09/23 00:13:45
それじゃ、
staticメソッドを使わず、あえてSingletonを使う意義というものを
まじめに議論して見ましょう。

FIGHT! ⊂(゚(エ)゚)⊃

76 :デフォルトの名無しさん:04/09/23 00:14:42
コーディングしている全てのクラスがFacadeパターンと言えないか?

77 :デフォルトの名無しさん:04/09/23 00:18:56
>>75
例えば ClassA を Singleton にしても ClassA のオブジェクトとしてつかえることに変わりは無い
Singleton な ClassA をある日突然 Singleton じゃなくしても何も問題は起きない

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

78 :77:04/09/23 00:21:27
>>77 の下部
別に俺はデザパタヽ(´ー`)ノバンザーイじゃないとは言っておく
ただし、ごちゃごちゃしたクラスの塊は扱いたくない

79 :63=66=67:04/09/23 00:31:03
>>68
ごめんなさい。
ちょっと矢印ではさんでみたかっただけなんです。
悪気はなかったんです。
ごめんなさい。

80 :60:04/09/23 00:31:47
思ったより反応があったので喜んでいるのですが、ふと疑問に感じたことがあります。

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

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

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

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

82 :デフォルトの名無しさん:04/09/23 00:58:31
>>60
>クラス変数をプロパティとして持ち、そのアクセサ・メソッドを持つクラスで、
>事足りるのでは?と思ったのですが、どうなのでしょうか?

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


83 :デフォルトの名無しさん:04/09/23 01:00:29
>>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だったわけで。

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

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

85 :デフォルトの名無しさん:04/09/23 01:14:16
ぶっちゃけ Java案件って保守性低いよね。
個人の趣味が出すぎる

86 :デフォルトの名無しさん:04/09/23 01:15:17
フレームワークをつかえ

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

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

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

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

88 :デフォルトの名無しさん:04/09/23 01:22:46
フレームワーク使っててもなんだかんだで自己満足な美意識を存分に発揮して
おかしなコードを書くやつが出てくる。


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


89 :デフォルトの名無しさん:04/09/23 01:30:18
ぐぐって引っかかった奴
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

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


90 :デフォルトの名無しさん:04/09/23 01:31:15
好きにすればいいと思うよ

91 :デフォルトの名無しさん:04/09/23 01:42:09
設定ファイルはSingletonの用途の成功例だろうと思うが

92 :デフォルトの名無しさん:04/09/23 02:13:28
百済ねー

93 :デフォルトの名無しさん:04/09/23 07:05:49
デザパタつかってりゃ、みんな成功例なんだろ
JAVAのライブラリの〜は、〜パターンの成功例だしな( ^∀^)ゲラ

94 :デフォルトの名無しさん:04/09/23 07:38:54
なんか、

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

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






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

95 :デフォルトの名無しさん:04/09/23 07:54:23
馬鹿はニヤニヤしながら放置
自演始めてもぐっとこらえて放置

96 :デフォルトの名無しさん:04/09/23 08:29:18
> Javaな人はGoFスレ出入り禁止にしよう!
そうでもしないと
いつまでたっても建設的な話にならない悪寒

97 :デフォルトの名無しさん:04/09/23 08:30:07
>ぐっとこらえて放置
つまり貴方はJAVA厨ってことですね?

98 :デフォルトの名無しさん:04/09/23 10:20:06
>>85
>>88
>>92
>>93
>>97
.dispose

99 :デフォルトの名無しさん:04/09/23 10:37:05
>>93
「デザパタつかってりゃ、みんな成功例なんだろ」

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

なんてね。

100 :デフォルトの名無しさん:04/09/23 12:31:17
>>99 日本語勉強してから出直してこい

101 :デフォルトの名無しさん:04/09/23 16:22:47
>>60
DBCP

102 :デフォルトの名無しさん:04/09/23 21:52:29
ジブロモクロロプロパン・・・じゃないな
データーベースコネクションプール?

103 :デフォルトの名無しさん:04/09/24 01:05:28
ドラゴンボール厨房パワー

104 :デフォルトの名無しさん:04/09/24 07:41:57
>>10をもう一度読むこと

105 :デフォルトの名無しさん:04/09/24 13:41:05
必死で覚えたデザパタを
使うことが目的なんだから
使ってあれば成功例なのは当然

106 :デフォルトの名無しさん:04/09/29 15:41:14
Singletonの利点は、あくまでそれが生成のみに関るってことだと思う。
例えば基本クラスXと派生クラスXA・XBがあって、XAとXBのインスタンスを
それぞれひとつに制限したいとする。
でも、Monostateでは共通部分(特にクラス変数)をXに書くわけにはいかないよね?
(C++ならtemplate等で実装共有するって手もあるだろうけど)
Singletonは生成方法を制限しているだけで、XAとXBは独立したインスタンスだから
そういう問題は出ない。

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

107 :デフォルトの名無しさん:04/09/29 17:32:47
>>106
正解

108 :デフォルトの名無しさん:04/09/30 03:16:22
またJava厨の自演かよ

109 :デフォルトの名無しさん:04/09/30 10:52:49
>>108
正解


110 :107:04/09/30 12:53:09
>>108
不正解
106 と 107 は別人だ

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

111 :デフォルトの名無しさん:04/09/30 13:01:43
まだいってるよ
誰が見ても >>106 = >>107 = >>110 だよな
あんな見当はずれなレスに
正解とかいう奴本人しかいないって(稾

112 :106:04/09/30 13:18:25
>>111
見当はずれだったか? すまん。

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

113 :デフォルトの名無しさん:04/09/30 13:38:23
放置

114 :107:04/09/30 15:25:12
>>111
ま、真相は俺と 106 氏のみが知っているということでFA
おまえら、別に俺が 106 氏と同一人物じゃなくても構わないんだろ?
ならどっちだっていいじゃねーか


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


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

115 :デフォルトの名無しさん:04/09/30 16:23:32
>>108 = >>109 = >>111みたいな馬鹿へ丁寧にレスしなくていいよ。
荒れるだけだから。

116 :デフォルトの名無しさん:04/09/30 19:19:42
これがJava厨って生き物ですか(;´Д`)

117 :デフォルトの名無しさん:04/10/01 01:15:47
さわるなよ〜

118 :デフォルトの名無しさん:04/10/01 07:49:00
このスレには「Java厨」は居ないが「Java厨かよ」と書き込んで話題を止めるヤツが常駐しているな。

119 :デフォルトの名無しさん:04/10/01 22:29:05
>>118
正解

120 :デフォルトの名無しさん:04/10/01 23:32:53
またJava厨の自演かよ

121 :デフォルトの名無しさん:04/10/02 00:07:42
ageで書いてるあたり120は本物の池沼くさいなw

122 :デフォルトの名無しさん:04/10/02 00:11:44
>>120
正解

123 :在日外国人参政権反対:04/10/02 00:35:37
Java中とか言ってる奴







  馬鹿じゃねーの

124 :デフォルトの名無しさん:04/10/02 06:03:54
Java厨氏んで

125 :デフォルトの名無しさん:04/10/02 07:31:56
>>123
荒らしは死ね
Rbuy1!!!!!!!!!!!!11Rbuysaikyou !!!!!!!!!!
Rubysaikougengo !!!!!!
Rubuyantoapojnte4p222222222222
Ruby!!!!!!!!!!

126 :デフォルトの名無しさん:04/10/02 10:00:39
もっともデザインパターンに向いている言語はマクロアセンブラ

127 :デフォルトの名無しさん:04/10/02 16:21:10
もっともデザインパターンに向いている言語はひまわり

128 :デフォルトの名無しさん:04/10/02 16:21:50
もっともデザインパターンに向いてる言語はHSP!!!

129 :デフォルトの名無しさん:04/10/02 16:31:09
いいかげんJava厨キエロ

130 :デフォルトの名無しさん:04/10/02 17:05:38
C#の言語仕様はJavaの言語仕様を全て含んでいるので
Javaでできることは全てC#でそのままできる。
それなのに何故
「デザインパターンに最も適した言語はJavaだ」
という言説が生まれるのか?
よく分からんな・・・
言語仕様がシンプルだからいい、とでも言うのか???


131 :デフォルトの名無しさん:04/10/02 18:28:42
>>130
本がいっぱい出てるから。

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

132 :デフォルトの名無しさん:04/10/02 20:33:46
>>130
どの発言に対するレス?

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

133 :デフォルトの名無しさん:04/10/02 21:18:45
デザインパターンに最も適した言語はRuby!

134 :デフォルトの名無しさん:04/10/02 22:46:54
>>132
脳内のヒト。

135 :デフォルトの名無しさん:04/10/03 11:57:15
>>130
(´∇`)ケラケラ
C# に Java のような匿名クラスなんて無いよ
Java に C# のようなデリゲートなんて無いよ
C# と Java の内部クラスの挙動は激しく違うよ

136 :デフォルトの名無しさん:04/10/03 13:18:18
というか>>130は「デザインパターンに最も適した言語はJavaだ」 という言説をどこで読んだんだ?
このスレで話題に上がっていないことを、突然語られても困るんだが。

137 :130:04/10/03 16:23:11
>135
匿名クラスも内部クラスもデザインパターンで使わないだろ?
そんな瑣末な例を挙げるなよ。


138 :デフォルトの名無しさん:04/10/03 16:33:09
宗教戦争はもうたくさんだ

139 :デフォルトの名無しさん:04/10/03 16:35:35
>>138
C ++字軍に参加しませんか

140 :135:04/10/03 16:36:09
>>137
130 の上から2行に突っ込んだだけだが……
デザパタとは関係ない部分であるにしろ、間違った認識を持つのはマズいぞ?

141 :デフォルトの名無しさん:04/10/03 16:38:04
>>136
このスレはこのパターンの繰り返し。


142 :デフォルトの名無しさん:04/10/03 16:39:20
>>136

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

143 :.Net陣営:04/10/03 21:20:48
>>138
では戦争を終わらせる為の戦争に参加したまえ。
我々は全てを飲み込む。


144 :デフォルトの名無しさん:04/10/03 21:22:31
ブビ廚なんぞハナっから相手ではないわ

145 :デフォルトの名無しさん:04/10/04 00:13:40
デザインパターンくらい知ってることが基本の職場に転職した。
意思疎通が格段に違う。
設計やビジネスプロセスの検討においても、「いわゆるCompositeで」とか平気で使えるし。

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

146 :デフォルトの名無しさん:04/10/04 00:29:17
そらよかったね。

147 :デフォルトの名無しさん:04/10/04 01:56:28
そういうとこは開発プロセスも
アジャイルとかいう奴なんでしょうか。

148 :デフォルトの名無しさん:04/10/04 02:01:42
>>145
どこの会社か教えてくれ。

149 :デフォルトの名無しさん:04/10/04 02:12:45
>>148
それは言えない。でも実在する会社だよ。嘘じゃないよ。

150 :デフォルトの名無しさん:04/10/04 03:05:31
色んな所に疑問を投げかけてマルチっぽくて
恐縮なんだけど、誰も明確にレスつけてくれないんで
145にききたいんですが。

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

151 :145:04/10/04 03:20:35
>>150
見積もりは、最終的なかたちは人月計算にしてる。
ただ、見積もりの再計算の機会を何回か設けている。

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

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

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


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

# >>149は自分じゃない


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

153 :デフォルトの名無しさん:04/10/04 05:58:32
いいかげん自作自演やめて出て逝けよ

154 :デフォルトの名無しさん:04/10/04 07:21:25
お前がなー

155 :150:04/10/04 23:18:46
>151
わー初めて現場の声がきけたうれしー。ありがとう。
ありがとうついでにもちょっと。

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

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

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

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

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

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

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

156 :デフォルトの名無しさん:04/10/05 02:04:38
いいかげん自作自演やめて出て逝けよ

157 :在日外国人参政権反対:04/10/05 02:15:19
理解できず煽ることしか出来ない人のいるスレはここですか?

158 :デフォルトの名無しさん:04/10/05 02:16:57
civ3スレ荒らした馬鹿はお前かね?

159 :150:04/10/05 02:24:47
いいレスつけてもらって感謝すると
大概ジサクジエン。
まあ風物詩ですからそれもまた一興。

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

160 :在日外国人参政権反対:04/10/05 02:31:19
>158
自分に対してのレスですか? civ3が何のことかわかりませんが.

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

161 :デフォルトの名無しさん:04/10/05 09:30:47
どっちかって言うとこっちのスレのほうが適切
ttp://pc5.2ch.net/test/read.cgi/tech/1091773629

162 :デフォルトの名無しさん:04/10/05 16:38:43
指定厨とクソコテがいる限りこのスレは駄目だろ

163 :デフォルトの名無しさん:04/10/06 03:58:44
Java厨ってほんと見苦しいね
頼むから氏んで(・∀・)

164 :デフォルトの名無しさん:04/10/07 13:20:23
なんか、脳内世界の発表会みたいなスレになってるね。

165 :デフォルトの名無しさん:04/10/08 07:52:49
>>164
そうそう。会話になってないよな。

166 :デフォルトの名無しさん:04/10/09 22:43:40
目を覆いたくなるような恥ずかしい自作自演だ
自分だったら首釣って氏んでるな

167 :デフォルトの名無しさん:04/10/10 21:33:14
>>166
だからさぁ、誰に言ってんの?
脳内世界の語り手って言われちまうぞ

168 :デフォルトの名無しさん:04/10/11 11:03:02
脳内世界の語り手登場

169 :デフォルトの名無しさん:04/10/11 14:52:04
VB.NETでもC#.NETでもいいけど、MS系でデザインパターンしてるやついる?


170 :デフォルトの名無しさん:04/10/11 15:52:09
MFCで 。・゚・(ノД‘)・゚・。

171 :デフォルトの名無しさん:04/10/12 00:35:44
>>169
やってるよ


172 :デフォルトの名無しさん:04/10/12 08:21:11
SDKで。

173 :デフォルトの名無しさん:04/10/12 16:11:36
> わー初めて現場の声がきけたうれしー。ありがとう。
ワラタ

174 :169:04/10/12 21:21:38
>>170
>>171
>>172
MFCとかSDKとかそういうんじゃなくてさ、 業務でよ。

175 :デフォルトの名無しさん:04/10/12 21:53:30
業務でSDKだよ。
MSだろうがなんだろうが
関係ないだろ。

176 :デフォルトの名無しさん:04/10/12 23:27:01
>>169
>>174
「デザインパターンしてる」って何よ。

177 :デフォルトの名無しさん:04/10/12 23:28:02
デザパタってる。

178 :デフォルトの名無しさん:04/10/13 00:38:49
>174
それらのレスみたらMFCベースの開発でとか、SDKベースの開発でという意味でしょう.
そもそも、言語ならともかく、MS系でというのが何を指すのかよくわからんです...

179 :デフォルトの名無しさん:04/10/13 07:11:54
モビルスーツか?

180 :デフォルトの名無しさん:04/10/13 22:48:54
>>178
つまり実務でC#使っているやつは、デザインパターンを知らないどころか、自分でクラス作れるやついないってことだな

181 :デフォルトの名無しさん:04/10/13 22:55:29
>>180
流石に C# でクラスを作れない奴は居ないだろう。
この場合引き合いに出されるのは 『クラスを使えるか』 もしくは 『クラスに使われるか』 だ。

182 :デフォルトの名無しさん:04/10/14 00:05:51
実務でC#使っているが、俺のプロジェクト誰一人としてまともなクラス作れてない
C++/Java上がりの連中なんだがな、どうしたものか。

183 :デフォルトの名無しさん:04/10/14 00:24:32
まともなクラスの定義はなんだよ。
C++/Java上がりの連中はCLRのクラス構成を熟知しているわけじゃないんだから
いきなり投げ込まれても正しく分析なんてできないだろ。

184 :デフォルトの名無しさん:04/10/14 00:35:03
>>183
逆でしょ、CLRだなんだっての知ってても
それは実装レベルの話じゃん。

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

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

185 :デフォルトの名無しさん:04/10/14 00:35:32
>>182
まず他人と会話してみるのがいいと思うよ

186 :デフォルトの名無しさん:04/10/14 01:07:37
>182
俺のプロジェクトが一人プロジェクトだったら面白い

187 :デフォルトの名無しさん:04/10/14 01:10:08
デザインパターンしてる。
デザパタってる。
デザってる。
パタってる。
ザパってる。
タってる。

>>182
どれがいい?

188 :デフォルトの名無しさん:04/10/14 01:36:48
デンパってる、がいい。

189 :デフォルトの名無しさん:04/10/14 11:30:00
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


190 :デフォルトの名無しさん:04/10/14 12:51:17
お気に入りの新着をすべて開くの動作が変わった?
新着あるものすべて開くんだけど、新茶区分を取得しに行かない.

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

191 :デフォルトの名無しさん:04/10/14 12:51:37
誤爆スマン

192 :デフォルトの名無しさん:04/10/14 16:15:49
>>189
宣伝乙

193 :デフォルトの名無しさん:04/10/16 22:43:04
安定したインタフェースを抽出できなくて困っている。
俺の頭が悪いのか? ・゚・(ノД‘)・゚・。

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

194 :デフォルトの名無しさん:04/10/16 23:28:18
>>193
最後の行に書いてるようなことを気にしすぎてはいけない。

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

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

195 :デフォルトの名無しさん:04/10/17 02:03:59
>>それに応じたソリューションがあるということ。

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

196 :デフォルトの名無しさん:04/10/17 02:12:07
何も言ってないのと同じだよな。
断言すると叩かれる、だから曖昧にしておく。

197 :デフォルトの名無しさん:04/10/17 10:23:41
ソリューションドメインの分析をしなきゃいけないようだけど
>>193の環境がわからないことには始まらない。C++だというなら
当てはまるのかも試練が。


198 :デフォルトの名無しさん:04/10/17 11:10:01
俺も、マルチパラダイムデザインは白眉だと思う。

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

199 :193:04/10/17 15:44:43
マルチパラダイムデザインですかー
本自体は聞いたことあるけど読んでみることにします。

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

200 :デフォルトの名無しさん:04/10/17 16:33:44
現実の問題領域がシングルパラダイムでは表現できないなんて当然だよな。

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

201 :デフォルトの名無しさん:04/10/17 23:23:53
マルチパラダイムデザイン・・・

売ってない ・゚・(ノД‘)・゚・。

202 :デフォルトの名無しさん:04/10/18 02:01:50
そこでマルチパラダイムして別の本を買え!

203 :デフォルトの名無しさん:04/10/20 17:02:47
>>200
俺は据えても構わないと思うんだけど
周りを残しておけば

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

204 :200:04/10/20 23:33:13
>>203
> 俺は据えても構わないと思うんだけど
> 周りを残しておけば

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

205 :203:04/10/23 10:31:11
>>204
切らんよw

206 :デフォルトの名無しさん:04/10/24 19:40:50
マルチパラダイム届いた。ざっと目を通してみたけど、
設計手法をパターン化し、『一歩離れたところから見て』まとめた
モノとして考えていいの?なにやらごちゃごちゃ書いてあるけど

207 :デフォルトの名無しさん:04/10/25 22:38:41
読み終わったか?

208 :206:04/10/26 18:15:35
読み終わった
理解にはもう少し時間かかると思う

209 :デフォルトの名無しさん:04/10/26 22:32:24
すごいじゃないか!こんな短時間で読み終わるだなんて!!






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

210 :デフォルトの名無しさん:04/10/26 23:09:17
マルチパラダイムに対する
『シングル』の方はどんなパラダイムなわけ?

211 :デフォルトの名無しさん:04/10/26 23:21:24
独身パラダイム

212 :デフォルトの名無しさん:04/10/26 23:27:12
マジレスまたは真面目な付き合いを望む

213 :206:04/10/27 15:36:49
>>209
無理だ。内容が濃すぎて頭の端から抜けていく^-^;

214 :206:04/10/27 16:17:35
>>212
とりあえず、全然理解できていない身で悪いが、

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

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

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

215 :デフォルトの名無しさん:04/10/28 00:26:44
逆に自然体だよなあ

△△を中心に据えよ!

...って気張るよりも

216 :デフォルトの名無しさん:04/11/02 22:57:31
117ページ

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

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

217 :デフォルトの名無しさん:04/11/03 00:55:04
ポリモーフィズムうまく使えるようにモデリングできるかということはないのか?
ポリモーフィズム使えるということは汎化がうまくいって、共通の枠組みに押し込めてるということだから。

218 :デフォルトの名無しさん:04/11/03 09:14:42
ポリモと言えばp114とp137にあるように広く見てるね

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

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

219 :デフォルトの名無しさん:04/11/03 11:32:19
それは広すぎるんでは?

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


220 :デフォルトの名無しさん:04/11/03 11:53:28
ポリモーフィズムといえば4のようなことを言うんだと思ってた
頭固いかな

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

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

222 :デフォルトの名無しさん:04/11/03 19:24:39
RMIで扱うスタブを末端のオブジェクトに渡すのってあまりよくないですよね?
皆さんだったらどうしますか?
僕はADAPTERパターンがいいのかな?と感じました。


223 :デフォルトの名無しさん:04/11/03 19:30:45
Gammaです・・・

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

・・・Gammaです

224 :デフォルトの名無しさん:04/11/03 19:45:20
>>223
Erich Gammaの事かな?
まだ皆さんの意見を聞きたいですが、早速実装してみます。

225 :デフォルトの名無しさん:04/11/03 20:05:57
Gammaです・・・

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

・・・Gammaです

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

227 :223:04/11/03 21:30:28
>>224
偽Gammaに負けずにがんがれ!


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

229 :デフォルトの名無しさん:04/11/03 23:38:30
>228

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

230 :デフォルトの名無しさん:04/11/06 12:13:21
State パターン使う場面を見出せなかったが、ゲームの状態遷移に思いっきり使えると気づいた今日この頃
気づくの遅いなぁ orz

231 :デフォルトの名無しさん:04/11/06 13:39:10
Stateパターンはものすごく参考になった。
switch文はほとんど出番なしなヨカーソ

232 :デフォルトの名無しさん:04/11/06 13:52:02
>229
何このスレ・・・
ねた?

233 :223:04/11/06 16:58:18
State と Strategy の違いってどんなんだっけ?

234 :230:04/11/06 17:02:21
>>233
どちらも委譲で挙動をごっそり替える点では同じ

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

235 :223:04/11/07 00:50:13
ありがとう
でも、目的が異なるって説明はいろんなところで
見た覚えがある(State vs. Strategy に限らず)けど
それだけじゃ異なるパターンとして別にする程のこと?
って思いが残る...

236 :デフォルトの名無しさん:04/11/07 16:02:22
>>235
デザインパターンが主とするオブジェクトパラダイムだと、
現実世界と如何に対応させるかが1つの焦点となるから、
ある意味でこれは自然な事だと思うけど……

237 :デフォルトの名無しさん:04/11/09 22:16:40
目的が異なるってことだけなら、クラス図は多少違うけど
CommandとStrategyも似ているよね。
違いはサブクラスの許容量の違いだと認識しているんだけど
Strategy・・・何かしらの共通目的をもつ
Command・・・何でも良い。
違う?

238 :デフォルトの名無しさん:04/11/10 16:34:08
とりあえず例の本を読み切った
『可変性』って言葉は、「仕様の変更に対処するための柔軟性」って読みかえてもいいものだろうか……



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

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

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

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

239 :デフォルトの名無しさん:04/11/10 16:49:38
構文木みたいのも一種のChain of Responibilityじゃないかな。
それなら何度も使ってる。


240 :デフォルトの名無しさん:04/11/10 17:28:04
>>238
イメージ/オーディオ/ビデオのフィルタみたいなのもCoRじゃないのかな?
同型インターフェイスを持つオブジェクトを自由に接続して連鎖的に処理させるやつ。

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

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

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

242 :デフォルトの名無しさん:04/11/16 22:32:32
もうGoF本から外した方がいいパターンはないかね?

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

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

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

243 :U ◆CZtFsGiu0c :04/11/17 12:36:52
>>242
Bridgeは特定の言語以外では有効な使い道がないからじゃないですかね。
JavaやSmalltalkでBridgeの使い道ってありますか?

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

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

245 :デフォルトの名無しさん:04/11/22 15:18:24


246 :在日外国人参政権反対:04/11/22 17:28:30
なんかいろんなスレで本文のない書き込みがあるんだが、誰かなんか作って変なテストしてるのか?

247 :デフォルトの名無しさん:04/11/22 21:15:41
>246
クソスレ見すぎ

248 :デフォルトの名無しさん:04/11/22 22:11:44
クソコテがクソスレをつくる

249 :在日外国人参政権反対:04/11/22 22:26:25
またチ(ry

250 :デフォルトの名無しさん:04/11/23 00:07:53
糞スレを作るのは、コテハンをみると決まって過剰反応する厨房名無しだろ。

251 :デフォルトの名無しさん:04/11/23 01:47:35
臆病者が伏せ字を使っていい気になってるスレはここですか?

252 :デフォルトの名無しさん:04/11/23 08:30:11
>>250
同意
俺の場合246は透明あぼ〜んされている
これお薦め

253 :デフォルトの名無しさん:04/11/24 16:40:05
>>244
ところでマジネタなんだが、パターンってつまり『クラス間の関係を表す』ものだと俺は認識してるから、
>「そんなのパターンと呼ばなくても普通に使うだろ」
ってすごく変な感じがする。

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

254 :デフォルトの名無しさん:04/11/25 00:00:07
『アンケート』
実際に使ったことのあるデザインパターン
さぁどぞ

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

255 :デフォルトの名無しさん:04/11/25 00:09:35
visitor

256 :デフォルトの名無しさん:04/11/25 00:09:50
し、しんぐるとん… にゃんにゃん

257 :デフォルトの名無しさん:04/11/25 00:23:20
State

258 :デフォルトの名無しさん:04/11/25 00:59:54
composit, iterate, visitor, builder, facade

259 :デフォルトの名無しさん:04/11/25 04:33:03
Product Trader パターンについて詳しく書かれているサイト or 本ってないですか?

260 :デフォルトの名無しさん:04/11/25 04:45:39
Singleton,Observer,state,Strategy,facade,Composite,Command,

261 :デフォルトの名無しさん:04/11/25 21:46:21
Singleton, Mediator, Strategy, Composition, Visitor

262 :デフォルトの名無しさん:04/11/25 22:01:50
卑怯な手段としての
Mediator

263 :デフォルトの名無しさん:04/11/25 23:35:24
どんな場面で使ったとかコメントもあるとおもしろいかも
300取ったやつカウントよろしく
じゃ続き

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

264 :デフォルトの名無しさん:04/11/26 22:49:36
Mediatorっていうか今思うとFunctorだな。
Mediatorの抽象ベースクラスがあって、派生クラスはテンプレート。
Boostのファンクタみたいな感じ。
5年以上前にしちゃイケてたかな。。。

265 :デフォルトの名無しさん:04/11/29 21:17:07
GoF 以外でどんなパターン使ってる?

266 :デフォルトの名無しさん:04/11/30 05:19:42
アンチパターン

267 :デフォルトの名無しさん:04/11/30 20:55:09
IoCってGoF?

268 :デフォルトの名無しさん:04/12/01 11:17:23
表面上ファクトリー使うから関係はあるけど
パターン自体は入ってない、よな。

269 :デフォルトの名無しさん:04/12/01 20:16:19
ぬるぽパターン

270 :デフォルトの名無しさん:04/12/01 23:12:28
DIって、spring出るまで知らなかったけど
割と最近の手法なのかな。

271 :デフォルトの名無しさん:04/12/01 23:34:44
>>269
ガッ パターン

272 :デフォルトの名無しさん:04/12/02 01:18:41
ttp://patterns-wg.fuka.info.waseda.ac.jp/study/8th.html
最近ググって見つけたんだけど、ひがやすを氏の説明がわかりやすかった

273 :デフォルトの名無しさん:04/12/02 10:15:38
Mediatorパターンと、Observerパターンの違いがよくわからないのですが、俺なりには、
同僚にイベントを通知されるのがMediatorパターン
非同僚にイベントを通知するのがObserverパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

274 :デフォルトの名無しさん:04/12/02 15:07:24
>>273
解からないなら解かるようになるまで教典を読みましょう。

275 :デフォルトの名無しさん:04/12/02 18:53:28
>>273
Mediatorは通知先を個体識別している。
Observerはしていない。
Mediatorは、なんかのイベント発生時に、どの通知先に何をすべきか知っている。
Obserberは、しらない。イベントが発生したことを知らせるだけ。通知を受けて何をするかは、Observable が決める。

276 :デフォルトの名無しさん:04/12/04 20:40:14
>>273
ObserverとMediatorの比較ということなら,
Observerを適用した場合 通知相手のオブジェクトに関する情報が
各オブジェクトに分散して管理が難しくなることがある
Mediatorの場合はMediator役が通知の交通整理を一手に引き受けるので
Observerを適用した場合に比べ管理は簡単になる(が,クラス間の結合が若干強くなる)

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

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

277 :デフォルトの名無しさん:04/12/05 11:33:29
>>270
昔から「コールバック」という名前で知られていたのでは

278 :デフォルトの名無しさん:04/12/05 22:24:32
>>277
コールバックとは違うようなが気がしないでもないが
勉強不足なのでよくわからない だれか解説キボンヌ

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

279 :253:04/12/05 22:31:40
>>278
『ノウハウ』というのは格好付け過ぎかと

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

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

280 :デフォルトの名無しさん:04/12/07 10:34:14
Strategyパターンと、Observerパターンと、Stateパターンの違いがよくわからないのですが、俺なりには、
入れ替える中身が戦略だとStrategyパターン
入れ替える中身が観察者だとObserverパターン
入れ替える中身が状態だとStateパターン
と解釈したのですが、他の方はどのような解釈をしているのでしょうか。

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

282 :デフォルトの名無しさん:04/12/07 13:08:23
>>279
278は,デザパタも含む,もっと広い意味でのパターンを
思い浮かべながら書いてた
デザパタスレだということをすっかり忘れてたorz すまぬ

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

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

283 :デフォルトの名無しさん:04/12/07 14:05:31
>>280
形は似ているからね。特に Strategy と State は。
形が似ていても目的が違うときには、違う名前をつけるのが、
デザイン・パターン流みたいだね。>>281はそのことを言っている。

284 :デフォルトの名無しさん:04/12/07 14:07:29
クラス図同じだしな

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

 会 社 は 評 価 し て く れ な い


286 :デフォルトの名無しさん:04/12/22 16:19:51
デザパタってコーディング技術じゃなくて設計技術だろ

287 :デフォルトの名無しさん:04/12/22 17:24:46
そうすると「コーディング技術」とはなんだろう・・・。
キーボードを早く打てるぜ俺は、とかに
なっちゃうんだろうか・・・。

288 :デフォルトの名無しさん:04/12/22 17:53:26
イディオムとかそういう類じゃないかな。
ファイルアクセス時のtry〜catchはこう書け、とか、文字列のNULLチェックはこうしろ、とか。

289 :デフォルトの名無しさん:04/12/22 18:16:00
なるほど。言語依存な所な訳ね。

290 :デフォルトの名無しさん:04/12/22 18:25:14
いや、そんなに言語依存でもないか。
リソースはちゃんと解放しようぜ、とかそういう話か。

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

291 :デフォルトの名無しさん:04/12/22 18:41:31
>>290
俺は『クラス関係のデザイン』やとおもとった
……っていうか設計と同じ意味か

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

292 :デフォルトの名無しさん:04/12/22 18:56:37
>291
そうそう、日本語カタカナでデザインていうと、
クリエーチブな業界のイメージだろうから
285みたいな意見が出るのだろうか。
考えすぎか。

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

293 :デフォルトの名無しさん:04/12/22 22:32:37
285は、「なるべく簡単にちゃんと動く」こととデザパタを相反する概念と考えているみたいだけど、なんでだろ
。デザパタは、「なるべく簡単にちゃんと動く」ための工夫に他ならないのに。惜しいね。

294 :デフォルトの名無しさん:04/12/23 18:19:19
>>285
自分が楽をするために学んでるだけだからね。
会社の評価なんてどうでもいいよ。
会社の評価のためにやってるんだったら無駄だから勉強しないほうがいいよ。

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

295 :デフォルトの名無しさん:04/12/23 18:51:35
>>294
御前はクラス間設計をコーティング時にやってるのか?

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


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

296 :デフォルトの名無しさん:04/12/23 19:47:18
デザインパターンだけど実装方法も定義してあるから
コーディング技術も含む設計技術なんじゃないですか?

297 :295:04/12/23 19:55:27
>>296
どの本だよ実装方法なんて定義してあるのは

298 :デフォルトの名無しさん:04/12/23 21:03:41
>>296
実装は例示されているだけです(教典だとSample Code)
一応Implementationに実装方法についての議論はあるけど,
あくまで付加情報だと思う

299 :デフォルトの名無しさん:04/12/23 21:12:19
コーディングは技術ではなく技能だ
とか言ってみる

300 :296:04/12/23 21:14:09
そうっすね定義っていう言い方は間違いでした。
ただ自分はプログラマーなので実装のために読んだ。
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

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


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

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


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


304 :デフォルトの名無しさん:04/12/23 21:31:59
>>303
同感

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

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

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


306 :デフォルトの名無しさん:04/12/23 21:42:30
>>305
別に「GoFが全く新規に提案した」なんて前置きをつけてないし。

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

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

その典型が>>285


307 :デフォルトの名無しさん:04/12/23 21:44:41
だからさ・・・でざぱたはそれまでのプログラム経験の中で有効だと思えたものを選んで分類整理したものだろ?
それ考えればおのぞから答え出てくるかと・・・

308 :デフォルトの名無しさん:04/12/23 21:52:00
しかし Bridge と FactoryMethod は有効だと思えない
俺の理解が浅いだけで、本当はいたるところで使われているのかもしれないが

309 :デフォルトの名無しさん:04/12/23 22:04:48
>>308
その2つの用途が分からんってのは、
お前がマトモにプログラムを書いた経験がないってのが丸分かりだな。

恥ずかしすぎるww


310 :308:04/12/23 22:35:07
>>309
すまぬ。俺の理解が浅かっただけらしい。

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

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

311 :デフォルトの名無しさん:04/12/23 22:38:23
>>308
がんがれ

312 :デフォルトの名無しさん:04/12/23 22:43:51
実装と振る舞いが分離されてりゃ全部 Bridge に分類されるのか? 素朴な疑問。

313 :デフォルトの名無しさん:04/12/23 22:56:55
だから、べつにパターンに分類することないんだツーの。
そのパターンらしきもの使うことで分離の利点を得られるならそれでいいんじゃ。

314 :294:04/12/25 17:57:43
>>295
ごめん。考え方の路線が違う意味でいった。

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

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

315 :295:04/12/25 18:05:04
>>314
む〜考え方が違うのか

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

316 :294:04/12/25 18:05:26
>>312
ストラテジーとかいうのも実装と振る舞いが分離されているパターンだと思った。

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

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

317 :295:04/12/25 18:07:59
>>316 上段
たぶん Strategy と Bridge は違うっしょ

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

318 :295:04/12/25 18:09:28
317 の理由から、Strategy と Bridge に似ている部分があるのは当たり前
けど、この2つはぜんぜん違うと思う

319 :295:04/12/25 18:11:07
>>317
基本概念を
・実装と振る舞いの分離
に訂正

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

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

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

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

322 :デフォルトの名無しさん:04/12/25 21:26:08
StrategyとBridgeなんてまったく違うだろ。

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

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

323 :デフォルトの名無しさん:04/12/26 00:11:51
俺が大雑把なのかも知らんが両方ともたたいの一種としてしか認識してません・・・

324 :デフォルトの名無しさん:04/12/26 13:43:03
>>323
一言で多態でくくらずに、分類して名前をつけることに意味があるんだと思われ。

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

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

325 :デフォルトの名無しさん:04/12/27 01:46:23
>>324
デザインパターンは、適用後の姿をすべて見てしまうと「おんなじじゃん」となってしまう。
適用前の時点で何が分かっているのかに注目してみたらいいよ。

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

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

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


327 :デフォルトの名無しさん:04/12/27 05:34:20
>>326
お前は一生VBでトイプログラムでも作ってろw
もちろん、いっちょまえにシェアレジを利用してww


328 :デフォルトの名無しさん:04/12/27 08:06:23
UMLツールでパターン名のステレオタイプを書けたりする訳だが

329 :デフォルトの名無しさん:04/12/27 18:47:06
>>326
マジレスすると,
パターンは(素人でも使えることを目的にした)テンプレートではない.
知識を共有するための枠組み.(ソフトウェア設計への適用がデザパタ)
素人が素人から脱却する助けにはなりうるが,
素人がパターンを使っても良質なソフトウェアを作ることが出来るわけではない.

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

330 :デフォルトの名無しさん:04/12/27 18:59:42
>>329
なら偉そうな事を言うな。カス。

331 :デフォルトの名無しさん:04/12/27 21:47:04
>>330
あんたよりはマトモに理解しているぞ、329は。

332 :デフォルトの名無しさん:04/12/28 00:14:28
>>331
そうでもないよ。

333 :デフォルトの名無しさん:04/12/28 02:19:01
ではがんばって プログラム オブ 女医トイ つくってください

334 :デフォルトの名無しさん:04/12/28 21:44:13
>>333
寒すぎて忘年会の酔いもすっかり冷めた

335 :デフォルトの名無しさん:04/12/28 22:26:13
カスとか、トイプログラムでも作ってろw とか
おまいらは小学生か。
反論するならもっとまともな発言しる。

336 :デフォルトの名無しさん:04/12/29 04:15:30
カスはカスでいいじゃん。

337 :デフォルトの名無しさん:05/01/03 18:32:57
そんなおまいらに
ttp://www.shos.info/develop/oo/dscsnptn.html

338 :デフォルトの名無しさん:05/01/09 18:57:07
>>337
おもしろい!

339 :デフォルトの名無しさん:05/01/30 16:32:19
保守age

340 :デフォルトの名無しさん:05/01/30 20:22:06
Visitorパターンで、木構造(DOMツリーに毛がはえたようなもの)をたどる処理を書いています。
ここで、木構造を「たどる」という処理を、Visitor側で行うべきか、Acceptorとなる木のほうで行うべきか悩んでます。
今はVisitor側で行っているんだけど、Acceptor側の構造が変わったときにいちいち整合性をとるのが面倒になってきました。
みなさん、どっちに書いてます?


341 :デフォルトの名無しさん:05/01/30 20:28:42
>>340
たどる処理って iterator がやるんじゃないのか?


342 :デフォルトの名無しさん:05/01/30 20:36:08
>>340
各家を辿るのは訪問者の役目だから Visitor
Acceptor 側で違いが吸収できないくらい構造が変わったら、さっさと Visitor パターンを使うのを止めれ

343 :デフォルトの名無しさん:05/01/30 20:44:32
どう考えてもvisitor

344 :デフォルトの名無しさん:05/01/30 20:51:04
辿る側が Visitor で辿られる側が Acceptor
辿るクラスが入れ替わったら、Visitor も↑を満たすように入れ替わる

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

345 :340:05/01/31 08:16:02
>>341-344
「たどる側がVisitor」って、いわれてみればそのとおり。だからVisitorという名前なんだよな。
どうもありがとう。めんどうでもがんばる。

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

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

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

347 :デフォルトの名無しさん:05/01/31 20:15:04
確かに、枠組みであるという点でパターンとUMLは似ているかもしれない。

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

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

348 :デフォルトの名無しさん:05/01/31 22:44:57
ああ、確かにイディオムってのは違うな。
イディオムと言えるほど具体的なコードで表せるのはSingletonくらいか?スマソ

349 :デフォルトの名無しさん:05/02/03 01:17:35
お客さんが満足するのでデザパタを使っています


350 :デフォルトの名無しさん:05/02/03 02:17:39
>>340
遅レスだがツリー構造を知る第3者がVisitorをAccepterに突っ込ませたほうがいいんじゃないのか?
自分ならそうするが。
なんでVisitorがAccepterのコンテナのデータ構造を知らなきゃいかんの?

351 :デフォルトの名無しさん:05/02/03 16:39:55
>>350
ツリー構造を知る第3者 = >>341のいうiterator
かな?

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

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

352 :デフォルトの名無しさん:05/02/03 17:15:45
>>351
>ツリー構造を知る第3者 = >>341のいうiterator
>かな?
”んーVisitorをAcceptorに突っ込ませる人”です。
南下のクラスかもしれないし、コマンド処理するところにじか書きかもしれないし。
Visitorが自分でAcceptorに入り込んでいくよりは誰かがVisitorを突っ込ませるイメージだったので

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


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


354 :デフォルトの名無しさん:05/02/07 00:44:59
・デザインパターンを知ってるA君とB君の場合
A「おいB、ここどうやって実装する?」
B「あ?これSingleton、こっちStrategy。」
A「え〜っと、これをSingletonに、こっちをStrategyにするのは何故?」
B「(゚Д゚)ハァ? 駄目だオマエ( ´,_ゝ`)プッ」

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

355 :デフォルトの名無しさん:05/02/07 00:57:55
デザインパターンとアンチパターンの融合か
美しいな

356 :デフォルトの名無しさん:05/02/07 07:32:19
>>354
コミュニケーションを阻害しているのはBの態度だろうw

357 :デフォルトの名無しさん:05/02/07 07:39:57
(1) Aは本当に分かっていない
(2) AはBの判断(2行目)が適切ではないと考え説明を求めた
Bが(2)の可能性を無視してるのが元凶ですな

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

358 :デフォルトの名無しさん:05/02/07 07:43:17
空気嫁てないだけ

359 :デフォルトの名無しさん:05/02/07 12:03:51
・デザインパターンを知らないA君とB君の場合
A「おいB、ここどうやって実装する?」
B「んー、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにしよう。
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲する。」
A「え〜っと、のクラスのインスタンスは二つ以上あるとまずいから、コンストラクタをprivateにして外部からnew出来ないようにして、
んで唯一のインスタンスをstaticメソッドでgetするようにする。
こっちのクラスは、状況によって選択するアルゴリズムが変わると思うから、アルゴリズムごとに処理専用クラスを作って、それを所持するようにする。
処理はそのクラスに丸ごと委譲するのはなぜ」
B「(゚Д゚)ハァ? 駄目だオマエ( ´,_ゝ`)プッ」

問題はBの態度と判明

360 :デフォルトの名無しさん:05/02/07 12:13:15
こぶがひっこんじまったい

361 :デフォルトの名無しさん:05/02/08 01:13:50
>>359
ワロタ

362 :デフォルトの名無しさん:05/02/09 23:23:39
ファウラー氏のアナリシスパターンが意味分からん。

363 :デフォルトの名無しさん:05/02/10 16:07:22
>>362
分析屋さん(?)が読むような本だからね…。
「責任関係」とか「観測」あたりは比較的分かりやすいと思われ
ガンガレ

364 :デフォルトの名無しさん:05/02/11 21:59:29
>>362
だいじょうぶ、わからんのはおまえだけじゃない。みんなわかったふりしてるだけだ。

365 :デフォルトの名無しさん:05/02/12 17:26:16
俺もわかんね

366 :デフォルトの名無しさん:05/02/12 20:57:17
何でそういう風に分析する糧のを考えるのにはいいね。
覚えるもんじゃない。考え方を学ぶもの。

367 :デフォルトの名無しさん:05/02/14 04:40:13
C#によるデザインパターン
http://www.dofactory.com/Patterns/Patterns.aspx

368 :デフォルトの名無しさん:05/02/19 22:24:31
MedieterとObserverの違いを普通に教えてください。
集中管理という目的では同じに見えるんですが。

369 :デフォルトの名無しさん:05/02/19 22:34:33
>>368
前者は伝達経路に対するパターン。
後者は伝達方法に対するパターン。
両者はそもそも目的が違う。

370 :デフォルトの名無しさん:05/02/20 00:26:49
>>369
やはり目的の違いですか。
statとstrategyの違いみたいな感じ?

371 :デフォルトの名無しさん:05/02/20 19:32:41
>>368
このスレくらい嫁
>>273-276

372 :デフォルトの名無しさん:05/02/20 19:37:19
http://www.ogis-ri.co.jp/otc/hiroba/technical/JPLoP/DPforRDB.html
数少ない日本発デザインパターンのひとつ

373 :デフォルトの名無しさん:05/02/21 14:21:06
デザインパターンF.A.Q.
http://www.hyuki.com/dp/dpfaq.html

天麩羅追加きぼん(次スレがあれば)

374 :デフォルトの名無しさん:05/02/23 02:29:04
最近DQ8をやっていて思ったこと。
1.
「さまようよろい」は、戦闘中に「ホイミスライム」を呼びます。
「じごくのよろい」は、戦闘中に「ベホマスライム」を呼びます。

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

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

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

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

375 :デフォルトの名無しさん:05/02/23 17:45:56
>>374
真性ヲタ

376 :デフォルトの名無しさん:05/02/23 19:50:20
可愛いあの子をObserve

377 :デフォルトの名無しさん:05/02/23 20:55:47
キモい>>376を Two-Phase Termination

378 :デフォルトの名無しさん:05/02/23 21:39:54
>>376 はストーカーパターン


379 :デフォルトの名無しさん:05/02/23 23:00:01
>>378
アンチパターンだよね

380 :デフォルトの名無しさん:05/02/23 23:48:06
>>377
だけど私はImmutable

381 :デフォルトの名無しさん:05/02/24 15:32:14
そいつぁItrator。

382 :デフォルトの名無しさん:05/02/25 02:15:53
>>381
×Itrator
○Iterator


383 :デフォルトの名無しさん:05/03/02 23:33:07
短時間でデザインパターンの全貌をなんとなくつかむには何がオススメですか?
「まずはこの Web(本) を読め!」というものを1つだけ選んで教えてください。

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

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

385 :デフォルトの名無しさん:05/03/03 00:17:49
>>383
GoF

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

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

387 :デフォルトの名無しさん:05/03/03 14:56:17
デザパタって何で賞賛されるんだ?

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

388 :デフォルトの名無しさん:05/03/03 15:22:50
手法に「名前を付けた」ことがデザパタの最大の功績。
手法自体はやってる人は昔からやっていること。


389 :デフォルトの名無しさん:05/03/03 16:21:58
>>387
……馬鹿じゃないの?マジで。
一体どうしたらそんな発想が出てくるんだ?
デザパタをなんだと思ってるんだ。「今まで誰も思いつかなかったオリジナリティあふれる設計」か?

390 :デフォルトの名無しさん:05/03/03 21:16:59
うぇあーお、やべーよ
おれはデザパタを読む前からテムプレートとかやてたーよ
おれってすげーよ

391 :デフォルトの名無しさん:05/03/03 21:29:15
>387
セクハラって何で非難されるんだ?

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




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

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

393 :デフォルトの名無しさん:05/03/03 23:30:48
>>392
言う相手を間違えてない?
390は明らかに387に対する煽りか、きちがいだろ

394 :デフォルトの名無しさん:05/03/04 00:17:00
>>393
そうか、そうかもな。

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

395 :デフォルトの名無しさん:05/03/04 12:40:44
暗黙知を形式知に変えることの重要性が分からない者には
何を言っても無駄。


396 :デフォルトの名無しさん:05/03/04 14:30:51
>>390
>>373の17を嫁

397 :デフォルトの名無しさん:05/03/04 14:56:13
>>388
そうですよね。
異様なまでに賛美されてるから
不思議に思ってしまって。

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

>>390
ばかでつね

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

398 :デフォルトの名無しさん:05/03/04 15:10:09
ANSIのC/C++のように規格化すればいいってか、くだらん。
案件にとりかかる前に仕様を統一しとけばイイだけだ。


399 :デフォルトの名無しさん:05/03/04 15:14:47
言語の規格さえしっかりしていれば、それで十分。

400 :デフォルトの名無しさん:05/03/04 15:31:48
シンタックス、イデォム、パターン

401 :デフォルトの名無しさん:05/03/15 12:04:44
日経ソフトウエアでデザインパターンの連載が始まっていると聞いたのですが、
今までどんなパターンが解説されてきたのかを教えてください。

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

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

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

403 :デフォルトの名無しさん:05/03/17 01:55:47
RootNodeParse()で
SkipTokenを2回つかって、<A> <B> とすすんで、currentTokenで<C>または<D>をとってきて
XNodeParse()かYNodeParse()にとぶか(それともUnsupportでエラーにするか)をきめればいいのでは?


404 :デフォルトの名無しさん:05/03/17 02:07:48
BNF は、文法の定義方法で、構文解析方法じゃないので、
「忠実に従う」といっても、プログラムの駆動が、
定義文をそのままトレースするという意味ではないんでは。

405 :デフォルトの名無しさん:05/03/17 03:36:16
このへんはデザパタじゃなくて言語処理の話だな。

406 :デフォルトの名無しさん:05/03/17 07:04:09
>>402
RootのBNF定義を変形するべしに1票。「BNFに忠実に」という意味は、BNFを変形してはいけないというわけではないと思う。

407 :デフォルトの名無しさん:05/03/17 08:40:58
インタプリタパターンで普通にコードを書くと
最初 ノードXのつもりで解析を始める
A B と順に解析を始める
C の解析に失敗する
Xの解析に失敗したと分かる
Rootの|が発動する
Yの解析が始まる
A B Dと解析が進む

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

408 :デフォルトの名無しさん:05/03/17 10:24:23
BNFに忠実にってのは、「書いた文法定義をそれに対応するコードに
置き換えましょう」という意味であって、
「文法定義に拡張BNFを使ってはいけない」という意味ではないと思う。


409 :デフォルトの名無しさん:05/03/17 12:40:10
>>402
俺、インタプリタパターン書いたとき
そういうBNFもちゃんと処理できたよ。
何で困ったのか教えてクリ

410 :デフォルトの名無しさん:05/03/19 01:59:38
StrategyとかCommandとかそこらへんの「振る舞いをまるごと変更や持ち運び」
っていうパターンって、クロージャひとつあれば解決するよな

411 :デフォルトの名無しさん:05/03/19 02:46:11
>>410
まぁ、クロージャは道具で、デザインパターンは工法だから、
問題なかろう。


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


413 :デフォルトの名無しさん:05/03/20 20:16:58
>>412
クロージャという言葉には色々な意味・用途がある。
構文解析が話題となっている時に出てくるクロージャといえば、
多分、"(その時点で考えうる)遷移状態全てからなる閉包"
を指しているんだろうな。


414 :デフォルトの名無しさん:05/03/20 22:52:26
閉包とかいわれてもわけわからん。

ヘイホー、ヘイホー。

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

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

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

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

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

416 :デフォルトの名無しさん:2005/03/21(月) 22:26:34
>>407じゃないけどScheme的解決法として、
そのままRootのYの直前の継続を呼び出すというのが簡単なんだけど、
Cとかの手続き型言語に言い換えればただのバックトラッキングということかな。
>>407の意見を聞いてみたいね。

99 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)