〔隔離〕デザインパターンは本当に必要か？〔スレ〕

1 ：デフォルトの名無しさん：2005/06/21(火) 19:09:56

そもそもデザインパターン自体どうなのよ？って話はここでやれ。

2 ：デフォルトの名無しさん：2005/06/21(火) 19:13:40

>>1
乙

確かにデザパタそのものについての話が全然無かったしな最近。

3 ：デフォルトの名無しさん：2005/06/21(火) 19:15:53

>>2
ここは隔離スレなんで建設的な話は期待しないほうがいいですよ

4 ：デフォルトの名無しさん：2005/06/21(火) 19:41:13

まず、オブジェクト指向からはずれちゃってるのが問題だよね。
デザパタがいいって人はとりあえずオブジェクト指向理解してる（つもり）なの？

5 ：デフォルトの名無しさん：2005/06/21(火) 19:48:22

オブジェクト指向以外認めないという人はいったいどんな言語を使っているんですか？

6 ：デフォルトの名無しさん：2005/06/21(火) 19:48:58

>>5
C++

7 ：デフォルトの名無しさん：2005/06/21(火) 20:02:16

>>6
いや、ネタはいいから（笑）

8 ：デフォルトの名無しさん：2005/06/21(火) 20:04:12

>>7
なんて答えて欲しかったんだ？
デザパタなんて使ってるぐらいだから、
一度もC++でオブジェクト指向で設計して組んでみたことなんでしょ？

9 ：デフォルトの名無しさん：2005/06/21(火) 20:13:32

デザパタで成功してるのはstlのイテレータくらい。
MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
どうしてもキショイコードになる。

10 ：デフォルトの名無しさん：2005/06/21(火) 20:32:56

MFCは忘れてやれよ･･･。あれは正直ウンコさ。
ＭＳのデザパタはC#とか見てあげてください。

11 ：デフォルトの名無しさん：2005/06/21(火) 20:46:31

>>8
まさかネタじゃなかったのか？
デザパタを否定するくらいstrictなOO人間がよりにもよってC++を肯定するなんて信じられないんだが。

12 ：デフォルトの名無しさん：2005/06/21(火) 21:00:08

デザパタ＝トリッキーと主張してた人は、結局テンプレートが
読めないから恨み節でデザパタ否定してただけでしょ？
いくら否定してもテンプレートがなくなる事はないのに、無駄
足掻きだな。

13 ：デフォルトの名無しさん：2005/06/21(火) 21:17:22

>>11
OOPLがC++しかない時期があったのだ

14 ：デフォルトの名無しさん：2005/06/21(火) 21:20:39

まぁ、一般向け処理系はSmalltalk/Vの方が早期から安く入手可能だったけどｗ

15 ：デフォルトの名無しさん：2005/06/21(火) 21:24:53

>>13
今はいろいろあるじゃん、なんで昔の話？

16 ：デフォルトの名無しさん：2005/06/21(火) 21:43:58

本スレでデザインパターンを否定していたやつってここにいる？
デザインパターンを否定していないやつはオブジェクト指向を理解していないとか、
ほんとうにオブジェクト指向で設計するとデザインパターンなんて使わないとか
いうようなことを言っていたけど、おまいのオブジェクト指向論を講師してくれんかな？
オセロプログラムでもいいから具体例だしてさ。

17 ：デフォルトの名無しさん：2005/06/21(火) 21:46:52

>>16
えー。向こうで死ぬほど書いたじゃん。
あと、設計の話だよー。
具体例なんてでねぇぞー。
ソースコード期待してるなら帰った方がいいぞ。

18 ：デフォルトの名無しさん：2005/06/21(火) 21:48:08

>>16
聞くポイントがまじぃんだよ。
ソースが欲しいわけじゃなくて、要は開発の流れみたいのが知りたいだけじゃねーの？

19 ：デフォルトの名無しさん：2005/06/21(火) 22:06:16

>えー。向こうで死ぬほど書いたじゃん。

ならリンク張ってよ、それくらいできるでしょ？

>あと、設計の話だよー。

>ソースコード期待してるなら帰った方がいいぞ。

オセロプログラムの設計の話でしょ？
しかも何でもいいみたいだよ？

20 ：デフォルトの名無しさん：2005/06/21(火) 23:10:56

>>19
げー。
俺が探してくんの？ｗ
誰か知らん奴のためになぜにここまで苦労せにゃならんのかｗ

21 ：デフォルトの名無しさん：2005/06/21(火) 23:57:34

>俺が探してくんの？ｗ

向こうで死ぬほど書いたんだろ？何言ってんの？

22 ：デフォルトの名無しさん：2005/06/22(水) 00:00:15

つか名無しの書き込みじゃどれ書いたのかなんて書いた本人しかわからないだろ

23 ：デフォルトの名無しさん：2005/06/22(水) 00:13:00

ここまでの流れ見てると、デザパタ否定派のが分が悪いな。

24 ：デフォルトの名無しさん：2005/06/22(水) 00:21:25

俺はてっきり
・オブジェクト指向で開発
・たくさんオブジェクト指向で開発
・なんか同じ様な設計パターンにならね？
・デザパタ誕生
かと思ってた
まぁオブジェクト指向しなくてもデザパタは適用できるんだけどさ

25 ：デフォルトの名無しさん：2005/06/22(水) 00:26:44

>>21
まあ、一番大事なのはこれ↓だな。

>ＯＯＰなんだけどもなにもアプローチが
>基本から脱線しまくってるじゃねーか。
>どんなに複雑だろうとなんだろうと、オブジェクト指向はオブジェクト指向だ。
>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。

掻い摘んでいうと、
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向であって
パターンを覚えさせるデザインパターンはアプローチがおかしい
と、そういうこと。

26 ：デフォルトの名無しさん：2005/06/22(水) 00:32:32

デザインパターンはコミュニケーションの手段であって設計のテンプレートではないと思ってたんだが

27 ：デフォルトの名無しさん：2005/06/22(水) 00:36:08

> 対象物の構造をそのままクラスとして反映させるのがオブジェクト指向

おまえまじでいってんのかよｗ　あんまプログラム組んだこと無いだろｗ
本当にそんな稚拙なOOPの定義で、１作品完全に組めるならやってみろｗ
素人がｗ

28 ：デフォルトの名無しさん：2005/06/22(水) 00:38:44

>>25
ゲームなどのクライアントアプリケーションやスタンドアロンアプリケーションならそれでも行けるよね。
DB連携のWebアプリはどうする？
DB検索と更新機能のデザインパターンを使わない設計の具体例を教えてくれ。

29 ：デフォルトの名無しさん：2005/06/22(水) 00:39:00

>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。

どこでこんなこと習ったんだ？
教えてもらった先生に文句言ったほうがいいぞ。

30 ：デフォルトの名無しさん：2005/06/22(水) 00:41:10

「オブジェクト指向で設計すればデザパタ不要」
もうこの一言で「デザインパターン」を知らないことは明白。

31 ：デフォルトの名無しさん：2005/06/22(水) 00:41:38

>>27
組めるよ。
なんでできないの？

32 ：デフォルトの名無しさん：2005/06/22(水) 00:41:46

>>26
同意
典型例に名前を付けただけだよな

33 ：デフォルトの名無しさん：2005/06/22(水) 00:41:47

「だったはずだ」ってまさか思い込みで書いてないよな？

34 ：デフォルトの名無しさん：2005/06/22(水) 00:42:39

LOL

35 ：デフォルトの名無しさん：2005/06/22(水) 00:44:11

>>28
web関連やったことないから知らんけど、
基本的に対象物の構造をそのままクラスに反映するわけだから
DBとやらの構造に根本的な欠陥が無い限り組めると思うよ。
それがオブジェクト指向の強みだからね。
逆にDBとやらが腐ってたら設計も腐るだろうね。

36 ：デフォルトの名無しさん：2005/06/22(水) 00:44:33

いいなぁ。専門学校生。生来勉強できないだけのことはあるｗ
講師もバカだしなｗ
超使えねぇ解雇された元同僚が某専門学校で講師やってるよｗ

37 ：デフォルトの名無しさん：2005/06/22(水) 00:47:28

>>35
もしかしたら、超天才かも。
そんなわけ無いか...

38 ：デフォルトの名無しさん：2005/06/22(水) 00:47:28

>>35
やったこともないのにできるなんてよく言えるな。
おめでたい奴だ。

39 ：デフォルトの名無しさん：2005/06/22(水) 00:53:58

GRASPパターンについてはどう考えてるのか聞きたい

40 ：デフォルトの名無しさん：2005/06/22(水) 00:54:06

>>38
いえる。
だから、マ板にいる奴等ってすげー偉そうじゃん。
それは自分が対象物の構造さえ理解できれば確実に
プログラムを組めるということが確信できているから。
で、オブジェクト指向覚えた奴同士で設計に関する議論ってみたことないでしょ？
そりゃする必要がないから。
なんたって確実。
あとは対象物の理解がどれだけできているかってただそれだけ。
人に聞いてわかるもんじゃないし、あとは自分がどれだけ勉強するかってだけ。

41 ：デフォルトの名無しさん：2005/06/22(水) 00:54:53

>>35はServletやJSPやJavaBeansをどうやって使うつもりなんだろう？
セッション管理やトランザクション管理の仕組みも自分で設計するのかな？
CommnadパターンもServiceLocatorも使わないから、ビジネスロジックの呼び出しもベタ書き？
プレゼンテーション層/ビジネスロジック層/EIS層を分けて考えることもしないんだよね？
DAOパターンやDTOパターンもSingltonも拒否？
拡張性もなく、リクエストの度に大量のオブジェクトを生成して恐ろしくパフォーマンスの低いシステムを作りそうだ。

42 ：デフォルトの名無しさん：2005/06/22(水) 00:56:38

本当にいいたいことは、やりたいようにプログラミングさせろってことなんだろ？
デザインパターンとかで縛りを受けたくないと...

オブジェクト指向云々は単なるこじつけでさ

43 ：本ｽﾚ住人：2005/06/22(水) 00:59:26

>>39
その本良書かもしれないけど、あんまポピュラーじゃないから、
ちゃんと説明する努力をしないと伝わらないよ。
俺なんて本ｽﾚで調査しまくり、翻訳しまくりだ、最近orz

44 ：デフォルトの名無しさん：2005/06/22(水) 00:59:26

デザパタは縛りでは無いが、名前がないパターンは伝達に不便なので
避けがちになるかもしれないから縛りに感じることもあるか。
それより伝達の欲求がないなら覚えるだけ面倒にしか感じないだろうな。
一人で設計してるだけならそう思うかも。

45 ：デフォルトの名無しさん：2005/06/22(水) 01:03:43

>>41
拡張性も糞も無い。
俺はただあるべき構造をただクラスに反映させるだけ。
そのために対象物の構造を理解する必要はあるけどね。
要は対象物の構造が破綻さえしてなきゃ大よそのもんは組めるってこと。

46 ：デフォルトの名無しさん：2005/06/22(水) 01:06:31

>>45
マジですか？
仕様の変更とかあったら組みなおすの大変じゃない？

47 ：本ｽﾚ住人：2005/06/22(水) 01:06:57

>>39
あと、こっちは隔離スレだから、
ちゃんとした話は本ｽﾚ　
　　【GoF】デザインパターン5
　　http://pc8.2ch.net/test/read.cgi/tech/1119158274/
でやった方がいい。
ところで、こんな荒れてるスレでパターン・コレクション名だけこそっと書いて
そのまま無反応になるのは、なにかのオマジナイですか？

48 ：デフォルトの名無しさん：2005/06/22(水) 01:12:02

>>45
Webシステム開発は仕様変更が激しいからねー。
そんなんじゃ、手戻り多くてあっという間にあぼーん確定だね♪

49 ：デフォルトの名無しさん：2005/06/22(水) 01:22:29

>>25への反論

1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
　　不完全な表現の例：
　　多重継承、
　　　　時間的な状態変化、
　　　　計算不可能な対象物/概念、
　　　　非常に複雑な対象物/概念
　　　　etc.

　　もしあらゆる事柄を表現しシミュレーションする方法があるのなら、
　　科学者の仕事の大半はいらなくなる

2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
　　対象物をそのまま記述するのではなく、
　　特徴を捉えて扱いやすい簡易的な表現を得る事である。
　　要するに、抽象化こそが知性の最も重要な働きなのである。

　　抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
　　それはせいぜいＰＣ上のソフトウェアの「移植」とか「エミュレーション」程度の事に過ぎない。

3. このように対象物の構造と、ソフトウェア上の表現・・・ここではオブジェクト指向モデル/プログラム
　　との差異を何らかの形で縮め、実用上問題がないように取り繕う技術が、
　　モデリングであり、設計であり、プログラミングである。

　　これは普通にソフトウェアを弄っている人間にとって、常識である。

50 ：デフォルトの名無しさん：2005/06/22(水) 01:23:05

>>48
仕様変更による構造の変更を無理やり設計レベルで吸収しようとすると
だいたいドツボにハマる。
俺はいっそしっかり組み直してしまったほうがいいと考えるけど。（完全に変更の場合はね）
つか、そのまま残して置いちゃ駄目でしょ。

それに、あいまいな部分をあいまいに組んでおく手もないわけではないよ。

例えば、始め敵クラスの詳細が決まってないときは詳細が決まるまで
「敵」クラスとしてあいまいなままおいときゃいいわけだし。
んで、「敵」クラスの詳細が決まったら初めて「敵：スライム系」「敵：ゴブリン系」だの
その詳細を組みだしゃいいわけだしね。
２つの方法があってどっちか迷ってるときも同じ。あいまいなままどさっとおいておきゃいい。
汎用性をつけたいときも同じ、でもそれなりに大変ではあるよ。
逆にあんまり詳細に組み過ぎてもやっぱり駄目。ＲＰＧなんかでアイテム１つ１つにクラス作るわけにはいかないからねぇ。
ってこの辺は人によって方法は違うだろうし、どんな方法をとろうがその人の自由だな。
まあ、本質にかかわる話じゃ無い。

51 ：デフォルトの名無しさん：2005/06/22(水) 01:30:33

>>49
ちょっと小出しに話してよ。
レスつけずらいよ。
1ってなんで不可能なのかさっぱりわからないんだけど。

52 ：デフォルトの名無しさん：2005/06/22(水) 01:37:11

>>50
変更に対して強い設計を可能にするデザインパターンもあるんだがそれは無視？

まぁ・・・あれだ。
完璧な設計などまずありえないし、お尻がキッチリ決まってる仕事の場合は
設計にそれほど時間をかけられないし、深くは追求するつもりはないけど。
# 書いているうちに余計なおせっかいな気がしてきた

53 ：49　一部訂正。結局駄文だけど本質は突いているつもり：2005/06/22(水) 01:39:23

>>25への反論

1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
　　オブジェクト指向では不完全な表現しか得られない事象の例：
　　　多重継承、
　　　　時間的な状態変化、
　　　　etc.

　　一般的に、不充分な表現しか得られない事象の例：
　　　　非常に複雑な対象物/概念
　　　　計算不可能な対象物/概念、
　　　　記述不可能な対象物/概念
　　　　etc.

　　もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
　　大半の科学者は仕事をする必要がなくなる。
　　(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)

2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
　　対象物をそのまま記述するのではなく、
　　特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
　　要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。

　　抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
　　それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。

3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
　　の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
　　モデリング/設計/プログラミングの中心的な作業であり、
　　そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。

54 ：デフォルトの名無しさん：2005/06/22(水) 01:40:03

>>51
　なんすか？
　質問があるなら簡潔明瞭に済ませてね。
　長々と議論する時間はもうないんで。

55 ：デフォルトの名無しさん：2005/06/22(水) 01:41:19

デザパタなんて息抜きって言うかお遊び

56 ：デフォルトの名無しさん：2005/06/22(水) 01:41:40

ダメだこりゃ。理想論でしかない。
この人はビジネスロジックとデータモデルの設計はできるが、それだけ。
プレゼンテーション層、EIS層の設計と実装はムリだね。
定石とかフレームワークという概念が皆無。

57 ：エリート研究開発すぁ：2005/06/22(水) 01:45:55

まぁ>>41あたりの大半は、
1996-1997当時にほぼ独力 (ただし関連文献や技術書、GoF、各種MLをROM捲り)
で作れたけどね。

58 ：デフォルトの名無しさん：2005/06/22(水) 01:46:59

Webアプリなんてこうやって組んでおけば誰にでもわかりやすいし
どんなアプリでもほぼこれでOKなのに、それでも毎回オレ様オリジナル設計するの？
無駄な努力にしか思えない。
http://java.sun.com/developer/technicalArticles/J2EE/patterns/J2EEPatternLanguage.gif

59 ：エリート研究開発すぁ：2005/06/22(水) 01:48:00

つまりJavaやHORBが出た当初なら、
しがらみがほとんどないから、
フルスクラッチで大建築を作りやすかったんだけど、
もうあれから10年近く立ってるからなぁ。しがらみ過ぎてて最近始めた人は大変だなぁと思う

60 ：デフォルトの名無しさん：2005/06/22(水) 01:48:52

>>57
作れるかどうかじゃなくて、これらの手法をパターン化していつも使うかどうか。
オブジェクト指向厨はそうはしないで、毎回毎回アタマをひねるらしいよ。

61 ：エリート研究開発すぁ：2005/06/22(水) 01:52:57

いうまでもなく俺はGoF賛成派で、パターンは重要と考える口だが。

歴史的経緯を見てきた漏れの意見を言うと、
J2EE Blueprint / J2EE Patternってイマドキ神格化されすぎてると思う。
リアルタイムでは、IBM BestPracticeやNetscape, WebLogicの方が
よっぽど進んでいたと思うよ。

更にマズイのは、J2EE反主流派のOracleなんて、
J2EE Pattern織り込み済みでもう必要としないＤＢ用フレームワークを使っている事。
そんな環境でも、木偶の坊みたいな人がJ2EE Patternを無理やり適用しようとする。
こういう奴を見ちゃうと、Pattern言語/Pattern推進派の努力にも限界があるのだと実感する。

62 ：デフォルトの名無しさん：2005/06/22(水) 01:54:20

>>58
つーか、webアプリ組んだことないから知らないけど
同じものなら使いまわせばいいでしょ？
どうしてパターン使ってまで組み直すの？

オブジェクト指向＝毎回作り直す

とかかってに捻じ曲げて無い？
そんなことはいってないよ。

63 ：デフォルトの名無しさん：2005/06/22(水) 01:55:33

>>39 まだぁ～(ﾁﾝ、ﾁﾝ☆

>>51 まだぁ～(ﾁﾝ、ﾁﾝ☆

もう寝るよぉ？

64 ：デフォルトの名無しさん：2005/06/22(水) 01:57:49

>>62
貴方の主張は、設計を使いまわすのではなく、実装を使いまわすって話ね。
SI屋がやりそうな手口だ。

ところでここの住人は何時まで起きてるの？
明日も仕事だよね？

65 ：デフォルトの名無しさん：2005/06/22(水) 02:03:59

オマエモナーと脊髄反射レス

66 ：デフォルトの名無しさん：2005/06/22(水) 02:05:19

>>62
よく使われる組み方をカタログ化しておいて、使い回すのがデザインパターンなんだけど。

67 ：デフォルトの名無しさん：2005/06/22(水) 02:07:26

>>66
ん？毎回パターン使って組まなきゃならないものなのか？
って聞いてるんだけど？
要はソースレベルでの使いまわしは効かないの？
って話ね。

68 ：デフォルトの名無しさん：2005/06/22(水) 02:12:49

>>67
もちろんフレームワークやライブラリは最大限利用するよ。

69 ：デフォルトの名無しさん：2005/06/22(水) 02:14:43

>>68
いやいや、ソースレベルでの使い回しができるかできないかの話。

70 ：デフォルトの名無しさん：2005/06/22(水) 02:14:53

ほぼ陥落だね

71 ：デフォルトの名無しさん：2005/06/22(水) 02:22:34

フレームワーク・ライブラリを最大限に利用したら
使い回せるモノなんてほとんど無いんだけど。
各システム固有の要件に応じた処理とか画面と設定ファイルしか作らないので。

72 ：デフォルトの名無しさん：2005/06/22(水) 02:24:55

>>68
おまえジェネリックプログラミングとかテンプレートって知らないのか？

73 ：デフォルトの名無しさん：2005/06/22(水) 02:32:59

本当にGenericに、ソースコードで直接パターンそのものを表現できるのなら
そっちのが望ましいのは確かだよな。Modern C++ Designの例のように。

ただし、デザパタ自体の存在価値がそれで無くなるわけではない。
あれは、プログラマ間の共通言語、意思疎通の道具としての存在価値が
もっとも大きいのだと思う。
パターン化されたデザインは、for (i = 0; i < 10; ++i);
のようなパターン化されたループのように、認識・理解しやすいし。

74 ：デフォルトの名無しさん：2005/06/22(水) 02:35:44

>>73
あいやー。
再利用なんて無理にしないほうがいいと思うぞ。
できたらラッキーぐらいにしとけ。

75 ：デフォルトの名無しさん：2005/06/22(水) 02:40:47

>>74
おまえ、STL(スタンダード・テンプレート・ライブラリ）って知らないのか？

76 ：デフォルトの名無しさん：2005/06/22(水) 02:43:15

> 本当にGenericに、ソースコードで直接パターンそのものを表現できるのなら
>そっちのが望ましいのは確かだよな。

ん？できるじゃん。なんでできないと思っているの？

77 ：デフォルトの名無しさん：2005/06/22(水) 02:44:31

ひょっとしてJavaってC++のtemplateのような機能は無いのか？

78 ：デフォルトの名無しさん：2005/06/22(水) 02:51:35

>>77
近いのはあるがあれはコレクションを使いやすくする程度の使い道しかない

79 ：デフォルトの名無しさん：2005/06/22(水) 02:51:40

>>16
君らは概念がごちゃごちゃになってる。
多重継承を使うなよ。ってのもデザインパターンの一種なんだよね。
べからず集なので、アンチパターンとも呼ぶが。

でだ、デザインパターンって本を読むと、全体にトリッキーだったり、
（そうなってしまう前に設計で回避しろよーてな場合が多い）
Tipsレベルが多いんだ、の割には宣伝文句が大げさだから、
喧嘩になってる。さらに日本では訳や書籍が訳分からん言葉を
積極的に使うから更に悲惨な事態になってる。

「デザインパターン」と言う概念は否定しようも無い、だって既に
この世の中に有る物に名前を付けただけなんだから。

で、デザインパターンを批判してる者の言い分を聞くと、提出
されたパターンが汚いって話で、これはその通りだと思うし、
デザインパターンに、（デザイン）なんて言葉付いてるのが
日本人感覚だと惑わされるんだよね。

今のデザインパターンってのは、どう読んでもレスキューパターン
と言う名前の方がふさわしい。

80 ：デフォルトの名無しさん：2005/06/22(水) 03:06:05

>>79
そんな上等なレベルじゃないよ。知りもしないくせに「パターン」で反応しているだけ。
標準ライブラリは当たり前に使っている癖に、なぜかメタレベルのライブラリだと拒否反応を起こす。

81 ：デフォルトの名無しさん：2005/06/22(水) 03:08:28

デザインパターンはライブラリじゃないだろ

82 ：デフォルトの名無しさん：2005/06/22(水) 03:08:48

言語依存の話しをするなよー

83 ：デフォルトの名無しさん：2005/06/22(水) 03:09:25

>>81
"メタ"ライブラリと言えるだろ

84 ：デフォルトの名無しさん：2005/06/22(水) 04:06:02

最初から「デザインＴｉｐｓ」とでもしとけば誤解する奴が減ったのになぁ・・・

85 ：デフォルトの名無しさん：2005/06/22(水) 09:47:37

>>79
＞「デザインパターン」と言う概念は否定しようも無い、だって既に
＞この世の中に有る物に名前を付けただけなんだから。
この世の中にあるもの。
であるはずなのに、なぜ名前をつけてはいけないのですか？

ドラえもんという存在がいて、名前がなかったらなんて呼べばいいのか。助けてドラえも～ん。

86 ：デフォルトの名無しさん：2005/06/22(水) 11:26:50

>>84
日本人の英語力のなさまで面倒みきれない

87 ：デフォルトの名無しさん：2005/06/22(水) 14:31:37

>>85 の日本語力のなさは誰が面倒みてくれるんでしょう？

88 ：デフォルトの名無しさん：2005/06/22(水) 14:36:45

>>67
>要はソースレベルでの使いまわし
なんだ、プログラミングパターンは使ってるじゃん。
それの抽象度を上げたのがデザインパターン。
使いまわすときに、多少変更して使った事ないか？

89 ：デフォルトの名無しさん：2005/06/22(水) 15:49:13

デザインパターンはゴミ。
デザインパターンなんてものは、口出しできないけど口出したいって思ってる
バカがひたすら持ち上げてるだけ。

90 ：デフォルトの名無しさん：2005/06/22(水) 16:07:46

>>89
てかゴミパターンも有るってことで。
SINGLETONパターンなんか、本当にゴミだと思うし。

91 ：デフォルトの名無しさん：2005/06/22(水) 16:09:30

>>90
クライアントやスタンドアロンしかやったことない奴はそう思うのだろう。
サーバサイドでは普通に使うけどね。

92 ：デフォルトの名無しさん：2005/06/22(水) 16:13:54

>>91
SINGLETONは普通に使うよ。GoF本の言うSINGLETONパターンを
ゴミと言ってるだけ。

93 ：デフォルトの名無しさん：2005/06/22(水) 16:25:38

>>92
それには同意。俺はDIコンテナにSingletonインスタンスの管理をさせてるから
ああいうコーディングはしない。

94 ：デフォルトの名無しさん：2005/06/22(水) 16:34:47

>>93
だよねー。

あのコーディングのどこにメリットが有るのか小一時間といつめたくなる。

95 ：デフォルトの名無しさん：2005/06/22(水) 16:49:56

ぜんぶstaticにしちゃえば嫌でもシングルトンだしね

96 ：デフォルトの名無しさん：2005/06/22(水) 17:00:10

>>95
うんだ。てか、ＳＩＮＧＬＥＴＯＮパターンには、初期化されてないインスタンスを
呼ぶ危険性まであって、アンチパターンの方が似合てると思うんだ。

97 ：デフォルトの名無しさん：2005/06/22(水) 17:01:06

>>96 それはない

98 ：デフォルトの名無しさん：2005/06/22(水) 17:05:01

>>96
それはバグだろ

99 ：デフォルトの名無しさん：2005/06/22(水) 17:11:27

いくつかのスレッドが同時に初回staticのインスタンスを呼ぶ場合、
ゴミデータになるらしい。あとSMP環境だともっとややこしい事になるそうな。

100 ：デフォルトの名無しさん：2005/06/22(水) 17:13:04

>>99
それってC++の話？

101 ：デフォルトの名無しさん：2005/06/22(水) 17:14:20

そうC++、Javaは知らん。

102 ：デフォルトの名無しさん：2005/06/22(水) 17:16:55

スレッドの排他制御もわからんのか・・・

103 ：デフォルトの名無しさん：2005/06/22(水) 17:19:22

Javaでそれが起こったらJVMのバグとしかいいようがないな。

104 ：デフォルトの名無しさん：2005/06/22(水) 18:22:05

シングルトンがガベコレ対象になる恐れがうんぬんって
記事を見た記憶がありんす。

105 ：デフォルトの名無しさん：2005/06/22(水) 18:46:44

>>99
GoF では環境に依存しないよう、あえて実装してないが
MT safe にするためには当然、排他制御しなきゃならん。
んなこたあパターンに限った話じゃない。

106 ：デフォルトの名無しさん：2005/06/22(水) 18:47:31

>>97-98
きっと何処かで初期化されてるオブジェクトを、2度目の
生成するリスクをさけるにしては、リスクの方が大きい
と思うんだね。

デザインパターンてな考えかたは、認めるし、効果あると
思うけど、GoFにカタログ作らせるのは、不味いと思うよ。
全体にトリッキーなんだよ、奴らのカタログは。

107 ：デフォルトの名無しさん：2005/06/22(水) 18:52:01

出たトリッキーｗ
どのへんがトリッキーなのか具体的に解説きぼんぬ

108 ：デフォルトの名無しさん：2005/06/22(水) 18:59:33

>>107
隔離スレなんだから、反証責任はデザパタのカタログを信じてる馬鹿の
方に有る.

109 ：デフォルトの名無しさん：2005/06/22(水) 19:00:24

トリッキー、トリッキー、GoF時代のthreadは、トリッキー、トリッキー、GoF時代のOOPアプリはね、
教えてあげないよっ、じゃん♪

110 ：デフォルトの名無しさん：2005/06/22(水) 19:21:52

>>108（笑）

111 ：デフォルトの名無しさん：2005/06/22(水) 19:33:04

>>105は >>96のいう危ないインスタンスの例をあげただけだが、
ModernC++Designにある安全で速いダブルロックチェックドなシングルトンさえも
いまは安全でなく、ReadMemoryBarrier()とWriteMemoryBarrier()を
つかってない時勢にそぐわないものになってるというおはなし。

112 ：デフォルトの名無しさん：2005/06/22(水) 19:36:18

その手の(ハードウェア・)アーキテクチャ依存な話は、
アレつかって切り離すというのが、ここ２～３年の潮流

113 ：デフォルトの名無しさん：2005/06/22(水) 19:58:56

どこがトリッキーなのか言わずにトリッキーだと言って信用されるとでも思ってるんだろうかｗ

114 ：デフォルトの名無しさん：2005/06/22(水) 20:06:07

トリッキーという発言自体がトリッキー

115 ：デフォルトの名無しさん：2005/06/22(水) 20:14:54

>>114
寧ろ発言者の存在自体がトリッキー

116 ：デフォルトの名無しさん：2005/06/22(水) 20:38:45

このスレの存在がトリッキー

117 ：デフォルトの名無しさん：2005/06/22(水) 20:59:45 BE:140478454-

お前らトリッキーって言いたいだけちゃうかと。

118 ：デフォルトの名無しさん：2005/06/22(水) 21:05:00

そうだ

119 ：デフォルトの名無しさん：2005/06/22(水) 21:11:00

お前らがトリッキーとか言ってる間に俺は既にトレッキー。
まぁ、お前らはゆっくりトロッキー辺りを目指せってことだな。

120 ：デフォルトの名無しさん：2005/06/22(水) 21:11:08

じゃあエキセントリック

121 ：デフォルトの名無しさん：2005/06/22(水) 21:28:48

結局アンチに正確な反証挙げられる奴はいなかったわけか

122 ：デフォルトの名無しさん：2005/06/22(水) 21:37:08

>>121
>>25の方法って普通のオブジェクト指向でしょ
デザパタ使ってる人ってこれのどの課程でデザパタを使うの？

123 ：デフォルトの名無しさん：2005/06/22(水) 21:39:05

一応これも貼っとこう
>>25への反論

1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
　　オブジェクト指向では不完全な表現しか得られない事象の例：
　　　多重継承、
　　　　時間的な状態変化、
　　　　etc.

　　一般的に、不充分な表現しか得られない事象の例：
　　　　非常に複雑な対象物/概念
　　　　計算不可能な対象物/概念、
　　　　記述不可能な対象物/概念
　　　　etc.

　　もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
　　大半の科学者は仕事をする必要がなくなる。
　　(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)

2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
　　対象物をそのまま記述するのではなく、
　　特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
　　要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。

　　抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
　　それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。

3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
　　の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
　　モデリング/設計/プログラミングの中心的な作業であり、
　　そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。

124 ：デフォルトの名無しさん：2005/06/22(水) 21:47:36

>>122
「対象物の構造を～」ってことを 25 は言っているけど、その切り出し方は無数にある
(例えばオセロで審判を導入するとかしないとか。審判を導入すると双方の不正を一元監視できたり)

んで、その切り出し方の一例としてデザパタを応用するというふうに俺は使っている
(デザパタは直接使用せず、応用として。改変なしでは絶対に組み込めないし、組み込みたくない)

125 ：デフォルトの名無しさん：2005/06/22(水) 21:48:36

>>123
それはネタでしょ。

126 ：124：2005/06/22(水) 21:49:18

ちなみに、改変しても組み込めそうになかったら、その時点であきらめてますのであしからず

127 ：デフォルトの名無しさん：2005/06/22(水) 21:49:43

こんな下の方でチマチマやらずに、
上の方でどうぞ

128 ：デフォルトの名無しさん：2005/06/22(水) 21:50:32

>>125の存在が冗談

129 ：デフォルトの名無しさん：2005/06/22(水) 21:50:38

>>124
具体的にどうやって使うの？
パターンに当てはめる方法でいいの？

130 ：124：2005/06/22(水) 21:55:55

>>129
当てはめはしない

俺が考えた構造と、デザパタで提示されている構造が一致したら「お？このまま行っても平気か？」って思ってる
ついでに、提示された構造を参考に、幾らか修正を入れる

要は、どんな下らない物でも良いから、自分の考えを支持してくれる物があれば良いんだな俺の場合

131 ：デフォルトの名無しさん：2005/06/22(水) 21:59:02 BE:379290896-

>>130
デザインパターンの本来の目的からは外れてる気がするが（ﾟεﾟ）ｷﾆｼﾅｲ

132 ：デフォルトの名無しさん：2005/06/22(水) 22:08:06

>>124
何処に石を置けるのか知らなければ、審判はジャッジできない。
何処に石を置けるのか知らなければ、CPプレーヤーは戦略を立てられない。
石を置くとボードがどう変化するのかを知らなければ、審判はジャッジできない。
石を置くとボードがどう変化するのかを知らなければ、CPプレーヤーは戦略を立てられない。
さて、どうしましょう？と、>>124に話を振るのは筋違いだな。

さて、どうしましょう？
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向と主張してた貴方！
上記の主張を前提に、クラス設計してみてちょいよ。

133 ：124：2005/06/22(水) 22:18:31

>>132
いや、だから、対象物の切り出し方は無数にあるって例を出しただけで……
(審判は思いつき。妥当かどうかは考えてない。ちなみに、俺は大抵ボードが制約を持つように組んでる)

答えは無数にある。どれも正解かもしれないし、どれも不正解かもしれない。

134 ：デフォルトの名無しさん：2005/06/22(水) 22:18:42

>>130
どうせ修正するなら、当てはめたほうが早いのではないでしょうか？

135 ：124：2005/06/22(水) 22:22:23

>>134
正直速くない。部分的に一致させる事もあるけど、
サンプルで提示されている構造の使用価値はサンプルで提示されている程度のレベルでしかないと思っているし

ガチガチに当てはめると融通が利かない。妥協が必要

136 ：デフォルトの名無しさん：2005/06/22(水) 22:24:58

デザインパターンは

「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていたあれですね。あの方法で組めばいいんですね」

というまどろっこしい会話を

「それsingletonね」
「はい」

というシンプルな会話にするためにあるのよ

137 ：デフォルトの名無しさん：2005/06/22(水) 22:28:07

>>136
「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていた Singleton ですね。あの方法で組めばいいんですね」

138 ：デフォルトの名無しさん：2005/06/22(水) 22:41:43

>>136
１人のときは、全く役に立たないのでしょうか？

139 ：デフォルトの名無しさん：2005/06/22(水) 22:57:29

>>136-137
かつて２ちゃんの粘着くんの議論を終結させるために、
そーゆー一見もっともそうな説明をした事がある。

で、同じ話を何回書き込んだら気が済むの？

140 ：デフォルトの名無しさん：2005/06/22(水) 23:00:09

アンチが何か具体的な事を書くまでマターリ待とう。
オブジェクト指向だの設計だのって、結局は具体的な事が言えない
から逃げる為の口上に使ってるだけじゃん。

141 ：デフォルトの名無しさん：2005/06/22(水) 23:09:37

>>140
この人のあいかわらずソースを求める姿勢はどうにかならないものだろうかｗ

142 ：デフォルトの名無しさん：2005/06/22(水) 23:09:55

ウンコだかウンチだか知らないが、
煽り好きの>>140みたいなのは、リアルには付き合いたくない。

143 ：デフォルトの名無しさん：2005/06/22(水) 23:12:27

>>141もウンコ

144 ：デフォルトの名無しさん：2005/06/22(水) 23:13:58

この人がどの人か知らないが、俺はソースなんて求めてない。
具体的な何かでいい。とりあえず、上で出てるクラス設計なんてどう？
てか、言い訳多すぎ。

145 ：デフォルトの名無しさん：2005/06/22(水) 23:33:13

クラス図出せよ。

146 ：デフォルトの名無しさん：2005/06/22(水) 23:36:38

>>132
　俺はこの件に関して傍観者だが、
　>>132の問題設定が問題の体を為していないのと、
　せっかく>>123に挙げた矛盾点を取り込んでいないあたりに、
　そこはかとなく素人臭さを感じた

147 ：デフォルトの名無しさん：2005/06/22(水) 23:38:51

>>146
　俺もこの件に関して傍観者だが、
　具体性がないところにいつものアンチ臭さを感じた

148 ：デフォルトの名無しさん：2005/06/22(水) 23:55:48

>>144-145は、問題設定を明確にした上で、課題を出した方がいい。
　このままだとアンチの自作自演と疑われて縞馬
　

149 ：デフォルトの名無しさん：2005/06/23(木) 00:01:13

では、僭越ながらｵﾚ様が課題をだしますよ。

Ｑ１．オセロを構成するのに必要なクラスを列挙せよ。
Ｑ２．Ｑ１で列挙した各クラスの役割について簡素に説明せよ。
Ｑ３．Ｑ１で列挙した各クラス間の関係(接続)について簡素に説明せよ。

150 ：デフォルトの名無しさん：2005/06/23(木) 00:04:29

>>136-137
>>111が例示してくれたように、デザインパターンのGoFカタログは
致命的なんだよ。
「SINGLETONパターンで、」と会話が成立してる*つもり*になって
いて、片方は、スレッーフなカスタマイズSINGLETONを話し、
片方は、GoFベースのSINGLETONで話てたらOUTなんだから。

GoFのカタログを、バイブルのように使うのは、危険なんだよ。
使い方としては、アルゴリズム集みたいなイメージで使うべき
なんだよ。

151 ：いつものアンチ：2005/06/23(木) 00:06:37

>>146
>>123は何がいいたいのかわからない。

>1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
の理由が
>オブジェクト指向では不完全な表現しか得られない事象の例：
> ～略～
>　　(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
なんだろうけど。
これは一体何がいいたいのかわからない。
とりあえず、手当たり次第レスつけると。
>オブジェクト指向では不完全な表現しか得られない事象の例
って書いてあるけど。
なんでここで「多重継承」なの？（このへんでもう相手にしなくていいかなーって思った）
多重継承を表現するって聞いた事ないんだけど。説明キボン。
んで次に書いてあるのが「時間的な状態変化」だけど。
なにこれ？意味がわからない。何がいいたいの？説明キボン。
で
>一般的に、不充分な表現しか得られない事象の例：
って書いてあるけど。
>非常に複雑な対象物/概念
どこまで複雑なのかは知らんけど根気よくやればできるんじゃない？
これはオブジェクト指向に限って表現できないものなのかなー。
>計算不可能な対象物/概念、
>記述不可能な対象物/概念
って書いてあるけど意味不明説明キボン。
ここでは１だけをとりあげたけど２と３なんて宇宙人の文でも読んでるのかと思った。ので意味不明。レス不能。

152 ：デフォルトの名無しさん：2005/06/23(木) 00:08:16

>>150
共有メモリアクセスの排他制御が必要だっつう
ハードウェア・アーキテクチャ依存の御託はもう判ってるから、
さっさと>>149に応えたらどうかね

153 ：デフォルトの名無しさん：2005/06/23(木) 00:09:15

>>151
キミの頭が未開拓なのはよく判ったから、
さっさと>>149に応えたらどうかね

154 ：デフォルトの名無しさん：2005/06/23(木) 00:12:35

>>153
やだよ。
だってそいつなんだかんだいってソースコードくれくれいってるのみえみえじゃん。
関わるとソース出さないとわめきたてるからレスつけない方がいいよ。
オブジェクト指向での設計からソースまでもってけないだけだろそいつは。
単純にクンフーが足りないｗ

155 ：デフォルトの名無しさん：2005/06/23(木) 00:13:39

クラス図出せ

156 ：デフォルトの名無しさん：2005/06/23(木) 00:16:37

ソースなんかいらないから、言語依存しないクラス図を出せよ。

157 ：デフォルトの名無しさん：2005/06/23(木) 00:31:25

また逃げたｗ

158 ：デフォルトの名無しさん：2005/06/23(木) 00:37:08

>>157
自作自演はバレてるから、さっさと>>149のクラス図出せ

159 ：デフォルトの名無しさん：2005/06/23(木) 00:38:42

あと、シーケンス図もな。

160 ：デフォルトの名無しさん：2005/06/23(木) 00:40:41

>>159
自作自演はバレてるから、さっさと>>149のクラス図出せ

161 ：デフォルトの名無しさん：2005/06/23(木) 01:02:42

だからクレクレ厨を相手にしちゃ駄目だって。
何、あげたって結局理解できるわけないんだから。

162 ：アンチじゃない人：2005/06/23(木) 01:04:00

ってか正直、>>123は俺でもわかりません。
1番を読み終えた時点で睡魔に襲われますた。

163 ：デフォルトの名無しさん：2005/06/23(木) 01:30:50

>>161-162
バレバレの自演はいいから早く出せよ

164 ：デフォルトの名無しさん：2005/06/23(木) 01:40:37

>>163
なんのために？

165 ：デフォルトの名無しさん：2005/06/23(木) 02:00:08

誤ったデザパタ推進派が、荒らしに来てる。
いやだ、いやだ。

166 ：デフォルトの名無しさん：2005/06/23(木) 02:04:36

いやあさすが隔離スレらしい展開だな(w

荒らしも糞も無いだろ
隔離スレにマトモな議論期待するなって

167 ：デフォルトの名無しさん：2005/06/23(木) 08:36:26

アンチの特徴：具体例を求めるとキレる
「デザパタってトリッキーだよな」
「どのへんが？」
「ﾑｷｰ！！！あ；ｄｌふぃうえあ；ｋじゃ；」

「オブジェクト指向がわかってればデザパタなんか設計に使わない」
「じゃあ○○をデザパタ使わずにどう設計する？」
「ぎえいぎえが；おい」

168 ：デフォルトの名無しさん：2005/06/23(木) 10:11:02

>>164-165
本当に言い訳がましいなｗ

169 ：デフォルトの名無しさん：2005/06/23(木) 12:32:12

お前ら空っぽの引き出しを何時まで弄ってるつもりだ？
もう完全スルーでいいだろ？

それはそれとして、このスレを何か有効に使う手はないものか？

170 ：デフォルトの名無しさん：2005/06/23(木) 13:13:42

っていうかここはもともとカラッポの引き出しを弄るスレですから

171 ：162(通りすがり)：2005/06/23(木) 14:24:13

>>163
自作自演じゃねーし。
>>123はごめん。素で意味不明。もっと文章力を付けてください。
で。オセロのクラス図？ごめｗｗｗｗダリｗｗｗｗｗ

172 ：デフォルトの名無しさん：2005/06/23(木) 16:08:16

デザインパターンを貶しておきながら具体的な話からとことん逃げ続けるアンチでありました

173 ：デフォルトの名無しさん：2005/06/23(木) 19:19:58

>>169
【デザパタ嵌り道】こんな失敗しますたスレヽ(`Д´)ﾉｳﾜｧｧﾝ【失敗談】
というのはどうか？

174 ：デフォルトの名無しさん：2005/06/23(木) 21:05:03

まぁ大体理解できてないか適用するパターンを間違えた例がでて終わりだろ

175 ：16：2005/06/23(木) 21:50:37

相変わらずちょっと空けるとずいぶん流れてるなー。このスレ。
あらかじめ断わっとくと、間違ってもソースコードはいらないから。

じゃあインベーダーの話をしよう。

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

でさ、まず自機、敵、弾のオブジェクト（クラス）を作るじゃん。

１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？

でさ、１と２って同じ処理だよね。やってることは。
どういう風に設計・実装するのか知りたいわけですよ。俺は。

俺がやるならどうやってもデザインパターンを使わずには作れないから。
っていうより、俺の能力じゃあ、どう書いても、誰かがこれはデザインパターンでいうなんとかパターンっていうものですよ。って言うだろう。俺がそのパターン名を知らなかったとしてもさ。

176 ：デフォルトの名無しさん：2005/06/23(木) 21:55:29

抽象クラス「キャラ」から「自機」と「敵」を継承させて
HitTest()は「キャラ」に実装するのが普通でしょう。

そのレベルではデザパタは別に関係ないし、例として適切じゃない気がするが。

177 ：デフォルトの名無しさん：2005/06/23(木) 22:10:50

つうかなんでいつも例がゲームなんだよ
中学生かよ

178 ：デフォルトの名無しさん：2005/06/23(木) 22:12:38

懐かしの「オブジェクト指向は戦場では必要無し」スレの
香りのするスレはここですか？

179 ：デフォルトの名無しさん：2005/06/23(木) 22:13:56

しかもまた「オセロ」でも書いて説明しるって言ってるし。
オマイたちは本当に進歩しませんね。

180 ：デフォルトの名無しさん：2005/06/23(木) 22:29:20

>>176
で、弾もあるよね。自分も敵も弾もそれぞれ座標（現在地）持ってるよね。
自分オブジェクトは１個かもしれないけど敵とか弾はたくさんオブジェクトがあるよね。
やっぱりループで回すよね。
ここまででデザパタは１つも出てこないのか？

>>177
じゃあ代わりに適切な例を上げて。

181 ：デフォルトの名無しさん：2005/06/23(木) 22:32:32

ゲームならオブジェクト指向でほぼOKでしょ。
俺が知りたいのはJ2EEアプリをJ2EEパターンを使わないで
アンチの主張する「オブジェクト指向設計」のみでどうやるのかに興味がある。
どんなに素晴らしいモノなのか、教えてもらいたいものだよ。
本当にできるならねｗ

182 ：デフォルトの名無しさん：2005/06/23(木) 22:41:18

>>180
「弾」も「キャラ」から派生させれば問題なかろ。

もう少し条件つけんとCompositeだのFlyweightだのは出てこんぞ。

183 ：デフォルトの名無しさん：2005/06/23(木) 22:43:44

そういえば彼はJ2EEの話に対して１回「出来る」ってレス返しただけであとは完全スルーだったな

184 ：デフォルトの名無しさん：2005/06/23(木) 22:48:02

仕事した事ないんだろ

185 ：デフォルトの名無しさん：2005/06/23(木) 22:50:33

J2EEアプリであるための条件って何なんだ？
helloworld.jsp
だけでいいんなら、別にパターンいらないぞ

186 ：デフォルトの名無しさん：2005/06/23(木) 23:14:01

>>181
前提が間違ってる。
崇高なオブジェクト指向を信奉する彼は邪悪なJ2EEなんて使わない。
彼なら最初にAPサーバを書くところから始めるに違いないｗ

187 ：デフォルトの名無しさん：2005/06/23(木) 23:41:58

>>186
だよな。「Servlet」というフレームワークや実装パターンのカタマリみたいな
プラットフォームは拒否るだろうからね。

188 ：デフォルトの名無しさん：2005/06/24(金) 00:25:49

今のところ肯定派の圧勝か。。

189 ：デフォルトの名無しさん：2005/06/24(金) 00:39:14

アンチは理想論ばかり振りかざして具体例をまったく出せていないからね。

190 ：いつものアンチ：2005/06/24(金) 01:03:27

奇跡だ！
まともな質問が！

>>175
>１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>
>でさ、１と２って同じ処理だよね。やってることは。
>どういう風に設計・実装するのか知りたいわけですよ。俺は。
これはオブジェクト指向で設計をしていれば、
オブジェクトの抽出のときに自機と敵が存在するフィールド（シーンのがいい？）のようなものができると思うから
そこに処理をかけばいいと思うよ。（なければフィールドクラスを作る。）
そのフィールドでの出来事だしね。

191 ：デフォルトの名無しさん：2005/06/24(金) 02:03:47

>>190
その"フィールド"をメディエイターとしてするのかな？

あと、敵キャラの動きとかはストラテジーパターンで表現できそうだ。

あと「スコアカウンタ」から「敵オブジェクト」を
オブザーバーパターンを使って監視しておけば
得点の加算ができそうだね。

192 ：デフォルトの名無しさん：2005/06/24(金) 04:04:33

お前らシングルトンも知らないのｗ
死ねば？

193 ：デフォルトの名無しさん：2005/06/24(金) 07:07:21

>>191
>あと「スコアカウンタ」から「敵オブジェクト」を
>オブザーバーパターンを使って監視しておけば
>得点の加算ができそうだね。
ん？これは何をやってるの？
もし、クラスのインスタンスの数を数えてシステムに反映させているなら
設計が悪いと思う。

194 ：デフォルトの名無しさん：2005/06/24(金) 10:28:59

>>191
アンチの人にパターン名で解説しても話が通じんだろ。

>>193
「スコアカウンタ」のインスタンスが一つあって、
敵オブジェクト一つ一つにその「スコアカウンタ」のインスタンスを持たせておいて、
敵オブジェクト自身が死んだときに「スコアカウンタ」に点数を報告するって方法では？
設計悪いかな？漏れはまあいいんじゃないかなと思うけど。

195 ：デフォルトの名無しさん：2005/06/24(金) 10:46:38

課題のインベーダー程度ならともかく
複数人同時プレーやもうすこし複雑なスコアシステムや設定によるスコアシステム自体の切り替えなどを考えると
シングルトンのスコアシステムに必要そうな情報全てを付加したスコア発生メッセージを通知するのがベター
嫌な設計だが

196 ：デフォルトの名無しさん：2005/06/24(金) 10:49:06

細かいところは分からないけど、全体的にMVCっぽくなりそうな...

197 ：194：2005/06/24(金) 11:30:53

>>195
複雑なスコアシステムだったとしても、
オブザーバに報告する内容をすこし増やせばいいんでない？
シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。

198 ：デフォルトの名無しさん：2005/06/24(金) 21:25:27

>>194
>敵オブジェクト自身が死んだときに
ゲームだとこの死んだときってのが微妙でね。
オブジェクト自身が本当に消滅したときなのか、
敵が死体で転がってる状態なのか、ってのは微妙でしょ。

だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の
プログラムはちょっと気を付けてみることにしてるｗ

もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
俺の環境だと即組み直しｗ
まあ、将来の為。

あ、これはデザパタとかオブジェクト指向とか関係無いから。

199 ：デフォルトの名無しさん：2005/06/24(金) 22:33:12

> 部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
意味不明。

200 ：デフォルトの名無しさん：2005/06/24(金) 22:58:38

>>199
そのままの意味だけど？
これ以上詳しくはできない。

201 ：デフォルトの名無しさん：2005/06/24(金) 23:05:28

単に死体になってるだけ＝ただの状態変化
実際にゲームから消滅した＝オブジェクトの消滅

として設計され、管理されているなら
> インスタンスの消滅を見てゲームを動かし
ていても問題ないのでは？

202 ：デフォルトの名無しさん：2005/06/24(金) 23:06:02

SE にとって重要な能力の一つは自分の考えを簡潔かつ適切に他人に伝えるだと思う

203 ：デフォルトの名無しさん：2005/06/24(金) 23:07:08

>>202
違うな。
どんな人間にも平気で嘘がつける度胸だ。

204 ：デフォルトの名無しさん：2005/06/24(金) 23:08:52

>>201
それが駄目なことについて延々と語るつもりは無いな。
いいと思うなら自由にやってくれ。

205 ：デフォルトの名無しさん：2005/06/24(金) 23:09:46

平気で嘘がつける = 適切に

206 ：デフォルトの名無しさん：2005/06/24(金) 23:10:32

SEなんて日本だけの腐れ職業のことなんざどうでもいいよ

207 ：デフォルトの名無しさん：2005/06/24(金) 23:11:14

またゲームかよおまえら
ゲームつくるのにデザパタはたいしていらんぞ

208 ：デフォルトの名無しさん：2005/06/24(金) 23:12:22 BE:393339078-

平気で嘘をつけない奴のほうが稀な気が。

209 ：デフォルトの名無しさん：2005/06/24(金) 23:13:26

そうだな日本は偽装派遣天国だしな

まあ面接でちゃんと問い詰めればすぐバレるけどな
問い詰めちゃいかんらしい

210 ：デフォルトの名無しさん：2005/06/24(金) 23:14:51

>>201
ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する（したように見える）バグがでるに一票。
危険な道は避ける。
これがわからない人間にゲームプログラマは難しい。

211 ：デフォルトの名無しさん：2005/06/24(金) 23:17:34

>>210
それはメモリ管理が出来ていないと言っているに等しいと思うんだが....

212 ：デフォルトの名無しさん：2005/06/24(金) 23:22:40

>>211
メモリの管理はできてるでしょ。
メモリは破壊していないし、はみ出してもいない。
ただ、ポインタを使いまわしてしまっただけの話さ。
まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。
鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、
就業規則に書いておけば自分の責任にならなくて済むと思うよ。

213 ：デフォルトの名無しさん：2005/06/24(金) 23:24:05

>>194
ん～、結局同じな気がする。
一瞬、変更に対して強いかな？とも思ったんだけど、「必要そうな情報」に幅がないし
幅を出すと結局変更が両者に及ぶから変わらない。
キャラクタ→スコアシステム#update→キャラクタ#getScore
これ以外の流れというのがちょっと見えてこない。

>>197
元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・
シングルトンをファクトリに生成させるパターンなら切り替えは可。
ScoreSystem scoreSystem = new ScoreSystemFactory(設定)
もう常套句すぎてアレなんだけど、こんな感じ。

214 ：デフォルトの名無しさん：2005/06/24(金) 23:35:04 BE:568936499-

Factoryをnewするのか？(･∀･)ﾆﾔﾆﾔ

隔離スレがパターンの話題で盛り上がって
本スレがスレッドストップとはこれいかに。（ﾟεﾟ）ｷﾆｼﾅｲけどな。

215 ：デフォルトの名無しさん：2005/06/24(金) 23:35:56

>>212
それは、ダングリングポインタを参照してしまったということだから、
広義ではメモリ管理が出来ていないに等しいと思う。
本来、誰かが使っているならそのポインタは削除してはいけない。

ま、それを完全に保証することはしばしば非常に困難であったり
不可能であったりするのは事実だが

216 ：デフォルトの名無しさん：2005/06/24(金) 23:38:44

メモリ管理できてねぇだけじゃん
インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる

217 ：デフォルトの名無しさん：2005/06/24(金) 23:40:13

>>214
あっ！orz
うるせ～、超省略表記なんだよヽ(`Д´)ﾉｳﾜｧｧﾝ

218 ：デフォルトの名無しさん：2005/06/24(金) 23:40:14

>>216
でも、この場合は誰の責任になるの？
敵クラス？敵管理クラス？メモリ管理クラス？

219 ：デフォルトの名無しさん：2005/06/24(金) 23:42:05

>>215
でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。

220 ：デフォルトの名無しさん：2005/06/24(金) 23:42:38 BE:505721489-

ところで複雑なスコアシステムってどんなのがあるの？
あんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。

221 ：デフォルトの名無しさん：2005/06/24(金) 23:45:10

>>219
いや、それはいいすぎ....
まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは
確かだが、常にそうだというわけではないし、参照カウンタで済む場合は
それを使うという手もある。

222 ：デフォルトの名無しさん：2005/06/24(金) 23:45:12

ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない
ゲームタスクのループ内で自機が参照してるかも知れないし
他の敵も参照してるかもしれない
敵キャラに消滅フラグなりなんなり持たせて
ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする

ってデザパタ関係ないな

223 ：デフォルトの名無しさん：2005/06/24(金) 23:45:31

ボーリングは少しメンドイ。
マージャンとかかな。

224 ：222：2005/06/24(金) 23:45:54

>>220

225 ：223：2005/06/24(金) 23:46:46

222すまん、ﾚｽつくの速すぎて慌てた。
>>220

226 ：デフォルトの名無しさん：2005/06/24(金) 23:49:47

>>221
でも本音ではしっかりステータス管理してもらったほうがいいでしょ。
よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。

227 ：デフォルトの名無しさん：2005/06/24(金) 23:52:12

>>226
なぜだッ！！
なぜ貴様に俺の心が読み取れるんだッ！！！

228 ：デフォルトの名無しさん：2005/06/24(金) 23:52:25

>>223
マージャンとインベーダーの間で再利用するの？
されは流石に無理ないか？

229 ：デフォルトの名無しさん：2005/06/24(金) 23:55:43 BE:442506097-

>>223
あぁ、なるほど。

敵の消滅とかの話が出てたから、
シューティングっぽいゲームばかりを想像していたヨ。

>>228
マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。
なので切り替えられると便利かもしれない。

230 ：デフォルトの名無しさん：2005/06/24(金) 23:56:50 BE:168574346-

さすがに異種ゲームの点数計算クラスを共有しようとは誰も考えないと思うので。

231 ：デフォルトの名無しさん：2005/06/25(土) 00:16:23

>>214
相変わらず僻みっぽい馬鹿だな。
とりあえず
http://pc8.2ch.net/test/read.cgi/tech/1119158274/14-15
のリンク先くらい読んでから煽れクズ

232 ：デフォルトの名無しさん：2005/06/25(土) 00:20:00

結局、>>198からの議論は、「オブジェクトを（ゲーム上）消したことに
すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」
（通常後者のほうが遅い）

ということに尽きるのかな。
一言で言えるんだから、一言で言えばいいのに。

233 ：デフォルトの名無しさん：2005/06/25(土) 00:21:35

まぁ、>>213がド素人なのは誰の目にも明らかだがなｗ
Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。
Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。

234 ：デフォルトの名無しさん：2005/06/25(土) 00:24:05

class Singleton {
　　static object m_Foo;
　　static object m_Bar;

　　static object getFoo() { return m_Foo; }
　　static object getBar() { return m_Bar; }
}

ではなぜまずいのでしょうか
getInstance()とかいちいちウザいです

235 ：デフォルトの名無しさん：2005/06/25(土) 00:30:39

スルー。

236 ：214：2005/06/25(土) 00:34:49 BE:210717465-

>>231
相変わらず汁が先走ってるな。
とりあえず >>213-214 >>217 の流れを見て
自分の過ちと傲慢さを理解して恥じろ。

237 ：デフォルトの名無しさん：2005/06/25(土) 00:36:54 BE:126431429-

>>232
注意点は一言で言えるが実装は一言で言えないぜ。

238 ：デフォルトの名無しさん：2005/06/25(土) 00:39:54

>>237
流石に実装まで示せとは誰も言ってないじゃまいか。

239 ：デフォルトの名無しさん：2005/06/25(土) 00:41:23

>>238
もう、日本は終わったんだよｗ

240 ：237：2005/06/25(土) 00:44:23 BE:505721298-

>>238
>>198-～の実装の議論は少し有意義に見えたが。

241 ：234：2005/06/25(土) 00:49:32

華麗にスルーされちゃってぼくちん少し寂しいの
てへ

242 ：デフォルトの名無しさん：2005/06/25(土) 00:53:55

>>241
俺はアンチなんだけど
それって実体はいつできるんだ？
呼び出す前からできちまってる気がしねぇ？

243 ：234：2005/06/25(土) 00:56:37

コンストラクタはstaticにすればいいんじゃまいか

つか、それだけの問題で
まいかい
Singleton timpo = Singleton.getInstance();
bokkiage = timpo.invoke();
とかやるのはいやです。

244 ：デフォルトの名無しさん：2005/06/25(土) 00:57:06

目的は「インスタンスを1つに固定する」だからいいじゃん

245 ：デフォルトの名無しさん：2005/06/25(土) 00:57:15

　華麗なる素人スレ

246 ：デフォルトの名無しさん：2005/06/25(土) 00:58:12

>>243
bokkiage = (Singleton.getInstance()).invoke();

247 ：デフォルトの名無しさん：2005/06/25(土) 00:59:32

>>234
仮想コンストラクタで検索。

一般に、クライアントコードが簡素になる点と
融通が効く点が利点して上げられてる。

248 ：デフォルトの名無しさん：2005/06/25(土) 01:00:36

>>243
それじゃおめ、
そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな？
つ逝ってよし

249 ：234：2005/06/25(土) 01:02:39

>>247
継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが
実際には、継承なんかしないクラスこそシングルトンの候補であることが
非常に多い気がします。
その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。

「クライアントコードが簡素に成る」については全く納得がいきません。
メンバがstaticであれば
(Singleton.getInstance()).invoke();
ではなく
Singleton.invoke();
と書けるでしょう。

250 ：デフォルトの名無しさん：2005/06/25(土) 01:04:50

まあ、いつみてもデザパタは役に立たないよね。

251 ：デフォルトの名無しさん：2005/06/25(土) 01:06:04

なんでSingletonの話題しか振れないの？
重箱の隅しか突付けない哀れな煽りだ

252 ：234：2005/06/25(土) 01:07:00

ぼく、あおりじゃないのに(; ;)

253 ：デフォルトの名無しさん：2005/06/25(土) 01:07:14

======================================================================
　　　　　　　　　　このスレは厨房を隔離するための隔離スレです。。。
======================================================================

254 ：デフォルトの名無しさん：2005/06/25(土) 01:07:54

>>234　→ >>243 → ぬるぽ

255 ：デフォルトの名無しさん：2005/06/25(土) 01:16:10

>>252
お前はネタｗ

256 ：デフォルトの名無しさん：2005/06/25(土) 01:20:06

>>249
インベーダーの例に戻って言うと、当初のスコアシステムに
ハイスコアの記録機能を追加した新スコアシステムを作る
場合、継承するのが妥当なんじゃない？

257 ：234：2005/06/25(土) 01:21:39

>>256
その場合、旧スコアシステムと新スコアシステムが共存しないのであれば
継承する必要は無いと考えますが。

258 ：234：2005/06/25(土) 01:22:03

>>255
ぼくでおなにーとかはしないでください
こわいので

259 ：デフォルトの名無しさん：2005/06/25(土) 01:24:55 BE:245837257-

単なる関数郡として使うだけならstaticでいいと思う。

260 ：234：2005/06/25(土) 01:26:34

>>259
それは、いわゆるUtilityクラスのような、状態の存在しないものですね。
それについて異存のあるひとはいないとおもいます。

ぼくがいっているのは、状態が存在するが、システムでユニークなクラス
のことです。とゆうか、Singletonというのは、そのようなものでしょ？

261 ：234：2005/06/25(土) 01:27:07

> システムでユニークなクラス
ちょっとはしょりすぎた

すみません、酔っているので

262 ：デフォルトの名無しさん：2005/06/25(土) 01:27:20

>>249
Foo foo = Singleton.getFoo();
Bar bar = Singleton.getBar();

Foo foo = Singleton.getInstance("Foo");
Bar bar = Singleton.getInstance("Bar");

後者の方が簡素というか、動的に生成物を変更するのが楽。

263 ：デフォルトの名無しさん：2005/06/25(土) 01:30:31

まぁ文字列渡すよりは、
・コンフィギュレーション選択用の定数か、
・コンフィギュレーションを表すオブジェクト
を渡すべき

264 ：デフォルトの名無しさん：2005/06/25(土) 01:32:54

>>260
それは「グローバル変数」だ。悪。

シングルトンでは「状態のないもの」を表現する。
たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、
「ステートパターン」で使うステートオブジェクトとか。
「ファクトリー」もそうだ。

265 ：デフォルトの名無しさん：2005/06/25(土) 01:34:21

>>257
オブザーバーパターンとのかみ合わせを考えてみて。
public class Enemy {
　addObserver(ScoreSystem ss) {}
}
↑こうなってた場合、継承が必要。

public interface Observer {}
public class Enemy {
　addObserver(Observer observer){}
}
↑こうしとかないオマイが馬鹿と言われれば、だよね～
としか言い様がない気もするが・・・・・・

266 ：234：2005/06/25(土) 01:34:27

>>254
え？
ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが
間違いですか？

なんか、ちょっとはつみみな所見です。

267 ：234：2005/06/25(土) 01:36:31

>>265
いやその、共存する必要が無いのであれば、インタフェースを変えずに
スコアシステムの「実装」を変えればいいだけなのではないかと。

なにか勘違いしていますか？ぼくは

268 ：234：2005/06/25(土) 01:37:33

>>262

それはちょっとSingletonといいつつFactory風でもありますね。
そういうニーズがある場合には、確かに意義がある気がします。

あまりそういうケースが多くは無い気はしますが。

269 ：デフォルトの名無しさん：2005/06/25(土) 01:40:49

デザパタ役に立って無いよ。
そろって馬鹿だな。
デザパタとか別にしても。

270 ：259：2005/06/25(土) 01:40:47 BE:379290896-

>>260
いまいちやりたいことが分からないなぁ…。
Singletonが1種類のオブジェクトしか返さなくて、
将来その仕様に変更がないと言い切れるなら
いっそ状態もstatic管理でいいと思う。要するにSingleton不要。

デザパタは仕様変更に柔軟に対応するための手段だと思うから。

271 ：デフォルトの名無しさん：2005/06/25(土) 01:42:57

>>264
このスレ読んでると、どんどん悪い癖、迷信に染まっていく傾向があるな。
状態はグローバル変数だから駄目？
それはあんたの信念であって、広く認められているSingletonの定義より狭いやん。
例えばアプリケーションの設定を Singletonに置くとして、
設定を変更する事は充分ありえる。つまり、Singletonに状態を持たせる事は充分有り得る。

GoF日本語版 p138
◎結果
Singletonパターンの効果を次にあげる。

1.インスタンスへのアクセスを制御する。(詳細略：唯一のインスタンスなのでアクセスチェックが簡単)
2.名前空間を減らす。Singletonパターンはグローバル変数の改良である。唯一のインスタンスを格納するグローバル変数 (注: C++, Smalltalk)を宣言する必要はなくなる。
3.オペレーションや内部表現を詳細化できる。(詳細略：Singleton のサブクラス化に関する話)
4.インスタンスの数を変えることができる。(詳細略：インスタンス数を２つ以上に変更する事も容易)
5.クラスオペレーションよりも柔軟である。(詳細略)

272 ：デフォルトの名無しさん：2005/06/25(土) 01:43:38

>>270
Visitorが状態を持たないとき、
それでもオマイさんは
Visitorをnewしますか？

273 ：234：2005/06/25(土) 01:43:59

>>270
いやその、「仕様変更」に対するデフォルトの対応が「継承」である、
というほうがぼくにとっては不自然なのですが。

たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて
両者に対応しなければならない、とかいうケースであれば、継承を
使うのは理解できます。

しかし、そもそも「唯一」であったものに、「継承」を適用するケース
って、そんなに多いのかな、と。普通、継承は、複数のものの差異を
選択的に無視したい場合に用いますよね。単純化のしすぎですが。

274 ：デフォルトの名無しさん：2005/06/25(土) 01:45:29

　　つまりさ、このスレの白熱議論っつうのは、
　　すべからく >>264みたいな素人の迷信暴言が発端なわけ。

　　くだらねぇんだよおまぃらの議論は

275 ：デフォルトの名無しさん：2005/06/25(土) 01:45:47

>>271
GoF本にはそんなこと書いてなかったけど
一体いつ定義されたの？

276 ：234：2005/06/25(土) 01:45:57

ぼくのほうが知

277 ：デフォルトの名無しさん：2005/06/25(土) 01:46:13

>>274
面白い議論ｷﾎﾞﾝ

278 ：デフォルトの名無しさん：2005/06/25(土) 01:46:26

>>275
　恥を知れクズが

279 ：234：2005/06/25(土) 01:46:38

とぎれた
ぼくのほうが素人だもん

とか書こうとしたのに

280 ：デフォルトの名無しさん：2005/06/25(土) 01:48:33

>>278
かかってこいよ厨房ｗ

281 ：デフォルトの名無しさん：2005/06/25(土) 01:48:39

>>266=>>234
おまぃは誤爆してる上、
>>234の定義で>>243するとNullPointerExceptionがおきるつう認識もない・・・
・・・Singleton書いた事あるぅ？(>>262を参照汁)

282 ：デフォルトの名無しさん：2005/06/25(土) 01:49:13

>>267
差分プログラミングと開放/閉鎖原則で検索。

283 ：デフォルトの名無しさん：2005/06/25(土) 01:49:47

>>280は底知れない白痴厨房。GoF本手元に置かずにそんな煽りやってるとは抱腹絶倒だな。

284 ：234：2005/06/25(土) 01:50:29

>>281
あ、>>234の例はただの非常に単純化した例ですので。

いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ
で行うようなクラスをSingletonの変わりにして何かまずいのか？
ということに過ぎません。

285 ：デフォルトの名無しさん：2005/06/25(土) 01:51:10

>>271の該当ページを読んでみたらぁ？

286 ：234：2005/06/25(土) 01:52:42

>>282
メイヤー先生ですか。
私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。

それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない
限り、継承してメソッドをオーバーライドするより元のメソッドそのものを
書き換えることのほうが容易であることも多い気がします。

287 ：234：2005/06/25(土) 01:53:59

実際、バージョンアップの際に常に継承で対応するという開発手法は
どれぐらい一般的なんでしょうか？

もとのクラスを書き換えるのは、邪悪？
open/close原則を厳密に適用すれば、そういうことになってしまいますね。

288 ：デフォルトの名無しさん：2005/06/25(土) 01:54:51

で？
好きにすりゃえーやん。
漏れは藻舞を説得するつもりはねぇ～し

289 ：259：2005/06/25(土) 01:55:54 BE:189645293-

>>234はSingletonにこだわらないほうがいいと思われ。
もうこれは個人個人の開発スタイルなので。

それでも共同開発時はSingletonをお勧めしたい。

290 ：デフォルトの名無しさん：2005/06/25(土) 02:00:01

>>287
アンチの俺から言わせると、
一般的なわけねーだろ。
あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。
アホだアホ。マジで救いようがねー。

291 ：デフォルトの名無しさん：2005/06/25(土) 02:03:49

哀れなもんだ
煽れる時に煽るだけで、
中身は空っぽだもんな、おまえ

292 ：デフォルトの名無しさん：2005/06/25(土) 02:04:28

>>268
仮想コンストラクタはファクトリとシングルトンの合わせ技だから

ニーズは普通にあると思うよ。
オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ？

293 ：234：2005/06/25(土) 02:04:40

ぼくは、あおりじゃないんだもん(; ;)

294 ：デフォルトの名無しさん：2005/06/25(土) 02:05:42

>>291
オマエモナーｗ

295 ：デフォルトの名無しさん：2005/06/25(土) 02:06:35

>>284
1つのクラスが複数のstaticメンバ変数を管理するのはいくない。

296 ：234：2005/06/25(土) 02:07:54

>>292
ニーズは、あるでしょうね。
ぼくは、実はSingletonでなくていいのに
「いまどきSingletonじゃないと、女のコにモテないぞ」
「グローバル変数はダサ！Bjarne stroustrupが何と言おうと絞め殺せ」
「static記憶クラス？そんなん、石器時代の遺物でしょ？」

とかそんな理由でSingletonにされているケースも、結構おおいんじゃないの？

と、そういいたかっただけです。

297 ：234：2005/06/25(土) 02:08:21

>>295
それは、なぜでしょうか。

298 ：デフォルトの名無しさん：2005/06/25(土) 02:08:44

>>291
文体と主張だけで彼は特定できる。
だから、スルーして淡々と進めてるだろ？お前さんもスルーするよろし。

299 ：デフォルトの名無しさん：2005/06/25(土) 02:10:45

デザパタ信者は巣に帰れよ。
http://pc8.2ch.net/test/read.cgi/tech/1119158274/l50

ここでデザパタを使う前提の話をするな。
ここはデザパタの存在の可否を決めるスレだ。

＃大体、デザパタなんて誰も使ってないんだから過疎スレで
＃まとまってろってのｗ
＃アンチをこっちに隔離したとかほざいてたくせにアンチ追い出したら
＃ただの過疎スレになってやんのｗバーカｗ

300 ：デフォルトの名無しさん：2005/06/25(土) 02:11:45

>>298
ここじゃ荒らしはお前の方なのｗ
わかったらさっさと過疎スレ帰れよｗ

301 ：デフォルトの名無しさん：2005/06/25(土) 02:12:20

>>297
クラスの役割が訳わかんなくなるから。

302 ：デフォルトの名無しさん：2005/06/25(土) 02:13:14

>>299-300
哀れな奴

303 ：デフォルトの名無しさん：2005/06/25(土) 02:13:38

>>302
ヒント：スルー

304 ：デフォルトの名無しさん：2005/06/25(土) 02:14:54

>>302-303
本気で帰ってよ。
デザパタ語るなら向こうが本スレだからｗ

305 ：234：2005/06/25(土) 02:15:01

>>301
ぼくは頭が悪いので、やはりそれでは理解できませんね。

確かに全てをstaticで実装すれば、クラスはただのグローバル変数＋関数と
それをつつむnamespaceに同等のものになるでしょう。

で、それが何か問題なのですか？

306 ：デフォルトの名無しさん：2005/06/25(土) 02:16:01

>>305
>何か問題なのですか？
だからここはデザパタの可否を決めるスレだっつってんだろ！
荒らしが！

307 ：デフォルトの名無しさん：2005/06/25(土) 02:18:16

>>305
だいたい、何、頭に血上らせて必死におばかな議論してんだ、厨房。
グローバル変数を１つも使わないプログラムとかみたことないのか？
使ってる時点でレベル低すぎだってのにいらいらすんだよ。
お前みたいな馬鹿みてると。

308 ：デフォルトの名無しさん：2005/06/25(土) 02:18:25

>>296の発言で、もう>>234はネタ決定だな。
わざわざSingletonが当てはまらない想定を持ち出して煽ってるんだから、
別にSingleton勧めるいわれはないじゃん。

>>234もそろそろ初心者プログラミング相談室にでも相談してみたらどう？

309 ：234：2005/06/25(土) 02:19:24

>>295さんの主張で一番よく分からないのは、
「1コのstaticメンバならOKだが、複数だとNGになる」
という理由です。

そこのところをもう少し分かりやすく説明していただけませんか。
寡聞にして聞いたことの無い主張なものですから。

310 ：デフォルトの名無しさん：2005/06/25(土) 02:19:33

>>307も変な奴だな。
Singletonはグローバル変数の代わりをスコープに入れている。
つか、Javaじゃグローバル変数なんてないし。

311 ：デフォルトの名無しさん：2005/06/25(土) 02:19:46

>>305
そういうことすると、そのクラスが何してるか（何を管理しているクラスなのか）、
後から見た人はわかんないでしょ。コード追っていかないと。
だからクラスの役割ははっきりさせる必要がある。

312 ：デフォルトの名無しさん：2005/06/25(土) 02:19:53

>>287
利点もあるし、難点もあるな＞継承
Javaなんかだと、最近は継承よりも委譲とインターフェイスを
優先する風潮がある。

ソースの書き換えは、規模が大きくなると変更が他の部分に
影響を与えてドタドタドタっとドミノ倒しになる事がある。
それじゃあ継承ならそうならないかって言うと、まぁそうとも言
い切れんわけだが・・・・・・
まっ、それでinterfaceを多用する風潮が生まれたんだろう。
これならインターフェイスのみを残して新しく書き起こす場合
でも、継承を利用する場合でも、変更部分を局所化できる。

313 ：234：2005/06/25(土) 02:20:50

>>308
いやその、パラメタライズされていないgetInstance()を使う
Singletonの例は多いと思うのですが。
パラメタライズされている場合については、了解しました
と言っておきましょう。

314 ：デフォルトの名無しさん：2005/06/25(土) 02:21:03

>>312
＞Javaなんかだと、最近は継承よりも委譲とインターフェイスを
＞優先する風潮がある。

Java「なんかだと最近」？はぁ？
最初っからそうだよ厨房

315 ：デフォルトの名無しさん：2005/06/25(土) 02:21:24

>>310
はぁ？デザパタ信者ってのは、
グローバル変数の何がまずいのか知らないのか？
アホだな。レベルが低すぎる。
もうちょっと勉強してきてくださいよｗ

316 ：234：2005/06/25(土) 02:22:28

>>311
>>309に答えていただけませんか。やはりよくわからないんですが。
なぜstatic変数が吹く数字なると
「後から見た人はわかんない」ようになるのか。

317 ：デフォルトの名無しさん：2005/06/25(土) 02:23:05

語尾ダブリューの人、なんか話題がtoo oldで哀れ

318 ：デフォルトの名無しさん：2005/06/25(土) 02:24:00

>>316
俺も聞いておきたい。つか、ネタかローカルルールだと思っている。

319 ：デフォルトの名無しさん：2005/06/25(土) 02:24:11

>>311が逃げてるのがよくわかるなｗ
ほら、本スレに逃げ込めよｗ

320 ：234：2005/06/25(土) 02:24:23

>>312
ぼくがinterfaceに対するプログラミングの一番の恩恵を認識したのは
実はC++のリンク互換性なんですがね。

COMの発想のベースはそこにあります。大変汚いものですが。

321 ：デフォルトの名無しさん：2005/06/25(土) 02:25:20

なんかかなりネタ臭いスレになってきたな。

322 ：デフォルトの名無しさん：2005/06/25(土) 02:26:15

>>321
お前は速く>>309の質問に答えてやれよｗ

323 ：デフォルトの名無しさん：2005/06/25(土) 02:26:57

>>311, >>316
実は、Singletonってインスタンスが２つ以上あってもいいんだよね。
つか２つ以上生成した時点で、狭義のSingletonとは見なされない傾向があるが。
例えば某所で話題になっていたInstance PoolとかConnection Poolみたいなパターンになっちまう。

324 ：デフォルトの名無しさん：2005/06/25(土) 02:27:55

>>323
だからどうしたんだよ。余計なレスつけんなアホ。

325 ：234：2005/06/25(土) 02:28:33

>>323
Poolのようなものならば、PoolManagerが欲しい気がしますね。Singletonの。

326 ：デフォルトの名無しさん：2005/06/25(土) 02:31:24

>>325
お。冴えてるやん。
すると、ダンマリ決め込んでる>>311が回答すべき内容が見えてくる・・・はず・・・なんだが・・・なんともはや

327 ：デフォルトの名無しさん：2005/06/25(土) 02:32:05

＞static変数が
デザパタとか関係なく好き嫌いの問題でしょ、単に。
漏れは嫌だけど。
↓こんなコード書いてくるチームメンバがいたらはったおしてやるけどね。

class Sigleton
{
　private static Object A;
　private static Object B;
　・・・
　private static Object Z;

　static{
　　A = new Object();
　　B = new Object();
　　・・・
　　Z = new Object();
　}

　static public Object getA(){ return A;}
　static public Object getB(){ return B;}
　・・・
　static public Object getZ(){ return Z;}
}

328 ：デフォルトの名無しさん：2005/06/25(土) 02:32:55

一向にまとまる気配が無いよ＞デザパタ
こんなのがコミュニケーションツールでいいんですか？＞デザパタ
人によって使い方違ってるじゃないですか？＞デザパタ
職場でもこんな戦いをしなきゃいけないんですか？＞デザパタ

329 ：326：2005/06/25(土) 02:33:17

あぁーあ。せっかく回答が見えかけた(つか見えた)のに、
また訳わかんない主張系の人が、ｽﾚを混沌に導く・・・・・・もう飽きたから寝る。

330 ：デフォルトの名無しさん：2005/06/25(土) 02:33:49

>>327
つか、マジで本スレ帰れってｗ

331 ：デフォルトの名無しさん：2005/06/25(土) 02:34:50

>>329
　お　れ　の　せ　い　に　な　る　の　は　な　に　か　ち　が　う　き　が　す　る　！　（笑）

332 ：234：2005/06/25(土) 02:40:17

>>327
ただの好き嫌いの問題であれば、ぼくの>>296の主張はあながち
ウソでもなかったようですね。

ちなみにそれによっていちいちgetInstance()を書かなければならないことを
あなたは面倒であると考えたことはないのでしょうか？

333 ：259：2005/06/25(土) 02:41:23 BE:189645293-

>>329
何に対する回答だ？？回答以前に問題が明確でないんだよ。論点あちこち行ってるじゃん。

334 ：デフォルトの名無しさん：2005/06/25(土) 02:42:40

こっちの方が盛り上がってるのがウケル。
こっちをデザパタスレにしようよ。

335 ：寝ぼけまなこでレス：2005/06/25(土) 02:44:06

>>333
　>>311

336 ：寝ぼけまなこでレス：2005/06/25(土) 02:45:15

>>334
　偽デザパタｽﾚ

337 ：寝ぼけまなこでレス：2005/06/25(土) 02:49:49

338 ：デフォルトの名無しさん：2005/06/25(土) 02:51:09

厨房の行動パターン
・メール欄に文章

339 ：259：2005/06/25(土) 02:51:15 BE:224765748-

>>335
static管理したらクラスの役目がわかりにくくなるって？
インターフェースが同じなら変わらないだろ。論点にもなりゃしないさ。

340 ：：2005/06/25(土) 02:52:01

341 ：259：2005/06/25(土) 02:53:01 BE:189645293-

ム板にもIDｷﾎﾞﾝﾇ

342 ：デフォルトの名無しさん：2005/06/25(土) 02:53:21

>>339
　>>323, >>325-326

343 ：デフォルトの名無しさん：2005/06/25(土) 02:54:48

>341
お前そんなんだからいつまでたっても0ポイントなんだよ。

344 ：デフォルトの名無しさん：2005/06/25(土) 02:55:58

で、アンチの反証は？

345 ：334：2005/06/25(土) 02:56:29

シングルトンで盛り上がってるのね。
↓static的としてこうするのがいいのか
Singleton.invoke();
↓シングルトン的にこうするのがいいのか
Singleton s = Singleton.getInstance();
s.invoke();
って話ね。

正直、シングルトンだとインスタンスを途中でいじれるぐらいしかメリットないんじゃないかな。
↓例えば、デコレータでシングルトンのインスタンスにちょっと加工するとか、
Singleton s = Singleton.getInstance();
s = new TuikaKinouSingleten(s);
// なにか処理～
s.invoke();
// なにか処理～

↓または途中で中身すり替えをするとか。
Singleton s = Singleton.getInstance();
s = new TestYouSingleten(s);
// なにか処理～
s.invoke();
// なにか処理～

staticだとそれができなくなるぐらいではないだろうか。
まあ個人の好みで使い分ければよいのではないかと。

346 ：デフォルトの名無しさん：2005/06/25(土) 02:58:56

>>345　GJ.

347 ：デフォルトの名無しさん：2005/06/25(土) 03:00:55

>>334
だからデザパタスレなんて本来はその存在の可否に関する
議論の方がもりあがってたんだってば。

デザパタ自体はシングルトン１つとっても意見はバラバラ。
コミュニケーションツールなんて夢のまた夢。

掲示板じゃ自由に言えるけど、会社じゃ適用に至る明確な理由が必要になる。
そこでデザパタが必要である理由なんて説明できる奴がいるわけが無い。
昔からずっとこんな調子なんだよ。
信者とアンチの聖戦が一番盛り上がるんだから叩きだしたって誰かが追撃してくるんだよ。

構図はいつも
「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」ＶＳ「オブジェクト指向原理主義者」

348 ：259：2005/06/25(土) 03:00:55 BE:568936499-

>>342
Poolはわからんが、
インターフェースとドキュメント見りゃ動作が分かるってのが、あるべきクラス設計の姿だろ、
実装に複数のstatic変数使ったからって、それが崩れることがあるのか？

349 ：259：2005/06/25(土) 03:03:10 BE:126431036-

>>347
＞オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿

アンチデザパタ派は何故いつもそう言う。
たとえば>>345がオブジェクト指向を理解できていないように見えるのか？
オブジェクト指向を理解しないとデザパタ理解できないぜ。

350 ：デフォルトの名無しさん：2005/06/25(土) 03:04:55

>>347
　頭悪い議論で盛り上がるのはもう沢山。
　だから隔離されてるんだよおまぃは

351 ：234：2005/06/25(土) 03:06:06

>>345
ああなるほど、そういう用例を考えると便利ですね。
でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
普通のオブジェクトよりその点がちょっとダーティ。でも逃げ道は在るよ、
というところでしょうか。

>>347
> 構図はいつも
> 「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」
> ＶＳ「オブジェクト指向原理主義者」

ぼくはどっちでもないとおもいます。

352 ：デフォルトの名無しさん：2005/06/25(土) 03:07:27

構図はいつも、「自作自演するアンチ」vs「自作自演するアンチアンチ」

353 ：234：2005/06/25(土) 03:07:55

そろそろ
イマドキDIだからSingletonなんかつかわないぜ（ﾌﾟ

とか誰か言うのかと思ってたらそうでもなかったですね

354 ：234：2005/06/25(土) 03:08:24

>>352
ぼくは自作自演なんかしてないもん(; ;)

355 ：デフォルトの名無しさん：2005/06/25(土) 03:08:50

基本的に意味不明。
説明汁。

356 ：デフォルトの名無しさん：2005/06/25(土) 03:09:47

なんだServiceLocatorの話か。

357 ：259：2005/06/25(土) 03:10:11 BE:393338887-

>>351
待て待て、>>273 で継承を否定しておきながら、それはないだろ。
>>345 は継承なくては実現し得ないんだぞ。

358 ：デフォルトの名無しさん：2005/06/25(土) 03:11:21

template<typename T>
calss singleton
{
static T ret;
public:
static T& get(){return ret;}
template<typename X1>
static T& set(const X1& x){ ret=T(x); return ret;}
template<typename X1,typename X2>
static T& set(const X1& x1,const X2& x2){ret=T(x1,x2);return ret;}
//... X3 X4 X5 ...
};
template<typename T> T singleton<T>::ret;
...
...
singleton<hoge> x;
hoge y = x.set("username");
...
...
vector vec;
...
singleton<vector<char> > v;
v.set(vec.begin(),vec.end());
vector vv=v.get();
...
v.set(1024,'\0');
read(fp,&v.get()[0],v.get().size());
...
class hoge2 : public singleton<hoge2> {}
...
テンプレートかますとそれなりに便利だが。
使い道がいまいち謎だ。

359 ：デフォルトの名無しさん：2005/06/25(土) 03:11:41

どーでもいいですよ。
>>273と>>351で同じ仮定をしなければならない義理があるわけでもなし。
つか、同じ仮定をしつこく主張しつづけたら、議論は進まない。

360 ：259：2005/06/25(土) 03:13:02 BE:252860494-

>>345 は継承による仕様変更の典型例だってことを言ってるのよ。

仕様変更に継承を用いることを肯定するなら、この問題は終結するはずなのだが。

361 ：デフォルトの名無しさん：2005/06/25(土) 03:13:10

>>358
　>>271

362 ：234：2005/06/25(土) 03:13:46

>>357
ぼくはべつに継承を常に否定してるわけじゃないんですが。
不要な継承を否定してるだけです。

>>345は、インタフェースを合わせるために必要な継承を巧みに使っている
例ですね。
まあ、実際にこういうtechniqueが実際にどれだけ必要になるかといえば、
疑問ですが。

363 ：デフォルトの名無しさん：2005/06/25(土) 03:13:49

>>360
　じゃ終結って事で。

364 ：デフォルトの名無しさん：2005/06/25(土) 03:13:56

>>349
少なくともお前は理解していないｗ
オブジェクト指向云々に関する話題は>>345には出ていない。
したがってお前はまぬけだ。

>オブジェクト指向を理解しないとデザパタ理解できないぜ。
これはまったくの嘘。
デザパタはオブジェクト指向なんてまったく知らない奴が作った物。
よっぽどのアホでもなきゃ騙されないけどねｗ
現にここにいる奴のほとんどが学生だろ？
言語は覚えたけど、プログラムが組めないってレベルの奴。
まあ、プログラマでもないのにいきなり現場にぶち込まれた奴が
たくさんいるからこのレベルの奴だと色々模索するから
学校のお勉強に近いデザパタに妄信する奴がでてくるんだよね。
だけど、いくら勉強してもプログラムなんて組めるようにはならない。
図星だろ？
くくくっ、プログラムの組み方が書いてある本が世にあるとよかったなぁｗ

365 ：334：2005/06/25(土) 03:14:07

>>347
あれ？アンチの人？おまいよく状況を知ってるなｗｗｗｗ
そうなんだよ昔から相手を馬鹿にするだけで、ろくな議論しないんだよあのスレｗｗｗ
だからここを有益なところにしようｗ

＞デザパタ自体はシングルトン１つとっても意見はバラバラ。
＞コミュニケーションツールなんて夢のまた夢。
コミュニケーションツールは確かに無理だねぇ。
書籍にしても著者によって捉え方が全然違う。
読んだ書籍によって、読み手も捉え方が異なってしまうし。

うーん、まあコーディングテクニック集ってとこなのかなぁ。

366 ：デフォルトの名無しさん：2005/06/25(土) 03:14:58

なんだ、NGワードが増えてきたな。
携帯４っつ使ってレス付けてるのか(笑

367 ：デフォルトの名無しさん：2005/06/25(土) 03:16:18

□■□■□　祝！秀ケツ　■□■□■

368 ：234：2005/06/25(土) 03:16:22

ああ、なるほど
>>259さんには、あのアダプタの適用も「仕様変更に際して用いられる
典型的なtechnique」なのか。
その辺が僕とは認識が違いますね。

まあ、仕様変更といっても色々ありますから、なんとも言えませんが、
Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
噛ませることがベストな解である、というタイプの仕様変更って
そんなに無い気がしますよ？

369 ：259：2005/06/25(土) 03:16:29 BE:112383528-

結局 >>234 は >>234 の質問から何を知りたかったわけ？

370 ：デフォルトの名無しさん：2005/06/25(土) 03:17:13

いままでどおり、机に向かって勉強してればプログラムが組めるようになるとでも思ったか？学生諸君ｗ
ならないだろ？ざまーみろｗ死ぬまでくるしめｗ

371 ：234：2005/06/25(土) 03:17:53

>>369
まあ、こんだけスレも盛り上がってることですし、いいじゃないですか(w

372 ：334：2005/06/25(土) 03:19:03

>>351
そですね。私の理解としては逃げ道つくるぐらいですかね。
開発してる時とかにメソッド呼ぶ前に、ログをとるデコレータクラスとかよく作ります。
そういった面で扱いやすいってだけですかね。
他にもメリットはあるかもしれませんが。

＞でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
↓これでどうでしょう・・・。一行にしてみました。だめですか・・・。
Singleton s = new TuikaKinouSingleten(Singleton.getInstance());

373 ：デフォルトの名無しさん：2005/06/25(土) 03:19:53

>>369
　たぶん、getInstance()にパラメータつけるより getFoo(), getBar()の方がいい、とか、
　それよりも static methodの方がもっとシンプル (継承できないけど継承は仕様変更の手段とすべきではない)

とか。じゃねぇ～の。いい加減寝るぞ

374 ：259：2005/06/25(土) 03:22:05 BE:393338887-

>>368
＞Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
＞噛ませることがベストな解である、というタイプの仕様変更って
＞そんなに無い気がしますよ？

ベタベタだがたとえばウィジットを生成する Factory。プラットフォームによって切り替え。
そんなにワサワサと例は出せないが。

逆に仕様変更のない Singleton は Singleton である必要がない気がする。
それこそ Utility 的な。

>>371
まぁそうだなｗ

375 ：デフォルトの名無しさん：2005/06/25(土) 03:22:10

正直、アンチの俺の意見としても継承の悪用は止めたほうがいいといっておく。

376 ：デフォルトの名無しさん：2005/06/25(土) 03:26:32

そもそもUtilityクラスとは、オブジェクト指向設計の放棄である (とりあえずそこまでクラス化するゆとりがないとか含む)
である事を指摘しておこう。

377 ：259：2005/06/25(土) 03:34:50 BE:393338887-

タイピングがめんどくさい、かつ、仕様変更に耐えうるシングルトンっぽいものを。
単にラッパーしただけな気もするが。ただの思い付きなんで落ち度があったら優しくつっこんで。
クラスAの実装自体のタイピングがめんどくさいけど。

class A{
　static StrategySingleton s=StrategySingleton.instance();
　static void invoke(){
　　s.invoke();
　}
}

A.invoke();

>>375
悪用ってのがどんな例だかわからんが、肯定派からも言わせてもらうと、
GoF本でも継承の濫用はするな、って書いてあった。
いちいち新しい動作を定義するのに毎回クラスを継承してたんじゃ、クラス増えまくりだからな。

>>376
まぁたしかにそうだな。
基本演算と同じレベルで考えればいいんじゃないか、と思う。
さすがに基本演算までオブジェクト指向にすることもなかろうと。

378 ：234：2005/06/25(土) 03:39:14

>>377
「全ての問題は間接参照をはさめば解決する」という
Andrew Koenigの言葉を思い出すような例ですね(w

379 ：デフォルトの名無しさん：2005/06/25(土) 05:35:21

・グローバル変数はダメ
・Singletonはダメ
・デザパタなんか誰も使っていない、普及していない

とほざく奴はJavaｄWebアプリの業務をやったことないだけだろ。
Javaではグローバル変数なんて概念はないし
Singletonはリクエストのたびにオブジェクト生成されるのを
防ぐために普通に使われるし（Factoryにすることも多い）
デザパタは使わないとスパゲッティ化してどうにもならなくなる
ってぐらいに当たり前のように使われている。
自分の知っている狭い世界だけで使ってないからって断言するな。クズ。

380 ：デフォルトの名無しさん：2005/06/25(土) 07:56:46

そもそもそんなそうちょうに、
なにあたりまえのことりきせつしてるの？

このすれは、
ていどのひくいひとがひっしにかんがえた
どうしようもなくていどのひくいねたを
かくりするすれだよ(わらい

381 ：デフォルトの名無しさん：2005/06/25(土) 07:57:55

382 ：デフォルトの名無しさん：2005/06/25(土) 13:31:42

なんでデザパタの由来も知らないような奴が、
「デザパタ肯定≠オブジェクト指向」
なんて言う脳内仮定で煽ってんの？

オブ戦スレの馬鹿がTMPこそデザパタとか
勘違いして、逆の立場で煽ってるの？

383 ：デフォルトの名無しさん：2005/06/25(土) 13:53:14

>>382
つか、「デザパタ自体、OOではない」らしいよ。奴にとって。

384 ：デフォルトの名無しさん：2005/06/25(土) 15:48:50

>>382
じゃあ、君がデザパタがオブジェクト指向にのっとっていることを証明したまえ。
ちなみに前スレだとデザパタはオブジェクト指向とは違う流れで
それは新しい進化ということで決着がついていた。

385 ：383じゃないが：2005/06/25(土) 15:52:27

>>384
なんとなく悪魔の証明っぽいな

OO 使わずとも組めるパターンもあるだろうに

386 ：デフォルトの名無しさん：2005/06/25(土) 16:10:07

いままでのデザパタ否定派の主張は
オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として
デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、
オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。

この主張の矛盾点を指摘する形では肯定派も否定派も
両者を納得させるまでにはいかず、煽りを繰り返すレスがついた。

はじめの主張が
「デザパタはオブジェクト指向では無い」
というところからはじまっているだけあって、アンチが主導権を握ってしまうのは仕方がないと思う。

387 ：俺は肯定派？：2005/06/25(土) 16:25:56

＞いままでのデザパタ否定派の主張は
＞オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として
＞デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、

このあたりは既に俺の考えとは違っていて、

＞オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。

これは当たり前だと思っている

388 ：デフォルトの名無しさん：2005/06/25(土) 16:56:54

>>384
>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。

389 ：デフォルトの名無しさん：2005/06/25(土) 17:44:18

やっぱりデザパタは僕の嫌いなオブジェクト指向じゃなかったんだ！

って思って欲しいのですか？
でオセロのソースでも晒すつもりですか？
おまいらは本当に進歩がないですね。

390 ：デフォルトの名無しさん：2005/06/25(土) 19:59:08

パターンはOO以前からあるし、互いに独立した手法だ。

>>389
まあ、そーゆーｽﾚだしね。適当に盛り上げといて。

391 ：デフォルトの名無しさん：2005/06/25(土) 21:02:46

>>390
どっちかと言うとテンプレートライブラリに近い。
テンプレートライブラリ化出来ないレベルを
デザインパターンで扱うべきなんだけど、
GoFのやってる事は、気持ち悪いタイプの
馬鹿プログラマみたいだ。

392 ：デフォルトの名無しさん：2005/06/25(土) 21:53:35

>>391
いくら明日予定が入って無いからって、そんなネタで暇つぶしの相手をみつようったってそうはいかない。

393 ：デフォルトの名無しさん：2005/06/25(土) 22:05:13

>>390
脳内妄想ステキー

394 ：デフォルトの名無しさん：2005/06/25(土) 22:06:14

>>392
今週のレスの付き具合を見るに、
>>391は毎日がエブリディもとい毎日が特別休日みたいだぞｗ

395 ：デフォルトの名無しさん：2005/06/25(土) 22:33:30

でも、マジな話、GoFのパターンは使えない。
てか、もういらない。

396 ：デフォルトの名無しさん：2005/06/25(土) 22:47:52

「パターン」はOOP以外にも適応できる概念だが、
それを「パターン」としてきっちり言語化したのはGoF以降だろう。
で、GoFのパターンの源はSmalltalkやC++での経験の蓄積が
元になっていると。
今では「デザインパターン」の語がOOPの領域以外にも
広げられてたとえば「モナド」は高階関数のデザパタの
一つ、と言ったりするわけだな。

だが、ここの厨がいってるような、デザパタはテンプレートで
オブジェクト指向とは関係ない、とかってのは、激しく
思い違いもいいところだ。

前橋、わかったのか？

397 ：デフォルトの名無しさん：2005/06/25(土) 22:48:05

>>394
毎日が出社とかも考えろ！！
ボケ、糞、カス、キチガイ、狂信者。

398 ：デフォルトの名無しさん：2005/06/25(土) 22:49:43

>>396
関係ないけどオブジェクト指向でも使えるのがデザインパターンなんで、
オブジェクト指向と関係ないちゅーのも、正しい物の見方だよ。

399 ：デフォルトの名無しさん：2005/06/25(土) 22:51:23

>>398

「パターン」としてきっちり言語化したのはGoF以降。

歴史は覆せないよ。

400 ：デフォルトの名無しさん：2005/06/25(土) 22:55:30

>>399
はぁ？
だからなんだってんだよ、GoFがオブジェクト指向的要素として
デザパタを提唱したんなら、オブジェクト指向の一部か否かてな
議論もなりたつが、C言語のデザインパターンだって成り立つんだから、
オブジェクト指向とは関係ないね。

で、GoFが出したカタログは、オブジェクト指向を破壊するデザインパターン
が多すぎるから誤解招いてるんだろ。糞。

401 ：デフォルトの名無しさん：2005/06/25(土) 23:01:25

>>400
>オブジェクト指向を破壊するデザインパターン
相変わらず具体性ないねｗ

402 ：デフォルトの名無しさん：2005/06/25(土) 23:02:26

これだから厨はいやなんだよ。関係ないも何も
デザインパターンが意識され始めたのは、
オブジェクト指向による設計に関する経験から
来ているのは事実なんだから。
そこで「デザインパターン」という、
「ライブラリ」なんかとは抽象レベルの違う概念が
意識されてきたわけで、あとから考えれば、
コレもアレもパターンてのは当然ある。
結局おまいらのいってるのは「CでもOOPできるYO」
ってのと同じく「Cでもデザパタできるよ」って言って
るだけで、吠えてみたところで、オブジェクト指向に
とってデザパタが重要なことに変わりはない。

403 ：デフォルトの名無しさん：2005/06/25(土) 23:03:31

わかったのか、前橋。

404 ：デフォルトの名無しさん：2005/06/25(土) 23:04:19

=================================================================
　　暑さのためおかしくなった不審人物がが大喜びではしゃいでます。

　　　　　　　　　　　　　　　　　　　　一般の方は刺されないように退避して下さい。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(隣組回覧)
=================================================================

405 ：デフォルトの名無しさん：2005/06/25(土) 23:08:51

前橋ってデザインパターンに否定的な見解なの？

406 ：デフォルトの名無しさん：2005/06/25(土) 23:09:29

無職５年とか不審人物とまで蔑まれてるのに、
それでも構ってもらえたと勘違いして、
大喜びで自作自演レスしまくるとは、相当なもんだよな。

きっと、人との交流に激しい飢餓感を持ってるのだろうな。
もまいさぁ、いい加減、額に汗して働けよ。
俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ

407 ：デフォルトの名無しさん：2005/06/25(土) 23:21:34

>>402
1994年に標準化されたSTLが有るのに、
95年に書かれたデザインパターンをもって、
新しいってのはちょっと違うなぁと思うぞ。

408 ：デフォルトの名無しさん：2005/06/25(土) 23:45:04

>>407
はぁ～。GoF程度は読んどけよ。まったく。
あれのパターンの元ネタはSmalltalk-80やMacAppやその他。
この期に及んでSTL持ち出すのも馬鹿丸出し。

409 ：デフォルトの名無しさん：2005/06/25(土) 23:50:32

>>406
>>俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ

どうやら >>406 にとって「働いている・働いていない」の基準とは、
室内のエアコンが「利いている・利いていない」って所らしいな。

410 ：デフォルトの名無しさん：2005/06/25(土) 23:56:42

いくらデザパタがオブジェクト指向からできたって、＃あの糞設計をみるとそれも怪しいが・・・ｗ
デザパタでの設計がオブジェクト指向にのっとっているかは別問題。
やっぱりオブジェクト指向とは考え方が違う。

オブジェクト指向で似通った設計を集めてそれをパターンにして当てはめたって
それはオブジェクト指向での設計にはならない。

411 ：デフォルトの名無しさん：2005/06/26(日) 00:20:29

　　　　　　｜　Hit!!
　　　　　　｜
　　　　　　｜
　　ぱくっ｜
　　　　　／V＼
　　　　/◎;;;,;,,,,ヽそんなエサで
　＿　ﾑ::::(,,ﾟДﾟ)::| 俺様が釣られると思ってんのか!!
ヽﾂ.（ﾉ:::::::::.:::::.:..|）
　ヾソ:::::::::::::::::.:ﾉ
　　｀ー U'"U'

412 ：デフォルトの名無しさん：2005/06/26(日) 03:02:48

>>410
オブジェクトであるパーツを再利用するとオブジェクト指向じゃねえって意味わかんないんですけど。
で、デザパタのどこがクソ設計なのか具体的に挙げてもらえますか？そしてそれはどう設計されるべきですか？

413 ：デフォルトの名無しさん：2005/06/26(日) 03:08:07

>>400
>C言語のデザインパターンだって成り立つんだから、オブジェクト指向とは関係ないね。

へぇ、オブジェクト指向って言語依存なんだ。てっきり設計の指針みたいなもんだと思ってたが。
プログラムできない人の考えることはオリジナリティがあっていいねｗ

414 ：デフォルトの名無しさん：2005/06/26(日) 03:24:06

>>412
それは実装の話。
設計段階でオブジェクト指向では対象物をそのままソースに移すことが重要。
その結果、同じクラスが出てきたら、再利用できるできないを検討すればいい。
パターンに当てはめてしまうデザパタとはやはり違う。

415 ：デフォルトの名無しさん：2005/06/26(日) 03:38:54

デザパタ=パターンに当てはめて設計する
という前提が異常。

416 ：デフォルトの名無しさん：2005/06/26(日) 03:40:25

>>415
じゃあ、パターンっていつ使うんだよｗ

417 ：デフォルトの名無しさん：2005/06/26(日) 03:58:57

>>414
煽りじゃなくってこれはいっとかなきゃいけないと思うので書くが、キミ全く判ってないよ。
デザパタで語られるパターンてのはジェネリックかつプリミティブ。
STLで言ったら、vectorとかlistみたいなもんだ。
「クラスのメンバーにvectorがあったらオブジェクト指向じゃない」なんて命題は有り得ないわけよ。
vectorはプリミティブなテンプレートクラスであって、これによって設計がOOPかどうかを判断するなんて全くナンセンス。
まず、GoF本くらい読んで「理解して」から書き込みしなよ。

418 ：デフォルトの名無しさん：2005/06/26(日) 04:23:16

>>417
なんでそこで実装の話がでちゃうのか理解不能。
余計わからない。
少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も
パターンに当てはめる形で設計をしている。
これは「～パターンが使えそうですね。」的な発言も見られることから明らか。
わけのわからないことを言わないでもらいたい。

419 ：デフォルトの名無しさん：2005/06/26(日) 04:24:58

レスに困ったら「それは実装の話」と言っちゃえばいいわけか。参考にしよう。

420 ：デフォルトの名無しさん：2005/06/26(日) 04:29:23

>>419
ハイハイ、そこは重要な箇所じゃないでしょ？
くだらない煽り入れないでね。

ちゃんと↓に答えてね

少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も
パターンに当てはめる形で設計をしている。
これは「～パターンが使えそうですね。」的な発言も見られることから明らか。
わけのわからないことを言わないでもらいたい。

421 ：デフォルトの名無しさん：2005/06/26(日) 05:03:04

もっと使いやすいパターンが普及すれば良い
っていう話？

422 ：デフォルトの名無しさん：2005/06/26(日) 05:31:37

>>420
じゃ、君は以前に自分が使った設計の方法を思い出して
「あ、ここはあのやり方が使えるな」と思うことはないのか？
そう思った時点でそれはオブジェクト指向ではないのか？

ばっかじゃねえの。

423 ：デフォルトの名無しさん：2005/06/26(日) 05:39:20

>>417
C言語でシングルトンパターンをどうやって利用しようか？
コンストラクターを隠蔽するから、一意性が保たれる？
プッって感じ。

では、オブジェクト指向的に考えてみようか？
インスタンスの生成を隠蔽すると安全なシステムになる？
プッて感じ。

GoF煎ってよし。

424 ：デフォルトの名無しさん：2005/06/26(日) 06:10:47

GoF本知る前からTemplateMethodとかCompositeパターンは使ってたなぁ（というかそうなってた）。

あれって継承とか多態とかオブジェクト指向独特のテクニックを駆使してるし、
そういう意味でデザパタがオブジェクト指向の文脈で語られるのは当然かなぁ。

GoFのパターンが糞というのはそれぞれのスタンスとしてはいいと思うけど、
それがオブジェクト指向から外れてるってのはちょっと的外れかなぁ。

あ、もしかして継承も多態も認めない、原理主義的オブジェクト指向信者だっていうなら納得w
でも、それだって単にオブジェクト指向に対するスタンスの違いってだけの話しだよねぇ・・・

425 ：デフォルトの名無しさん：2005/06/26(日) 10:31:43

× 継承も多態も認めない、原理主義的オブジェクト指向信者
○ 継承も多態も解らない、抽象的に物事が考えられないバカ

426 ：デフォルトの名無しさん：2005/06/26(日) 11:35:15

アンチの主張は抽象的かつ主観的でなんら具体性も客観性もない全く内容のないものだ

427 ：デフォルトの名無しさん：2005/06/26(日) 11:42:55

>>424
>それがオブジェクト指向から外れてるってのはちょっと的外れかなぁ。
理由を言ってよ。
議論にならない。

428 ：デフォルトの名無しさん：2005/06/26(日) 12:08:10

>>427
一般にオブジェクト指向の重要な概念として(1)カプセル化(2)継承(3)多態性というのがあるよね。

デザインパターンはこれらの概念をいかに設計レベルで利用するかと言うサンプル集みたいなものだから、
やはりオブジェクト指向の文脈で語られるべきものだと思うんだよね

429 ：デフォルトの名無しさん：2005/06/26(日) 12:32:45

>>428
そりゃオブジェクト指向言語の機能じゃね？ｗ
はなしにならねー
さすがにお前みたいな肯定派はいなかったぞｗ

430 ：デフォルトの名無しさん：2005/06/26(日) 12:33:52

>>420
ちゃんと答えるも何も、なにを答えたらいいのかわからない。
「パターンを当てはめる形で設計している。」に対して
「はい」または「いいえ」と答えればよいということかな？

その答えが知りたい意図がわからない。

431 ：デフォルトの名無しさん：2005/06/26(日) 12:35:26

>>430
それでいいよ。

432 ：430：2005/06/26(日) 12:36:54

>>420
それでいつも>>419のようにある程度、具体的な話にもっていってるのに、
>>420はいつも宙ぶらりなレスを返すからこちらとしても議論ができない。

433 ：430：2005/06/26(日) 12:38:12

>>431
ああ、そうなの。
つまり、君が結論を出したかったことは
「パターンを当てはめる形で設計している。」に対して
「はい」って答えさせたかったってだけなのね。

それ以外の議論はしたくないと。

434 ：デフォルトの名無しさん：2005/06/26(日) 12:39:15

>>429
デザインの話だから言語とは独立したお話。
という建前だけど、実際には言語の使用に引っ張られることも多いやねぇ・・・

435 ：デフォルトの名無しさん：2005/06/26(日) 12:42:01

GoFは言語から独立だろ。

436 ：デフォルトの名無しさん：2005/06/26(日) 13:03:11

>>429
オブジェクト指向自体にはカプセル化や多態性の概念って無かったんだっけか？
むか～しに
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/
でオブジェクト指向勉強したんだが、これにはそんな風に書いては無かったと
思う（もはや手元に無いので未確認。間違ってたらごめん）。

437 ：デフォルトの名無しさん：2005/06/26(日) 13:07:24

>>417のどこが実装の話なのかよくわからない
っていうかアンチにとってどこからが実装の話なのかもよくわからない

438 ：デフォルトの名無しさん：2005/06/26(日) 13:08:59

多態がなけりゃオブジェクト指向なんて役にたたねぇ

439 ：デフォルトの名無しさん：2005/06/26(日) 13:24:27

ここのオブジェクト指向信者は、
カプセル化や多態性も分からずにオブジェクト指向を語っていたのか...
それこそ話にならん

440 ：デフォルトの名無しさん：2005/06/26(日) 13:26:57

>>439
そりゃ実装技術だろ。
オブジェクト指向での設計の話をしているだろ。

441 ：デフォルトの名無しさん：2005/06/26(日) 13:30:07

>>440
え？ポリモーフィズム意識せずに設計やってんの？マジで？

442 ：デフォルトの名無しさん：2005/06/26(日) 13:30:10

>>440
おいおい、実装だけの話ではないよw
適当に検索してみればいくらでも出てくると思うがなぁ・・・

443 ：デフォルトの名無しさん：2005/06/26(日) 13:30:47

>>440
継承やカプセル化や多態性を考慮しながらクラス図を描いたりしないのか？

444 ：デフォルトの名無しさん：2005/06/26(日) 13:34:59

>>441
やってるよ。マジで。
その辺って後からできた技術でしょ？
純正のオブジェクト指向信者の俺はそんな無駄なことはしない。

カプセル化なんて意識しなくても普通になるが、
継承や多態性なんて狙って設計なんかすると糞設計まっしぐらだぞ。

445 ：デフォルトの名無しさん：2005/06/26(日) 13:38:20

>>441
> その辺って後からできた技術でしょ？
情報源を希望

446 ：デフォルトの名無しさん：2005/06/26(日) 13:38:28

多態を考慮しない設計なんてオブジェクト指向じゃないよ・・・

447 ：445：2005/06/26(日) 13:39:20

×>>441
○>>444
スマン orz

448 ：デフォルトの名無しさん：2005/06/26(日) 13:39:43

後からできたどころか、多態なんかはオブジェクト指向の本質だなんだけどね

449 ：デフォルトの名無しさん：2005/06/26(日) 13:40:27

>>446
なんで？
多態性や継承なんてバグの温床だと思うけど？

450 ：デフォルトの名無しさん：2005/06/26(日) 13:41:48

>>449
> 多態性や継承なんてバグの温床だと思うけど
なんでそう思ったんだい？

451 ：デフォルトの名無しさん：2005/06/26(日) 13:41:58

>>448
本質じゃないよ。
本質は対象物の構造をそのままソースに映すことだよ。
多態性なんて付属品じゃないか。

452 ：デフォルトの名無しさん：2005/06/26(日) 13:43:29

>>450
自分の主張を入れて無いレスにレスは返さないよ。
自分はどう思うけど～って形にしてくれない？

453 ：デフォルトの名無しさん：2005/06/26(日) 13:45:16

対象物の構造をそのままなんていってるが
純粋架空物のクラスは作らないのかよ

454 ：デフォルトの名無しさん：2005/06/26(日) 13:46:10

オブジェクト指向に多態性が必要ないっていう意見は初めて聞いたな

455 ：デフォルトの名無しさん：2005/06/26(日) 13:48:40

>>454
なぜそっちを相手にしてるのか？
が疑問だ。

456 ：デフォルトの名無しさん：2005/06/26(日) 13:48:44

>>454
心に刻んでおきたまへｗ

457 ：デフォルトの名無しさん：2005/06/26(日) 13:52:16

>>450
多分、>>449はC++プログラマーで基底クラスのデストラクタをvirtualにし忘れたとか、
そういう低レベルのことをいっているんジャマイカ？

458 ：デフォルトの名無しさん：2005/06/26(日) 13:55:43

多態を否定すると、Javaのライブラリが何も使えなくなってしまうなw

459 ：デフォルトの名無しさん：2005/06/26(日) 13:57:15

おい、34℃超えたってよ。

460 ：デフォルトの名無しさん：2005/06/26(日) 14:01:03

>>458
アンチの彼はC++しか使ったこと無いみたいだから、いいんじゃﾈｰﾉ

461 ：デフォルトの名無しさん：2005/06/26(日) 14:01:17

>>458 boostもC++の標準ライブラリも使えないっす。つらすぎる。

462 ：デフォルトの名無しさん：2005/06/26(日) 14:01:23

>>457
そのレベルなの？

基底クラスをバーチャルにするしないは、場合よるか、
統一事項の世界かと？

463 ：デフォルトの名無しさん：2005/06/26(日) 14:02:49

>>441
設計、分析、実装の違いがわからん厨は糞して寝ろｗ

464 ：デフォルトの名無しさん：2005/06/26(日) 14:07:05

>>461
MFCも使えないな。
# まぁ、別の意味でMFCは使えないライブラリだし、いいのか？

465 ：デフォルトの名無しさん：2005/06/26(日) 14:08:28

C++ライブラリはまず全滅。
Cの時代に逆戻り。

466 ：デフォルトの名無しさん：2005/06/26(日) 15:24:27

なんだ、この程度のを相手にしていたのか。
キミにはなっかりだよ。

467 ：デフォルトの名無しさん：2005/06/26(日) 15:24:36 BE:56191542-

(´ー｀)早くID導入されてほしいな

468 ：デフォルトの名無しさん：2005/06/26(日) 15:32:50

継承とポリモーフィズム使わないんならそれはオブジェクト指向じゃなくて
モジュール指向だとか抽象データ型の世界だろ
別に後者が悪いという訳じゃないが、オブジェクト指向を後者から決定的に
峻別するものが継承とポリモーフィズム。

469 ：デフォルトの名無しさん：2005/06/26(日) 16:30:54

>>468
なんどもいうけど
オブジェクト指向ってのは
対象物の構造をソースに反映させることだよ。
継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。
だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ？
結局、設計が腐ってたら継承だって多態性だって全く意味が無いよ。

470 ：デフォルトの名無しさん：2005/06/26(日) 16:40:31

>>469 ポリモーフィズムの意味を理解した上での発言だよね？

471 ：デフォルトの名無しさん：2005/06/26(日) 16:41:52

>>470
そのつもり。
まず、正しい分析、正しい設計ありき。
継承や多態性なんて出てくるのはあとのあと。

472 ：デフォルトの名無しさん：2005/06/26(日) 16:47:56

>>471 設計終わってから新しくクラス派生させるの？
設計終わってから派生させちゃいけないっていってるわけじゃないよ。

でも実装時にクラス派生させることを前提にした設計って...

473 ：デフォルトの名無しさん：2005/06/26(日) 16:52:03

>>449
使いこなせない事の言い訳に「バグの温床」というのは
よく聞かれる詭弁ですね。

474 ：デフォルトの名無しさん：2005/06/26(日) 16:52:10

継承なんて面倒なんで、pimpl使えばいい、
どうせ関数呼出しに関しては継承とたいして変わらん、
動的な切替えもできるし。

475 ：デフォルトの名無しさん：2005/06/26(日) 16:59:10

>>474
pimplイディオムは良くってデザインパターンはダメってのが良く分からん。
pimplではなく委譲といえばまだ分かるんだが・・・

476 ：デフォルトの名無しさん：2005/06/26(日) 17:03:36

>>472
そんなウォーターフォールな脳みそでこの先どうするつもりだｗ

477 ：デフォルトの名無しさん：2005/06/26(日) 17:07:58

>>476
いや、設計は設計、実装は実装みたいな言いかたする割には、
実装に強く依存した設計するんだなって思ってさ。

478 ：デフォルトの名無しさん：2005/06/26(日) 17:25:47

>>474 継承を使用しないでどうやって多態性を導入するの？

479 ：デフォルトの名無しさん：2005/06/26(日) 17:27:16

Javaだったらインターフェースがあるけどさ

480 ：デフォルトの名無しさん：2005/06/26(日) 17:33:16

>>469
またお前か

481 ：デフォルトの名無しさん：2005/06/26(日) 17:42:45

>>477
てゆうか、設計が崩れたら実装はやり直しでしょ。

482 ：デフォルトの名無しさん：2005/06/26(日) 18:08:11

設計が終わってから、新規にクラスを導入するってのはあり得ない事ではないんだけど、
設計終わってから継承、そしてポリモーフィズムを取り入れるってことは
新しくクラスを導入することが確定事項としてあるわけで、
それって設計が終わってないって事じゃないのか？

483 ：デフォルトの名無しさん：2005/06/26(日) 18:12:40

HumanクラスがFactoryで生成されるのはオブジェクト指向的におかしい！
先ずはFatherクラスとMotherクラスを作るべきだ！

⊂⌒~⊃｡Д｡）⊃ どうでもいいですよ～

484 ：デフォルトの名無しさん：2005/06/26(日) 18:20:55

>>482は>>469への問題提起ね

485 ：デフォルトの名無しさん：2005/06/26(日) 18:22:46

>>469
＞対象物の構造をソースに反映させることだよ。

この時点で大きな間違いを犯していることに気付いてくれ OTL

＞継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。

んで、この行は前行と合わせるとえらく矛盾している事にも気付いてくれ OTL

486 ：デフォルトの名無しさん：2005/06/26(日) 18:23:37

>>482
ウォーターフォールしか頭にないのか？

分析→設計→実装→分析→設計→実装→設計→実装→分析→設計→実装・・・

ってやっても別にいいんだぞ。

487 ：デフォルトの名無しさん：2005/06/26(日) 18:24:02

>>483
ヒント：クローン

488 ：デフォルトの名無しさん：2005/06/26(日) 18:25:10

>>485
ちゃんどどこがどうまちがっているまで書いてくれなきゃレスはつけないのでよろしく。

ちゃんと自分の主張を相手に伝えることぐらいはできなくちゃ駄目だよ。
プログラムがどんなに組めたってそれじゃいっしょに仕事ができない。

489 ：デフォルトの名無しさん：2005/06/26(日) 18:31:19

＞ちゃんと自分の主張を相手に伝えることぐらいはできなくちゃ駄目だよ。
主張するだけで具体性を伴ってないから、全く相手に伝わってない奴もいるな

490 ：デフォルトの名無しさん：2005/06/26(日) 18:31:32

>>486 いいよ。それで。
問題にしているのは>>469が
> だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ？
としていること。
>>469にとって継承のために新しくクラスを導入することは「設計をやり直す」
ことには属さない。

491 ：485：2005/06/26(日) 18:31:33

>>488
あ、了解。っていうか問題だけ提起して裏でごにょごにょ書いてたでス。

＞対象物の構造をソースに反映させることだよ。

オブジェクト指向を使えば、同じ対象物に対し、万人が同じ構造のソースを書いてくる……筈も無い事から、
構造を反映させるのは合っているが、構造の詳細はPGに任されると思った。
ニュアンスの問題。

＞継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。

継承や多様性も含めた対象の構造を考えるのが、オブジェクト指向。
そこまで構造に反映させてくれ。

492 ：デフォルトの名無しさん：2005/06/26(日) 18:33:24

自分は具体的な話から逃げておいて相手には具体的な内容を要求するとはなんたる自己矛盾

493 ：デフォルトの名無しさん：2005/06/26(日) 18:37:26

>>469=>>474は
>>475と>>478をスルーするつもりなんだろうか？

494 ：デフォルトの名無しさん：2005/06/26(日) 18:45:15

>>490
ん？文章的には結論がついてるみたいだけど、何が聞きたいの？

>>491
でもさ、継承や多態性なんて構造に入れるのなんて
対象物の構造が間違いないぐらいきっちりわかってからの話じゃない？
要は全体の設計にさほど影響を与えるものでは無いよ。
俺の組み方だけど継承やら多態性やらを考慮してクラスを組み変えるのは一度実装が
ほぼ終わりに近づいてからしかやったこと無いな。
そこまで設計とは遠いものだと考えてる。

ちなみに最近じゃ使って無い。（むしろ、使わない方がいいと思ってる。）

495 ：デフォルトの名無しさん：2005/06/26(日) 18:46:02

>>493
悪いけど、>>474は俺じゃない。
pimplって何？ｗ

496 ：デフォルトの名無しさん：2005/06/26(日) 18:48:00

>>493
469と474て同一人物じゃないだろ？
同一人物だとしたら説が矛盾する。

497 ：493：2005/06/26(日) 18:50:14

>>495 そうか．．．スマン
Pimplは Exceptional C++ にありますです。

498 ：485：2005/06/26(日) 18:52:25

>>494
＞対象物の構造が間違いないぐらいきっちりわかってからの話じゃない？

つまり貴方は、何時も見切り発進でやってると……言うような冗談は置いておいて

・分かっているならば構造に組み込むというのは FA
・分かった時点で構造に組み込むというのも FA

だれも『判明していない構造』を組み込めなんて言ってないですし

＞継承やら多態性やらを考慮してクラスを組み変えるのは

っていうか、もしかしたらと思ったんだけど、
『コーティングの技巧として、構造とは異なる継承や多様性を組み込む』
とかやってませんか？

それはオブジェクト指向から微妙に外れるし、それを「オブジェクト指向とは言わない」と言うのはトートロジ

499 ：485：2005/06/26(日) 18:57:23

なんかデザパタじゃなくてオブジェクト指向の話になっているけど、

>>494
俺でも確かに、継承とかを使わないときは全く使わないんだけど、それでも時折閃くときがあるんだな
そういうときには使う

500 ：デフォルトの名無しさん：2005/06/26(日) 18:57:47

pimplって何？ときましたかｗ
これでコイツがC++で実務をこなした事は一度も無いって事が分かったな。

Java&J2EEに関する知識は皆無で、C++に関してはテンプレートに苦戦中
でpimplを知らないというレベル。なんとなく、どんな奴だか見えてきた。

501 ：490：2005/06/26(日) 18:57:51

>>494
聞きたいのは>>482だったんだが、
>>494を読む限り、君にとってis-aの関係のためのクラス導入は、
設計とはほぼ無関係であるとしてるね。

設計に無いクラスの導入を実装時にすることを確定事項とした設計であると理解して良いね？

502 ：デフォルトの名無しさん：2005/06/26(日) 18:59:17

教えて君の奇形だろ。

503 ：デフォルトの名無しさん：2005/06/26(日) 18:59:33

>>498
あ？なんか非常にわかりにくい文章で何言ってるのかわからない。
何がいいたかったの？
書いた本人的にも微妙でしょ？>>498の文章って。

504 ：485：2005/06/26(日) 19:00:42

>>503
微妙だけど？

505 ：デフォルトの名無しさん：2005/06/26(日) 19:05:51

横レス申し訳ないんだが。
「構造」って「データ構造＋論理構造」だよね?

506 ：デフォルトの名無しさん：2005/06/26(日) 19:07:13

>>505
「オブジェクト構造」

507 ：485：2005/06/26(日) 19:17:51

まとめた

>>494
『コーティングの技巧として、想定していたオブジェクトの構造とは異なる継承や多様性を組み込む』ことは、
たとえクラス等を使用していてもオブジェクト指向とは言えない (かもしれない)

508 ：デフォルトの名無しさん：2005/06/26(日) 19:20:24

>>507
何がききてぇんだ？ｗ
もう、てめぇの中で結論は出てるのか？ｗ

509 ：485：2005/06/26(日) 19:22:39

>>508
何も聞きたくありませんわ

510 ：デフォルトの名無しさん：2005/06/26(日) 19:33:05

is-aの関係なんて分析時に真っ先に判明するもんでしょ？普通は。
それを>>494では
> 継承やら多態性やらを考慮してクラスを組み変えるのは一度実装が
> ほぼ終わりに近づいてからしかやったこと無いな。
なんていっちゃってるし、これって設計せずにプログラミングしているのと何か違いがあるのか？

511 ：デフォルトの名無しさん：2005/06/26(日) 19:39:40

1.要求定義
2.分析
3.設計
4.実装
5.品質管理

それぞれのステージにおいてOOの意味や役割が異なる。という前提は確認しあってるの？

512 ：デフォルトの名無しさん：2005/06/26(日) 19:42:24

設計に落とす段階で挫折する人が多いようだけど。そういう人たちがデザパタに
頼っちゃうのかな？

513 ：デフォルトの名無しさん：2005/06/26(日) 19:59:29

とデザパタに挫折した人が言っております。

514 ：485：2005/06/26(日) 20:03:16

デザパタに挫折したからどうなるってもんでも無いような気がしますが

デザパタって、料理のレシピみたいな物なのかもね
レシピを見れば、腕が良ければそこそこの料理ができる
レシピをたくさん眺めていれば、新しい料理を作ってみることもできる

……レシピを見なくても、料理できる人は料理しちゃう

515 ：デフォルトの名無しさん：2005/06/26(日) 20:04:31

>>494は、先に継承・多態性を否定したデザパタ否定派が、
多態性を否定するとほとんどの既存のライブラリを使用できなくなることを指摘され、
それを無理に方向修正しようとして失敗した結果だろ？

516 ：デフォルトの名無しさん：2005/06/26(日) 20:05:56

>>513
そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か？

517 ：デフォルトの名無しさん：2005/06/26(日) 20:07:32

>>516
？
512 への間違い？

518 ：デフォルトの名無しさん：2005/06/26(日) 20:11:49

>>515
×デザパタ否定派
○デザパタ否定君

519 ：デフォルトの名無しさん：2005/06/26(日) 20:14:07

>>517は天然？

520 ：517：2005/06/26(日) 20:20:29

>>519

＞513 ：デフォルトの名無しさん：2005/06/26(日) 19:59:29
＞とデザパタに挫折した人が言っております。

＞516 ：デフォルトの名無しさん：2005/06/26(日) 20:05:56
＞ >>513
＞そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か？

ごめん。この２個のレスが全然繋がらないんだ

521 ：デフォルトの名無しさん：2005/06/26(日) 20:28:13

>>428があるから継承・多態性を否定しないと、
デザパタはオブジェクト思考に従っていないからダメ
というロジックが崩れてしまうし、
かといって継承・多態性を完全に否定してしまうと今度は、
ほとんど全部の既存のライブラリを使えないことになってしまうし・・・

と、考えたデザパタ否定君は>>494をカキコしたのでしょう。

522 ：デフォルトの名無しさん：2005/06/26(日) 20:28:47

>>520
だろうね。

523 ：デフォルトの名無しさん：2005/06/26(日) 20:32:48

>オブジェクト指向の重要な概念として(1)カプセル化(2)継承(3)多態性というのがあるよね。
まあ、最も重要な概念である「振る舞い」を外してる時点でアレだけどね。

524 ：デフォルトの名無しさん：2005/06/26(日) 20:33:51

>>523
「振る舞い」というか「インターフェイスの抽象化」の方が

525 ：デフォルトの名無しさん：2005/06/26(日) 20:41:04

>>524
もう一息だね。
「インターフェイスの抽象化」を「振る舞い」と呼びたくなった時にはじめて
自分がテイクオフしたことを実感できると思うよ。頑張って！

526 ：デフォルトの名無しさん：2005/06/26(日) 20:45:39

>>525
ああ、多分俺が考えているのと違うわ。
「対象物のインターフェイスを抽象化する」＝「対象物の振る舞いを定義する」

527 ：デフォルトの名無しさん：2005/06/26(日) 20:47:15

>>526
うん。違うね。

528 ：デフォルトの名無しさん：2005/06/26(日) 20:50:02

単なる集約を抽象化などと小難しく表現するのは勘弁な。

529 ：デフォルトの名無しさん：2005/06/26(日) 20:54:56

悪い。「振る舞いの定義」の「の定義」って部分がさらりと出てこなかった。

530 ：デフォルトの名無しさん：2005/06/26(日) 20:55:27

>>526
ｲﾀﾀﾀﾀ

531 ：25 ◆41ucRLNOBQ ：2005/06/26(日) 20:56:28

俺は>>508あたりからレスしてないぞ。

532 ：デフォルトの名無しさん：2005/06/26(日) 20:57:56

>>531
それが何か？

533 ：デフォルトの名無しさん：2005/06/26(日) 20:58:37

>>531
何か？

534 ：デフォルトの名無しさん：2005/06/26(日) 21:14:39

ところで、今日考えてたんだけど、否定派の主張は

　『デザパタはオブジェクト指向に従っていない、トリッキーなコードである』

ってコトらしいけど、俺は仮説として

　『デザパタを適用してもオブジェクト指向に従っている例は存在するのではないか』

を考えた。否定派の主張を覆すならば、その様な具体例を示せれば良いと思う。
もし存在すれば、デザパタは反オブジェクト指向的コードを強制する物ではないと示せる筈だから。

んで、具体例を挙げるにあたって、

　『実世界の物体において実現されている構造ならば、オブジェクト指向で考えられる。つまり、オブジェクト指向に従っている』

と考えた。

【続く】

535 ：デフォルトの名無しさん：2005/06/26(日) 21:14:51

【続き】

んで、試しに Strategy が適応されている、もしくは Strategy 的な構造になっている現実世界の実例を考えてみたら

　・マザーボードと CPU の関係
　・ゲームボーイとカートリッジの関係

とか、妙にたくさん出てきて困った。

これらの関係は、２つの接触部分を固定化して、片方を必要に応じて切り替えられるようになっている関係だ。
必要に応じて切り替えられる、って言うのはつまり切り替えなくても良い、って意味も含むけど。

んで、俺の仮説における具体例が示せたわけだが、果たして合っているだろうか……

======

あと、この例ならば、以前否定派の人が「戦術をクラスとして抜き出すのはオブジェクト指向的ではない」
って言っていたことの、簡単な反証にもなると思う。

この主張は「戦術≠オブジェクト」ってコトを根拠にしているけど、
「抜き出す作業」はつまり、「戦術を内包したオブジェクトを定義する」ことに等しいから、そもそも問題になってない。

536 ：デフォルトの名無しさん：2005/06/26(日) 21:25:12

>>534-535
>>386がよくまとまってるから読んでからにしたほうがいいと思う。

537 ：デフォルトの名無しさん：2005/06/26(日) 21:29:04

>>536
否定派の主張が間違っているって言うこと？
その主張には何通りかあったと認識してたけど……

538 ：デフォルトの名無しさん：2005/06/26(日) 21:34:49

539 ：デフォルトの名無しさん：2005/06/26(日) 22:01:18

いい加減に
『「現実物をそのままモデル化するのがオブジェクト指向」ってのは間違ってるんだぜ！ぎゃはは』
っていう釣りは止めてください。
おまいらは本当に進歩がないですね。

540 ：デフォルトの名無しさん：2005/06/26(日) 22:01:41

わかったのか、前橋？

541 ：デフォルトの名無しさん：2005/06/26(日) 22:04:51

『「現実物をそのままモデル化するのがオブジェクト指向」ってのは間違ってる』って言ってるのは俺だけだなそういえば

542 ：デフォルトの名無しさん：2005/06/26(日) 22:05:25

ところで前橋って何

543 ：デフォルトの名無しさん：2005/06/26(日) 22:05:48

モノを知らない人が来ました。

544 ：デフォルトの名無しさん：2005/06/26(日) 22:05:55

>>540
前橋って誰だー！

545 ：デフォルトの名無しさん：2005/06/26(日) 23:06:27

=================================================================
　　　　　要するに、読む価値ないスレ。
　　　　　無理に読んだら、確実にバカが伝染する
=================================================================

546 ：デフォルトの名無しさん：2005/06/26(日) 23:07:44

>>545
枠線付けないとみんなにスルーされると思って不安なんですねｗ

547 ：デフォルトの名無しさん：2005/06/26(日) 23:08:07

ほんと、痛い人の巣窟

548 ：デフォルトの名無しさん：2005/06/26(日) 23:10:15

これだけ痛い人が一つのスレに集まるのは奇跡的。
つか、どー考えても自作自演だろ、この痛さは

549 ：デフォルトの名無しさん：2005/06/26(日) 23:17:32

痛い人同士の間でこれらが会話（議論）として成り立っているのが、真に不思議

550 ：デフォルトの名無しさん：2005/06/26(日) 23:23:18

自作自演の脳内会話だから
・・・いわゆる一般の会話じゃなくて、
分裂症患者の妄言みたいなもの

551 ：デフォルトの名無しさん：2005/06/27(月) 00:22:49

ところで前橋とはどのような殿方かね？
っていうか誰だよ前橋。

552 ：デフォルトの名無しさん：2005/06/27(月) 00:23:37

まあ隔離ｽﾚとしてはこんなものでしょう。

553 ：デフォルトの名無しさん：2005/06/27(月) 00:54:04

ここのアンチみたいな人が部下や同僚にいると大変だよなぁ・・・
まぁ、実際この手のタイプはいるけどさ

554 ：デフォルトの名無しさん：2005/06/27(月) 02:34:47

>>541
>「現実物をそのままモデル化するのがオブジェクト指向」

痛いよなｗ　だから存在しない「抽象の抽象」は理解不能なんだよなｗ
いつからOOPってこんな稚拙で低知能な思考形態を正当化する概念になったんだ？
こんなのプログラム組んだことのない、影で「クソ設計勘弁してくれ」呼ばわりされている「自称」SEの戯言だから心配するな。
こういう連中が「オブジェクト指向」と連呼するごとにチープな言葉になっていく。

555 ：デフォルトの名無しさん：2005/06/27(月) 02:37:54

いや、素人でしょ？＞彼

556 ：デフォルトの名無しさん：2005/06/27(月) 02:41:46

つまり、アンチがこんなところで必死なのは、自分の思考能力を超えているような概念が流行してしまっては困るからだよ。
過去ログを見てみ。クソみたいな感情論，オリジナリティあふれる稚拙なオブジェクト指向論ばっかで、まともにデザパタを理解しての批判は一つもない。
必死に自分のカスぶりをアピールしているだけということに本人が気付いていないところが滑稽だよなｗ

557 ：デフォルトの名無しさん：2005/06/27(月) 03:28:20

>>555
まぁ、Fランク文系大卒で営業からSEに転向した(もしくはそれに準ずる）という意味ではど素人だわな。

558 ：デフォルトの名無しさん：2005/06/27(月) 03:30:11

ねぇ、ここに粘着してるキミは、
明日の仕事は無いのかな？
つか、未来永劫仕事無いのか？

・・・気楽でいいなぁ、落伍者は

559 ：デフォルトの名無しさん：2005/06/27(月) 03:40:43

>>558
エリート相手に落伍者呼ばわりかよ小アジアの５流NEAT風情がｗ
こっちは日曜日の昼前なの。

560 ：デフォルトの名無しさん：2005/06/27(月) 03:43:03

要するに、海外逃亡したけどやっぱ２ちゃん荒らしが日課の落伍者か

561 ：デフォルトの名無しさん：2005/06/27(月) 03:43:59

ヒント：脳内海外

562 ：デフォルトの名無しさん：2005/06/27(月) 07:21:39

>>554-556
定期的にこういうのが湧いちゃうのは仕方がないのかな？

563 ：デフォルトの名無しさん：2005/06/27(月) 07:48:54

>>562
仕方がないんじゃない？
そう言われても仕方がないのが事実だからね。

564 ：デフォルトの名無しさん：2005/06/27(月) 07:51:04

>>562
>>552

565 ：デフォルトの名無しさん：2005/06/27(月) 10:23:24

>>562-564
(・∀・)

566 ：デフォルトの名無しさん：2005/06/27(月) 13:54:03

>>554-556 >>559
さすがエリート的な発言ですね。
っていうか議論のレベルがアンチ以下のような気がするんですが。
ガキ同志の悪口のいい合いじゃん。
こんなのがエリートだなんて人間終わってるな。

567 ：デフォルトの名無しさん：2005/06/27(月) 14:22:18

かつてのアンチオブジェクト指向スレと同じ流れ
Template Methodパターンかな

568 ：デフォルトの名無しさん：2005/06/27(月) 14:23:16

>>557は認めるのかｗ

569 ：デフォルトの名無しさん：2005/06/27(月) 14:48:00

>>568
それ本人じゃね？

570 ：566：2005/06/27(月) 15:58:08

>>568
むっ？漏れへのレス？本当だ。見逃してますた。

>>569
むっ？漏れへのレス？漏れは>>557はじゃないですたい。

571 ：566：2005/06/27(月) 15:59:39

>>554-557 >>559
というか俺も言い過ぎた。ごめんよう。

572 ：デフォルトの名無しさん：2005/06/27(月) 19:10:15

学生やってる間にあれやこれやと思いを馳せるのはいいことだ。がんばれ。

573 ：デフォルトの名無しさん：2005/06/27(月) 23:52:28

ただ、固定観念にとらわれないように気をつけたほうがいいね。
本当に正しいことなんてそれほどない。
5年たったら評価が真逆になっていたり。

柔軟じゃないと変化についていけないお

574 ：デフォルトの名無しさん：2005/06/28(火) 04:29:22

>5年たったら評価が真逆になっていたり。 orz

575 ：デフォルトの名無しさん：2005/06/28(火) 11:44:54

GoFも５年以上たってるし、
もう海外ではもっとすごい手法が編み出されてるんだろうな。
取り残されているようでｶﾅｼｽ。

576 ：デフォルトの名無しさん：2005/06/28(火) 15:19:05

テクニック　踊らされれば　最先端
うれしや悲し　操り人形

577 ：575：2005/06/28(火) 16:49:00

>>576
まあ、そうだな。
俺は常に良いものを勉強していきたいし。
ある意味、操り人形。

578 ：デフォルトの名無しさん：2005/06/28(火) 18:00:01

>>575
　情動過多による学習障害か？
　>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/14-15 のリンク先を注意深く嫁

579 ：デフォルトの名無しさん：2005/06/28(火) 18:58:30

>情動過多
詳しい意味はしらないけど、
漢字見る限り多分俺それだ…これって病気なのか？

580 ：デフォルトの名無しさん：2005/06/28(火) 19:08:22

リンク先は読んだのか？
早く読め

581 ：デフォルトの名無しさん：2005/06/28(火) 19:20:57

邪魔して悪かった。俺はROMだ。575じゃない。

582 ：575：2005/06/28(火) 19:44:28

>>578
すまんす。漏れは基本的に英語が読めん。
それにそのリンク先も、新しい技術に関する情報であって、良い情報なのかどうかわからん。
新しいからといって良いものとは限らんし。

というか「面白い技術情報は海外にあるけど漏れ英語読めねーし」と諦めたときから学習する気がうせた。

583 ：541：2005/06/28(火) 20:27:26

>>554
×「現実世界をそのままモデル化するのがオブジェクト指向」
○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」

そのままモデル化したら、ある対象物Ａからの構造は１通りに決まりそうだけど、そういうわけにも行かない
モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている

例)
　　java.lang.System.out と System.Console は、両方とも Console への入出力を扱うが、双方には大きな違いがある
などなど

……ってゴメン。書いてて気付いたけど『オブジェクト指向的な構造を考える』って思いっきり『モデル化』だった罠
超訂正

584 ：デフォルトの名無しさん：2005/06/28(火) 20:34:59

似たものを、共通項でくくりひとまとめにするのがオブジェクト指向。

585 ：デフォルトの名無しさん：2005/06/28(火) 20:56:47

>>584
何か違う気がする。

586 ：デフォルトの名無しさん：2005/06/28(火) 21:11:46

>>582
http://pc8.2ch.net/test/read.cgi/tech/1119158274/14で、ドメイン名が jpで終わってるリンクと、
http://pc8.2ch.net/test/read.cgi/tech/1119158274/15のリンクは、
全部日本語のページだ。
早く読め。

587 ：デフォルトの名無しさん：2005/06/28(火) 21:18:29

>>583
>そのままモデル化したら、ある対象物Ａからの構造は１通りに決まりそうだけど、そういうわけにも行かない
>モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている
そんなのお前のレベルが低いからじゃんｗ

>○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」
そんなのまで許しちゃったら、オブジェクト指向（？）で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃないじゃん。

ちゃんと考えてるの？
俺もオブジェクト指向覚えたばかりの頃はそういういらんクラスが出たけど
最近は研ぎ澄まされてきて、そんな必要ない中間クラスはさっぱりでなくなったよ。
単に経験の差のような気がするけどねぇ。

588 ：デフォルトの名無しさん：2005/06/28(火) 21:21:54

>>587
継承も多態もないオブジェクト指向（？）の何が便利なの？

589 ：541：2005/06/28(火) 21:25:20

>>587
＞そんなのまで許しちゃったら、オブジェクト指向（？）で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃない

現実世界とは無関係の物を捏造しろ、とは言っていないんで注意。
大まかな部分は似せろ、細かな部分で調節しろ。

俺は、経験というか世界観の違いのような気がするんだけどねぇ。

590 ：デフォルトの名無しさん：2005/06/28(火) 21:33:56

>>587
　>>49の意味をちゃんと理解しろ、バァァァァーーーーーーカ

591 ：デフォルトの名無しさん：2005/06/28(火) 21:37:04

ノーターリンのOCaml厨は生きとるか？

592 ：デフォルトの名無しさん：2005/06/28(火) 21:37:54

ノーリターンに見えた

593 ：デフォルトの名無しさん：2005/06/28(火) 21:40:03

>>591
　>>591自身の過去レスを厨房呼ばわりする
　>>591の人生って無価値

594 ：デフォルトの名無しさん：2005/06/28(火) 21:41:15

２ちゃんねるの粘着くん(約一名)って、
コンプレックスだらけだな。ｶﾜｲｿ（爆笑

595 ：デフォルトの名無しさん：2005/06/28(火) 21:57:03

>>594
しかし、それでもこっちが本スレっぽくなって、
本スレが過疎スレになってしまう不思議ｗ

みんなどっちが正しいこといってるかなんて感覚ではわかってるんだよ。
だってデザパタっておせじにもわかりやすいとはいえないじゃん。
こういうのは直感が役に立たないもんは流行らないよ。
みんなで使うモンなんだからさ。

596 ：デフォルトの名無しさん：2005/06/28(火) 22:15:11

>>595
http://pc8.2ch.net/test/read.cgi/tech/1119158274/14で、ドメイン名が jpで終わってるリンクと、
http://pc8.2ch.net/test/read.cgi/tech/1119158274/15のリンクは、
全部日本語のページだ。
早く読め。読んだら報告しろ

597 ：595：2005/06/28(火) 23:02:40

>>596
俺は>>582じゃないよー。

598 ：582：2005/06/28(火) 23:13:37

>>596
えっ？いやあの。

１．エンタープライズアプリケーション開発のパターン　by マーチン・ファウラー
これ洋書の紹介だけじゃん。（´∀｀；）

２．マーチン・ファウラー's bliki (blog)
これ更新履歴一覧じゃん（´∀｀；）
ここのは「クロージャ」の説明しか読んだことない。全部読めと？

３．MixJuiceによるデザインパターン改善カタログ
リンク切れしてるじゃん（´∀｀；）

４．AspectJ を使ったデザインパターンの改善と支援
まずアスペクト志向がﾜｹﾜｶﾗﾅｽなので説明がﾜｹﾜｶﾗﾅｽ（´∀｀；）

599 ：デフォルトの名無しさん：2005/06/28(火) 23:14:52

>>590
すごい。中学時代を思い出すかのような素敵なレスだ。

600 ：582：2005/06/28(火) 23:16:32

>>596
いやぁ（´∀｀；）ゞ、ごめんねぇ。

601 ：デフォルトの名無しさん：2005/06/28(火) 23:22:48

>>597
いいからお前も読んどけって。
どうせ頭の中身は >>582とどっこいどっこいだろ？

>>598
おまえには、短い文章の読解力もろくにない事がよく判る。

1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、
　それくらい最低読んどけ。

2. 上記1.の文書が掲載されているblog (bliki)だ。
　気になる文書があったら端から目を通してみろ。
　そうすれば、ここまでレベルの低い会話はしなくて済む。

3. こっち嫁
　http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/

4. なんだよ？結局英語がわかんねぇだけじゃなくて、日本語でも駄目なんじゃねぇか。
　じゃ上の1の本、端から買って嫁。読み終わってから議論しろ

602 ：デフォルトの名無しさん：2005/06/28(火) 23:24:59

最初から学習する気がないのかよ

603 ：582：2005/06/28(火) 23:32:02

>>595
こういっちゃなんだが元々、過疎スレだったのさ（涙

>>601
＞1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、
＞　それくらい最低読んどけ。
>>596のレスにこんな深い意味が込められていたのかーｗｗｗいや冗談です。まあ、買って読んで見ます。

＞2. （略
まあ、これは読む気だった。

＞3. こっ（略
thx

＞4.なん（略
いやぁ。これ全部書き途中＆自分用メモみたいだわ。文章としては非常に読みにくい。
パターン説明の８割がソースコードで解説とかｱﾘｴﾅｽ。ﾜｹﾜｶﾗﾅｽ。

604 ：デフォルトの名無しさん：2005/06/28(火) 23:35:10

語尾「ねぇ。」もNGワードにすべきだと気付いた。

605 ：デフォルトの名無しさん：2005/06/28(火) 23:37:40

>>603
正直に言え。おまえはソースなんてろくすっぽ読めない素人だろ？
証拠のソース出せずに荒れ、UML設計でいいから出せと言われてまた荒れ、
挙句にソースで解説されても判らねぇ？はぁ？

おまえには、ここで議論する資格ねぇんだよ。
さっさと巣に戻って、プルプルプルプル一晩中震えてろって

606 ：デフォルトの名無しさん：2005/06/28(火) 23:39:15

＞ここで議論する資格

（ ´,_ゝ｀）ﾌﾟ

607 ：デフォルトの名無しさん：2005/06/28(火) 23:40:20

クズはさっさと巣に戻れ

608 ：デフォルトの名無しさん：2005/06/28(火) 23:41:21

=================================================================

　　現在、ソースも読めない素人が粘着中です。
　　粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。

=================================================================

609 ：デフォルトの名無しさん：2005/06/28(火) 23:43:11

>>602
そーゆーこと。
さっさとこいつをアクセス禁止にしないと、
プログラム板の荒れが収まりようがない
のは周知の事実

610 ：デフォルトの名無しさん：2005/06/28(火) 23:43:39

↓玄人が一言

611 ：582：2005/06/28(火) 23:43:48

>>601
なにぃ！J2EEパターンとかいう本があったのね。
これはめっさ読みたい。ありがとう。

>>605
おおぅ、なんか荒れてるなぁ（´∀｀；）
漏れはむしろこのスレでソースコード書いてた奴さね。
まあ、議論する資格なさそうだから消えるよ。

612 ：582：2005/06/28(火) 23:44:22

あっ、玄人ゲットｳﾚｼｽｗｗｗｗ

613 ：デフォルトの名無しさん：2005/06/28(火) 23:51:26

議論スレで人に「本読んで勉強してくださいね」ってのは無しだよ。
自分でDLLが無いと動かないＭＦＣアプリ作っておいて
ユーザに押し付けて、動かないのをユーザのせいにする奴とにてるよ。

この場合ってＭＦＣのＤＬＬが無くても動くように作るのが普通だよね？

結局さ、議論スレで強引に自分の気にいった本を読むように押し付ける奴ってこういう奴なんだよ。
俺等が読んで無い本はお前にとってＭＦＣのＤＬＬなんだろ？ｗ
じゃあさ、ＤＬＬが必要なくても動くようにしてこいよｗ

614 ：デフォルトの名無しさん：2005/06/28(火) 23:53:24

>>613
と、ソースも読めない厨房が寝言をほざいてます（笑

無視無視

615 ：デフォルトの名無しさん：2005/06/28(火) 23:54:36

J2EEパターン本すら初めて知った素人>>582が
玄人のフリをする痛いスレ

616 ：デフォルトの名無しさん：2005/06/28(火) 23:55:17

>>604
耳や尻尾をみつけた時は黙って自分の胸に仕舞っとけ。
気付いてる奴はとっくに気付いてて発言者の特定に使ってるんだから
そういう発言は邪魔になる。無くて七癖文章の癖ってなｗ

617 ：デフォルトの名無しさん：2005/06/28(火) 23:58:26

>>613
議論をするにはいくらかの前提が必要だ。敷居と言い直してもいい。
必要と発言するにも、不要と発言するにも、最低限それについて知
っていなければ議論にならない。

618 ：デフォルトの名無しさん：2005/06/28(火) 23:59:22

>>614
図星突かれて、ファビョ（火病）って改行連発しちゃった？

619 ：デフォルトの名無しさん：2005/06/29(水) 00:00:42

なんでわざわざ（火病）ｗ

620 ：デフォルトの名無しさん：2005/06/29(水) 00:01:49

>>617
ＭＦＣのＤＬＬはユーザが自分で入れておくべきだと。そういうことか。
まあ、流行らないものって全部そうだよ。
MSが出したManagedなんとかっていうゴミもこんな感じで流行らないし。
勝手に敷居を作るのはかまわないけど、みんなの同意もなしじゃ
独りよがりと言われてもしょうがないよね？

621 ：デフォルトの名無しさん：2005/06/29(水) 00:03:21

自分が知っていることが常識ですよ。

622 ：デフォルトの名無しさん：2005/06/29(水) 00:05:04

>>617
同意。そして、>>608に賛成。

623 ：デフォルトの名無しさん：2005/06/29(水) 00:05:37

ここの粘着は本当に単純だね。
図星を突かれると、瞬間的に脳が火病って途端に話が非論理的になるからな。

624 ：デフォルトの名無しさん：2005/06/29(水) 00:06:30

>>616
かつての「ねぇ」遣いは、多少マトモな事を言う糞粘着院生だったんだけどねぇ（藁
今の「ねぇ」遣いは、皆が一番嫌っているコテハンの多くを駆使してる基地外だからなぁ（ｗ

625 ：デフォルトの名無しさん：2005/06/29(水) 00:07:35

で？>>596のリンク先文書は読んだ？
さっさと報告しろ

626 ：デフォルトの名無しさん：2005/06/29(水) 00:09:45

>>624
アレは瞬間湯沸かし器だから、一発で判る。
たぶんそのうち、脳溢血で逝くだろう。その日を楽しみにしている。

煽って煽って喧嘩ばかりの荒んだ毎日。可哀想な人生だね。同情するよ

627 ：デフォルトの名無しさん：2005/06/29(水) 00:10:36

>>625
そう人にＤＬＬの挿入を押し付けるなよｗ
俺等が入れたくねぇって言ってるんだから。
むしろてめぇの方がＤＬＬが必要ないように実行ファイル作ってこいよｗ

628 ：582：2005/06/29(水) 00:11:07

>>625
えっ、漏れっすか！
漏れ書き込んでいいんすか！

いやぁ、まだ読んでません。（´∀｀；）ゞ

629 ：デフォルトの名無しさん：2005/06/29(水) 00:11:48

DLLについて議論している粘着(約一名)の方へ

DLLに関する議論はスレ違いです。
適切なスレに移動したらいかがですか？
頭悪いから理解できないかな？

630 ：デフォルトの名無しさん：2005/06/29(水) 00:12:51

>>628
じゃぁさっさと読め。
読み終えるまで発言するな。
他のレス番使った発言も一切するな。

631 ：デフォルトの名無しさん：2005/06/29(水) 00:16:10

>>629
例え話がぴったりだったからそんな的外れないい逃れするの？
君さっき改行連発してた人だよね？
もしかして、ファビョ（火病）った？ｗ

632 ：デフォルトの名無しさん：2005/06/29(水) 00:17:15

>>631
と、ソースも読めない厨房が寝言をほざいてます（笑

無視無視

633 ：582：2005/06/29(水) 00:18:24

>>630
＞他のレス番使った発言も一切するな。
これだけは言わせてもらうけど、漏れずっと名前欄に「582」って入れてる奴だよ。
他は俺の書込みではない。

634 ：デフォルトの名無しさん：2005/06/29(水) 00:19:24

>>633
じゃぁさっさと読め。
読み終えるまで発言するな。

以下、1000番まで同様な繰り返し。(省略)

635 ：デフォルトの名無しさん：2005/06/29(水) 00:20:19

キチガイの相手をするから、スレが荒れるのだと思う

636 ：デフォルトの名無しさん：2005/06/29(水) 00:21:09

>>634
くそ！ＤＬＬが無いと！俺のアプリがうごかねぇよ！
早く入れろよ！馬鹿！
もしかして、ＶＢのランタイムの方？ぷｗ

637 ：デフォルトの名無しさん：2005/06/29(水) 00:22:05

>>635
それがおもしろいんだろ
もう、必死でしょう・・・最近のデザパタ厨

638 ：デフォルトの名無しさん：2005/06/29(水) 00:23:28

相手をしてる香具師はそいつと同レベルだと言うことに気付け

639 ：デフォルトの名無しさん：2005/06/29(水) 00:23:36

=================================================================

　　現在、ソースも読めない素人が、話題をずらそうと必死に粘着中です。
　　粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。

=================================================================

640 ：582：2005/06/29(水) 00:23:55

>>634
君のための議論スレでもないのに自治活動お疲れさん。

つーか、ここはアンチデザパタさんと「デザパタは本当に必要か」議論するスレだと思ったんけど。
このスレに書込むには>>596を読めと？それはアンチデザパタさんが読むかな？
まあいいや、くだらないことだわ。

641 ：デフォルトの名無しさん：2005/06/29(水) 00:26:52

日本語の情報があっても学習する気のないﾔｼが必死に弁解していまつねｗ

642 ：デフォルトの名無しさん：2005/06/29(水) 00:26:56

普通の人間だったら、恥ずかしくて自殺すらしかねない恥をかいているのに、
それでもまだ自作自演で粘着してくる >>582のキチガイっぷりにひどく感心

643 ：デフォルトの名無しさん：2005/06/29(水) 00:29:30

>>640
>それはアンチデザパタさんが読むかな？

それならそれでろくに理解しようともせずにデザパタ不要と喚いてる厨であることがわかるので好都合

644 ：デフォルトの名無しさん：2005/06/29(水) 00:30:51

>>642
人間との言葉のやり取りに激しい飢餓感を感じ、
コケにされてもキチガイ扱いされてもスレにすがりつく疎外された人間
(例: ひきこもり、アル中患者、禁治産者)の類だろ、奴は

645 ：デフォルトの名無しさん：2005/06/29(水) 00:35:34

>>643
てゆうか、はやく学校卒業しろよｗ
みんな深夜まで仕事しててマジでぶっちゃけそんな本読んでる奴いないからｗ
みんなそれぞれ家庭があったり他に趣味があったり、プログラム１つとっても設計に
時間を費やせる奴ってそんなにいないぞ。

２年ぐらいかけてGoF本読むのが精一杯な奴多いんじゃねーかな？（俺は学生の頃読んだけど）

現場でプログラマの仕事の作業量みれば、
こんなの（デザパタ）流行らねーってわかるんだよ。
それじゃなくても不勉強な奴多いのに。
こんなの読むわけないだろｗアフォかっつーのｗ

646 ：デフォルトの名無しさん：2005/06/29(水) 00:44:15

>>645
キチガイの発言の特徴は、時代感覚がズレまくっているあたりだな。

例えば先週か今週、本屋に行って雑誌売り場覗いてれば、
そんなキチガイみたいな書き込みはしないと思うけど。

647 ：デフォルトの名無しさん：2005/06/29(水) 00:45:58

流行る流行らないじゃなく自然に存在してるんだけど・・・・・・
もう最近ではそれと意識されずに使われてる事の方が多い。

648 ：デフォルトの名無しさん：2005/06/29(水) 00:49:04

>>645 プログラム１つとっても設計に時間を費やせる奴ってそんなにいないぞ

素人乙

649 ：デフォルトの名無しさん：2005/06/29(水) 00:51:35

JAVAは特にそうだな＞自然に存在してる
でも、アレは酷だよな。パターンを知らない人間には意図が読めない
から、無駄に持って回った複雑な設計にしか見えない。ｹﾞｷﾑｺﾞｽｗ

650 ：デフォルトの名無しさん：2005/06/29(水) 00:58:24

>>646
まあ、現場で働いてる人間にそんなもん読む暇があるかどうかがわからない人間にはわからないだろうなｗ
たくさんの人に伝えなきゃ意味の無いものはそんなに複雑であっちゃいけないんだよ。
本を読め→読みました！→言っていることがわかりました。
なんて流れなかっただろ？
逆に俺の方から本の推薦をしたら、お前はきっと嫌がるだろう。
そんなこともわからない奴が設計について語ったって役に立たないことはわかるだろ。

誰もついていかないよ。
基本的に嫌じゃん。知識が無いのを馬鹿にされるのって。
必ず自分の知らない分野で仕返しされるじゃん。
個人ってそんなに万能じゃないじゃん。

お前も人を馬鹿にするとき、自分の知ってる分野をあげてそれについて語って、
相手がそれについての知識があさいとここぞとばかりに「勉強してくださいよｗ」とかいって
本を薦めて議論に勝った気になるのよくやってるじゃん。
これってされたほうの気持ち考えたことある？
この先、その調子で仲間とうまくやれる自信ある？

651 ：582：2005/06/29(水) 01:00:43

>>645
まあそうだねぇ。時間ないよなぁ。最近、本買うのも慎重になってきたし。
変な本読まされて時間を無駄にする事ほど苦痛なものはない。
でもデザパタはなかなかいいもんだと思うよ。一部だけのパターンは。

>>649
おお、それ激しく同意。以前、勉強をかねてJavaのソースコード解析してたけど、
Socketクラス辺りとかﾜｹﾜｶﾗﾅｽｗｗｗ(SocketImplとかSocketImplFactoryとかの変なクラス)
デザパタ知ってああそうなんだってすげぇとか感動した。

652 ：582：2005/06/29(水) 01:01:41

>>651
s/一部だけのパターンは/一部のパターンだけは/

へんな日本語になってた。

653 ：デフォルトの名無しさん：2005/06/29(水) 01:09:07

正直、ここの粘着基地外は、在日朝鮮人でしょ。
この腐りきったメンタリティはとても日本人の物とは思えない。

654 ：デフォルトの名無しさん：2005/06/29(水) 01:11:02

自分の嫌いの香具師は全員在日朝鮮人です

655 ：デフォルトの名無しさん：2005/06/29(水) 01:15:08

cppllにOCaml厨が投稿してるが、このスレのOCaml厨とひょっとして
同一人物じゃね？何か直感的にそんな気がした。時期的に一致しすぎてる。

656 ：デフォルトの名無しさん：2005/06/29(水) 01:16:22

>>650
かかって来い(げらぷ
まじ。結構俺って万能なのね、下らない話題以外は

657 ：デフォルトの名無しさん：2005/06/29(水) 01:16:36

>嫌いの香具師は
訂正しる！

658 ：デフォルトの名無しさん：2005/06/29(水) 01:22:58

あとさ、>>650。
社交辞令で「・・・自信ありません」くらいの事を言う可愛げはあるけど、
それが社交辞令だってことくらい、ちゃんと見抜け。
コミュニケーションの為に、相手が想定しているであろうプレゼンをする事で、
たとえそのプレゼンが偽りであっても、以降のコミュニケーションがうまく進む、
そういった効果を狙っているだけだよ、実際。

10年前に嫌々関わったOO分野だが、
いい加減 GoFも流し読みできないレベルの奴と関わるのには飽き飽きした。
もしOO分野に関わるということが、GoFも読めない猿にGoFを説得する事を意味するのであれば、
OO分野にはもうかかわりたくも無い

659 ：デフォルトの名無しさん：2005/06/29(水) 01:29:16

>>658←こいつなんでこのスレにきたの？ｗ

660 ：デフォルトの名無しさん：2005/06/29(水) 01:32:31

>>659
にほんごのどくかいりょくがたりません。もっとがんばりましょう

661 ：デフォルトの名無しさん：2005/06/29(水) 01:37:00

>>655
今cppll探して読んでみたが、実名らしき物をシグニチャに書いてるね。
メルアドも。

違う人だったらいけないのでここには晒せないが、もし本人だったら
間抜け過ぎだね。

662 ：デフォルトの名無しさん：2005/06/29(水) 01:39:50

>>655
cppllってなんじゃらほい。
ここのOCaml厨房は、単にOCamlとMLって単語を連発するだけの池沼だよ。

663 ：デフォルトの名無しさん：2005/06/29(水) 01:42:29

>>662
http://www.tietew.jp/cppll/
ここ。
C++のML。
後は悪いけど、自分で探してちょ。ヒントは、ごく最近の投稿。

664 ：デフォルトの名無しさん：2005/06/29(水) 01:42:45

>>662
むしろ >>655, >>651あたりが
この板でOCaml厨と呼ばれている厨房の希ガス

665 ：デフォルトの名無しさん：2005/06/29(水) 01:46:16

だいたい、国立情報学研究所の人間捕まえて、
OCaml厨呼ばわりするのもなかなか厨房じみた妄想だ。

今現在２ちゃんで、「ML」と「OCaml」というキーワード使って荒らしやってるのは、
かつてRubyやHSPで荒らしやってたキチガイだろ。

666 ：デフォルトの名無しさん：2005/06/29(水) 01:47:56

>>663
http://www.tietew.jp/cppll/archive/12065
こいつのことか？

667 ：デフォルトの名無しさん：2005/06/29(水) 01:51:40

ま、しかし、2chのム板を見ても、OCamlなんてマイナー
な言語について熱く語る香具師は、数えるほどしかいないね。

２ｃｈ内なら同一人物の可能性もあるけど。だからどうしたって
聞かれると、別に何もないけどな。

668 ：デフォルトの名無しさん：2005/06/29(水) 01:54:04

>>666-667
そうかぁ？
俺が学生の頃は、Haskelｌが動くPCなんてなかったから、
OCamlかGoferで自己学習・・・ってのがデフォだったけどね。

669 ：デフォルトの名無しさん：2005/06/29(水) 01:54:46

>>666
明らかにレベルが違うじゃん。
そもそもの不満点(というか単なる愚痴に見えるが･･･)からして、コードが
書けない人間からは決して生まれない類のものだし、その改善法と問題
点も把握できてる。
具体的な事は何一つ書けない某彼と一緒にするのは、あまりにも酷だ。

670 ：デフォルトの名無しさん：2005/06/29(水) 01:58:44

>>655, >>651, >>667＝OCaml厨本人

理由：OCamlに関する話題は、全て同一人物が行っていると妄想する程のキチガイだから。

671 ：デフォルトの名無しさん：2005/06/29(水) 01:59:26

Haskellって言うとghcしか知らないけど、なかなか面白いや。

672 ：デフォルトの名無しさん：2005/06/29(水) 02:00:55

>>671
具体的に何が面白いか、説明してみな。

673 ：デフォルトの名無しさん：2005/06/29(水) 02:10:52

>>672
それが人に物を聞く態度かい。横柄な奴には教えてやらないよ。ベーだ。

674 ：デフォルトの名無しさん：2005/06/29(水) 02:12:29

黙ってりゃ書いてたものを。>>672みたいなのをやぶ蛇って言うんだ。覚えとけ。

675 ：デフォルトの名無しさん：2005/06/29(水) 02:22:38

>>650
あなたの発言は、一昨日昼飯を一緒に食った人物と同じ、
特徴的な思考パターンが見られるので、非常に興味深い。

その件について、いずれ話し合おう

676 ：デフォルトの名無しさん：2005/06/29(水) 02:25:58

>>671, >>673-674のような低レベルな奴が現れるのと同じタイミングで、
>>650が現れるのは、非常に興味深い現象である。

677 ：デフォルトの名無しさん：2005/06/29(水) 02:27:56

あ、それから、もしHaskellについて判りやすい説明が必要なら、
それも今度説明しましょう。リアルの方で

678 ：デフォルトの名無しさん：2005/06/29(水) 09:12:14

>>675
リアルで特定されてる？ﾜﾛﾀ!!

679 ：デフォルトの名無しさん：2005/06/29(水) 12:42:54

話し戻すけど、技術の流行り廃れはメディア上の現象で、
実際にソース組む人の立場になれば、未だに構造化手法も
有効だし、オブジェクト指向も大切だし、デザインパターンも、
亜蛇煎るプログラミングも有効だし、UMLも有効だし、
フローチャートも有効だし、ウォータフォールモデルも有効だし、
データモデリングも有効だし、どれ一つを取っても捨てていい
技術は無いんだよね。

もちろん、今時フローチャートでシステムレベルの記述を
する事は避けた方が良いし、フローチャートじゃあ記述出来ない
けれど、メソッドの中の人を記述する必要が有る時にはやっぱり
フローチャートが一番しっくりくるし、メソッド一つ一つを見れば、
構造化で培ってきた関数化の技術が生きるしさ。

新しい技術は取り入れるもので、捨て去るのはなかなか難しいよ。

もちろん、GoFのパターンカタログを一生懸命勉強すればデザインパターン
を身に付けられると思う馬鹿は、幸せに生きてれば良いけど。

680 ：デフォルトの名無しさん：2005/06/29(水) 13:28:15

#フローチャートは23年前に捨てましたが何か？

681 ：デフォルトの名無しさん：2005/06/29(水) 13:29:09

うちの大学では今まさに教えられてますが orz

いらねーよこんなの orz

682 ：デフォルトの名無しさん：2005/06/29(水) 13:31:58

アクティビティ図の練習だと思ってガマンしなよ・・・

683 ：デフォルトの名無しさん：2005/06/29(水) 13:37:45

>>679
お前何才よ？ロートルプログラマか？ｗ
年取りすぎて会社じゃもうどこも雇ってもらえないから、家で妄想の毎日か。

684 ：デフォルトの名無しさん：2005/06/29(水) 14:40:13

>>683
679じゃないけど、結構あるよーこういう現場。
まだ679は新旧混合で選択しようってんだからいい方だよ。

685 ：デフォルトの名無しさん：2005/06/29(水) 14:47:14

フローチャートはちとキツイ。
あれはホントにお絵かきで終わっちゃうからなぁ。

PAD図だったらプログラムの構造が保たれているからまだマシなんだけど。
# でも実際には使ってないけどね。

UMLのクラス図なんかもリバースエンジニアリング出来ないとお絵かきで終わっちゃう。

686 ：デフォルトの名無しさん：2005/06/29(水) 19:22:49

フローチャートって、ループすらマトモに書けないじゃん

はっきり言ってアセンブラならまだしも
今時の高級言語なら、フローチャートに落とすことによって
何かがわかりやすくなったりすることはありえない

687 ：681：2005/06/29(水) 20:35:12

まあ、機械語を扱う部分で出てきたんで、何とか我慢できるんですが……

C で PAD を教えてきた先生も居たけど、ぶっちゃけ PAD だと関数出てきたあたりからお手上げ状態
構造化チャートは、オブジェクト指向まで考えるともう使えないでし

折角なんで愚痴らせてもらうと

　ハード系の某先生「これからは最低でもオブジェクト指向が出来ないと」

んで、出てきたのがコレ

　class Sample {
　    public void input(String filename) { /* filename で指定したファイルを読み込む */ }
　    public void process() { /* input で読み込んだデータを処理 */ }
　    public void output() { /* process で書き換えたデータを表示する */ }
　}

……まあ、若い先生方にはしっかりした人が多いんで、まだ救いがあるんですが OTL

688 ：デフォルトの名無しさん：2005/06/29(水) 21:44:54

>>679
結構同意。

689 ：デフォルトの名無しさん：2005/06/29(水) 22:22:42

構造化もOOもデザパタも勉強してみると実は現場で似たような事やってた
ってオチがままある

690 ：デフォルトの名無しさん：2005/06/30(木) 01:12:18

>>679
状況によっては古い技術の方が、効力を発揮したりするしね。
色々な知識を持って、あらゆる状況に対応できることが大切だと思う。

691 ：デフォルトの名無しさん：2005/06/30(木) 01:27:38

>>689
Cで構造体のメンバとして関数ポインタ持たせて
偽多態みたいなのは良くやるが、
クラスや継承までエミュレートしたことはないなあ。
後、構造体の先頭レイアウトだけ合わせてポインタ渡しとかはありがちだな。

なんかOOというより苦し紛れのテクニック、という気分もするが。

692 ：デフォルトの名無しさん：2005/06/30(木) 01:30:06 BE:84286962-

>>691
Cしか使えない現場なの？

693 ：デフォルトの名無しさん：2005/06/30(木) 01:37:35

>>692
少なくとも俺が入社したころ（そんなに昔ではないのだが）は
Windows3.1、VC++1.0が現役だったし
C + SDKで組まれてるプログラムが珍しくなかったんですわ

694 ：デフォルトの名無しさん：2005/06/30(木) 01:39:02

あと、apacheのモジュールみたいなso作ったりとか、
その手の仕事はCが普通じゃまいか。
別に制御屋さんとかじゃなくてもC触る機会、結構あるでよ。

695 ：デフォルトの名無しさん：2005/06/30(木) 02:03:20 BE:42143832-

なるほど、昔の話か。今となってしまっては
よほど速度や資源を求めない限りはCオンリーは嫌ぽ。

# apacheのsoはよくわからんす。

696 ：デフォルトの名無しさん：2005/06/30(木) 02:19:55

>>695
apacheのモジュールは、いわゆるプラグインみたいなもんだす。
soはshared object(library)、いわゆるDLLね。

アプリじゃなくてDLL書く場合はCで書くことは珍しくないと思うよ今でも

697 ：デフォルトの名無しさん：2005/06/30(木) 02:28:33

>>696
DLL書く場合でもC++のが楽でいい。

698 ：デフォルトの名無しさん：2005/06/30(木) 02:32:47

>>697
C++だとスタートアップコードが必要になったりしてちょっとヤじゃない？
もともとC++用のDLLならいいけれど

Cインタフェースを公開するDLLなら、Cで書いて、しかもlibcに依存しない
形にしたい

699 ：デフォルトの名無しさん：2005/06/30(木) 08:39:28

Cしか使えないならCを使うけど、積極的に使おうと思うものじゃないよあれは。
一刻も早く地上から消え去って欲しい。

700 ：デフォルトの名無しさん：2005/06/30(木) 09:42:29

>>699
Cと一緒にお前も消えろ。

701 ：デフォルトの名無しさん：2005/06/30(木) 14:20:49

なんでもデザパタに当てはめないと設計できなくなったら終わりだな。
というか、あーでもない、こーでもないって、
ころころ設計変えるのが、楽しいのに。
漏れの楽しみ取らないでくださいよ。

702 ：デフォルトの名無しさん：2005/06/30(木) 14:36:11

>>701
いもしない人間を想定して適当なことを言うのはやめましょう

703 ：デフォルトの名無しさん：2005/06/30(木) 15:11:34

>>687
学生時代、pad2psというソフトをつかってソースからPAD図生成してました。
レポート書くのに助けられたなぁ・・・今は使ってないけど。

704 ：デフォルトの名無しさん：2005/06/30(木) 21:03:09

いくらJavaやC#でオブジェクト指向だなんていっても、メソッドの中では構造化の知識がいるだろ。
５行で終わるようなものを５０行ぐらいかけてなにやってんだか分からないようなダサダサソースはうんざりするでしょ。

705 ：デフォルトの名無しさん：2005/06/30(木) 21:17:37

構造化分析と構造化プログラム設計と構造化コード

706 ：デフォルトの名無しさん：2005/07/01(金) 01:45:06

>>699
それはCも使えてないってことだろ。

707 ：デフォルトの名無しさん：2005/07/01(金) 02:00:07

今からここはCの素晴らしさを褒め称えるスレになりますた

708 ：デフォルトの名無しさん：2005/07/01(金) 09:37:08

>>706
じゃあおまいさんはC++もjavaもC#も使えるような環境において積極的にC言語を選択するか？

709 ：デフォルトの名無しさん：2005/07/01(金) 10:05:40

たいていの言語はC言語やC言語のライブラリが土台になってるから消え去ってもらっては困る

710 ：デフォルトの名無しさん：2005/07/01(金) 17:07:33

>>708
1)shell等の外のプログラムから部品として呼び出すことを想定したコマンド・
　フィルタ風のプログラムなら、少なくともJavaやC#は「絶対に」使わない。
　ツールボックスアプローチの部品としては、起動遅いのは致命的。

2)C向けのDLLは大抵Cで書くな。
　libc使ってしまうと、クライアントコードとlibcのバージョン合わせる必要が
　生じてウザい。これ、Win32の話ですが。

3)俺は書かないけど、オープンソースでなるべく広い環境で使われたいと願う
　コードを記述するなら、Cのが今でも多いだろ。環境をそもそも特定できない
　から、だが。

711 ：デフォルトの名無しさん：2005/07/01(金) 17:09:10

>>710
なるほど。そうかそうか、よーくわかったぞ。それは面白い考えだ。

712 ：デフォルトの名無しさん：2005/07/01(金) 17:28:26

>>711
せっかく真面目に答えてやっとるのになんだ、その人を小ばかにしたような
態度は。それで優位に立ってるつもりなのかね、チミは。
反論があるならもっとマジメにやれ。

713 ：デフォルトの名無しさん：2005/07/01(金) 18:14:36 BE:70239252-

C++でDLL作ったことないので深く突っ込めないんだけど、
インターフェースはCで提供して、
実装はC++ってのもやっぱ無理ですか？

714 ：デフォルトの名無しさん：2005/07/01(金) 18:19:01

>>712
だってお前の意見になんか全然興味ないもん。

715 ：デフォルトの名無しさん：2005/07/01(金) 18:33:41

>>713
可能か不可能かといえば可能。extern "C"すればいいだけだから。

716 ：デフォルトの名無しさん：2005/07/01(金) 18:34:20

>>714
なら下らん一言でスレ汚さずに単にスルーしろよ

717 ：デフォルトの名無しさん：2005/07/01(金) 18:39:47

>>716
うるせぇーよ。ぼけ、氏ね　(　´∀`)

718 ：デフォルトの名無しさん：2005/07/01(金) 18:46:30

そういえばツールボックスアプローチってデザパタ厨的にはどうなのよ

719 ：デフォルトの名無しさん：2005/07/01(金) 19:27:28 BE:70239825-

>>715
それでも>>710の言うようなlibcのバージョン合わせる必要ありますか？

>>718
嫌いじゃないが。

720 ：デフォルトの名無しさん：2005/07/01(金) 20:36:27

>>718
OOPな時点でツー～ーチなん違うん？

721 ：デフォルトの名無しさん：2005/07/01(金) 20:46:21

>>719
libcのバージョンは、合わせる必要はある。Cを使おうがC++を使おうが
関係ない。Cの方がlibc非依存にしやすいというだけ。

たとえばDLLが(VC++6以前の)MSVCRT.DLLを利用しているならば、
クライアントプログラムもMSVCRT.DLLを用いなければならない。

ま、実際には合わせなくとも動作する場合もある。DLLのインタフェース
や何やってるかによるんだが。
ファイルポインタ、ファイルデスクリプタ、ロケール、errnoのような
CRTオブジェクトの受け渡し、あるいは一方でmalloc()したメモリの
他方でのfree()、といったことをやる場合は、バージョン合わせないと
完璧にマズい。

722 ：デフォルトの名無しさん：2005/07/01(金) 21:05:28

>>720
UNIXのツールボックスアプローチってのは、シェルという糊言語を用いて、
部品になる小さくて独立したプログラム群を組み合わせることで
仕事を実現する手法のことなんだが。

プログラムが分かれてるから完全に疎結合。で、標準入出力、パイプ、
コマンドライン引数、戻り値といった単純でwel-definedな仕組みを用いて
それを組み合わせていく。

概念的にはOOとは全く関係ないし、Smalltalkとか見ても、OOはむしろ
モノリシックで巨大なものを指向する傾向があるんじゃないか。
むしろLISPに似ているというか。

723 ：デフォルトの名無しさん：2005/07/01(金) 21:17:37

>>722
＞概念的にはOOとは全く関係ないし

疎結合という面と、独立したプログラムという面から見て、オブジェクト指向に通じる物があるかと思ってた

724 ：デフォルトの名無しさん：2005/07/01(金) 21:20:50

>>722
クラスは>>722の中段で書かれてる要素を全て満たしてると思う。
「である。」とは思わないけど、「の様な振る舞いを持たせる事もできる。」と思う。

725 ：デフォルトの名無しさん：2005/07/01(金) 21:53:44

Javaで実装されたシェルもあるね、実用上は使い物にならないと思うけど。
コマンドパターン風に実装したクラスがプログラムのかわりで、
それを実行時ロードとかまあそんな感じかな。

726 ：デフォルトの名無しさん：2005/07/01(金) 21:58:22

本当にそんなんなのか？

727 ：デフォルトの名無しさん：2005/07/01(金) 22:02:59

>>726
すまん大して興味が無いのでちゃんと見てないんだが

要するに、コマンド実行するたびにVMロードされちゃたまらんワケで、
同一VM上でコマンドを実行するのが、Javaで「使い物になる」シェル風の
環境を作る大前提。
find . -name '*.html' -exec rm {}
とかそんなことをやると、それこそうんざりするほど大量の子プロセスが
生成されて実行されるのがシェルの世界だからな。

その辺は、antのタスクの考え方と同じ。要するに、インタラクティブに
実行できてmake作業に特化してないant＋αみたいなもんじゃないかな。

728 ：デフォルトの名無しさん：2005/07/01(金) 22:11:51

tclとかはシェル風のごく単純なグルー言語＋コマンド関数の世界だが
あれはCで書かれてるから、Javaみたいに実行時ロードできないんだよな

ってどんどんスレ違いの世界に

729 ：719：2005/07/01(金) 23:46:32 BE:210717465-

>>721
なるほど、ありがとん。たぶん将来とても役立つ知識になった。

730 ：スレ違いですが：2005/07/02(土) 01:06:25

Javaベースのシェルかぁ。

・こんなんあったね。漏れも一個くらいはインストールした覚えがある。

JDistro jsh : A Un*x-lke shell written in pure Java. Java Web Start対応
　　http://www.jdistro.com/jsh/

COLLIN Gerard's jsh: the opensource java application launcher !　Java Web Start対応
　　http://gerard.collin3.free.fr/

TeaShell: 複数のJavaアプリケーションを一つのJavaVMで動かすJavaシェル
　　http://www.vector.co.jp/soft/other/java/se089271.html

・その他国内某所で Java シェルOS開発というスレが立ち上がってるのを発見したんだけど、
　そこの1、一体何作ろうとしてんのか、よくわかんないや(OSによらず使い慣れたシェル環境を提供するって何？)

・JDK1.6では、Oracle JavaVM流のapplication partitioningの仕組みが導入されるそうなんで、
　JavaVMプロセスを多数起動しなくても、いろいろな事がやりやすくなるね。(本来はAppServer向け機能だけど)

731 ：デフォルトの名無しさん：2005/07/02(土) 01:17:07

>>730
少なくともこのスレと関連のあることをいってくれないと。
リンクの貼り付けだけだと荒らしに見える。

732 ：本ｽﾚ住人：2005/07/02(土) 04:01:40

わるいね。
UNIXシェルとコマンドによる祖結合プログラミングは、
デザインパターンと並んでソフトウェア工学上重要な話題です。

Javaにおいてどのような試みがなされているか、
そして、Javaサーバ～Webサービスの基盤 (アプリケーション・パーティショニング)が、
UNIXシェルの基盤にもなりうる、という話題を振ったつもりですが。
もしかして、ここは似非スレだから、似非話題以外はスレ違いなのかな（藁

733 ：デフォルトの名無しさん：2005/07/02(土) 08:27:03

>>730
>OSによらず使い慣れたシェル環境を提供するって何？
OSによるshellの方言を吸収しようという意味じゃないすか。

734 ：デフォルトの名無しさん：2005/07/02(土) 11:19:11

>>732
>デザインパターンと並んでソフトウェア工学上重要な話題です。
だから何？ｽﾚ違いに変わりない事に気付けよバカ。

735 ：デフォルトの名無しさん：2005/07/02(土) 12:29:02

>>734
気付いてないのは恐らく君だけ

736 ：デフォルトの名無しさん：2005/07/02(土) 13:17:27

>>732
早く本スレ帰ればいいじゃん。
過疎スレ帰れよｗ
＃デザパタなんてどうせやってる奴いないからこないだろうけどｗぷｗ

>>731と>>734は別人ね。俺は>>731。

737 ：デフォルトの名無しさん：2005/07/02(土) 14:58:05

本当に隔離スレだな
どうでもいいレスでageてるし

738 ：デフォルトの名無しさん：2005/07/02(土) 15:56:53

糞な香具師だらけだから、糞スレになるのは当たり前

739 ：デフォルトの名無しさん：2005/07/02(土) 16:17:40

>>737-738
じゃあ、早く本スレ帰んな。

740 ：デフォルトの名無しさん：2005/07/02(土) 16:18:59

ω日本のハッカー、今立ち上がれ！！！！
http://pc8.2ch.net/test/read.cgi/pcnews/1120271067/

また中国です。

741 ：152：2005/07/02(土) 16:23:42

>>740
　そんなことしてる暇あるならコード書けってかんじだよなぁ

742 ：デフォルトの名無しさん：2005/07/02(土) 16:44:15

>>740
それ、東アジアニュース+でガイシュツだよ。
中国と韓国からのケーブルは切断しなきゃダメだね。

743 ：デフォルトの名無しさん：2005/07/02(土) 17:20:28

Javaで動くシェル作るぐらいなら、オールJavaのOS作れ。

744 ：デフォルトの名無しさん：2005/07/02(土) 19:21:30

>>740
なんつーか、どっちも死ねよと。

745 ：デフォルトの名無しさん：2005/07/02(土) 21:52:29

……………　く　ず　れ　す　……………

746 ：デフォルトの名無しさん：2005/07/03(日) 18:40:06

プログラム板が荒れているため、IDを導入するか検討中です。
賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。

プログラム技術板に強制ID制を導入すべきか否か
http://etc4.2ch.net/test/read.cgi/vote/1118144381/

理由などの記入は別に構いません。
<<賛成>>か<<反対>>かだけ御記入頂ければ結構です。
ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。

747 ：デフォルトの名無しさん：2005/07/10(日) 14:08:52

本スレが伸びてると思ったら、
ここに粘着してた頭のおかしいデザパタ信者が集中砲火浴びたっぽいなｗ
いつも都合の悪い話題が出ると自分の発言を軌道修正するから
あいつ嫌われるだろうなと思ったら滅多撃ちにされてるなｗ

748 ：デフォルトの名無しさん：2005/07/10(日) 14:35:43

伸びてるも何も2005/07/08(金) 12:50:07から書き込みがないぞ？

749 ：デフォルトの名無しさん：2005/07/10(日) 16:25:41

>>748
いや、向こうのスレで

2005/06/23(木) 23:12:19

周辺から糞化してたから見て無かったんで・・・

750 ：デフォルトの名無しさん：2005/07/10(日) 16:28:28

>>749
つか、あのスレ自体、信者vsアンチの構図が無くなった時点で全く意味がない。
デザパタ自体は誰も仕事でなんか使ってないから、デザパタ自体のことを語るのはおもしろくない。

751 ：デフォルトの名無しさん：2005/07/10(日) 17:21:15

バカ粘着スレ

仕事してる俺たちゃ、
あんたみたいな無職野郎と違って
暇じゃないのよ

752 ：デフォルトの名無しさん：2005/07/10(日) 20:26:09

>>750
J2EEアプリやったことがないのに
＞デザパタ自体は誰も仕事でなんか使ってない
なんて断言するなよ。無知丸出し。

753 ：デフォルトの名無しさん：2005/07/10(日) 20:33:18

J2EE だけじゃないんですが

JavaAPI のレベルでも、既にパターンを見つけることも出来るんですが

754 ：デフォルトの名無しさん：2005/07/10(日) 20:42:17

>>753
APIで使われているかどうかじゃなくて、自分が作成するアプリの設計に適用するかどうかを言ったつもりだった。
まあ、ヤツはJavaすらやったこと無いんだろうけど。

755 ：デフォルトの名無しさん：2005/07/10(日) 20:53:25

>>754
ああん了解

756 ：デフォルトの名無しさん：2005/07/10(日) 21:04:29

ファクトリやストラテジ、アダプタなんかは趣味グラムでも多用するぞ。
もっとも、趣味グラムの場合、単に完成を急ぎたいからそうするだけな
んだけど・・・・・・要はcommons-loggingの悪用と同じ。

詳細決まってないとこは空箱でも詰めとけｗ

757 ：デフォルトの名無しさん：2005/07/10(日) 21:06:19

> デザパタ自体は誰も仕事でなんか使ってない

誰もというのは言いすぎだが、ほぼ正しい。

１．使ってないやつ　70%
２．使ってプロジェクトに混乱を起こすやつ　25%
３．正しく理解して設計に応用するやつ　5%

もちろん俺は３

758 ：デフォルトの名無しさん：2005/07/10(日) 21:09:59

ネタスレだから、低レベルな奴しか居ないというのには同意。

759 ：デフォルトの名無しさん：2005/07/10(日) 21:13:49

JAVA前提の職業プログラマに限れば
１．使わされてる奴：70%
２．使わせてる奴：20%
３．（ﾟдﾟ）ﾎﾟｶｰﾝ：10%

もちろん俺は１orz

760 ：デフォルトの名無しさん：2005/07/10(日) 21:20:25

「知らずに使ってる奴」も居る筈

761 ：デフォルトの名無しさん：2005/07/10(日) 21:27:59

>>760
大規模プロジェクトでは「知らずに使われてる奴」は多そうだね。

762 ：デフォルトの名無しさん：2005/07/10(日) 21:38:19

デザインパターンなんて基本的に不要でつね。
継承、多態なんてまずは使わないで設計できるかを考えるべき。
その上で、どうしようもない場合は、継承、多態を使う。
で、継承、多態を使う場合も、基本的なTemplate Methodとかはともかく、
基本的にデザパタは使わないで設計を考える。
それでも必要の時だけデザパタを使うと。
極力シンプルを目指して、リファクタリングをして、継承、多態を減らすと。
つまり、デザパタは基本的に不要！

763 ：デフォルトの名無しさん：2005/07/10(日) 21:41:19

>>762
＞どうしようもない場合は、継承、多態を使う

「構造が簡潔になる場合は～」に訂正して欲しいこと以外は同意

764 ：デフォルトの名無しさん：2005/07/10(日) 21:47:17

デザパタは認めないのにリファクタリングはOKなんですか？

765 ：デフォルトの名無しさん：2005/07/10(日) 21:48:27

>>762みたいなのは、コンテナ依存のコンポーネントのモックテストなんてやったことないんだろうな。

766 ：デフォルトの名無しさん：2005/07/10(日) 22:42:49

さすが隔離スレだな。
1987 OOPSLAのGamma以前のレベルで進化が止まってるわ。
>>765
あんたもデザパタなんて保守的な事言わず、J2EEパターン、.NETパターン、PoEAAにESBって
どんどん話題振らなきゃ。

767 ：デフォルトの名無しさん：2005/07/10(日) 22:53:18

＞J2EEパターン、.NETパターン、PoEAAにESB
それらはデザインパターンとは呼ばないのか？

768 ：デフォルトの名無しさん：2005/07/10(日) 22:54:37

「デザイン」の「パターン」ならば「デザインパターン」なんだろうな

769 ：デフォルトの名無しさん：2005/07/10(日) 22:57:07

http://www.microsoft.com/japan/msdn/practices/Type/Patterns/enterprise/
によれば、パターンの適用範囲はデザインだけではないね

770 ：デフォルトの名無しさん：2005/07/10(日) 23:08:00

>>767
一応、口ではそんなんデザパタに含んでると反論するが、
実際のパターン名はシングルトンにファクトリー、テンプレートメソッドくらいしか出てこないのが、
隔離スレ・クオリティ（藁

771 ：デフォルトの名無しさん：2005/07/11(月) 01:10:18

本スレもそうだけど、君ら自慢と煽り合いが大好きね('A`)
議論を持ち出せば「お前、レベルが低い」とか、馬鹿だなんだと罵り、
どこのサイトのなんの記事を熟読してから書き込めなどといって書き込み排除。
別にいいじゃんレベル低かろうが。

もっと気軽な議論スレがほしい。
正直この状態じゃ何も議論できない気がする。
デザパタ初心者スレでも建てっかな。

772 ：デフォルトの名無しさん：2005/07/11(月) 01:11:57

そしてまた増えるデザパタスレ（過疎）

773 ：デフォルトの名無しさん：2005/07/11(月) 01:13:16

>>762
デザパタ => オブジェクト指向
に変えても読めてしまう。

そういうことですか？>>762

774 ：デフォルトの名無しさん：2005/07/11(月) 01:35:37

>>771
>正直この状態じゃ何も議論できない気がする。
お前の脳みそはまだそんなこと考えてるのかとｗ

>>757
>３．正しく理解して設計に応用するやつ　5%
これは嘘。
5%もいるわけない。
デザパタはネタ。
実際のプロジェクトでは使ってるところは存在しない。

775 ：デフォルトの名無しさん：2005/07/11(月) 01:37:22

>>771
何のための隔離スレだかわかってる？

776 ：デフォルトの名無しさん：2005/07/11(月) 01:43:27

＞実際のプロジェクトでは使ってるところは存在しない。
そんなわけない。
俺がいる会社でも使ってるし、知り合いのいる会社でも普通に使うし。
ホントに無知だな。かわいそうに。

777 ：デフォルトの名無しさん：2005/07/11(月) 01:56:08

>>775
はじめはアンチだけをここに隔離する目的だったんだけど、
アンチがいなくなったら本スレが過疎スレになっちゃったから今となっては微妙一色ｗ

折角、隔離スレとしてアンチ同士で楽しくやろうと思ってたのに
本スレが過疎スレになったから信者がこっちにまできて非常に邪魔。

はっきりいうけど、本スレが盛り上がらないのは、
本当はデザパタなんて誰も使ってないから、話す話題がない。

技術としても不確定で誰が正しくて間違っているか特定させる手段が無いから、
パターンブームにのってエセ研究者気取りがいいたい放題。

議論も「いかにして相手を言い負かすか」が焦点になっててまったく本質に触れようとしない。

>>776
君こそ、知らないの？
デザパタなんて狭い世界の話なんだよｗ

778 ：デフォルトの名無しさん：2005/07/11(月) 01:56:48

>>776
そんなにいうなら本スレ盛り上げてきてよｗ
ま、誰もこないだろうけどさｗ

779 ：デフォルトの名無しさん：2005/07/11(月) 02:10:51

>>777
「存在しない」から「狭い世界」へ修正ですか？ｗ
次は「特定の分野では使われている」に修正して
さらには「○○では使われていない」に修正ですか？
どこかの議員さんみたいですね。

780 ：デフォルトの名無しさん：2005/07/11(月) 02:11:39

>>778
だって、使って当たり前、使われ方もほぼ決まっているのに何を今更議論するのさ？

781 ：デフォルトの名無しさん：2005/07/11(月) 02:13:08

>>777
＞はじめはアンチだけをここに隔離する目的
ちがうだろ？
デザパタが必要か要らないかの議論をするのがこのスレの目的。
本スレはデザパタありきでの議論が目的。

782 ：デフォルトの名無しさん：2005/07/11(月) 02:37:38

本ｽﾚが寂れたのは、頭がおかしい人物が荒らしまくって、良心的な人々を遠ざけたから。
荒らし風情がひらきなおるんじゃねぇ～よ、クズめ

783 ：デフォルトの名無しさん：2005/07/11(月) 02:40:48

>>771
某スレで、またぞろakon叩きするバカが発生してたけど、
あんたらのコミュニティは一体どうなってるの？

784 ：デフォルトの名無しさん：2005/07/11(月) 02:47:10

未だにパターンに無理やり当てはめて類型化することをパターンを使うと表現している人がいるのか

785 ：デフォルトの名無しさん：2005/07/11(月) 02:59:15

おまいはすっこんでろ

786 ：デフォルトの名無しさん：2005/07/11(月) 03:10:49

>>784 はほとんど宗教じみているな

787 ：デフォルトの名無しさん：2005/07/11(月) 03:14:46

ＧＨＧＨ

788 ：デフォルトの名無しさん：2005/07/11(月) 03:36:40

>>771
そーゆー前向きな活動は本来、
ML上で署名付きで行うべきものではないか？
その署名が偽りであったとしても、誰も気付かないのだし。

匿名掲示板で本音のぶつかり合いを期待するのは、
虫のいい考えだと思う。blog立てろよ(ｵﾚﾓﾅｰ

789 ：788：2005/07/11(月) 03:43:05

特に２ちゃんは、平日昼間から深夜まで例の粘着が
　・情報システム板
　・プログラム技術板
　・プログラマー板
　・ゲーム製作板
　・セキュリティ板
　他
を常時巡回して荒らしをやっているんで、
多くの人が、ここではもうコミュニケーションが機能しないものとして見放している。

考えても見ろよ、あれだけあちこちで話題になっているRubyのスレが
この板に一個もない。原因は何故だと思う？
例の粘着とおぼしき人物が「Rubyキチ」とかいうコテハンで何年もしつこい荒らし行為を行って、
さすがのMatzも手を引いたからだ。

こんなゴミタメで、鬱憤晴らしと気まぐれな独り言以外、何ができようか？
なんちゃって

790 ：788：2005/07/11(月) 03:46:34

>>771
ちょっと考え直してみたら、俺もよくわけの判らんレスを付けてしまった。
貴方が「気楽に議論できるデザパタスレが欲しい」と思うのなら、立てたらいい。
掲示板のスレ立て制限以外、誰もスレ立てを制限する事などできないのだから。

791 ：デフォルトの名無しさん：2005/07/11(月) 07:20:45

>>780
その割には本スレで馬鹿と盛り上がってたじゃんｗ

792 ：デフォルトの名無しさん：2005/07/11(月) 07:39:21

馬鹿はどこにでもいるし、どうしようもない議論で盛り上がるさ。
こっちでもあっちでもまともな議論はできていない。

793 ：デフォルトの名無しさん：2005/07/11(月) 07:48:40

>>792
>こっちでもあっちでもまともな議論はできていない
まともな議論なんて無駄。
デザパタ自体の存在意義について触れた時点で荒らしがはじまる。

794 ：デフォルトの名無しさん：2005/07/11(月) 08:24:22

きっと、役立たずの人間にとっては、
世の中に役に立つ概念があるというだけで、
腹が立つんだろうね(藁

795 ：771：2005/07/11(月) 14:41:48

>>790
新しいスレ建てるほどのことではないんだよね。
ほぼ重複だし。叩かれそう。なのでやっぱりいいです。

>>792
馬鹿でも、どうしようもない議論でもいいじゃないか。
そこをおまいのような理解してる奴がうまく啓蒙してあげればいいんじゃないか

>>793
まあ馬鹿同志、無駄な議論してるんで生暖かく見守っててくだされヽ（´ー｀）ﾉ

796 ：デフォルトの名無しさん：2005/07/11(月) 14:55:10

こっそりとID導入待ち

797 ：デフォルトの名無しさん：2005/07/11(月) 15:11:19

IDが必要なのはこのスレだけだろ。他の板逝ってやれ。
他の人が迷惑する。

798 ：デフォルトの名無しさん：2005/07/11(月) 15:28:47

プログラムに関係ないことをプログラム板以外でやれと？どっちが迷惑だか。

799 ：デフォルトの名無しさん：2005/07/11(月) 15:30:24

プログラムのことを、だ。

800 ：デフォルトの名無しさん：2005/07/11(月) 16:53:59

じゃあ、ID出てしかもコテハン専用のプログラム板作ってもらえよ。
お前のルールに他の人間を全部従わせるつもりか。カス。

801 ：デフォルトの名無しさん：2005/07/11(月) 17:03:49

クオリティ低いな

802 ：デフォルトの名無しさん：2005/07/11(月) 17:41:48

>>797
>IDが必要なのはこのスレだけだろ。
そうでもない。

803 ：デフォルトの名無しさん：2005/07/12(火) 23:36:08

隔離スレに来てる肯定派のアフォども、元気か。
本スレ盛り上げろよな。まあ、おまえらアフォどもには無理だろうけど。

804 ：デフォルトの名無しさん：2005/07/12(火) 23:45:43

必要って言うか、なんていうか。
こんなやり方あるんだね、みたいな。そんな軽い気持ちで使えばイイんじゃねーの？
ほとんどの場合でそのまま使えねーんだし。

805 ：デフォルトの名無しさん：2005/07/13(水) 00:21:37

>>803
お前ほどアフォではない。残念。

806 ：デフォルトの名無しさん：2005/07/13(水) 00:24:52

＞＞８０３
おまいほど暇人でわない

807 ：デフォルトの名無しさん：2005/07/13(水) 00:35:21

>>803
元から話題が無い（涙

808 ：デフォルトの名無しさん：2005/07/13(水) 00:41:35

>>807
まぁ話題がない、などと言う奴は中身からっぽなんだろうが。
Martin Fawlerの一連の著作やら、DSLやMDAとの絡みやら、
設計レベルのパターン言語について語るべき事はたくさんある。
問題は、書き込みが少ないこと。

809 ：デフォルトの名無しさん：2005/07/13(水) 00:42:58

Fowlerな。
あと、書き込み少ないって、某荒らしが粘着してるネタスレと比較しての話だ。
某荒らしが一切書き込みをやめてくれれば、また盛り上がれるスレだと思うよ。

810 ：デフォルトの名無しさん：2005/07/13(水) 01:16:57

>>805-809
やはりお前らアフォどもに本スレを盛り上げるのは無理ってことだな。
隔離スレで内容のない話をしてろ、アフォども。

811 ：デフォルトの名無しさん：2005/07/13(水) 02:14:11

>>810
勝利宣言か。本当に日本人ですか？

812 ：デフォルトの名無しさん：2005/07/13(水) 23:08:14

盛り上げるもなにもデザパタ使ってる奴なんてハナっから存在しない。
信者だって本当に実在しているのかも疑問。

813 ：デフォルトの名無しさん：2005/07/14(木) 11:18:53

>>812
>デザパタ使ってる奴なんてハナっから存在しない。
という事にしないと、理解できない自分がｶﾜｲｿｽ、と。

814 ：デフォルトの名無しさん：2005/07/14(木) 11:40:11

井の中の蛙もいいところ

815 ：デフォルトの名無しさん：2005/07/14(木) 12:57:25

こないだつかった。

816 ：デフォルトの名無しさん：2005/07/14(木) 20:00:39

俺なんか飯のときにも使ってる

817 ：デフォルトの名無しさん：2005/07/14(木) 21:14:38

>>815
シングルトンはもういいってｗ

818 ：デフォルトの名無しさん：2005/07/14(木) 21:44:28

>>817
君がそれしか知らないのは判ったから。

819 ： != 815：2005/07/15(金) 00:47:16

>>817
このスレの住人ってくだらない煽りヤロウばっかりだな('A`)

820 ：808：2005/07/15(金) 01:30:19

同意。つか、これが例の情報システム板のスレでバカなレスばかり付けている「出張３２」ですよ

821 ：デフォルトの名無しさん：2005/07/15(金) 07:45:18

>>819
オマエモナーｗ

822 ：819：2005/07/15(金) 09:59:55

>>820
いや、あの、きみの>>808の一行目のレスするあたり対してレベルが変わらない気がｽ('A`)
きみのその一言がなければ、おお。とか思った。思われただろうに。
つか、>>820自体のレスも対してレベ（略

>>821
（ﾟ∀ﾟ）ｵｳﾖ!!

823 ：デフォルトの名無しさん：2005/07/15(金) 11:06:37

>>817
Abstract Factoryでした。
まあこれも使いやすい方なので
じまんにはならんでしょうけど！

824 ：デフォルトの名無しさん：2005/07/15(金) 14:35:21

>>821
釣られて出てくる「くだらない煽りヤロウ」。

825 ：デフォルトの名無しさん：2005/07/17(日) 18:36:19

ふと思い立ったんだが、アンチデザパタさん達の中でも、
interpreter パターンを知らずに使ってる人は意外と多いかもしれない

なにせ、
Window_X = 120
Window_Y = 100
とかの初期化用スクリプト組んで、config.ini って名前付けるけでも interpreter の思想は受け継がれているからな

【この程度の事で interpreter パターンなどと勿体ぶった言い方を俺はしたくないですが】

826 ：デフォルトの名無しさん：2005/07/17(日) 21:32:52

>>825
お前は本当になにもわかってねぇウンチングスタイルだな。

827 ：デフォルトの名無しさん：2005/07/17(日) 22:26:33

はぁ。インタープリタ・パターンねぇ。
再帰下降型パーサなら簡単に書けるけど、
正規表現のように状態遷移マシンつかったり、
JavaやCのようにあるていど大きな規模の構文を効率的に扱うには、
ちょっと寸足らず・・・
つか、実装は別の方法でやって、表面的なインタフェースはinterpriterパターンといったところか。

ってGoFがゆってた

828 ：825：2005/07/18(月) 18:30:54

っていうか interpreter パターンって
『処理内容のハードコーティングを避け、必要ならカスタマイズ可能に』
ってのが第一条件で、別に実装方式は問わなかった筈

その気になれば BF を組み込む程度でも interpreter になりそうで

829 ：デフォルトの名無しさん：2005/07/18(月) 18:35:17

BFでカスタマイズする処理系ｽｺﾞｽ

830 ：デフォルトの名無しさん：2005/07/18(月) 22:39:54

BF？！
BNF (Backus-Naur Form)じゃなくて？

831 ：デフォルトの名無しさん：2005/07/18(月) 22:48:10

BF
http://pc8.2ch.net/test/read.cgi/tech/1036013915/l50

832 ：デフォルトの名無しさん：2005/07/19(火) 00:19:44

Boy Friend

うほっｗｗｗ

833 ：デフォルトの名無しさん：2005/11/24(木) 02:13:02

ＭＶＣとかって本当に必要なの？
開発ってか設計がめんどうなんだけど・・・

834 ：デフォルトの名無しさん：2005/11/24(木) 08:00:24

>>833
VCしかないシステムの拡張やらされた時には前任者に殺意を覚えたぞ。

835 ：デフォルトの名無しさん：2005/11/24(木) 08:35:41

>>833
一度、プログラマが10人以上いるプロジェクトで
すべての処理を一つのクラスにつっこむ実装をしてみるとわかるよ

836 ：デフォルトの名無しさん：2005/11/24(木) 14:05:48

>>9
> デザパタで成功してるのはstlのイテレータくらい。
なんでイテレータだけなんだ？
JavaのIteratorのほかにObserver、I/OのDecoratorとかはどうよ？

> MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
> どうしてもキショイコードになる。

837 ：デフォルトの名無しさん：2005/11/24(木) 16:50:37

MVC ってさ、

M：機能本体
V：出力
C：入力と制御（メインループとか）

で良いの？
正直、よく分からんのだが・・・

838 ：google って知ってる？：2005/11/24(木) 19:03:03

>>837
調べる気のない人は
一生解らないままでいて下さい。

839 ：デフォルトの名無しさん：2005/11/27(日) 01:16:05

>>838
ﾋﾄﾞｽ

840 ：デフォルトの名無しさん：2005/11/27(日) 08:33:23

>>839
デザパタ信者ってこんなのばっかだよ。
教えないんじゃなくて「知らない」or「自分の勝手な解釈で覚えたと思い込んでる」から説明なんてできない。
もし、説明なんかして他の人間と解釈が違っていたら、自分が理解していないことがばれちゃうから、
そういう危ない橋は渡らないのが奴等の処世術。
デザパタなんてオブジェクト指向すら無視してるんだから、当然オブジェクト指向すら理解してない。
で、なんだかんだ苦しくなると「デザパタは全く新しい～」とか御馬鹿なこと言い出す始末。
これが前スレからの流れ。

841 ：デフォルトの名無しさん：2005/11/27(日) 08:49:45

　　　　　　 /:
　　 ∧∧ /　 :
　　(,,ﾟДﾟ/　　 :
＿ / つ/）＿　　:
～（⌒）__）　/|　,, :　　
￣￣￣￣￣|/,,,　　　　
　　　　　　　　～～～～～～～～～～～

842 ：デフォルトの名無しさん：2005/11/27(日) 15:34:19

>>837==>>840
による自作自演か。

>>838の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね。

843 ：デフォルトの名無しさん：2005/11/27(日) 16:04:25

>>838==>>842
による自作自演か。

>>840の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね

844 ：デフォルトの名無しさん：2005/11/27(日) 17:29:00

まてまて
調べても理解出来なかった　というパターンもありうる。

845 ：デフォルトの名無しさん：2005/11/27(日) 17:33:38

>>844
我々は選ばれた人間なのですね！

846 ：デフォルトの名無しさん：2005/11/27(日) 22:59:43

一人で書くなら不要
一人神グラマがいれば、そいつを基準に周りがまねたら良いから不要
一人ではまだ頼りない感じの人達をまとめ上げるために必要なものだ

847 ：838：2005/11/28(月) 12:18:29

>>843
> >>838==>>842
残念ながら違いますよ。間抜け。

> ちょっと調べればMVCで実際に設計する方法がわかるのにね
判っているなら、そうしなさい。

848 ：839：2005/11/30(水) 23:48:07

>>844 調べてわかったけど釣り発言してみよう　というパターンもあり、えない
>>845 ！
>>847 ｵﾄﾅｹﾞﾅｻｽ

849 ：デフォルトの名無しさん：2005/11/30(水) 23:57:52

850 ：デフォルトの名無しさん：2005/12/01(木) 05:51:30

M　マゾな
V　vsialbasic使いは
C　CやC♯は使えません。

MVCで
webは何となく分かるけど
javaのクラス設計で考えたら
Vはインターフェイスとして
Mが実装で
Cはインスタンス化＝利用するクラス？
結城先生の本買った方が良いのかな・・・・
高いしな
　

851 ：デフォルトの名無しさん：2005/12/01(木) 07:53:24

あのころのおれならＭＬですまーとにかいたんだけどねｗ

852 ：デフォルトの名無しさん：2005/12/04(日) 21:08:41

strategy パターンって単なるコールバックじゃんｗｗｗ

853 ：デフォルトの名無しさん：2005/12/04(日) 21:17:04

そうだが……何か辛いことでもあったのか？　俺でよければ相談にのるぞ？

854 ：デフォルトの名無しさん：2005/12/04(日) 23:05:16

良スレあげ

855 ：デフォルトの名無しさん：2005/12/09(金) 00:50:56

>>847 >>842

> >>837==>>840
も実は違うんだが・・・

ちょっとからかっただけ
オマイってからかうとオモシロイナw
必死に反応してくれてw

856 ：デフォルトの名無しさん：2005/12/09(金) 10:59:08

釣り宣言キタコレ

857 ：デフォルトの名無しさん：2005/12/10(土) 00:21:15

まあ　隔離スレなんだから、こんなんばっかだろ。
頭のいい奴は、つられたりしないわけだから
気をつけてればいいのさ

858 ：デフォルトの名無しさん：2005/12/11(日) 17:38:28

852>strategy パターンって単なるコールバックじゃんｗｗｗ

同感です。昔、GOF 本を読んでクラスを使って実装した strategy パターンのコードを単純化して言ったら、関数ポインタの設定値の切り替えだけになっちゃいました。

それから GOF 本を真剣に読む気持ちがなくなりました。

859 ：デフォルトの名無しさん：2005/12/11(日) 17:58:58

>>858
デザパタの存在意義が「技術ブレークスルー」だと勘違いしている
馬鹿がまた一人。

860 ：デフォルトの名無しさん：2005/12/11(日) 17:59:31

>>852,858
デザインパターンに過剰な期待をしていないか？
「単なる○○じゃん」「同感」という発言は、
デザインパターンの目的・役割を取り違えてないか？

デザインパターンは、別に
「そこらのエンジニアが考えつかないような素晴らしい夢のパターン集」
でもなんでもないぞ。
誰でもやっている・よく使われる設計手法に名前を付けてカタログ化したものでしかない。
エンジニア間の共通認識化・共通語化するのが目的。

861 ：デフォルトの名無しさん：2005/12/11(日) 18:14:57

指きたす同様デザインパターンって言葉を使いたがる人たちがいるだけだろ

862 ：デフォルトの名無しさん：2005/12/11(日) 19:33:05

例えばJavaDoc に
　・・・
　このクラスはGoFの○○パターンの××です．
　@see □□
　@see △△
とか書いて有ればクラス図見なくても設計意図と構造が解る

ってのもデザインパターンとして用語と設計が定義して有るおかげよね．

863 ：デフォルトの名無しさん：2005/12/11(日) 19:40:58

>>862
ぶっちゃけ言いたい。

構造が分かっても用途が分からないドキュメントは糞。

864 ：デフォルトの名無しさん：2005/12/11(日) 20:16:20

＞とか書いて有ればクラス図見なくても設計意図と構造が解る
　　　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣
＞構造が分かっても用途が分からないドキュメントは糞。
　　　　　　　　　　　　￣￣￣

ここでもエンジニア間の共通認識化・共通語化をする必要がありそうだな

865 ：デフォルトの名無しさん：2005/12/11(日) 20:24:19

デザインパターンは、単なるカタログです。

共通的に使える設計で出てくるパターンは、
資産化しなさいよーという教えです。

866 ：デフォルトの名無しさん：2005/12/11(日) 20:28:27

完全にデザインパターンにマッチする方が少ないんじゃない？
適用できるなら適用すればいいだけかと

867 ：デフォルトの名無しさん：2005/12/11(日) 21:01:21

>>863

詭弁のガイドライン
6.一見、関係がありそうで関係のない話を始める
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する

あたりか

868 ：デフォルトの名無しさん：2005/12/11(日) 21:02:12

>>863
>構造が分かっても用途が分からないドキュメントは糞。

そんな当たり前のことを偉そうになに突っ込んでるんだよｗ

869 ：デフォルトの名無しさん：2005/12/11(日) 21:23:54

>構造が分かっても用途が分からないドキュメントは糞
まんまデザパタのことだな。

870 ：デフォルトの名無しさん：2005/12/11(日) 21:27:25

…………俺、爆弾投下しちゃったっぽいな

871 ：デフォルトの名無しさん：2005/12/26(月) 18:26:38

で、隔離スレが出来たら本スレがほんとに落ちちゃったわけか･･･

ここのアンチの人ってオブジェクト嗜好だよね。
憂鬱本読んでわかった気になってるパターンか。

872 ：デフォルトの名無しさん：2006/02/21(火) 23:48:17

ちょっとデザインパターンからはずれてしまうんですが、
内部設計というか、プログラムのインターフェース設計ってどうやってます？

自分の経験では、共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
簡単にいうと、こういうことです。

処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）のように１つのメソッドで処理Ａ～Ｃを行い、どれを行うかは引数で指定する）。
ただし、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品を作るべきだが、
大元の処理は分けて実装すべきだった。

なんで、こんな失敗するんでしょう？
最初からＡ～Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ～Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。

皆様どうやって設計してますか？

873 ：デフォルトの名無しさん：2006/02/21(火) 23:49:16

872の続き

けれど、「想定外」のことを想定して設計なんてできないんですよ。

皆様どうやって設計してますか？

874 ：デフォルトの名無しさん：2006/02/21(火) 23:59:09

2行しか読んでないけど
>どれを行うかは引数で指定する
これが間違ってると思う

875 ：大根：2006/02/22(水) 00:00:29

>>874
ご回答ありがとうございます。
すいません、新スレ立てさせていただきました。
デザインパターンとは違う話題なので。。。

876 ：デフォルトの名無しさん：2006/02/22(水) 16:53:47

そういや、デザパタスレなくなったな。悲しいことだ。

877 ：デフォルトの名無しさん：2006/02/23(木) 18:31:51

昔から俺がやってた手法に勝手に名前つけられただけ

878 ：デフォルトの名無しさん：2006/02/23(木) 18:48:42

未だに>>877みたいな勘違いをしている奴がいるんだな。
名前を付けて普及させ、技術者間の共通認識にするところまでやってはじめて価値が出る。
どんなに優れた設計でも『オレ様パターン』じゃ意味ないんだよ。

879 ：デフォルトの名無しさん：2006/02/23(木) 19:12:09

>>878
その点において最大の価値がある。

>>877
全パターンをただ一人で考案した
というのはとても信じられない

880 ：責任転嫁マン：2006/02/24(金) 01:07:28

じゃあ、このスレで900を取った奴がデザパタスレ建ててくれ。
確か、５スレ目まで言ってたので、「【GoF】Design Pattern 6」とかで。

881 ：デフォルトの名無しさん：2006/02/25(土) 00:39:28

まだ、こんなスレあんのか？
デザパタなんて使ってる会社無いっていってるだろ。
だいたいGoF本なんてもう絶版だろ？ﾜﾛｽ
オブジェクト指向が理解できない奴ほど食いつくんだよな
いい加減にオブジェクト指向理解しろって
オブジェクト指向言語がメジャーになってから何年経つんだよﾃﾗﾜﾛｽ

882 ：デフォルトの名無しさん：2006/02/25(土) 00:47:09

J2EEパターンを知らない奴がまた現れたのか。
JavaでサーバサイドシステムをJ2EEパターンを使わないで作ってる会社なんて無いよｗ

883 ：デフォルトの名無しさん：2006/02/25(土) 00:54:09

>>882
はぁ？なにそれ？

884 ：デフォルトの名無しさん：2006/02/25(土) 01:39:23

>>883
「？」の後は１つ空白を入れろ　話はそこからだ
ただし」が続く場合はいらないぞ

885 ：デフォルトの名無しさん：2006/02/25(土) 02:42:03

>>884
うるせえよ
氏ね

886 ：デフォルトの名無しさん：2006/02/25(土) 10:49:04

>>883
言われたとおりに書いてればおｋなドカタには不要なモノだよ

887 ：デフォルトの名無しさん：2006/02/25(土) 10:56:55

まあれだ、デザパタってのはプログラマに対して、
コンビニのアルバイトみたいに、接客対応マニュアル
を用意してくれたってことでしょ

888 ：デフォルトの名無しさん：2006/02/25(土) 12:43:07

デパガがトイレに行く事を棚卸してきますとか言うだろ？
共通の認識がないとこういう符丁は成立しない。デザパタも似た様なもんだｗ

889 ：デフォルトの名無しさん：2006/02/25(土) 18:16:18

一人プロジェクトでメンテも自分以外やらない、つー場合でもメリットある？
あるなら本でも読んでみようという気になるかも

890 ：デフォルトの名無しさん：2006/02/25(土) 18:35:05

>>889
こうしてこっちはあーしてこういう風に作ろう　が　これしよう　と単純に考えられる
ライブラリでデザインパターンになってるものがあるから、それを簡単に理解できるようになる

891 ：デフォルトの名無しさん：2006/02/25(土) 19:02:37

考察段階でつまずいたり時間がかかったりすることは
ほとんどないしなあ。今ひとつ食指が動かない

892 ：デフォルトの名無しさん：2006/02/25(土) 19:24:15

http://pc8.2ch.net/test/read.cgi/prog/1140795650/2
　　, -‐－-､　　ヽ∧∧∧ //　　|
. 　/////_ﾊヽ＜釣れた！＞　ハ
　ﾚ//ｊけ ,fjlﾘ　/ ∨∨V ヽ　　h. ﾟl;
　ﾊｲｲﾄ､"ヮノﾊ　　　　　//　　　|::: ｊ　　｡
　 /⌒ヽヾ'ﾘ、　　　　　// 　　　ヾ､≦ '
.　{ 　　j｀ｰ' ﾊ　　　//　ヽ∧∧∧∧∧∧∨/
　ｋ～'ｌ　　ﾚﾍ. 　 ,r'ス　＜初めてなのに　＞
　 |　ヽ＼　ト､ヽ-kヾｿ　＜釣れちゃった！＞
.　 l　　＼｀ｰ‐ゝ-〈/´　　　/ ∨∨∨∨∨∨ヽ
　　l 　　 `ー-､___ﾉ
　　ﾊ　 ´￣｀　〈/‐-､

893 ：デフォルトの名無しさん：2006/02/25(土) 19:42:26

>>891
考察段階でつまずくんじゃなくて、考察内容自体を短縮するんじゃないか？

894 ：デフォルトの名無しさん：2006/02/25(土) 20:53:19

例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）

こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
んだけど。

895 ：デフォルトの名無しさん：2006/02/25(土) 20:56:16

>例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
>動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
>思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
入るわけない
誰がそんなこと言ったの？

896 ：デフォルトの名無しさん：2006/02/25(土) 20:57:45

だから、それじゃあ学ぶ価値なんかないよ。一人でやってる限りは。

897 ：デフォルトの名無しさん：2006/02/25(土) 21:05:59

デザパタの使い道がわかっていない典型だ

898 ：デフォルトの名無しさん：2006/02/25(土) 21:30:33

だから一人プロジェクトでの効能をｷﾎﾞﾝ

899 ：デフォルトの名無しさん：2006/02/25(土) 21:41:49

10ステップの命令文を1つの関数にすれば、関数の名前だけで内容が一気に把握できる
そういうことが本当に分からないなら勉強する気も起きないだろうしやんなくていい
釣りかな

900 ：デフォルトの名無しさん：2006/02/25(土) 21:51:18

そんなことは百も承知だけど例えとしてそういうもんなのか？
無限の関数名が出来そうだけど

901 ：デフォルトの名無しさん：2006/02/25(土) 22:04:06

>>898
「こういうときはこうする」というチップス集としても役立つ。
自分で考える手間が減るだろ？

専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
機能として実装するだろ？
そういう部分で「よくやる手法」としてのチップス集にはなる。
あるいは機能の重複をどう効率よく実装するか、とか。

・・・無理矢理かな？

902 ：デフォルトの名無しさん：2006/02/25(土) 22:11:07

なんねぇんじゃん。
変数名をプロジェクトで決まった用語のローマ字方式でつけてて
開発の途中でダサいって理由で英語で付け変えた変数名も、
誰も読めないって理由で結局対応表が必要になった。

これはデザパタにもいえることだけど余計な手間増やしてない？
みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
その説得力は無いも同然。

デザパタがいいという人間はデザパタを知ってる人間とかしか開発がしたくなくなるとかいう呪い付き。
やっぱり駄目じゃねぇのかな？

903 ：デフォルトの名無しさん：2006/02/25(土) 22:16:55

>>901
＞専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
＞機能として実装するだろ？

この辺がどう効率的になるのかわかんないんだ。現状でもコーディング
の時間以外はコストかからんしライブラリやフレームワークがあればそれ
も軽減できる。

＞「こういうときはこうする」というチップス集としても役立つ。

チップスの数って数えられるほどに押さえられるもんなのか？

そういわれると問題に対して適用する手法はそんなにない
ような気もしてきた。

904 ：デフォルトの名無しさん：2006/02/25(土) 22:59:21

>>900
無限ってことはないでしょ　使われなくなったら消えるし
良く使われる部分にそれがあると楽になるんじゃないか

良く使われる部分でもその名前が知られてなければしょうがないというのは……
まあ自分で考える時に使うということで
gotoよりforループだ　ってぐらいのものじゃないと意味がないってことか？

905 ：デフォルトの名無しさん：2006/02/25(土) 23:20:01

>>904
>gotoよりforループだ　ってぐらいのものじゃないと意味がないってことか？
そう。
プロジェクトで結構手間がかかるのは
個人個人の認識の仕方を確認し、それを共通認識までもってくことだからな。
その手間をぶっちぎって、「デザインパターン読んでください」なんて突き放してうまくいくわけがない。

中国語と英語を話す国に
「今日から日本語が母国語になります。ええ、決まったことですからしょうがないですね。」
なんてふっかける行為となんら代らない。

906 ：デフォルトの名無しさん：2006/02/25(土) 23:21:10

＞ライブラリやフレームワークがあればそれも軽減できる。
それこそがデザパタの適用ｗ

907 ：デフォルトの名無しさん：2006/02/25(土) 23:22:01

＞無限ってことはないでしょ
これはなんとなく分かるけど

＞使われなくなったら消えるし
＞gotoよりforループだ　ってぐらいのものじゃないと意味がないってことか？
スマンが何を言ってるのか不明。

908 ：デフォルトの名無しさん：2006/02/25(土) 23:22:12

たしかに日本語のテキストなんかもたくさん出てるだろうし、
勉強する環境やらお金やらは問題ないかもしれんだけどやるか？やらんだろ？

909 ：デフォルトの名無しさん：2006/02/25(土) 23:25:47

＞＞ライブラリやフレームワークがあればそれも軽減できる。
＞それこそがデザパタの適用ｗ

おれデザパタとか意識してないよ。

こういうときはこれ（ライブラリでも手法でも）を使う、ってのは
大概苦労せずに出てくるけど

910 ：デフォルトの名無しさん：2006/02/25(土) 23:25:51

＞アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
＞その説得力は無いも同然。

わかってんじゃん。

＞みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
＞そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。

俺の周囲は常識としてあたりまえに知っているけどな。
デザパタを知らないDQNばかりの開発者だらけの現場だとそうなる。

･･･とは言え、分野にもよるのだろう。
J2EEアプリの開発者達は知っていて当たり前。知らなければDQNと言われても仕方ない。
他の分野だとJ2EEアプリほどアプリ全体の作りがパターン化しないと思われるから
デザパタが普及する必要性は低くなるだろう。

911 ：デフォルトの名無しさん：2006/02/25(土) 23:31:49

>>910
J2EEなんて狭い世界にしかいないからそんなんなんだよｗ

912 ：デフォルトの名無しさん：2006/02/25(土) 23:54:14

データ構造には名前が付いてる。スタックだとかツリーだとかリストだとか？
アルゴリズムにも名前が付いてる。バブルソートだとかクイックソートだとか？
OODにも名前を付けてみた。それがデザインパターン。

>>905
デザパタがあるから不親切なのか？不親切な奴はデザパタの有無とは無
関係に不親切だぞ？
もしデザパタがなかったなら、ソース読めと突き放されるだけだと思うが？

全部暗記しないと話にならない？ありえん。
全てのデータ構造を知ってるか？全てのアルゴリズムを知ってるか？
少なくとも俺が知る限り、そんな奴はいない。

重要なのは、名前は目次になるってこと。
名前を得られれば、その実装なり実装例なりを得られる。ないと困るだろ？

913 ：デフォルトの名無しさん：2006/02/26(日) 01:05:34

>>907
使われなくなったら消えるっていうのはそのままだ
誰も使わないデザインパターンは消え去るでしょ？　言葉と同じ

gotoとforループは機能と認知度のことで例としてあげた
gotoでforと同じ機能が実現できるけど、forを使う
それは便利で、そして誰でも知ってるからか　という話

そんなに分かりにくかったかな……

914 ：デフォルトの名無しさん：2006/02/26(日) 01:44:57

>>912
>ないと困るだろ？
別に困らない。
むしろ、勝手に名前をつけて共通認識にもなってないのに使ってくる奴のがウザイ。

915 ：デフォルトの名無しさん：2006/02/26(日) 01:58:36

自分の知ってることが全て　俺が知らないことは言うな
ってやつもウザイ。

916 ：デフォルトの名無しさん：2006/02/26(日) 03:15:27

>>915
でも、仕事でそういう状況のときってどうするのが適切なのかな？
例えば、
Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはステートパターン」
Ｂ：「なにそれ？」
Ａ：「デザインパターンという・・・というわけですよ」
Ｂ：「なんかよくわからないけど、そのパターンがどうしてここで使っててそれで間違った組み方じゃないって言えるの？」
Ａ：「だから、デザインパターンの・・・はこういう・・・のときに使うのが・・・なわけですよ。」
Ｂ：「どして？さっぱりわかんね。そもそも、そのステートパターンとかよくわからないし。何がよくてどうしてそのパターンを使いたいの？」
ってなったときね。
ここで本を渡して「はい、自分で勝手に調べてね」っていうとすげーヤナ奴じゃない？
上司でもないのに変な用語使って勝手に仕事増やしてる痛い奴であることに間違いは無いよ。
やっぱり無難にそのパターンの詳細を説明することになると思うけどそれだと別にそのクラスの仕組みを説明すればいいんであって
べつにパターンとかいう必要ねぇし。と思う。
これってデザパタ知ってる奴同士でも同じじゃね？

917 ：デフォルトの名無しさん：2006/02/26(日) 03:40:56

Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはステートパターン」
Ｂ：「なるほどね」

- 完 -

918 ：デフォルトの名無しさん：2006/02/26(日) 03:42:02

>>916
それ、前提が間違ってるわ。
配列で済むとこにリスト使ってたら、そりゃただの馬鹿だろ？
デザパタも同じで、不要なとこで使ってたらただの馬鹿だ。

試しにさ、リストを使う妥当な理由があるという前提の下で
リストを知らない者にリストという単語を使う事なくそのデー
タ構造を説明するというシチュエーションで話作ってみてよ。

919 ：デフォルトの名無しさん：2006/02/26(日) 03:42:14

J2EEってそんなに狭い世界なのか？

920 ：デフォルトの名無しさん：2006/02/26(日) 04:17:28

自分はもっといろいろ知ってるんだぜ！って言いたいんだろｗ

921 ：デフォルトの名無しさん：2006/02/26(日) 05:09:22

>>916
クラスの仕組みを説明したときに、それにこういう名前がついてるっていえばいいんじゃないか？
名前の説明が追加されても大差ないし、次があれば楽に説明できる

それとその例だとAさんが説明したのにBさんが分かってないようだが
Aさんの説明が悪いか、Bさんに理解する気がないかのどちらかだ

922 ：デフォルトの名無しさん：2006/02/26(日) 08:51:14

>>918
916じゃないけどやってみた

Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはリスト構造」
Ｂ：「なにそれ？」
Ａ：「要素をインデックスじゃなくて、次へのポインタで指すデータ構造です」
Ｂ：「……ああなるほど、これだとデータ挟んだり抜いたり、配列でやりにくいことが楽に出来るんだ」

例えが分かり易すぎて引き合いにはなりませんですた。

デザパタが物議をかもすのは、ひとつの名前に対しての内容が
人によってはアンバランスに感じるほど詰まってるからじゃねーの？

おれはデザパタ知らん人間ね。

923 ：デフォルトの名無しさん：2006/02/26(日) 08:51:24

共通の名前ってーのも一理あると思うが、デザパタって「システム」という大枠を
どのように細分化していくかって話もあるだろう？　（つまり境界線をどこに引くか）

>>894
＞例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
＞動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
＞思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）

そういった思考手法そのものが手に入るのではなく、そういった思考手法と他の機能が
どのように連携するのかを考え、適切なクラス分割が行えるようになる。
例えば、将来的に音声認識アルゴリズムを（クラスを追加するだけで）ばっさり他のものと
入れ替えることが簡単に行えるようになるわけ。

＞こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
＞んだけど。

ソフトが行っている内容は考察するほどもない簡単なものかもしれんが、
将来どういった仕様変更があるのか（どの部分を入れ替えられるようにするのか）について
は色々考えるべき点が多いぞ。

924 ：デフォルトの名無しさん：2006/02/26(日) 09:02:06

>>923
＞入れ替えることが簡単に行えるようになるわけ。
別にデザパタ知らんでも簡単に入れ替えられるんだな。

＞将来どういった仕様変更があるのか
仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。

つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
組み方してるんだろう。

素直に組んでれば改変追加etc、何も問題ないと思うんだけど。

925 ：デフォルトの名無しさん：2006/02/26(日) 09:20:16

>>924
＞別にデザパタ知らんでも簡単に入れ替えられるんだな。

そういう人にとってはデザパタって「共通の名前」という以外の意味はないんでしょうな。

＞仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。

その「面倒くさいなぁ」ってーのはどんな感覚？
Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？
Ａの機能を呼び出したりする部分を一切変更することなく、Ｂの機能を実現したクラスの
追加だけで対応できているんであれば、あんたはかなりの実力者だ。

＞つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
＞組み方してるんだろう。

仕様変更が起こった場合、変更とは直接関係のない部分（上記で言うところのＡの機能を
呼び出している部分）まで修正が及ぶため、そこも含めてテストをやり直さなければなら
なくなるのが普通。　これによって工数が無茶苦茶増える。

＞素直に組んでれば改変追加etc、何も問題ないと思うんだけど。

客先からの要求ヒアリングでも、「どこに仕様変更が起こりそうか」なんてことは
ほとんど聞けないのが実態。　素直に組むことで問題が解決される例はほとんどない。

926 ：デフォルトの名無しさん：2006/02/26(日) 11:14:54

>>925
＞その「面倒くさいなぁ」ってーのはどんな感覚？
単に仕事が増えてゴルア。精神的な問題のみ

＞Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？

クラスかどうかはともかく、変更の規模によって

・Aを多少改造（現機能も維持したまま条件判断で追加のケース）
・Aをまるまる残してBを追加。

関係ないけど、どっちのケースもAの動作はとりあえず残しておく。
元に戻したい時ってのは常にあるから。容量が厳しい場合はケースバイケース

＞変更とは直接関係のない部分（Ａの機能を呼び出している部分）まで修正が及ぶ

AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
変えたところをテストするのはしゃーないじゃん

まったく関係ないところはあたりまえだが変更など皆無。

＞「どこに仕様変更が起こりそうか」予測できない
だから、変更を許容せよ、がおれの組む時の一番頭にあること。

プログラムを仕事にしてから一番学んだのはそれだね。

927 ：デフォルトの名無しさん：2006/02/26(日) 11:58:16

ソース管理ツールくらい使ってるだろうし、
戻すなんて手間じゃないだろうに。

…じゃなくて。冷静になろう。
話がデザパタから微妙にずれてきてる。
これはニュアンス的にはリファクタリングのネタだよな。

928 ：925：2006/02/26(日) 12:11:13

>>926
＞ AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。

そうとも言えないんじゃない？
AとかBとかの機能と、それを呼び出す部分のインタフェースをうまく設計すると
AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
無くなるわけです。
さらに、Aのインスタンスを生成する部分に工夫を加えておくと、設定ファイルを
いじるだけでAのインスタンスでもBのインスタンスでも生成できるようになるん
ですな。　コードに手を加える（修正する）必要が無くなるんです。

＞変えたところをテストするのはしゃーないじゃん
その通り。　だから修正部分が減るとテスト工数が激減することになる。

＞だから、変更を許容せよ、がおれの組む時の一番頭にあること。
デザパタ（というかオブジェクト指向原則の多く）が言っているのはまさにそこ。
変更を許容する以上、変更点を局所化することこそを考えるべきではないで
しょうか？

929 ：デフォルトの名無しさん：2006/02/26(日) 12:14:07

>>927
＞話がデザパタから微妙にずれてきてる。
＞これはニュアンス的にはリファクタリングのネタだよな。
いや、ずれてないと思うぞ。
デザパタを利用することでリファクタリングも楽になるという点で、関連はあるが。

930 ：デフォルトの名無しさん：2006/02/26(日) 12:22:05

>>927
スレ違いごめんよ

＞ソース管理ツールくらい使ってるだろうし、
＞戻すなんて手間じゃないだろうに。

単純に戻すとかいう問題じゃなくて、どっちも使いたいとかなる
場合もあるからプログラム的に共存させておくことを念頭におい
て作っている

>>928
＞AがBに変わったとしても、
もちろん外見が同じなら何も変更はしないよ。
ただそうじゃない場合もあるし。（まれと言えばまれ）

まあ、

＞設定ファイル
それをもっと進めている。外見のインターフェースがまったく
変わったとしてもコードのビルドしなおしなんてやんない。

ビルドしなおすのはまったく新しい機能追加と
大好きな最適化やる時だけ

931 ：925：2006/02/26(日) 12:38:28

>>930
＞もちろん外見が同じなら何も変更はしないよ。
＞ただそうじゃない場合もあるし。（まれと言えばまれ）

外見（つまりインタフェース）を同じになるようにするってーのが、システムを設計する
際の肝であり、GoF本が主張している「インタフェースに対して設計する」ということで
すね。
「そうじゃない場合もあるし」というのは、まだまだ精進する余地があるってことでしょう。
（とはいえ、完璧に予想するなんて、神にしかできないだろうが。w）

そういった観点から見た場合、デザパタは「変化しそうな部分の外見（インタフェース）を
汎用的な形に変形するための設計をカタログ化」したものと言えるんじゃないかな。

デザパタを使うと無意味なクラスが多くできるとか、デザパタを用いて失敗したという
のは、こういった変形を必要以上にシステム内に持ち込んだり、誤った変形をしてしまった
結果に起因するのではないかと言ってみる。

932 ：デフォルトの名無しさん：2006/02/26(日) 17:15:45

>>928
>AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
>無くなるわけです。
これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

933 ：デフォルトの名無しさん：2006/02/26(日) 19:37:56

>>932
＞これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

ふっ、、、甘いな。
テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？

934 ：デフォルトの名無しさん：2006/02/26(日) 21:52:34

＞これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。

ひょっとして、ここは笑いどころだったのか？
ソースコードだけの話って、ソースコードいじると色々とたちの悪い問題が出てくるんだが。

935 ：デフォルトの名無しさん：2006/02/26(日) 22:08:04

というふうに、デザパタ肯定派でも意見の対立がある（・∀・）

936 ：デフォルトの名無しさん：2006/02/26(日) 23:47:30

>>933
>テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？
そのテストってどうやるの？
何を証明すればキチンとした動作になってると言えるのかわからない。
とりあえず全パターン出して、今回の変更で変わる部分を抜き出さないとテストは終わらない。
そういうふうに人に説明しにくい仕組みしてしまうよりは、ベタで書いたほうが早いと思う。単純に。

937 ：デフォルトの名無しさん：2006/02/27(月) 01:46:03

多分単体テストと結合テスト、外部テストがごっちゃになってるんだと思う。

938 ：デフォルトの名無しさん：2006/02/27(月) 01:48:05

テストの種別も組織によって違うしねｗ

939 ：デフォルトの名無しさん：2006/02/27(月) 02:58:03

>>937
それを含めて全パターンだしても>>936のいってることは代わらないと思う。

940 ：デフォルトの名無しさん：2006/02/27(月) 06:41:21

自動化できるところとできないところの切り分けができていないのかと。

941 ：デフォルトの名無しさん：2006/02/27(月) 07:48:49

>>936
＞そのテストってどうやるの？
＞何を証明すればキチンとした動作になってると言えるのかわからない。

そんなことを聞くあなたは、ひょっとするとテストの際、毎回全てのケースをテストしているのかい？
（まぁ、xUnit 等をうまく使えば、そういったことも可能だし、効率もさほど低下しないだろうから、
　毎回全てのケースをテストすることに対して否定はしないが。）

答えは色々あるだろうが、正しいインスタンスが生成されているかどうかを確認したいのならば
クラスBのコンストラクタが起動された際にコンソールメッセージを出すようにするというのは
一つの手じゃないか？　　まぁ、この手の方法は組織によって向き不向きがあるんだろうけど。

それよりも >>932 は >>934 の言ってたソースコードを触った時の危険性を認識しなさ過ぎ。
たいていの厄介なバグは、新規機能に作り込んでしまうのではなく、新規機能を追加した時に
既存機能側をいじり壊して作り込んでしまうものです。

942 ：デフォルトの名無しさん：2006/02/27(月) 08:30:39

交通事故と同じ。やるやつは繰り返す

943 ：デフォルトの名無しさん：2006/02/27(月) 09:12:00

かもな。
俺は絶対事故らない、、、とみんな思ってる。

944 ：デフォルトの名無しさん：2006/02/27(月) 10:31:57

むしろ事故らなかったことはありませんが（プログラムの方だよん。
車の方はやばいと思って運転するのやめた）

945 ：デフォルトの名無しさん：2006/02/28(火) 03:01:40

>>926の発言をみる限り、プログラミングはうまそうなので、
必要だと思わないのであれば別に無理して覚える必要はないんじゃない？

俺は面白かったから勉強したけど。
俺が得られたメリットは、コードの整理がうまくなったってことかな。
昔、色々コード書いてて、規模が大きくなればなるほど、整理の方法がわからず、
コードが汚くなることが悩みだったが、デザパタ覚えたことで少し改善した感じ。

あと「カタログ化して、みんなの共通の認識とする」っていうのはあんまメリットない気がする。
デザパタしらん人には無意味だし。ただの浮いてる奴としか見られない。

946 ：デフォルトの名無しさん：2006/02/28(火) 20:30:50

デザパタなくとも、プログラム上手くなればコード整理はできるけど
デザパタないと、共通認識にはできないから俺はそっちの方が重要だと思う

データ構造とアルゴリズム　みたいな本がいっぱいあるけど
クラス構造とアルゴリズム　になるのがデザパタだろう
どちらも丸暗記する必要はないけどな

947 ：デフォルトの名無しさん：2006/02/28(火) 22:12:30

「デザパタしらん人には無意味だし。」ってのが正論としてまかり通るのが問題だ。

948 ：デフォルトの名無しさん：2006/03/01(水) 01:13:50

>>947
つーかもう本でてないしｗ
流行りも廃れたしｗ
あのぶ厚い本を一冊読むことを強制するってのは流行らないと思うわ。
なんかもうちょっとお手軽なのじゃないとねぇ。

949 ：デフォルトの名無しさん：2006/03/01(水) 01:23:54

>>948
もう少し本屋にいった方がいいと思う

950 ：デフォルトの名無しさん：2006/03/01(水) 06:29:12

>>949
オススメは何？

951 ：デフォルトの名無しさん：2006/03/01(水) 14:20:46

>>947
うーん、無理だろう。
プログラム勉強するようになっていきなりデザインパターン勉強する奴とかいないだろ。
「関数で処理を分けるのは、なぜ必要なんですか」っていうレベルからだろうし。

１００人のプログラマがいても２０人くらいしか知ってる奴は期待できないとおもう。
それを２０人の都合で、８０人に本よめっていうのはわがまますぎだと思う。
所詮たよれるのは自分です。なんつって。

>>948
まあ、とりあえず、デザパタは得て損はないと思うよ。
ただ全部が全部、よいパターン／読んで欲しいパターンだとはいえないんだけど。

952 ：デフォルトの名無しさん：2006/03/01(水) 15:17:11

100人中100人が知っている必要はないだろう。
100人いたら半数以上は言われたとおりに部品製造していればいいコーディング担当だろうし。

設計を担当するアーキテクトチームなら常識的に知ってて当然だとは思う。
設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題。
使う・使わない・どこにどう適用するかは別問題として。

953 ：デフォルトの名無しさん：2006/03/01(水) 20:36:03

>>950
俺は結城さんの読んで覚えた、お勧め
読んではいないが、最近だと変なねーちゃん表紙のやつ評判よかったような

954 ：デフォルトの名無しさん：2006/03/05(日) 18:13:55

>>952
>設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題
なんで？

955 ：デフォルトの名無しさん：2006/03/05(日) 20:08:18

>>954
アーキテクトにとっては、良し悪し・使うべき/使わないべきまで含めて知ってて当然の知識だからな。
デザパタも知らない、共通の概念のない非常識な人間が寄ってたかって設計したシステムなど、お里が知れるわｗ

956 ：デフォルトの名無しさん：2006/03/05(日) 23:34:37

そうか「当然の知識」か。そして「共通の概念」か。
・・・それは思いこみであって現実の正しい認識であるとは思えないけどね。

957 ：デフォルトの名無しさん：2006/03/05(日) 23:39:43

>>955
具体的な根拠がなにも示されて無いな。
本当に理系の人間なのかどうか疑問

>>956
ね。
なんか思い込み強いよね。

958 ：デフォルトの名無しさん：2006/03/06(月) 00:19:40

デザパタのように今や古典とも言える超メジャーな設計上のスキームを
「知りもしない」ってのは、土方コーダーならともかく
アーキテクトとしては激しく問題があると思われ。

知った上で使う・使わないは別問題だがな。

959 ：デフォルトの名無しさん：2006/03/06(月) 00:43:55

知ったつもりになって使ったつもりになる。
形式だけ学んだので不必要に濫用する。

このパターンが少なくない気がする。

デザパタの粒度ってアーキテクトレベルなんかな？
どちらかと言うとプログラミング(詳細設計から下)レベルに思うんだが。

960 ：デフォルトの名無しさん：2006/03/06(月) 06:35:25

>>958
デザパタなんていつ必須事項になったんだか。
オブジェクト指向でもなんでもないし。
すっげどうでもいい部分の寄せ集めじゃん。

>知った上で使う・使わないは別問題だがな
これでデザパタは使えないって結論に至った人間をどうやって説得するのか？

961 ：デフォルトの名無しさん：2006/03/06(月) 06:43:31

>>959
＞知ったつもりになって使ったつもりになる。
＞形式だけ学んだので不必要に濫用する。
＞このパターンが少なくない気がする。

ここのところは同意。　しかし、デザパタの真意はアーキテクトレベルにあると思うぞ。
それをコーディングの定石集だと誤解しているﾔｼが多すぎ。

>>960
＞オブジェクト指向でもなんでもないし。

オブジェクト指向原理主義ですか？
90年代前半の呪縛に捕らわれてますな。

962 ：デフォルトの名無しさん：2006/03/06(月) 13:23:31

>>960
＞すっげどうでもいい部分の寄せ集めじゃん。
そうかね？JavaとかC#とかの標準ライブラリ（java.langとかjava.ioとか）は、
デザパタを基準に作られてると思うけど、あれもすっげどうでもいい使えないライブラリかね？
あれらを見たときなかなかいいもんだと感じたもんだが。
まあ、良いか悪いかの感じ方は、人それぞれとは思うけどね。

>>961
俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
あそこまで本の中身がソースコードだらけにはならないと思う。

963 ：962：2006/03/06(月) 13:28:47

まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。

964 ：961：2006/03/06(月) 15:08:20

>>962
＞俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
＞デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
＞あそこまで本の中身がソースコードだらけにはならないと思う。

デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
ことを明確にしている点が肝なんだと考えています。
そういった意味では、本の中身をあそこまでソースコードだらけにしてしまう必要はなか
ったんじゃないかな。　　（クラス図とせいぜい状態遷移図があれば十分だったはず。）

実は「GoF本の翻訳がイマイチで理解しづらかった」→「みんなソースコードに頼ろうと
する」というだけなのではないかと。
（かの結城氏もJavaで書かれてないから判りにくいんだと誤解していたし。）

そもそもデザパタがプログラミングレベルの概念だったとしたら、もっと色々な言語が
シンタックスシュガーとしてデザパタ構文を採用してるんじゃないか？

＞まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
＞アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。

アーキテクトほどいい加減な言葉もそうそうないと思う。
あれってプログラミングが設計工程に属していることを認めたくない連中が、
（彼らの言う）設計工程とプログラミング工程のギャップを埋めるために作り出した
役割なんだと思うな。

965 ：デフォルトの名無しさん：2006/03/06(月) 18:49:58

>>964
>デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
>ことを明確にしている点が肝なんだと考えています。
よく考えると切り離す意味が全くわからないな。

966 ：デフォルトの名無しさん：2006/03/06(月) 19:20:35

>>965
＞よく考えると切り離す意味が全くわからないな。

変更に強くするため。
いくらクラスを作って「カプセル化」だと叫んでも、インタフェース部分に変更が
あると、そのクラスを変更した時、山火事のように影響度が飛び火して広がって
いく。

967 ：デフォルトの名無しさん：2006/03/06(月) 20:00:30

>>966
変更に強いかどうかってそんなに重要かぁ？
俺には設計と実装がマッチしてない糞みたいなソースができるような気がするぜ。
つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
一致してることの方が何倍も大事なことのように思えるんだけど。

968 ：デフォルトの名無しさん：2006/03/06(月) 20:01:59

ああ、言いたいことはさ。
変更されたらそれに合わせて変更が必要になってもいいんじゃないの？
ってこと。
てゆうか、設計が変更されたのに実装がそのまんまっておかしいｗ

969 ：デフォルトの名無しさん：2006/03/06(月) 20:16:10

>>967
設計と実装はそんなに離れない　離れたらその設計参考にされてない
変更に強いって言うのは変更箇所が少ない、影響範囲が小さいってこと
釣りなのかマジなのか……

970 ：962：2006/03/06(月) 20:21:39

>>967-968
まあ、デザパタを覚えることで利点を感じなければ覚える必要は無いと思うけどね。

あと、「設計変更による変更に強い」というよりは、
設定ファイルや、オプションによる処理の変更には強くできるね。
一行変えるくらいで後々の処理を大きく変えることができるとか。
設計変更されたら実装かえるのは当然だぁね。

971 ：962：2006/03/06(月) 20:35:48

>>967
＞つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
＞一致してることの方が何倍も大事なことのように思えるんだけど。
こりゃ同意だな。実装はともかく、設計（インターフェース）は、
万人がイメージしやすい＆理解しやすいことが望ましい、というかそうすべきであると思う。

デザパタのほとんどのパターンは、実装の変更を容易にすることを目的としているかな。

例えば、データを読込＆保存する処理をしたい場合に、保存する手法は何でもよいというとき、
その中身の実装は、普通にファイルで保存したり、ＤＢにしたり、ＸＭＬにしたり、
と後々実装を変えたい、または、コマンドラインオプションや設定ファイルによって変えたいと
思った場合の変更に強くすることができるかと。

972 ：デフォルトの名無しさん：2006/03/06(月) 20:44:47

フト思ったんだが、、、
ひょっとしたらアンチデザパタってﾔｼは、設計時に無茶苦茶にデザパタを
適用した結果、設計結果とみんなのイメージが乖離してしまったという
暗い過去を持っているんｼﾞｬﾏｲｶ？

973 ：デフォルトの名無しさん：2006/03/07(火) 00:18:43

そこで結城先生の登場ですよ。

>デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
>つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。
>ですから、プログラム例を｢完成品」として見るのではなく、今後「機能を拡張していくもの」
>｢変更を加えていくもの」として見るようにしましょう。
>　・どのような機能が拡張される可能性があるか？
>　・その機能拡張を行うときに修正が必要になるのはどのクラスか？
>　・修正が不要なのはどのクラスか？
>このような観点でデザインパターンを見ると、理解が深まるでしょう。

974 ：デフォルトの名無しさん：2006/03/07(火) 00:36:28

＞変更に強いかどうかってそんなに重要かぁ？

極めて重要だと思う。特に脱ウォーターフォールを標榜する今後のJavaの開発形態としては特に。
と、いうかJavaの抽象化フレームワークやJunitやEclipseの強力なリファクタリング機能が
何の為に存在するのかといったら、やっぱ「変更しないのが前提」、っていうウォーターフォールの一番駄目駄目な
部分を徹底的に唾を吐き、"いかにソースを良くしていくか"、"｢動いているソースは駄目ソースでも触るな」じゃなく
「ガリガリ直してどんどん洗練されたソースにリファクタリング」していくか"、
"余計なドキュメント製造に掛かるコストをカットする事で生ずるリスクをどこで吸収できるか"
等にあるわけで。

変更に強い、というのは客の仕様を満たすのと同じくらい重要だと思う。

975 ：デフォルトの名無しさん：2006/03/07(火) 00:49:56

世の中には二種類のアーキテクトが居る。

一方のアーキテクトはアンチパターンを認識・検出・除去することが出来る。
残りのアーキテクトは日々新たなアンチパターンを生産することが出来る。

後者多すぎ。

976 ：デフォルトの名無しさん：2006/03/07(火) 03:20:30

>>969
いや、だから、どんな変更に強いってのか謎。
変更したらさ、設計がかわるんだよね？
ここはいいよね？
影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
要はメインじゃなくて付加価値みたいなもんでしょ？
それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
プログラムってのはそれだけで気持ち悪いと思うんだ。
おそらく、みて理解のしやすいソースにはなっていない。

977 ：デフォルトの名無しさん：2006/03/07(火) 07:30:31

>>976
＞いや、だから、どんな変更に強いってのか謎。
「十分予測できるが、現時点では詳細が不明な変更」ですな。
そこを押さえずに何でもかんでも変更可能にしてやろう、あるいはとにかくデザパタを
適用しようという発想がいかんのです。

＞変更したらさ、設計がかわるんだよね？
＞ここはいいよね？
ここはＯＫ。　マクロな視点で見れば必ず設計は変わる。　しかしミクロな視点で
構成要素を一つずつ見ていき、影響が出る構成要素の数を極力減らす努力が
必要。

＞影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
変更内容が判らないというのであれば、その通り。　しかし裏を返せば、変更の匂いが
するところに対してデザパタを適用できるということ。
伝家の宝刀はここぞという時にしか抜いてはならない（とはいえ意外と多かったりするがなw）。

＞普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
それはダウト。　現状の静的なスナップショットを取っているだけのデザイナは、松竹梅で
言えば梅レベル。　そもそも現状のスナップショットをいくら睨んで見ても、そのどの部分が
変わりそうなのかといった情報は読みとれないものだ。　つまり「普通にそれぞれのクラスを
閉じこめるように作っていく」だけでは全然不足というわけだ。

978 ：デフォルトの名無しさん：2006/03/07(火) 07:31:26

（続き）
>>976
＞要はメインじゃなくて付加価値みたいなもんでしょ？
システムを作るだけ作ってそのまま逃げるような開発をするのであれば、現状のスナップ
ショットのみを用いて設計してもいいかもしれない。　（開発中に入ってくる要求変更と戦う
必要はあるが。）　　しかしその後の保守を考えると、変更に対する強度は極めて重要な
ことになるのだ。

＞それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞プログラムってのはそれだけで気持ち悪いと思うんだ。
＞おそらく、みて理解のしやすいソースにはなっていない。
おそらく君が過去に接したシステムというのは伝家の宝刀を濫用したものなんだろう。
デザパタを適切に使用した場合のクラス図は、現状のスナップショットがどうなっている
のかという情報だけでなく、今後どういった部分が変化しそうなのかという情報もはっきりと
伝える判りやすいものになるのだ。

979 ：デフォルトの名無しさん：2006/03/07(火) 07:33:10

>>976
＞要はメインじゃなくて付加価値みたいなもんでしょ？
＞それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞プログラムってのはそれだけで気持ち悪いと思うんだ。
＞おそらく、みて理解のしやすいソースにはなっていない。

俺も最近流行りのDIコンテナを利用した実装とインタフェースを分ける設計をみて
そう感じることがよくある。
IDEのデバッガでも追いづらいし、開発の効率を下げている一面もあるよな。
クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
やりやすい点ぐらいか・・・

オブジェクト指向本来のインタフェースの用途ではなく、
言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。

980 ：デフォルトの名無しさん：2006/03/07(火) 07:51:27

>>973
＞そこで結城先生の登場ですよ。
＞
＞ >デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
＞ >つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。

注意すべきはここでの「部品」，「再利用」という表現ですな。

A, B, C, D, E, F, Gという7つのクラスで構成されたシステムがあったとする。
普通に「部品」というと、例えばCとかDというクラスを思い浮かべ，「再利用」というと
そういったクラスを他のシステムから利用することを想像してしまいがちになる。

しかし、デザパタのいう「部品」、「再利用」は違う。
デザパタでいう「部品」というのは、「Cというクラスから見た場合はA, B, D, E, F, Gと
いう6つのクラス」であり、Cが変更になった時にこれら6つのクラスに影響を与える
ことなく、「このシステム自体から見て6つのクラスを再利用する」ということだ。

981 ：デフォルトの名無しさん：2006/03/07(火) 08:01:01

>>979
＞クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
＞やりやすい点ぐらいか・・・
ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに
対して変更があった場合、保守コストが引き下げられるということを意味しているはず。

＞オブジェクト指向本来のインタフェースの用途ではなく、
＞言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう？
実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので
あるべきなんじゃないかい？

982 ：デフォルトの名無しさん：2006/03/07(火) 12:17:18

>979
DIコンテナ使わないチームと使ったチームで比べられればいいけどね。
俺はもうDIコンテナなしの開発は考えたくないです。

まぁDIスレ(typoしてるが)でやるのが適切な話題だし、
あっち過疎ってるから盛り上げて欲しいってのが本音。

983 ：デフォルトの名無しさん：2006/03/07(火) 16:36:13

＞将来そのクラスに
＞対して変更があった場合、保守コストが引き下げられるということを意味しているはず。

タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
よくあるのかな？

984 ：962：2006/03/07(火) 18:00:51

>>982
DIコンテナって使うとソース見やすくなったりとかするの？
DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね？

設定ファイルの情報を反映させたいときは再起動が必要みたいだから、
ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。

985 ：981：2006/03/07(火) 19:20:50

>>983
＞タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
＞よくあるのかな？

意外とよくある。　新規開発の際、客先がちゃんと要求を出せてない部分が
開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき
るぞ。　　その都度リファクタリングしてもいいんだが、新規開発時だとユニット
テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。
どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。

986 ：デフォルトの名無しさん：2006/03/07(火) 19:29:23

変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う

987 ：デフォルトの名無しさん：2006/03/07(火) 19:55:01

インタフェース設計レベルから変更を余儀なくされる要求が多いな。

988 ：デフォルトの名無しさん：2006/03/07(火) 20:10:10

>>976
極端から極端に走らなくてもいいじゃん
仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして
隠しオプションでどんな仕様にも即対応！　みたいのはそりゃだめだ

デザパタは問題の解決法として書かれていて
その問題があるときは割と的確な粒度の解決だと思うがどうだ？
あれでもまだ余分かな？

989 ：981：2006/03/07(火) 20:23:57

>>986
＞変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
＞デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う

結構大変だけどね。　客先が「XXがYYという風に変わりそうだ」なんて自分から教えて
くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます？」といった
聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。
で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに
入る。

990 ：デフォルトの名無しさん：2006/03/07(火) 23:54:24

>984
この話題、DIスレにコピペしてもフォローしてくれますか？
(スレタイの意味での)デザパタとは全然関係ないと思うし。

＞ソース見やすくなったりとかするの？
それはないです。

>988
＞的確な粒度の解決だと思うがどうだ？
当方もそういう意識ですね。
そういう意味でもアーキテクトと言うよりは、
プログラミングレベルの話題だと思う。
フレームワーク作成チームが知っておくべきプラクティス。

991 ：962：2006/03/08(水) 01:21:50

>>990
＞この話題、DIスレにコピペしてもフォローしてくれますか？
いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。
ありがとう。あっ、でもやっぱり聞いてみようかな。

>>986
漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、
プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。

ただプログラムのやることは同じだけど実装を変える。
例えばパフォーマンスアップのために仕様変更するというのであれば、
それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。

992 ：デフォルトの名無しさん：2006/03/08(水) 01:40:16

つーかさ、
ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に
その処理が記述してあってほしい。（関数とかクラスとか）

そうでないと他の人間の書いたソースなんて追えない。
降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。
すげー面倒臭い。どうにかしてくれ。

単純に、ただ単純に書いて欲しい。
それだけ・・・それだけなんだ・・・orz

993 ：986：2006/03/08(水) 01:43:31

>>991
たとえ話になるけど「１００Ｖコンセントがあれば、殆どの電化製品に対応できる」とか考えて実装してると、
いざ「実は、この家電アース線がついてるんだけど……」ってなったときに、コンセント側も改造しなくちゃいけないな、
って話をしてみた。

アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。
ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、
どこまで変更を予測するか～って話だ。

ちなみに↑は Strategy を想定してみた。
解決策としては、Adapter が使えれば手っ取り早い。

どうでも良い。次ぎスレたのむ。

994 ：962：2006/03/08(水) 02:08:21

>>992
基本的には単純なものは単純に書くよｗｗ必要になったときにしかデザパタは適用しないよ。

処理をたらいまわしにしている人のソースに悩まされてるの？たまにいるわなぁ。
デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。

必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。
やるべき処理を素直にコードにすることが一番の解だというのに。

995 ：デフォルトの名無しさん：2006/03/08(水) 02:22:21

マ板的な話題になってしまうが

とあるベンダが俺様フレームワークを作成して
基本設計の説明に加えて
「ここはあのパターン、ここにはあのパターンを使ってる。」
みたいなことをのたまって
最後にパターン名と適用の有無からなる
2列23行の表を見せて、こんなにたくさん○が付いてますよ
(使った(ことになってる)パターンを○でカウントする。)
みたいな感じで胸を張ってた。

手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。
アンチパターンの表を作るのは意味があるかも知れん。

なんか盛り上がってきたし次スレ欲しいなあ。

996 ：デフォルトの名無しさん：2006/03/08(水) 03:02:51

手段のためには目的を選ばない。

997 ：962：2006/03/09(木) 03:33:36

では私が建てよう。ひっそりと深夜に。

998 ：962：2006/03/09(木) 03:39:13

＞新このホストでは、しばらくスレッドが立てられません。
＞またの機会にどうぞ。。。
「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz
建てて誘導したいけど残り２レスしかない・・・。

999 ：デフォルトの名無しさん：2006/03/09(木) 04:28:57

次すれ

「【GoF】デザインパターン 6
http://pc8.2ch.net/test/read.cgi/tech/1141846078/

1000 ：デフォルトの名無しさん：2006/03/09(木) 04:29:41

コピペミスで「が残ってたorz

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。