05/06/21 19:13:40
>>1
乙
確かにデザパタそのものについての話が全然無かったしな最近。
3:デフォルトの名無しさん
05/06/21 19:15:53
>>2
ここは隔離スレなんで建設的な話は期待しないほうがいいですよ
4:デフォルトの名無しさん
05/06/21 19:41:13
まず、オブジェクト指向からはずれちゃってるのが問題だよね。
デザパタがいいって人はとりあえずオブジェクト指向理解してる（つもり）なの？
5:デフォルトの名無しさん
05/06/21 19:48:22
オブジェクト指向以外認めないという人はいったいどんな言語を使っているんですか？
6:デフォルトの名無しさん
05/06/21 19:48:58
>>5
C++
7:デフォルトの名無しさん
05/06/21 20:02:16
>>6
いや、ネタはいいから（笑）
8:デフォルトの名無しさん
05/06/21 20:04:12
>>7
なんて答えて欲しかったんだ？
デザパタなんて使ってるぐらいだから、
一度もC++でオブジェクト指向で設計して組んでみたことなんでしょ？
9:デフォルトの名無しさん
05/06/21 20:13:32
デザパタで成功してるのはstlのイテレータくらい。
MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
どうしてもキショイコードになる。
10:デフォルトの名無しさん
05/06/21 20:32:56
MFCは忘れてやれよ･･･。あれは正直ウンコさ。
ＭＳのデザパタはC#とか見てあげてください。
11:デフォルトの名無しさん
05/06/21 20:46:31
>>8
まさかネタじゃなかったのか？
デザパタを否定するくらいstrictなOO人間がよりにもよってC++を肯定するなんて信じられないんだが。
12:デフォルトの名無しさん
05/06/21 21:00:08
デザパタ＝トリッキーと主張してた人は、結局テンプレートが
読めないから恨み節でデザパタ否定してただけでしょ？
いくら否定してもテンプレートがなくなる事はないのに、無駄
足掻きだな。
13:デフォルトの名無しさん
05/06/21 21:17:22
>>11
OOPLがC++しかない時期があったのだ
14:デフォルトの名無しさん
05/06/21 21:20:39
まぁ、一般向け処理系はSmalltalk/Vの方が早期から安く入手可能だったけどｗ
15:デフォルトの名無しさん
05/06/21 21:24:53
>>13
今はいろいろあるじゃん、なんで昔の話？
16:デフォルトの名無しさん
05/06/21 21:43:58
本スレでデザインパターンを否定していたやつってここにいる？
デザインパターンを否定していないやつはオブジェクト指向を理解していないとか、
ほんとうにオブジェクト指向で設計するとデザインパターンなんて使わないとか
いうようなことを言っていたけど、おまいのオブジェクト指向論を講師してくれんかな？
オセロプログラムでもいいから具体例だしてさ。
17:デフォルトの名無しさん
05/06/21 21:46:52
>>16
えー。向こうで死ぬほど書いたじゃん。
あと、設計の話だよー。
具体例なんてでねぇぞー。
ソースコード期待してるなら帰った方がいいぞ。
18:デフォルトの名無しさん
05/06/21 21:48:08
>>16
聞くポイントがまじぃんだよ。
ソースが欲しいわけじゃなくて、要は開発の流れみたいのが知りたいだけじゃねーの？
19:デフォルトの名無しさん
05/06/21 22:06:16
>えー。向こうで死ぬほど書いたじゃん。
ならリンク張ってよ、それくらいできるでしょ？
>あと、設計の話だよー。
>ソースコード期待してるなら帰った方がいいぞ。
オセロプログラムの設計の話でしょ？
しかも何でもいいみたいだよ？
20:デフォルトの名無しさん
05/06/21 23:10:56
>>19
げー。
俺が探してくんの？ｗ
誰か知らん奴のためになぜにここまで苦労せにゃならんのかｗ
21:デフォルトの名無しさん
05/06/21 23:57:34
>俺が探してくんの？ｗ
向こうで死ぬほど書いたんだろ？何言ってんの？
22:デフォルトの名無しさん
05/06/22 00:00:15
つか名無しの書き込みじゃどれ書いたのかなんて書いた本人しかわからないだろ
23:デフォルトの名無しさん
05/06/22 00:13:00
ここまでの流れ見てると、デザパタ否定派のが分が悪いな。
24:デフォルトの名無しさん
05/06/22 00:21:25
俺はてっきり
・オブジェクト指向で開発
・たくさんオブジェクト指向で開発
・なんか同じ様な設計パターンにならね？
・デザパタ誕生
かと思ってた
まぁオブジェクト指向しなくてもデザパタは適用できるんだけどさ
25:デフォルトの名無しさん
05/06/22 00:26:44
>>21
まあ、一番大事なのはこれ↓だな。
>ＯＯＰなんだけどもなにもアプローチが
>基本から脱線しまくってるじゃねーか。
>どんなに複雑だろうとなんだろうと、オブジェクト指向はオブジェクト指向だ。
>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。
掻い摘んでいうと、
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向であって
パターンを覚えさせるデザインパターンはアプローチがおかしい
と、そういうこと。
26:デフォルトの名無しさん
05/06/22 00:32:32
デザインパターンはコミュニケーションの手段であって設計のテンプレートではないと思ってたんだが
27:デフォルトの名無しさん
05/06/22 00:36:08
> 対象物の構造をそのままクラスとして反映させるのがオブジェクト指向
おまえまじでいってんのかよｗ あんまプログラム組んだこと無いだろｗ
本当にそんな稚拙なOOPの定義で、１作品完全に組めるならやってみろｗ
素人がｗ
28:デフォルトの名無しさん
05/06/22 00:38:44
>>25
ゲームなどのクライアントアプリケーションやスタンドアロンアプリケーションならそれでも行けるよね。
DB連携のWebアプリはどうする？
DB検索と更新機能のデザインパターンを使わない設計の具体例を教えてくれ。
29:デフォルトの名無しさん
05/06/22 00:39:00
>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。
どこでこんなこと習ったんだ？
教えてもらった先生に文句言ったほうがいいぞ。
30:デフォルトの名無しさん
05/06/22 00:41:10
「オブジェクト指向で設計すればデザパタ不要」
もうこの一言で「デザインパターン」を知らないことは明白。
31:デフォルトの名無しさん
05/06/22 00:41:38
>>27
組めるよ。
なんでできないの？
32:デフォルトの名無しさん
05/06/22 00:41:46
>>26
同意
典型例に名前を付けただけだよな
33:デフォルトの名無しさん
05/06/22 00:41:47
「だったはずだ」ってまさか思い込みで書いてないよな？
34:デフォルトの名無しさん
05/06/22 00:42:39
LOL
35:デフォルトの名無しさん
05/06/22 00:44:11
>>28
web関連やったことないから知らんけど、
基本的に対象物の構造をそのままクラスに反映するわけだから
DBとやらの構造に根本的な欠陥が無い限り組めると思うよ。
それがオブジェクト指向の強みだからね。
逆にDBとやらが腐ってたら設計も腐るだろうね。
36:デフォルトの名無しさん
05/06/22 00:44:33
いいなぁ。専門学校生。生来勉強できないだけのことはあるｗ
講師もバカだしなｗ
超使えねぇ解雇された元同僚が某専門学校で講師やってるよｗ
37:デフォルトの名無しさん
05/06/22 00:47:28
>>35
もしかしたら、超天才かも。
そんなわけ無いか...
38:デフォルトの名無しさん
05/06/22 00:47:28
>>35
やったこともないのにできるなんてよく言えるな。
おめでたい奴だ。
39:デフォルトの名無しさん
05/06/22 00:53:58
GRASPパターンについてはどう考えてるのか聞きたい
40:デフォルトの名無しさん
05/06/22 00:54:06
>>38
いえる。
だから、マ板にいる奴等ってすげー偉そうじゃん。
それは自分が対象物の構造さえ理解できれば確実に
プログラムを組めるということが確信できているから。
で、オブジェクト指向覚えた奴同士で設計に関する議論ってみたことないでしょ？
そりゃする必要がないから。
なんたって確実。
あとは対象物の理解がどれだけできているかってただそれだけ。
人に聞いてわかるもんじゃないし、あとは自分がどれだけ勉強するかってだけ。
41:デフォルトの名無しさん
05/06/22 00:54:53
>>35はServletやJSPやJavaBeansをどうやって使うつもりなんだろう？
セッション管理やトランザクション管理の仕組みも自分で設計するのかな？
CommnadパターンもServiceLocatorも使わないから、ビジネスロジックの呼び出しもベタ書き？
プレゼンテーション層/ビジネスロジック層/EIS層を分けて考えることもしないんだよね？
DAOパターンやDTOパターンもSingltonも拒否？
拡張性もなく、リクエストの度に大量のオブジェクトを生成して恐ろしくパフォーマンスの低いシステムを作りそうだ。
42:デフォルトの名無しさん
05/06/22 00:56:38
本当にいいたいことは、やりたいようにプログラミングさせろってことなんだろ？
デザインパターンとかで縛りを受けたくないと...
オブジェクト指向云々は単なるこじつけでさ
43:本ｽﾚ住人
05/06/22 00:59:26
>>39
その本良書かもしれないけど、あんまポピュラーじゃないから、
ちゃんと説明する努力をしないと伝わらないよ。
俺なんて本ｽﾚで調査しまくり、翻訳しまくりだ、最近orz
44:デフォルトの名無しさん
05/06/22 00:59:26
デザパタは縛りでは無いが、名前がないパターンは伝達に不便なので
避けがちになるかもしれないから縛りに感じることもあるか。
それより伝達の欲求がないなら覚えるだけ面倒にしか感じないだろうな。
一人で設計してるだけならそう思うかも。
45:デフォルトの名無しさん
05/06/22 01:03:43
>>41
拡張性も糞も無い。
俺はただあるべき構造をただクラスに反映させるだけ。
そのために対象物の構造を理解する必要はあるけどね。
要は対象物の構造が破綻さえしてなきゃ大よそのもんは組めるってこと。
46:デフォルトの名無しさん
05/06/22 01:06:31
>>45
マジですか？
仕様の変更とかあったら組みなおすの大変じゃない？
47:本ｽﾚ住人
05/06/22 01:06:57
>>39
あと、こっちは隔離スレだから、
ちゃんとした話は本ｽﾚ
【GoF】デザインパターン5
ｽﾚﾘﾝｸ(tech板)
でやった方がいい。
ところで、こんな荒れてるスレでパターン・コレクション名だけこそっと書いて
そのまま無反応になるのは、なにかのオマジナイですか？
48:デフォルトの名無しさん
05/06/22 01:12:02
>>45
Webシステム開発は仕様変更が激しいからねー。
そんなんじゃ、手戻り多くてあっという間にあぼーん確定だね♪
49:デフォルトの名無しさん
05/06/22 01:22:29
>>25への反論
1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
不完全な表現の例：
多重継承、
時間的な状態変化、
計算不可能な対象物/概念、
非常に複雑な対象物/概念
etc.
もしあらゆる事柄を表現しシミュレーションする方法があるのなら、
科学者の仕事の大半はいらなくなる
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて扱いやすい簡易的な表現を得る事である。
要するに、抽象化こそが知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいＰＣ上のソフトウェアの「移植」とか「エミュレーション」程度の事に過ぎない。
3. このように対象物の構造と、ソフトウェア上の表現・・・ここではオブジェクト指向モデル/プログラム
との差異を何らかの形で縮め、実用上問題がないように取り繕う技術が、
モデリングであり、設計であり、プログラミングである。
これは普通にソフトウェアを弄っている人間にとって、常識である。
50:デフォルトの名無しさん
05/06/22 01:23:05
>>48
仕様変更による構造の変更を無理やり設計レベルで吸収しようとすると
だいたいドツボにハマる。
俺はいっそしっかり組み直してしまったほうがいいと考えるけど。（完全に変更の場合はね）
つか、そのまま残して置いちゃ駄目でしょ。
それに、あいまいな部分をあいまいに組んでおく手もないわけではないよ。
例えば、始め敵クラスの詳細が決まってないときは詳細が決まるまで
「敵」クラスとしてあいまいなままおいときゃいいわけだし。
んで、「敵」クラスの詳細が決まったら初めて「敵：スライム系」「敵：ゴブリン系」だの
その詳細を組みだしゃいいわけだしね。
２つの方法があってどっちか迷ってるときも同じ。あいまいなままどさっとおいておきゃいい。
汎用性をつけたいときも同じ、でもそれなりに大変ではあるよ。
逆にあんまり詳細に組み過ぎてもやっぱり駄目。ＲＰＧなんかでアイテム１つ１つにクラス作るわけにはいかないからねぇ。
ってこの辺は人によって方法は違うだろうし、どんな方法をとろうがその人の自由だな。
まあ、本質にかかわる話じゃ無い。
51:デフォルトの名無しさん
05/06/22 01:30:33
>>49
ちょっと小出しに話してよ。
レスつけずらいよ。
1ってなんで不可能なのかさっぱりわからないんだけど。
52:デフォルトの名無しさん
05/06/22 01:37:11
>>50
変更に対して強い設計を可能にするデザインパターンもあるんだがそれは無視？
まぁ・・・あれだ。
完璧な設計などまずありえないし、お尻がキッチリ決まってる仕事の場合は
設計にそれほど時間をかけられないし、深くは追求するつもりはないけど。
# 書いているうちに余計なおせっかいな気がしてきた
53:49 一部訂正。結局駄文だけど本質は突いているつもり
05/06/22 01:39:23
>>25への反論
1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
オブジェクト指向では不完全な表現しか得られない事象の例：
多重継承、
時間的な状態変化、
etc.
一般的に、不充分な表現しか得られない事象の例：
非常に複雑な対象物/概念
計算不可能な対象物/概念、
記述不可能な対象物/概念
etc.
もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
大半の科学者は仕事をする必要がなくなる。
(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。
3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
モデリング/設計/プログラミングの中心的な作業であり、
そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。
54:デフォルトの名無しさん
05/06/22 01:40:03
>>51
なんすか？
質問があるなら簡潔明瞭に済ませてね。
長々と議論する時間はもうないんで。
55:デフォルトの名無しさん
05/06/22 01:41:19
デザパタなんて息抜きって言うかお遊び
56:デフォルトの名無しさん
05/06/22 01:41:40
ダメだこりゃ。理想論でしかない。
この人はビジネスロジックとデータモデルの設計はできるが、それだけ。
プレゼンテーション層、EIS層の設計と実装はムリだね。
定石とかフレームワークという概念が皆無。
57:エリート研究開発すぁ
05/06/22 01:45:55
まぁ>>41あたりの大半は、
1996-1997当時にほぼ独力 (ただし関連文献や技術書、GoF、各種MLをROM捲り)
で作れたけどね。
58:デフォルトの名無しさん
05/06/22 01:46:59
Webアプリなんてこうやって組んでおけば誰にでもわかりやすいし
どんなアプリでもほぼこれでOKなのに、それでも毎回オレ様オリジナル設計するの？
無駄な努力にしか思えない。
URLﾘﾝｸ(java.sun.com)
59:エリート研究開発すぁ
05/06/22 01:48:00
つまりJavaやHORBが出た当初なら、
しがらみがほとんどないから、
フルスクラッチで大建築を作りやすかったんだけど、
もうあれから10年近く立ってるからなぁ。しがらみ過ぎてて最近始めた人は大変だなぁと思う
60:デフォルトの名無しさん
05/06/22 01:48:52
>>57
作れるかどうかじゃなくて、これらの手法をパターン化していつも使うかどうか。
オブジェクト指向厨はそうはしないで、毎回毎回アタマをひねるらしいよ。
61:エリート研究開発すぁ
05/06/22 01:52:57
いうまでもなく俺はGoF賛成派で、パターンは重要と考える口だが。
歴史的経緯を見てきた漏れの意見を言うと、
J2EE Blueprint / J2EE Patternってイマドキ神格化されすぎてると思う。
リアルタイムでは、IBM BestPracticeやNetscape, WebLogicの方が
よっぽど進んでいたと思うよ。
更にマズイのは、J2EE反主流派のOracleなんて、
J2EE Pattern織り込み済みでもう必要としないＤＢ用フレームワークを使っている事。
そんな環境でも、木偶の坊みたいな人がJ2EE Patternを無理やり適用しようとする。
こういう奴を見ちゃうと、Pattern言語/Pattern推進派の努力にも限界があるのだと実感する。
62:デフォルトの名無しさん
05/06/22 01:54:20
>>58
つーか、webアプリ組んだことないから知らないけど
同じものなら使いまわせばいいでしょ？
どうしてパターン使ってまで組み直すの？
オブジェクト指向＝毎回作り直す
とかかってに捻じ曲げて無い？
そんなことはいってないよ。
63:デフォルトの名無しさん
05/06/22 01:55:33
>>39 まだぁ～(ﾁﾝ、ﾁﾝ☆
>>51 まだぁ～(ﾁﾝ、ﾁﾝ☆
もう寝るよぉ？
64:デフォルトの名無しさん
05/06/22 01:57:49
>>62
貴方の主張は、設計を使いまわすのではなく、実装を使いまわすって話ね。
SI屋がやりそうな手口だ。
ところでここの住人は何時まで起きてるの？
明日も仕事だよね？
65:デフォルトの名無しさん
05/06/22 02:03:59
オマエモナーと脊髄反射レス
66:デフォルトの名無しさん
05/06/22 02:05:19
>>62
よく使われる組み方をカタログ化しておいて、使い回すのがデザインパターンなんだけど。
67:デフォルトの名無しさん
05/06/22 02:07:26
>>66
ん？毎回パターン使って組まなきゃならないものなのか？
って聞いてるんだけど？
要はソースレベルでの使いまわしは効かないの？
って話ね。
68:デフォルトの名無しさん
05/06/22 02:12:49
>>67
もちろんフレームワークやライブラリは最大限利用するよ。
69:デフォルトの名無しさん
05/06/22 02:14:43
>>68
いやいや、ソースレベルでの使い回しができるかできないかの話。
70:デフォルトの名無しさん
05/06/22 02:14:53
ほぼ陥落だね
71:デフォルトの名無しさん
05/06/22 02:22:34
フレームワーク・ライブラリを最大限に利用したら
使い回せるモノなんてほとんど無いんだけど。
各システム固有の要件に応じた処理とか画面と設定ファイルしか作らないので。
72:デフォルトの名無しさん
05/06/22 02:24:55
>>68
おまえジェネリックプログラミングとかテンプレートって知らないのか？
73:デフォルトの名無しさん
05/06/22 02:32:59
本当にGenericに、ソースコードで直接パターンそのものを表現できるのなら
そっちのが望ましいのは確かだよな。Modern C++ Designの例のように。
ただし、デザパタ自体の存在価値がそれで無くなるわけではない。
あれは、プログラマ間の共通言語、意思疎通の道具としての存在価値が
もっとも大きいのだと思う。
パターン化されたデザインは、for (i = 0; i < 10; ++i);
のようなパターン化されたループのように、認識・理解しやすいし。
74:デフォルトの名無しさん
05/06/22 02:35:44
>>73
あいやー。
再利用なんて無理にしないほうがいいと思うぞ。
できたらラッキーぐらいにしとけ。
75:デフォルトの名無しさん
05/06/22 02:40:47
>>74
おまえ、STL(スタンダード・テンプレート・ライブラリ）って知らないのか？
76:デフォルトの名無しさん
05/06/22 02:43:15
> 本当にGenericに、ソースコードで直接パターンそのものを表現できるのなら
>そっちのが望ましいのは確かだよな。
ん？できるじゃん。なんでできないと思っているの？
77:デフォルトの名無しさん
05/06/22 02:44:31
ひょっとしてJavaってC++のtemplateのような機能は無いのか？
78:デフォルトの名無しさん
05/06/22 02:51:35
>>77
近いのはあるがあれはコレクションを使いやすくする程度の使い道しかない
79:デフォルトの名無しさん
05/06/22 02:51:40
>>16
君らは概念がごちゃごちゃになってる。
多重継承を使うなよ。ってのもデザインパターンの一種なんだよね。
べからず集なので、アンチパターンとも呼ぶが。
でだ、デザインパターンって本を読むと、全体にトリッキーだったり、
（そうなってしまう前に設計で回避しろよーてな場合が多い）
Tipsレベルが多いんだ、の割には宣伝文句が大げさだから、
喧嘩になってる。さらに日本では訳や書籍が訳分からん言葉を
積極的に使うから更に悲惨な事態になってる。
「デザインパターン」と言う概念は否定しようも無い、だって既に
この世の中に有る物に名前を付けただけなんだから。
で、デザインパターンを批判してる者の言い分を聞くと、提出
されたパターンが汚いって話で、これはその通りだと思うし、
デザインパターンに、（デザイン）なんて言葉付いてるのが
日本人感覚だと惑わされるんだよね。
今のデザインパターンってのは、どう読んでもレスキューパターン
と言う名前の方がふさわしい。
80:デフォルトの名無しさん
05/06/22 03:06:05
>>79
そんな上等なレベルじゃないよ。知りもしないくせに「パターン」で反応しているだけ。
標準ライブラリは当たり前に使っている癖に、なぜかメタレベルのライブラリだと拒否反応を起こす。
81:デフォルトの名無しさん
05/06/22 03:08:28
デザインパターンはライブラリじゃないだろ
82:デフォルトの名無しさん
05/06/22 03:08:48
言語依存の話しをするなよー
83:デフォルトの名無しさん
05/06/22 03:09:25
>>81
"メタ"ライブラリと言えるだろ
84:デフォルトの名無しさん
05/06/22 04:06:02
最初から「デザインＴｉｐｓ」とでもしとけば誤解する奴が減ったのになぁ・・・
85:デフォルトの名無しさん
05/06/22 09:47:37
>>79
＞「デザインパターン」と言う概念は否定しようも無い、だって既に
＞この世の中に有る物に名前を付けただけなんだから。
この世の中にあるもの。
であるはずなのに、なぜ名前をつけてはいけないのですか？
ドラえもんという存在がいて、名前がなかったらなんて呼べばいいのか。助けてドラえも～ん。
86:デフォルトの名無しさん
05/06/22 11:26:50
>>84
日本人の英語力のなさまで面倒みきれない
87:デフォルトの名無しさん
05/06/22 14:31:37
>>85 の日本語力のなさは誰が面倒みてくれるんでしょう？
88:デフォルトの名無しさん
05/06/22 14:36:45
>>67
>要はソースレベルでの使いまわし
なんだ、プログラミングパターンは使ってるじゃん。
それの抽象度を上げたのがデザインパターン。
使いまわすときに、多少変更して使った事ないか？
89:デフォルトの名無しさん
05/06/22 15:49:13
デザインパターンはゴミ。
デザインパターンなんてものは、口出しできないけど口出したいって思ってる
バカがひたすら持ち上げてるだけ。
90:デフォルトの名無しさん
05/06/22 16:07:46
>>89
てかゴミパターンも有るってことで。
SINGLETONパターンなんか、本当にゴミだと思うし。
91:デフォルトの名無しさん
05/06/22 16:09:30
>>90
クライアントやスタンドアロンしかやったことない奴はそう思うのだろう。
サーバサイドでは普通に使うけどね。
92:デフォルトの名無しさん
05/06/22 16:13:54
>>91
SINGLETONは普通に使うよ。GoF本の言うSINGLETONパターンを
ゴミと言ってるだけ。
93:デフォルトの名無しさん
05/06/22 16:25:38
>>92
それには同意。俺はDIコンテナにSingletonインスタンスの管理をさせてるから
ああいうコーディングはしない。
94:デフォルトの名無しさん
05/06/22 16:34:47
>>93
だよねー。
あのコーディングのどこにメリットが有るのか小一時間といつめたくなる。
95:デフォルトの名無しさん
05/06/22 16:49:56
ぜんぶstaticにしちゃえば嫌でもシングルトンだしね
96:デフォルトの名無しさん
05/06/22 17:00:10
>>95
うんだ。てか、ＳＩＮＧＬＥＴＯＮパターンには、初期化されてないインスタンスを
呼ぶ危険性まであって、アンチパターンの方が似合てると思うんだ。
97:デフォルトの名無しさん
05/06/22 17:01:06
>>96 それはない
98:デフォルトの名無しさん
05/06/22 17:05:01
>>96
それはバグだろ
99:デフォルトの名無しさん
05/06/22 17:11:27
いくつかのスレッドが同時に初回staticのインスタンスを呼ぶ場合、
ゴミデータになるらしい。あとSMP環境だともっとややこしい事になるそうな。
100:デフォルトの名無しさん
05/06/22 17:13:04
>>99
それってC++の話？
101:デフォルトの名無しさん
05/06/22 17:14:20
そうC++、Javaは知らん。
102:デフォルトの名無しさん
05/06/22 17:16:55
スレッドの排他制御もわからんのか・・・
103:デフォルトの名無しさん
05/06/22 17:19:22
Javaでそれが起こったらJVMのバグとしかいいようがないな。
104:デフォルトの名無しさん
05/06/22 18:22:05
シングルトンがガベコレ対象になる恐れがうんぬんって
記事を見た記憶がありんす。
105:デフォルトの名無しさん
05/06/22 18:46:44
>>99
GoF では環境に依存しないよう、あえて実装してないが
MT safe にするためには当然、排他制御しなきゃならん。
んなこたあパターンに限った話じゃない。
106:デフォルトの名無しさん
05/06/22 18:47:31
>>97-98
きっと何処かで初期化されてるオブジェクトを、2度目の
生成するリスクをさけるにしては、リスクの方が大きい
と思うんだね。
デザインパターンてな考えかたは、認めるし、効果あると
思うけど、GoFにカタログ作らせるのは、不味いと思うよ。
全体にトリッキーなんだよ、奴らのカタログは。
107:デフォルトの名無しさん
05/06/22 18:52:01
出たトリッキーｗ
どのへんがトリッキーなのか具体的に解説きぼんぬ
108:デフォルトの名無しさん
05/06/22 18:59:33
>>107
隔離スレなんだから、反証責任はデザパタのカタログを信じてる馬鹿の
方に有る.
109:デフォルトの名無しさん
05/06/22 19:00:24
トリッキー、トリッキー、GoF時代のthreadは、トリッキー、トリッキー、GoF時代のOOPアプリはね、
教えてあげないよっ、じゃん♪
110:デフォルトの名無しさん
05/06/22 19:21:52
>>108（笑）
111:デフォルトの名無しさん
05/06/22 19:33:04
>>105は >>96のいう危ないインスタンスの例をあげただけだが、
ModernC++Designにある安全で速いダブルロックチェックドなシングルトンさえも
いまは安全でなく、ReadMemoryBarrier()とWriteMemoryBarrier()を
つかってない時勢にそぐわないものになってるというおはなし。
112:デフォルトの名無しさん
05/06/22 19:36:18
その手の(ハードウェア・)アーキテクチャ依存な話は、
アレつかって切り離すというのが、ここ２～３年の潮流
113:デフォルトの名無しさん
05/06/22 19:58:56
どこがトリッキーなのか言わずにトリッキーだと言って信用されるとでも思ってるんだろうかｗ
114:デフォルトの名無しさん
05/06/22 20:06:07
トリッキーという発言自体がトリッキー
115:デフォルトの名無しさん
05/06/22 20:14:54
>>114
寧ろ発言者の存在自体がトリッキー
116:デフォルトの名無しさん
05/06/22 20:38:45
このスレの存在がトリッキー
117:デフォルトの名無しさん
05/06/22 20:59:45 BE:140478454-
お前らトリッキーって言いたいだけちゃうかと。
118:デフォルトの名無しさん
05/06/22 21:05:00
そうだ
119:デフォルトの名無しさん
05/06/22 21:11:00
お前らがトリッキーとか言ってる間に俺は既にトレッキー。
まぁ、お前らはゆっくりトロッキー辺りを目指せってことだな。
120:デフォルトの名無しさん
05/06/22 21:11:08
じゃあエキセントリック
121:デフォルトの名無しさん
05/06/22 21:28:48
結局アンチに正確な反証挙げられる奴はいなかったわけか
122:デフォルトの名無しさん
05/06/22 21:37:08
>>121
>>25の方法って普通のオブジェクト指向でしょ
デザパタ使ってる人ってこれのどの課程でデザパタを使うの？
123:デフォルトの名無しさん
05/06/22 21:39:05
一応これも貼っとこう
>>25への反論
1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
オブジェクト指向では不完全な表現しか得られない事象の例：
多重継承、
時間的な状態変化、
etc.
一般的に、不充分な表現しか得られない事象の例：
非常に複雑な対象物/概念
計算不可能な対象物/概念、
記述不可能な対象物/概念
etc.
もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
大半の科学者は仕事をする必要がなくなる。
(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。
3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
モデリング/設計/プログラミングの中心的な作業であり、
そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。
124:デフォルトの名無しさん
05/06/22 21:47:36
>>122
「対象物の構造を～」ってことを 25 は言っているけど、その切り出し方は無数にある
(例えばオセロで審判を導入するとかしないとか。審判を導入すると双方の不正を一元監視できたり)
んで、その切り出し方の一例としてデザパタを応用するというふうに俺は使っている
(デザパタは直接使用せず、応用として。改変なしでは絶対に組み込めないし、組み込みたくない)
125:デフォルトの名無しさん
05/06/22 21:48:36
>>123
それはネタでしょ。
126:124
05/06/22 21:49:18
ちなみに、改変しても組み込めそうになかったら、その時点であきらめてますのであしからず
127:デフォルトの名無しさん
05/06/22 21:49:43
こんな下の方でチマチマやらずに、
上の方でどうぞ
128:デフォルトの名無しさん
05/06/22 21:50:32
>>125の存在が冗談
129:デフォルトの名無しさん
05/06/22 21:50:38
>>124
具体的にどうやって使うの？
パターンに当てはめる方法でいいの？
130:124
05/06/22 21:55:55
>>129
当てはめはしない
俺が考えた構造と、デザパタで提示されている構造が一致したら 「お？このまま行っても平気か？」 って思ってる
ついでに、提示された構造を参考に、幾らか修正を入れる
要は、どんな下らない物でも良いから、自分の考えを支持してくれる物があれば良いんだな俺の場合
131:デフォルトの名無しさん
05/06/22 21:59:02 BE:379290896-
>>130
デザインパターンの本来の目的からは外れてる気がするが（ﾟεﾟ）ｷﾆｼﾅｲ
132:デフォルトの名無しさん
05/06/22 22:08:06
>>124
何処に石を置けるのか知らなければ、審判はジャッジできない。
何処に石を置けるのか知らなければ、CPプレーヤーは戦略を立てられない。
石を置くとボードがどう変化するのかを知らなければ、審判はジャッジできない。
石を置くとボードがどう変化するのかを知らなければ、CPプレーヤーは戦略を立てられない。
さて、どうしましょう？と、>>124に話を振るのは筋違いだな。
さて、どうしましょう？
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向と主張してた貴方！
上記の主張を前提に、クラス設計してみてちょいよ。
133:124
05/06/22 22:18:31
>>132
いや、だから、対象物の切り出し方は無数にあるって例を出しただけで……
(審判は思いつき。妥当かどうかは考えてない。ちなみに、俺は大抵ボードが制約を持つように組んでる)
答えは無数にある。どれも正解かもしれないし、どれも不正解かもしれない。
134:デフォルトの名無しさん
05/06/22 22:18:42
>>130
どうせ修正するなら、当てはめたほうが早いのではないでしょうか？
135:124
05/06/22 22:22:23
>>134
正直速くない。部分的に一致させる事もあるけど、
サンプルで提示されている構造の使用価値はサンプルで提示されている程度のレベルでしかないと思っているし
ガチガチに当てはめると融通が利かない。妥協が必要
136:デフォルトの名無しさん
05/06/22 22:24:58
デザインパターンは
「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていたあれですね。あの方法で組めばいいんですね」
というまどろっこしい会話を
「それsingletonね」
「はい」
というシンプルな会話にするためにあるのよ
137:デフォルトの名無しさん
05/06/22 22:28:07
>>136
「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていた Singleton ですね。あの方法で組めばいいんですね」
138:デフォルトの名無しさん
05/06/22 22:41:43
>>136
１人のときは、全く役に立たないのでしょうか？
139:デフォルトの名無しさん
05/06/22 22:57:29
>>136-137
かつて２ちゃんの粘着くんの議論を終結させるために、
そーゆー一見もっともそうな説明をした事がある。
で、同じ話を何回書き込んだら気が済むの？
140:デフォルトの名無しさん
05/06/22 23:00:09
アンチが何か具体的な事を書くまでマターリ待とう。
オブジェクト指向だの設計だのって、結局は具体的な事が言えない
から逃げる為の口上に使ってるだけじゃん。
141:デフォルトの名無しさん
05/06/22 23:09:37
>>140
この人のあいかわらずソースを求める姿勢はどうにかならないものだろうかｗ
142:デフォルトの名無しさん
05/06/22 23:09:55
ウンコだかウンチだか知らないが、
煽り好きの>>140みたいなのは、リアルには付き合いたくない。
143:デフォルトの名無しさん
05/06/22 23:12:27
>>141もウンコ
144:デフォルトの名無しさん
05/06/22 23:13:58
この人がどの人か知らないが、俺はソースなんて求めてない。
具体的な何かでいい。とりあえず、上で出てるクラス設計なんてどう？
てか、言い訳多すぎ。
145:デフォルトの名無しさん
05/06/22 23:33:13
クラス図出せよ。
146:デフォルトの名無しさん
05/06/22 23:36:38
>>132
俺はこの件に関して傍観者だが、
>>132の問題設定が問題の体を為していないのと、
せっかく>>123に挙げた矛盾点を取り込んでいないあたりに、
そこはかとなく素人臭さを感じた
147:デフォルトの名無しさん
05/06/22 23:38:51
>>146
俺もこの件に関して傍観者だが、
具体性がないところにいつものアンチ臭さを感じた
148:デフォルトの名無しさん
05/06/22 23:55:48
>>144-145は、問題設定を明確にした上で、課題を出した方がいい。
このままだとアンチの自作自演と疑われて縞馬
149:デフォルトの名無しさん
05/06/23 00:01:13
では、僭越ながらｵﾚ様が課題をだしますよ。
Ｑ１．オセロを構成するのに必要なクラスを列挙せよ。
Ｑ２．Ｑ１で列挙した各クラスの役割について簡素に説明せよ。
Ｑ３．Ｑ１で列挙した各クラス間の関係(接続)について簡素に説明せよ。
150:デフォルトの名無しさん
05/06/23 00:04:29
>>136-137
>>111が例示してくれたように、デザインパターンのGoFカタログは
致命的なんだよ。
「SINGLETONパターンで、」と会話が成立してる*つもり*になって
いて、片方は、スレッーフなカスタマイズSINGLETONを話し、
片方は、GoFベースのSINGLETONで話てたらOUTなんだから。
GoFのカタログを、バイブルのように使うのは、危険なんだよ。
使い方としては、アルゴリズム集みたいなイメージで使うべき
なんだよ。
151:いつものアンチ
05/06/23 00:06:37
>>146
>>123は何がいいたいのかわからない。
>1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
の理由が
>オブジェクト指向では不完全な表現しか得られない事象の例：
> ～略～
> (例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
なんだろうけど。
これは一体何がいいたいのかわからない。
とりあえず、手当たり次第レスつけると。
>オブジェクト指向では不完全な表現しか得られない事象の例
って書いてあるけど。
なんでここで「多重継承」なの？（このへんでもう相手にしなくていいかなーって思った）
多重継承を表現するって聞いた事ないんだけど。説明キボン。
んで次に書いてあるのが「時間的な状態変化」だけど。
なにこれ？意味がわからない。何がいいたいの？説明キボン。
で
>一般的に、不充分な表現しか得られない事象の例：
って書いてあるけど。
>非常に複雑な対象物/概念
どこまで複雑なのかは知らんけど根気よくやればできるんじゃない？
これはオブジェクト指向に限って表現できないものなのかなー。
>計算不可能な対象物/概念、
>記述不可能な対象物/概念
って書いてあるけど意味不明説明キボン。
ここでは１だけをとりあげたけど２と３なんて宇宙人の文でも読んでるのかと思った。ので意味不明。レス不能。
152:デフォルトの名無しさん
05/06/23 00:08:16
>>150
共有メモリアクセスの排他制御が必要だっつう
ハードウェア・アーキテクチャ依存の御託はもう判ってるから、
さっさと>>149に応えたらどうかね
153:デフォルトの名無しさん
05/06/23 00:09:15
>>151
キミの頭が未開拓なのはよく判ったから、
さっさと>>149に応えたらどうかね
154:デフォルトの名無しさん
05/06/23 00:12:35
>>153
やだよ。
だってそいつなんだかんだいってソースコードくれくれいってるのみえみえじゃん。
関わるとソース出さないとわめきたてるからレスつけない方がいいよ。
オブジェクト指向での設計からソースまでもってけないだけだろそいつは。
単純にクンフーが足りないｗ
155:デフォルトの名無しさん
05/06/23 00:13:39
クラス図出せ
156:デフォルトの名無しさん
05/06/23 00:16:37
ソースなんかいらないから、言語依存しないクラス図を出せよ。
157:デフォルトの名無しさん
05/06/23 00:31:25
また逃げたｗ
158:デフォルトの名無しさん
05/06/23 00:37:08
>>157
自作自演はバレてるから、さっさと>>149のクラス図出せ
159:デフォルトの名無しさん
05/06/23 00:38:42
あと、シーケンス図もな。
160:デフォルトの名無しさん
05/06/23 00:40:41
>>159
自作自演はバレてるから、さっさと>>149のクラス図出せ
161:デフォルトの名無しさん
05/06/23 01:02:42
だからクレクレ厨を相手にしちゃ駄目だって。
何、あげたって結局理解できるわけないんだから。
162:アンチじゃない人
05/06/23 01:04:00
ってか正直、>>123は俺でもわかりません。
1番を読み終えた時点で睡魔に襲われますた。
163:デフォルトの名無しさん
05/06/23 01:30:50
>>161-162
バレバレの自演はいいから早く出せよ
164:デフォルトの名無しさん
05/06/23 01:40:37
>>163
なんのために？
165:デフォルトの名無しさん
05/06/23 02:00:08
誤ったデザパタ推進派が、荒らしに来てる。
いやだ、いやだ。
166:デフォルトの名無しさん
05/06/23 02:04:36
いやあさすが隔離スレらしい展開だな(w
荒らしも糞も無いだろ
隔離スレにマトモな議論期待するなって
167:デフォルトの名無しさん
05/06/23 08:36:26
アンチの特徴：具体例を求めるとキレる
「デザパタってトリッキーだよな」
「どのへんが？」
「ﾑｷｰ！！！あ；ｄｌふぃうえあ；ｋじゃ；」
「オブジェクト指向がわかってればデザパタなんか設計に使わない」
「じゃあ○○をデザパタ使わずにどう設計する？」
「ぎえいぎえが；おい」
168:デフォルトの名無しさん
05/06/23 10:11:02
>>164-165
本当に言い訳がましいなｗ
169:デフォルトの名無しさん
05/06/23 12:32:12
お前ら空っぽの引き出しを何時まで弄ってるつもりだ？
もう完全スルーでいいだろ？
それはそれとして、このスレを何か有効に使う手はないものか？
170:デフォルトの名無しさん
05/06/23 13:13:42
っていうかここはもともとカラッポの引き出しを弄るスレですから
171:162(通りすがり)
05/06/23 14:24:13
>>163
自作自演じゃねーし。
>>123はごめん。素で意味不明。もっと文章力を付けてください。
で。オセロのクラス図？ごめｗｗｗｗダリｗｗｗｗｗ
172:デフォルトの名無しさん
05/06/23 16:08:16
デザインパターンを貶しておきながら具体的な話からとことん逃げ続けるアンチでありました
173:デフォルトの名無しさん
05/06/23 19:19:58
>>169
【デザパタ嵌り道】こんな失敗しますたスレヽ(`Д´)ﾉｳﾜｧｧﾝ【失敗談】
というのはどうか？
174:デフォルトの名無しさん
05/06/23 21:05:03
まぁ大体理解できてないか適用するパターンを間違えた例がでて終わりだろ
175:16
05/06/23 21:50:37
相変わらずちょっと空けるとずいぶん流れてるなー。このスレ。
あらかじめ断わっとくと、間違ってもソースコードはいらないから。
じゃあインベーダーの話をしよう。
>>25
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。
でさ、まず自機、敵、弾のオブジェクト（クラス）を作るじゃん。
１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
でさ、１と２って同じ処理だよね。やってることは。
どういう風に設計・実装するのか知りたいわけですよ。俺は。
俺がやるならどうやってもデザインパターンを使わずには作れないから。
っていうより、俺の能力じゃあ、どう書いても、誰かがこれはデザインパターンでいうなんとかパターンっていうものですよ。って言うだろう。俺がそのパターン名を知らなかったとしてもさ。
176:デフォルトの名無しさん
05/06/23 21:55:29
抽象クラス「キャラ」から「自機」と「敵」を継承させて
HitTest()は「キャラ」に実装するのが普通でしょう。
そのレベルではデザパタは別に関係ないし、例として適切じゃない気がするが。
177:デフォルトの名無しさん
05/06/23 22:10:50
つうかなんでいつも例がゲームなんだよ
中学生かよ
178:デフォルトの名無しさん
05/06/23 22:12:38
懐かしの「オブジェクト指向は戦場では必要無し」スレの
香りのするスレはここですか？
179:デフォルトの名無しさん
05/06/23 22:13:56
しかもまた「オセロ」でも書いて説明しるって言ってるし。
オマイたちは本当に進歩しませんね。
180:デフォルトの名無しさん
05/06/23 22:29:20
>>176
で、弾もあるよね。自分も敵も弾もそれぞれ座標（現在地）持ってるよね。
自分オブジェクトは１個かもしれないけど敵とか弾はたくさんオブジェクトがあるよね。
やっぱりループで回すよね。
ここまででデザパタは１つも出てこないのか？
>>177
じゃあ代わりに適切な例を上げて。
181:デフォルトの名無しさん
05/06/23 22:32:32
ゲームならオブジェクト指向でほぼOKでしょ。
俺が知りたいのはJ2EEアプリをJ2EEパターンを使わないで
アンチの主張する「オブジェクト指向設計」のみでどうやるのかに興味がある。
どんなに素晴らしいモノなのか、教えてもらいたいものだよ。
本当にできるならねｗ
182:デフォルトの名無しさん
05/06/23 22:41:18
>>180
「弾」も「キャラ」から派生させれば問題なかろ。
もう少し条件つけんとCompositeだのFlyweightだのは出てこんぞ。
183:デフォルトの名無しさん
05/06/23 22:43:44
そういえば彼はJ2EEの話に対して１回「出来る」ってレス返しただけであとは完全スルーだったな
184:デフォルトの名無しさん
05/06/23 22:48:02
仕事した事ないんだろ
185:デフォルトの名無しさん
05/06/23 22:50:33
J2EEアプリであるための条件って何なんだ？
helloworld.jsp
だけでいいんなら、別にパターンいらないぞ
186:デフォルトの名無しさん
05/06/23 23:14:01
>>181
前提が間違ってる。
崇高なオブジェクト指向を信奉する彼は邪悪なJ2EEなんて使わない。
彼なら最初にAPサーバを書くところから始めるに違いないｗ
187:デフォルトの名無しさん
05/06/23 23:41:58
>>186
だよな。「Servlet」というフレームワークや実装パターンのカタマリみたいな
プラットフォームは拒否るだろうからね。
188:デフォルトの名無しさん
05/06/24 00:25:49
今のところ肯定派の圧勝か。。
189:デフォルトの名無しさん
05/06/24 00:39:14
アンチは理想論ばかり振りかざして具体例をまったく出せていないからね。
190:いつものアンチ
05/06/24 01:03:27
奇跡だ！
まともな質問が！
>>175
>１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>
>でさ、１と２って同じ処理だよね。やってることは。
>どういう風に設計・実装するのか知りたいわけですよ。俺は。
これはオブジェクト指向で設計をしていれば、
オブジェクトの抽出のときに自機と敵が存在するフィールド（シーンのがいい？）のようなものができると思うから
そこに処理をかけばいいと思うよ。（なければフィールドクラスを作る。）
そのフィールドでの出来事だしね。
191:デフォルトの名無しさん
05/06/24 02:03:47
>>190
その"フィールド"をメディエイターとしてするのかな？
あと、敵キャラの動きとかはストラテジーパターンで表現できそうだ。
あと「スコアカウンタ」から「敵オブジェクト」を
オブザーバーパターンを使って監視しておけば
得点の加算ができそうだね。
192:デフォルトの名無しさん
05/06/24 04:04:33
お前らシングルトンも知らないのｗ
死ねば？
193:デフォルトの名無しさん
05/06/24 07:07:21
>>191
>あと「スコアカウンタ」から「敵オブジェクト」を
>オブザーバーパターンを使って監視しておけば
>得点の加算ができそうだね。
ん？これは何をやってるの？
もし、クラスのインスタンスの数を数えてシステムに反映させているなら
設計が悪いと思う。
194:デフォルトの名無しさん
05/06/24 10:28:59
>>191
アンチの人にパターン名で解説しても話が通じんだろ。
>>193
「スコアカウンタ」のインスタンスが一つあって、
敵オブジェクト一つ一つにその「スコアカウンタ」のインスタンスを持たせておいて、
敵オブジェクト自身が死んだときに「スコアカウンタ」に点数を報告するって方法では？
設計悪いかな？漏れはまあいいんじゃないかなと思うけど。
195:デフォルトの名無しさん
05/06/24 10:46:38
課題のインベーダー程度ならともかく
複数人同時プレーやもうすこし複雑なスコアシステムや設定によるスコアシステム自体の切り替えなどを考えると
シングルトンのスコアシステムに必要そうな情報全てを付加したスコア発生メッセージを通知するのがベター
嫌な設計だが
196:デフォルトの名無しさん
05/06/24 10:49:06
細かいところは分からないけど、全体的にMVCっぽくなりそうな...
197:194
05/06/24 11:30:53
>>195
複雑なスコアシステムだったとしても、
オブザーバに報告する内容をすこし増やせばいいんでない？
シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。
198:デフォルトの名無しさん
05/06/24 21:25:27
>>194
>敵オブジェクト自身が死んだときに
ゲームだとこの死んだときってのが微妙でね。
オブジェクト自身が本当に消滅したときなのか、
敵が死体で転がってる状態なのか、ってのは微妙でしょ。
だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の
プログラムはちょっと気を付けてみることにしてるｗ
もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
俺の環境だと即組み直しｗ
まあ、将来の為。
あ、これはデザパタとかオブジェクト指向とか関係無いから。
199:デフォルトの名無しさん
05/06/24 22:33:12
> 部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
意味不明。
200:デフォルトの名無しさん
05/06/24 22:58:38
>>199
そのままの意味だけど？
これ以上詳しくはできない。
201:デフォルトの名無しさん
05/06/24 23:05:28
単に死体になってるだけ＝ただの状態変化
実際にゲームから消滅した＝オブジェクトの消滅
として設計され、管理されているなら
> インスタンスの消滅を見てゲームを動かし
ていても問題ないのでは？
202:デフォルトの名無しさん
05/06/24 23:06:02
SE にとって重要な能力の一つは 自分の考えを簡潔かつ適切に他人に伝える だと思う
203:デフォルトの名無しさん
05/06/24 23:07:08
>>202
違うな。
どんな人間にも平気で嘘がつける度胸だ。
204:デフォルトの名無しさん
05/06/24 23:08:52
>>201
それが駄目なことについて延々と語るつもりは無いな。
いいと思うなら自由にやってくれ。
205:デフォルトの名無しさん
05/06/24 23:09:46
平気で嘘がつける = 適切に
206:デフォルトの名無しさん
05/06/24 23:10:32
SEなんて日本だけの腐れ職業のことなんざどうでもいいよ
207:デフォルトの名無しさん
05/06/24 23:11:14
またゲームかよおまえら
ゲームつくるのにデザパタはたいしていらんぞ
208:デフォルトの名無しさん
05/06/24 23:12:22 BE:393339078-
平気で嘘をつけない奴のほうが稀な気が。
209:デフォルトの名無しさん
05/06/24 23:13:26
そうだな日本は偽装派遣天国だしな
まあ面接でちゃんと問い詰めればすぐバレるけどな
問い詰めちゃいかんらしい
210:デフォルトの名無しさん
05/06/24 23:14:51
>>201
ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する（したように見える）バグがでるに一票。
危険な道は避ける。
これがわからない人間にゲームプログラマは難しい。
211:デフォルトの名無しさん
05/06/24 23:17:34
>>210
それはメモリ管理が出来ていないと言っているに等しいと思うんだが....
212:デフォルトの名無しさん
05/06/24 23:22:40
>>211
メモリの管理はできてるでしょ。
メモリは破壊していないし、はみ出してもいない。
ただ、ポインタを使いまわしてしまっただけの話さ。
まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。
鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、
就業規則に書いておけば自分の責任にならなくて済むと思うよ。
213:デフォルトの名無しさん
05/06/24 23:24:05
>>194
ん～、結局同じな気がする。
一瞬、変更に対して強いかな？とも思ったんだけど、「必要そうな情報」に幅がないし
幅を出すと結局変更が両者に及ぶから変わらない。
キャラクタ→スコアシステム#update→キャラクタ#getScore
これ以外の流れというのがちょっと見えてこない。
>>197
元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・
シングルトンをファクトリに生成させるパターンなら切り替えは可。
ScoreSystem scoreSystem = new ScoreSystemFactory(設定)
もう常套句すぎてアレなんだけど、こんな感じ。
214:デフォルトの名無しさん
05/06/24 23:35:04 BE:568936499-
Factoryをnewするのか？(･∀･)ﾆﾔﾆﾔ
隔離スレがパターンの話題で盛り上がって
本スレがスレッドストップとはこれいかに。（ﾟεﾟ）ｷﾆｼﾅｲけどな。
215:デフォルトの名無しさん
05/06/24 23:35:56
>>212
それは、ダングリングポインタを参照してしまったということだから、
広義ではメモリ管理が出来ていないに等しいと思う。
本来、誰かが使っているならそのポインタは削除してはいけない。
ま、それを完全に保証することはしばしば非常に困難であったり
不可能であったりするのは事実だが
216:デフォルトの名無しさん
05/06/24 23:38:44
メモリ管理できてねぇだけじゃん
インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる
217:デフォルトの名無しさん
05/06/24 23:40:13
>>214
あっ！orz
うるせ～、超省略表記なんだよヽ(`Д´)ﾉｳﾜｧｧﾝ
218:デフォルトの名無しさん
05/06/24 23:40:14
>>216
でも、この場合は誰の責任になるの？
敵クラス？敵管理クラス？メモリ管理クラス？
219:デフォルトの名無しさん
05/06/24 23:42:05
>>215
でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。
220:デフォルトの名無しさん
05/06/24 23:42:38 BE:505721489-
ところで複雑なスコアシステムってどんなのがあるの？
あんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。
221:デフォルトの名無しさん
05/06/24 23:45:10
>>219
いや、それはいいすぎ....
まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは
確かだが、常にそうだというわけではないし、参照カウンタで済む場合は
それを使うという手もある。
222:デフォルトの名無しさん
05/06/24 23:45:12
ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない
ゲームタスクのループ内で自機が参照してるかも知れないし
他の敵も参照してるかもしれない
敵キャラに消滅フラグなりなんなり持たせて
ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする
ってデザパタ関係ないな
223:デフォルトの名無しさん
05/06/24 23:45:31
ボーリングは少しメンドイ。
マージャンとかかな。
224:222
05/06/24 23:45:54
>>220
225:223
05/06/24 23:46:46
222すまん、ﾚｽつくの速すぎて慌てた。
>>220
226:デフォルトの名無しさん
05/06/24 23:49:47
>>221
でも本音ではしっかりステータス管理してもらったほうがいいでしょ。
よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。
227:デフォルトの名無しさん
05/06/24 23:52:12
>>226
なぜだッ！！
なぜ貴様に俺の心が読み取れるんだッ！！！
228:デフォルトの名無しさん
05/06/24 23:52:25
>>223
マージャンとインベーダーの間で再利用するの？
されは流石に無理ないか？
229:デフォルトの名無しさん
05/06/24 23:55:43 BE:442506097-
>>223
あぁ、なるほど。
敵の消滅とかの話が出てたから、
シューティングっぽいゲームばかりを想像していたヨ。
>>228
マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。
なので切り替えられると便利かもしれない。
230:デフォルトの名無しさん
05/06/24 23:56:50 BE:168574346-
さすがに異種ゲームの点数計算クラスを共有しようとは誰も考えないと思うので。
231:デフォルトの名無しさん
05/06/25 00:16:23
>>214
相変わらず僻みっぽい馬鹿だな。
とりあえず
ｽﾚﾘﾝｸ(tech板:14-15番)
のリンク先くらい読んでから煽れクズ
232:デフォルトの名無しさん
05/06/25 00:20:00
結局、>>198からの議論は、「オブジェクトを（ゲーム上）消したことに
すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」
（通常後者のほうが遅い）
ということに尽きるのかな。
一言で言えるんだから、一言で言えばいいのに。
233:デフォルトの名無しさん
05/06/25 00:21:35
まぁ、>>213がド素人なのは誰の目にも明らかだがなｗ
Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。
Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。
234:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/06/25 00:30:39
スルー。
236:214
05/06/25 00:34:49 BE:210717465-
>>231
相変わらず汁が先走ってるな。
とりあえず >>213-214 >>217 の流れを見て
自分の過ちと傲慢さを理解して恥じろ。
237:デフォルトの名無しさん
05/06/25 00:36:54 BE:126431429-
>>232
注意点は一言で言えるが実装は一言で言えないぜ。
238:デフォルトの名無しさん
05/06/25 00:39:54
>>237
流石に実装まで示せとは誰も言ってないじゃまいか。
239:デフォルトの名無しさん
05/06/25 00:41:23
>>238
もう、日本は終わったんだよｗ
240:237
05/06/25 00:44:23 BE:505721298-
>>238
>>198-～の実装の議論は少し有意義に見えたが。
241:234
05/06/25 00:49:32
華麗にスルーされちゃってぼくちん少し寂しいの
てへ
242:デフォルトの名無しさん
05/06/25 00:53:55
>>241
俺はアンチなんだけど
それって実体はいつできるんだ？
呼び出す前からできちまってる気がしねぇ？
243:234
05/06/25 00:56:37
コンストラクタはstaticにすればいいんじゃまいか
つか、それだけの問題で
まいかい
Singleton timpo = Singleton.getInstance();
bokkiage = timpo.invoke();
とかやるのはいやです。
244:デフォルトの名無しさん
05/06/25 00:57:06
目的は「インスタンスを1つに固定する」だからいいじゃん
245:デフォルトの名無しさん
05/06/25 00:57:15
華麗なる素人スレ
246:デフォルトの名無しさん
05/06/25 00:58:12
>>243
bokkiage = (Singleton.getInstance()).invoke();
247:デフォルトの名無しさん
05/06/25 00:59:32
>>234
仮想コンストラクタで検索。
一般に、クライアントコードが簡素になる点と
融通が効く点が利点して上げられてる。
248:デフォルトの名無しさん
05/06/25 01:00:36
>>243
それじゃおめ、
そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな？
つ 逝ってよし
249:234
05/06/25 01:02:39
>>247
継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが
実際には、継承なんかしないクラスこそシングルトンの候補であることが
非常に多い気がします。
その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。
「クライアントコードが簡素に成る」については全く納得がいきません。
メンバがstaticであれば
(Singleton.getInstance()).invoke();
ではなく
Singleton.invoke();
と書けるでしょう。
250:デフォルトの名無しさん
05/06/25 01:04:50
まあ、いつみてもデザパタは役に立たないよね。
251:デフォルトの名無しさん
05/06/25 01:06:04
なんでSingletonの話題しか振れないの？
重箱の隅しか突付けない哀れな煽りだ
252:234
05/06/25 01:07:00
ぼく、あおりじゃないのに(; ;)
253:デフォルトの名無しさん
05/06/25 01:07:14
======================================================================
このスレは厨房を隔離するための隔離スレです。。。
======================================================================
254:デフォルトの名無しさん
05/06/25 01:07:54
>>234 → >>243 → ぬるぽ
255:デフォルトの名無しさん
05/06/25 01:16:10
>>252
お前はネタｗ
256:デフォルトの名無しさん
05/06/25 01:20:06
>>249
インベーダーの例に戻って言うと、当初のスコアシステムに
ハイスコアの記録機能を追加した新スコアシステムを作る
場合、継承するのが妥当なんじゃない？
257:234
05/06/25 01:21:39
>>256
その場合、旧スコアシステムと新スコアシステムが共存しないのであれば
継承する必要は無いと考えますが。
258:234
05/06/25 01:22:03
>>255
ぼくでおなにーとかはしないでください
こわいので
259:デフォルトの名無しさん
05/06/25 01:24:55 BE:245837257-
単なる関数郡として使うだけならstaticでいいと思う。
260:234
05/06/25 01:26:34
>>259
それは、いわゆるUtilityクラスのような、状態の存在しないものですね。
それについて異存のあるひとはいないとおもいます。
ぼくがいっているのは、状態が存在するが、システムでユニークなクラス
のことです。とゆうか、Singletonというのは、そのようなものでしょ？
261:234
05/06/25 01:27:07
> システムでユニークなクラス
ちょっとはしょりすぎた
すみません、酔っているので
262:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/06/25 01:30:31
まぁ文字列渡すよりは、
・コンフィギュレーション選択用の定数か、
・コンフィギュレーションを表すオブジェクト
を渡すべき
264:デフォルトの名無しさん
05/06/25 01:32:54
>>260
それは「グローバル変数」だ。悪。
シングルトンでは「状態のないもの」を表現する。
たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、
「ステートパターン」で使うステートオブジェクトとか。
「ファクトリー」もそうだ。
265:デフォルトの名無しさん
05/06/25 01:34:21
>>257
オブザーバーパターンとのかみ合わせを考えてみて。
public class Enemy {
addObserver(ScoreSystem ss) {}
}
↑こうなってた場合、継承が必要。
public interface Observer {}
public class Enemy {
addObserver(Observer observer){}
}
↑こうしとかないオマイが馬鹿と言われれば、だよね～
としか言い様がない気もするが・・・・・・
266:234
05/06/25 01:34:27
>>254
え？
ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが
間違いですか？
なんか、ちょっとはつみみな所見です。
267:234
05/06/25 01:36:31
>>265
いやその、共存する必要が無いのであれば、インタフェースを変えずに
スコアシステムの「実装」を変えればいいだけなのではないかと。
なにか勘違いしていますか？ぼくは
268:234
05/06/25 01:37:33
>>262
それはちょっとSingletonといいつつFactory風でもありますね。
そういうニーズがある場合には、確かに意義がある気がします。
あまりそういうケースが多くは無い気はしますが。
269:デフォルトの名無しさん
05/06/25 01:40:49
デザパタ役に立って無いよ。
そろって馬鹿だな。
デザパタとか別にしても。
270:259
05/06/25 01:40:47 BE:379290896-
>>260
いまいちやりたいことが分からないなぁ…。
Singletonが1種類のオブジェクトしか返さなくて、
将来その仕様に変更がないと言い切れるなら
いっそ状態もstatic管理でいいと思う。要するにSingleton不要。
デザパタは仕様変更に柔軟に対応するための手段だと思うから。
271:デフォルトの名無しさん
05/06/25 01:42:57
>>264
このスレ読んでると、どんどん悪い癖、迷信に染まっていく傾向があるな。
状態はグローバル変数だから駄目？
それはあんたの信念であって、広く認められているSingletonの定義より狭いやん。
例えばアプリケーションの設定を Singletonに置くとして、
設定を変更する事は充分ありえる。つまり、Singletonに状態を持たせる事は充分有り得る。
GoF日本語版 p138
◎結果
Singletonパターンの効果を次にあげる。
1.インスタンスへのアクセスを制御する。(詳細略：唯一のインスタンスなのでアクセスチェックが簡単)
2.名前空間を減らす。Singletonパターンはグローバル変数の改良である。唯一のインスタンスを格納するグローバル変数 (注: C++, Smalltalk)を宣言する必要はなくなる。
3.オペレーションや内部表現を詳細化できる。(詳細略：Singleton のサブクラス化に関する話)
4.インスタンスの数を変えることができる。(詳細略：インスタンス数を２つ以上に変更する事も容易)
5.クラスオペレーションよりも柔軟である。(詳細略)
272:デフォルトの名無しさん
05/06/25 01:43:38
>>270
Visitorが状態を持たないとき、
それでもオマイさんは
Visitorをnewしますか？
273:234
05/06/25 01:43:59
>>270
いやその、「仕様変更」に対するデフォルトの対応が「継承」である、
というほうがぼくにとっては不自然なのですが。
たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて
両者に対応しなければならない、とかいうケースであれば、継承を
使うのは理解できます。
しかし、そもそも「唯一」であったものに、「継承」を適用するケース
って、そんなに多いのかな、と。普通、継承は、複数のものの差異を
選択的に無視したい場合に用いますよね。単純化のしすぎですが。
274:デフォルトの名無しさん
05/06/25 01:45:29
つまりさ、このスレの白熱議論っつうのは、
すべからく >>264みたいな素人の迷信暴言が発端なわけ。
くだらねぇんだよおまぃらの議論は
275:デフォルトの名無しさん
05/06/25 01:45:47
>>271
GoF本にはそんなこと書いてなかったけど
一体いつ定義されたの？
276:234
05/06/25 01:45:57
ぼくのほうが知
277:デフォルトの名無しさん
05/06/25 01:46:13
>>274
面白い議論ｷﾎﾞﾝ
278:デフォルトの名無しさん
05/06/25 01:46:26
>>275
恥を知れクズが
279:234
05/06/25 01:46:38
とぎれた
ぼくのほうが素人だもん
とか書こうとしたのに
280:デフォルトの名無しさん
05/06/25 01:48:33
>>278
かかってこいよ厨房ｗ
281:デフォルトの名無しさん
05/06/25 01:48:39
>>266=>>234
おまぃは誤爆してる上、
>>234の定義で>>243するとNullPointerExceptionがおきるつう認識もない・・・
・・・Singleton書いた事あるぅ？(>>262を参照汁)
282:デフォルトの名無しさん
05/06/25 01:49:13
>>267
差分プログラミングと開放/閉鎖原則で検索。
283:デフォルトの名無しさん
05/06/25 01:49:47
>>280は底知れない白痴厨房。GoF本手元に置かずにそんな煽りやってるとは抱腹絶倒だな。
284:234
05/06/25 01:50:29
>>281
あ、>>234の例はただの非常に単純化した例ですので。
いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ
で行うようなクラスをSingletonの変わりにして何かまずいのか？
ということに過ぎません。
285:デフォルトの名無しさん
05/06/25 01:51:10
>>271の該当ページを読んでみたらぁ？
286:234
05/06/25 01:52:42
>>282
メイヤー先生ですか。
私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。
それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない
限り、継承してメソッドをオーバーライドするより元のメソッドそのものを
書き換えることのほうが容易であることも多い気がします。
287:234
05/06/25 01:53:59
実際、バージョンアップの際に常に継承で対応するという開発手法は
どれぐらい一般的なんでしょうか？
もとのクラスを書き換えるのは、邪悪？
open/close原則を厳密に適用すれば、そういうことになってしまいますね。
288:デフォルトの名無しさん
05/06/25 01:54:51
で？
好きにすりゃえーやん。
漏れは藻舞を説得するつもりはねぇ～し
289:259
05/06/25 01:55:54 BE:189645293-
>>234はSingletonにこだわらないほうがいいと思われ。
もうこれは個人個人の開発スタイルなので。
それでも共同開発時はSingletonをお勧めしたい。
290:デフォルトの名無しさん
05/06/25 02:00:01
>>287
アンチの俺から言わせると、
一般的なわけねーだろ。
あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。
アホだアホ。マジで救いようがねー。
291:デフォルトの名無しさん
05/06/25 02:03:49
哀れなもんだ
煽れる時に煽るだけで、
中身は空っぽだもんな、おまえ
292:デフォルトの名無しさん
05/06/25 02:04:28
>>268
仮想コンストラクタはファクトリとシングルトンの合わせ技だから
ニーズは普通にあると思うよ。
オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ？
293:234
05/06/25 02:04:40
ぼくは、あおりじゃないんだもん(; ;)
294:デフォルトの名無しさん
05/06/25 02:05:42
>>291
オマエモナーｗ
295:デフォルトの名無しさん
05/06/25 02:06:35
>>284
1つのクラスが複数のstaticメンバ変数を管理するのはいくない。
296:234
05/06/25 02:07:54
>>292
ニーズは、あるでしょうね。
ぼくは、実はSingletonでなくていいのに
「いまどきSingletonじゃないと、女のコにモテないぞ」
「グローバル変数はダサ！Bjarne stroustrupが何と言おうと絞め殺せ」
「static記憶クラス？そんなん、石器時代の遺物でしょ？」
とかそんな理由でSingletonにされているケースも、結構おおいんじゃないの？
と、そういいたかっただけです。
297:234
05/06/25 02:08:21
>>295
それは、なぜでしょうか。
298:デフォルトの名無しさん
05/06/25 02:08:44
>>291
文体と主張だけで彼は特定できる。
だから、スルーして淡々と進めてるだろ？お前さんもスルーするよろし。
299:デフォルトの名無しさん
05/06/25 02:10:45
デザパタ信者は巣に帰れよ。
ｽﾚﾘﾝｸ(tech板)l50
ここでデザパタを使う前提の話をするな。
ここはデザパタの存在の可否を決めるスレだ。
＃大体、デザパタなんて誰も使ってないんだから過疎スレで
＃まとまってろってのｗ
＃アンチをこっちに隔離したとかほざいてたくせにアンチ追い出したら
＃ただの過疎スレになってやんのｗバーカｗ
300:デフォルトの名無しさん
05/06/25 02:11:45
>>298
ここじゃ荒らしはお前の方なのｗ
わかったらさっさと過疎スレ帰れよｗ
301:デフォルトの名無しさん
05/06/25 02:12:20
>>297
クラスの役割が訳わかんなくなるから。
302:デフォルトの名無しさん
05/06/25 02:13:14
>>299-300
哀れな奴
303:デフォルトの名無しさん
05/06/25 02:13:38
>>302
ヒント：スルー
304:デフォルトの名無しさん
05/06/25 02:14:54
>>302-303
本気で帰ってよ。
デザパタ語るなら向こうが本スレだからｗ
305:234
05/06/25 02:15:01
>>301
ぼくは頭が悪いので、やはりそれでは理解できませんね。
確かに全てをstaticで実装すれば、クラスはただのグローバル変数＋関数と
それをつつむnamespaceに同等のものになるでしょう。
で、それが何か問題なのですか？
306:デフォルトの名無しさん
05/06/25 02:16:01
>>305
>何か問題なのですか？
だからここはデザパタの可否を決めるスレだっつってんだろ！
荒らしが！
307:デフォルトの名無しさん
05/06/25 02:18:16
>>305
だいたい、何、頭に血上らせて必死におばかな議論してんだ、厨房。
グローバル変数を１つも使わないプログラムとかみたことないのか？
使ってる時点でレベル低すぎだってのにいらいらすんだよ。
お前みたいな馬鹿みてると。
308:デフォルトの名無しさん
05/06/25 02:18:25
>>296の発言で、もう>>234はネタ決定だな。
わざわざSingletonが当てはまらない想定を持ち出して煽ってるんだから、
別にSingleton勧めるいわれはないじゃん。
>>234もそろそろ初心者プログラミング相談室にでも相談してみたらどう？
309:234
05/06/25 02:19:24
>>295さんの主張で一番よく分からないのは、
「1コのstaticメンバならOKだが、複数だとNGになる」
という理由です。
そこのところをもう少し分かりやすく説明していただけませんか。
寡聞にして聞いたことの無い主張なものですから。
310:デフォルトの名無しさん
05/06/25 02:19:33
>>307も変な奴だな。
Singletonはグローバル変数の代わりをスコープに入れている。
つか、Javaじゃグローバル変数なんてないし。
311:デフォルトの名無しさん
05/06/25 02:19:46
>>305
そういうことすると、そのクラスが何してるか（何を管理しているクラスなのか）、
後から見た人はわかんないでしょ。コード追っていかないと。
だからクラスの役割ははっきりさせる必要がある。
312:デフォルトの名無しさん
05/06/25 02:19:53
>>287
利点もあるし、難点もあるな＞継承
Javaなんかだと、最近は継承よりも委譲とインターフェイスを
優先する風潮がある。
ソースの書き換えは、規模が大きくなると変更が他の部分に
影響を与えてドタドタドタっとドミノ倒しになる事がある。
それじゃあ継承ならそうならないかって言うと、まぁそうとも言
い切れんわけだが・・・・・・
まっ、それでinterfaceを多用する風潮が生まれたんだろう。
これならインターフェイスのみを残して新しく書き起こす場合
でも、継承を利用する場合でも、変更部分を局所化できる。
313:234
05/06/25 02:20:50
>>308
いやその、パラメタライズされていないgetInstance()を使う
Singletonの例は多いと思うのですが。
パラメタライズされている場合については、了解しました
と言っておきましょう。
314:デフォルトの名無しさん
05/06/25 02:21:03
>>312
＞Javaなんかだと、最近は継承よりも委譲とインターフェイスを
＞優先する風潮がある。
Java「なんかだと最近」？はぁ？
最初っからそうだよ厨房
315:デフォルトの名無しさん
05/06/25 02:21:24
>>310
はぁ？デザパタ信者ってのは、
グローバル変数の何がまずいのか知らないのか？
アホだな。レベルが低すぎる。
もうちょっと勉強してきてくださいよｗ
316:234
05/06/25 02:22:28
>>311
>>309に答えていただけませんか。やはりよくわからないんですが。
なぜstatic変数が吹く数字なると
「後から見た人はわかんない」ようになるのか。
317:デフォルトの名無しさん
05/06/25 02:23:05
語尾ダブリューの人、なんか話題がtoo oldで哀れ
318:デフォルトの名無しさん
05/06/25 02:24:00
>>316
俺も聞いておきたい。つか、ネタかローカルルールだと思っている。
319:デフォルトの名無しさん
05/06/25 02:24:11
>>311が逃げてるのがよくわかるなｗ
ほら、本スレに逃げ込めよｗ
320:234
05/06/25 02:24:23
>>312
ぼくがinterfaceに対するプログラミングの一番の恩恵を認識したのは
実はC++のリンク互換性なんですがね。
COMの発想のベースはそこにあります。大変汚いものですが。
321:デフォルトの名無しさん
05/06/25 02:25:20
なんかかなりネタ臭いスレになってきたな。
322:デフォルトの名無しさん
05/06/25 02:26:15
>>321
お前は速く>>309の質問に答えてやれよｗ
323:デフォルトの名無しさん
05/06/25 02:26:57
>>311, >>316
実は、Singletonってインスタンスが２つ以上あってもいいんだよね。
つか２つ以上生成した時点で、狭義のSingletonとは見なされない傾向があるが。
例えば某所で話題になっていたInstance PoolとかConnection Poolみたいなパターンになっちまう。
324:デフォルトの名無しさん
05/06/25 02:27:55
>>323
だからどうしたんだよ。余計なレスつけんなアホ。
325:234
05/06/25 02:28:33
>>323
Poolのようなものならば、PoolManagerが欲しい気がしますね。Singletonの。
326:デフォルトの名無しさん
05/06/25 02:31:24
>>325
お。冴えてるやん。
すると、ダンマリ決め込んでる>>311が回答すべき内容が見えてくる・・・はず・・・なんだが・・・なんともはや
327:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/06/25 02:32:55
一向にまとまる気配が無いよ＞デザパタ
こんなのがコミュニケーションツールでいいんですか？＞デザパタ
人によって使い方違ってるじゃないですか？＞デザパタ
職場でもこんな戦いをしなきゃいけないんですか？＞デザパタ
329:326
05/06/25 02:33:17
あぁーあ。せっかく回答が見えかけた(つか見えた)のに、
また訳わかんない主張系の人が、ｽﾚを混沌に導く・・・・・・もう飽きたから寝る。
330:デフォルトの名無しさん
05/06/25 02:33:49
>>327
つか、マジで本スレ帰れってｗ
331:デフォルトの名無しさん
05/06/25 02:34:50
>>329
お れ の せ い に な る の は な に か ち が う き が す る ！ （笑）
332:234
05/06/25 02:40:17
>>327
ただの好き嫌いの問題であれば、ぼくの>>296の主張はあながち
ウソでもなかったようですね。
ちなみにそれによっていちいちgetInstance()を書かなければならないことを
あなたは面倒であると考えたことはないのでしょうか？
333:259
05/06/25 02:41:23 BE:189645293-
>>329
何に対する回答だ？？回答以前に問題が明確でないんだよ。論点あちこち行ってるじゃん。
334:デフォルトの名無しさん
05/06/25 02:42:40
こっちの方が盛り上がってるのがウケル。
こっちをデザパタスレにしようよ。
335:寝ぼけまなこでレス
05/06/25 02:44:06
>>333
>>311
336:寝ぼけまなこでレス
05/06/25 02:45:15
>>334
偽デザパタｽﾚ
337:寝ぼけまなこでレス
05/06/25 02:49:49
338:デフォルトの名無しさん
05/06/25 02:51:09
厨房の行動パターン
・メール欄に文章
339:259
05/06/25 02:51:15 BE:224765748-
>>335
static管理したらクラスの役目がわかりにくくなるって？
インターフェースが同じなら変わらないだろ。論点にもなりゃしないさ。
340:
05/06/25 02:52:01
341:259
05/06/25 02:53:01 BE:189645293-
ム板にもIDｷﾎﾞﾝﾇ
342:デフォルトの名無しさん
05/06/25 02:53:21
>>339
>>323, >>325-326
343:デフォルトの名無しさん
05/06/25 02:54:48
>341
お前そんなんだからいつまでたっても0ポイントなんだよ。
344:デフォルトの名無しさん
05/06/25 02:55:58
で、アンチの反証は？
345:334
05/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:デフォルトの名無しさん
05/06/25 02:58:56
>>345 GJ.
347:デフォルトの名無しさん
05/06/25 03:00:55
>>334
だからデザパタスレなんて本来はその存在の可否に関する
議論の方がもりあがってたんだってば。
デザパタ自体はシングルトン１つとっても意見はバラバラ。
コミュニケーションツールなんて夢のまた夢。
掲示板じゃ自由に言えるけど、会社じゃ適用に至る明確な理由が必要になる。
そこでデザパタが必要である理由なんて説明できる奴がいるわけが無い。
昔からずっとこんな調子なんだよ。
信者とアンチの聖戦が一番盛り上がるんだから叩きだしたって誰かが追撃してくるんだよ。
構図はいつも
「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」ＶＳ「オブジェクト指向原理主義者」
348:259
05/06/25 03:00:55 BE:568936499-
>>342
Poolはわからんが、
インターフェースとドキュメント見りゃ動作が分かるってのが、あるべきクラス設計の姿だろ、
実装に複数のstatic変数使ったからって、それが崩れることがあるのか？
349:259
05/06/25 03:03:10 BE:126431036-
>>347
＞オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿
アンチデザパタ派は何故いつもそう言う。
たとえば>>345がオブジェクト指向を理解できていないように見えるのか？
オブジェクト指向を理解しないとデザパタ理解できないぜ。
350:デフォルトの名無しさん
05/06/25 03:04:55
>>347
頭悪い議論で盛り上がるのはもう沢山。
だから隔離されてるんだよおまぃは
351:234
05/06/25 03:06:06
>>345
ああなるほど、そういう用例を考えると便利ですね。
でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
普通のオブジェクトよりその点がちょっとダーティ。でも逃げ道は在るよ、
というところでしょうか。
>>347
> 構図はいつも
> 「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」
> ＶＳ「オブジェクト指向原理主義者」
ぼくはどっちでもないとおもいます。
352:デフォルトの名無しさん
05/06/25 03:07:27
構図はいつも、「自作自演するアンチ」vs「自作自演するアンチアンチ」
353:234
05/06/25 03:07:55
そろそろ
イマドキDIだからSingletonなんかつかわないぜ（ﾌﾟ
とか誰か言うのかと思ってたらそうでもなかったですね
354:234
05/06/25 03:08:24
>>352
ぼくは自作自演なんかしてないもん(; ;)
355:デフォルトの名無しさん
05/06/25 03:08:50
基本的に意味不明。
説明汁。
356:デフォルトの名無しさん
05/06/25 03:09:47
なんだServiceLocatorの話か。
357:259
05/06/25 03:10:11 BE:393338887-
>>351
待て待て、>>273 で継承を否定しておきながら、それはないだろ。
>>345 は継承なくては実現し得ないんだぞ。
358:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/06/25 03:11:41
どーでもいいですよ。
>>273と>>351で同じ仮定をしなければならない義理があるわけでもなし。
つか、同じ仮定をしつこく主張しつづけたら、議論は進まない。
360:259
05/06/25 03:13:02 BE:252860494-
>>345 は継承による仕様変更の典型例だってことを言ってるのよ。
仕様変更に継承を用いることを肯定するなら、この問題は終結するはずなのだが。
361:デフォルトの名無しさん
05/06/25 03:13:10
>>358
>>271
362:234
05/06/25 03:13:46
>>357
ぼくはべつに継承を常に否定してるわけじゃないんですが。
不要な継承を否定してるだけです。
>>345は、インタフェースを合わせるために必要な継承を巧みに使っている
例ですね。
まあ、実際にこういうtechniqueが実際にどれだけ必要になるかといえば、
疑問ですが。
363:デフォルトの名無しさん
05/06/25 03:13:49
>>360
じゃ終結って事で。
364:デフォルトの名無しさん
05/06/25 03:13:56
>>349
少なくともお前は理解していないｗ
オブジェクト指向云々に関する話題は>>345には出ていない。
したがってお前はまぬけだ。
>オブジェクト指向を理解しないとデザパタ理解できないぜ。
これはまったくの嘘。
デザパタはオブジェクト指向なんてまったく知らない奴が作った物。
よっぽどのアホでもなきゃ騙されないけどねｗ
現にここにいる奴のほとんどが学生だろ？
言語は覚えたけど、プログラムが組めないってレベルの奴。
まあ、プログラマでもないのにいきなり現場にぶち込まれた奴が
たくさんいるからこのレベルの奴だと色々模索するから
学校のお勉強に近いデザパタに妄信する奴がでてくるんだよね。
だけど、いくら勉強してもプログラムなんて組めるようにはならない。
図星だろ？
くくくっ、プログラムの組み方が書いてある本が世にあるとよかったなぁｗ
365:334
05/06/25 03:14:07
>>347
あれ？アンチの人？おまいよく状況を知ってるなｗｗｗｗ
そうなんだよ昔から相手を馬鹿にするだけで、ろくな議論しないんだよあのスレｗｗｗ
だからここを有益なところにしようｗ
＞デザパタ自体はシングルトン１つとっても意見はバラバラ。
＞コミュニケーションツールなんて夢のまた夢。
コミュニケーションツールは確かに無理だねぇ。
書籍にしても著者によって捉え方が全然違う。
読んだ書籍によって、読み手も捉え方が異なってしまうし。
うーん、まあコーディングテクニック集ってとこなのかなぁ。
366:デフォルトの名無しさん
05/06/25 03:14:58
なんだ、NGワードが増えてきたな。
携帯４っつ使ってレス付けてるのか(笑
367:デフォルトの名無しさん
05/06/25 03:16:18
□■□■□ 祝！秀ケツ ■□■□■
368:234
05/06/25 03:16:22
ああ、なるほど
>>259さんには、あのアダプタの適用も「仕様変更に際して用いられる
典型的なtechnique」なのか。
その辺が僕とは認識が違いますね。
まあ、仕様変更といっても色々ありますから、なんとも言えませんが、
Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
噛ませることがベストな解である、というタイプの仕様変更って
そんなに無い気がしますよ？
369:259
05/06/25 03:16:29 BE:112383528-
結局 >>234 は >>234 の質問から何を知りたかったわけ？
370:デフォルトの名無しさん
05/06/25 03:17:13
いままでどおり、机に向かって勉強してればプログラムが組めるようになるとでも思ったか？学生諸君ｗ
ならないだろ？ざまーみろｗ死ぬまでくるしめｗ
371:234
05/06/25 03:17:53
>>369
まあ、こんだけスレも盛り上がってることですし、いいじゃないですか(w
372:334
05/06/25 03:19:03
>>351
そですね。私の理解としては逃げ道つくるぐらいですかね。
開発してる時とかにメソッド呼ぶ前に、ログをとるデコレータクラスとかよく作ります。
そういった面で扱いやすいってだけですかね。
他にもメリットはあるかもしれませんが。
＞でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
↓これでどうでしょう・・・。一行にしてみました。だめですか・・・。
Singleton s = new TuikaKinouSingleten(Singleton.getInstance());
373:デフォルトの名無しさん
05/06/25 03:19:53
>>369
たぶん、getInstance()にパラメータつけるより getFoo(), getBar()の方がいい、とか、
それよりも static methodの方がもっとシンプル (継承できないけど継承は仕様変更の手段とすべきではない)
とか。じゃねぇ～の。いい加減寝るぞ
374:259
05/06/25 03:22:05 BE:393338887-
>>368
＞Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
＞噛ませることがベストな解である、というタイプの仕様変更って
＞そんなに無い気がしますよ？
ベタベタだがたとえばウィジットを生成する Factory。プラットフォームによって切り替え。
そんなにワサワサと例は出せないが。
逆に仕様変更のない Singleton は Singleton である必要がない気がする。
それこそ Utility 的な。
>>371
まぁそうだなｗ
375:デフォルトの名無しさん
05/06/25 03:22:10
正直、アンチの俺の意見としても継承の悪用は止めたほうがいいといっておく。
376:デフォルトの名無しさん
05/06/25 03:26:32
そもそもUtilityクラスとは、オブジェクト指向設計の放棄である (とりあえずそこまでクラス化するゆとりがないとか含む)
である事を指摘しておこう。