1 名前:デフォルトの名無しさん mailto:sage [2005/06/21(火) 19:09:56 ] そもそもデザインパターン自体どうなのよ?って話はここでやれ。
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 ] このスレの存在がトリッキー
117 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 20:59:45 BE:140478454- ] お前らトリッキーって言いたいだけちゃうかと。
118 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:05:00 ] そうだ
119 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:11:00 ] お前らがトリッキーとか言ってる間に俺は既にトレッキー。 まぁ、お前らはゆっくりトロッキー辺りを目指せってことだな。
120 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:11:08 ] じゃあエキセントリック
121 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:28:48 ] 結局アンチに正確な反証挙げられる奴はいなかったわけか
122 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:37:08 ] >>121 >>25 の方法って普通のオブジェクト指向でしょ デザパタ使ってる人ってこれのどの課程でデザパタを使うの?
123 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:39:05 ] 一応これも貼っとこう >>25 への反論 1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。 オブジェクト指向では不完全な表現しか得られない事象の例: 多重継承、 時間的な状態変化、 etc. 一般的に、不充分な表現しか得られない事象の例: 非常に複雑な対象物/概念 計算不可能な対象物/概念、 記述不可能な対象物/概念 etc. もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、 大半の科学者は仕事をする必要がなくなる。 (例:宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる) 2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、 対象物をそのまま記述するのではなく、 特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。 要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。 抽象化を行わないオブジェクト指向プログラミングがあるとすれば、 それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。 3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム) の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、 モデリング/設計/プログラミングの中心的な作業であり、 そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。
124 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:47:36 ] >>122 「対象物の構造を〜」ってことを 25 は言っているけど、その切り出し方は無数にある (例えばオセロで審判を導入するとかしないとか。審判を導入すると双方の不正を一元監視できたり) んで、その切り出し方の一例としてデザパタを応用するというふうに俺は使っている (デザパタは直接使用せず、応用として。改変なしでは絶対に組み込めないし、組み込みたくない)
125 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:48:36 ] >>123 それはネタでしょ。
126 名前:124 mailto:sage [2005/06/22(水) 21:49:18 ] ちなみに、改変しても組み込めそうになかったら、その時点であきらめてますのであしからず
127 名前:デフォルトの名無しさん [2005/06/22(水) 21:49:43 ] こんな下の方でチマチマやらずに、 上の方でどうぞ
128 名前:デフォルトの名無しさん [2005/06/22(水) 21:50:32 ] >>125 の存在が冗談
129 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:50:38 ] >>124 具体的にどうやって使うの? パターンに当てはめる方法でいいの?
130 名前:124 mailto:sage [2005/06/22(水) 21:55:55 ] >>129 当てはめはしない 俺が考えた構造と、デザパタで提示されている構造が一致したら 「お?このまま行っても平気か?」 って思ってる ついでに、提示された構造を参考に、幾らか修正を入れる 要は、どんな下らない物でも良いから、自分の考えを支持してくれる物があれば良いんだな俺の場合
131 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 21:59:02 BE:379290896- ] >>130 デザインパターンの本来の目的からは外れてる気がするが(゚ε゚)キニシナイ
132 名前:デフォルトの名無しさん [2005/06/22(水) 22:08:06 ] >>124 何処に石を置けるのか知らなければ、審判はジャッジできない。 何処に石を置けるのか知らなければ、CPプレーヤーは戦略を立てられない。 石を置くとボードがどう変化するのかを知らなければ、審判はジャッジできない。 石を置くとボードがどう変化するのかを知らなければ、CPプレーヤーは戦略を立てられない。 さて、どうしましょう?と、>>124 に話を振るのは筋違いだな。 さて、どうしましょう? 対象物の構造をそのままクラスとして反映させるのがオブジェクト指向と主張してた貴方! 上記の主張を前提に、クラス設計してみてちょいよ。
133 名前:124 mailto:sage [2005/06/22(水) 22:18:31 ] >>132 いや、だから、対象物の切り出し方は無数にあるって例を出しただけで…… (審判は思いつき。妥当かどうかは考えてない。ちなみに、俺は大抵ボードが制約を持つように組んでる) 答えは無数にある。どれも正解かもしれないし、どれも不正解かもしれない。
134 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 22:18:42 ] >>130 どうせ修正するなら、当てはめたほうが早いのではないでしょうか?
135 名前:124 mailto:sage [2005/06/22(水) 22:22:23 ] >>134 正直速くない。部分的に一致させる事もあるけど、 サンプルで提示されている構造の使用価値はサンプルで提示されている程度のレベルでしかないと思っているし ガチガチに当てはめると融通が利かない。妥協が必要
136 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 22:24:58 ] デザインパターンは 「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」 「あぁ、以前のシステムでも使っていたあれですね。あの方法で組めばいいんですね」 というまどろっこしい会話を 「それsingletonね」 「はい」 というシンプルな会話にするためにあるのよ
137 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 22:28:07 ] >>136 「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」 「あぁ、以前のシステムでも使っていた Singleton ですね。あの方法で組めばいいんですね」
138 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 22:41:43 ] >>136 1人のときは、全く役に立たないのでしょうか?
139 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 22:57:29 ] >>136-137 かつて2ちゃんの粘着くんの議論を終結させるために、 そーゆー一見もっともそうな説明をした事がある。 で、同じ話を何回書き込んだら気が済むの?
140 名前:デフォルトの名無しさん [2005/06/22(水) 23:00:09 ] アンチが何か具体的な事を書くまでマターリ待とう。 オブジェクト指向だの設計だのって、結局は具体的な事が言えない から逃げる為の口上に使ってるだけじゃん。
141 名前:デフォルトの名無しさん [2005/06/22(水) 23:09:37 ] >>140 この人のあいかわらずソースを求める姿勢はどうにかならないものだろうかw
142 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:09:55 ] ウンコだかウンチだか知らないが、 煽り好きの>>140 みたいなのは、リアルには付き合いたくない。
143 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:12:27 ] >>141 もウンコ
144 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:13:58 ] この人がどの人か知らないが、俺はソースなんて求めてない。 具体的な何かでいい。とりあえず、上で出てるクラス設計なんてどう? てか、言い訳多すぎ。
145 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:33:13 ] クラス図出せよ。
146 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:36:38 ] >>132 俺はこの件に関して傍観者だが、 >>132 の問題設定が問題の体を為していないのと、 せっかく>>123 に挙げた矛盾点を取り込んでいないあたりに、 そこはかとなく素人臭さを感じた
147 名前:デフォルトの名無しさん [2005/06/22(水) 23:38:51 ] >>146 俺もこの件に関して傍観者だが、 具体性がないところにいつものアンチ臭さを感じた
148 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 23:55:48 ] >>144-145 は、問題設定を明確にした上で、課題を出した方がいい。 このままだとアンチの自作自演と疑われて縞馬
149 名前:デフォルトの名無しさん [2005/06/23(木) 00:01:13 ] では、僭越ながらオレ様が課題をだしますよ。 Q1.オセロを構成するのに必要なクラスを列挙せよ。 Q2.Q1で列挙した各クラスの役割について簡素に説明せよ。 Q3.Q1で列挙した各クラス間の関係(接続)について簡素に説明せよ。
150 名前:デフォルトの名無しさん mailto:sage [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.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。 の理由が >オブジェクト指向では不完全な表現しか得られない事象の例: > 〜略〜 > (例:宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる) なんだろうけど。 これは一体何がいいたいのかわからない。 とりあえず、手当たり次第レスつけると。 >オブジェクト指向では不完全な表現しか得られない事象の例 って書いてあるけど。 なんでここで「多重継承」なの?(このへんでもう相手にしなくていいかなーって思った) 多重継承を表現するって聞いた事ないんだけど。説明キボン。 んで次に書いてあるのが「時間的な状態変化」だけど。 なにこれ?意味がわからない。何がいいたいの?説明キボン。 で >一般的に、不充分な表現しか得られない事象の例: って書いてあるけど。 >非常に複雑な対象物/概念 どこまで複雑なのかは知らんけど根気よくやればできるんじゃない? これはオブジェクト指向に限って表現できないものなのかなー。 >計算不可能な対象物/概念、 >記述不可能な対象物/概念 って書いてあるけど意味不明説明キボン。 ここでは1だけをとりあげたけど2と3なんて宇宙人の文でも読んでるのかと思った。ので意味不明。レス不能。
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 やだよ。 だってそいつなんだかんだいってソースコードくれくれいってるのみえみえじゃん。 関わるとソース出さないとわめきたてるからレスつけない方がいいよ。 オブジェクト指向での設計からソースまでもってけないだけだろそいつは。 単純にクンフーが足りないw
155 名前:デフォルトの名無しさん [2005/06/23(木) 00:13:39 ] クラス図出せ
156 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 00:16:37 ] ソースなんかいらないから、言語依存しないクラス図を出せよ。
157 名前:デフォルトの名無しさん [2005/06/23(木) 00:31:25 ] また逃げたw
158 名前:デフォルトの名無しさん [2005/06/23(木) 00:37:08 ] >>157 自作自演はバレてるから、さっさと>>149 のクラス図出せ
159 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 00:38:42 ] あと、シーケンス図もな。
160 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 00:40:41 ] >>159 自作自演はバレてるから、さっさと>>149 のクラス図出せ
161 名前:デフォルトの名無しさん [2005/06/23(木) 01:02:42 ] だからクレクレ厨を相手にしちゃ駄目だって。 何、あげたって結局理解できるわけないんだから。
162 名前:アンチじゃない人 mailto:sage [2005/06/23(木) 01:04:00 ] ってか正直、>>123 は俺でもわかりません。 1番を読み終えた時点で睡魔に襲われますた。
163 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 01:30:50 ] >>161-162 バレバレの自演はいいから早く出せよ
164 名前:デフォルトの名無しさん [2005/06/23(木) 01:40:37 ] >>163 なんのために?
165 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 02:00:08 ] 誤ったデザパタ推進派が、荒らしに来てる。 いやだ、いやだ。
166 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 02:04:36 ] いやあさすが隔離スレらしい展開だな(w 荒らしも糞も無いだろ 隔離スレにマトモな議論期待するなって
167 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 08:36:26 ] アンチの特徴:具体例を求めるとキレる 「デザパタってトリッキーだよな」 「どのへんが?」 「ムキー!!!あ;dlふぃうえあ;kじゃ;」 「オブジェクト指向がわかってればデザパタなんか設計に使わない」 「じゃあ○○をデザパタ使わずにどう設計する?」 「ぎえいぎえが;おい」
168 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 10:11:02 ] >>164-165 本当に言い訳がましいなw
169 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 12:32:12 ] お前ら空っぽの引き出しを何時まで弄ってるつもりだ? もう完全スルーでいいだろ? それはそれとして、このスレを何か有効に使う手はないものか?
170 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 13:13:42 ] っていうかここはもともとカラッポの引き出しを弄るスレですから
171 名前:162(通りすがり) mailto:sage [2005/06/23(木) 14:24:13 ] >>163 自作自演じゃねーし。 >>123 はごめん。素で意味不明。もっと文章力を付けてください。 で。オセロのクラス図?ごめwwwwダリwwwww
172 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 16:08:16 ] デザインパターンを貶しておきながら具体的な話からとことん逃げ続けるアンチでありました
173 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 19:19:58 ] >>169 【デザパタ嵌り道】こんな失敗しますたスレヽ(`Д´)ノウワァァン【失敗談】 というのはどうか?
174 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 21:05:03 ] まぁ大体理解できてないか適用するパターンを間違えた例がでて終わりだろ
175 名前:16 mailto:sage [2005/06/23(木) 21:50:37 ] 相変わらずちょっと空けるとずいぶん流れてるなー。このスレ。 あらかじめ断わっとくと、間違ってもソースコードはいらないから。 じゃあインベーダーの話をしよう。 >>25 >要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを >そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。 >この基本は絶対に変わらない。 >プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが >無かったら真っ先に担当者を問い詰めることができる。 >これがオブジェクト指向の単純な利点だ。 でさ、まず自機、敵、弾のオブジェクト(クラス)を作るじゃん。 1)自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの? 2)同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの? でさ、1と2って同じ処理だよね。やってることは。 どういう風に設計・実装するのか知りたいわけですよ。俺は。 俺がやるならどうやってもデザインパターンを使わずには作れないから。 っていうより、俺の能力じゃあ、どう書いても、誰かがこれはデザインパターンでいうなんとかパターンっていうものですよ。って言うだろう。俺がそのパターン名を知らなかったとしてもさ。
176 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 21:55:29 ] 抽象クラス「キャラ」から「自機」と「敵」を継承させて HitTest()は「キャラ」に実装するのが普通でしょう。 そのレベルではデザパタは別に関係ないし、例として適切じゃない気がするが。
177 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:10:50 ] つうかなんでいつも例がゲームなんだよ 中学生かよ
178 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:12:38 ] 懐かしの「オブジェクト指向は戦場では必要無し」スレの 香りのするスレはここですか?
179 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:13:56 ] しかもまた「オセロ」でも書いて説明しるって言ってるし。 オマイたちは本当に進歩しませんね。
180 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:29:20 ] >>176 で、弾もあるよね。自分も敵も弾もそれぞれ座標(現在地)持ってるよね。 自分オブジェクトは1個かもしれないけど敵とか弾はたくさんオブジェクトがあるよね。 やっぱりループで回すよね。 ここまででデザパタは1つも出てこないのか? >>177 じゃあ代わりに適切な例を上げて。
181 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:32:32 ] ゲームならオブジェクト指向でほぼOKでしょ。 俺が知りたいのはJ2EEアプリをJ2EEパターンを使わないで アンチの主張する「オブジェクト指向設計」のみでどうやるのかに興味がある。 どんなに素晴らしいモノなのか、教えてもらいたいものだよ。 本当にできるならねw
182 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:41:18 ] >>180 「弾」も「キャラ」から派生させれば問題なかろ。 もう少し条件つけんとCompositeだのFlyweightだのは出てこんぞ。
183 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:43:44 ] そういえば彼はJ2EEの話に対して1回「出来る」ってレス返しただけであとは完全スルーだったな
184 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:48:02 ] 仕事した事ないんだろ
185 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 22:50:33 ] J2EEアプリであるための条件って何なんだ? helloworld.jsp だけでいいんなら、別にパターンいらないぞ
186 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 23:14:01 ] >>181 前提が間違ってる。 崇高なオブジェクト指向を信奉する彼は邪悪なJ2EEなんて使わない。 彼なら最初にAPサーバを書くところから始めるに違いないw
187 名前:デフォルトの名無しさん mailto:sage [2005/06/23(木) 23:41:58 ] >>186 だよな。「Servlet」というフレームワークや実装パターンのカタマリみたいな プラットフォームは拒否るだろうからね。
188 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 00:25:49 ] 今のところ肯定派の圧勝か。。
189 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 00:39:14 ] アンチは理想論ばかり振りかざして具体例をまったく出せていないからね。
190 名前:いつものアンチ [2005/06/24(金) 01:03:27 ] 奇跡だ! まともな質問が! >>175 >1)自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの? >2)同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの? > >でさ、1と2って同じ処理だよね。やってることは。 >どういう風に設計・実装するのか知りたいわけですよ。俺は。 これはオブジェクト指向で設計をしていれば、 オブジェクトの抽出のときに自機と敵が存在するフィールド(シーンのがいい?)のようなものができると思うから そこに処理をかけばいいと思うよ。(なければフィールドクラスを作る。) そのフィールドでの出来事だしね。
191 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 02:03:47 ] >>190 その"フィールド"をメディエイターとしてするのかな? あと、敵キャラの動きとかはストラテジーパターンで表現できそうだ。 あと「スコアカウンタ」から「敵オブジェクト」を オブザーバーパターンを使って監視しておけば 得点の加算ができそうだね。
192 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 04:04:33 ] お前らシングルトンも知らないのw 死ねば?
193 名前:デフォルトの名無しさん [2005/06/24(金) 07:07:21 ] >>191 >あと「スコアカウンタ」から「敵オブジェクト」を >オブザーバーパターンを使って監視しておけば >得点の加算ができそうだね。 ん?これは何をやってるの? もし、クラスのインスタンスの数を数えてシステムに反映させているなら 設計が悪いと思う。
194 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 10:28:59 ] >>191 アンチの人にパターン名で解説しても話が通じんだろ。 >>193 「スコアカウンタ」のインスタンスが一つあって、 敵オブジェクト一つ一つにその「スコアカウンタ」のインスタンスを持たせておいて、 敵オブジェクト自身が死んだときに「スコアカウンタ」に点数を報告するって方法では? 設計悪いかな?漏れはまあいいんじゃないかなと思うけど。
195 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 10:46:38 ] 課題のインベーダー程度ならともかく 複数人同時プレーやもうすこし複雑なスコアシステムや設定によるスコアシステム自体の切り替えなどを考えると シングルトンのスコアシステムに必要そうな情報全てを付加したスコア発生メッセージを通知するのがベター 嫌な設計だが
196 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 10:49:06 ] 細かいところは分からないけど、全体的にMVCっぽくなりそうな...
197 名前:194 mailto:sage [2005/06/24(金) 11:30:53 ] >>195 複雑なスコアシステムだったとしても、 オブザーバに報告する内容をすこし増やせばいいんでない? シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。
198 名前:デフォルトの名無しさん [2005/06/24(金) 21:25:27 ] >>194 >敵オブジェクト自身が死んだときに ゲームだとこの死んだときってのが微妙でね。 オブジェクト自身が本当に消滅したときなのか、 敵が死体で転がってる状態なのか、ってのは微妙でしょ。 だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の プログラムはちょっと気を付けてみることにしてるw もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら 俺の環境だと即組み直しw まあ、将来の為。 あ、これはデザパタとかオブジェクト指向とか関係無いから。
199 名前:デフォルトの名無しさん [2005/06/24(金) 22:33:12 ] > 部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら 意味不明。
200 名前:デフォルトの名無しさん [2005/06/24(金) 22:58:38 ] >>199 そのままの意味だけど? これ以上詳しくはできない。
201 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:05:28 ] 単に死体になってるだけ=ただの状態変化 実際にゲームから消滅した=オブジェクトの消滅 として設計され、管理されているなら > インスタンスの消滅を見てゲームを動かし ていても問題ないのでは?
202 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:06:02 ] SE にとって重要な能力の一つは 自分の考えを簡潔かつ適切に他人に伝える だと思う
203 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:07:08 ] >>202 違うな。 どんな人間にも平気で嘘がつける度胸だ。
204 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:08:52 ] >>201 それが駄目なことについて延々と語るつもりは無いな。 いいと思うなら自由にやってくれ。
205 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:09:46 ] 平気で嘘がつける = 適切に
206 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:10:32 ] SEなんて日本だけの腐れ職業のことなんざどうでもいいよ
207 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:11:14 ] またゲームかよおまえら ゲームつくるのにデザパタはたいしていらんぞ
208 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:12:22 BE:393339078- ] 平気で嘘をつけない奴のほうが稀な気が。
209 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:13:26 ] そうだな日本は偽装派遣天国だしな まあ面接でちゃんと問い詰めればすぐバレるけどな 問い詰めちゃいかんらしい
210 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:14:51 ] >>201 ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する(したように見える)バグがでるに一票。 危険な道は避ける。 これがわからない人間にゲームプログラマは難しい。
211 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:17:34 ] >>210 それはメモリ管理が出来ていないと言っているに等しいと思うんだが....
212 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:22:40 ] >>211 メモリの管理はできてるでしょ。 メモリは破壊していないし、はみ出してもいない。 ただ、ポインタを使いまわしてしまっただけの話さ。 まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。 鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、 就業規則に書いておけば自分の責任にならなくて済むと思うよ。
213 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:24:05 ] >>194 ん〜、結局同じな気がする。 一瞬、変更に対して強いかな?とも思ったんだけど、「必要そうな情報」に幅がないし 幅を出すと結局変更が両者に及ぶから変わらない。 キャラクタ→スコアシステム#update→キャラクタ#getScore これ以外の流れというのがちょっと見えてこない。 >>197 元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・ シングルトンをファクトリに生成させるパターンなら切り替えは可。 ScoreSystem scoreSystem = new ScoreSystemFactory(設定) もう常套句すぎてアレなんだけど、こんな感じ。
214 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:35:04 BE:568936499- ] Factoryをnewするのか?(・∀・)ニヤニヤ 隔離スレがパターンの話題で盛り上がって 本スレがスレッドストップとはこれいかに。(゚ε゚)キニシナイけどな。
215 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:35:56 ] >>212 それは、ダングリングポインタを参照してしまったということだから、 広義ではメモリ管理が出来ていないに等しいと思う。 本来、誰かが使っているならそのポインタは削除してはいけない。 ま、それを完全に保証することはしばしば非常に困難であったり 不可能であったりするのは事実だが
216 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:38:44 ] メモリ管理できてねぇだけじゃん インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる
217 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:40:13 ] >>214 あっ!orz うるせ〜、超省略表記なんだよヽ(`Д´)ノウワァァン
218 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:40:14 ] >>216 でも、この場合は誰の責任になるの? 敵クラス?敵管理クラス?メモリ管理クラス?
219 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:42:05 ] >>215 でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。
220 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:42:38 BE:505721489- ] ところで複雑なスコアシステムってどんなのがあるの? あんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。
221 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:10 ] >>219 いや、それはいいすぎ.... まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは 確かだが、常にそうだというわけではないし、参照カウンタで済む場合は それを使うという手もある。
222 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:12 ] ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない ゲームタスクのループ内で自機が参照してるかも知れないし 他の敵も参照してるかもしれない 敵キャラに消滅フラグなりなんなり持たせて ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする ってデザパタ関係ないな
223 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:45:31 ] ボーリングは少しメンドイ。 マージャンとかかな。
224 名前:222 mailto:sage [2005/06/24(金) 23:45:54 ] >>220
225 名前:223 mailto:sage [2005/06/24(金) 23:46:46 ] 222すまん、レスつくの速すぎて慌てた。 >>220
226 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:49:47 ] >>221 でも本音ではしっかりステータス管理してもらったほうがいいでしょ。 よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。
227 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:52:12 ] >>226 なぜだッ!! なぜ貴様に俺の心が読み取れるんだッ!!!
228 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:52:25 ] >>223 マージャンとインベーダーの間で再利用するの? されは流石に無理ないか?
229 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:55:43 BE:442506097- ] >>223 あぁ、なるほど。 敵の消滅とかの話が出てたから、 シューティングっぽいゲームばかりを想像していたヨ。 >>228 マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。 なので切り替えられると便利かもしれない。
230 名前:デフォルトの名無しさん mailto:sage [2005/06/24(金) 23:56:50 BE:168574346- ] さすがに異種ゲームの点数計算クラスを共有しようとは誰も考えないと思うので。
231 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:16:23 ] >>214 相変わらず僻みっぽい馬鹿だな。 とりあえず pc8.2ch.net/test/read.cgi/tech/1119158274/14-15 のリンク先くらい読んでから煽れクズ
232 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:20:00 ] 結局、>>198 からの議論は、「オブジェクトを(ゲーム上)消したことに すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」 (通常後者のほうが遅い) ということに尽きるのかな。 一言で言えるんだから、一言で言えばいいのに。
233 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:21:35 ] まぁ、>>213 がド素人なのは誰の目にも明らかだがなw Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。 Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。
234 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:30:39 ] スルー。
236 名前:214 mailto:sage [2005/06/25(土) 00:34:49 BE:210717465- ] >>231 相変わらず汁が先走ってるな。 とりあえず >>213-214 >>217 の流れを見て 自分の過ちと傲慢さを理解して恥じろ。
237 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:36:54 BE:126431429- ] >>232 注意点は一言で言えるが実装は一言で言えないぜ。
238 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:39:54 ] >>237 流石に実装まで示せとは誰も言ってないじゃまいか。
239 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:41:23 ] >>238 もう、日本は終わったんだよw
240 名前:237 mailto:sage [2005/06/25(土) 00:44:23 BE:505721298- ] >>238 >>198-〜の実装の議論は少し有意義に見えたが。
241 名前:234 [2005/06/25(土) 00:49:32 ] 華麗にスルーされちゃってぼくちん少し寂しいの てへ
242 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:53:55 ] >>241 俺はアンチなんだけど それって実体はいつできるんだ? 呼び出す前からできちまってる気がしねぇ?
243 名前:234 mailto:sage [2005/06/25(土) 00:56:37 ] コンストラクタはstaticにすればいいんじゃまいか つか、それだけの問題で まいかい Singleton timpo = Singleton.getInstance(); bokkiage = timpo.invoke(); とかやるのはいやです。
244 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:57:06 ] 目的は「インスタンスを1つに固定する」だからいいじゃん
245 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:57:15 ] 華麗なる素人スレ
246 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:58:12 ] >>243 bokkiage = (Singleton.getInstance()).invoke();
247 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 00:59:32 ] >>234 仮想コンストラクタで検索。 一般に、クライアントコードが簡素になる点と 融通が効く点が利点して上げられてる。
248 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:00:36 ] >>243 それじゃおめ、 そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな? つ 逝ってよし
249 名前:234 mailto:sage [2005/06/25(土) 01:02:39 ] >>247 継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが 実際には、継承なんかしないクラスこそシングルトンの候補であることが 非常に多い気がします。 その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。 「クライアントコードが簡素に成る」については全く納得がいきません。 メンバがstaticであれば (Singleton.getInstance()).invoke(); ではなく Singleton.invoke(); と書けるでしょう。
250 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:04:50 ] まあ、いつみてもデザパタは役に立たないよね。
251 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:06:04 ] なんでSingletonの話題しか振れないの? 重箱の隅しか突付けない哀れな煽りだ
252 名前:234 mailto:sage [2005/06/25(土) 01:07:00 ] ぼく、あおりじゃないのに(; ;)
253 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:07:14 ] ====================================================================== このスレは厨房を隔離するための隔離スレです。。。 ======================================================================
254 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:07:54 ] >>234 → >>243 → ぬるぽ
255 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:16:10 ] >>252 お前はネタw
256 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:20:06 ] >>249 インベーダーの例に戻って言うと、当初のスコアシステムに ハイスコアの記録機能を追加した新スコアシステムを作る 場合、継承するのが妥当なんじゃない?
257 名前:234 mailto:sage [2005/06/25(土) 01:21:39 ] >>256 その場合、旧スコアシステムと新スコアシステムが共存しないのであれば 継承する必要は無いと考えますが。
258 名前:234 mailto:sage [2005/06/25(土) 01:22:03 ] >>255 ぼくでおなにーとかはしないでください こわいので
259 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:24:55 BE:245837257- ] 単なる関数郡として使うだけならstaticでいいと思う。
260 名前:234 mailto:sage [2005/06/25(土) 01:26:34 ] >>259 それは、いわゆるUtilityクラスのような、状態の存在しないものですね。 それについて異存のあるひとはいないとおもいます。 ぼくがいっているのは、状態が存在するが、システムでユニークなクラス のことです。とゆうか、Singletonというのは、そのようなものでしょ?
261 名前:234 mailto:sage [2005/06/25(土) 01:27:07 ] > システムでユニークなクラス ちょっとはしょりすぎた すみません、酔っているので
262 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:30:31 ] まぁ文字列渡すよりは、 ・コンフィギュレーション選択用の定数か、 ・コンフィギュレーションを表すオブジェクト を渡すべき
264 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:32:54 ] >>260 それは「グローバル変数」だ。悪。 シングルトンでは「状態のないもの」を表現する。 たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、 「ステートパターン」で使うステートオブジェクトとか。 「ファクトリー」もそうだ。
265 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:34:21 ] >>257 オブザーバーパターンとのかみ合わせを考えてみて。 public class Enemy { addObserver(ScoreSystem ss) {} } ↑こうなってた場合、継承が必要。 public interface Observer {} public class Enemy { addObserver(Observer observer){} } ↑こうしとかないオマイが馬鹿と言われれば、だよね〜 としか言い様がない気もするが・・・・・・
266 名前:234 mailto:sage [2005/06/25(土) 01:34:27 ] >>254 え? ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが 間違いですか? なんか、ちょっとはつみみな所見です。
267 名前:234 mailto:sage [2005/06/25(土) 01:36:31 ] >>265 いやその、共存する必要が無いのであれば、インタフェースを変えずに スコアシステムの「実装」を変えればいいだけなのではないかと。 なにか勘違いしていますか?ぼくは
268 名前:234 mailto:sage [2005/06/25(土) 01:37:33 ] >>262 それはちょっとSingletonといいつつFactory風でもありますね。 そういうニーズがある場合には、確かに意義がある気がします。 あまりそういうケースが多くは無い気はしますが。
269 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:40:49 ] デザパタ役に立って無いよ。 そろって馬鹿だな。 デザパタとか別にしても。
270 名前:259 mailto:sage [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.インスタンスの数を変えることができる。(詳細略:インスタンス数を2つ以上に変更する事も容易) 5.クラスオペレーションよりも柔軟である。(詳細略)
272 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:43:38 ] >>270 Visitorが状態を持たないとき、 それでもオマイさんは Visitorをnewしますか?
273 名前:234 mailto:sage [2005/06/25(土) 01:43:59 ] >>270 いやその、「仕様変更」に対するデフォルトの対応が「継承」である、 というほうがぼくにとっては不自然なのですが。 たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて 両者に対応しなければならない、とかいうケースであれば、継承を 使うのは理解できます。 しかし、そもそも「唯一」であったものに、「継承」を適用するケース って、そんなに多いのかな、と。普通、継承は、複数のものの差異を 選択的に無視したい場合に用いますよね。単純化のしすぎですが。
274 名前:デフォルトの名無しさん [2005/06/25(土) 01:45:29 ] つまりさ、このスレの白熱議論っつうのは、 すべからく >>264 みたいな素人の迷信暴言が発端なわけ。 くだらねぇんだよおまぃらの議論は
275 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:45:47 ] >>271 GoF本にはそんなこと書いてなかったけど 一体いつ定義されたの?
276 名前:234 mailto:sage [2005/06/25(土) 01:45:57 ] ぼくのほうが知
277 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:46:13 ] >>274 面白い議論キボン
278 名前:デフォルトの名無しさん [2005/06/25(土) 01:46:26 ] >>275 恥を知れクズが
279 名前:234 mailto:sage [2005/06/25(土) 01:46:38 ] とぎれた ぼくのほうが素人だもん とか書こうとしたのに
280 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:48:33 ] >>278 かかってこいよ厨房w
281 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:48:39 ] >>266 =>>234 おまぃは誤爆してる上、 >>234 の定義で>>243 するとNullPointerExceptionがおきるつう認識もない・・・ ・・・Singleton書いた事あるぅ?(>>262 を参照汁)
282 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:49:13 ] >>267 差分プログラミングと開放/閉鎖原則で検索。
283 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:49:47 ] >>280 は底知れない白痴厨房。GoF本手元に置かずにそんな煽りやってるとは抱腹絶倒だな。
284 名前:234 mailto:sage [2005/06/25(土) 01:50:29 ] >>281 あ、>>234 の例はただの非常に単純化した例ですので。 いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ で行うようなクラスをSingletonの変わりにして何かまずいのか? ということに過ぎません。
285 名前:デフォルトの名無しさん [2005/06/25(土) 01:51:10 ] >>271 の該当ページを読んでみたらぁ?
286 名前:234 mailto:sage [2005/06/25(土) 01:52:42 ] >>282 メイヤー先生ですか。 私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。 それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない 限り、継承してメソッドをオーバーライドするより元のメソッドそのものを 書き換えることのほうが容易であることも多い気がします。
287 名前:234 mailto:sage [2005/06/25(土) 01:53:59 ] 実際、バージョンアップの際に常に継承で対応するという開発手法は どれぐらい一般的なんでしょうか? もとのクラスを書き換えるのは、邪悪? open/close原則を厳密に適用すれば、そういうことになってしまいますね。
288 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 01:54:51 ] で? 好きにすりゃえーやん。 漏れは藻舞を説得するつもりはねぇ〜し
289 名前:259 mailto:sage [2005/06/25(土) 01:55:54 BE:189645293- ] >>234 はSingletonにこだわらないほうがいいと思われ。 もうこれは個人個人の開発スタイルなので。 それでも共同開発時はSingletonをお勧めしたい。
290 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:00:01 ] >>287 アンチの俺から言わせると、 一般的なわけねーだろ。 あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。 アホだアホ。マジで救いようがねー。
291 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:03:49 ] 哀れなもんだ 煽れる時に煽るだけで、 中身は空っぽだもんな、おまえ
292 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:04:28 ] >>268 仮想コンストラクタはファクトリとシングルトンの合わせ技だから ニーズは普通にあると思うよ。 オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ?
293 名前:234 mailto:sage [2005/06/25(土) 02:04:40 ] ぼくは、あおりじゃないんだもん(; ;)
294 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:05:42 ] >>291 オマエモナーw
295 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:06:35 ] >>284 1つのクラスが複数のstaticメンバ変数を管理するのはいくない。
296 名前:234 mailto:sage [2005/06/25(土) 02:07:54 ] >>292 ニーズは、あるでしょうね。 ぼくは、実はSingletonでなくていいのに 「いまどきSingletonじゃないと、女のコにモテないぞ」 「グローバル変数はダサ!Bjarne stroustrupが何と言おうと絞め殺せ」 「static記憶クラス?そんなん、石器時代の遺物でしょ?」 とかそんな理由でSingletonにされているケースも、結構おおいんじゃないの? と、そういいたかっただけです。
297 名前:234 mailto:sage [2005/06/25(土) 02:08:21 ] >>295 それは、なぜでしょうか。
298 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:08:44 ] >>291 文体と主張だけで彼は特定できる。 だから、スルーして淡々と進めてるだろ?お前さんもスルーするよろし。
299 名前:デフォルトの名無しさん [2005/06/25(土) 02:10:45 ] デザパタ信者は巣に帰れよ。 pc8.2ch.net/test/read.cgi/tech/1119158274/l50 ここでデザパタを使う前提の話をするな。 ここはデザパタの存在の可否を決めるスレだ。 #大体、デザパタなんて誰も使ってないんだから過疎スレで #まとまってろってのw #アンチをこっちに隔離したとかほざいてたくせにアンチ追い出したら #ただの過疎スレになってやんのwバーカw
300 名前:デフォルトの名無しさん [2005/06/25(土) 02:11:45 ] >>298 ここじゃ荒らしはお前の方なのw わかったらさっさと過疎スレ帰れよw
301 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:12:20 ] >>297 クラスの役割が訳わかんなくなるから。
302 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:13:14 ] >>299-300 哀れな奴
303 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:13:38 ] >>302 ヒント:スルー
304 名前:デフォルトの名無しさん [2005/06/25(土) 02:14:54 ] >>302-303 本気で帰ってよ。 デザパタ語るなら向こうが本スレだからw
305 名前:234 mailto:sage [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 だいたい、何、頭に血上らせて必死におばかな議論してんだ、厨房。 グローバル変数を1つも使わないプログラムとかみたことないのか? 使ってる時点でレベル低すぎだってのにいらいらすんだよ。 お前みたいな馬鹿みてると。
308 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:18:25 ] >>296 の発言で、もう>>234 はネタ決定だな。 わざわざSingletonが当てはまらない想定を持ち出して煽ってるんだから、 別にSingleton勧めるいわれはないじゃん。 >>234 もそろそろ初心者プログラミング相談室にでも相談してみたらどう?
309 名前:234 mailto:sage [2005/06/25(土) 02:19:24 ] >>295 さんの主張で一番よく分からないのは、 「1コのstaticメンバならOKだが、複数だとNGになる」 という理由です。 そこのところをもう少し分かりやすく説明していただけませんか。 寡聞にして聞いたことの無い主張なものですから。
310 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:19:33 ] >>307 も変な奴だな。 Singletonはグローバル変数の代わりをスコープに入れている。 つか、Javaじゃグローバル変数なんてないし。
311 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:19:46 ] >>305 そういうことすると、そのクラスが何してるか(何を管理しているクラスなのか)、 後から見た人はわかんないでしょ。コード追っていかないと。 だからクラスの役割ははっきりさせる必要がある。
312 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:19:53 ] >>287 利点もあるし、難点もあるな>継承 Javaなんかだと、最近は継承よりも委譲とインターフェイスを 優先する風潮がある。 ソースの書き換えは、規模が大きくなると変更が他の部分に 影響を与えてドタドタドタっとドミノ倒しになる事がある。 それじゃあ継承ならそうならないかって言うと、まぁそうとも言 い切れんわけだが・・・・・・ まっ、それでinterfaceを多用する風潮が生まれたんだろう。 これならインターフェイスのみを残して新しく書き起こす場合 でも、継承を利用する場合でも、変更部分を局所化できる。
313 名前:234 mailto:sage [2005/06/25(土) 02:20:50 ] >>308 いやその、パラメタライズされていないgetInstance()を使う Singletonの例は多いと思うのですが。 パラメタライズされている場合については、了解しました と言っておきましょう。
314 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:21:03 ] >>312 >Javaなんかだと、最近は継承よりも委譲とインターフェイスを >優先する風潮がある。 Java「なんかだと最近」?はぁ? 最初っからそうだよ厨房
315 名前:デフォルトの名無しさん [2005/06/25(土) 02:21:24 ] >>310 はぁ?デザパタ信者ってのは、 グローバル変数の何がまずいのか知らないのか? アホだな。レベルが低すぎる。 もうちょっと勉強してきてくださいよw
316 名前:234 mailto:sage [2005/06/25(土) 02:22:28 ] >>311 >>309 に答えていただけませんか。やはりよくわからないんですが。 なぜstatic変数が吹く数字なると 「後から見た人はわかんない」ようになるのか。
317 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:23:05 ] 語尾ダブリューの人、なんか話題がtoo oldで哀れ
318 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:24:00 ] >>316 俺も聞いておきたい。つか、ネタかローカルルールだと思っている。
319 名前:デフォルトの名無しさん [2005/06/25(土) 02:24:11 ] >>311 が逃げてるのがよくわかるなw ほら、本スレに逃げ込めよw
320 名前:234 mailto:sage [2005/06/25(土) 02:24:23 ] >>312 ぼくがinterfaceに対するプログラミングの一番の恩恵を認識したのは 実はC++のリンク互換性なんですがね。 COMの発想のベースはそこにあります。大変汚いものですが。
321 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:25:20 ] なんかかなりネタ臭いスレになってきたな。
322 名前:デフォルトの名無しさん [2005/06/25(土) 02:26:15 ] >>321 お前は速く>>309 の質問に答えてやれよw
323 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:26:57 ] >>311 , >>316 実は、Singletonってインスタンスが2つ以上あってもいいんだよね。 つか2つ以上生成した時点で、狭義のSingletonとは見なされない傾向があるが。 例えば某所で話題になっていたInstance PoolとかConnection Poolみたいなパターンになっちまう。
324 名前:デフォルトの名無しさん [2005/06/25(土) 02:27:55 ] >>323 だからどうしたんだよ。余計なレスつけんなアホ。
325 名前:234 mailto:sage [2005/06/25(土) 02:28:33 ] >>323 Poolのようなものならば、PoolManagerが欲しい気がしますね。Singletonの。
326 名前:デフォルトの名無しさん [2005/06/25(土) 02:31:24 ] >>325 お。冴えてるやん。 すると、ダンマリ決め込んでる>>311 が回答すべき内容が見えてくる・・・はず・・・なんだが・・・なんともはや
327 名前:デフォルトの名無しさん mailto:sage [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 つか、マジで本スレ帰れってw
331 名前:デフォルトの名無しさん [2005/06/25(土) 02:34:50 ] >>329 お れ の せ い に な る の は な に か ち が う き が す る ! (笑)
332 名前:234 mailto:sage [2005/06/25(土) 02:40:17 ] >>327 ただの好き嫌いの問題であれば、ぼくの>>296 の主張はあながち ウソでもなかったようですね。 ちなみにそれによっていちいちgetInstance()を書かなければならないことを あなたは面倒であると考えたことはないのでしょうか?
333 名前:259 mailto:sage [2005/06/25(土) 02:41:23 BE:189645293- ] >>329 何に対する回答だ??回答以前に問題が明確でないんだよ。論点あちこち行ってるじゃん。
334 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:42:40 ] こっちの方が盛り上がってるのがウケル。 こっちをデザパタスレにしようよ。
335 名前:寝ぼけまなこでレス mailto:sage 今日のおネグは赤 [2005/06/25(土) 02:44:06 ] >>333 >>311
336 名前:寝ぼけまなこでレス mailto:sage しかもシースルー [2005/06/25(土) 02:45:15 ] >>334 偽デザパタスレ
337 名前:寝ぼけまなこでレス mailto:sage だってあついんだもん [2005/06/25(土) 02:49:49 ]
338 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:51:09 ] 厨房の行動パターン ・メール欄に文章
339 名前:259 mailto:女なのか、そうなのか!? sage [2005/06/25(土) 02:51:15 BE:224765748- ] >>335 static管理したらクラスの役目がわかりにくくなるって? インターフェースが同じなら変わらないだろ。論点にもなりゃしないさ。
340 名前: mailto:sage あ、instanceできちゃう・・・ [2005/06/25(土) 02:52:01 ]
341 名前:259 mailto:338はどうしてこうも野暮なんだ sage [2005/06/25(土) 02:53:01 BE:189645293- ] ム板にもIDキボンヌ
342 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:53:21 ] >>339 >>323 , >>325-326
343 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:54:48 ] >341 お前そんなんだからいつまでたっても0ポイントなんだよ。
344 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:55:58 ] で、アンチの反証は?
345 名前:334 mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 02:58:56 ] >>345 GJ.
347 名前:デフォルトの名無しさん [2005/06/25(土) 03:00:55 ] >>334 だからデザパタスレなんて本来はその存在の可否に関する 議論の方がもりあがってたんだってば。 デザパタ自体はシングルトン1つとっても意見はバラバラ。 コミュニケーションツールなんて夢のまた夢。 掲示板じゃ自由に言えるけど、会社じゃ適用に至る明確な理由が必要になる。 そこでデザパタが必要である理由なんて説明できる奴がいるわけが無い。 昔からずっとこんな調子なんだよ。 信者とアンチの聖戦が一番盛り上がるんだから叩きだしたって誰かが追撃してくるんだよ。 構図はいつも 「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」VS「オブジェクト指向原理主義者」
348 名前:259 mailto:343はポイントよこせ sage [2005/06/25(土) 03:00:55 BE:568936499- ] >>342 Poolはわからんが、 インターフェースとドキュメント見りゃ動作が分かるってのが、あるべきクラス設計の姿だろ、 実装に複数のstatic変数使ったからって、それが崩れることがあるのか?
349 名前:259 mailto:sage [2005/06/25(土) 03:03:10 BE:126431036- ] >>347 >オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿 アンチデザパタ派は何故いつもそう言う。 たとえば>>345 がオブジェクト指向を理解できていないように見えるのか? オブジェクト指向を理解しないとデザパタ理解できないぜ。
350 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:04:55 ] >>347 頭悪い議論で盛り上がるのはもう沢山。 だから隔離されてるんだよおまぃは
351 名前:234 mailto:sage [2005/06/25(土) 03:06:06 ] >>345 ああなるほど、そういう用例を考えると便利ですね。 でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。 普通のオブジェクトよりその点がちょっとダーティ。でも逃げ道は在るよ、 というところでしょうか。 >>347 > 構図はいつも > 「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」 > VS「オブジェクト指向原理主義者」 ぼくはどっちでもないとおもいます。
352 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:07:27 ] 構図はいつも、「自作自演するアンチ」vs「自作自演するアンチアンチ」
353 名前:234 mailto:sage [2005/06/25(土) 03:07:55 ] そろそろ イマドキDIだからSingletonなんかつかわないぜ(プ とか誰か言うのかと思ってたらそうでもなかったですね
354 名前:234 mailto:sage [2005/06/25(土) 03:08:24 ] >>352 ぼくは自作自演なんかしてないもん(; ;)
355 名前:デフォルトの名無しさん [2005/06/25(土) 03:08:50 ] 基本的に意味不明。 説明汁。
356 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:09:47 ] なんだServiceLocatorの話か。
357 名前:259 mailto:sage [2005/06/25(土) 03:10:11 BE:393338887- ] >>351 待て待て、>>273 で継承を否定しておきながら、それはないだろ。 >>345 は継承なくては実現し得ないんだぞ。
358 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:11:41 ] どーでもいいですよ。 >>273 と>>351 で同じ仮定をしなければならない義理があるわけでもなし。 つか、同じ仮定をしつこく主張しつづけたら、議論は進まない。
360 名前:259 mailto:sage [2005/06/25(土) 03:13:02 BE:252860494- ] >>345 は継承による仕様変更の典型例だってことを言ってるのよ。 仕様変更に継承を用いることを肯定するなら、この問題は終結するはずなのだが。
361 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:13:10 ] >>358 >>271
362 名前:234 mailto:sage [2005/06/25(土) 03:13:46 ] >>357 ぼくはべつに継承を常に否定してるわけじゃないんですが。 不要な継承を否定してるだけです。 >>345 は、インタフェースを合わせるために必要な継承を巧みに使っている 例ですね。 まあ、実際にこういうtechniqueが実際にどれだけ必要になるかといえば、 疑問ですが。
363 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:13:49 ] >>360 じゃ終結って事で。
364 名前:デフォルトの名無しさん [2005/06/25(土) 03:13:56 ] >>349 少なくともお前は理解していないw オブジェクト指向云々に関する話題は>>345 には出ていない。 したがってお前はまぬけだ。 >オブジェクト指向を理解しないとデザパタ理解できないぜ。 これはまったくの嘘。 デザパタはオブジェクト指向なんてまったく知らない奴が作った物。 よっぽどのアホでもなきゃ騙されないけどねw 現にここにいる奴のほとんどが学生だろ? 言語は覚えたけど、プログラムが組めないってレベルの奴。 まあ、プログラマでもないのにいきなり現場にぶち込まれた奴が たくさんいるからこのレベルの奴だと色々模索するから 学校のお勉強に近いデザパタに妄信する奴がでてくるんだよね。 だけど、いくら勉強してもプログラムなんて組めるようにはならない。 図星だろ? くくくっ、プログラムの組み方が書いてある本が世にあるとよかったなぁw
365 名前:334 mailto:sage [2005/06/25(土) 03:14:07 ] >>347 あれ?アンチの人?おまいよく状況を知ってるなwwww そうなんだよ昔から相手を馬鹿にするだけで、ろくな議論しないんだよあのスレwww だからここを有益なところにしようw >デザパタ自体はシングルトン1つとっても意見はバラバラ。 >コミュニケーションツールなんて夢のまた夢。 コミュニケーションツールは確かに無理だねぇ。 書籍にしても著者によって捉え方が全然違う。 読んだ書籍によって、読み手も捉え方が異なってしまうし。 うーん、まあコーディングテクニック集ってとこなのかなぁ。
366 名前:デフォルトの名無しさん [2005/06/25(土) 03:14:58 ] なんだ、NGワードが増えてきたな。 携帯4っつ使ってレス付けてるのか(笑
367 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:16:18 ] □■□■□ 祝!秀ケツ ■□■□■
368 名前:234 mailto:sage [2005/06/25(土) 03:16:22 ] ああ、なるほど >>259 さんには、あのアダプタの適用も「仕様変更に際して用いられる 典型的なtechnique」なのか。 その辺が僕とは認識が違いますね。 まあ、仕様変更といっても色々ありますから、なんとも言えませんが、 Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを 噛ませることがベストな解である、というタイプの仕様変更って そんなに無い気がしますよ?
369 名前:259 mailto:sage [2005/06/25(土) 03:16:29 BE:112383528- ] 結局 >>234 は >>234 の質問から何を知りたかったわけ?
370 名前:デフォルトの名無しさん [2005/06/25(土) 03:17:13 ] いままでどおり、机に向かって勉強してればプログラムが組めるようになるとでも思ったか?学生諸君w ならないだろ?ざまーみろw死ぬまでくるしめw
371 名前:234 mailto:sage [2005/06/25(土) 03:17:53 ] >>369 まあ、こんだけスレも盛り上がってることですし、いいじゃないですか(w
372 名前:334 mailto:sage [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 mailto:sage [2005/06/25(土) 03:22:05 BE:393338887- ] >>368 >Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを >噛ませることがベストな解である、というタイプの仕様変更って >そんなに無い気がしますよ? ベタベタだがたとえばウィジットを生成する Factory。プラットフォームによって切り替え。 そんなにワサワサと例は出せないが。 逆に仕様変更のない Singleton は Singleton である必要がない気がする。 それこそ Utility 的な。 >>371 まぁそうだなw
375 名前:デフォルトの名無しさん [2005/06/25(土) 03:22:10 ] 正直、アンチの俺の意見としても継承の悪用は止めたほうがいいといっておく。
376 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 03:26:32 ] そもそもUtilityクラスとは、オブジェクト指向設計の放棄である (とりあえずそこまでクラス化するゆとりがないとか含む) である事を指摘しておこう。
377 名前:259 mailto:sage [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 mailto:sage [2005/06/25(土) 03:39:14 ] >>377 「全ての問題は間接参照をはさめば解決する」という Andrew Koenigの言葉を思い出すような例ですね(w
379 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 05:35:21 ] ・グローバル変数はダメ ・Singletonはダメ ・デザパタなんか誰も使っていない、普及していない とほざく奴はJavadWebアプリの業務をやったことないだけだろ。 Javaではグローバル変数なんて概念はないし Singletonはリクエストのたびにオブジェクト生成されるのを 防ぐために普通に使われるし(Factoryにすることも多い) デザパタは使わないとスパゲッティ化してどうにもならなくなる ってぐらいに当たり前のように使われている。 自分の知っている狭い世界だけで使ってないからって断言するな。クズ。
380 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 07:56:46 ] そもそもそんなそうちょうに、 なにあたりまえのことりきせつしてるの? このすれは、 ていどのひくいひとがひっしにかんがえた どうしようもなくていどのひくいねたを かくりするすれだよ(わらい
381 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 07:57:55 ] そもそもそんなそうちょうに、 なにあたりまえのことりきせつしてるの? このすれは、 ていどのひくいひとがひっしにかんがえた どうしようもなくていどのひくいねたを かくりするすれだよ(わらい
382 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 13:31:42 ] なんでデザパタの由来も知らないような奴が、 「デザパタ肯定≠オブジェクト指向」 なんて言う脳内仮定で煽ってんの? オブ戦スレの馬鹿がTMPこそデザパタとか 勘違いして、逆の立場で煽ってるの?
383 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 13:53:14 ] >>382 つか、「デザパタ自体、OOではない」らしいよ。奴にとって。
384 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 15:48:50 ] >>382 じゃあ、君がデザパタがオブジェクト指向にのっとっていることを証明したまえ。 ちなみに前スレだとデザパタはオブジェクト指向とは違う流れで それは新しい進化ということで決着がついていた。
385 名前:383じゃないが mailto:sage [2005/06/25(土) 15:52:27 ] >>384 なんとなく悪魔の証明っぽいな OO 使わずとも組めるパターンもあるだろうに
386 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 16:10:07 ] いままでのデザパタ否定派の主張は オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、 オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。 この主張の矛盾点を指摘する形では肯定派も否定派も 両者を納得させるまでにはいかず、煽りを繰り返すレスがついた。 はじめの主張が 「デザパタはオブジェクト指向では無い」 というところからはじまっているだけあって、アンチが主導権を握ってしまうのは仕方がないと思う。
387 名前:俺は肯定派? mailto:sage [2005/06/25(土) 16:25:56 ] > いままでのデザパタ否定派の主張は > オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として > デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、 このあたりは既に俺の考えとは違っていて、 > オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。 これは当たり前だと思っている
388 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 16:56:54 ] >>384 >それは新しい進化ということで決着がついていた。 >それは新しい進化ということで決着がついていた。 >それは新しい進化ということで決着がついていた。 >それは新しい進化ということで決着がついていた。
389 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 17:44:18 ] やっぱりデザパタは僕の嫌いなオブジェクト指向じゃなかったんだ! って思って欲しいのですか? でオセロのソースでも晒すつもりですか? おまいらは本当に進歩がないですね。
390 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 19:59:08 ] パターンはOO以前からあるし、互いに独立した手法だ。 >>389 まあ、そーゆースレだしね。適当に盛り上げといて。
391 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 21:02:46 ] >>390 どっちかと言うとテンプレートライブラリに近い。 テンプレートライブラリ化出来ないレベルを デザインパターンで扱うべきなんだけど、 GoFのやってる事は、気持ち悪いタイプの 馬鹿プログラマみたいだ。
392 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 21:53:35 ] >>391 いくら明日予定が入って無いからって、そんなネタで暇つぶしの相手をみつようったってそうはいかない。
393 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:05:13 ] >>390 脳内妄想ステキー
394 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:06:14 ] >>392 今週のレスの付き具合を見るに、 >>391 は毎日がエブリディもとい毎日が特別休日みたいだぞw
395 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:33:30 ] でも、マジな話、GoFのパターンは使えない。 てか、もういらない。
396 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:47:52 ] 「パターン」はOOP以外にも適応できる概念だが、 それを「パターン」としてきっちり言語化したのはGoF以降だろう。 で、GoFのパターンの源はSmalltalkやC++での経験の蓄積が 元になっていると。 今では「デザインパターン」の語がOOPの領域以外にも 広げられてたとえば「モナド」は高階関数のデザパタの 一つ、と言ったりするわけだな。 だが、ここの厨がいってるような、デザパタはテンプレートで オブジェクト指向とは関係ない、とかってのは、激しく 思い違いもいいところだ。 前橋、わかったのか?
397 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:48:05 ] >>394 毎日が出社とかも考えろ!! ボケ、糞、カス、キチガイ、狂信者。
398 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:49:43 ] >>396 関係ないけどオブジェクト指向でも使えるのがデザインパターンなんで、 オブジェクト指向と関係ないちゅーのも、正しい物の見方だよ。
399 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:51:23 ] >>398 「パターン」としてきっちり言語化したのはGoF以降。 歴史は覆せないよ。
400 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 22:55:30 ] >>399 はぁ? だからなんだってんだよ、GoFがオブジェクト指向的要素として デザパタを提唱したんなら、オブジェクト指向の一部か否かてな 議論もなりたつが、C言語のデザインパターンだって成り立つんだから、 オブジェクト指向とは関係ないね。 で、GoFが出したカタログは、オブジェクト指向を破壊するデザインパターン が多すぎるから誤解招いてるんだろ。糞。
401 名前:デフォルトの名無しさん [2005/06/25(土) 23:01:25 ] >>400 >オブジェクト指向を破壊するデザインパターン 相変わらず具体性ないねw
402 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:02:26 ] これだから厨はいやなんだよ。関係ないも何も デザインパターンが意識され始めたのは、 オブジェクト指向による設計に関する経験から 来ているのは事実なんだから。 そこで「デザインパターン」という、 「ライブラリ」なんかとは抽象レベルの違う概念が 意識されてきたわけで、あとから考えれば、 コレもアレもパターンてのは当然ある。 結局おまいらのいってるのは「CでもOOPできるYO」 ってのと同じく「Cでもデザパタできるよ」って言って るだけで、吠えてみたところで、オブジェクト指向に とってデザパタが重要なことに変わりはない。
403 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:03:31 ] わかったのか、前橋。
404 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:04:19 ] ================================================================= 暑さのためおかしくなった不審人物がが大喜びではしゃいでます。 一般の方は刺されないように退避して下さい。 (隣組回覧) =================================================================
405 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:08:51 ] 前橋ってデザインパターンに否定的な見解なの?
406 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:09:29 ] 無職5年とか不審人物とまで蔑まれてるのに、 それでも構ってもらえたと勘違いして、 大喜びで自作自演レスしまくるとは、相当なもんだよな。 きっと、人との交流に激しい飢餓感を持ってるのだろうな。 もまいさぁ、いい加減、額に汗して働けよ。 俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ
407 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:21:34 ] >>402 1994年に標準化されたSTLが有るのに、 95年に書かれたデザインパターンをもって、 新しいってのはちょっと違うなぁと思うぞ。
408 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:45:04 ] >>407 はぁ〜。GoF程度は読んどけよ。まったく。 あれのパターンの元ネタはSmalltalk-80やMacAppやその他。 この期に及んでSTL持ち出すのも馬鹿丸出し。
409 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:50:32 ] >>406 >>俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ どうやら >>406 にとって「働いている・働いていない」の基準とは、 室内のエアコンが「利いている・利いていない」って所らしいな。
410 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 23:56:42 ] いくらデザパタがオブジェクト指向からできたって、#あの糞設計をみるとそれも怪しいが・・・w デザパタでの設計がオブジェクト指向にのっとっているかは別問題。 やっぱりオブジェクト指向とは考え方が違う。 オブジェクト指向で似通った設計を集めてそれをパターンにして当てはめたって それはオブジェクト指向での設計にはならない。
411 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 00:20:29 ] | Hit!! | | ぱくっ| /V\ /◎;;;,;,,,,ヽそんなエサで _ ム::::(,,゚Д゚)::| 俺様が釣られると思ってんのか!! ヽツ.(ノ:::::::::.:::::.:..|) ヾソ:::::::::::::::::.:ノ ` ー U'"U'
412 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:02:48 ] >>410 オブジェクトであるパーツを再利用するとオブジェクト指向じゃねえって意味わかんないんですけど。 で、デザパタのどこがクソ設計なのか具体的に挙げてもらえますか?そしてそれはどう設計されるべきですか?
413 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:08:07 ] >>400 >C言語のデザインパターンだって成り立つんだから、オブジェクト指向とは関係ないね。 へぇ、オブジェクト指向って言語依存なんだ。てっきり設計の指針みたいなもんだと思ってたが。 プログラムできない人の考えることはオリジナリティがあっていいねw
414 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:24:06 ] >>412 それは実装の話。 設計段階でオブジェクト指向では対象物をそのままソースに移すことが重要。 その結果、同じクラスが出てきたら、再利用できるできないを検討すればいい。 パターンに当てはめてしまうデザパタとはやはり違う。
415 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:38:54 ] デザパタ=パターンに当てはめて設計する という前提が異常。
416 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:40:25 ] >>415 じゃあ、パターンっていつ使うんだよw
417 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 03:58:57 ] >>414 煽りじゃなくってこれはいっとかなきゃいけないと思うので書くが、キミ全く判ってないよ。 デザパタで語られるパターンてのはジェネリックかつプリミティブ。 STLで言ったら、vectorとかlistみたいなもんだ。 「クラスのメンバーにvectorがあったらオブジェクト指向じゃない」なんて命題は有り得ないわけよ。 vectorはプリミティブなテンプレートクラスであって、これによって設計がOOPかどうかを判断するなんて全くナンセンス。 まず、GoF本くらい読んで「理解して」から書き込みしなよ。
418 名前:デフォルトの名無しさん [2005/06/26(日) 04:23:16 ] >>417 なんでそこで実装の話がでちゃうのか理解不能。 余計わからない。 少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も パターンに当てはめる形で設計をしている。 これは「〜パターンが使えそうですね。」的な発言も見られることから明らか。 わけのわからないことを言わないでもらいたい。
419 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 04:24:58 ] レスに困ったら「それは実装の話」と言っちゃえばいいわけか。参考にしよう。
420 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 04:29:23 ] >>419 ハイハイ、そこは重要な箇所じゃないでしょ? くだらない煽り入れないでね。 ちゃんと↓に答えてね 少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も パターンに当てはめる形で設計をしている。 これは「〜パターンが使えそうですね。」的な発言も見られることから明らか。 わけのわからないことを言わないでもらいたい。
421 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 05:03:04 ] もっと使いやすいパターンが普及すれば良い っていう話?
422 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 05:31:37 ] >>420 じゃ、君は以前に自分が使った設計の方法を思い出して 「あ、ここはあのやり方が使えるな」と思うことはないのか? そう思った時点でそれはオブジェクト指向ではないのか? ばっかじゃねえの。
423 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 05:39:20 ] >>417 C言語でシングルトンパターンをどうやって利用しようか? コンストラクターを隠蔽するから、一意性が保たれる? プッって感じ。 では、オブジェクト指向的に考えてみようか? インスタンスの生成を隠蔽すると安全なシステムになる? プッて感じ。 GoF煎ってよし。
424 名前:デフォルトの名無しさん [2005/06/26(日) 06:10:47 ] GoF本知る前からTemplateMethodとかCompositeパターンは使ってたなぁ(というかそうなってた)。 あれって継承とか多態とかオブジェクト指向独特のテクニックを駆使してるし、 そういう意味でデザパタがオブジェクト指向の文脈で語られるのは当然かなぁ。 GoFのパターンが糞というのはそれぞれのスタンスとしてはいいと思うけど、 それがオブジェクト指向から外れてるってのはちょっと的外れかなぁ。 あ、もしかして継承も多態も認めない、原理主義的オブジェクト指向信者だっていうなら納得w でも、それだって単にオブジェクト指向に対するスタンスの違いってだけの話しだよねぇ・・・
425 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 10:31:43 ] × 継承も多態も認めない、原理主義的オブジェクト指向信者 ○ 継承も多態も解らない、抽象的に物事が考えられないバカ
426 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 12:32:45 ] >>428 そりゃオブジェクト指向言語の機能じゃね?w はなしにならねー さすがにお前みたいな肯定派はいなかったぞw
430 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 12:33:52 ] >>420 ちゃんと答えるも何も、なにを答えたらいいのかわからない。 「パターンを当てはめる形で設計している。」に対して 「はい」または「いいえ」と答えればよいということかな? その答えが知りたい意図がわからない。
431 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 12:35:26 ] >>430 それでいいよ。
432 名前:430 mailto:sage [2005/06/26(日) 12:36:54 ] >>420 それでいつも>>419 のようにある程度、具体的な話にもっていってるのに、 >>420 はいつも宙ぶらりなレスを返すからこちらとしても議論ができない。
433 名前:430 mailto:sage [2005/06/26(日) 12:38:12 ] >>431 ああ、そうなの。 つまり、君が結論を出したかったことは 「パターンを当てはめる形で設計している。」に対して 「はい」って答えさせたかったってだけなのね。 それ以外の議論はしたくないと。
434 名前:デフォルトの名無しさん [2005/06/26(日) 12:39:15 ] >>429 デザインの話だから言語とは独立したお話。 という建前だけど、実際には言語の使用に引っ張られることも多いやねぇ・・・
435 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 12:42:01 ] GoFは言語から独立だろ。
436 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:03:11 ] >>429 オブジェクト指向自体にはカプセル化や多態性の概念って無かったんだっけか? むか〜しに www.amazon.co.jp/exec/obidos/ASIN/4881356194/ でオブジェクト指向勉強したんだが、これにはそんな風に書いては無かったと 思う(もはや手元に無いので未確認。間違ってたらごめん)。
437 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:07:24 ] >>417 のどこが実装の話なのかよくわからない っていうかアンチにとってどこからが実装の話なのかもよくわからない
438 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:08:59 ] 多態がなけりゃオブジェクト指向なんて役にたたねぇ
439 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:24:27 ] ここのオブジェクト指向信者は、 カプセル化や多態性も分からずにオブジェクト指向を語っていたのか... それこそ話にならん
440 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:26:57 ] >>439 そりゃ実装技術だろ。 オブジェクト指向での設計の話をしているだろ。
441 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:30:07 ] >>440 え?ポリモーフィズム意識せずに設計やってんの?マジで?
442 名前:デフォルトの名無しさん [2005/06/26(日) 13:30:10 ] >>440 おいおい、実装だけの話ではないよw 適当に検索してみればいくらでも出てくると思うがなぁ・・・
443 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:30:47 ] >>440 継承やカプセル化や多態性を考慮しながらクラス図を描いたりしないのか?
444 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:34:59 ] >>441 やってるよ。マジで。 その辺って後からできた技術でしょ? 純正のオブジェクト指向信者の俺はそんな無駄なことはしない。 カプセル化なんて意識しなくても普通になるが、 継承や多態性なんて狙って設計なんかすると糞設計まっしぐらだぞ。
445 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:38:20 ] >>441 > その辺って後からできた技術でしょ? 情報源を希望
446 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:38:28 ] 多態を考慮しない設計なんてオブジェクト指向じゃないよ・・・
447 名前:445 mailto:sage [2005/06/26(日) 13:39:20 ] ×>>441 ○>>444 スマン orz
448 名前:デフォルトの名無しさん [2005/06/26(日) 13:39:43 ] 後からできたどころか、多態なんかはオブジェクト指向の本質だなんだけどね
449 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:40:27 ] >>446 なんで? 多態性や継承なんてバグの温床だと思うけど?
450 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:41:48 ] >>449 > 多態性や継承なんてバグの温床だと思うけど なんでそう思ったんだい?
451 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:41:58 ] >>448 本質じゃないよ。 本質は対象物の構造をそのままソースに映すことだよ。 多態性なんて付属品じゃないか。
452 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:43:29 ] >>450 自分の主張を入れて無いレスにレスは返さないよ。 自分はどう思うけど〜って形にしてくれない?
453 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:45:16 ] 対象物の構造をそのままなんていってるが 純粋架空物のクラスは作らないのかよ
454 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:46:10 ] オブジェクト指向に多態性が必要ないっていう意見は初めて聞いたな
455 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:48:40 ] >>454 なぜそっちを相手にしてるのか? が疑問だ。
456 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:48:44 ] >>454 心に刻んでおきたまへw
457 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:52:16 ] >>450 多分、>>449 はC++プログラマーで基底クラスのデストラクタをvirtualにし忘れたとか、 そういう低レベルのことをいっているんジャマイカ?
458 名前:デフォルトの名無しさん [2005/06/26(日) 13:55:43 ] 多態を否定すると、Javaのライブラリが何も使えなくなってしまうなw
459 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:57:15 ] おい、34℃超えたってよ。
460 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:01:03 ] >>458 アンチの彼はC++しか使ったこと無いみたいだから、いいんじゃネーノ
461 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:01:17 ] >>458 boostもC++の標準ライブラリも使えないっす。つらすぎる。
462 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:01:23 ] >>457 そのレベルなの? 基底クラスをバーチャルにするしないは、場合よるか、 統一事項の世界かと?
463 名前:デフォルトの名無しさん [2005/06/26(日) 14:02:49 ] >>441 設計、分析、実装の違いがわからん厨は糞して寝ろw
464 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:07:05 ] >>461 MFCも使えないな。 # まぁ、別の意味でMFCは使えないライブラリだし、いいのか?
465 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:08:28 ] C++ライブラリはまず全滅。 Cの時代に逆戻り。
466 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:24:27 ] なんだ、この程度のを相手にしていたのか。 キミにはなっかりだよ。
467 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:24:36 BE:56191542- ] (´ー`)早くID導入されてほしいな
468 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:32:50 ] 継承とポリモーフィズム使わないんならそれはオブジェクト指向じゃなくて モジュール指向だとか抽象データ型の世界だろ 別に後者が悪いという訳じゃないが、オブジェクト指向を後者から決定的に 峻別するものが継承とポリモーフィズム。
469 名前:デフォルトの名無しさん [2005/06/26(日) 16:30:54 ] >>468 なんどもいうけど オブジェクト指向ってのは 対象物の構造をソースに反映させることだよ。 継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。 だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ? 結局、設計が腐ってたら継承だって多態性だって全く意味が無いよ。
470 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:40:31 ] >>469 ポリモーフィズムの意味を理解した上での発言だよね?
471 名前:デフォルトの名無しさん [2005/06/26(日) 16:41:52 ] >>470 そのつもり。 まず、正しい分析、正しい設計ありき。 継承や多態性なんて出てくるのはあとのあと。
472 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:47:56 ] >>471 設計終わってから新しくクラス派生させるの? 設計終わってから派生させちゃいけないっていってるわけじゃないよ。 でも実装時にクラス派生させることを前提にした設計って...
473 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:52:03 ] >>449 使いこなせない事の言い訳に「バグの温床」というのは よく聞かれる詭弁ですね。
474 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:52:10 ] 継承なんて面倒なんで、pimpl使えばいい、 どうせ関数呼出しに関しては継承とたいして変わらん、 動的な切替えもできるし。
475 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:59:10 ] >>474 pimplイディオムは良くってデザインパターンはダメってのが良く分からん。 pimplではなく委譲といえばまだ分かるんだが・・・
476 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:03:36 ] >>472 そんなウォーターフォールな脳みそでこの先どうするつもりだw
477 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:07:58 ] >>476 いや、設計は設計、実装は実装みたいな言いかたする割には、 実装に強く依存した設計するんだなって思ってさ。
478 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:25:47 ] >>474 継承を使用しないでどうやって多態性を導入するの?
479 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:27:16 ] Javaだったらインターフェースがあるけどさ
480 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:33:16 ] >>469 またお前か
481 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 17:42:45 ] >>477 てゆうか、設計が崩れたら実装はやり直しでしょ。
482 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:08:11 ] 設計が終わってから、新規にクラスを導入するってのはあり得ない事ではないんだけど、 設計終わってから継承、そしてポリモーフィズムを取り入れるってことは 新しくクラスを導入することが確定事項としてあるわけで、 それって設計が終わってないって事じゃないのか?
483 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:12:40 ] HumanクラスがFactoryで生成されるのはオブジェクト指向的におかしい! 先ずはFatherクラスとMotherクラスを作るべきだ! ⊂⌒~⊃。Д。)⊃ どうでもいいですよ〜
484 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:20:55 ] >>482 は>>469 への問題提起ね
485 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:22:46 ] >>469 >対象物の構造をソースに反映させることだよ。 この時点で大きな間違いを犯していることに気付いてくれ OTL >継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。 んで、この行は前行と合わせるとえらく矛盾している事にも気付いてくれ OTL
486 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:23:37 ] >>482 ウォーターフォールしか頭にないのか? 分析→設計→実装→分析→設計→実装→設計→実装→分析→設計→実装・・・ ってやっても別にいいんだぞ。
487 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:24:02 ] >>483 ヒント:クローン
488 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:25:10 ] >>485 ちゃんどどこがどうまちがっているまで書いてくれなきゃレスはつけないのでよろしく。 ちゃんと自分の主張を相手に伝えることぐらいはできなくちゃ駄目だよ。 プログラムがどんなに組めたってそれじゃいっしょに仕事ができない。
489 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:31:19 ] >ちゃんと自分の主張を相手に伝えることぐらいはできなくちゃ駄目だよ。 主張するだけで具体性を伴ってないから、全く相手に伝わってない奴もいるな
490 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:31:32 ] >>486 いいよ。それで。 問題にしているのは>>469 が > だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ? としていること。 >>469 にとって継承のために新しくクラスを導入することは「設計をやり直す」 ことには属さない。
491 名前:485 mailto:sage [2005/06/26(日) 18:31:33 ] >>488 あ、了解。っていうか問題だけ提起して裏でごにょごにょ書いてたでス。 >対象物の構造をソースに反映させることだよ。 オブジェクト指向を使えば、同じ対象物に対し、万人が同じ構造のソースを書いてくる……筈も無い事から、 構造を反映させるのは合っているが、構造の詳細はPGに任されると思った。 ニュアンスの問題。 >継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。 継承や多様性も含めた対象の構造を考えるのが、オブジェクト指向。 そこまで構造に反映させてくれ。
492 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:33:24 ] 自分は具体的な話から逃げておいて相手には具体的な内容を要求するとはなんたる自己矛盾
493 名前:デフォルトの名無しさん mailto:sage [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って何?w
496 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:48:00 ] >>493 469と474て同一人物じゃないだろ? 同一人物だとしたら説が矛盾する。
497 名前:493 mailto:sage [2005/06/26(日) 18:50:14 ] >>495 そうか...スマン Pimplは Exceptional C++ にありますです。
498 名前:485 mailto:sage [2005/06/26(日) 18:52:25 ] >>494 >対象物の構造が間違いないぐらいきっちりわかってからの話じゃない? つまり貴方は、何時も見切り発進でやってると……言うような冗談は置いておいて ・分かっているならば構造に組み込むというのは FA ・分かった時点で構造に組み込むというのも FA だれも 『判明していない構造』 を組み込めなんて言ってないですし >継承やら多態性やらを考慮してクラスを組み変えるのは っていうか、もしかしたらと思ったんだけど、 『コーティングの技巧として、構造とは異なる継承や多様性を組み込む』 とかやってませんか? それはオブジェクト指向から微妙に外れるし、それを 「オブジェクト指向とは言わない」 と言うのはトートロジ
499 名前:485 mailto:sage [2005/06/26(日) 18:57:23 ] なんかデザパタじゃなくてオブジェクト指向の話になっているけど、 >>494 俺でも確かに、継承とかを使わないときは全く使わないんだけど、それでも時折閃くときがあるんだな そういうときには使う
500 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:57:47 ] pimplって何?ときましたかw これでコイツがC++で実務をこなした事は一度も無いって事が分かったな。 Java&J2EEに関する知識は皆無で、C++に関してはテンプレートに苦戦中 でpimplを知らないというレベル。なんとなく、どんな奴だか見えてきた。
501 名前:490 mailto:sage [2005/06/26(日) 18:57:51 ] >>494 聞きたいのは>>482 だったんだが、 >>494 を読む限り、君にとってis-aの関係のためのクラス導入は、 設計とはほぼ無関係であるとしてるね。 設計に無いクラスの導入を実装時にすることを確定事項とした設計であると理解して良いね?
502 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:59:17 ] 教えて君の奇形だろ。
503 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 18:59:33 ] >>498 あ?なんか非常にわかりにくい文章で何言ってるのかわからない。 何がいいたかったの? 書いた本人的にも微妙でしょ?>>498 の文章って。
504 名前:485 mailto:sage [2005/06/26(日) 19:00:42 ] >>503 微妙だけど?
505 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 19:05:51 ] 横レス申し訳ないんだが。 「構造」って「データ構造+論理構造」だよね?
506 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 19:07:13 ] >>505 「オブジェクト構造」
507 名前:485 mailto:sage [2005/06/26(日) 19:17:51 ] まとめた >>494 『コーティングの技巧として、想定していたオブジェクトの構造とは異なる継承や多様性を組み込む』 ことは、 たとえクラス等を使用していてもオブジェクト指向とは言えない (かもしれない)
508 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 19:20:24 ] >>507 何がききてぇんだ?w もう、てめぇの中で結論は出てるのか?w
509 名前:485 mailto:sage [2005/06/26(日) 19:22:39 ] >>508 何も聞きたくありませんわ
510 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 19:59:29 ] とデザパタに挫折した人が言っております。
514 名前:485 mailto:sage [2005/06/26(日) 20:03:16 ] デザパタに挫折したからどうなるってもんでも無いような気がしますが デザパタって、料理のレシピみたいな物なのかもね レシピを見れば、腕が良ければそこそこの料理ができる レシピをたくさん眺めていれば、新しい料理を作ってみることもできる ……レシピを見なくても、料理できる人は料理しちゃう
515 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:04:31 ] >>494 は、先に継承・多態性を否定したデザパタ否定派が、 多態性を否定するとほとんどの既存のライブラリを使用できなくなることを指摘され、 それを無理に方向修正しようとして失敗した結果だろ?
516 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:05:56 ] >>513 そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か?
517 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:07:32 ] >>516 ? 512 への間違い?
518 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:11:49 ] >>515 ×デザパタ否定派 ○デザパタ否定君
519 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:14:07 ] >>517 は天然?
520 名前:517 mailto:sage [2005/06/26(日) 20:20:29 ] >>519 >513 :デフォルトの名無しさん :2005/06/26(日) 19:59:29 > とデザパタに挫折した人が言っております。 >516 :デフォルトの名無しさん :2005/06/26(日) 20:05:56 > >>513 >そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か? ごめん。この2個のレスが全然繋がらないんだ
521 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:28:13 ] >>428 があるから継承・多態性を否定しないと、 デザパタはオブジェクト思考に従っていないからダメ というロジックが崩れてしまうし、 かといって継承・多態性を完全に否定してしまうと今度は、 ほとんど全部の既存のライブラリを使えないことになってしまうし・・・ と、考えたデザパタ否定君は>>494 をカキコしたのでしょう。
522 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:28:47 ] >>520 だろうね。
523 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:32:48 ] >オブジェクト指向の重要な概念として(1)カプセル化(2)継承(3)多態性というのがあるよね。 まあ、最も重要な概念である「振る舞い」を外してる時点でアレだけどね。
524 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:33:51 ] >>523 「振る舞い」 というか 「インターフェイスの抽象化」 の方が
525 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:41:04 ] >>524 もう一息だね。 「インターフェイスの抽象化」を「振る舞い」 と呼びたくなった時にはじめて 自分がテイクオフしたことを実感できると思うよ。頑張って!
526 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:45:39 ] >>525 ああ、多分俺が考えているのと違うわ。 「対象物のインターフェイスを抽象化する」 = 「対象物の振る舞いを定義する」
527 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:47:15 ] >>526 うん。違うね。
528 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:50:02 ] 単なる集約を抽象化などと小難しく表現するのは勘弁な。
529 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:54:56 ] 悪い。「振る舞いの定義」 の 「の定義」 って部分がさらりと出てこなかった。
530 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:55:27 ] >>526 イタタタタ
531 名前:25 ◆41ucRLNOBQ mailto:sage [2005/06/26(日) 20:56:28 ] 俺は>>508 あたりからレスしてないぞ。
532 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:57:56 ] >>531 それが何か?
533 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 20:58:37 ] >>531 何か?
534 名前:デフォルトの名無しさん mailto:妄想吐き捨てsage [2005/06/26(日) 21:14:39 ] ところで、今日考えてたんだけど、否定派の主張は 『デザパタはオブジェクト指向に従っていない、トリッキーなコードである』 ってコトらしいけど、俺は仮説として 『デザパタを適用してもオブジェクト指向に従っている例は存在するのではないか』 を考えた。否定派の主張を覆すならば、その様な具体例を示せれば良いと思う。 もし存在すれば、デザパタは反オブジェクト指向的コードを 強制する 物ではないと示せる筈だから。 んで、具体例を挙げるにあたって、 『実世界の物体において実現されている構造ならば、オブジェクト指向で考えられる。つまり、オブジェクト指向に従っている』 と考えた。 【続く】
535 名前:デフォルトの名無しさん mailto:妄想吐き捨てsage [2005/06/26(日) 21:14:51 ] 【続き】 んで、試しに Strategy が適応されている、もしくは Strategy 的な構造になっている現実世界の実例を考えてみたら ・マザーボードと CPU の関係 ・ゲームボーイとカートリッジの関係 とか、妙にたくさん出てきて困った。 これらの関係は、2つの接触部分を固定化して、片方を必要に応じて切り替えられるようになっている関係だ。 必要に応じて切り替えられる、って言うのはつまり切り替えなくても良い、って意味も含むけど。 んで、俺の仮説における具体例が示せたわけだが、果たして合っているだろうか…… ====== あと、この例ならば、以前否定派の人が 「戦術をクラスとして抜き出すのはオブジェクト指向的ではない」 って言っていたことの、簡単な反証にもなると思う。 この主張は 「戦術≠オブジェクト」 ってコトを根拠にしているけど、 「抜き出す作業」 はつまり、「戦術を内包したオブジェクトを定義する」 ことに等しいから、そもそも問題になってない。
536 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 21:25:12 ] >>534-535 >>386 がよくまとまってるから読んでからにしたほうがいいと思う。
537 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 21:29:04 ] >>536 否定派の主張が間違っているって言うこと? その主張には何通りかあったと認識してたけど……
538 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 21:34:49 ] ui
539 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:01:18 ] いい加減に 『「現実物をそのままモデル化するのがオブジェクト指向」ってのは間違ってるんだぜ!ぎゃはは』 っていう釣りは止めてください。 おまいらは本当に進歩がないですね。
540 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:01:41 ] わかったのか、前橋?
541 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:04:51 ] 『「現実物をそのままモデル化するのがオブジェクト指向」ってのは間違ってる』 って言ってるのは俺だけだなそういえば
542 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:05:25 ] ところで前橋って何
543 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:05:48 ] モノを知らない人が来ました。
544 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:05:55 ] >>540 前橋って誰だー!
545 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:06:27 ] ================================================================= 要するに、読む価値ないスレ。 無理に読んだら、確実にバカが伝染する =================================================================
546 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:07:44 ] >>545 枠線付けないとみんなにスルーされると思って不安なんですねw
547 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:08:07 ] ほんと、痛い人の巣窟
548 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:10:15 ] これだけ痛い人が一つのスレに集まるのは奇跡的。 つか、どー考えても自作自演だろ、この痛さは
549 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:17:32 ] 痛い人同士の間でこれらが会話(議論)として成り立っているのが、真に不思議
550 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 23:23:18 ] 自作自演の脳内会話だから ・・・いわゆる一般の会話じゃなくて、 分裂症患者の妄言みたいなもの
551 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 00:22:49 ] ところで前橋とはどのような殿方かね? っていうか誰だよ前橋。
552 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 00:23:37 ] まあ隔離スレとしてはこんなものでしょう。
553 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 00:54:04 ] ここのアンチみたいな人が部下や同僚にいると大変だよなぁ・・・ まぁ、実際この手のタイプはいるけどさ
554 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 02:34:47 ] >>541 >「現実物をそのままモデル化するのがオブジェクト指向」 痛いよなw だから存在しない「抽象の抽象」は理解不能なんだよなw いつからOOPってこんな稚拙で低知能な思考形態を正当化する概念になったんだ? こんなのプログラム組んだことのない、影で「クソ設計勘弁してくれ」呼ばわりされている「自称」SEの戯言だから心配するな。 こういう連中が「オブジェクト指向」と連呼するごとにチープな言葉になっていく。
555 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 02:37:54 ] いや、素人でしょ?>彼
556 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 02:41:46 ] つまり、アンチがこんなところで必死なのは、自分の思考能力を超えているような概念が流行してしまっては困るからだよ。 過去ログを見てみ。クソみたいな感情論,オリジナリティあふれる稚拙なオブジェクト指向論ばっかで、まともにデザパタを理解しての批判は一つもない。 必死に自分のカスぶりをアピールしているだけということに本人が気付いていないところが滑稽だよなw
557 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 03:28:20 ] >>555 まぁ、Fランク文系大卒で営業からSEに転向した(もしくはそれに準ずる)という意味ではど素人だわな。
558 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 03:30:11 ] ねぇ、ここに粘着してるキミは、 明日の仕事は無いのかな? つか、未来永劫仕事無いのか? ・・・気楽でいいなぁ、落伍者は
559 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 03:40:43 ] >>558 エリート相手に落伍者呼ばわりかよ小アジアの5流NEAT風情がw こっちは日曜日の昼前なの。
560 名前:デフォルトの名無しさん [2005/06/27(月) 03:43:03 ] 要するに、海外逃亡したけどやっぱ2ちゃん荒らしが日課の落伍者か
561 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 03:43:59 ] ヒント:脳内海外
562 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 07:21:39 ] >>554-556 定期的にこういうのが湧いちゃうのは仕方がないのかな?
563 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 07:48:54 ] >>562 仕方がないんじゃない? そう言われても仕方がないのが事実だからね。
564 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 07:51:04 ] >>562 >>552
565 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 10:23:24 ] >>562-564 (・∀・)
566 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 13:54:03 ] >>554-556 >>559 さすがエリート的な発言ですね。 っていうか議論のレベルがアンチ以下のような気がするんですが。 ガキ同志の悪口のいい合いじゃん。 こんなのがエリートだなんて人間終わってるな。
567 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 14:22:18 ] かつてのアンチオブジェクト指向スレと同じ流れ Template Methodパターンかな
568 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 14:23:16 ] >>557 は認めるのかw
569 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 14:48:00 ] >>568 それ本人じゃね?
570 名前:566 mailto:sage [2005/06/27(月) 15:58:08 ] >>568 むっ?漏れへのレス?本当だ。見逃してますた。 >>569 むっ?漏れへのレス?漏れは>>557 はじゃないですたい。
571 名前:566 mailto:sage [2005/06/27(月) 15:59:39 ] >>554-557 >>559 というか俺も言い過ぎた。ごめんよう。
572 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 19:10:15 ] 学生やってる間にあれやこれやと思いを馳せるのはいいことだ。がんばれ。
573 名前:デフォルトの名無しさん mailto:sage [2005/06/27(月) 23:52:28 ] ただ、固定観念にとらわれないように気をつけたほうがいいね。 本当に正しいことなんてそれほどない。 5年たったら評価が真逆になっていたり。 柔軟じゃないと変化についていけないお
574 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 04:29:22 ] >5年たったら評価が真逆になっていたり。 orz
575 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 11:44:54 ] GoFも5年以上たってるし、 もう海外ではもっとすごい手法が編み出されてるんだろうな。 取り残されているようでカナシス。
576 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 15:19:05 ] テクニック 踊らされれば 最先端 うれしや悲し 操り人形
577 名前:575 mailto:sage [2005/06/28(火) 16:49:00 ] >>576 まあ、そうだな。 俺は常に良いものを勉強していきたいし。 ある意味、操り人形。
578 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 18:00:01 ] >>575 情動過多による学習障害か? >> pc8.2ch.net/test/read.cgi/tech/1119158274/14-15 のリンク先を注意深く嫁
579 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 18:58:30 ] >情動過多 詳しい意味はしらないけど、 漢字見る限り多分俺それだ…これって病気なのか?
580 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 19:08:22 ] リンク先は読んだのか? 早く読め
581 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 19:20:57 ] 邪魔して悪かった。俺はROMだ。575じゃない。
582 名前:575 mailto:sage [2005/06/28(火) 19:44:28 ] >>578 すまんす。漏れは基本的に英語が読めん。 それにそのリンク先も、新しい技術に関する情報であって、良い情報なのかどうかわからん。 新しいからといって良いものとは限らんし。 というか「面白い技術情報は海外にあるけど漏れ英語読めねーし」と諦めたときから学習する気がうせた。
583 名前:541 mailto:sage [2005/06/28(火) 20:27:26 ] >>554 ×「現実世界をそのままモデル化するのがオブジェクト指向」 ○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」 そのままモデル化したら、ある対象物Aからの構造は1通りに決まりそうだけど、そういうわけにも行かない モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている 例) java.lang.System.out と System.Console は、両方とも Console への入出力を扱うが、双方には大きな違いがある などなど ……ってゴメン。書いてて気付いたけど 『オブジェクト指向的な構造を考える』 って思いっきり 『モデル化』 だった罠 超訂正
584 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 20:34:59 ] 似たものを、共通項でくくりひとまとめにするのがオブジェクト指向。
585 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 20:56:47 ] >>584 何か違う気がする。
586 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:11:46 ] >>582 pc8.2ch.net/test/read.cgi/tech/1119158274/14 で、ドメイン名が jpで終わってるリンクと、 pc8.2ch.net/test/read.cgi/tech/1119158274/15 のリンクは、 全部日本語のページだ。 早く読め。
587 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:18:29 ] >>583 >そのままモデル化したら、ある対象物Aからの構造は1通りに決まりそうだけど、そういうわけにも行かない >モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている そんなのお前のレベルが低いからじゃんw >○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」 そんなのまで許しちゃったら、オブジェクト指向(?)で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃないじゃん。 ちゃんと考えてるの? 俺もオブジェクト指向覚えたばかりの頃はそういういらんクラスが出たけど 最近は研ぎ澄まされてきて、そんな必要ない中間クラスはさっぱりでなくなったよ。 単に経験の差のような気がするけどねぇ。
588 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:21:54 ] >>587 継承も多態もないオブジェクト指向(?)の何が便利なの?
589 名前:541 mailto:sage [2005/06/28(火) 21:25:20 ] >>587 >そんなのまで許しちゃったら、オブジェクト指向(?)で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃない 現実世界とは無関係の物を捏造しろ、とは言っていないんで注意。 大まかな部分は似せろ、細かな部分で調節しろ。 俺は、経験というか世界観の違いのような気がするんだけどねぇ。
590 名前:デフォルトの名無しさん [2005/06/28(火) 21:33:56 ] >>587 >>49 の意味をちゃんと理解しろ、バァァァァーーーーーーカ
591 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:37:04 ] ノーターリンのOCaml厨は生きとるか?
592 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:37:54 ] ノーリターンに見えた
593 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:40:03 ] >>591 >>591 自身の過去レスを厨房呼ばわりする >>591 の人生って無価値
594 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:41:15 ] 2ちゃんねるの粘着くん(約一名)って、 コンプレックスだらけだな。カワイソ(爆笑
595 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 21:57:03 ] >>594 しかし、それでもこっちが本スレっぽくなって、 本スレが過疎スレになってしまう不思議w みんなどっちが正しいこといってるかなんて感覚ではわかってるんだよ。 だってデザパタっておせじにもわかりやすいとはいえないじゃん。 こういうのは直感が役に立たないもんは流行らないよ。 みんなで使うモンなんだからさ。
596 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 22:15:11 ] >>595 pc8.2ch.net/test/read.cgi/tech/1119158274/14 で、ドメイン名が jpで終わってるリンクと、 pc8.2ch.net/test/read.cgi/tech/1119158274/15 のリンクは、 全部日本語のページだ。 早く読め。 読んだら報告しろ
597 名前:595 mailto:sage [2005/06/28(火) 23:02:40 ] >>596 俺は>>582 じゃないよー。
598 名前:582 mailto:sage [2005/06/28(火) 23:13:37 ] >>596 えっ?いやあの。 1.エンタープライズアプリケーション開発のパターン by マーチン・ファウラー これ洋書の紹介だけじゃん。(´∀`;) 2.マーチン・ファウラー's bliki (blog) これ更新履歴一覧じゃん(´∀`;) ここのは「クロージャ」の説明しか読んだことない。全部読めと? 3.MixJuiceによるデザインパターン改善カタログ リンク切れしてるじゃん(´∀`;) 4.AspectJ を使ったデザインパターンの改善と支援 まずアスペクト志向がワケワカラナスなので説明がワケワカラナス(´∀`;)
599 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:14:52 ] >>590 すごい。中学時代を思い出すかのような素敵なレスだ。
600 名前:582 mailto:sage [2005/06/28(火) 23:16:32 ] >>596 いやぁ(´∀`;)ゞ、ごめんねぇ。
601 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:22:48 ] >>597 いいからお前も読んどけって。 どうせ頭の中身は >>582 とどっこいどっこいだろ? >>598 おまえには、短い文章の読解力もろくにない事がよく判る。 1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、 それくらい最低読んどけ。 2. 上記1.の文書が掲載されているblog (bliki)だ。 気になる文書があったら端から目を通してみろ。 そうすれば、ここまでレベルの低い会話はしなくて済む。 3. こっち嫁 staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/ 4. なんだよ?結局英語がわかんねぇだけじゃなくて、日本語でも駄目なんじゃねぇか。 じゃ 上の1の本、端から買って嫁。読み終わってから議論しろ
602 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:24:59 ] 最初から学習する気がないのかよ
603 名前:582 mailto:sage [2005/06/28(火) 23:32:02 ] >>595 こういっちゃなんだが元々、過疎スレだったのさ(涙 >>601 >1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、 > それくらい最低読んどけ。 >>596 のレスにこんな深い意味が込められていたのかーwwwいや冗談です。まあ、買って読んで見ます。 >2. (略 まあ、これは読む気だった。 >3. こっ(略 thx >4.なん(略 いやぁ。これ全部書き途中&自分用メモみたいだわ。文章としては非常に読みにくい。 パターン説明の8割がソースコードで解説とかアリエナス。ワケワカラナス。
604 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:35:10 ] 語尾「ねぇ。」もNGワードにすべきだと気付いた。
605 名前:デフォルトの名無しさん [2005/06/28(火) 23:37:40 ] >>603 正直に言え。おまえはソースなんてろくすっぽ読めない素人だろ? 証拠のソース出せずに荒れ、UML設計でいいから出せと言われてまた荒れ、 挙句にソースで解説されても判らねぇ?はぁ? おまえには、ここで議論する資格ねぇんだよ。 さっさと巣に戻って、プルプルプルプル一晩中震えてろって
606 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:39:15 ] >ここで議論する資格 ( ´,_ゝ`)プ
607 名前:デフォルトの名無しさん [2005/06/28(火) 23:40:20 ] クズはさっさと巣に戻れ
608 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:41:21 ] ================================================================= 現在、ソースも読めない素人が粘着中です。 粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。 =================================================================
609 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:43:11 ] >>602 そーゆーこと。 さっさとこいつをアクセス禁止にしないと、 プログラム板の荒れが収まりようがない のは周知の事実
610 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:43:39 ] ↓玄人が一言
611 名前:582 mailto:sage [2005/06/28(火) 23:43:48 ] >>601 なにぃ!J2EEパターンとかいう本があったのね。 これはめっさ読みたい。ありがとう。 >>605 おおぅ、なんか荒れてるなぁ(´∀`;) 漏れはむしろこのスレでソースコード書いてた奴さね。 まあ、議論する資格なさそうだから消えるよ。
612 名前:582 mailto:sage [2005/06/28(火) 23:44:22 ] あっ、玄人ゲットウレシスwwww
613 名前:デフォルトの名無しさん [2005/06/28(火) 23:51:26 ] 議論スレで人に「本読んで勉強してくださいね」ってのは無しだよ。 自分でDLLが無いと動かないMFCアプリ作っておいて ユーザに押し付けて、動かないのをユーザのせいにする奴とにてるよ。 この場合ってMFCのDLLが無くても動くように作るのが普通だよね? 結局さ、議論スレで強引に自分の気にいった本を読むように押し付ける奴ってこういう奴なんだよ。 俺等が読んで無い本はお前にとってMFCのDLLなんだろ?w じゃあさ、DLLが必要なくても動くようにしてこいよw
614 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:53:24 ] >>613 と、ソースも読めない厨房が寝言をほざいてます(笑 無視無視
615 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:54:36 ] J2EEパターン本すら初めて知った素人>>582 が 玄人のフリをする痛いスレ
616 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:55:17 ] >>604 耳や尻尾をみつけた時は黙って自分の胸に仕舞っとけ。 気付いてる奴はとっくに気付いてて発言者の特定に使ってるんだから そういう発言は邪魔になる。無くて七癖文章の癖ってなw
617 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:58:26 ] >>613 議論をするにはいくらかの前提が必要だ。敷居と言い直してもいい。 必要と発言するにも、不要と発言するにも、最低限それについて知 っていなければ議論にならない。
618 名前:デフォルトの名無しさん mailto:sage [2005/06/28(火) 23:59:22 ] >>614 図星突かれて、ファビョ(火病)って改行連発しちゃった?
619 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:00:42 ] なんでわざわざ(火病)w
620 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:01:49 ] >>617 MFCのDLLはユーザが自分で入れておくべきだと。そういうことか。 まあ、流行らないものって全部そうだよ。 MSが出したManagedなんとかっていうゴミもこんな感じで流行らないし。 勝手に敷居を作るのはかまわないけど、みんなの同意もなしじゃ 独りよがりと言われてもしょうがないよね?
621 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:03:21 ] 自分が知っていることが常識ですよ。
622 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:05:04 ] >>617 同意。そして、>>608 に賛成。
623 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:05:37 ] ここの粘着は本当に単純だね。 図星を突かれると、瞬間的に脳が火病って途端に話が非論理的になるからな。
624 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:06:30 ] >>616 かつての「ねぇ」遣いは、多少マトモな事を言う糞粘着院生だったんだけどねぇ(藁 今の「ねぇ」遣いは、皆が一番嫌っているコテハンの多くを駆使してる基地外だからなぁ(w
625 名前:デフォルトの名無しさん [2005/06/29(水) 00:07:35 ] で?>>596 のリンク先文書は読んだ? さっさと報告しろ
626 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:09:45 ] >>624 アレは瞬間湯沸かし器だから、一発で判る。 たぶんそのうち、脳溢血で逝くだろう。その日を楽しみにしている。 煽って煽って喧嘩ばかりの荒んだ毎日。可哀想な人生だね。同情するよ
627 名前:デフォルトの名無しさん [2005/06/29(水) 00:10:36 ] >>625 そう人にDLLの挿入を押し付けるなよw 俺等が入れたくねぇって言ってるんだから。 むしろてめぇの方がDLLが必要ないように実行ファイル作ってこいよw
628 名前:582 mailto:sage [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 例え話がぴったりだったからそんな的外れないい逃れするの? 君さっき改行連発してた人だよね? もしかして、ファビョ(火病)った?w
632 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:17:15 ] >>631 と、ソースも読めない厨房が寝言をほざいてます(笑 無視無視
633 名前:582 mailto:sage [2005/06/29(水) 00:18:24 ] >>630 >他のレス番使った発言も一切するな。 これだけは言わせてもらうけど、漏れずっと名前欄に「582」って入れてる奴だよ。 他は俺の書込みではない。
634 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:19:24 ] >>633 じゃぁさっさと読め。 読み終えるまで発言するな。 以下、1000番まで同様な繰り返し。(省略)
635 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:20:19 ] キチガイの相手をするから、スレが荒れるのだと思う
636 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:21:09 ] >>634 くそ!DLLが無いと!俺のアプリがうごかねぇよ! 早く入れろよ!馬鹿! もしかして、VBのランタイムの方?ぷw
637 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:22:05 ] >>635 それがおもしろいんだろ もう、必死でしょう・・・最近のデザパタ厨
638 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:23:28 ] 相手をしてる香具師はそいつと同レベルだと言うことに気付け
639 名前:デフォルトの名無しさん [2005/06/29(水) 00:23:36 ] ================================================================= 現在、ソースも読めない素人が、話題をずらそうと必死に粘着中です。 粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。 =================================================================
640 名前:582 mailto:sage [2005/06/29(水) 00:23:55 ] >>634 君のための議論スレでもないのに自治活動お疲れさん。 つーか、ここはアンチデザパタさんと「デザパタは本当に必要か」議論するスレだと思ったんけど。 このスレに書込むには>>596 を読めと?それはアンチデザパタさんが読むかな? まあいいや、くだらないことだわ。
641 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:26:52 ] 日本語の情報があっても学習する気のないヤシが必死に弁解していまつねw
642 名前:デフォルトの名無しさん [2005/06/29(水) 00:26:56 ] 普通の人間だったら、恥ずかしくて自殺すらしかねない恥をかいているのに、 それでもまだ自作自演で粘着してくる >>582 のキチガイっぷりにひどく感心
643 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:29:30 ] >>640 >それはアンチデザパタさんが読むかな? それならそれでろくに理解しようともせずにデザパタ不要と喚いてる厨であることがわかるので好都合
644 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:30:51 ] >>642 人間との言葉のやり取りに激しい飢餓感を感じ、 コケにされてもキチガイ扱いされてもスレにすがりつく疎外された人間 (例: ひきこもり、アル中患者、禁治産者)の類だろ、奴は
645 名前:デフォルトの名無しさん [2005/06/29(水) 00:35:34 ] >>643 てゆうか、はやく学校卒業しろよw みんな深夜まで仕事しててマジでぶっちゃけそんな本読んでる奴いないからw みんなそれぞれ家庭があったり他に趣味があったり、プログラム1つとっても設計に 時間を費やせる奴ってそんなにいないぞ。 2年ぐらいかけてGoF本読むのが精一杯な奴多いんじゃねーかな?(俺は学生の頃読んだけど) 現場でプログラマの仕事の作業量みれば、 こんなの(デザパタ)流行らねーってわかるんだよ。 それじゃなくても不勉強な奴多いのに。 こんなの読むわけないだろwアフォかっつーのw
646 名前:デフォルトの名無しさん [2005/06/29(水) 00:44:15 ] >>645 キチガイの発言の特徴は、時代感覚がズレまくっているあたりだな。 例えば先週か今週、本屋に行って雑誌売り場覗いてれば、 そんなキチガイみたいな書き込みはしないと思うけど。
647 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:45:58 ] 流行る流行らないじゃなく自然に存在してるんだけど・・・・・・ もう最近ではそれと意識されずに使われてる事の方が多い。
648 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:49:04 ] >>645 プログラム1つとっても設計に時間を費やせる奴ってそんなにいないぞ 素人乙
649 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 00:51:35 ] JAVAは特にそうだな>自然に存在してる でも、アレは酷だよな。パターンを知らない人間には意図が読めない から、無駄に持って回った複雑な設計にしか見えない。ゲキムゴスw
650 名前:デフォルトの名無しさん [2005/06/29(水) 00:58:24 ] >>646 まあ、現場で働いてる人間にそんなもん読む暇があるかどうかがわからない人間にはわからないだろうなw たくさんの人に伝えなきゃ意味の無いものはそんなに複雑であっちゃいけないんだよ。 本を読め→読みました!→言っていることがわかりました。 なんて流れなかっただろ? 逆に俺の方から本の推薦をしたら、お前はきっと嫌がるだろう。 そんなこともわからない奴が設計について語ったって役に立たないことはわかるだろ。 誰もついていかないよ。 基本的に嫌じゃん。知識が無いのを馬鹿にされるのって。 必ず自分の知らない分野で仕返しされるじゃん。 個人ってそんなに万能じゃないじゃん。 お前も人を馬鹿にするとき、自分の知ってる分野をあげてそれについて語って、 相手がそれについての知識があさいとここぞとばかりに「勉強してくださいよw」とかいって 本を薦めて議論に勝った気になるのよくやってるじゃん。 これってされたほうの気持ち考えたことある? この先、その調子で仲間とうまくやれる自信ある?
651 名前:582 mailto:sage [2005/06/29(水) 01:00:43 ] >>645 まあそうだねぇ。時間ないよなぁ。最近、本買うのも慎重になってきたし。 変な本読まされて時間を無駄にする事ほど苦痛なものはない。 でもデザパタはなかなかいいもんだと思うよ。一部だけのパターンは。 >>649 おお、それ激しく同意。以前、勉強をかねてJavaのソースコード解析してたけど、 Socketクラス辺りとかワケワカラナスwww(SocketImplとかSocketImplFactoryとかの変なクラス) デザパタ知ってああそうなんだってすげぇとか感動した。
652 名前:582 mailto:sage [2005/06/29(水) 01:01:41 ] >>651 s/一部だけのパターンは/一部のパターンだけは/ へんな日本語になってた。
653 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:09:07 ] 正直、ここの粘着基地外は、在日朝鮮人でしょ。 この腐りきったメンタリティはとても日本人の物とは思えない。
654 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:11:02 ] 自分の嫌いの香具師は全員在日朝鮮人です
655 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:15:08 ] cppllにOCaml厨が投稿してるが、このスレのOCaml厨とひょっとして 同一人物じゃね?何か直感的にそんな気がした。時期的に一致しすぎてる。
656 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:16:22 ] >>650 かかって来い(げらぷ まじ。結構俺って万能なのね、下らない話題以外は
657 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:16:36 ] >嫌いの香具師は 訂正しる!
658 名前:デフォルトの名無しさん [2005/06/29(水) 01:22:58 ] あとさ、>>650 。 社交辞令で「・・・自信ありません」くらいの事を言う可愛げはあるけど、 それが社交辞令だってことくらい、ちゃんと見抜け。 コミュニケーションの為に、相手が想定しているであろうプレゼンをする事で、 たとえそのプレゼンが偽りであっても、以降のコミュニケーションがうまく進む、 そういった効果を狙っているだけだよ、実際。 10年前に嫌々関わったOO分野だが、 いい加減 GoFも流し読みできないレベルの奴と関わるのには飽き飽きした。 もしOO分野に関わるということが、GoFも読めない猿にGoFを説得する事を意味するのであれば、 OO分野にはもうかかわりたくも無い
659 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:29:16 ] >>658 ←こいつなんでこのスレにきたの?w
660 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:32:31 ] >>659 にほんごのどくかいりょくがたりません。もっとがんばりましょう
661 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:37:00 ] >>655 今cppll探して読んでみたが、実名らしき物をシグニチャに書いてるね。 メルアドも。 違う人だったらいけないのでここには晒せないが、もし本人だったら 間抜け過ぎだね。
662 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:39:50 ] >>655 cppllってなんじゃらほい。 ここのOCaml厨房は、単にOCamlとMLって単語を連発するだけの池沼だよ。
663 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:42:29 ] >>662 www.tietew.jp/cppll/ ここ。 C++のML。 後は悪いけど、自分で探してちょ。ヒントは、ごく最近の投稿。
664 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:42:45 ] >>662 むしろ >>655 , >>651 あたりが この板でOCaml厨と呼ばれている厨房の希ガス
665 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:46:16 ] だいたい、国立情報学研究所の人間捕まえて、 OCaml厨呼ばわりするのもなかなか厨房じみた妄想だ。 今現在2ちゃんで、「ML」と「OCaml」というキーワード使って荒らしやってるのは、 かつてRubyやHSPで荒らしやってたキチガイだろ。
666 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:47:56 ] >>663 www.tietew.jp/cppll/archive/12065 こいつのことか?
667 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:51:40 ] ま、しかし、2chのム板を見ても、OCamlなんてマイナー な言語について熱く語る香具師は、数えるほどしかいないね。 2ch内なら同一人物の可能性もあるけど。だからどうしたって 聞かれると、別に何もないけどな。
668 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:54:04 ] >>666-667 そうかぁ? 俺が学生の頃は、Haskellが動くPCなんてなかったから、 OCamlかGoferで自己学習・・・ってのがデフォだったけどね。
669 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:54:46 ] >>666 明らかにレベルが違うじゃん。 そもそもの不満点(というか単なる愚痴に見えるが・・・)からして、コードが 書けない人間からは決して生まれない類のものだし、その改善法と問題 点も把握できてる。 具体的な事は何一つ書けない某彼と一緒にするのは、あまりにも酷だ。
670 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:58:44 ] >>655 , >>651 , >>667 =OCaml厨本人 理由:OCamlに関する話題は、全て同一人物が行っていると妄想する程のキチガイだから。
671 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 01:59:26 ] Haskellって言うとghcしか知らないけど、なかなか面白いや。
672 名前:デフォルトの名無しさん mailto:sage こいつがOCaml厨本人やん [2005/06/29(水) 02:00:55 ] >>671 具体的に何が面白いか、説明してみな。
673 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 02:10:52 ] >>672 それが人に物を聞く態度かい。横柄な奴には教えてやらないよ。ベーだ。
674 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 02:12:29 ] 黙ってりゃ書いてたものを。>>672 みたいなのをやぶ蛇って言うんだ。覚えとけ。
675 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 02:22:38 ] >>650 あなたの発言は、一昨日昼飯を一緒に食った人物と同じ、 特徴的な思考パターンが見られるので、非常に興味深い。 その件について、いずれ話し合おう
676 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 02:25:58 ] >>671 , >>673-674 のような低レベルな奴が現れるのと同じタイミングで、 >>650 が現れるのは、非常に興味深い現象である。
677 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 02:27:56 ] あ、それから、もしHaskellについて判りやすい説明が必要なら、 それも今度説明しましょう。リアルの方で
678 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 09:12:14 ] >>675 リアルで特定されてる?ワロタ!!
679 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 12:42:54 ] 話し戻すけど、技術の流行り廃れはメディア上の現象で、 実際にソース組む人の立場になれば、未だに構造化手法も 有効だし、オブジェクト指向も大切だし、デザインパターンも、 亜蛇煎るプログラミングも有効だし、UMLも有効だし、 フローチャートも有効だし、ウォータフォールモデルも有効だし、 データモデリングも有効だし、どれ一つを取っても捨てていい 技術は無いんだよね。 もちろん、今時フローチャートでシステムレベルの記述を する事は避けた方が良いし、フローチャートじゃあ記述出来ない けれど、メソッドの中の人を記述する必要が有る時にはやっぱり フローチャートが一番しっくりくるし、メソッド一つ一つを見れば、 構造化で培ってきた関数化の技術が生きるしさ。 新しい技術は取り入れるもので、捨て去るのはなかなか難しいよ。 もちろん、GoFのパターンカタログを一生懸命勉強すればデザインパターン を身に付けられると思う馬鹿は、幸せに生きてれば良いけど。
680 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 13:28:15 ] #フローチャートは23年前に捨てましたが何か?
681 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 13:29:09 ] うちの大学では今まさに教えられてますが orz いらねーよこんなの orz
682 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 13:31:58 ] アクティビティ図の練習だと思ってガマンしなよ・・・
683 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 13:37:45 ] >>679 お前何才よ?ロートルプログラマか?w 年取りすぎて会社じゃもうどこも雇ってもらえないから、家で妄想の毎日か。
684 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 14:40:13 ] >>683 679じゃないけど、結構あるよーこういう現場。 まだ679は新旧混合で選択しようってんだからいい方だよ。
685 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 14:47:14 ] フローチャートはちとキツイ。 あれはホントにお絵かきで終わっちゃうからなぁ。 PAD図だったらプログラムの構造が保たれているからまだマシなんだけど。 # でも実際には使ってないけどね。 UMLのクラス図なんかもリバースエンジニアリング出来ないとお絵かきで終わっちゃう。
686 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 19:22:49 ] フローチャートって、ループすらマトモに書けないじゃん はっきり言ってアセンブラならまだしも 今時の高級言語なら、フローチャートに落とすことによって 何かがわかりやすくなったりすることはありえない
687 名前:681 mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 21:44:54 ] >>679 結構同意。
689 名前:デフォルトの名無しさん mailto:sage [2005/06/29(水) 22:22:42 ] 構造化もOOもデザパタも勉強してみると実は現場で似たような事やってた ってオチがままある
690 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:12:18 ] >>679 状況によっては古い技術の方が、効力を発揮したりするしね。 色々な知識を持って、あらゆる状況に対応できることが大切だと思う。
691 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:27:38 ] >>689 Cで構造体のメンバとして関数ポインタ持たせて 偽多態みたいなのは良くやるが、 クラスや継承までエミュレートしたことはないなあ。 後、構造体の先頭レイアウトだけ合わせてポインタ渡しとかはありがちだな。 なんかOOというより苦し紛れのテクニック、という気分もするが。
692 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:30:06 BE:84286962- ] >>691 Cしか使えない現場なの?
693 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:37:35 ] >>692 少なくとも俺が入社したころ(そんなに昔ではないのだが)は Windows3.1、VC++1.0が現役だったし C + SDKで組まれてるプログラムが珍しくなかったんですわ
694 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 01:39:02 ] あと、apacheのモジュールみたいなso作ったりとか、 その手の仕事はCが普通じゃまいか。 別に制御屋さんとかじゃなくてもC触る機会、結構あるでよ。
695 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:03:20 BE:42143832- ] なるほど、昔の話か。今となってしまっては よほど速度や資源を求めない限りはCオンリーは嫌ぽ。 # apacheのsoはよくわからんす。
696 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:19:55 ] >>695 apacheのモジュールは、いわゆるプラグインみたいなもんだす。 soはshared object(library)、いわゆるDLLね。 アプリじゃなくてDLL書く場合はCで書くことは珍しくないと思うよ今でも
697 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:28:33 ] >>696 DLL書く場合でもC++のが楽でいい。
698 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 02:32:47 ] >>697 C++だとスタートアップコードが必要になったりしてちょっとヤじゃない? もともとC++用のDLLならいいけれど Cインタフェースを公開するDLLなら、Cで書いて、しかもlibcに依存しない 形にしたい
699 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 08:39:28 ] Cしか使えないならCを使うけど、積極的に使おうと思うものじゃないよあれは。 一刻も早く地上から消え去って欲しい。
700 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 09:42:29 ] >>699 Cと一緒にお前も消えろ。
701 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 14:20:49 ] なんでもデザパタに当てはめないと設計できなくなったら終わりだな。 というか、あーでもない、こーでもないって、 ころころ設計変えるのが、楽しいのに。 漏れの楽しみ取らないでくださいよ。
702 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 14:36:11 ] >>701 いもしない人間を想定して適当なことを言うのはやめましょう
703 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 15:11:34 ] >>687 学生時代、pad2psというソフトをつかってソースからPAD図生成してました。 レポート書くのに助けられたなぁ・・・今は使ってないけど。
704 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:03:09 ] いくらJavaやC#でオブジェクト指向だなんていっても、メソッドの中では構造化の知識がいるだろ。 5行で終わるようなものを50行ぐらいかけてなにやってんだか分からないようなダサダサソースはうんざりするでしょ。
705 名前:デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:17:37 ] 構造化分析と構造化プログラム設計と構造化コード
706 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 01:45:06 ] >>699 それはCも使えてないってことだろ。
707 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 02:00:07 ] 今からここはCの素晴らしさを褒め称えるスレになりますた
708 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 09:37:08 ] >>706 じゃあおまいさんはC++もjavaもC#も使えるような環境において積極的にC言語を選択するか?
709 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 10:05:40 ] たいていの言語はC言語やC言語のライブラリが土台になってるから消え去ってもらっては困る
710 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:07:33 ] >>708 1)shell等の外のプログラムから部品として呼び出すことを想定したコマンド・ フィルタ風のプログラムなら、少なくともJavaやC#は「絶対に」使わない。 ツールボックスアプローチの部品としては、起動遅いのは致命的。 2)C向けのDLLは大抵Cで書くな。 libc使ってしまうと、クライアントコードとlibcのバージョン合わせる必要が 生じてウザい。これ、Win32の話ですが。 3)俺は書かないけど、オープンソースでなるべく広い環境で使われたいと願う コードを記述するなら、Cのが今でも多いだろ。環境をそもそも特定できない から、だが。
711 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:09:10 ] >>710 なるほど。そうかそうか、よーくわかったぞ。それは面白い考えだ。
712 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:28:26 ] >>711 せっかく真面目に答えてやっとるのになんだ、その人を小ばかにしたような 態度は。それで優位に立ってるつもりなのかね、チミは。 反論があるならもっとマジメにやれ。
713 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:14:36 BE:70239252- ] C++でDLL作ったことないので深く突っ込めないんだけど、 インターフェースはCで提供して、 実装はC++ってのもやっぱ無理ですか?
714 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:19:01 ] >>712 だってお前の意見になんか全然興味ないもん。
715 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:33:41 ] >>713 可能か不可能かといえば可能。extern "C"すればいいだけだから。
716 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:34:20 ] >>714 なら下らん一言でスレ汚さずに単にスルーしろよ
717 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:39:47 ] >>716 うるせぇーよ。ぼけ、氏ね ( ´∀`)
718 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 18:46:30 ] そういえばツールボックスアプローチってデザパタ厨的にはどうなのよ
719 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 19:27:28 BE:70239825- ] >>715 それでも>>710 の言うようなlibcのバージョン合わせる必要ありますか? >>718 嫌いじゃないが。
720 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 20:36:27 ] >>718 OOPな時点でツー〜ーチなん違うん?
721 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:05:28 ] >>720 UNIXのツールボックスアプローチってのは、シェルという糊言語を用いて、 部品になる小さくて独立したプログラム群を組み合わせることで 仕事を実現する手法のことなんだが。 プログラムが分かれてるから完全に疎結合。で、標準入出力、パイプ、 コマンドライン引数、戻り値といった単純でwel-definedな仕組みを用いて それを組み合わせていく。 概念的にはOOとは全く関係ないし、Smalltalkとか見ても、OOはむしろ モノリシックで巨大なものを指向する傾向があるんじゃないか。 むしろLISPに似ているというか。
723 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:17:37 ] >>722 >概念的にはOOとは全く関係ないし 疎結合という面と、独立したプログラムという面から見て、オブジェクト指向に通じる物があるかと思ってた
724 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:20:50 ] >>722 クラスは>>722 の中段で書かれてる要素を全て満たしてると思う。 「である。」とは思わないけど、「の様な振る舞いを持たせる事もできる。」と思う。
725 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:53:44 ] Javaで実装されたシェルもあるね、実用上は使い物にならないと思うけど。 コマンドパターン風に実装したクラスがプログラムのかわりで、 それを実行時ロードとかまあそんな感じかな。
726 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:58:22 ] 本当にそんなんなのか?
727 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 22:02:59 ] >>726 すまん大して興味が無いのでちゃんと見てないんだが 要するに、コマンド実行するたびにVMロードされちゃたまらんワケで、 同一VM上でコマンドを実行するのが、Javaで「使い物になる」シェル風の 環境を作る大前提。 find . -name '*.html' -exec rm {} とかそんなことをやると、それこそうんざりするほど大量の子プロセスが 生成されて実行されるのがシェルの世界だからな。 その辺は、antのタスクの考え方と同じ。要するに、インタラクティブに 実行できてmake作業に特化してないant+αみたいなもんじゃないかな。
728 名前:デフォルトの名無しさん mailto:sage [2005/07/01(金) 22:11:51 ] tclとかはシェル風のごく単純なグルー言語+コマンド関数の世界だが あれはCで書かれてるから、Javaみたいに実行時ロードできないんだよな ってどんどんスレ違いの世界に
729 名前:719 mailto:sage [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対応 www.jdistro.com/jsh/ COLLIN Gerard's jsh: the opensource java application launcher ! Java Web Start対応 gerard.collin3.free.fr/ TeaShell: 複数のJavaアプリケーションを一つのJavaVMで動かすJavaシェル www.vector.co.jp/soft/other/java/se089271.html ・その他国内某所で Java シェルOS開発というスレが立ち上がってるのを発見したんだけど、 そこの1、一体何作ろうとしてんのか、よくわかんないや(OSによらず使い慣れたシェル環境を提供するって何?) ・JDK1.6では、Oracle JavaVM流のapplication partitioningの仕組みが導入されるそうなんで、 JavaVMプロセスを多数起動しなくても、いろいろな事がやりやすくなるね。(本来はAppServer向け機能だけど)
731 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 01:17:07 ] >>730 少なくともこのスレと関連のあることをいってくれないと。 リンクの貼り付けだけだと荒らしに見える。
732 名前:本スレ住人 mailto:sage [2005/07/02(土) 04:01:40 ] わるいね。 UNIXシェルとコマンドによる祖結合プログラミングは、 デザインパターンと並んでソフトウェア工学上重要な話題です。 Javaにおいてどのような試みがなされているか、 そして、Javaサーバ〜Webサービスの基盤 (アプリケーション・パーティショニング)が、 UNIXシェルの基盤にもなりうる、という話題を振ったつもりですが。 もしかして、ここは似非スレだから、似非話題以外はスレ違いなのかな(藁
733 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 08:27:03 ] >>730 >OSによらず使い慣れたシェル環境を提供するって何? OSによるshellの方言を吸収しようという意味じゃないすか。
734 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 11:19:11 ] >>732 >デザインパターンと並んでソフトウェア工学上重要な話題です。 だから何?スレ違いに変わりない事に気付けよバカ。
735 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 12:29:02 ] >>734 気付いてないのは恐らく君だけ
736 名前:デフォルトの名無しさん [2005/07/02(土) 13:17:27 ] >>732 早く本スレ帰ればいいじゃん。 過疎スレ帰れよw #デザパタなんてどうせやってる奴いないからこないだろうけどwぷw >>731 と>>734 は別人ね。俺は>>731 。
737 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 14:58:05 ] 本当に隔離スレだな どうでもいいレスでageてるし
738 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 15:56:53 ] 糞な香具師だらけだから、糞スレになるのは当たり前
739 名前:デフォルトの名無しさん [2005/07/02(土) 16:17:40 ] >>737-738 じゃあ、早く本スレ帰んな。
740 名前:デフォルトの名無しさん [2005/07/02(土) 16:18:59 ] ω日本のハッカー、今立ち上がれ!!!! pc8.2ch.net/test/read.cgi/pcnews/1120271067/ また中国です。
741 名前:152 [2005/07/02(土) 16:23:42 ] >>740 そんなことしてる暇あるならコード書けってかんじだよなぁ
742 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 16:44:15 ] >>740 それ、東アジアニュース+でガイシュツだよ。 中国と韓国からのケーブルは切断しなきゃダメだね。
743 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 17:20:28 ] Javaで動くシェル作るぐらいなら、オールJavaのOS作れ。
744 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 19:21:30 ] >>740 なんつーか、どっちも死ねよと。
745 名前:デフォルトの名無しさん mailto:sage [2005/07/02(土) 21:52:29 ] …………… く ず れ す ……………
746 名前:デフォルトの名無しさん mailto:sage [2005/07/03(日) 18:40:06 ] プログラム板が荒れているため、IDを導入するか検討中です。 賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。 プログラム技術板に強制ID制を導入すべきか否か etc4.2ch.net/test/read.cgi/vote/1118144381/ 理由などの記入は別に構いません。 <<賛成>>か<<反対>>かだけ御記入頂ければ結構です。 ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。
747 名前:デフォルトの名無しさん [2005/07/10(日) 14:08:52 ] 本スレが伸びてると思ったら、 ここに粘着してた頭のおかしいデザパタ信者が集中砲火浴びたっぽいなw いつも都合の悪い話題が出ると自分の発言を軌道修正するから あいつ嫌われるだろうなと思ったら滅多撃ちにされてるなw
748 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 14:35:43 ] 伸びてるも何も2005/07/08(金) 12:50:07から書き込みがないぞ?
749 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 16:25:41 ] >>748 いや、向こうのスレで 2005/06/23(木) 23:12:19 周辺から糞化してたから見て無かったんで・・・
750 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 16:28:28 ] >>749 つか、あのスレ自体、信者vsアンチの構図が無くなった時点で全く意味がない。 デザパタ自体は誰も仕事でなんか使ってないから、デザパタ自体のことを語るのはおもしろくない。
751 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 17:21:15 ] バカ粘着スレ 仕事してる俺たちゃ、 あんたみたいな無職野郎と違って 暇じゃないのよ
752 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:26:09 ] >>750 J2EEアプリやったことがないのに > デザパタ自体は誰も仕事でなんか使ってない なんて断言するなよ。無知丸出し。
753 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:33:18 ] J2EE だけじゃないんですが JavaAPI のレベルでも、既にパターンを見つけることも出来るんですが
754 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:42:17 ] >>753 APIで使われているかどうかじゃなくて、自分が作成するアプリの設計に適用するかどうかを言ったつもりだった。 まあ、ヤツはJavaすらやったこと無いんだろうけど。
755 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 20:53:25 ] >>754 ああん了解
756 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:04:29 ] ファクトリやストラテジ、アダプタなんかは趣味グラムでも多用するぞ。 もっとも、趣味グラムの場合、単に完成を急ぎたいからそうするだけな んだけど・・・・・・要はcommons-loggingの悪用と同じ。 詳細決まってないとこは空箱でも詰めとけw
757 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:06:19 ] > デザパタ自体は誰も仕事でなんか使ってない 誰もというのは言いすぎだが、ほぼ正しい。 1.使ってないやつ 70% 2.使ってプロジェクトに混乱を起こすやつ 25% 3.正しく理解して設計に応用するやつ 5% もちろん俺は3
758 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:09:59 ] ネタスレだから、低レベルな奴しか居ないというのには同意。
759 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:13:49 ] JAVA前提の職業プログラマに限れば 1.使わされてる奴:70% 2.使わせてる奴:20% 3.( ゚д゚)ポカーン:10% もちろん俺は1orz
760 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:20:25 ] 「知らずに使ってる奴」も居る筈
761 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:27:59 ] >>760 大規模プロジェクトでは「知らずに使われてる奴」は多そうだね。
762 名前:デフォルトの名無しさん mailto:aoru [2005/07/10(日) 21:38:19 ] デザインパターンなんて基本的に不要でつね。 継承、多態なんてまずは使わないで設計できるかを考えるべき。 その上で、どうしようもない場合は、継承、多態を使う。 で、継承、多態を使う場合も、基本的なTemplate Methodとかはともかく、 基本的にデザパタは使わないで設計を考える。 それでも必要の時だけデザパタを使うと。 極力シンプルを目指して、リファクタリングをして、継承、多態を減らすと。 つまり、デザパタは基本的に不要!
763 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:41:19 ] >>762 >どうしようもない場合は、継承、多態を使う 「構造が簡潔になる場合は〜」 に訂正して欲しいこと以外は同意
764 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:47:17 ] デザパタは認めないのにリファクタリングはOKなんですか?
765 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 21:48:27 ] >>762 みたいなのは、コンテナ依存のコンポーネントのモックテストなんてやったことないんだろうな。
766 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:42:49 ] さすが隔離スレだな。 1987 OOPSLAのGamma以前のレベルで進化が止まってるわ。 >>765 あんたもデザパタなんて保守的な事言わず、J2EEパターン、.NETパターン、PoEAAにESBって どんどん話題振らなきゃ。
767 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:53:18 ] >J2EEパターン、.NETパターン、PoEAAにESB それらはデザインパターンとは呼ばないのか?
768 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:54:37 ] 「デザイン」 の 「パターン」 ならば 「デザインパターン」 なんだろうな
769 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 22:57:07 ] www.microsoft.com/japan/msdn/practices/Type/Patterns/enterprise/ によれば、パターンの適用範囲はデザインだけではないね
770 名前:デフォルトの名無しさん mailto:sage [2005/07/10(日) 23:08:00 ] >>767 一応、口ではそんなんデザパタに含んでると反論するが、 実際のパターン名はシングルトンにファクトリー、テンプレートメソッドくらいしか出てこないのが、 隔離スレ・クオリティ(藁
771 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:10:18 ] 本スレもそうだけど、君ら自慢と煽り合いが大好きね('A`) 議論を持ち出せば「お前、レベルが低い」とか、馬鹿だなんだと罵り、 どこのサイトのなんの記事を熟読してから書き込めなどといって書き込み排除。 別にいいじゃんレベル低かろうが。 もっと気軽な議論スレがほしい。 正直この状態じゃ何も議論できない気がする。 デザパタ初心者スレでも建てっかな。
772 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:11:57 ] そしてまた増えるデザパタスレ(過疎)
773 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:13:16 ] >>762 デザパタ => オブジェクト指向 に変えても読めてしまう。 そういうことですか?>>762
774 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:35:37 ] >>771 >正直この状態じゃ何も議論できない気がする。 お前の脳みそはまだそんなこと考えてるのかとw >>757 >3.正しく理解して設計に応用するやつ 5% これは嘘。 5%もいるわけない。 デザパタはネタ。 実際のプロジェクトでは使ってるところは存在しない。
775 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:37:22 ] >>771 何のための隔離スレだかわかってる?
776 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:43:27 ] > 実際のプロジェクトでは使ってるところは存在しない。 そんなわけない。 俺がいる会社でも使ってるし、知り合いのいる会社でも普通に使うし。 ホントに無知だな。かわいそうに。
777 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 01:56:08 ] >>775 はじめはアンチだけをここに隔離する目的だったんだけど、 アンチがいなくなったら本スレが過疎スレになっちゃったから今となっては微妙一色w 折角、隔離スレとしてアンチ同士で楽しくやろうと思ってたのに 本スレが過疎スレになったから信者がこっちにまできて非常に邪魔。 はっきりいうけど、本スレが盛り上がらないのは、 本当はデザパタなんて誰も使ってないから、話す話題がない。 技術としても不確定で誰が正しくて間違っているか特定させる手段が無いから、 パターンブームにのってエセ研究者気取りがいいたい放題。 議論も「いかにして相手を言い負かすか」が焦点になっててまったく本質に触れようとしない。 >>776 君こそ、知らないの? デザパタなんて狭い世界の話なんだよw
778 名前:デフォルトの名無しさん [2005/07/11(月) 01:56:48 ] >>776 そんなにいうなら本スレ盛り上げてきてよw ま、誰もこないだろうけどさw
779 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:10:51 ] >>777 「存在しない」から「狭い世界」へ修正ですか?w 次は「特定の分野では使われている」に修正して さらには「○○では使われていない」に修正ですか? どこかの議員さんみたいですね。
780 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:11:39 ] >>778 だって、使って当たり前、使われ方もほぼ決まっているのに何を今更議論するのさ?
781 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:13:08 ] >>777 > はじめはアンチだけをここに隔離する目的 ちがうだろ? デザパタが必要か要らないかの議論をするのがこのスレの目的。 本スレはデザパタありきでの議論が目的。
782 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:37:38 ] 本スレが寂れたのは、頭がおかしい人物が荒らしまくって、良心的な人々を遠ざけたから。 荒らし風情がひらきなおるんじゃねぇ〜よ、クズめ
783 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:40:48 ] >>771 某スレで、またぞろakon叩きするバカが発生してたけど、 あんたらのコミュニティは一体どうなってるの?
784 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:47:10 ] 未だにパターンに無理やり当てはめて類型化することをパターンを使うと表現している人がいるのか
785 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 02:59:15 ] おまいはすっこんでろ
786 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 03:10:49 ] >>784 はほとんど宗教じみているな
787 名前:デフォルトの名無しさん [2005/07/11(月) 03:14:46 ] GHGH
788 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 03:36:40 ] >>771 そーゆー前向きな活動は本来、 ML上で署名付きで行うべきものではないか? その署名が偽りであったとしても、誰も気付かないのだし。 匿名掲示板で本音のぶつかり合いを期待するのは、 虫のいい考えだと思う。blog立てろよ(オレモナー
789 名前:788 mailto:sage [2005/07/11(月) 03:43:05 ] 特に2ちゃんは、平日昼間から深夜まで例の粘着が ・情報システム板 ・プログラム技術板 ・プログラマー板 ・ゲーム製作板 ・セキュリティ板 他 を常時巡回して荒らしをやっているんで、 多くの人が、ここではもうコミュニケーションが機能しないものとして見放している。 考えても見ろよ、あれだけあちこちで話題になっているRubyのスレが この板に一個もない。原因は何故だと思う? 例の粘着とおぼしき人物が「Rubyキチ」とかいうコテハンで何年もしつこい荒らし行為を行って、 さすがのMatzも手を引いたからだ。 こんなゴミタメで、鬱憤晴らしと気まぐれな独り言以外、何ができようか? なんちゃって
790 名前:788 mailto:sage [2005/07/11(月) 03:46:34 ] >>771 ちょっと考え直してみたら、俺もよくわけの判らんレスを付けてしまった。 貴方が「気楽に議論できるデザパタスレが欲しい」と思うのなら、立てたらいい。 掲示板のスレ立て制限以外、誰もスレ立てを制限する事などできないのだから。
791 名前:デフォルトの名無しさん [2005/07/11(月) 07:20:45 ] >>780 その割には本スレで馬鹿と盛り上がってたじゃんw
792 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 07:39:21 ] 馬鹿はどこにでもいるし、どうしようもない議論で盛り上がるさ。 こっちでもあっちでもまともな議論はできていない。
793 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 07:48:40 ] >>792 >こっちでもあっちでもまともな議論はできていない まともな議論なんて無駄。 デザパタ自体の存在意義について触れた時点で荒らしがはじまる。
794 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 08:24:22 ] きっと、役立たずの人間にとっては、 世の中に役に立つ概念があるというだけで、 腹が立つんだろうね(藁
795 名前:771 mailto:sage [2005/07/11(月) 14:41:48 ] >>790 新しいスレ建てるほどのことではないんだよね。 ほぼ重複だし。叩かれそう。なのでやっぱりいいです。 >>792 馬鹿でも、どうしようもない議論でもいいじゃないか。 そこをおまいのような理解してる奴がうまく啓蒙してあげればいいんじゃないか >>793 まあ馬鹿同志、無駄な議論してるんで生暖かく見守っててくだされヽ(´ー`)ノ
796 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 14:55:10 ] こっそりとID導入待ち
797 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:11:19 ] IDが必要なのはこのスレだけだろ。他の板逝ってやれ。 他の人が迷惑する。
798 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:28:47 ] プログラムに関係ないことをプログラム板以外でやれと?どっちが迷惑だか。
799 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 15:30:24 ] プログラムのことを、だ。
800 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 16:53:59 ] じゃあ、ID出てしかもコテハン専用のプログラム板作ってもらえよ。 お前のルールに他の人間を全部従わせるつもりか。カス。
801 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 17:03:49 ] クオリティ低いな
802 名前:デフォルトの名無しさん mailto:sage [2005/07/11(月) 17:41:48 ] >>797 >IDが必要なのはこのスレだけだろ。 そうでもない。
803 名前:デフォルトの名無しさん [2005/07/12(火) 23:36:08 ] 隔離スレに来てる肯定派のアフォども、元気か。 本スレ盛り上げろよな。まあ、おまえらアフォどもには無理だろうけど。
804 名前:デフォルトの名無しさん mailto:sage [2005/07/12(火) 23:45:43 ] 必要って言うか、なんていうか。 こんなやり方あるんだね、みたいな。そんな軽い気持ちで使えばイイんじゃねーの? ほとんどの場合でそのまま使えねーんだし。
805 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:21:37 ] >>803 お前ほどアフォではない。残念。
806 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:24:52 ] >>803 おまいほど暇人でわない
807 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:35:21 ] >>803 元から話題が無い(涙
808 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:41:35 ] >>807 まぁ話題がない、などと言う奴は中身からっぽなんだろうが。 Martin Fawlerの一連の著作やら、DSLやMDAとの絡みやら、 設計レベルのパターン言語について語るべき事はたくさんある。 問題は、書き込みが少ないこと。
809 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 00:42:58 ] Fowlerな。 あと、書き込み少ないって、某荒らしが粘着してるネタスレと比較しての話だ。 某荒らしが一切書き込みをやめてくれれば、また盛り上がれるスレだと思うよ。
810 名前:デフォルトの名無しさん [2005/07/13(水) 01:16:57 ] >>805-809 やはりお前らアフォどもに本スレを盛り上げるのは無理ってことだな。 隔離スレで内容のない話をしてろ、アフォども。
811 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 02:14:11 ] >>810 勝利宣言か。本当に日本人ですか?
812 名前:デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:08:14 ] 盛り上げるもなにもデザパタ使ってる奴なんてハナっから存在しない。 信者だって本当に実在しているのかも疑問。
813 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 11:18:53 ] >>812 >デザパタ使ってる奴なんてハナっから存在しない。 という事にしないと、理解できない自分がカワイソス、と。
814 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 11:40:11 ] 井の中の蛙もいいところ
815 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 12:57:25 ] こないだつかった。
816 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 20:00:39 ] 俺なんか飯のときにも使ってる
817 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 21:14:38 ] >>815 シングルトンはもういいってw
818 名前:デフォルトの名無しさん mailto:sage [2005/07/14(木) 21:44:28 ] >>817 君がそれしか知らないのは判ったから。
819 名前: != 815 mailto:sage [2005/07/15(金) 00:47:16 ] >>817 このスレの住人ってくだらない煽りヤロウばっかりだな('A`)
820 名前:808 mailto:sage [2005/07/15(金) 01:30:19 ] 同意。つか、これが例の情報システム板のスレでバカなレスばかり付けている「出張32」ですよ
821 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 07:45:18 ] >>819 オマエモナーw
822 名前:819 mailto:sage [2005/07/15(金) 09:59:55 ] >>820 いや、あの、きみの>>808 の一行目のレスするあたり対してレベルが変わらない気がス('A`) きみのその一言がなければ、おお。とか思った。思われただろうに。 つか、>>820 自体のレスも対してレベ(略 >>821 (゚∀゚)オウヨ!!
823 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 11:06:37 ] >>817 Abstract Factoryでした。 まあこれも使いやすい方なので じまんにはならんでしょうけど!
824 名前:デフォルトの名無しさん mailto:sage [2005/07/15(金) 14:35:21 ] >>821 釣られて出てくる「くだらない煽りヤロウ」。
825 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 18:36:19 ] ふと思い立ったんだが、アンチデザパタさん達の中でも、 interpreter パターンを知らずに使ってる人は意外と多いかもしれない なにせ、 Window_X = 120 Window_Y = 100 とかの初期化用スクリプト組んで、config.ini って名前付けるけでも interpreter の思想は受け継がれているからな 【この程度の事で interpreter パターンなどと勿体ぶった言い方を俺はしたくないですが】
826 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 21:32:52 ] >>825 お前は本当になにもわかってねぇウンチングスタイルだな。
827 名前:デフォルトの名無しさん mailto:sage [2005/07/17(日) 22:26:33 ] はぁ。インタープリタ・パターンねぇ。 再帰下降型パーサなら簡単に書けるけど、 正規表現のように状態遷移マシンつかったり、 JavaやCのようにあるていど大きな規模の構文を効率的に扱うには、 ちょっと寸足らず・・・ つか、実装は別の方法でやって、表面的なインタフェースはinterpriterパターンといったところか。 ってGoFがゆってた
828 名前:825 mailto:sage [2005/07/18(月) 18:30:54 ] っていうか interpreter パターンって 『処理内容のハードコーティングを避け、必要ならカスタマイズ可能に』 ってのが第一条件で、別に実装方式は問わなかった筈 その気になれば BF を組み込む程度でも interpreter になりそうで
829 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 18:35:17 ] BFでカスタマイズする処理系スゴス
830 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 22:39:54 ] BF?! BNF (Backus-Naur Form)じゃなくて?
831 名前:デフォルトの名無しさん mailto:sage [2005/07/18(月) 22:48:10 ] BF pc8.2ch.net/test/read.cgi/tech/1036013915/l50
832 名前:デフォルトの名無しさん mailto:sage [2005/07/19(火) 00:19:44 ] Boy Friend うほっwww
833 名前:デフォルトの名無しさん [2005/11/24(木) 02:13:02 ] MVCとかって本当に必要なの? 開発ってか設計がめんどうなんだけど・・・
834 名前:デフォルトの名無しさん mailto:sage [2005/11/24(木) 08:00:24 ] >>833 VCしかないシステムの拡張やらされた時には前任者に殺意を覚えたぞ。
835 名前:デフォルトの名無しさん mailto:sage [2005/11/24(木) 08:35:41 ] >>833 一度、プログラマが10人以上いるプロジェクトで すべての処理を一つのクラスにつっこむ実装をしてみるとわかるよ
836 名前:デフォルトの名無しさん mailto:sage [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 って知ってる? mailto:sage [2005/11/24(木) 19:03:03 ] >>837 調べる気のない人は 一生解らないままでいて下さい。
839 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 01:16:05 ] >>838 ヒドス
840 名前:デフォルトの名無しさん [2005/11/27(日) 08:33:23 ] >>839 デザパタ信者ってこんなのばっかだよ。 教えないんじゃなくて「知らない」or「自分の勝手な解釈で覚えたと思い込んでる」から説明なんてできない。 もし、説明なんかして他の人間と解釈が違っていたら、自分が理解していないことがばれちゃうから、 そういう危ない橋は渡らないのが奴等の処世術。 デザパタなんてオブジェクト指向すら無視してるんだから、当然オブジェクト指向すら理解してない。 で、なんだかんだ苦しくなると「デザパタは全く新しい〜」とか御馬鹿なこと言い出す始末。 これが前スレからの流れ。
841 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 08:49:45 ] /: ∧∧ / : (,,゚Д゚/ : _ / つ/) _ : 〜(⌒)__) /| ,, :  ̄ ̄ ̄ ̄ ̄|/,,, 〜〜〜〜〜〜〜〜〜〜〜
842 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 15:34:19 ] >>837 ==>>840 による自作自演か。 >>838 の言うとおりなんだけどね。 ちょっと調べればMVCで実際に設計する方法がわかるのにね。
843 名前:デフォルトの名無しさん [2005/11/27(日) 16:04:25 ] >>838 ==>>842 による自作自演か。 >>840 の言うとおりなんだけどね。 ちょっと調べればMVCで実際に設計する方法がわかるのにね
844 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:29:00 ] まてまて 調べても理解出来なかった というパターンもありうる。
845 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 17:33:38 ] >>844 我々は選ばれた人間なのですね!
846 名前:デフォルトの名無しさん mailto:sage [2005/11/27(日) 22:59:43 ] 一人で書くなら不要 一人神グラマがいれば、そいつを基準に周りがまねたら良いから不要 一人ではまだ頼りない感じの人達をまとめ上げるために必要なものだ
847 名前:838 mailto:sage [2005/11/28(月) 12:18:29 ] >>843 > >>838 ==>>842 残念ながら違いますよ。間抜け。 > ちょっと調べればMVCで実際に設計する方法がわかるのにね 判っているなら、そうしなさい。
848 名前:839 mailto:sage [2005/11/30(水) 23:48:07 ] >>844 調べてわかったけど釣り発言してみよう というパターンもあり、えない >>845 ! >>847 オトナゲナサス
849 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/12/01(木) 07:53:24 ] あのころのおれならMLですまーとにかいたんだけどねw
852 名前:デフォルトの名無しさん mailto:sage [2005/12/04(日) 21:08:41 ] strategy パターンって単なるコールバックじゃんwww
853 名前:デフォルトの名無しさん mailto:sage [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 名前:デフォルトの名無しさん mailto:sage [2005/12/09(金) 10:59:08 ] 釣り宣言キタコレ
857 名前:デフォルトの名無しさん mailto:sage [2005/12/10(土) 00:21:15 ] まあ 隔離スレなんだから、こんなんばっかだろ。 頭のいい奴は、つられたりしないわけだから 気をつけてればいいのさ
858 名前:デフォルトの名無しさん [2005/12/11(日) 17:38:28 ] 852>strategy パターンって単なるコールバックじゃんwww 同感です。昔、GOF 本を読んでクラスを使って実装した strategy パターンのコードを単純化して言ったら、関数ポインタの設定値の切り替えだけになっちゃいました。 それから GOF 本を真剣に読む気持ちがなくなりました。
859 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:58:58 ] >>858 デザパタの存在意義が「技術ブレークスルー」だと勘違いしている 馬鹿がまた一人。
860 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:59:31 ] >>852 ,858 デザインパターンに過剰な期待をしていないか? 「単なる○○じゃん」「同感」という発言は、 デザインパターンの目的・役割を取り違えてないか? デザインパターンは、別に 「そこらのエンジニアが考えつかないような素晴らしい夢のパターン集」 でもなんでもないぞ。 誰でもやっている・よく使われる設計手法に名前を付けてカタログ化したものでしかない。 エンジニア間の共通認識化・共通語化するのが目的。
861 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 18:14:57 ] 指きたす同様デザインパターンって言葉を使いたがる人たちがいるだけだろ
862 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:33:05 ] 例えばJavaDoc に ・・・ このクラスはGoFの○○パターンの××です. @see □□ @see △△ とか書いて有ればクラス図見なくても設計意図と構造が解る ってのもデザインパターンとして用語と設計が定義して有るおかげよね.
863 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 19:40:58 ] >>862 ぶっちゃけ言いたい。 構造が分かっても用途が分からないドキュメントは糞。
864 名前:デフォルトの名無しさん [2005/12/11(日) 20:16:20 ] >とか書いて有ればクラス図見なくても設計意図と構造が解る  ̄ ̄ ̄ ̄ >構造が分かっても用途が分からないドキュメントは糞。  ̄ ̄ ̄ ここでもエンジニア間の共通認識化・共通語化をする必要がありそうだな
865 名前:デフォルトの名無しさん [2005/12/11(日) 20:24:19 ] デザインパターンは、単なるカタログです。 共通的に使える設計で出てくるパターンは、 資産化しなさいよーという教えです。
866 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 20:28:27 ] 完全にデザインパターンにマッチする方が少ないんじゃない? 適用できるなら適用すればいいだけかと
867 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:01:21 ] >>863 詭弁のガイドライン 6.一見、関係がありそうで関係のない話を始める 16.全てか無かで途中を認めないか、あえて無視する 17.勝手に極論化して、結論の正当性に疑問を呈する あたりか
868 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:02:12 ] >>863 >構造が分かっても用途が分からないドキュメントは糞。 そんな当たり前のことを偉そうになに突っ込んでるんだよw
869 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:23:54 ] >構造が分かっても用途が分からないドキュメントは糞 まんまデザパタのことだな。
870 名前:デフォルトの名無しさん mailto:sage [2005/12/11(日) 21:27:25 ] …………俺、爆弾投下しちゃったっぽいな
871 名前:デフォルトの名無しさん mailto:sage [2005/12/26(月) 18:26:38 ] で、隔離スレが出来たら本スレがほんとに落ちちゃったわけか・・・ ここのアンチの人ってオブジェクト嗜好だよね。 憂鬱本読んでわかった気になってるパターンか。
872 名前:デフォルトの名無しさん [2006/02/21(火) 23:48:17 ] ちょっとデザインパターンからはずれてしまうんですが、 内部設計というか、プログラムのインターフェース設計ってどうやってます? 自分の経験では、共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。 簡単にいうと、こういうことです。 処理A、処理B、処理Cがあったとして、この3つは横展開の関係にあります。 3つも実装するのは大変なので、全て共通化して実装した(methodX(A)のように1つのメソッドで処理A〜Cを行い、どれを行うかは引数で指定する)。 ただし、メンテナンス作業を繰り返すうちに、If (処理Aの時のみ)...のような記述が増え、所謂マカロニソースになってしまった。 最初から処理A、処理B、処理Cは別々に実装すべきだった。 もちろん共通化すべき部分はあるので、下請け処理の共通部品を作るべきだが、 大元の処理は分けて実装すべきだった。 なんで、こんな失敗するんでしょう? 最初からA〜Cはほとんど同じ実装で済むと思っていたのが、 想定外のバグ、仕様漏れ、仕様変更等により、A〜Cが乖離した結果、マカロニ化してしまうんですね。 けれど、「想定外」のことを想定して設計なんてできないんですよ。 皆様どうやって設計してますか?
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 名前:デフォルトの名無しさん mailto:sage [2006/02/22(水) 16:53:47 ] そういや、デザパタスレなくなったな。悲しいことだ。
877 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:31:51 ] 昔から俺がやってた手法に勝手に名前つけられただけ
878 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 18:48:42 ] 未だに>>877 みたいな勘違いをしている奴がいるんだな。 名前を付けて普及させ、技術者間の共通認識にするところまでやってはじめて価値が出る。 どんなに優れた設計でも『オレ様パターン』じゃ意味ないんだよ。
879 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 19:12:09 ] >>878 その点において最大の価値がある。 >>877 全パターンをただ一人で考案した というのはとても信じられない
880 名前:責任転嫁マン mailto:sage [2006/02/24(金) 01:07:28 ] じゃあ、このスレで900を取った奴がデザパタスレ建ててくれ。 確か、5スレ目まで言ってたので、「【GoF】Design Pattern 6」とかで。
881 名前:デフォルトの名無しさん [2006/02/25(土) 00:39:28 ] まだ、こんなスレあんのか? デザパタなんて使ってる会社無いっていってるだろ。 だいたいGoF本なんてもう絶版だろ?ワロス オブジェクト指向が理解できない奴ほど食いつくんだよな いい加減にオブジェクト指向理解しろって オブジェクト指向言語がメジャーになってから何年経つんだよテラワロス
882 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:47:09 ] J2EEパターンを知らない奴がまた現れたのか。 JavaでサーバサイドシステムをJ2EEパターンを使わないで作ってる会社なんて無いよw
883 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 00:54:09 ] >>882 はぁ?なにそれ?
884 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 01:39:23 ] >>883 「?」の後は1つ空白を入れろ 話はそこからだ ただし」が続く場合はいらないぞ
885 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 02:42:03 ] >>884 うるせえよ 氏ね
886 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:49:04 ] >>883 言われたとおりに書いてればおkなドカタには不要なモノだよ
887 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 10:56:55 ] まあれだ、デザパタってのはプログラマに対して、 コンビニのアルバイトみたいに、接客対応マニュアル を用意してくれたってことでしょ
888 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 12:43:07 ] デパガがトイレに行く事を棚卸してきますとか言うだろ? 共通の認識がないとこういう符丁は成立しない。デザパタも似た様なもんだw
889 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:16:18 ] 一人プロジェクトでメンテも自分以外やらない、つー場合でもメリットある? あるなら本でも読んでみようという気になるかも
890 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 18:35:05 ] >>889 こうしてこっちはあーしてこういう風に作ろう が これしよう と単純に考えられる ライブラリでデザインパターンになってるものがあるから、それを簡単に理解できるようになる
891 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:02:37 ] 考察段階でつまずいたり時間がかかったりすることは ほとんどないしなあ。今ひとつ食指が動かない
892 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:24:15 ] pc8.2ch.net/test/read.cgi/prog/1140795650/2 , -‐−-、 ヽ∧∧∧ // | . /////_ハ ヽ< 釣れた!> ハ レ//j け ,fjlリ / ∨∨V ヽ h. ゚l; ハイイト、"ヮノハ // |::: j 。 /⌒ヽヾ'リ、 // ヾ、≦ ' . { j`ー' ハ // ヽ∧∧∧∧∧∧∨/ k〜'l レヘ. ,r'ス < 初めてなのに > | ヽ \ ト、 ヽ-kヾソ < 釣れちゃった!> . l \ `ー‐ゝ-〈/´ / ∨∨∨∨∨∨ヽ l `ー-、___ノ ハ ´ ̄` 〈/‐-、
893 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 19:42:26 ] >>891 考察段階でつまずくんじゃなくて、考察内容自体を短縮するんじゃないか?
894 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:53:19 ] 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、 動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの 思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて) こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う んだけど。
895 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:56:16 ] >例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、 >動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの >思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて) 入るわけない 誰がそんなこと言ったの?
896 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 20:57:45 ] だから、それじゃあ学ぶ価値なんかないよ。一人でやってる限りは。
897 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:05:59 ] デザパタの使い道がわかっていない典型だ
898 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:30:33 ] だから一人プロジェクトでの効能をキボン
899 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:41:49 ] 10ステップの命令文を1つの関数にすれば、関数の名前だけで内容が一気に把握できる そういうことが本当に分からないなら勉強する気も起きないだろうしやんなくていい 釣りかな
900 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 21:51:18 ] そんなことは百も承知だけど例えとしてそういうもんなのか? 無限の関数名が出来そうだけど
901 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:04:06 ] >>898 「こういうときはこうする」というチップス集としても役立つ。 自分で考える手間が減るだろ? 専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは 機能として実装するだろ? そういう部分で「よくやる手法」としてのチップス集にはなる。 あるいは機能の重複をどう効率よく実装するか、とか。 ・・・無理矢理かな?
902 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:11:07 ] なんねぇんじゃん。 変数名をプロジェクトで決まった用語のローマ字方式でつけてて 開発の途中でダサいって理由で英語で付け変えた変数名も、 誰も読めないって理由で結局対応表が必要になった。 これはデザパタにもいえることだけど余計な手間増やしてない? みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。 アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ その説得力は無いも同然。 デザパタがいいという人間はデザパタを知ってる人間とかしか開発がしたくなくなるとかいう呪い付き。 やっぱり駄目じゃねぇのかな?
903 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:16:55 ] >>901 >専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは >機能として実装するだろ? この辺がどう効率的になるのかわかんないんだ。現状でもコーディング の時間以外はコストかからんしライブラリやフレームワークがあればそれ も軽減できる。 >「こういうときはこうする」というチップス集としても役立つ。 チップスの数って数えられるほどに押さえられるもんなのか? そういわれると問題に対して適用する手法はそんなにない ような気もしてきた。
904 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 22:59:21 ] >>900 無限ってことはないでしょ 使われなくなったら消えるし 良く使われる部分にそれがあると楽になるんじゃないか 良く使われる部分でもその名前が知られてなければしょうがないというのは…… まあ自分で考える時に使うということで gotoよりforループだ ってぐらいのものじゃないと意味がないってことか?
905 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:20:01 ] >>904 >gotoよりforループだ ってぐらいのものじゃないと意味がないってことか? そう。 プロジェクトで結構手間がかかるのは 個人個人の認識の仕方を確認し、それを共通認識までもってくことだからな。 その手間をぶっちぎって、「デザインパターン読んでください」なんて突き放してうまくいくわけがない。 中国語と英語を話す国に 「今日から日本語が母国語になります。ええ、決まったことですからしょうがないですね。」 なんてふっかける行為となんら代らない。
906 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:21:10 ] > ライブラリやフレームワークがあればそれも軽減できる。 それこそがデザパタの適用w
907 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:01 ] >無限ってことはないでしょ これはなんとなく分かるけど >使われなくなったら消えるし >gotoよりforループだ ってぐらいのものじゃないと意味がないってことか? スマンが何を言ってるのか不明。
908 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:22:12 ] たしかに日本語のテキストなんかもたくさん出てるだろうし、 勉強する環境やらお金やらは問題ないかもしれんだけどやるか?やらんだろ?
909 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:47 ] >> ライブラリやフレームワークがあればそれも軽減できる。 >それこそがデザパタの適用w おれデザパタとか意識してないよ。 こういうときはこれ(ライブラリでも手法でも)を使う、ってのは 大概苦労せずに出てくるけど
910 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:25:51 ] > アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ > その説得力は無いも同然。 わかってんじゃん。 > みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも > そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。 俺の周囲は常識としてあたりまえに知っているけどな。 デザパタを知らないDQNばかりの開発者だらけの現場だとそうなる。 ・・・とは言え、分野にもよるのだろう。 J2EEアプリの開発者達は知っていて当たり前。知らなければDQNと言われても仕方ない。 他の分野だとJ2EEアプリほどアプリ全体の作りがパターン化しないと思われるから デザパタが普及する必要性は低くなるだろう。
911 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:31:49 ] >>910 J2EEなんて狭い世界にしかいないからそんなんなんだよw
912 名前:デフォルトの名無しさん mailto:sage [2006/02/25(土) 23:54:14 ] データ構造には名前が付いてる。スタックだとかツリーだとかリストだとか? アルゴリズムにも名前が付いてる。バブルソートだとかクイックソートだとか? OODにも名前を付けてみた。それがデザインパターン。 >>905 デザパタがあるから不親切なのか?不親切な奴はデザパタの有無とは無 関係に不親切だぞ? もしデザパタがなかったなら、ソース読めと突き放されるだけだと思うが? 全部暗記しないと話にならない?ありえん。 全てのデータ構造を知ってるか?全てのアルゴリズムを知ってるか? 少なくとも俺が知る限り、そんな奴はいない。 重要なのは、名前は目次になるってこと。 名前を得られれば、その実装なり実装例なりを得られる。ないと困るだろ?
913 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:05:34 ] >>907 使われなくなったら消えるっていうのはそのままだ 誰も使わないデザインパターンは消え去るでしょ? 言葉と同じ gotoとforループは機能と認知度のことで例としてあげた gotoでforと同じ機能が実現できるけど、forを使う それは便利で、そして誰でも知ってるからか という話 そんなに分かりにくかったかな……
914 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:44:57 ] >>912 >ないと困るだろ? 別に困らない。 むしろ、勝手に名前をつけて共通認識にもなってないのに使ってくる奴のがウザイ。
915 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 01:58:36 ] 自分の知ってることが全て 俺が知らないことは言うな ってやつもウザイ。
916 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:15:27 ] >>915 でも、仕事でそういう状況のときってどうするのが適切なのかな? 例えば、 B:「これなんでこんな変な組み方してんの?」 A:「あ、ここはステートパターン」 B:「なにそれ?」 A:「デザインパターンという・・・というわけですよ」 B:「なんかよくわからないけど、そのパターンがどうしてここで使っててそれで間違った組み方じゃないって言えるの?」 A:「だから、デザインパターンの・・・はこういう・・・のときに使うのが・・・なわけですよ。」 B:「どして?さっぱりわかんね。そもそも、そのステートパターンとかよくわからないし。何がよくてどうしてそのパターンを使いたいの?」 ってなったときね。 ここで本を渡して「はい、自分で勝手に調べてね」っていうとすげーヤナ奴じゃない? 上司でもないのに変な用語使って勝手に仕事増やしてる痛い奴であることに間違いは無いよ。 やっぱり無難にそのパターンの詳細を説明することになると思うけどそれだと別にそのクラスの仕組みを説明すればいいんであって べつにパターンとかいう必要ねぇし。と思う。 これってデザパタ知ってる奴同士でも同じじゃね?
917 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:40:56 ] B:「これなんでこんな変な組み方してんの?」 A:「あ、ここはステートパターン」 B:「なるほどね」 - 完 -
918 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:02 ] >>916 それ、前提が間違ってるわ。 配列で済むとこにリスト使ってたら、そりゃただの馬鹿だろ? デザパタも同じで、不要なとこで使ってたらただの馬鹿だ。 試しにさ、リストを使う妥当な理由があるという前提の下で リストを知らない者にリストという単語を使う事なくそのデー タ構造を説明するというシチュエーションで話作ってみてよ。
919 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:42:14 ] J2EEってそんなに狭い世界なのか?
920 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 04:17:28 ] 自分はもっといろいろ知ってるんだぜ!って言いたいんだろw
921 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 05:09:22 ] >>916 クラスの仕組みを説明したときに、それにこういう名前がついてるっていえばいいんじゃないか? 名前の説明が追加されても大差ないし、次があれば楽に説明できる それとその例だとAさんが説明したのにBさんが分かってないようだが Aさんの説明が悪いか、Bさんに理解する気がないかのどちらかだ
922 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:14 ] >>918 916じゃないけどやってみた B:「これなんでこんな変な組み方してんの?」 A:「あ、ここはリスト構造」 B:「なにそれ?」 A:「要素をインデックスじゃなくて、次へのポインタで指すデータ構造です」 B:「……ああなるほど、これだとデータ挟んだり抜いたり、配列でやりにくいことが楽に出来るんだ」 例えが分かり易すぎて引き合いにはなりませんですた。 デザパタが物議をかもすのは、ひとつの名前に対しての内容が 人によってはアンバランスに感じるほど詰まってるからじゃねーの? おれはデザパタ知らん人間ね。
923 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 08:51:24 ] 共通の名前ってーのも一理あると思うが、デザパタって「システム」という大枠を どのように細分化していくかって話もあるだろう? (つまり境界線をどこに引くか) >>894 > 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、 > 動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの > 思考手法が手に入るの?(コーディングとかマンパワー的なものは除いて) そういった思考手法そのものが手に入るのではなく、そういった思考手法と他の機能が どのように連携するのかを考え、適切なクラス分割が行えるようになる。 例えば、将来的に音声認識アルゴリズムを(クラスを追加するだけで)ばっさり他のものと 入れ替えることが簡単に行えるようになるわけ。 > こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う > んだけど。 ソフトが行っている内容は考察するほどもない簡単なものかもしれんが、 将来どういった仕様変更があるのか(どの部分を入れ替えられるようにするのか)について は色々考えるべき点が多いぞ。
924 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:02:06 ] >>923 >入れ替えることが簡単に行えるようになるわけ。 別にデザパタ知らんでも簡単に入れ替えられるんだな。 >将来どういった仕様変更があるのか 仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。 つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな 組み方してるんだろう。 素直に組んでれば改変追加etc、何も問題ないと思うんだけど。
925 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 09:20:16 ] >>924 > 別にデザパタ知らんでも簡単に入れ替えられるんだな。 そういう人にとってはデザパタって「共通の名前」という以外の意味はないんでしょうな。 > 仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。 その「面倒くさいなぁ」ってーのはどんな感覚? Aという要求がBという要求に変わった時、クラスの「追加だけ」で対処できる? Aの機能を呼び出したりする部分を一切変更することなく、Bの機能を実現したクラスの 追加だけで対応できているんであれば、あんたはかなりの実力者だ。 > つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな > 組み方してるんだろう。 仕様変更が起こった場合、変更とは直接関係のない部分(上記で言うところのAの機能を 呼び出している部分)まで修正が及ぶため、そこも含めてテストをやり直さなければなら なくなるのが普通。 これによって工数が無茶苦茶増える。 > 素直に組んでれば改変追加etc、何も問題ないと思うんだけど。 客先からの要求ヒアリングでも、「どこに仕様変更が起こりそうか」なんてことは ほとんど聞けないのが実態。 素直に組むことで問題が解決される例はほとんどない。
926 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:14:54 ] >>925 >その「面倒くさいなぁ」ってーのはどんな感覚? 単に仕事が増えてゴルア。精神的な問題のみ >Aという要求がBという要求に変わった時、クラスの「追加だけ」で対処できる? クラスかどうかはともかく、変更の規模によって ・Aを多少改造(現機能も維持したまま条件判断で追加のケース) ・Aをまるまる残してBを追加。 関係ないけど、どっちのケースもAの動作はとりあえず残しておく。 元に戻したい時ってのは常にあるから。容量が厳しい場合はケースバイケース >変更とは直接関係のない部分(Aの機能を呼び出している部分)まで修正が及ぶ AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。 変えたところをテストするのはしゃーないじゃん まったく関係ないところはあたりまえだが変更など皆無。 >「どこに仕様変更が起こりそうか」予測できない だから、変更を許容せよ、がおれの組む時の一番頭にあること。 プログラムを仕事にしてから一番学んだのはそれだね。
927 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 11:58:16 ] ソース管理ツールくらい使ってるだろうし、 戻すなんて手間じゃないだろうに。 …じゃなくて。冷静になろう。 話がデザパタから微妙にずれてきてる。 これはニュアンス的にはリファクタリングのネタだよな。
928 名前:925 mailto:sage [2006/02/26(日) 12:11:13 ] >>926 > AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。 そうとも言えないんじゃない? AとかBとかの機能と、それを呼び出す部分のインタフェースをうまく設計すると AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は 無くなるわけです。 さらに、Aのインスタンスを生成する部分に工夫を加えておくと、設定ファイルを いじるだけでAのインスタンスでもBのインスタンスでも生成できるようになるん ですな。 コードに手を加える(修正する)必要が無くなるんです。 > 変えたところをテストするのはしゃーないじゃん その通り。 だから修正部分が減るとテスト工数が激減することになる。 > だから、変更を許容せよ、がおれの組む時の一番頭にあること。 デザパタ(というかオブジェクト指向原則の多く)が言っているのはまさにそこ。 変更を許容する以上、変更点を局所化することこそを考えるべきではないで しょうか?
929 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:14:07 ] >>927 > 話がデザパタから微妙にずれてきてる。 > これはニュアンス的にはリファクタリングのネタだよな。 いや、ずれてないと思うぞ。 デザパタを利用することでリファクタリングも楽になるという点で、関連はあるが。
930 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 12:22:05 ] >>927 スレ違いごめんよ >ソース管理ツールくらい使ってるだろうし、 >戻すなんて手間じゃないだろうに。 単純に戻すとかいう問題じゃなくて、どっちも使いたいとかなる 場合もあるからプログラム的に共存させておくことを念頭におい て作っている >>928 >AがBに変わったとしても、 もちろん外見が同じなら何も変更はしないよ。 ただそうじゃない場合もあるし。(まれと言えばまれ) まあ、 >設定ファイル それをもっと進めている。外見のインターフェースがまったく 変わったとしてもコードのビルドしなおしなんてやんない。 ビルドしなおすのはまったく新しい機能追加と 大好きな最適化やる時だけ
931 名前:925 mailto:sage [2006/02/26(日) 12:38:28 ] >>930 > もちろん外見が同じなら何も変更はしないよ。 > ただそうじゃない場合もあるし。(まれと言えばまれ) 外見(つまりインタフェース)を同じになるようにするってーのが、システムを設計する 際の肝であり、GoF本が主張している「インタフェースに対して設計する」ということで すね。 「そうじゃない場合もあるし」というのは、まだまだ精進する余地があるってことでしょう。 (とはいえ、完璧に予想するなんて、神にしかできないだろうが。w) そういった観点から見た場合、デザパタは「変化しそうな部分の外見(インタフェース)を 汎用的な形に変形するための設計をカタログ化」したものと言えるんじゃないかな。 デザパタを使うと無意味なクラスが多くできるとか、デザパタを用いて失敗したという のは、こういった変形を必要以上にシステム内に持ち込んだり、誤った変形をしてしまった 結果に起因するのではないかと言ってみる。
932 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 17:15:45 ] >>928 >AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は >無くなるわけです。 これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
933 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:37:56 ] >>932 > これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。 ふっ、、、甘いな。 テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう?
934 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 21:52:34 ] >これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。 ひょっとして、ここは笑いどころだったのか? ソースコードだけの話って、ソースコードいじると色々とたちの悪い問題が出てくるんだが。
935 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 22:08:04 ] というふうに、デザパタ肯定派でも意見の対立がある(・∀・)
936 名前:デフォルトの名無しさん mailto:sage [2006/02/26(日) 23:47:30 ] >>933 >テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう? そのテストってどうやるの? 何を証明すればキチンとした動作になってると言えるのかわからない。 とりあえず全パターン出して、今回の変更で変わる部分を抜き出さないとテストは終わらない。 そういうふうに人に説明しにくい仕組みしてしまうよりは、ベタで書いたほうが早いと思う。単純に。
937 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:46:03 ] 多分単体テストと結合テスト、外部テストがごっちゃになってるんだと思う。
938 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 01:48:05 ] テストの種別も組織によって違うしねw
939 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 02:58:03 ] >>937 それを含めて全パターンだしても>>936 のいってることは代わらないと思う。
940 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 06:41:21 ] 自動化できるところとできないところの切り分けができていないのかと。
941 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 07:48:49 ] >>936 > そのテストってどうやるの? > 何を証明すればキチンとした動作になってると言えるのかわからない。 そんなことを聞くあなたは、ひょっとするとテストの際、毎回全てのケースをテストしているのかい? (まぁ、xUnit 等をうまく使えば、そういったことも可能だし、効率もさほど低下しないだろうから、 毎回全てのケースをテストすることに対して否定はしないが。) 答えは色々あるだろうが、正しいインスタンスが生成されているかどうかを確認したいのならば クラスBのコンストラクタが起動された際にコンソールメッセージを出すようにするというのは 一つの手じゃないか? まぁ、この手の方法は組織によって向き不向きがあるんだろうけど。 それよりも >>932 は >>934 の言ってたソースコードを触った時の危険性を認識しなさ過ぎ。 たいていの厄介なバグは、新規機能に作り込んでしまうのではなく、新規機能を追加した時に 既存機能側をいじり壊して作り込んでしまうものです。
942 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 08:30:39 ] 交通事故と同じ。やるやつは繰り返す
943 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 09:12:00 ] かもな。 俺は絶対事故らない、、、とみんな思ってる。
944 名前:デフォルトの名無しさん mailto:sage [2006/02/27(月) 10:31:57 ] むしろ事故らなかったことはありませんが(プログラムの方だよん。 車の方はやばいと思って運転するのやめた)
945 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 03:01:40 ] >>926 の発言をみる限り、プログラミングはうまそうなので、 必要だと思わないのであれば別に無理して覚える必要はないんじゃない? 俺は面白かったから勉強したけど。 俺が得られたメリットは、コードの整理がうまくなったってことかな。 昔、色々コード書いてて、規模が大きくなればなるほど、整理の方法がわからず、 コードが汚くなることが悩みだったが、デザパタ覚えたことで少し改善した感じ。 あと「カタログ化して、みんなの共通の認識とする」っていうのはあんまメリットない気がする。 デザパタしらん人には無意味だし。ただの浮いてる奴としか見られない。
946 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 20:30:50 ] デザパタなくとも、プログラム上手くなればコード整理はできるけど デザパタないと、共通認識にはできないから俺はそっちの方が重要だと思う データ構造とアルゴリズム みたいな本がいっぱいあるけど クラス構造とアルゴリズム になるのがデザパタだろう どちらも丸暗記する必要はないけどな
947 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 22:12:30 ] 「デザパタしらん人には無意味だし。」ってのが正論としてまかり通るのが問題だ。
948 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:13:50 ] >>947 つーかもう本でてないしw 流行りも廃れたしw あのぶ厚い本を一冊読むことを強制するってのは流行らないと思うわ。 なんかもうちょっとお手軽なのじゃないとねぇ。
949 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 01:23:54 ] >>948 もう少し本屋にいった方がいいと思う
950 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 06:29:12 ] >>949 オススメは何?
951 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 14:20:46 ] >>947 うーん、無理だろう。 プログラム勉強するようになっていきなりデザインパターン勉強する奴とかいないだろ。 「関数で処理を分けるのは、なぜ必要なんですか」っていうレベルからだろうし。 100人のプログラマがいても20人くらいしか知ってる奴は期待できないとおもう。 それを20人の都合で、80人に本よめっていうのはわがまますぎだと思う。 所詮たよれるのは自分です。なんつって。 >>948 まあ、とりあえず、デザパタは得て損はないと思うよ。 ただ全部が全部、よいパターン/読んで欲しいパターンだとはいえないんだけど。
952 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 15:17:11 ] 100人中100人が知っている必要はないだろう。 100人いたら半数以上は言われたとおりに部品製造していればいいコーディング担当だろうし。 設計を担当するアーキテクトチームなら常識的に知ってて当然だとは思う。 設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題。 使う・使わない・どこにどう適用するかは別問題として。
953 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 20:36:03 ] >>950 俺は結城さんの読んで覚えた、お勧め 読んではいないが、最近だと変なねーちゃん表紙のやつ評判よかったような
954 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 18:13:55 ] >>952 >設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題 なんで?
955 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 20:08:18 ] >>954 アーキテクトにとっては、良し悪し・使うべき/使わないべきまで含めて知ってて当然の知識だからな。 デザパタも知らない、共通の概念のない非常識な人間が寄ってたかって設計したシステムなど、お里が知れるわw
956 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:34:37 ] そうか「当然の知識」か。そして「共通の概念」か。 ・・・それは思いこみであって現実の正しい認識であるとは思えないけどね。
957 名前:デフォルトの名無しさん mailto:sage [2006/03/05(日) 23:39:43 ] >>955 具体的な根拠がなにも示されて無いな。 本当に理系の人間なのかどうか疑問 >>956 ね。 なんか思い込み強いよね。
958 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:19:40 ] デザパタのように今や古典とも言える超メジャーな設計上のスキームを 「知りもしない」ってのは、土方コーダーならともかく アーキテクトとしては激しく問題があると思われ。 知った上で使う・使わないは別問題だがな。
959 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 00:43:55 ] 知ったつもりになって使ったつもりになる。 形式だけ学んだので不必要に濫用する。 このパターンが少なくない気がする。 デザパタの粒度ってアーキテクトレベルなんかな? どちらかと言うとプログラミング(詳細設計から下)レベルに思うんだが。
960 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:35:25 ] >>958 デザパタなんていつ必須事項になったんだか。 オブジェクト指向でもなんでもないし。 すっげどうでもいい部分の寄せ集めじゃん。 >知った上で使う・使わないは別問題だがな これでデザパタは使えないって結論に至った人間をどうやって説得するのか?
961 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:43:31 ] >>959 > 知ったつもりになって使ったつもりになる。 > 形式だけ学んだので不必要に濫用する。 > このパターンが少なくない気がする。 ここのところは同意。 しかし、デザパタの真意はアーキテクトレベルにあると思うぞ。 それをコーディングの定石集だと誤解しているヤシが多すぎ。 >>960 > オブジェクト指向でもなんでもないし。 オブジェクト指向原理主義ですか? 90年代前半の呪縛に捕らわれてますな。
962 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 13:23:31 ] >>960 >すっげどうでもいい部分の寄せ集めじゃん。 そうかね?JavaとかC#とかの標準ライブラリ(java.langとかjava.ioとか)は、 デザパタを基準に作られてると思うけど、あれもすっげどうでもいい使えないライブラリかね? あれらを見たときなかなかいいもんだと感じたもんだが。 まあ、良いか悪いかの感じ方は、人それぞれとは思うけどね。 >>961 俺も>>959 と同じくプログラミングレベルの概念だと思うのだが、 デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、 あそこまで本の中身がソースコードだらけにはならないと思う。
963 名前:962 mailto:sage [2006/03/06(月) 13:28:47 ] まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。 アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。
964 名前:961 mailto:sage [2006/03/06(月) 15:08:20 ] >>962 > 俺も>>959 と同じくプログラミングレベルの概念だと思うのだが、 > デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、 > あそこまで本の中身がソースコードだらけにはならないと思う。 デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという ことを明確にしている点が肝なんだと考えています。 そういった意味では、本の中身をあそこまでソースコードだらけにしてしまう必要はなか ったんじゃないかな。 (クラス図とせいぜい状態遷移図があれば十分だったはず。) 実は「GoF本の翻訳がイマイチで理解しづらかった」→「みんなソースコードに頼ろうと する」というだけなのではないかと。 (かの結城氏もJavaで書かれてないから判りにくいんだと誤解していたし。) そもそもデザパタがプログラミングレベルの概念だったとしたら、もっと色々な言語が シンタックスシュガーとしてデザパタ構文を採用してるんじゃないか? > まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。 > アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。 アーキテクトほどいい加減な言葉もそうそうないと思う。 あれってプログラミングが設計工程に属していることを認めたくない連中が、 (彼らの言う)設計工程とプログラミング工程のギャップを埋めるために作り出した 役割なんだと思うな。
965 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 18:49:58 ] >>964 >デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという >ことを明確にしている点が肝なんだと考えています。 よく考えると切り離す意味が全くわからないな。
966 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 19:20:35 ] >>965 > よく考えると切り離す意味が全くわからないな。 変更に強くするため。 いくらクラスを作って「カプセル化」だと叫んでも、インタフェース部分に変更が あると、そのクラスを変更した時、山火事のように影響度が飛び火して広がって いく。
967 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:00:30 ] >>966 変更に強いかどうかってそんなに重要かぁ? 俺には設計と実装がマッチしてない糞みたいなソースができるような気がするぜ。 つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが 一致してることの方が何倍も大事なことのように思えるんだけど。
968 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:01:59 ] ああ、言いたいことはさ。 変更されたらそれに合わせて変更が必要になってもいいんじゃないの? ってこと。 てゆうか、設計が変更されたのに実装がそのまんまっておかしいw
969 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:16:10 ] >>967 設計と実装はそんなに離れない 離れたらその設計参考にされてない 変更に強いって言うのは変更箇所が少ない、影響範囲が小さいってこと 釣りなのかマジなのか……
970 名前:962 mailto:sage [2006/03/06(月) 20:21:39 ] >>967-968 まあ、デザパタを覚えることで利点を感じなければ覚える必要は無いと思うけどね。 あと、「設計変更による変更に強い」というよりは、 設定ファイルや、オプションによる処理の変更には強くできるね。 一行変えるくらいで後々の処理を大きく変えることができるとか。 設計変更されたら実装かえるのは当然だぁね。
971 名前:962 mailto:sage [2006/03/06(月) 20:35:48 ] >>967 >つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが >一致してることの方が何倍も大事なことのように思えるんだけど。 こりゃ同意だな。実装はともかく、設計(インターフェース)は、 万人がイメージしやすい&理解しやすいことが望ましい、というかそうすべきであると思う。 デザパタのほとんどのパターンは、実装の変更を容易にすることを目的としているかな。 例えば、データを読込&保存する処理をしたい場合に、保存する手法は何でもよいというとき、 その中身の実装は、普通にファイルで保存したり、DBにしたり、XMLにしたり、 と後々実装を変えたい、または、コマンドラインオプションや設定ファイルによって変えたいと 思った場合の変更に強くすることができるかと。
972 名前:デフォルトの名無しさん mailto:sage [2006/03/06(月) 20:44:47 ] フト思ったんだが、、、 ひょっとしたらアンチデザパタってヤシは、設計時に無茶苦茶にデザパタを 適用した結果、設計結果とみんなのイメージが乖離してしまったという 暗い過去を持っているんジャマイカ?
973 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:18:43 ] そこで結城先生の登場ですよ。 >デザインパターンの目標の1つは、プログラムを再利用可能にすることです。 >つまり、どうやってプログラムを「部品」として再利用するかを考えているのです。 >ですから、プログラム例を「完成品」として見るのではなく、今後「機能を拡張していくもの」 >「変更を加えていくもの」として見るようにしましょう。 > ・どのような機能が拡張される可能性があるか? > ・その機能拡張を行うときに修正が必要になるのはどのクラスか? > ・修正が不要なのはどのクラスか? >このような観点でデザインパターンを見ると、理解が深まるでしょう。
974 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:36:28 ] >変更に強いかどうかってそんなに重要かぁ? 極めて重要だと思う。特に脱ウォーターフォールを標榜する今後のJavaの開発形態としては特に。 と、いうかJavaの抽象化フレームワークやJunitやEclipseの強力なリファクタリング機能が 何の為に存在するのかといったら、やっぱ「変更しないのが前提」、っていうウォーターフォールの一番駄目駄目な 部分を徹底的に唾を吐き、"いかにソースを良くしていくか"、"「動いているソースは駄目ソースでも触るな」じゃなく 「ガリガリ直してどんどん洗練されたソースにリファクタリング」していくか"、 "余計なドキュメント製造に掛かるコストをカットする事で生ずるリスクをどこで吸収できるか" 等にあるわけで。 変更に強い、というのは客の仕様を満たすのと同じくらい重要だと思う。
975 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:49:56 ] 世の中には二種類のアーキテクトが居る。 一方のアーキテクトはアンチパターンを認識・検出・除去することが出来る。 残りのアーキテクトは日々新たなアンチパターンを生産することが出来る。 後者多すぎ。
976 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 03:20:30 ] >>969 いや、だから、どんな変更に強いってのか謎。 変更したらさ、設計がかわるんだよね? ここはいいよね? 影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね? 普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。 要はメインじゃなくて付加価値みたいなもんでしょ? それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる プログラムってのはそれだけで気持ち悪いと思うんだ。 おそらく、みて理解のしやすいソースにはなっていない。
977 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:30:31 ] >>976 > いや、だから、どんな変更に強いってのか謎。 「十分予測できるが、現時点では詳細が不明な変更」ですな。 そこを押さえずに何でもかんでも変更可能にしてやろう、あるいはとにかくデザパタを 適用しようという発想がいかんのです。 > 変更したらさ、設計がかわるんだよね? > ここはいいよね? ここはOK。 マクロな視点で見れば必ず設計は変わる。 しかしミクロな視点で 構成要素を一つずつ見ていき、影響が出る構成要素の数を極力減らす努力が 必要。 > 影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね? 変更内容が判らないというのであれば、その通り。 しかし裏を返せば、変更の匂いが するところに対してデザパタを適用できるということ。 伝家の宝刀はここぞという時にしか抜いてはならない(とはいえ意外と多かったりするがなw)。 > 普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。 それはダウト。 現状の静的なスナップショットを取っているだけのデザイナは、松竹梅で 言えば梅レベル。 そもそも現状のスナップショットをいくら睨んで見ても、そのどの部分が 変わりそうなのかといった情報は読みとれないものだ。 つまり「普通にそれぞれのクラスを 閉じこめるように作っていく」だけでは全然不足というわけだ。
978 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:31:26 ] (続き) >>976 > 要はメインじゃなくて付加価値みたいなもんでしょ? システムを作るだけ作ってそのまま逃げるような開発をするのであれば、現状のスナップ ショットのみを用いて設計してもいいかもしれない。 (開発中に入ってくる要求変更と戦う 必要はあるが。) しかしその後の保守を考えると、変更に対する強度は極めて重要な ことになるのだ。 > それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる > プログラムってのはそれだけで気持ち悪いと思うんだ。 > おそらく、みて理解のしやすいソースにはなっていない。 おそらく君が過去に接したシステムというのは伝家の宝刀を濫用したものなんだろう。 デザパタを適切に使用した場合のクラス図は、現状のスナップショットがどうなっている のかという情報だけでなく、今後どういった部分が変化しそうなのかという情報もはっきりと 伝える判りやすいものになるのだ。
979 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:33:10 ] >>976 > 要はメインじゃなくて付加価値みたいなもんでしょ? > それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる > プログラムってのはそれだけで気持ち悪いと思うんだ。 > おそらく、みて理解のしやすいソースにはなっていない。 俺も最近流行りのDIコンテナを利用した実装とインタフェースを分ける設計をみて そう感じることがよくある。 IDEのデバッガでも追いづらいし、開発の効率を下げている一面もあるよな。 クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで やりやすい点ぐらいか・・・ オブジェクト指向本来のインタフェースの用途ではなく、 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
980 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 07:51:27 ] >>973 > そこで結城先生の登場ですよ。 > > >デザインパターンの目標の1つは、プログラムを再利用可能にすることです。 > >つまり、どうやってプログラムを「部品」として再利用するかを考えているのです。 注意すべきはここでの「部品」,「再利用」という表現ですな。 A, B, C, D, E, F, Gという7つのクラスで構成されたシステムがあったとする。 普通に「部品」というと、例えばCとかDというクラスを思い浮かべ,「再利用」というと そういったクラスを他のシステムから利用することを想像してしまいがちになる。 しかし、デザパタのいう「部品」、「再利用」は違う。 デザパタでいう「部品」というのは、「Cというクラスから見た場合はA, B, D, E, F, Gと いう6つのクラス」であり、Cが変更になった時にこれら6つのクラスに影響を与える ことなく、「このシステム自体から見て6つのクラスを再利用する」ということだ。
981 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 08:01:01 ] >>979 > クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで > やりやすい点ぐらいか・・・ ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに 対して変更があった場合、保守コストが引き下げられるということを意味しているはず。 > オブジェクト指向本来のインタフェースの用途ではなく、 > 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。 あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう? 実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので あるべきなんじゃないかい?
982 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:17:18 ] >979 DIコンテナ使わないチームと使ったチームで比べられればいいけどね。 俺はもうDIコンテナなしの開発は考えたくないです。 まぁDIスレ(typoしてるが)でやるのが適切な話題だし、 あっち過疎ってるから盛り上げて欲しいってのが本音。
983 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 16:36:13 ] >将来そのクラスに >対して変更があった場合、保守コストが引き下げられるということを意味しているはず。 タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは よくあるのかな?
984 名前:962 mailto:sage [2006/03/07(火) 18:00:51 ] >>982 DIコンテナって使うとソース見やすくなったりとかするの? DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね? 設定ファイルの情報を反映させたいときは再起動が必要みたいだから、 ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。
985 名前:981 mailto:sage [2006/03/07(火) 19:20:50 ] >>983 > タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは > よくあるのかな? 意外とよくある。 新規開発の際、客先がちゃんと要求を出せてない部分が 開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき るぞ。 その都度リファクタリングしてもいいんだが、新規開発時だとユニット テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。 どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。
986 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:29:23 ] 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明 デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
987 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 19:55:01 ] インタフェース設計レベルから変更を余儀なくされる要求が多いな。
988 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 20:10:10 ] >>976 極端から極端に走らなくてもいいじゃん 仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして 隠しオプションでどんな仕様にも即対応! みたいのはそりゃだめだ デザパタは問題の解決法として書かれていて その問題があるときは割と的確な粒度の解決だと思うがどうだ? あれでもまだ余分かな?
989 名前:981 mailto:sage [2006/03/07(火) 20:23:57 ] >>986 > 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明 > デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う 結構大変だけどね。 客先が「XXがYYという風に変わりそうだ」なんて自分から教えて くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます?」といった 聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。 で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに 入る。
990 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:54:24 ] >984 この話題、DIスレにコピペしてもフォローしてくれますか? (スレタイの意味での)デザパタとは全然関係ないと思うし。 >ソース見やすくなったりとかするの? それはないです。 >988 >的確な粒度の解決だと思うがどうだ? 当方もそういう意識ですね。 そういう意味でもアーキテクトと言うよりは、 プログラミングレベルの話題だと思う。 フレームワーク作成チームが知っておくべきプラクティス。
991 名前:962 mailto:sage [2006/03/08(水) 01:21:50 ] >>990 >この話題、DIスレにコピペしてもフォローしてくれますか? いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。 ありがとう。あっ、でもやっぱり聞いてみようかな。 >>986 漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、 プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。 ただプログラムのやることは同じだけど実装を変える。 例えばパフォーマンスアップのために仕様変更するというのであれば、 それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。
992 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 01:40:16 ] つーかさ、 ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に その処理が記述してあってほしい。(関数とかクラスとか) そうでないと他の人間の書いたソースなんて追えない。 降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。 すげー面倒臭い。どうにかしてくれ。 単純に、ただ単純に書いて欲しい。 それだけ・・・それだけなんだ・・・orz
993 名前:986 mailto:sage [2006/03/08(水) 01:43:31 ] >>991 たとえ話になるけど 「100Vコンセントがあれば、殆どの電化製品に対応できる」 とか考えて実装してると、 いざ 「実は、この家電アース線がついてるんだけど……」 ってなったときに、コンセント側も改造しなくちゃいけないな、 って話をしてみた。 アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。 ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、 どこまで変更を予測するか〜って話だ。 ちなみに↑は Strategy を想定してみた。 解決策としては、Adapter が使えれば手っ取り早い。 どうでも良い。次ぎスレたのむ。
994 名前:962 mailto:sage [2006/03/08(水) 02:08:21 ] >>992 基本的には単純なものは単純に書くよww 必要になったときにしかデザパタは適用しないよ。 処理をたらいまわしにしている人のソースに悩まされてるの?たまにいるわなぁ。 デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。 必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。 やるべき処理を素直にコードにすることが一番の解だというのに。
995 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 02:22:21 ] マ板的な話題になってしまうが とあるベンダが俺様フレームワークを作成して 基本設計の説明に加えて 「ここはあのパターン、ここにはあのパターンを使ってる。」 みたいなことをのたまって 最後にパターン名と適用の有無からなる 2列23行の表を見せて、こんなにたくさん○が付いてますよ (使った(ことになってる)パターンを○でカウントする。) みたいな感じで胸を張ってた。 手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。 アンチパターンの表を作るのは意味があるかも知れん。 なんか盛り上がってきたし次スレ欲しいなあ。
996 名前:デフォルトの名無しさん mailto:sage [2006/03/08(水) 03:02:51 ] 手段のためには目的を選ばない。
997 名前:962 mailto:sage [2006/03/09(木) 03:33:36 ] では私が建てよう。ひっそりと深夜に。
998 名前:962 mailto:sage [2006/03/09(木) 03:39:13 ] >新このホストでは、しばらくスレッドが立てられません。 >またの機会にどうぞ。。。 「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz 建てて誘導したいけど残り2レスしかない・・・。
999 名前:デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:28:57 ] 次すれ 「【GoF】デザインパターン 6 pc8.2ch.net/test/read.cgi/tech/1141846078/
1000 名前:デフォルトの名無しさん mailto:sage [2006/03/09(木) 04:29:41 ] コピペミスで「が残ってたorz
1001 名前:1001 [Over 1000 Thread] このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。