[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:54 / Filesize : 288 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 19:09:56 ]
そもそもデザインパターン自体どうなのよ?って話はここでやれ。

16 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 21:43:58 ]
本スレでデザインパターンを否定していたやつってここにいる?
デザインパターンを否定していないやつはオブジェクト指向を理解していないとか、
ほんとうにオブジェクト指向で設計するとデザインパターンなんて使わないとか
いうようなことを言っていたけど、おまいのオブジェクト指向論を講師してくれんかな?
オセロプログラムでもいいから具体例だしてさ。

17 名前:デフォルトの名無しさん [2005/06/21(火) 21:46:52 ]
>>16
えー。向こうで死ぬほど書いたじゃん。
あと、設計の話だよー。
具体例なんてでねぇぞー。
ソースコード期待してるなら帰った方がいいぞ。

18 名前:デフォルトの名無しさん [2005/06/21(火) 21:48:08 ]
>>16
聞くポイントがまじぃんだよ。
ソースが欲しいわけじゃなくて、要は開発の流れみたいのが知りたいだけじゃねーの?

19 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 22:06:16 ]
>えー。向こうで死ぬほど書いたじゃん。

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

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

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

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

20 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 23:10:56 ]
>>19
げー。
俺が探してくんの?w
誰か知らん奴のためになぜにここまで苦労せにゃならんのかw

21 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 23:57:34 ]
>俺が探してくんの?w

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

22 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:00:15 ]
つか名無しの書き込みじゃどれ書いたのかなんて書いた本人しかわからないだろ

23 名前:デフォルトの名無しさん [2005/06/22(水) 00:13:00 ]
ここまでの流れ見てると、デザパタ否定派のが分が悪いな。

24 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:21:25 ]
俺はてっきり
・オブジェクト指向で開発
・たくさんオブジェクト指向で開発
・なんか同じ様な設計パターンにならね?
・デザパタ誕生
かと思ってた
まぁオブジェクト指向しなくてもデザパタは適用できるんだけどさ



25 名前:デフォルトの名無しさん [2005/06/22(水) 00:26:44 ]
>>21
まあ、一番大事なのはこれ↓だな。

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

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

26 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:32:32 ]
デザインパターンはコミュニケーションの手段であって設計のテンプレートではないと思ってたんだが

27 名前:デフォルトの名無しさん [2005/06/22(水) 00:36:08 ]
> 対象物の構造をそのままクラスとして反映させるのがオブジェクト指向

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


28 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:38:44 ]
>>25
ゲームなどのクライアントアプリケーションやスタンドアロンアプリケーションならそれでも行けるよね。
DB連携のWebアプリはどうする?
DB検索と更新機能のデザインパターンを使わない設計の具体例を教えてくれ。

29 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:39:00 ]
>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。

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

30 名前:デフォルトの名無しさん [2005/06/22(水) 00:41:10 ]
「オブジェクト指向で設計すればデザパタ不要」
もうこの一言で「デザインパターン」を知らないことは明白。


31 名前:デフォルトの名無しさん [2005/06/22(水) 00:41:38 ]
>>27
組めるよ。
なんでできないの?

32 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:41:46 ]
>>26
同意
典型例に名前を付けただけだよな

33 名前:デフォルトの名無しさん mailto:sage [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 ]
いいなぁ。専門学校生。生来勉強できないだけのことはあるw
講師もバカだしなw
超使えねぇ解雇された元同僚が某専門学校で講師やってるよw


37 名前:デフォルトの名無しさん [2005/06/22(水) 00:47:28 ]
>>35
もしかしたら、超天才かも。
そんなわけ無いか...

38 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:47:28 ]
>>35
やったこともないのにできるなんてよく言えるな。
おめでたい奴だ。

39 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:53:58 ]
GRASPパターンについてはどう考えてるのか聞きたい


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

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


42 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:56:38 ]
本当にいいたいことは、やりたいようにプログラミングさせろってことなんだろ?
デザインパターンとかで縛りを受けたくないと...

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

43 名前:本スレ住人 [2005/06/22(水) 00:59:26 ]
>>39
その本良書かもしれないけど、あんまポピュラーじゃないから、
ちゃんと説明する努力をしないと伝わらないよ。
俺なんて本スレで調査しまくり、翻訳しまくりだ、最近orz


44 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 00:59:26 ]
デザパタは縛りでは無いが、名前がないパターンは伝達に不便なので
避けがちになるかもしれないから縛りに感じることもあるか。
それより伝達の欲求がないなら覚えるだけ面倒にしか感じないだろうな。
一人で設計してるだけならそう思うかも。



45 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:03:43 ]
>>41
拡張性も糞も無い。
俺はただあるべき構造をただクラスに反映させるだけ。
そのために対象物の構造を理解する必要はあるけどね。
要は対象物の構造が破綻さえしてなきゃ大よそのもんは組めるってこと。

46 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:06:31 ]
>>45
マジですか?
仕様の変更とかあったら組みなおすの大変じゃない?

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

48 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:12:02 ]
>>45
Webシステム開発は仕様変更が激しいからねー。
そんなんじゃ、手戻り多くてあっという間にあぼーん確定だね♪

49 名前:デフォルトの名無しさん [2005/06/22(水) 01:22:29 ]
>>25への反論

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

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

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

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

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

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


50 名前:デフォルトの名無しさん [2005/06/22(水) 01:23:05 ]
>>48
仕様変更による構造の変更を無理やり設計レベルで吸収しようとすると
だいたいドツボにハマる。
俺はいっそしっかり組み直してしまったほうがいいと考えるけど。(完全に変更の場合はね)
つか、そのまま残して置いちゃ駄目でしょ。

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

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

51 名前:デフォルトの名無しさん [2005/06/22(水) 01:30:33 ]
>>49
ちょっと小出しに話してよ。
レスつけずらいよ。
1ってなんで不可能なのかさっぱりわからないんだけど。

52 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:37:11 ]
>>50
変更に対して強い設計を可能にするデザインパターンもあるんだがそれは無視?

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

53 名前:49 一部訂正。結局駄文だけど本質は突いているつもり [2005/06/22(水) 01:39:23 ]
>>25への反論

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

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

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

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

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

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


54 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:40:03 ]
>>51
 なんすか?
 質問があるなら簡潔明瞭に済ませてね。
 長々と議論する時間はもうないんで。



55 名前:デフォルトの名無しさん [2005/06/22(水) 01:41:19 ]
デザパタなんて息抜きって言うかお遊び

56 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:41:40 ]
ダメだこりゃ。理想論でしかない。
この人はビジネスロジックとデータモデルの設計はできるが、それだけ。
プレゼンテーション層、EIS層の設計と実装はムリだね。
定石とかフレームワークという概念が皆無。


57 名前:エリート研究開発すぁ [2005/06/22(水) 01:45:55 ]
まぁ>>41あたりの大半は、
1996-1997当時にほぼ独力 (ただし関連文献や技術書、GoF、各種MLをROM捲り)
で作れたけどね。



58 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:46:59 ]
Webアプリなんてこうやって組んでおけば誰にでもわかりやすいし
どんなアプリでもほぼこれでOKなのに、それでも毎回オレ様オリジナル設計するの?
無駄な努力にしか思えない。
java.sun.com/developer/technicalArticles/J2EE/patterns/J2EEPatternLanguage.gif


59 名前:エリート研究開発すぁ mailto:sage [2005/06/22(水) 01:48:00 ]
つまりJavaやHORBが出た当初なら、
しがらみがほとんどないから、
フルスクラッチで大建築を作りやすかったんだけど、
もうあれから10年近く立ってるからなぁ。しがらみ過ぎてて最近始めた人は大変だなぁと思う

60 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:48:52 ]
>>57
作れるかどうかじゃなくて、これらの手法をパターン化していつも使うかどうか。
オブジェクト指向厨はそうはしないで、毎回毎回アタマをひねるらしいよ。

61 名前:エリート研究開発すぁ mailto:sage [2005/06/22(水) 01:52:57 ]
いうまでもなく俺はGoF賛成派で、パターンは重要と考える口だが。

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

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

62 名前:デフォルトの名無しさん [2005/06/22(水) 01:54:20 ]
>>58
つーか、webアプリ組んだことないから知らないけど
同じものなら使いまわせばいいでしょ?
どうしてパターン使ってまで組み直すの?

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

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

63 名前:デフォルトの名無しさん [2005/06/22(水) 01:55:33 ]
>>39 まだぁ〜(チン、チン☆

>>51 まだぁ〜(チン、チン☆

もう寝るよぉ?

64 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 01:57:49 ]
>>62
貴方の主張は、設計を使いまわすのではなく、実装を使いまわすって話ね。
SI屋がやりそうな手口だ。

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



65 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:03:59 ]
オマエモナーと脊髄反射レス

66 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:05:19 ]
>>62
よく使われる組み方をカタログ化しておいて、使い回すのがデザインパターンなんだけど。


67 名前:デフォルトの名無しさん [2005/06/22(水) 02:07:26 ]
>>66
ん?毎回パターン使って組まなきゃならないものなのか?
って聞いてるんだけど?
要はソースレベルでの使いまわしは効かないの?
って話ね。

68 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:12:49 ]
>>67
もちろんフレームワークやライブラリは最大限利用するよ。


69 名前:デフォルトの名無しさん [2005/06/22(水) 02:14:43 ]
>>68
いやいや、ソースレベルでの使い回しができるかできないかの話。

70 名前:デフォルトの名無しさん [2005/06/22(水) 02:14:53 ]
ほぼ陥落だね

71 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:22:34 ]
フレームワーク・ライブラリを最大限に利用したら
使い回せるモノなんてほとんど無いんだけど。
各システム固有の要件に応じた処理とか画面と設定ファイルしか作らないので。

72 名前:デフォルトの名無しさん [2005/06/22(水) 02:24:55 ]
>>68
おまえジェネリックプログラミングとかテンプレートって知らないのか?


73 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:51:35 ]
>>77
近いのはあるがあれはコレクションを使いやすくする程度の使い道しかない

79 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 02:51:40 ]
>>16
君らは概念がごちゃごちゃになってる。
多重継承を使うなよ。ってのもデザインパターンの一種なんだよね。
べからず集なので、アンチパターンとも呼ぶが。

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

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

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

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

80 名前:デフォルトの名無しさん [2005/06/22(水) 03:06:05 ]
>>79
そんな上等なレベルじゃないよ。知りもしないくせに「パターン」で反応しているだけ。
標準ライブラリは当たり前に使っている癖に、なぜかメタレベルのライブラリだと拒否反応を起こす。


81 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 03:08:28 ]
デザインパターンはライブラリじゃないだろ

82 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 03:08:48 ]
言語依存の話しをするなよー

83 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 03:09:25 ]
>>81
"メタ"ライブラリと言えるだろ

84 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 04:06:02 ]
最初から「デザインTips」とでもしとけば誤解する奴が減ったのになぁ・・・



85 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 09:47:37 ]
>>79
>「デザインパターン」と言う概念は否定しようも無い、だって既に
>この世の中に有る物に名前を付けただけなんだから。
この世の中にあるもの。
であるはずなのに、なぜ名前をつけてはいけないのですか?

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

86 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 11:26:50 ]
>>84
日本人の英語力のなさまで面倒みきれない

87 名前:デフォルトの名無しさん mailto:sage 日本語力ってのも何だか解らんが [2005/06/22(水) 14:31:37 ]
>>85 の日本語力のなさは誰が面倒みてくれるんでしょう?

88 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 14:36:45 ]
>>67
>要はソースレベルでの使いまわし
なんだ、プログラミングパターンは使ってるじゃん。
それの抽象度を上げたのがデザインパターン。
使いまわすときに、多少変更して使った事ないか?

89 名前:デフォルトの名無しさん [2005/06/22(水) 15:49:13 ]
デザインパターンはゴミ。
デザインパターンなんてものは、口出しできないけど口出したいって思ってる
バカがひたすら持ち上げてるだけ。

90 名前:デフォルトの名無しさん [2005/06/22(水) 16:07:46 ]
>>89
てかゴミパターンも有るってことで。
SINGLETONパターンなんか、本当にゴミだと思うし。

91 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 16:09:30 ]
>>90
クライアントやスタンドアロンしかやったことない奴はそう思うのだろう。
サーバサイドでは普通に使うけどね。

92 名前:デフォルトの名無しさん [2005/06/22(水) 16:13:54 ]
>>91
SINGLETONは普通に使うよ。GoF本の言うSINGLETONパターンを
ゴミと言ってるだけ。


93 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 16:25:38 ]
>>92
それには同意。俺はDIコンテナにSingletonインスタンスの管理をさせてるから
ああいうコーディングはしない。

94 名前:デフォルトの名無しさん [2005/06/22(水) 16:34:47 ]
>>93
だよねー。

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




95 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 16:49:56 ]
ぜんぶstaticにしちゃえば嫌でもシングルトンだしね

96 名前:デフォルトの名無しさん [2005/06/22(水) 17:00:10 ]
>>95
うんだ。てか、SINGLETONパターンには、初期化されてないインスタンスを
呼ぶ危険性まであって、アンチパターンの方が似合てると思うんだ。

97 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:01:06 ]
>>96 それはない

98 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:05:01 ]
>>96
それはバグだろ

99 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:11:27 ]
いくつかのスレッドが同時に初回staticのインスタンスを呼ぶ場合、
ゴミデータになるらしい。あとSMP環境だともっとややこしい事になるそうな。

100 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:13:04 ]
>>99
それってC++の話?

101 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:14:20 ]
そうC++、Javaは知らん。

102 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:16:55 ]
スレッドの排他制御もわからんのか・・・

103 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 17:19:22 ]
Javaでそれが起こったらJVMのバグとしかいいようがないな。

104 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 18:22:05 ]
シングルトンがガベコレ対象になる恐れがうんぬんって
記事を見た記憶がありんす。



105 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 18:46:44 ]
>>99
GoF では環境に依存しないよう、あえて実装してないが
MT safe にするためには当然、排他制御しなきゃならん。
んなこたあパターンに限った話じゃない。

106 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 18:47:31 ]
>>97-98
きっと何処かで初期化されてるオブジェクトを、2度目の
生成するリスクをさけるにしては、リスクの方が大きい
と思うんだね。

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

107 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 18:52:01 ]
出たトリッキーw
どのへんがトリッキーなのか具体的に解説きぼんぬ

108 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 18:59:33 ]
>>107
隔離スレなんだから、反証責任はデザパタのカタログを信じてる馬鹿の
方に有る.


109 名前:デフォルトの名無しさん [2005/06/22(水) 19:00:24 ]
トリッキー、トリッキー、GoF時代のthreadは、トリッキー、トリッキー、GoF時代のOOPアプリはね、
教えてあげないよっ、じゃん♪

110 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 19:21:52 ]
>>108(笑)

111 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 19:33:04 ]
>>105>>96のいう危ないインスタンスの例をあげただけだが、
ModernC++Designにある安全で速いダブルロックチェックドなシングルトンさえも
いまは安全でなく、ReadMemoryBarrier()とWriteMemoryBarrier()を
つかってない時勢にそぐわないものになってるというおはなし。

112 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 19:36:18 ]
その手の(ハードウェア・)アーキテクチャ依存な話は、
アレつかって切り離すというのが、ここ2〜3年の潮流

113 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 19:58:56 ]
どこがトリッキーなのか言わずにトリッキーだと言って信用されるとでも思ってるんだろうかw

114 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 20:06:07 ]
トリッキーという発言自体がトリッキー



115 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 20:14:54 ]
>>114
寧ろ発言者の存在自体がトリッキー

116 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 20:38:45 ]
このスレの存在がトリッキー






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<288KB

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