〔隔離〕デザインパターンは本当に必要か？〔スレ〕
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2005/06/21(火) 19:09:560002デフォルトの名無しさん
2005/06/21(火) 19:13:40乙
確かにデザパタそのものについての話が全然無かったしな最近。
0003デフォルトの名無しさん
2005/06/21(火) 19:15:53ここは隔離スレなんで建設的な話は期待しないほうがいいですよ
0004デフォルトの名無しさん
2005/06/21(火) 19:41:13デザパタがいいって人はとりあえずオブジェクト指向理解してる（つもり）なの？
0005デフォルトの名無しさん
2005/06/21(火) 19:48:220006デフォルトの名無しさん
2005/06/21(火) 19:48:58C++
0007デフォルトの名無しさん
2005/06/21(火) 20:02:16いや、ネタはいいから（笑）
0008デフォルトの名無しさん
2005/06/21(火) 20:04:12なんて答えて欲しかったんだ？
デザパタなんて使ってるぐらいだから、
一度もC++でオブジェクト指向で設計して組んでみたことなんでしょ？
0009デフォルトの名無しさん
2005/06/21(火) 20:13:32MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
どうしてもキショイコードになる。
0010デフォルトの名無しさん
2005/06/21(火) 20:32:56ＭＳのデザパタはC#とか見てあげてください。
0011デフォルトの名無しさん
2005/06/21(火) 20:46:31まさかネタじゃなかったのか？
デザパタを否定するくらいstrictなOO人間がよりにもよってC++を肯定するなんて信じられないんだが。
0012デフォルトの名無しさん
2005/06/21(火) 21:00:08読めないから恨み節でデザパタ否定してただけでしょ？
いくら否定してもテンプレートがなくなる事はないのに、無駄
足掻きだな。
0013デフォルトの名無しさん
2005/06/21(火) 21:17:22OOPLがC++しかない時期があったのだ
0014デフォルトの名無しさん
2005/06/21(火) 21:20:390015デフォルトの名無しさん
2005/06/21(火) 21:24:53今はいろいろあるじゃん、なんで昔の話？
0016デフォルトの名無しさん
2005/06/21(火) 21:43:58デザインパターンを否定していないやつはオブジェクト指向を理解していないとか、
ほんとうにオブジェクト指向で設計するとデザインパターンなんて使わないとか
いうようなことを言っていたけど、おまいのオブジェクト指向論を講師してくれんかな？
オセロプログラムでもいいから具体例だしてさ。
0017デフォルトの名無しさん
2005/06/21(火) 21:46:52えー。向こうで死ぬほど書いたじゃん。
あと、設計の話だよー。
具体例なんてでねぇぞー。
ソースコード期待してるなら帰った方がいいぞ。
0018デフォルトの名無しさん
2005/06/21(火) 21:48:08聞くポイントがまじぃんだよ。
ソースが欲しいわけじゃなくて、要は開発の流れみたいのが知りたいだけじゃねーの？
0019デフォルトの名無しさん
2005/06/21(火) 22:06:16ならリンク張ってよ、それくらいできるでしょ？
>あと、設計の話だよー。
>ソースコード期待してるなら帰った方がいいぞ。
オセロプログラムの設計の話でしょ？
しかも何でもいいみたいだよ？
0020デフォルトの名無しさん
2005/06/21(火) 23:10:56げー。
俺が探してくんの？ｗ
誰か知らん奴のためになぜにここまで苦労せにゃならんのかｗ
0021デフォルトの名無しさん
2005/06/21(火) 23:57:34向こうで死ぬほど書いたんだろ？何言ってんの？
0022デフォルトの名無しさん
2005/06/22(水) 00:00:150023デフォルトの名無しさん
2005/06/22(水) 00:13:000024デフォルトの名無しさん
2005/06/22(水) 00:21:25・オブジェクト指向で開発
・たくさんオブジェクト指向で開発
・なんか同じ様な設計パターンにならね？
・デザパタ誕生
かと思ってた
まぁオブジェクト指向しなくてもデザパタは適用できるんだけどさ
0025デフォルトの名無しさん
2005/06/22(水) 00:26:44まあ、一番大事なのはこれ↓だな。
>ＯＯＰなんだけどもなにもアプローチが
>基本から脱線しまくってるじゃねーか。
>どんなに複雑だろうとなんだろうと、オブジェクト指向はオブジェクト指向だ。
>基本理念は
>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。
掻い摘んでいうと、
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向であって
パターンを覚えさせるデザインパターンはアプローチがおかしい
と、そういうこと。
0026デフォルトの名無しさん
2005/06/22(水) 00:32:320027デフォルトの名無しさん
2005/06/22(水) 00:36:08おまえまじでいってんのかよｗ あんまプログラム組んだこと無いだろｗ
本当にそんな稚拙なOOPの定義で、１作品完全に組めるならやってみろｗ
素人がｗ
0028デフォルトの名無しさん
2005/06/22(水) 00:38:44ゲームなどのクライアントアプリケーションやスタンドアロンアプリケーションならそれでも行けるよね。
DB連携のWebアプリはどうする？
DB検索と更新機能のデザインパターンを使わない設計の具体例を教えてくれ。
0029デフォルトの名無しさん
2005/06/22(水) 00:39:00>
>現実にあるものの構造をそのままプログラムに反映することで
>誰がみてもその構造を把握できやすいようにすること
>
>だったはずだ。
どこでこんなこと習ったんだ？
教えてもらった先生に文句言ったほうがいいぞ。
0030デフォルトの名無しさん
2005/06/22(水) 00:41:10もうこの一言で「デザインパターン」を知らないことは明白。
0031デフォルトの名無しさん
2005/06/22(水) 00:41:38組めるよ。
なんでできないの？
0032デフォルトの名無しさん
2005/06/22(水) 00:41:46同意
典型例に名前を付けただけだよな
0033デフォルトの名無しさん
2005/06/22(水) 00:41:470034デフォルトの名無しさん
2005/06/22(水) 00:42:390035デフォルトの名無しさん
2005/06/22(水) 00:44:11web関連やったことないから知らんけど、
基本的に対象物の構造をそのままクラスに反映するわけだから
DBとやらの構造に根本的な欠陥が無い限り組めると思うよ。
それがオブジェクト指向の強みだからね。
逆にDBとやらが腐ってたら設計も腐るだろうね。
0036デフォルトの名無しさん
2005/06/22(水) 00:44:33講師もバカだしなｗ
超使えねぇ解雇された元同僚が某専門学校で講師やってるよｗ
0037デフォルトの名無しさん
2005/06/22(水) 00:47:28もしかしたら、超天才かも。
そんなわけ無いか...
0038デフォルトの名無しさん
2005/06/22(水) 00:47:28やったこともないのにできるなんてよく言えるな。
おめでたい奴だ。
0039デフォルトの名無しさん
2005/06/22(水) 00:53:580040デフォルトの名無しさん
2005/06/22(水) 00:54:06いえる。
だから、マ板にいる奴等ってすげー偉そうじゃん。
それは自分が対象物の構造さえ理解できれば確実に
プログラムを組めるということが確信できているから。
で、オブジェクト指向覚えた奴同士で設計に関する議論ってみたことないでしょ？
そりゃする必要がないから。
なんたって確実。
あとは対象物の理解がどれだけできているかってただそれだけ。
人に聞いてわかるもんじゃないし、あとは自分がどれだけ勉強するかってだけ。
0041デフォルトの名無しさん
2005/06/22(水) 00:54:53セッション管理やトランザクション管理の仕組みも自分で設計するのかな？
CommnadパターンもServiceLocatorも使わないから、ビジネスロジックの呼び出しもベタ書き？
プレゼンテーション層/ビジネスロジック層/EIS層を分けて考えることもしないんだよね？
DAOパターンやDTOパターンもSingltonも拒否？
拡張性もなく、リクエストの度に大量のオブジェクトを生成して恐ろしくパフォーマンスの低いシステムを作りそうだ。
0042デフォルトの名無しさん
2005/06/22(水) 00:56:38デザインパターンとかで縛りを受けたくないと...
オブジェクト指向云々は単なるこじつけでさ
0043本ｽﾚ住人
2005/06/22(水) 00:59:26その本良書かもしれないけど、あんまポピュラーじゃないから、
ちゃんと説明する努力をしないと伝わらないよ。
俺なんて本ｽﾚで調査しまくり、翻訳しまくりだ、最近orz
0044デフォルトの名無しさん
2005/06/22(水) 00:59:26避けがちになるかもしれないから縛りに感じることもあるか。
それより伝達の欲求がないなら覚えるだけ面倒にしか感じないだろうな。
一人で設計してるだけならそう思うかも。
0045デフォルトの名無しさん
2005/06/22(水) 01:03:43拡張性も糞も無い。
俺はただあるべき構造をただクラスに反映させるだけ。
そのために対象物の構造を理解する必要はあるけどね。
要は対象物の構造が破綻さえしてなきゃ大よそのもんは組めるってこと。
0046デフォルトの名無しさん
2005/06/22(水) 01:06:31マジですか？
仕様の変更とかあったら組みなおすの大変じゃない？
0047本ｽﾚ住人
2005/06/22(水) 01:06:57あと、こっちは隔離スレだから、
ちゃんとした話は本ｽﾚ
【GoF】デザインパターン5
http://pc8.2ch.net/test/read.cgi/tech/1119158274/
でやった方がいい。
ところで、こんな荒れてるスレでパターン・コレクション名だけこそっと書いて
そのまま無反応になるのは、なにかのオマジナイですか？
0048デフォルトの名無しさん
2005/06/22(水) 01:12:02Webシステム開発は仕様変更が激しいからねー。
そんなんじゃ、手戻り多くてあっという間にあぼーん確定だね♪
0049デフォルトの名無しさん
2005/06/22(水) 01:22:291.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
不完全な表現の例：
多重継承、
時間的な状態変化、
計算不可能な対象物/概念、
非常に複雑な対象物/概念
etc.
もしあらゆる事柄を表現しシミュレーションする方法があるのなら、
科学者の仕事の大半はいらなくなる
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて扱いやすい簡易的な表現を得る事である。
要するに、抽象化こそが知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいＰＣ上のソフトウェアの「移植」とか「エミュレーション」程度の事に過ぎない。
3. このように対象物の構造と、ソフトウェア上の表現・・・ここではオブジェクト指向モデル/プログラム
との差異を何らかの形で縮め、実用上問題がないように取り繕う技術が、
モデリングであり、設計であり、プログラミングである。
これは普通にソフトウェアを弄っている人間にとって、常識である。
0050デフォルトの名無しさん
2005/06/22(水) 01:23:05仕様変更による構造の変更を無理やり設計レベルで吸収しようとすると
だいたいドツボにハマる。
俺はいっそしっかり組み直してしまったほうがいいと考えるけど。（完全に変更の場合はね）
つか、そのまま残して置いちゃ駄目でしょ。
それに、あいまいな部分をあいまいに組んでおく手もないわけではないよ。
例えば、始め敵クラスの詳細が決まってないときは詳細が決まるまで
「敵」クラスとしてあいまいなままおいときゃいいわけだし。
んで、「敵」クラスの詳細が決まったら初めて「敵：スライム系」「敵：ゴブリン系」だの
その詳細を組みだしゃいいわけだしね。
２つの方法があってどっちか迷ってるときも同じ。あいまいなままどさっとおいておきゃいい。
汎用性をつけたいときも同じ、でもそれなりに大変ではあるよ。
逆にあんまり詳細に組み過ぎてもやっぱり駄目。ＲＰＧなんかでアイテム１つ１つにクラス作るわけにはいかないからねぇ。
ってこの辺は人によって方法は違うだろうし、どんな方法をとろうがその人の自由だな。
まあ、本質にかかわる話じゃ無い。
0051デフォルトの名無しさん
2005/06/22(水) 01:30:33ちょっと小出しに話してよ。
レスつけずらいよ。
1ってなんで不可能なのかさっぱりわからないんだけど。
0052デフォルトの名無しさん
2005/06/22(水) 01:37:11変更に対して強い設計を可能にするデザインパターンもあるんだがそれは無視？
まぁ・・・あれだ。
完璧な設計などまずありえないし、お尻がキッチリ決まってる仕事の場合は
設計にそれほど時間をかけられないし、深くは追求するつもりはないけど。
# 書いているうちに余計なおせっかいな気がしてきた
005349 一部訂正。結局駄文だけど本質は突いているつもり
2005/06/22(水) 01:39:231.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
オブジェクト指向では不完全な表現しか得られない事象の例：
多重継承、
時間的な状態変化、
etc.
一般的に、不充分な表現しか得られない事象の例：
非常に複雑な対象物/概念
計算不可能な対象物/概念、
記述不可能な対象物/概念
etc.
もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
大半の科学者は仕事をする必要がなくなる。
(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。
3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
モデリング/設計/プログラミングの中心的な作業であり、
そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。
0054デフォルトの名無しさん
2005/06/22(水) 01:40:03なんすか？
質問があるなら簡潔明瞭に済ませてね。
長々と議論する時間はもうないんで。
0055デフォルトの名無しさん
2005/06/22(水) 01:41:190056デフォルトの名無しさん
2005/06/22(水) 01:41:40この人はビジネスロジックとデータモデルの設計はできるが、それだけ。
プレゼンテーション層、EIS層の設計と実装はムリだね。
定石とかフレームワークという概念が皆無。
0057エリート研究開発すぁ
2005/06/22(水) 01:45:551996-1997当時にほぼ独力 (ただし関連文献や技術書、GoF、各種MLをROM捲り)
で作れたけどね。
0058デフォルトの名無しさん
2005/06/22(水) 01:46:59どんなアプリでもほぼこれでOKなのに、それでも毎回オレ様オリジナル設計するの？
無駄な努力にしか思えない。
http://java.sun.com/developer/technicalArticles/J2EE/patterns/J2EEPatternLanguage.gif
0059エリート研究開発すぁ
2005/06/22(水) 01:48:00しがらみがほとんどないから、
フルスクラッチで大建築を作りやすかったんだけど、
もうあれから10年近く立ってるからなぁ。しがらみ過ぎてて最近始めた人は大変だなぁと思う
0060デフォルトの名無しさん
2005/06/22(水) 01:48:52作れるかどうかじゃなくて、これらの手法をパターン化していつも使うかどうか。
オブジェクト指向厨はそうはしないで、毎回毎回アタマをひねるらしいよ。
0061エリート研究開発すぁ
2005/06/22(水) 01:52:57歴史的経緯を見てきた漏れの意見を言うと、
J2EE Blueprint / J2EE Patternってイマドキ神格化されすぎてると思う。
リアルタイムでは、IBM BestPracticeやNetscape, WebLogicの方が
よっぽど進んでいたと思うよ。
更にマズイのは、J2EE反主流派のOracleなんて、
J2EE Pattern織り込み済みでもう必要としないＤＢ用フレームワークを使っている事。
そんな環境でも、木偶の坊みたいな人がJ2EE Patternを無理やり適用しようとする。
こういう奴を見ちゃうと、Pattern言語/Pattern推進派の努力にも限界があるのだと実感する。
0062デフォルトの名無しさん
2005/06/22(水) 01:54:20つーか、webアプリ組んだことないから知らないけど
同じものなら使いまわせばいいでしょ？
どうしてパターン使ってまで組み直すの？
オブジェクト指向＝毎回作り直す
とかかってに捻じ曲げて無い？
そんなことはいってないよ。
0064デフォルトの名無しさん
2005/06/22(水) 01:57:49貴方の主張は、設計を使いまわすのではなく、実装を使いまわすって話ね。
SI屋がやりそうな手口だ。
ところでここの住人は何時まで起きてるの？
明日も仕事だよね？
0065デフォルトの名無しさん
2005/06/22(水) 02:03:590066デフォルトの名無しさん
2005/06/22(水) 02:05:19よく使われる組み方をカタログ化しておいて、使い回すのがデザインパターンなんだけど。
0067デフォルトの名無しさん
2005/06/22(水) 02:07:26ん？毎回パターン使って組まなきゃならないものなのか？
って聞いてるんだけど？
要はソースレベルでの使いまわしは効かないの？
って話ね。
0068デフォルトの名無しさん
2005/06/22(水) 02:12:49もちろんフレームワークやライブラリは最大限利用するよ。
0069デフォルトの名無しさん
2005/06/22(水) 02:14:43いやいや、ソースレベルでの使い回しができるかできないかの話。
0070デフォルトの名無しさん
2005/06/22(水) 02:14:530071デフォルトの名無しさん
2005/06/22(水) 02:22:34使い回せるモノなんてほとんど無いんだけど。
各システム固有の要件に応じた処理とか画面と設定ファイルしか作らないので。
0072デフォルトの名無しさん
2005/06/22(水) 02:24:55おまえジェネリックプログラミングとかテンプレートって知らないのか？
0073デフォルトの名無しさん
2005/06/22(水) 02:32:59そっちのが望ましいのは確かだよな。Modern C++ Designの例のように。
ただし、デザパタ自体の存在価値がそれで無くなるわけではない。
あれは、プログラマ間の共通言語、意思疎通の道具としての存在価値が
もっとも大きいのだと思う。
パターン化されたデザインは、for (i = 0; i < 10; ++i);
のようなパターン化されたループのように、認識・理解しやすいし。
0074デフォルトの名無しさん
2005/06/22(水) 02:35:44あいやー。
再利用なんて無理にしないほうがいいと思うぞ。
できたらラッキーぐらいにしとけ。
0075デフォルトの名無しさん
2005/06/22(水) 02:40:47おまえ、STL(スタンダード・テンプレート・ライブラリ）って知らないのか？
0076デフォルトの名無しさん
2005/06/22(水) 02:43:15>そっちのが望ましいのは確かだよな。
ん？できるじゃん。なんでできないと思っているの？
0077デフォルトの名無しさん
2005/06/22(水) 02:44:310078デフォルトの名無しさん
2005/06/22(水) 02:51:35近いのはあるがあれはコレクションを使いやすくする程度の使い道しかない
0079デフォルトの名無しさん
2005/06/22(水) 02:51:40君らは概念がごちゃごちゃになってる。
多重継承を使うなよ。ってのもデザインパターンの一種なんだよね。
べからず集なので、アンチパターンとも呼ぶが。
でだ、デザインパターンって本を読むと、全体にトリッキーだったり、
（そうなってしまう前に設計で回避しろよーてな場合が多い）
Tipsレベルが多いんだ、の割には宣伝文句が大げさだから、
喧嘩になってる。さらに日本では訳や書籍が訳分からん言葉を
積極的に使うから更に悲惨な事態になってる。
「デザインパターン」と言う概念は否定しようも無い、だって既に
この世の中に有る物に名前を付けただけなんだから。
で、デザインパターンを批判してる者の言い分を聞くと、提出
されたパターンが汚いって話で、これはその通りだと思うし、
デザインパターンに、（デザイン）なんて言葉付いてるのが
日本人感覚だと惑わされるんだよね。
今のデザインパターンってのは、どう読んでもレスキューパターン
と言う名前の方がふさわしい。
0080デフォルトの名無しさん
2005/06/22(水) 03:06:05そんな上等なレベルじゃないよ。知りもしないくせに「パターン」で反応しているだけ。
標準ライブラリは当たり前に使っている癖に、なぜかメタレベルのライブラリだと拒否反応を起こす。
0081デフォルトの名無しさん
2005/06/22(水) 03:08:280082デフォルトの名無しさん
2005/06/22(水) 03:08:480083デフォルトの名無しさん
2005/06/22(水) 03:09:25"メタ"ライブラリと言えるだろ
0084デフォルトの名無しさん
2005/06/22(水) 04:06:020085デフォルトの名無しさん
2005/06/22(水) 09:47:37＞「デザインパターン」と言う概念は否定しようも無い、だって既に
＞この世の中に有る物に名前を付けただけなんだから。
この世の中にあるもの。
であるはずなのに、なぜ名前をつけてはいけないのですか？
ドラえもんという存在がいて、名前がなかったらなんて呼べばいいのか。助けてドラえも〜ん。
0086デフォルトの名無しさん
2005/06/22(水) 11:26:50日本人の英語力のなさまで面倒みきれない
0087デフォルトの名無しさん
2005/06/22(水) 14:31:370088デフォルトの名無しさん
2005/06/22(水) 14:36:45>要はソースレベルでの使いまわし
なんだ、プログラミングパターンは使ってるじゃん。
それの抽象度を上げたのがデザインパターン。
使いまわすときに、多少変更して使った事ないか？
0089デフォルトの名無しさん
2005/06/22(水) 15:49:13デザインパターンなんてものは、口出しできないけど口出したいって思ってる
バカがひたすら持ち上げてるだけ。
0090デフォルトの名無しさん
2005/06/22(水) 16:07:46てかゴミパターンも有るってことで。
SINGLETONパターンなんか、本当にゴミだと思うし。
0091デフォルトの名無しさん
2005/06/22(水) 16:09:30クライアントやスタンドアロンしかやったことない奴はそう思うのだろう。
サーバサイドでは普通に使うけどね。
0092デフォルトの名無しさん
2005/06/22(水) 16:13:54SINGLETONは普通に使うよ。GoF本の言うSINGLETONパターンを
ゴミと言ってるだけ。
0093デフォルトの名無しさん
2005/06/22(水) 16:25:38それには同意。俺はDIコンテナにSingletonインスタンスの管理をさせてるから
ああいうコーディングはしない。
0094デフォルトの名無しさん
2005/06/22(水) 16:34:47だよねー。
あのコーディングのどこにメリットが有るのか小一時間といつめたくなる。
0095デフォルトの名無しさん
2005/06/22(水) 16:49:560096デフォルトの名無しさん
2005/06/22(水) 17:00:10うんだ。てか、ＳＩＮＧＬＥＴＯＮパターンには、初期化されてないインスタンスを
呼ぶ危険性まであって、アンチパターンの方が似合てると思うんだ。
0097デフォルトの名無しさん
2005/06/22(水) 17:01:060098デフォルトの名無しさん
2005/06/22(水) 17:05:01それはバグだろ
0099デフォルトの名無しさん
2005/06/22(水) 17:11:27ゴミデータになるらしい。あとSMP環境だともっとややこしい事になるそうな。
0100デフォルトの名無しさん
2005/06/22(水) 17:13:04それってC++の話？
0101デフォルトの名無しさん
2005/06/22(水) 17:14:200102デフォルトの名無しさん
2005/06/22(水) 17:16:550103デフォルトの名無しさん
2005/06/22(水) 17:19:220104デフォルトの名無しさん
2005/06/22(水) 18:22:05記事を見た記憶がありんす。
0105デフォルトの名無しさん
2005/06/22(水) 18:46:44GoF では環境に依存しないよう、あえて実装してないが
MT safe にするためには当然、排他制御しなきゃならん。
んなこたあパターンに限った話じゃない。
0106デフォルトの名無しさん
2005/06/22(水) 18:47:31きっと何処かで初期化されてるオブジェクトを、2度目の
生成するリスクをさけるにしては、リスクの方が大きい
と思うんだね。
デザインパターンてな考えかたは、認めるし、効果あると
思うけど、GoFにカタログ作らせるのは、不味いと思うよ。
全体にトリッキーなんだよ、奴らのカタログは。
0107デフォルトの名無しさん
2005/06/22(水) 18:52:01どのへんがトリッキーなのか具体的に解説きぼんぬ
0108デフォルトの名無しさん
2005/06/22(水) 18:59:33隔離スレなんだから、反証責任はデザパタのカタログを信じてる馬鹿の
方に有る.
0109デフォルトの名無しさん
2005/06/22(水) 19:00:24教えてあげないよっ、じゃん♪
0110デフォルトの名無しさん
2005/06/22(水) 19:21:520111デフォルトの名無しさん
2005/06/22(水) 19:33:04ModernC++Designにある安全で速いダブルロックチェックドなシングルトンさえも
いまは安全でなく、ReadMemoryBarrier()とWriteMemoryBarrier()を
つかってない時勢にそぐわないものになってるというおはなし。
0112デフォルトの名無しさん
2005/06/22(水) 19:36:18アレつかって切り離すというのが、ここ２〜３年の潮流
0113デフォルトの名無しさん
2005/06/22(水) 19:58:560114デフォルトの名無しさん
2005/06/22(水) 20:06:070115デフォルトの名無しさん
2005/06/22(水) 20:14:54寧ろ発言者の存在自体がトリッキー
0116デフォルトの名無しさん
2005/06/22(水) 20:38:450117デフォルトの名無しさん
NGNG0118デフォルトの名無しさん
2005/06/22(水) 21:05:000119デフォルトの名無しさん
2005/06/22(水) 21:11:00まぁ、お前らはゆっくりトロッキー辺りを目指せってことだな。
0120デフォルトの名無しさん
2005/06/22(水) 21:11:080121デフォルトの名無しさん
2005/06/22(水) 21:28:480122デフォルトの名無しさん
2005/06/22(水) 21:37:08>>25の方法って普通のオブジェクト指向でしょ
デザパタ使ってる人ってこれのどの課程でデザパタを使うの？
0123デフォルトの名無しさん
2005/06/22(水) 21:39:05>>25への反論
1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
オブジェクト指向では不完全な表現しか得られない事象の例：
多重継承、
時間的な状態変化、
etc.
一般的に、不充分な表現しか得られない事象の例：
非常に複雑な対象物/概念
計算不可能な対象物/概念、
記述不可能な対象物/概念
etc.
もしあらゆる事柄を表現し自動的にシミュレーションできる方法があるならば、
大半の科学者は仕事をする必要がなくなる。
(例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
2. オブジェクト指向に限らず、モデリングとシミュレーション、そして科学の肝は、
対象物をそのまま記述するのではなく、
特徴を捉えて、扱いやすい簡易的な表現を得て、その表現を操作する事である。
要するに、抽象化と記号的処理こそが、知性の最も重要な働きなのである。
抽象化を行わないオブジェクト指向プログラミングがあるとすれば、
それはせいぜいコンピュータ上のソフトウェアの「移植」とか「エミュレーション」程度の仕事に過ぎない。
3. このような、対象物の構造と、ソフトウェア上の表現(ここではオブジェクト指向モデル/プログラム)
の間にある差異を、何らかの形で縮めて、実用上問題がないように取り繕う技術が、
モデリング/設計/プログラミングの中心的な作業であり、
そのためのノウハウや経験則は、ソフトウェア・パターンとかプログラミング・スタイルとかイディオムと呼ばれている。
0124デフォルトの名無しさん
2005/06/22(水) 21:47:36「対象物の構造を〜」ってことを 25 は言っているけど、その切り出し方は無数にある
(例えばオセロで審判を導入するとかしないとか。審判を導入すると双方の不正を一元監視できたり)
んで、その切り出し方の一例としてデザパタを応用するというふうに俺は使っている
(デザパタは直接使用せず、応用として。改変なしでは絶対に組み込めないし、組み込みたくない)
0125デフォルトの名無しさん
2005/06/22(水) 21:48:36それはネタでしょ。
0126124
2005/06/22(水) 21:49:180127デフォルトの名無しさん
2005/06/22(水) 21:49:43上の方でどうぞ
0128デフォルトの名無しさん
2005/06/22(水) 21:50:320129デフォルトの名無しさん
2005/06/22(水) 21:50:38具体的にどうやって使うの？
パターンに当てはめる方法でいいの？
0130124
2005/06/22(水) 21:55:55当てはめはしない
俺が考えた構造と、デザパタで提示されている構造が一致したら 「お？このまま行っても平気か？」 って思ってる
ついでに、提示された構造を参考に、幾らか修正を入れる
要は、どんな下らない物でも良いから、自分の考えを支持してくれる物があれば良いんだな俺の場合
0131デフォルトの名無しさん
NGNGデザインパターンの本来の目的からは外れてる気がするが（ﾟεﾟ）ｷﾆｼﾅｲ
0132デフォルトの名無しさん
2005/06/22(水) 22:08:06何処に石を置けるのか知らなければ、審判はジャッジできない。
何処に石を置けるのか知らなければ、CPプレーヤーは戦略を立てられない。
石を置くとボードがどう変化するのかを知らなければ、審判はジャッジできない。
石を置くとボードがどう変化するのかを知らなければ、CPプレーヤーは戦略を立てられない。
さて、どうしましょう？と、>>124に話を振るのは筋違いだな。
さて、どうしましょう？
対象物の構造をそのままクラスとして反映させるのがオブジェクト指向と主張してた貴方！
上記の主張を前提に、クラス設計してみてちょいよ。
0133124
2005/06/22(水) 22:18:31いや、だから、対象物の切り出し方は無数にあるって例を出しただけで……
(審判は思いつき。妥当かどうかは考えてない。ちなみに、俺は大抵ボードが制約を持つように組んでる)
答えは無数にある。どれも正解かもしれないし、どれも不正解かもしれない。
0134デフォルトの名無しさん
2005/06/22(水) 22:18:42どうせ修正するなら、当てはめたほうが早いのではないでしょうか？
0135124
2005/06/22(水) 22:22:23正直速くない。部分的に一致させる事もあるけど、
サンプルで提示されている構造の使用価値はサンプルで提示されている程度のレベルでしかないと思っているし
ガチガチに当てはめると融通が利かない。妥協が必要
0136デフォルトの名無しさん
2005/06/22(水) 22:24:58「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていたあれですね。あの方法で組めばいいんですね」
というまどろっこしい会話を
「それsingletonね」
「はい」
というシンプルな会話にするためにあるのよ
0137デフォルトの名無しさん
2005/06/22(水) 22:28:07「ほら、あの処理あるじゃん。インスタンスをいっこに限定する方法」
「あぁ、以前のシステムでも使っていた Singleton ですね。あの方法で組めばいいんですね」
0138デフォルトの名無しさん
2005/06/22(水) 22:41:43１人のときは、全く役に立たないのでしょうか？
0139デフォルトの名無しさん
2005/06/22(水) 22:57:29かつて２ちゃんの粘着くんの議論を終結させるために、
そーゆー一見もっともそうな説明をした事がある。
で、同じ話を何回書き込んだら気が済むの？
0140デフォルトの名無しさん
2005/06/22(水) 23:00:09オブジェクト指向だの設計だのって、結局は具体的な事が言えない
から逃げる為の口上に使ってるだけじゃん。
0141デフォルトの名無しさん
2005/06/22(水) 23:09:37この人のあいかわらずソースを求める姿勢はどうにかならないものだろうかｗ
0142デフォルトの名無しさん
2005/06/22(水) 23:09:55煽り好きの>>140みたいなのは、リアルには付き合いたくない。
0143デフォルトの名無しさん
2005/06/22(水) 23:12:270144デフォルトの名無しさん
2005/06/22(水) 23:13:58具体的な何かでいい。とりあえず、上で出てるクラス設計なんてどう？
てか、言い訳多すぎ。
0145デフォルトの名無しさん
2005/06/22(水) 23:33:130146デフォルトの名無しさん
2005/06/22(水) 23:36:38俺はこの件に関して傍観者だが、
>>132の問題設定が問題の体を為していないのと、
せっかく>>123に挙げた矛盾点を取り込んでいないあたりに、
そこはかとなく素人臭さを感じた
0147デフォルトの名無しさん
2005/06/22(水) 23:38:51俺もこの件に関して傍観者だが、
具体性がないところにいつものアンチ臭さを感じた
0148デフォルトの名無しさん
2005/06/22(水) 23:55:48このままだとアンチの自作自演と疑われて縞馬
0149デフォルトの名無しさん
2005/06/23(木) 00:01:13Ｑ１．オセロを構成するのに必要なクラスを列挙せよ。
Ｑ２．Ｑ１で列挙した各クラスの役割について簡素に説明せよ。
Ｑ３．Ｑ１で列挙した各クラス間の関係(接続)について簡素に説明せよ。
0150デフォルトの名無しさん
2005/06/23(木) 00:04:29>>111が例示してくれたように、デザインパターンのGoFカタログは
致命的なんだよ。
「SINGLETONパターンで、」と会話が成立してる*つもり*になって
いて、片方は、スレッーフなカスタマイズSINGLETONを話し、
片方は、GoFベースのSINGLETONで話てたらOUTなんだから。
GoFのカタログを、バイブルのように使うのは、危険なんだよ。
使い方としては、アルゴリズム集みたいなイメージで使うべき
なんだよ。
0151いつものアンチ
2005/06/23(木) 00:06:37>>123は何がいいたいのかわからない。
>1.対象物の構造をそのまま、オブジェクト指向言語で完全に表現する事はできない。
の理由が
>オブジェクト指向では不完全な表現しか得られない事象の例：
> 〜略〜
> (例：宇宙誕生をオブジェクト指向言語でそのまま表現可能なら、宇宙論は不要になる)
なんだろうけど。
これは一体何がいいたいのかわからない。
とりあえず、手当たり次第レスつけると。
>オブジェクト指向では不完全な表現しか得られない事象の例
って書いてあるけど。
なんでここで「多重継承」なの？（このへんでもう相手にしなくていいかなーって思った）
多重継承を表現するって聞いた事ないんだけど。説明キボン。
んで次に書いてあるのが「時間的な状態変化」だけど。
なにこれ？意味がわからない。何がいいたいの？説明キボン。
で
>一般的に、不充分な表現しか得られない事象の例：
って書いてあるけど。
>非常に複雑な対象物/概念
どこまで複雑なのかは知らんけど根気よくやればできるんじゃない？
これはオブジェクト指向に限って表現できないものなのかなー。
>計算不可能な対象物/概念、
>記述不可能な対象物/概念
って書いてあるけど意味不明説明キボン。
ここでは１だけをとりあげたけど２と３なんて宇宙人の文でも読んでるのかと思った。ので意味不明。レス不能。
0152デフォルトの名無しさん
2005/06/23(木) 00:08:16共有メモリアクセスの排他制御が必要だっつう
ハードウェア・アーキテクチャ依存の御託はもう判ってるから、
さっさと>>149に応えたらどうかね
0154デフォルトの名無しさん
2005/06/23(木) 00:12:35やだよ。
だってそいつなんだかんだいってソースコードくれくれいってるのみえみえじゃん。
関わるとソース出さないとわめきたてるからレスつけない方がいいよ。
オブジェクト指向での設計からソースまでもってけないだけだろそいつは。
単純にクンフーが足りないｗ
0155デフォルトの名無しさん
2005/06/23(木) 00:13:390156デフォルトの名無しさん
2005/06/23(木) 00:16:370157デフォルトの名無しさん
2005/06/23(木) 00:31:250159デフォルトの名無しさん
2005/06/23(木) 00:38:420160デフォルトの名無しさん
2005/06/23(木) 00:40:41自作自演はバレてるから、さっさと>>149のクラス図出せ
0161デフォルトの名無しさん
2005/06/23(木) 01:02:42何、あげたって結局理解できるわけないんだから。
0163デフォルトの名無しさん
2005/06/23(木) 01:30:50バレバレの自演はいいから早く出せよ
0164デフォルトの名無しさん
2005/06/23(木) 01:40:37なんのために？
0165デフォルトの名無しさん
2005/06/23(木) 02:00:08いやだ、いやだ。
0166デフォルトの名無しさん
2005/06/23(木) 02:04:36荒らしも糞も無いだろ
隔離スレにマトモな議論期待するなって
0167デフォルトの名無しさん
2005/06/23(木) 08:36:26「デザパタってトリッキーだよな」
「どのへんが？」
「ﾑｷｰ！！！あ；ｄｌふぃうえあ；ｋじゃ；」
「オブジェクト指向がわかってればデザパタなんか設計に使わない」
「じゃあ○○をデザパタ使わずにどう設計する？」
「ぎえいぎえが；おい」
0168デフォルトの名無しさん
2005/06/23(木) 10:11:02本当に言い訳がましいなｗ
0169デフォルトの名無しさん
2005/06/23(木) 12:32:12もう完全スルーでいいだろ？
それはそれとして、このスレを何か有効に使う手はないものか？
0170デフォルトの名無しさん
2005/06/23(木) 13:13:420171162(通りすがり)
2005/06/23(木) 14:24:13自作自演じゃねーし。
>>123はごめん。素で意味不明。もっと文章力を付けてください。
で。オセロのクラス図？ごめｗｗｗｗダリｗｗｗｗｗ
0172デフォルトの名無しさん
2005/06/23(木) 16:08:160173デフォルトの名無しさん
2005/06/23(木) 19:19:58【デザパタ嵌り道】こんな失敗しますたスレヽ(`Д´)ﾉｳﾜｧｧﾝ【失敗談】
というのはどうか？
0174デフォルトの名無しさん
2005/06/23(木) 21:05:03017516
2005/06/23(木) 21:50:37あらかじめ断わっとくと、間違ってもソースコードはいらないから。
じゃあインベーダーの話をしよう。
>>25
>要はインベーダゲームを作るときの自機、敵、弾、このオブジェクトを
>そのままクラスという形でソースコードに反映することができること。これがオブジェクト指向でしょ。
>この基本は絶対に変わらない。
>プログラムに多少疎い人でも、インベーダゲームで自機、敵、弾に相当するクラスが
>無かったら真っ先に担当者を問い詰めることができる。
>これがオブジェクト指向の単純な利点だ。
でさ、まず自機、敵、弾のオブジェクト（クラス）を作るじゃん。
１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
でさ、１と２って同じ処理だよね。やってることは。
どういう風に設計・実装するのか知りたいわけですよ。俺は。
俺がやるならどうやってもデザインパターンを使わずには作れないから。
っていうより、俺の能力じゃあ、どう書いても、誰かがこれはデザインパターンでいうなんとかパターンっていうものですよ。って言うだろう。俺がそのパターン名を知らなかったとしてもさ。
0176デフォルトの名無しさん
2005/06/23(木) 21:55:29HitTest()は「キャラ」に実装するのが普通でしょう。
そのレベルではデザパタは別に関係ないし、例として適切じゃない気がするが。
0177デフォルトの名無しさん
2005/06/23(木) 22:10:50中学生かよ
0178デフォルトの名無しさん
2005/06/23(木) 22:12:38香りのするスレはここですか？
0179デフォルトの名無しさん
2005/06/23(木) 22:13:56オマイたちは本当に進歩しませんね。
0180デフォルトの名無しさん
2005/06/23(木) 22:29:20で、弾もあるよね。自分も敵も弾もそれぞれ座標（現在地）持ってるよね。
自分オブジェクトは１個かもしれないけど敵とか弾はたくさんオブジェクトがあるよね。
やっぱりループで回すよね。
ここまででデザパタは１つも出てこないのか？
>>177
じゃあ代わりに適切な例を上げて。
0181デフォルトの名無しさん
2005/06/23(木) 22:32:32俺が知りたいのはJ2EEアプリをJ2EEパターンを使わないで
アンチの主張する「オブジェクト指向設計」のみでどうやるのかに興味がある。
どんなに素晴らしいモノなのか、教えてもらいたいものだよ。
本当にできるならねｗ
0182デフォルトの名無しさん
2005/06/23(木) 22:41:18「弾」も「キャラ」から派生させれば問題なかろ。
もう少し条件つけんとCompositeだのFlyweightだのは出てこんぞ。
0183デフォルトの名無しさん
2005/06/23(木) 22:43:440184デフォルトの名無しさん
2005/06/23(木) 22:48:020185デフォルトの名無しさん
2005/06/23(木) 22:50:33helloworld.jsp
だけでいいんなら、別にパターンいらないぞ
0186デフォルトの名無しさん
2005/06/23(木) 23:14:01前提が間違ってる。
崇高なオブジェクト指向を信奉する彼は邪悪なJ2EEなんて使わない。
彼なら最初にAPサーバを書くところから始めるに違いないｗ
0187デフォルトの名無しさん
2005/06/23(木) 23:41:58だよな。「Servlet」というフレームワークや実装パターンのカタマリみたいな
プラットフォームは拒否るだろうからね。
0188デフォルトの名無しさん
2005/06/24(金) 00:25:490189デフォルトの名無しさん
2005/06/24(金) 00:39:140190いつものアンチ
2005/06/24(金) 01:03:27まともな質問が！
>>175
>１）自機に弾が当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>２）同じように敵が弾に当たったかどうかっていう判断をする処理をどっかに書くでしょ。どういう風に設計するの？
>
>でさ、１と２って同じ処理だよね。やってることは。
>どういう風に設計・実装するのか知りたいわけですよ。俺は。
これはオブジェクト指向で設計をしていれば、
オブジェクトの抽出のときに自機と敵が存在するフィールド（シーンのがいい？）のようなものができると思うから
そこに処理をかけばいいと思うよ。（なければフィールドクラスを作る。）
そのフィールドでの出来事だしね。
0191デフォルトの名無しさん
2005/06/24(金) 02:03:47その"フィールド"をメディエイターとしてするのかな？
あと、敵キャラの動きとかはストラテジーパターンで表現できそうだ。
あと「スコアカウンタ」から「敵オブジェクト」を
オブザーバーパターンを使って監視しておけば
得点の加算ができそうだね。
0192デフォルトの名無しさん
2005/06/24(金) 04:04:33死ねば？
0193デフォルトの名無しさん
2005/06/24(金) 07:07:21>あと「スコアカウンタ」から「敵オブジェクト」を
>オブザーバーパターンを使って監視しておけば
>得点の加算ができそうだね。
ん？これは何をやってるの？
もし、クラスのインスタンスの数を数えてシステムに反映させているなら
設計が悪いと思う。
0194デフォルトの名無しさん
2005/06/24(金) 10:28:59アンチの人にパターン名で解説しても話が通じんだろ。
>>193
「スコアカウンタ」のインスタンスが一つあって、
敵オブジェクト一つ一つにその「スコアカウンタ」のインスタンスを持たせておいて、
敵オブジェクト自身が死んだときに「スコアカウンタ」に点数を報告するって方法では？
設計悪いかな？漏れはまあいいんじゃないかなと思うけど。
0195デフォルトの名無しさん
2005/06/24(金) 10:46:38複数人同時プレーやもうすこし複雑なスコアシステムや設定によるスコアシステム自体の切り替えなどを考えると
シングルトンのスコアシステムに必要そうな情報全てを付加したスコア発生メッセージを通知するのがベター
嫌な設計だが
0196デフォルトの名無しさん
2005/06/24(金) 10:49:060197194
2005/06/24(金) 11:30:53複雑なスコアシステムだったとしても、
オブザーバに報告する内容をすこし増やせばいいんでない？
シングルトンだと、設定によるスコアシステム自体の切り替えはきつそうな希ガス。
0198デフォルトの名無しさん
2005/06/24(金) 21:25:27>敵オブジェクト自身が死んだときに
ゲームだとこの死んだときってのが微妙でね。
オブジェクト自身が本当に消滅したときなのか、
敵が死体で転がってる状態なのか、ってのは微妙でしょ。
だから、ゲームの仕様でインスタンスだのオブジェクトだのが出てくる人間の
プログラムはちょっと気を付けてみることにしてるｗ
もし、部下がインスタンスの消滅を見てゲームを動かしてるのを発見したら
俺の環境だと即組み直しｗ
まあ、将来の為。
あ、これはデザパタとかオブジェクト指向とか関係無いから。
0199デフォルトの名無しさん
2005/06/24(金) 22:33:12意味不明。
0200デフォルトの名無しさん
2005/06/24(金) 22:58:38そのままの意味だけど？
これ以上詳しくはできない。
0201デフォルトの名無しさん
2005/06/24(金) 23:05:28実際にゲームから消滅した＝オブジェクトの消滅
として設計され、管理されているなら
> インスタンスの消滅を見てゲームを動かし
ていても問題ないのでは？
0202デフォルトの名無しさん
2005/06/24(金) 23:06:020203デフォルトの名無しさん
2005/06/24(金) 23:07:08違うな。
どんな人間にも平気で嘘がつける度胸だ。
0204デフォルトの名無しさん
2005/06/24(金) 23:08:52それが駄目なことについて延々と語るつもりは無いな。
いいと思うなら自由にやってくれ。
0205デフォルトの名無しさん
2005/06/24(金) 23:09:460206デフォルトの名無しさん
2005/06/24(金) 23:10:320207デフォルトの名無しさん
2005/06/24(金) 23:11:14ゲームつくるのにデザパタはたいしていらんぞ
0208デフォルトの名無しさん
NGNG0209デフォルトの名無しさん
2005/06/24(金) 23:13:26まあ面接でちゃんと問い詰めればすぐバレるけどな
問い詰めちゃいかんらしい
0210デフォルトの名無しさん
2005/06/24(金) 23:14:51ポインタ使いまわしてて、消滅したはずのオブジェクトが復活する（したように見える）バグがでるに一票。
危険な道は避ける。
これがわからない人間にゲームプログラマは難しい。
0211デフォルトの名無しさん
2005/06/24(金) 23:17:34それはメモリ管理が出来ていないと言っているに等しいと思うんだが....
0212デフォルトの名無しさん
2005/06/24(金) 23:22:40メモリの管理はできてるでしょ。
メモリは破壊していないし、はみ出してもいない。
ただ、ポインタを使いまわしてしまっただけの話さ。
まあ、敵クラスを作った人間以外の人間が敵クラスを使うときは要注意といったところだね。
鉄則としてヌル判定をするポインタの使い回しは死んでもしないとか、
就業規則に書いておけば自分の責任にならなくて済むと思うよ。
0213デフォルトの名無しさん
2005/06/24(金) 23:24:05ん〜、結局同じな気がする。
一瞬、変更に対して強いかな？とも思ったんだけど、「必要そうな情報」に幅がないし
幅を出すと結局変更が両者に及ぶから変わらない。
キャラクタ→スコアシステム#update→キャラクタ#getScore
これ以外の流れというのがちょっと見えてこない。
>>197
元発言者の意図とかみ合ってるかは不明なんだけど・・・・・・
シングルトンをファクトリに生成させるパターンなら切り替えは可。
ScoreSystem scoreSystem = new ScoreSystemFactory(設定)
もう常套句すぎてアレなんだけど、こんな感じ。
0214デフォルトの名無しさん
NGNG隔離スレがパターンの話題で盛り上がって
本スレがスレッドストップとはこれいかに。（ﾟεﾟ）ｷﾆｼﾅｲけどな。
0215デフォルトの名無しさん
2005/06/24(金) 23:35:56それは、ダングリングポインタを参照してしまったということだから、
広義ではメモリ管理が出来ていないに等しいと思う。
本来、誰かが使っているならそのポインタは削除してはいけない。
ま、それを完全に保証することはしばしば非常に困難であったり
不可能であったりするのは事実だが
0216デフォルトの名無しさん
2005/06/24(金) 23:38:44インスタンスの生成、消滅の責任とタイミングをキチンとしないからそうなる
0217デフォルトの名無しさん
2005/06/24(金) 23:40:13あっ！orz
うるせ〜、超省略表記なんだよヽ(`Д´)ﾉｳﾜｧｧﾝ
0218デフォルトの名無しさん
2005/06/24(金) 23:40:14でも、この場合は誰の責任になるの？
敵クラス？敵管理クラス？メモリ管理クラス？
0219デフォルトの名無しさん
2005/06/24(金) 23:42:05でしょ。ポインタ頼みのステータス管理なんてやらないにこしたことないんだよ。
0220デフォルトの名無しさん
NGNGあんまりいろんな種類のゲーム知らないから単純なポイントの加算しか思い浮かばない。
0221デフォルトの名無しさん
2005/06/24(金) 23:45:10いや、それはいいすぎ....
まあ、参照関係が複雑な有向巡回グラフみたいになると手におえなくなりがちなのは
確かだが、常にそうだというわけではないし、参照カウンタで済む場合は
それを使うという手もある。
0222デフォルトの名無しさん
2005/06/24(金) 23:45:12ゲームの場合例えば敵キャラが消滅したら即deleteするのはありえない
ゲームタスクのループ内で自機が参照してるかも知れないし
他の敵も参照してるかもしれない
敵キャラに消滅フラグなりなんなり持たせて
ゲームタスクのループとは別フェイズで実際にdeleteなりメモリプールに戻すなりする
ってデザパタ関係ないな
0223デフォルトの名無しさん
2005/06/24(金) 23:45:31マージャンとかかな。
0226デフォルトの名無しさん
2005/06/24(金) 23:49:47でも本音ではしっかりステータス管理してもらったほうがいいでしょ。
よくないよ。議論に勝つ為のレスなんてつけるもんじゃない。
0227デフォルトの名無しさん
2005/06/24(金) 23:52:12なぜだッ！！
なぜ貴様に俺の心が読み取れるんだッ！！！
0228デフォルトの名無しさん
2005/06/24(金) 23:52:25マージャンとインベーダーの間で再利用するの？
されは流石に無理ないか？
0229デフォルトの名無しさん
NGNGあぁ、なるほど。
敵の消滅とかの話が出てたから、
シューティングっぽいゲームばかりを想像していたヨ。
>>228
マージャンだと点数の計算方法が複数ある…気がしたような気がしないような。
なので切り替えられると便利かもしれない。
0230デフォルトの名無しさん
NGNG0231デフォルトの名無しさん
2005/06/25(土) 00:16:23相変わらず僻みっぽい馬鹿だな。
とりあえず
http://pc8.2ch.net/test/read.cgi/tech/1119158274/14-15
のリンク先くらい読んでから煽れクズ
0232デフォルトの名無しさん
2005/06/25(土) 00:20:00すべきタイミングと、実際に消していいタイミングは必ずしも一致しない」
（通常後者のほうが遅い）
ということに尽きるのかな。
一言で言えるんだから、一言で言えばいいのに。
0233デフォルトの名無しさん
2005/06/25(土) 00:21:35Singletonの生成にはコンストラクターを使わない。つまり、getInstance()とかで生成する。
Factoryの目的は、どのサブクラスのインスタンスを生成するか、という点を抽象する事にある。
0234デフォルトの名無しさん
2005/06/25(土) 00:24:05static object m_Foo;
static object m_Bar;
static object getFoo() { return m_Foo; }
static object getBar() { return m_Bar; }
}
ではなぜまずいのでしょうか
getInstance()とかいちいちウザいです
0235デフォルトの名無しさん
2005/06/25(土) 00:30:390237デフォルトの名無しさん
NGNG注意点は一言で言えるが実装は一言で言えないぜ。
0238デフォルトの名無しさん
2005/06/25(土) 00:39:54流石に実装まで示せとは誰も言ってないじゃまいか。
0239デフォルトの名無しさん
2005/06/25(土) 00:41:23もう、日本は終わったんだよｗ
0241234
2005/06/25(土) 00:49:32てへ
0242デフォルトの名無しさん
2005/06/25(土) 00:53:55俺はアンチなんだけど
それって実体はいつできるんだ？
呼び出す前からできちまってる気がしねぇ？
0243234
2005/06/25(土) 00:56:37つか、それだけの問題で
まいかい
Singleton timpo = Singleton.getInstance();
bokkiage = timpo.invoke();
とかやるのはいやです。
0244デフォルトの名無しさん
2005/06/25(土) 00:57:060245デフォルトの名無しさん
2005/06/25(土) 00:57:15華麗なる素人スレ
0246デフォルトの名無しさん
2005/06/25(土) 00:58:12bokkiage = (Singleton.getInstance()).invoke();
0247デフォルトの名無しさん
2005/06/25(土) 00:59:32仮想コンストラクタで検索。
一般に、クライアントコードが簡素になる点と
融通が効く点が利点して上げられてる。
0248デフォルトの名無しさん
2005/06/25(土) 01:00:36それじゃおめ、
そうやって組んだしんぐるトンは通る可能性のあるものに関しては実行時にすべて生成されてしまうわけだな？
つ 逝ってよし
0249234
2005/06/25(土) 01:02:39継承を考えてなんとなく柔軟性を持たせたいというのは分かりますが
実際には、継承なんかしないクラスこそシングルトンの候補であることが
非常に多い気がします。
その場合には、闇雲にシングルトンにせずとも構わないんでしょうかね。
「クライアントコードが簡素に成る」については全く納得がいきません。
メンバがstaticであれば
(Singleton.getInstance()).invoke();
ではなく
Singleton.invoke();
と書けるでしょう。
0250デフォルトの名無しさん
2005/06/25(土) 01:04:500251デフォルトの名無しさん
2005/06/25(土) 01:06:04重箱の隅しか突付けない哀れな煽りだ
0252234
2005/06/25(土) 01:07:000253デフォルトの名無しさん
2005/06/25(土) 01:07:14このスレは厨房を隔離するための隔離スレです。。。
======================================================================
0254デフォルトの名無しさん
2005/06/25(土) 01:07:540255デフォルトの名無しさん
2005/06/25(土) 01:16:10お前はネタｗ
0256デフォルトの名無しさん
2005/06/25(土) 01:20:06インベーダーの例に戻って言うと、当初のスコアシステムに
ハイスコアの記録機能を追加した新スコアシステムを作る
場合、継承するのが妥当なんじゃない？
0259デフォルトの名無しさん
NGNG0260234
2005/06/25(土) 01:26:34それは、いわゆるUtilityクラスのような、状態の存在しないものですね。
それについて異存のあるひとはいないとおもいます。
ぼくがいっているのは、状態が存在するが、システムでユニークなクラス
のことです。とゆうか、Singletonというのは、そのようなものでしょ？
0261234
2005/06/25(土) 01:27:07ちょっとはしょりすぎた
すみません、酔っているので
0262デフォルトの名無しさん
2005/06/25(土) 01:27:20Foo foo = Singleton.getFoo();
Bar bar = Singleton.getBar();
Foo foo = Singleton.getInstance("Foo");
Bar bar = Singleton.getInstance("Bar");
後者の方が簡素というか、動的に生成物を変更するのが楽。
0263デフォルトの名無しさん
2005/06/25(土) 01:30:31・コンフィギュレーション選択用の定数か、
・コンフィギュレーションを表すオブジェクト
を渡すべき
0264デフォルトの名無しさん
2005/06/25(土) 01:32:54それは「グローバル変数」だ。悪。
シングルトンでは「状態のないもの」を表現する。
たとえば、「ストラテジーパターン」で使うストラテジーオブジェクトとか、
「ステートパターン」で使うステートオブジェクトとか。
「ファクトリー」もそうだ。
0265デフォルトの名無しさん
2005/06/25(土) 01:34:21オブザーバーパターンとのかみ合わせを考えてみて。
public class Enemy {
addObserver(ScoreSystem ss) {}
}
↑こうなってた場合、継承が必要。
public interface Observer {}
public class Enemy {
addObserver(Observer observer){}
}
↑こうしとかないオマイが馬鹿と言われれば、だよね〜
としか言い様がない気もするが・・・・・・
0266234
2005/06/25(土) 01:34:27え？
ぼくの認識では、メンバ変数はすべからく「状態」だと思っているのですが
間違いですか？
なんか、ちょっとはつみみな所見です。
0267234
2005/06/25(土) 01:36:31いやその、共存する必要が無いのであれば、インタフェースを変えずに
スコアシステムの「実装」を変えればいいだけなのではないかと。
なにか勘違いしていますか？ぼくは
0268234
2005/06/25(土) 01:37:33それはちょっとSingletonといいつつFactory風でもありますね。
そういうニーズがある場合には、確かに意義がある気がします。
あまりそういうケースが多くは無い気はしますが。
0269デフォルトの名無しさん
2005/06/25(土) 01:40:49そろって馬鹿だな。
デザパタとか別にしても。
0270259
NGNGいまいちやりたいことが分からないなぁ…。
Singletonが1種類のオブジェクトしか返さなくて、
将来その仕様に変更がないと言い切れるなら
いっそ状態もstatic管理でいいと思う。要するにSingleton不要。
デザパタは仕様変更に柔軟に対応するための手段だと思うから。
0271デフォルトの名無しさん
2005/06/25(土) 01:42:57このスレ読んでると、どんどん悪い癖、迷信に染まっていく傾向があるな。
状態はグローバル変数だから駄目？
それはあんたの信念であって、広く認められているSingletonの定義より狭いやん。
例えばアプリケーションの設定を Singletonに置くとして、
設定を変更する事は充分ありえる。つまり、Singletonに状態を持たせる事は充分有り得る。
GoF日本語版 p138
◎結果
Singletonパターンの効果を次にあげる。
1.インスタンスへのアクセスを制御する。(詳細略：唯一のインスタンスなのでアクセスチェックが簡単)
2.名前空間を減らす。Singletonパターンはグローバル変数の改良である。唯一のインスタンスを格納するグローバル変数 (注: C++, Smalltalk)を宣言する必要はなくなる。
3.オペレーションや内部表現を詳細化できる。(詳細略：Singleton のサブクラス化に関する話)
4.インスタンスの数を変えることができる。(詳細略：インスタンス数を２つ以上に変更する事も容易)
5.クラスオペレーションよりも柔軟である。(詳細略)
0272デフォルトの名無しさん
2005/06/25(土) 01:43:38Visitorが状態を持たないとき、
それでもオマイさんは
Visitorをnewしますか？
0273234
2005/06/25(土) 01:43:59いやその、「仕様変更」に対するデフォルトの対応が「継承」である、
というほうがぼくにとっては不自然なのですが。
たとえばオブジェクトのシリアライズ方式がv1とv2で変わっていて
両者に対応しなければならない、とかいうケースであれば、継承を
使うのは理解できます。
しかし、そもそも「唯一」であったものに、「継承」を適用するケース
って、そんなに多いのかな、と。普通、継承は、複数のものの差異を
選択的に無視したい場合に用いますよね。単純化のしすぎですが。
0274デフォルトの名無しさん
2005/06/25(土) 01:45:29つまりさ、このスレの白熱議論っつうのは、
すべからく >>264みたいな素人の迷信暴言が発端なわけ。
くだらねぇんだよおまぃらの議論は
0275デフォルトの名無しさん
2005/06/25(土) 01:45:47GoF本にはそんなこと書いてなかったけど
一体いつ定義されたの？
0276234
2005/06/25(土) 01:45:570277デフォルトの名無しさん
2005/06/25(土) 01:46:13面白い議論ｷﾎﾞﾝ
0278デフォルトの名無しさん
2005/06/25(土) 01:46:26恥を知れクズが
0279234
2005/06/25(土) 01:46:38ぼくのほうが素人だもん
とか書こうとしたのに
0280デフォルトの名無しさん
2005/06/25(土) 01:48:33かかってこいよ厨房ｗ
0281デフォルトの名無しさん
2005/06/25(土) 01:48:39おまぃは誤爆してる上、
>>234の定義で>>243するとNullPointerExceptionがおきるつう認識もない・・・
・・・Singleton書いた事あるぅ？(>>262を参照汁)
0282デフォルトの名無しさん
2005/06/25(土) 01:49:13差分プログラミングと開放/閉鎖原則で検索。
0283デフォルトの名無しさん
2005/06/25(土) 01:49:470284234
2005/06/25(土) 01:50:29あ、>>234の例はただの非常に単純化した例ですので。
いいたいことは、メンバを全てstaticで実装し、初期化はstaticコンストラクタ
で行うようなクラスをSingletonの変わりにして何かまずいのか？
ということに過ぎません。
0285デフォルトの名無しさん
2005/06/25(土) 01:51:100286234
2005/06/25(土) 01:52:42メイヤー先生ですか。
私としては、もう使いもしないv1のコードが残っているのは違和感を感じますがね。
それに、元のデザインが非常によくできていて、適切なフックなどが容易されていない
限り、継承してメソッドをオーバーライドするより元のメソッドそのものを
書き換えることのほうが容易であることも多い気がします。
0287234
2005/06/25(土) 01:53:59どれぐらい一般的なんでしょうか？
もとのクラスを書き換えるのは、邪悪？
open/close原則を厳密に適用すれば、そういうことになってしまいますね。
0288デフォルトの名無しさん
2005/06/25(土) 01:54:51好きにすりゃえーやん。
漏れは藻舞を説得するつもりはねぇ〜し
0290デフォルトの名無しさん
2005/06/25(土) 02:00:01アンチの俺から言わせると、
一般的なわけねーだろ。
あきらかに継承の使い方を間違ってる上に悪用としかいいようがない。
アホだアホ。マジで救いようがねー。
0291デフォルトの名無しさん
2005/06/25(土) 02:03:49煽れる時に煽るだけで、
中身は空っぽだもんな、おまえ
0292デフォルトの名無しさん
2005/06/25(土) 02:04:28仮想コンストラクタはファクトリとシングルトンの合わせ技だから
ニーズは普通にあると思うよ。
オセロの例に戻ると、プレーヤーを動的に変更したいというのは自然でしょ？
0293234
2005/06/25(土) 02:04:400294デフォルトの名無しさん
2005/06/25(土) 02:05:42オマエモナーｗ
0295デフォルトの名無しさん
2005/06/25(土) 02:06:351つのクラスが複数のstaticメンバ変数を管理するのはいくない。
0296234
2005/06/25(土) 02:07:54ニーズは、あるでしょうね。
ぼくは、実はSingletonでなくていいのに
「いまどきSingletonじゃないと、女のコにモテないぞ」
「グローバル変数はダサ！Bjarne stroustrupが何と言おうと絞め殺せ」
「static記憶クラス？そんなん、石器時代の遺物でしょ？」
とかそんな理由でSingletonにされているケースも、結構おおいんじゃないの？
と、そういいたかっただけです。
0298デフォルトの名無しさん
2005/06/25(土) 02:08:44文体と主張だけで彼は特定できる。
だから、スルーして淡々と進めてるだろ？お前さんもスルーするよろし。
0299デフォルトの名無しさん
2005/06/25(土) 02:10:45http://pc8.2ch.net/test/read.cgi/tech/1119158274/l50
ここでデザパタを使う前提の話をするな。
ここはデザパタの存在の可否を決めるスレだ。
＃大体、デザパタなんて誰も使ってないんだから過疎スレで
＃まとまってろってのｗ
＃アンチをこっちに隔離したとかほざいてたくせにアンチ追い出したら
＃ただの過疎スレになってやんのｗバーカｗ
0300デフォルトの名無しさん
2005/06/25(土) 02:11:45ここじゃ荒らしはお前の方なのｗ
わかったらさっさと過疎スレ帰れよｗ
0301デフォルトの名無しさん
2005/06/25(土) 02:12:20クラスの役割が訳わかんなくなるから。
0302デフォルトの名無しさん
2005/06/25(土) 02:13:14哀れな奴
0303デフォルトの名無しさん
2005/06/25(土) 02:13:38ヒント：スルー
0304デフォルトの名無しさん
2005/06/25(土) 02:14:54本気で帰ってよ。
デザパタ語るなら向こうが本スレだからｗ
0305234
2005/06/25(土) 02:15:01ぼくは頭が悪いので、やはりそれでは理解できませんね。
確かに全てをstaticで実装すれば、クラスはただのグローバル変数＋関数と
それをつつむnamespaceに同等のものになるでしょう。
で、それが何か問題なのですか？
0306デフォルトの名無しさん
2005/06/25(土) 02:16:01>何か問題なのですか？
だからここはデザパタの可否を決めるスレだっつってんだろ！
荒らしが！
0307デフォルトの名無しさん
2005/06/25(土) 02:18:16だいたい、何、頭に血上らせて必死におばかな議論してんだ、厨房。
グローバル変数を１つも使わないプログラムとかみたことないのか？
使ってる時点でレベル低すぎだってのにいらいらすんだよ。
お前みたいな馬鹿みてると。
0308デフォルトの名無しさん
2005/06/25(土) 02:18:25わざわざSingletonが当てはまらない想定を持ち出して煽ってるんだから、
別にSingleton勧めるいわれはないじゃん。
>>234もそろそろ初心者プログラミング相談室にでも相談してみたらどう？
0309234
2005/06/25(土) 02:19:24「1コのstaticメンバならOKだが、複数だとNGになる」
という理由です。
そこのところをもう少し分かりやすく説明していただけませんか。
寡聞にして聞いたことの無い主張なものですから。
0310デフォルトの名無しさん
2005/06/25(土) 02:19:33Singletonはグローバル変数の代わりをスコープに入れている。
つか、Javaじゃグローバル変数なんてないし。
0311デフォルトの名無しさん
2005/06/25(土) 02:19:46そういうことすると、そのクラスが何してるか（何を管理しているクラスなのか）、
後から見た人はわかんないでしょ。コード追っていかないと。
だからクラスの役割ははっきりさせる必要がある。
0312デフォルトの名無しさん
2005/06/25(土) 02:19:53利点もあるし、難点もあるな＞継承
Javaなんかだと、最近は継承よりも委譲とインターフェイスを
優先する風潮がある。
ソースの書き換えは、規模が大きくなると変更が他の部分に
影響を与えてドタドタドタっとドミノ倒しになる事がある。
それじゃあ継承ならそうならないかって言うと、まぁそうとも言
い切れんわけだが・・・・・・
まっ、それでinterfaceを多用する風潮が生まれたんだろう。
これならインターフェイスのみを残して新しく書き起こす場合
でも、継承を利用する場合でも、変更部分を局所化できる。
0313234
2005/06/25(土) 02:20:50いやその、パラメタライズされていないgetInstance()を使う
Singletonの例は多いと思うのですが。
パラメタライズされている場合については、了解しました
と言っておきましょう。
0314デフォルトの名無しさん
2005/06/25(土) 02:21:03＞Javaなんかだと、最近は継承よりも委譲とインターフェイスを
＞優先する風潮がある。
Java「なんかだと最近」？はぁ？
最初っからそうだよ厨房
0315デフォルトの名無しさん
2005/06/25(土) 02:21:24はぁ？デザパタ信者ってのは、
グローバル変数の何がまずいのか知らないのか？
アホだな。レベルが低すぎる。
もうちょっと勉強してきてくださいよｗ
0316234
2005/06/25(土) 02:22:28>>309に答えていただけませんか。やはりよくわからないんですが。
なぜstatic変数が吹く数字なると
「後から見た人はわかんない」ようになるのか。
0317デフォルトの名無しさん
2005/06/25(土) 02:23:050318デフォルトの名無しさん
2005/06/25(土) 02:24:00俺も聞いておきたい。つか、ネタかローカルルールだと思っている。
0319デフォルトの名無しさん
2005/06/25(土) 02:24:11ほら、本スレに逃げ込めよｗ
0320234
2005/06/25(土) 02:24:23ぼくがinterfaceに対するプログラミングの一番の恩恵を認識したのは
実はC++のリンク互換性なんですがね。
COMの発想のベースはそこにあります。大変汚いものですが。
0321デフォルトの名無しさん
2005/06/25(土) 02:25:200323デフォルトの名無しさん
2005/06/25(土) 02:26:57実は、Singletonってインスタンスが２つ以上あってもいいんだよね。
つか２つ以上生成した時点で、狭義のSingletonとは見なされない傾向があるが。
例えば某所で話題になっていたInstance PoolとかConnection Poolみたいなパターンになっちまう。
0324デフォルトの名無しさん
2005/06/25(土) 02:27:55だからどうしたんだよ。余計なレスつけんなアホ。
0326デフォルトの名無しさん
2005/06/25(土) 02:31:24お。冴えてるやん。
すると、ダンマリ決め込んでる>>311が回答すべき内容が見えてくる・・・はず・・・なんだが・・・なんともはや
0327デフォルトの名無しさん
2005/06/25(土) 02:32:05デザパタとか関係なく好き嫌いの問題でしょ、単に。
漏れは嫌だけど。
↓こんなコード書いてくるチームメンバがいたらはったおしてやるけどね。
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;}
}
0328デフォルトの名無しさん
2005/06/25(土) 02:32:55こんなのがコミュニケーションツールでいいんですか？＞デザパタ
人によって使い方違ってるじゃないですか？＞デザパタ
職場でもこんな戦いをしなきゃいけないんですか？＞デザパタ
0329326
2005/06/25(土) 02:33:17また訳わかんない主張系の人が、ｽﾚを混沌に導く・・・・・・もう飽きたから寝る。
0330デフォルトの名無しさん
2005/06/25(土) 02:33:49つか、マジで本スレ帰れってｗ
0331デフォルトの名無しさん
2005/06/25(土) 02:34:50お れ の せ い に な る の は な に か ち が う き が す る ！ （笑）
0332234
2005/06/25(土) 02:40:17ただの好き嫌いの問題であれば、ぼくの>>296の主張はあながち
ウソでもなかったようですね。
ちなみにそれによっていちいちgetInstance()を書かなければならないことを
あなたは面倒であると考えたことはないのでしょうか？
0334デフォルトの名無しさん
2005/06/25(土) 02:42:40こっちをデザパタスレにしようよ。
0337寝ぼけまなこでレス
2005/06/25(土) 02:49:490338デフォルトの名無しさん
2005/06/25(土) 02:51:09・メール欄に文章
0341259
NGNG0342デフォルトの名無しさん
2005/06/25(土) 02:53:21>>323, >>325-326
0343デフォルトの名無しさん
2005/06/25(土) 02:54:48お前そんなんだからいつまでたっても0ポイントなんだよ。
0344デフォルトの名無しさん
2005/06/25(土) 02:55:580345334
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だとそれができなくなるぐらいではないだろうか。
まあ個人の好みで使い分ければよいのではないかと。
0346デフォルトの名無しさん
2005/06/25(土) 02:58:560347デフォルトの名無しさん
2005/06/25(土) 03:00:55だからデザパタスレなんて本来はその存在の可否に関する
議論の方がもりあがってたんだってば。
デザパタ自体はシングルトン１つとっても意見はバラバラ。
コミュニケーションツールなんて夢のまた夢。
掲示板じゃ自由に言えるけど、会社じゃ適用に至る明確な理由が必要になる。
そこでデザパタが必要である理由なんて説明できる奴がいるわけが無い。
昔からずっとこんな調子なんだよ。
信者とアンチの聖戦が一番盛り上がるんだから叩きだしたって誰かが追撃してくるんだよ。
構図はいつも
「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」ＶＳ「オブジェクト指向原理主義者」
0348259
NGNGPoolはわからんが、
インターフェースとドキュメント見りゃ動作が分かるってのが、あるべきクラス設計の姿だろ、
実装に複数のstatic変数使ったからって、それが崩れることがあるのか？
0349259
NGNG＞オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿
アンチデザパタ派は何故いつもそう言う。
たとえば>>345がオブジェクト指向を理解できていないように見えるのか？
オブジェクト指向を理解しないとデザパタ理解できないぜ。
0350デフォルトの名無しさん
2005/06/25(土) 03:04:55頭悪い議論で盛り上がるのはもう沢山。
だから隔離されてるんだよおまぃは
0351234
2005/06/25(土) 03:06:06ああなるほど、そういう用例を考えると便利ですね。
でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
普通のオブジェクトよりその点がちょっとダーティ。でも逃げ道は在るよ、
というところでしょうか。
>>347
> 構図はいつも
> 「オブジェクト指向が理解できなくて、デザパタに逃げてきた馬鹿」
> ＶＳ「オブジェクト指向原理主義者」
ぼくはどっちでもないとおもいます。
0352デフォルトの名無しさん
2005/06/25(土) 03:07:270353234
2005/06/25(土) 03:07:55イマドキDIだからSingletonなんかつかわないぜ（ﾌﾟ
とか誰か言うのかと思ってたらそうでもなかったですね
0355デフォルトの名無しさん
2005/06/25(土) 03:08:50説明汁。
0356デフォルトの名無しさん
2005/06/25(土) 03:09:470358デフォルトの名無しさん
2005/06/25(土) 03:11:21calss 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> {}
...
テンプレートかますとそれなりに便利だが。
使い道がいまいち謎だ。
0359デフォルトの名無しさん
2005/06/25(土) 03:11:41>>273と>>351で同じ仮定をしなければならない義理があるわけでもなし。
つか、同じ仮定をしつこく主張しつづけたら、議論は進まない。
0361デフォルトの名無しさん
2005/06/25(土) 03:13:10>>271
0362234
2005/06/25(土) 03:13:46ぼくはべつに継承を常に否定してるわけじゃないんですが。
不要な継承を否定してるだけです。
>>345は、インタフェースを合わせるために必要な継承を巧みに使っている
例ですね。
まあ、実際にこういうtechniqueが実際にどれだけ必要になるかといえば、
疑問ですが。
0363デフォルトの名無しさん
2005/06/25(土) 03:13:49じゃ終結って事で。
0364デフォルトの名無しさん
2005/06/25(土) 03:13:56少なくともお前は理解していないｗ
オブジェクト指向云々に関する話題は>>345には出ていない。
したがってお前はまぬけだ。
>オブジェクト指向を理解しないとデザパタ理解できないぜ。
これはまったくの嘘。
デザパタはオブジェクト指向なんてまったく知らない奴が作った物。
よっぽどのアホでもなきゃ騙されないけどねｗ
現にここにいる奴のほとんどが学生だろ？
言語は覚えたけど、プログラムが組めないってレベルの奴。
まあ、プログラマでもないのにいきなり現場にぶち込まれた奴が
たくさんいるからこのレベルの奴だと色々模索するから
学校のお勉強に近いデザパタに妄信する奴がでてくるんだよね。
だけど、いくら勉強してもプログラムなんて組めるようにはならない。
図星だろ？
くくくっ、プログラムの組み方が書いてある本が世にあるとよかったなぁｗ
0365334
2005/06/25(土) 03:14:07あれ？アンチの人？おまいよく状況を知ってるなｗｗｗｗ
そうなんだよ昔から相手を馬鹿にするだけで、ろくな議論しないんだよあのスレｗｗｗ
だからここを有益なところにしようｗ
＞デザパタ自体はシングルトン１つとっても意見はバラバラ。
＞コミュニケーションツールなんて夢のまた夢。
コミュニケーションツールは確かに無理だねぇ。
書籍にしても著者によって捉え方が全然違う。
読んだ書籍によって、読み手も捉え方が異なってしまうし。
うーん、まあコーディングテクニック集ってとこなのかなぁ。
0366デフォルトの名無しさん
2005/06/25(土) 03:14:58携帯４っつ使ってレス付けてるのか(笑
0367デフォルトの名無しさん
2005/06/25(土) 03:16:180368234
2005/06/25(土) 03:16:22>>259さんには、あのアダプタの適用も「仕様変更に際して用いられる
典型的なtechnique」なのか。
その辺が僕とは認識が違いますね。
まあ、仕様変更といっても色々ありますから、なんとも言えませんが、
Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
噛ませることがベストな解である、というタイプの仕様変更って
そんなに無い気がしますよ？
0370デフォルトの名無しさん
2005/06/25(土) 03:17:13ならないだろ？ざまーみろｗ死ぬまでくるしめｗ
0372334
2005/06/25(土) 03:19:03そですね。私の理解としては逃げ道つくるぐらいですかね。
開発してる時とかにメソッド呼ぶ前に、ログをとるデコレータクラスとかよく作ります。
そういった面で扱いやすいってだけですかね。
他にもメリットはあるかもしれませんが。
＞でも、加工前にgetInstance()しなきゃいかんのはちょっとカッコ悪いですね。
↓これでどうでしょう・・・。一行にしてみました。だめですか・・・。
Singleton s = new TuikaKinouSingleten(Singleton.getInstance());
0373デフォルトの名無しさん
2005/06/25(土) 03:19:53たぶん、getInstance()にパラメータつけるより getFoo(), getBar()の方がいい、とか、
それよりも static methodの方がもっとシンプル (継承できないけど継承は仕様変更の手段とすべきではない)
とか。じゃねぇ〜の。いい加減寝るぞ
0374259
NGNG＞Singletonのようなインスタンスが一つだけのクラスに、このようなアダプタを
＞噛ませることがベストな解である、というタイプの仕様変更って
＞そんなに無い気がしますよ？
ベタベタだがたとえばウィジットを生成する Factory。プラットフォームによって切り替え。
そんなにワサワサと例は出せないが。
逆に仕様変更のない Singleton は Singleton である必要がない気がする。
それこそ Utility 的な。
>>371
まぁそうだなｗ
0375デフォルトの名無しさん
2005/06/25(土) 03:22:100376デフォルトの名無しさん
2005/06/25(土) 03:26:32である事を指摘しておこう。
0377259
NGNG単にラッパーしただけな気もするが。ただの思い付きなんで落ち度があったら優しくつっこんで。
クラスAの実装自体のタイピングがめんどくさいけど。
class A{
static StrategySingleton s=StrategySingleton.instance();
static void invoke(){
s.invoke();
}
}
A.invoke();
>>375
悪用ってのがどんな例だかわからんが、肯定派からも言わせてもらうと、
GoF本でも継承の濫用はするな、って書いてあった。
いちいち新しい動作を定義するのに毎回クラスを継承してたんじゃ、クラス増えまくりだからな。
>>376
まぁたしかにそうだな。
基本演算と同じレベルで考えればいいんじゃないか、と思う。
さすがに基本演算までオブジェクト指向にすることもなかろうと。
0379デフォルトの名無しさん
2005/06/25(土) 05:35:21・Singletonはダメ
・デザパタなんか誰も使っていない、普及していない
とほざく奴はJavaｄWebアプリの業務をやったことないだけだろ。
Javaではグローバル変数なんて概念はないし
Singletonはリクエストのたびにオブジェクト生成されるのを
防ぐために普通に使われるし（Factoryにすることも多い）
デザパタは使わないとスパゲッティ化してどうにもならなくなる
ってぐらいに当たり前のように使われている。
自分の知っている狭い世界だけで使ってないからって断言するな。クズ。
0380デフォルトの名無しさん
2005/06/25(土) 07:56:46なにあたりまえのことりきせつしてるの？
このすれは、
ていどのひくいひとがひっしにかんがえた
どうしようもなくていどのひくいねたを
かくりするすれだよ(わらい
0381デフォルトの名無しさん
2005/06/25(土) 07:57:55なにあたりまえのことりきせつしてるの？
このすれは、
ていどのひくいひとがひっしにかんがえた
どうしようもなくていどのひくいねたを
かくりするすれだよ(わらい
0382デフォルトの名無しさん
2005/06/25(土) 13:31:42「デザパタ肯定≠オブジェクト指向」
なんて言う脳内仮定で煽ってんの？
オブ戦スレの馬鹿がTMPこそデザパタとか
勘違いして、逆の立場で煽ってるの？
0383デフォルトの名無しさん
2005/06/25(土) 13:53:14つか、「デザパタ自体、OOではない」らしいよ。奴にとって。
0384デフォルトの名無しさん
2005/06/25(土) 15:48:50じゃあ、君がデザパタがオブジェクト指向にのっとっていることを証明したまえ。
ちなみに前スレだとデザパタはオブジェクト指向とは違う流れで
それは新しい進化ということで決着がついていた。
0386デフォルトの名無しさん
2005/06/25(土) 16:10:07オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として
デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、
オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。
この主張の矛盾点を指摘する形では肯定派も否定派も
両者を納得させるまでにはいかず、煽りを繰り返すレスがついた。
はじめの主張が
「デザパタはオブジェクト指向では無い」
というところからはじまっているだけあって、アンチが主導権を握ってしまうのは仕方がないと思う。
0387俺は肯定派？
2005/06/25(土) 16:25:56＞ オブジェクト指向での設計を、「対象物の構造をそのままソースに反映させること」として
＞ デザパタでの設計を、「パターンを用いてそれに当てはめること」とし、
このあたりは既に俺の考えとは違っていて、
＞ オブジェクト指向とデザパタが根本的に設計理念の異なるものだということだった。
これは当たり前だと思っている
0388デフォルトの名無しさん
2005/06/25(土) 16:56:54>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。
>それは新しい進化ということで決着がついていた。
0389デフォルトの名無しさん
2005/06/25(土) 17:44:18って思って欲しいのですか？
でオセロのソースでも晒すつもりですか？
おまいらは本当に進歩がないですね。
0390デフォルトの名無しさん
2005/06/25(土) 19:59:08>>389
まあ、そーゆーｽﾚだしね。適当に盛り上げといて。
0391デフォルトの名無しさん
2005/06/25(土) 21:02:46どっちかと言うとテンプレートライブラリに近い。
テンプレートライブラリ化出来ないレベルを
デザインパターンで扱うべきなんだけど、
GoFのやってる事は、気持ち悪いタイプの
馬鹿プログラマみたいだ。
0392デフォルトの名無しさん
2005/06/25(土) 21:53:35いくら明日予定が入って無いからって、そんなネタで暇つぶしの相手をみつようったってそうはいかない。
0393デフォルトの名無しさん
2005/06/25(土) 22:05:13脳内妄想ステキー
0394デフォルトの名無しさん
2005/06/25(土) 22:06:14今週のレスの付き具合を見るに、
>>391は毎日がエブリディもとい毎日が特別休日みたいだぞｗ
0395デフォルトの名無しさん
2005/06/25(土) 22:33:30てか、もういらない。
0396デフォルトの名無しさん
2005/06/25(土) 22:47:52それを「パターン」としてきっちり言語化したのはGoF以降だろう。
で、GoFのパターンの源はSmalltalkやC++での経験の蓄積が
元になっていると。
今では「デザインパターン」の語がOOPの領域以外にも
広げられてたとえば「モナド」は高階関数のデザパタの
一つ、と言ったりするわけだな。
だが、ここの厨がいってるような、デザパタはテンプレートで
オブジェクト指向とは関係ない、とかってのは、激しく
思い違いもいいところだ。
前橋、わかったのか？
0397デフォルトの名無しさん
2005/06/25(土) 22:48:05毎日が出社とかも考えろ！！
ボケ、糞、カス、キチガイ、狂信者。
0398デフォルトの名無しさん
2005/06/25(土) 22:49:43関係ないけどオブジェクト指向でも使えるのがデザインパターンなんで、
オブジェクト指向と関係ないちゅーのも、正しい物の見方だよ。
0399デフォルトの名無しさん
2005/06/25(土) 22:51:23「パターン」としてきっちり言語化したのはGoF以降。
歴史は覆せないよ。
0400デフォルトの名無しさん
2005/06/25(土) 22:55:30はぁ？
だからなんだってんだよ、GoFがオブジェクト指向的要素として
デザパタを提唱したんなら、オブジェクト指向の一部か否かてな
議論もなりたつが、C言語のデザインパターンだって成り立つんだから、
オブジェクト指向とは関係ないね。
で、GoFが出したカタログは、オブジェクト指向を破壊するデザインパターン
が多すぎるから誤解招いてるんだろ。糞。
0401デフォルトの名無しさん
2005/06/25(土) 23:01:25>オブジェクト指向を破壊するデザインパターン
相変わらず具体性ないねｗ
0402デフォルトの名無しさん
2005/06/25(土) 23:02:26デザインパターンが意識され始めたのは、
オブジェクト指向による設計に関する経験から
来ているのは事実なんだから。
そこで「デザインパターン」という、
「ライブラリ」なんかとは抽象レベルの違う概念が
意識されてきたわけで、あとから考えれば、
コレもアレもパターンてのは当然ある。
結局おまいらのいってるのは「CでもOOPできるYO」
ってのと同じく「Cでもデザパタできるよ」って言って
るだけで、吠えてみたところで、オブジェクト指向に
とってデザパタが重要なことに変わりはない。
0403デフォルトの名無しさん
2005/06/25(土) 23:03:310404デフォルトの名無しさん
2005/06/25(土) 23:04:19暑さのためおかしくなった不審人物がが大喜びではしゃいでます。
一般の方は刺されないように退避して下さい。
(隣組回覧)
=================================================================
0405デフォルトの名無しさん
2005/06/25(土) 23:08:510406デフォルトの名無しさん
2005/06/25(土) 23:09:29それでも構ってもらえたと勘違いして、
大喜びで自作自演レスしまくるとは、相当なもんだよな。
きっと、人との交流に激しい飢餓感を持ってるのだろうな。
もまいさぁ、いい加減、額に汗して働けよ。
俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ
0407デフォルトの名無しさん
2005/06/25(土) 23:21:341994年に標準化されたSTLが有るのに、
95年に書かれたデザインパターンをもって、
新しいってのはちょっと違うなぁと思うぞ。
0408デフォルトの名無しさん
2005/06/25(土) 23:45:04はぁ〜。GoF程度は読んどけよ。まったく。
あれのパターンの元ネタはSmalltalk-80やMacAppやその他。
この期に及んでSTL持ち出すのも馬鹿丸出し。
0409デフォルトの名無しさん
2005/06/25(土) 23:50:32>>俺今日、土曜出勤でエアコン効いてない室内で熱中症になりかかったんだぞ
どうやら >>406 にとって「働いている・働いていない」の基準とは、
室内のエアコンが「利いている・利いていない」って所らしいな。
0410デフォルトの名無しさん
2005/06/25(土) 23:56:42デザパタでの設計がオブジェクト指向にのっとっているかは別問題。
やっぱりオブジェクト指向とは考え方が違う。
オブジェクト指向で似通った設計を集めてそれをパターンにして当てはめたって
それはオブジェクト指向での設計にはならない。
0411デフォルトの名無しさん
2005/06/26(日) 00:20:29｜
｜
ぱくっ｜
／V＼
/◎;;;,;,,,,ヽそんなエサで
＿ ﾑ::::(,,ﾟДﾟ)::| 俺様が釣られると思ってんのか!!
ヽﾂ.（ﾉ:::::::::.:::::.:..|）
ヾソ:::::::::::::::::.:ﾉ
｀ ー U'"U'
0412デフォルトの名無しさん
2005/06/26(日) 03:02:48オブジェクトであるパーツを再利用するとオブジェクト指向じゃねえって意味わかんないんですけど。
で、デザパタのどこがクソ設計なのか具体的に挙げてもらえますか？そしてそれはどう設計されるべきですか？
0413デフォルトの名無しさん
2005/06/26(日) 03:08:07>C言語のデザインパターンだって成り立つんだから、オブジェクト指向とは関係ないね。
へぇ、オブジェクト指向って言語依存なんだ。てっきり設計の指針みたいなもんだと思ってたが。
プログラムできない人の考えることはオリジナリティがあっていいねｗ
0414デフォルトの名無しさん
2005/06/26(日) 03:24:06それは実装の話。
設計段階でオブジェクト指向では対象物をそのままソースに移すことが重要。
その結果、同じクラスが出てきたら、再利用できるできないを検討すればいい。
パターンに当てはめてしまうデザパタとはやはり違う。
0415デフォルトの名無しさん
2005/06/26(日) 03:38:54という前提が異常。
0416デフォルトの名無しさん
2005/06/26(日) 03:40:25じゃあ、パターンっていつ使うんだよｗ
0417デフォルトの名無しさん
2005/06/26(日) 03:58:57煽りじゃなくってこれはいっとかなきゃいけないと思うので書くが、キミ全く判ってないよ。
デザパタで語られるパターンてのはジェネリックかつプリミティブ。
STLで言ったら、vectorとかlistみたいなもんだ。
「クラスのメンバーにvectorがあったらオブジェクト指向じゃない」なんて命題は有り得ないわけよ。
vectorはプリミティブなテンプレートクラスであって、これによって設計がOOPかどうかを判断するなんて全くナンセンス。
まず、GoF本くらい読んで「理解して」から書き込みしなよ。
0418デフォルトの名無しさん
2005/06/26(日) 04:23:16なんでそこで実装の話がでちゃうのか理解不能。
余計わからない。
少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も
パターンに当てはめる形で設計をしている。
これは「〜パターンが使えそうですね。」的な発言も見られることから明らか。
わけのわからないことを言わないでもらいたい。
0419デフォルトの名無しさん
2005/06/26(日) 04:24:580420デフォルトの名無しさん
2005/06/26(日) 04:29:23ハイハイ、そこは重要な箇所じゃないでしょ？
くだらない煽り入れないでね。
ちゃんと↓に答えてね
少なくとも本スレからこのスレでデザパタのパターンの話をしている人間も
パターンに当てはめる形で設計をしている。
これは「〜パターンが使えそうですね。」的な発言も見られることから明らか。
わけのわからないことを言わないでもらいたい。
0421デフォルトの名無しさん
2005/06/26(日) 05:03:04っていう話？
0422デフォルトの名無しさん
2005/06/26(日) 05:31:37じゃ、君は以前に自分が使った設計の方法を思い出して
「あ、ここはあのやり方が使えるな」と思うことはないのか？
そう思った時点でそれはオブジェクト指向ではないのか？
ばっかじゃねえの。
0423デフォルトの名無しさん
2005/06/26(日) 05:39:20C言語でシングルトンパターンをどうやって利用しようか？
コンストラクターを隠蔽するから、一意性が保たれる？
プッって感じ。
では、オブジェクト指向的に考えてみようか？
インスタンスの生成を隠蔽すると安全なシステムになる？
プッて感じ。
GoF煎ってよし。
0424デフォルトの名無しさん
2005/06/26(日) 06:10:47あれって継承とか多態とかオブジェクト指向独特のテクニックを駆使してるし、
そういう意味でデザパタがオブジェクト指向の文脈で語られるのは当然かなぁ。
GoFのパターンが糞というのはそれぞれのスタンスとしてはいいと思うけど、
それがオブジェクト指向から外れてるってのはちょっと的外れかなぁ。
あ、もしかして継承も多態も認めない、原理主義的オブジェクト指向信者だっていうなら納得w
でも、それだって単にオブジェクト指向に対するスタンスの違いってだけの話しだよねぇ・・・
0425デフォルトの名無しさん
2005/06/26(日) 10:31:43× 継承も多態も認めない、原理主義的オブジェクト指向信者
○ 継承も多態も解らない、抽象的に物事が考えられないバカ
0426デフォルトの名無しさん
2005/06/26(日) 11:35:150427デフォルトの名無しさん
2005/06/26(日) 11:42:55>それがオブジェクト指向から外れてるってのはちょっと的外れかなぁ。
理由を言ってよ。
議論にならない。
0428デフォルトの名無しさん
2005/06/26(日) 12:08:10一般にオブジェクト指向の重要な概念として(1)カプセル化(2)継承(3)多態性というのがあるよね。
デザインパターンはこれらの概念をいかに設計レベルで利用するかと言うサンプル集みたいなものだから、
やはりオブジェクト指向の文脈で語られるべきものだと思うんだよね
0429デフォルトの名無しさん
2005/06/26(日) 12:32:45そりゃオブジェクト指向言語の機能じゃね？ｗ
はなしにならねー
さすがにお前みたいな肯定派はいなかったぞｗ
0430デフォルトの名無しさん
2005/06/26(日) 12:33:52ちゃんと答えるも何も、なにを答えたらいいのかわからない。
「パターンを当てはめる形で設計している。」に対して
「はい」または「いいえ」と答えればよいということかな？
その答えが知りたい意図がわからない。
0431デフォルトの名無しさん
2005/06/26(日) 12:35:26それでいいよ。
0432430
2005/06/26(日) 12:36:54それでいつも>>419のようにある程度、具体的な話にもっていってるのに、
>>420はいつも宙ぶらりなレスを返すからこちらとしても議論ができない。
0433430
2005/06/26(日) 12:38:12ああ、そうなの。
つまり、君が結論を出したかったことは
「パターンを当てはめる形で設計している。」に対して
「はい」って答えさせたかったってだけなのね。
それ以外の議論はしたくないと。
0434デフォルトの名無しさん
2005/06/26(日) 12:39:15デザインの話だから言語とは独立したお話。
という建前だけど、実際には言語の使用に引っ張られることも多いやねぇ・・・
0435デフォルトの名無しさん
2005/06/26(日) 12:42:010436デフォルトの名無しさん
2005/06/26(日) 13:03:11オブジェクト指向自体にはカプセル化や多態性の概念って無かったんだっけか？
むか〜しに
http://www.amazon.co.jp/exec/obidos/ASIN/4881356194/
でオブジェクト指向勉強したんだが、これにはそんな風に書いては無かったと
思う（もはや手元に無いので未確認。間違ってたらごめん）。
0437デフォルトの名無しさん
2005/06/26(日) 13:07:24っていうかアンチにとってどこからが実装の話なのかもよくわからない
0438デフォルトの名無しさん
2005/06/26(日) 13:08:590439デフォルトの名無しさん
2005/06/26(日) 13:24:27カプセル化や多態性も分からずにオブジェクト指向を語っていたのか...
それこそ話にならん
0440デフォルトの名無しさん
2005/06/26(日) 13:26:57そりゃ実装技術だろ。
オブジェクト指向での設計の話をしているだろ。
0441デフォルトの名無しさん
2005/06/26(日) 13:30:07え？ポリモーフィズム意識せずに設計やってんの？マジで？
0442デフォルトの名無しさん
2005/06/26(日) 13:30:10おいおい、実装だけの話ではないよw
適当に検索してみればいくらでも出てくると思うがなぁ・・・
0443デフォルトの名無しさん
2005/06/26(日) 13:30:47継承やカプセル化や多態性を考慮しながらクラス図を描いたりしないのか？
0444デフォルトの名無しさん
2005/06/26(日) 13:34:59やってるよ。マジで。
その辺って後からできた技術でしょ？
純正のオブジェクト指向信者の俺はそんな無駄なことはしない。
カプセル化なんて意識しなくても普通になるが、
継承や多態性なんて狙って設計なんかすると糞設計まっしぐらだぞ。
0445デフォルトの名無しさん
2005/06/26(日) 13:38:20> その辺って後からできた技術でしょ？
情報源を希望
0446デフォルトの名無しさん
2005/06/26(日) 13:38:280448デフォルトの名無しさん
2005/06/26(日) 13:39:430449デフォルトの名無しさん
2005/06/26(日) 13:40:27なんで？
多態性や継承なんてバグの温床だと思うけど？
0450デフォルトの名無しさん
2005/06/26(日) 13:41:48> 多態性や継承なんてバグの温床だと思うけど
なんでそう思ったんだい？
0451デフォルトの名無しさん
2005/06/26(日) 13:41:58本質じゃないよ。
本質は対象物の構造をそのままソースに映すことだよ。
多態性なんて付属品じゃないか。
0452デフォルトの名無しさん
2005/06/26(日) 13:43:29自分の主張を入れて無いレスにレスは返さないよ。
自分はどう思うけど〜って形にしてくれない？
0453デフォルトの名無しさん
2005/06/26(日) 13:45:16純粋架空物のクラスは作らないのかよ
0454デフォルトの名無しさん
2005/06/26(日) 13:46:100455デフォルトの名無しさん
2005/06/26(日) 13:48:40なぜそっちを相手にしてるのか？
が疑問だ。
0456デフォルトの名無しさん
2005/06/26(日) 13:48:44心に刻んでおきたまへｗ
0457デフォルトの名無しさん
2005/06/26(日) 13:52:16多分、>>449はC++プログラマーで基底クラスのデストラクタをvirtualにし忘れたとか、
そういう低レベルのことをいっているんジャマイカ？
0458デフォルトの名無しさん
2005/06/26(日) 13:55:430459デフォルトの名無しさん
2005/06/26(日) 13:57:150460デフォルトの名無しさん
2005/06/26(日) 14:01:03アンチの彼はC++しか使ったこと無いみたいだから、いいんじゃﾈｰﾉ
0461デフォルトの名無しさん
2005/06/26(日) 14:01:170462デフォルトの名無しさん
2005/06/26(日) 14:01:23そのレベルなの？
基底クラスをバーチャルにするしないは、場合よるか、
統一事項の世界かと？
0463デフォルトの名無しさん
2005/06/26(日) 14:02:49設計、分析、実装の違いがわからん厨は糞して寝ろｗ
0464デフォルトの名無しさん
2005/06/26(日) 14:07:05MFCも使えないな。
# まぁ、別の意味でMFCは使えないライブラリだし、いいのか？
0465デフォルトの名無しさん
2005/06/26(日) 14:08:28Cの時代に逆戻り。
0466デフォルトの名無しさん
2005/06/26(日) 15:24:27キミにはなっかりだよ。
0467デフォルトの名無しさん
NGNG0468デフォルトの名無しさん
2005/06/26(日) 15:32:50モジュール指向だとか抽象データ型の世界だろ
別に後者が悪いという訳じゃないが、オブジェクト指向を後者から決定的に
峻別するものが継承とポリモーフィズム。
0469デフォルトの名無しさん
2005/06/26(日) 16:30:54なんどもいうけど
オブジェクト指向ってのは
対象物の構造をソースに反映させることだよ。
継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。
だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ？
結局、設計が腐ってたら継承だって多態性だって全く意味が無いよ。
0470デフォルトの名無しさん
2005/06/26(日) 16:40:310471デフォルトの名無しさん
2005/06/26(日) 16:41:52そのつもり。
まず、正しい分析、正しい設計ありき。
継承や多態性なんて出てくるのはあとのあと。
0472デフォルトの名無しさん
2005/06/26(日) 16:47:56設計終わってから派生させちゃいけないっていってるわけじゃないよ。
でも実装時にクラス派生させることを前提にした設計って...
0473デフォルトの名無しさん
2005/06/26(日) 16:52:03使いこなせない事の言い訳に「バグの温床」というのは
よく聞かれる詭弁ですね。
0474デフォルトの名無しさん
2005/06/26(日) 16:52:10どうせ関数呼出しに関しては継承とたいして変わらん、
動的な切替えもできるし。
0475デフォルトの名無しさん
2005/06/26(日) 16:59:10pimplイディオムは良くってデザインパターンはダメってのが良く分からん。
pimplではなく委譲といえばまだ分かるんだが・・・
0476デフォルトの名無しさん
2005/06/26(日) 17:03:36そんなウォーターフォールな脳みそでこの先どうするつもりだｗ
0477デフォルトの名無しさん
2005/06/26(日) 17:07:58いや、設計は設計、実装は実装みたいな言いかたする割には、
実装に強く依存した設計するんだなって思ってさ。
0478デフォルトの名無しさん
2005/06/26(日) 17:25:470479デフォルトの名無しさん
2005/06/26(日) 17:27:160480デフォルトの名無しさん
2005/06/26(日) 17:33:16またお前か
0481デフォルトの名無しさん
2005/06/26(日) 17:42:45てゆうか、設計が崩れたら実装はやり直しでしょ。
0482デフォルトの名無しさん
2005/06/26(日) 18:08:11設計終わってから継承、そしてポリモーフィズムを取り入れるってことは
新しくクラスを導入することが確定事項としてあるわけで、
それって設計が終わってないって事じゃないのか？
0483デフォルトの名無しさん
2005/06/26(日) 18:12:40先ずはFatherクラスとMotherクラスを作るべきだ！
⊂⌒~⊃｡Д｡）⊃ どうでもいいですよ〜
0484デフォルトの名無しさん
2005/06/26(日) 18:20:550485デフォルトの名無しさん
2005/06/26(日) 18:22:46＞対象物の構造をソースに反映させることだよ。
この時点で大きな間違いを犯していることに気付いてくれ OTL
＞継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。
んで、この行は前行と合わせるとえらく矛盾している事にも気付いてくれ OTL
0486デフォルトの名無しさん
2005/06/26(日) 18:23:37ウォーターフォールしか頭にないのか？
分析→設計→実装→分析→設計→実装→設計→実装→分析→設計→実装・・・
ってやっても別にいいんだぞ。
0487デフォルトの名無しさん
2005/06/26(日) 18:24:02ヒント：クローン
0488デフォルトの名無しさん
2005/06/26(日) 18:25:10ちゃんどどこがどうまちがっているまで書いてくれなきゃレスはつけないのでよろしく。
ちゃんと自分の主張を相手に伝えることぐらいはできなくちゃ駄目だよ。
プログラムがどんなに組めたってそれじゃいっしょに仕事ができない。
0489デフォルトの名無しさん
2005/06/26(日) 18:31:19主張するだけで具体性を伴ってないから、全く相手に伝わってない奴もいるな
0490デフォルトの名無しさん
2005/06/26(日) 18:31:32問題にしているのは>>469が
> だいたい継承やら多態性なんてのは設計がきっちりできたあとの話だろ？
としていること。
>>469にとって継承のために新しくクラスを導入することは「設計をやり直す」
ことには属さない。
0491485
2005/06/26(日) 18:31:33あ、了解。っていうか問題だけ提起して裏でごにょごにょ書いてたでス。
＞対象物の構造をソースに反映させることだよ。
オブジェクト指向を使えば、同じ対象物に対し、万人が同じ構造のソースを書いてくる……筈も無い事から、
構造を反映させるのは合っているが、構造の詳細はPGに任されると思った。
ニュアンスの問題。
＞継承やら多態性なんてのは本質からはずれまくってて話しにならないよ。
継承や多様性も含めた対象の構造を考えるのが、オブジェクト指向。
そこまで構造に反映させてくれ。
0492デフォルトの名無しさん
2005/06/26(日) 18:33:240493デフォルトの名無しさん
2005/06/26(日) 18:37:26>>475と>>478をスルーするつもりなんだろうか？
0494デフォルトの名無しさん
2005/06/26(日) 18:45:15ん？文章的には結論がついてるみたいだけど、何が聞きたいの？
>>491
でもさ、継承や多態性なんて構造に入れるのなんて
対象物の構造が間違いないぐらいきっちりわかってからの話じゃない？
要は全体の設計にさほど影響を与えるものでは無いよ。
俺の組み方だけど継承やら多態性やらを考慮してクラスを組み変えるのは一度実装が
ほぼ終わりに近づいてからしかやったこと無いな。
そこまで設計とは遠いものだと考えてる。
ちなみに最近じゃ使って無い。（むしろ、使わない方がいいと思ってる。）
0496デフォルトの名無しさん
2005/06/26(日) 18:48:00469と474て同一人物じゃないだろ？
同一人物だとしたら説が矛盾する。
0498485
2005/06/26(日) 18:52:25＞対象物の構造が間違いないぐらいきっちりわかってからの話じゃない？
つまり貴方は、何時も見切り発進でやってると……言うような冗談は置いておいて
・分かっているならば構造に組み込むというのは FA
・分かった時点で構造に組み込むというのも FA
だれも 『判明していない構造』 を組み込めなんて言ってないですし
＞継承やら多態性やらを考慮してクラスを組み変えるのは
っていうか、もしかしたらと思ったんだけど、
『コーティングの技巧として、構造とは異なる継承や多様性を組み込む』
とかやってませんか？
それはオブジェクト指向から微妙に外れるし、それを 「オブジェクト指向とは言わない」 と言うのはトートロジ
0499485
2005/06/26(日) 18:57:23>>494
俺でも確かに、継承とかを使わないときは全く使わないんだけど、それでも時折閃くときがあるんだな
そういうときには使う
0500デフォルトの名無しさん
2005/06/26(日) 18:57:47これでコイツがC++で実務をこなした事は一度も無いって事が分かったな。
Java&J2EEに関する知識は皆無で、C++に関してはテンプレートに苦戦中
でpimplを知らないというレベル。なんとなく、どんな奴だか見えてきた。
0501490
2005/06/26(日) 18:57:51聞きたいのは>>482だったんだが、
>>494を読む限り、君にとってis-aの関係のためのクラス導入は、
設計とはほぼ無関係であるとしてるね。
設計に無いクラスの導入を実装時にすることを確定事項とした設計であると理解して良いね？
0502デフォルトの名無しさん
2005/06/26(日) 18:59:170503デフォルトの名無しさん
2005/06/26(日) 18:59:33あ？なんか非常にわかりにくい文章で何言ってるのかわからない。
何がいいたかったの？
書いた本人的にも微妙でしょ？>>498の文章って。
0505デフォルトの名無しさん
2005/06/26(日) 19:05:51「構造」って「データ構造＋論理構造」だよね?
0506デフォルトの名無しさん
2005/06/26(日) 19:07:13「オブジェクト構造」
0507485
2005/06/26(日) 19:17:51>>494
『コーティングの技巧として、想定していたオブジェクトの構造とは異なる継承や多様性を組み込む』 ことは、
たとえクラス等を使用していてもオブジェクト指向とは言えない (かもしれない)
0508デフォルトの名無しさん
2005/06/26(日) 19:20:24何がききてぇんだ？ｗ
もう、てめぇの中で結論は出てるのか？ｗ
0510デフォルトの名無しさん
2005/06/26(日) 19:33:05それを>>494では
> 継承やら多態性やらを考慮してクラスを組み変えるのは一度実装が
> ほぼ終わりに近づいてからしかやったこと無いな。
なんていっちゃってるし、これって設計せずにプログラミングしているのと何か違いがあるのか？
0511デフォルトの名無しさん
2005/06/26(日) 19:39:402.分析
3.設計
4.実装
5.品質管理
それぞれのステージにおいてOOの意味や役割が異なる。という前提は確認しあってるの？
0512デフォルトの名無しさん
2005/06/26(日) 19:42:24頼っちゃうのかな？
0513デフォルトの名無しさん
2005/06/26(日) 19:59:290514485
2005/06/26(日) 20:03:16デザパタって、料理のレシピみたいな物なのかもね
レシピを見れば、腕が良ければそこそこの料理ができる
レシピをたくさん眺めていれば、新しい料理を作ってみることもできる
……レシピを見なくても、料理できる人は料理しちゃう
0515デフォルトの名無しさん
2005/06/26(日) 20:04:31多態性を否定するとほとんどの既存のライブラリを使用できなくなることを指摘され、
それを無理に方向修正しようとして失敗した結果だろ？
0516デフォルトの名無しさん
2005/06/26(日) 20:05:56そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か？
0517デフォルトの名無しさん
2005/06/26(日) 20:07:32？
512 への間違い？
0518デフォルトの名無しさん
2005/06/26(日) 20:11:49×デザパタ否定派
○デザパタ否定君
0519デフォルトの名無しさん
2005/06/26(日) 20:14:070520517
2005/06/26(日) 20:20:29＞513 ：デフォルトの名無しさん ：2005/06/26(日) 19:59:29
＞ とデザパタに挫折した人が言っております。
＞516 ：デフォルトの名無しさん ：2005/06/26(日) 20:05:56
＞ >>513
＞そういうパターンの使い方が限界なんだろうな。ここまでくると頭蓋骨の容積の問題か？
ごめん。この２個のレスが全然繋がらないんだ
0521デフォルトの名無しさん
2005/06/26(日) 20:28:13デザパタはオブジェクト思考に従っていないからダメ
というロジックが崩れてしまうし、
かといって継承・多態性を完全に否定してしまうと今度は、
ほとんど全部の既存のライブラリを使えないことになってしまうし・・・
と、考えたデザパタ否定君は>>494をカキコしたのでしょう。
0522デフォルトの名無しさん
2005/06/26(日) 20:28:47だろうね。
0523デフォルトの名無しさん
2005/06/26(日) 20:32:48まあ、最も重要な概念である「振る舞い」を外してる時点でアレだけどね。
0524デフォルトの名無しさん
2005/06/26(日) 20:33:51「振る舞い」 というか 「インターフェイスの抽象化」 の方が
0525デフォルトの名無しさん
2005/06/26(日) 20:41:04もう一息だね。
「インターフェイスの抽象化」を「振る舞い」 と呼びたくなった時にはじめて
自分がテイクオフしたことを実感できると思うよ。頑張って！
0526デフォルトの名無しさん
2005/06/26(日) 20:45:39ああ、多分俺が考えているのと違うわ。
「対象物のインターフェイスを抽象化する」 ＝ 「対象物の振る舞いを定義する」
0527デフォルトの名無しさん
2005/06/26(日) 20:47:15うん。違うね。
0528デフォルトの名無しさん
2005/06/26(日) 20:50:020529デフォルトの名無しさん
2005/06/26(日) 20:54:560530デフォルトの名無しさん
2005/06/26(日) 20:55:27ｲﾀﾀﾀﾀ
0532デフォルトの名無しさん
2005/06/26(日) 20:57:56それが何か？
0533デフォルトの名無しさん
2005/06/26(日) 20:58:37何か？
0534デフォルトの名無しさん
2005/06/26(日) 21:14:39『デザパタはオブジェクト指向に従っていない、トリッキーなコードである』
ってコトらしいけど、俺は仮説として
『デザパタを適用してもオブジェクト指向に従っている例は存在するのではないか』
を考えた。否定派の主張を覆すならば、その様な具体例を示せれば良いと思う。
もし存在すれば、デザパタは反オブジェクト指向的コードを 強制する 物ではないと示せる筈だから。
んで、具体例を挙げるにあたって、
『実世界の物体において実現されている構造ならば、オブジェクト指向で考えられる。つまり、オブジェクト指向に従っている』
と考えた。
【続く】
0535デフォルトの名無しさん
2005/06/26(日) 21:14:51んで、試しに Strategy が適応されている、もしくは Strategy 的な構造になっている現実世界の実例を考えてみたら
・マザーボードと CPU の関係
・ゲームボーイとカートリッジの関係
とか、妙にたくさん出てきて困った。
これらの関係は、２つの接触部分を固定化して、片方を必要に応じて切り替えられるようになっている関係だ。
必要に応じて切り替えられる、って言うのはつまり切り替えなくても良い、って意味も含むけど。
んで、俺の仮説における具体例が示せたわけだが、果たして合っているだろうか……
======
あと、この例ならば、以前否定派の人が 「戦術をクラスとして抜き出すのはオブジェクト指向的ではない」
って言っていたことの、簡単な反証にもなると思う。
この主張は 「戦術≠オブジェクト」 ってコトを根拠にしているけど、
「抜き出す作業」 はつまり、「戦術を内包したオブジェクトを定義する」 ことに等しいから、そもそも問題になってない。
0536デフォルトの名無しさん
2005/06/26(日) 21:25:12>>386がよくまとまってるから読んでからにしたほうがいいと思う。
0537デフォルトの名無しさん
2005/06/26(日) 21:29:04否定派の主張が間違っているって言うこと？
その主張には何通りかあったと認識してたけど……
0538デフォルトの名無しさん
2005/06/26(日) 21:34:490539デフォルトの名無しさん
2005/06/26(日) 22:01:18『「現実物をそのままモデル化するのがオブジェクト指向」ってのは間違ってるんだぜ！ぎゃはは』
っていう釣りは止めてください。
おまいらは本当に進歩がないですね。
0540デフォルトの名無しさん
2005/06/26(日) 22:01:410541デフォルトの名無しさん
2005/06/26(日) 22:04:510542デフォルトの名無しさん
2005/06/26(日) 22:05:250543デフォルトの名無しさん
2005/06/26(日) 22:05:480544デフォルトの名無しさん
2005/06/26(日) 22:05:55前橋って誰だー！
0545デフォルトの名無しさん
2005/06/26(日) 23:06:27要するに、読む価値ないスレ。
無理に読んだら、確実にバカが伝染する
=================================================================
0546デフォルトの名無しさん
2005/06/26(日) 23:07:44枠線付けないとみんなにスルーされると思って不安なんですねｗ
0547デフォルトの名無しさん
2005/06/26(日) 23:08:070548デフォルトの名無しさん
2005/06/26(日) 23:10:15つか、どー考えても自作自演だろ、この痛さは
0549デフォルトの名無しさん
2005/06/26(日) 23:17:320550デフォルトの名無しさん
2005/06/26(日) 23:23:18・・・いわゆる一般の会話じゃなくて、
分裂症患者の妄言みたいなもの
0551デフォルトの名無しさん
2005/06/27(月) 00:22:49っていうか誰だよ前橋。
0552デフォルトの名無しさん
2005/06/27(月) 00:23:370553デフォルトの名無しさん
2005/06/27(月) 00:54:04まぁ、実際この手のタイプはいるけどさ
0554デフォルトの名無しさん
2005/06/27(月) 02:34:47>「現実物をそのままモデル化するのがオブジェクト指向」
痛いよなｗ だから存在しない「抽象の抽象」は理解不能なんだよなｗ
いつからOOPってこんな稚拙で低知能な思考形態を正当化する概念になったんだ？
こんなのプログラム組んだことのない、影で「クソ設計勘弁してくれ」呼ばわりされている「自称」SEの戯言だから心配するな。
こういう連中が「オブジェクト指向」と連呼するごとにチープな言葉になっていく。
0555デフォルトの名無しさん
2005/06/27(月) 02:37:540556デフォルトの名無しさん
2005/06/27(月) 02:41:46過去ログを見てみ。クソみたいな感情論，オリジナリティあふれる稚拙なオブジェクト指向論ばっかで、まともにデザパタを理解しての批判は一つもない。
必死に自分のカスぶりをアピールしているだけということに本人が気付いていないところが滑稽だよなｗ
0557デフォルトの名無しさん
2005/06/27(月) 03:28:20まぁ、Fランク文系大卒で営業からSEに転向した(もしくはそれに準ずる）という意味ではど素人だわな。
0558デフォルトの名無しさん
2005/06/27(月) 03:30:11明日の仕事は無いのかな？
つか、未来永劫仕事無いのか？
・・・気楽でいいなぁ、落伍者は
0559デフォルトの名無しさん
2005/06/27(月) 03:40:43エリート相手に落伍者呼ばわりかよ小アジアの５流NEAT風情がｗ
こっちは日曜日の昼前なの。
0560デフォルトの名無しさん
2005/06/27(月) 03:43:030561デフォルトの名無しさん
2005/06/27(月) 03:43:590562デフォルトの名無しさん
2005/06/27(月) 07:21:39定期的にこういうのが湧いちゃうのは仕方がないのかな？
0563デフォルトの名無しさん
2005/06/27(月) 07:48:54仕方がないんじゃない？
そう言われても仕方がないのが事実だからね。
0564デフォルトの名無しさん
2005/06/27(月) 07:51:04>>552
0565デフォルトの名無しさん
2005/06/27(月) 10:23:24(・∀・)
0566デフォルトの名無しさん
2005/06/27(月) 13:54:03さすがエリート的な発言ですね。
っていうか議論のレベルがアンチ以下のような気がするんですが。
ガキ同志の悪口のいい合いじゃん。
こんなのがエリートだなんて人間終わってるな。
0567デフォルトの名無しさん
2005/06/27(月) 14:22:18Template Methodパターンかな
0568デフォルトの名無しさん
2005/06/27(月) 14:23:160569デフォルトの名無しさん
2005/06/27(月) 14:48:00それ本人じゃね？
0572デフォルトの名無しさん
2005/06/27(月) 19:10:150573デフォルトの名無しさん
2005/06/27(月) 23:52:28本当に正しいことなんてそれほどない。
5年たったら評価が真逆になっていたり。
柔軟じゃないと変化についていけないお
0574デフォルトの名無しさん
2005/06/28(火) 04:29:220575デフォルトの名無しさん
2005/06/28(火) 11:44:54もう海外ではもっとすごい手法が編み出されてるんだろうな。
取り残されているようでｶﾅｼｽ。
0576デフォルトの名無しさん
2005/06/28(火) 15:19:05うれしや悲し 操り人形
0578デフォルトの名無しさん
2005/06/28(火) 18:00:01情動過多による学習障害か？
>> http://pc8.2ch.net/test/read.cgi/tech/1119158274/14-15 のリンク先を注意深く嫁
0579デフォルトの名無しさん
2005/06/28(火) 18:58:30詳しい意味はしらないけど、
漢字見る限り多分俺それだ…これって病気なのか？
0580デフォルトの名無しさん
2005/06/28(火) 19:08:22早く読め
0581デフォルトの名無しさん
2005/06/28(火) 19:20:570582575
2005/06/28(火) 19:44:28すまんす。漏れは基本的に英語が読めん。
それにそのリンク先も、新しい技術に関する情報であって、良い情報なのかどうかわからん。
新しいからといって良いものとは限らんし。
というか「面白い技術情報は海外にあるけど漏れ英語読めねーし」と諦めたときから学習する気がうせた。
0583541
2005/06/28(火) 20:27:26×「現実世界をそのままモデル化するのがオブジェクト指向」
○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」
そのままモデル化したら、ある対象物Ａからの構造は１通りに決まりそうだけど、そういうわけにも行かない
モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている
例)
java.lang.System.out と System.Console は、両方とも Console への入出力を扱うが、双方には大きな違いがある
などなど
……ってゴメン。書いてて気付いたけど 『オブジェクト指向的な構造を考える』 って思いっきり 『モデル化』 だった罠
超訂正
0584デフォルトの名無しさん
2005/06/28(火) 20:34:590585デフォルトの名無しさん
2005/06/28(火) 20:56:47何か違う気がする。
0586デフォルトの名無しさん
2005/06/28(火) 21:11:46http://pc8.2ch.net/test/read.cgi/tech/1119158274/14で、ドメイン名が jpで終わってるリンクと、
http://pc8.2ch.net/test/read.cgi/tech/1119158274/15のリンクは、
全部日本語のページだ。
早く読め。
0587デフォルトの名無しさん
2005/06/28(火) 21:18:29>そのままモデル化したら、ある対象物Ａからの構造は１通りに決まりそうだけど、そういうわけにも行かない
>モデル化の前段階として、オブジェクト指向的な構造を考えるステップが存在していて、そこで意外と構造は書き変えられている
そんなのお前のレベルが低いからじゃんｗ
>○「現実世界にオブジェクト指向的な構造を“見いだし”または“作り上げ”、その構造をモデル化するのがオブジェクト指向」
そんなのまで許しちゃったら、オブジェクト指向（？）で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃないじゃん。
ちゃんと考えてるの？
俺もオブジェクト指向覚えたばかりの頃はそういういらんクラスが出たけど
最近は研ぎ澄まされてきて、そんな必要ない中間クラスはさっぱりでなくなったよ。
単に経験の差のような気がするけどねぇ。
0588デフォルトの名無しさん
2005/06/28(火) 21:21:54継承も多態もないオブジェクト指向（？）の何が便利なの？
0589541
2005/06/28(火) 21:25:20＞そんなのまで許しちゃったら、オブジェクト指向（？）で作ってもわけのわからないクラスばっかり増えてちっとも便利じゃない
現実世界とは無関係の物を捏造しろ、とは言っていないんで注意。
大まかな部分は似せろ、細かな部分で調節しろ。
俺は、経験というか世界観の違いのような気がするんだけどねぇ。
0591デフォルトの名無しさん
2005/06/28(火) 21:37:040592デフォルトの名無しさん
2005/06/28(火) 21:37:540593デフォルトの名無しさん
2005/06/28(火) 21:40:03>>591自身の過去レスを厨房呼ばわりする
>>591の人生って無価値
0594デフォルトの名無しさん
2005/06/28(火) 21:41:15コンプレックスだらけだな。ｶﾜｲｿ（爆笑
0595デフォルトの名無しさん
2005/06/28(火) 21:57:03しかし、それでもこっちが本スレっぽくなって、
本スレが過疎スレになってしまう不思議ｗ
みんなどっちが正しいこといってるかなんて感覚ではわかってるんだよ。
だってデザパタっておせじにもわかりやすいとはいえないじゃん。
こういうのは直感が役に立たないもんは流行らないよ。
みんなで使うモンなんだからさ。
0596デフォルトの名無しさん
2005/06/28(火) 22:15:11http://pc8.2ch.net/test/read.cgi/tech/1119158274/14で、ドメイン名が jpで終わってるリンクと、
http://pc8.2ch.net/test/read.cgi/tech/1119158274/15のリンクは、
全部日本語のページだ。
早く読め。 読んだら報告しろ
0598582
2005/06/28(火) 23:13:37えっ？いやあの。
１．エンタープライズアプリケーション開発のパターン by マーチン・ファウラー
これ洋書の紹介だけじゃん。（´∀｀；）
２．マーチン・ファウラー's bliki (blog)
これ更新履歴一覧じゃん（´∀｀；）
ここのは「クロージャ」の説明しか読んだことない。全部読めと？
３．MixJuiceによるデザインパターン改善カタログ
リンク切れしてるじゃん（´∀｀；）
４．AspectJ を使ったデザインパターンの改善と支援
まずアスペクト志向がﾜｹﾜｶﾗﾅｽなので説明がﾜｹﾜｶﾗﾅｽ（´∀｀；）
0599デフォルトの名無しさん
2005/06/28(火) 23:14:52すごい。中学時代を思い出すかのような素敵なレスだ。
0601デフォルトの名無しさん
2005/06/28(火) 23:22:48いいからお前も読んどけって。
どうせ頭の中身は >>582とどっこいどっこいだろ？
>>598
おまえには、短い文章の読解力もろくにない事がよく判る。
1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、
それくらい最低読んどけ。
2. 上記1.の文書が掲載されているblog (bliki)だ。
気になる文書があったら端から目を通してみろ。
そうすれば、ここまでレベルの低い会話はしなくて済む。
3. こっち嫁
http://staff.aist.go.jp/y-ichisugi/ja/mj/design-pattern/
4. なんだよ？結局英語がわかんねぇだけじゃなくて、日本語でも駄目なんじゃねぇか。
じゃ 上の1の本、端から買って嫁。読み終わってから議論しろ
0602デフォルトの名無しさん
2005/06/28(火) 23:24:590603582
2005/06/28(火) 23:32:02こういっちゃなんだが元々、過疎スレだったのさ（涙
>>601
＞1. 日本語版ページには、ごく一部を除いてほとんどの洋書の邦訳版書名が載ってるだろ、
＞ それくらい最低読んどけ。
>>596のレスにこんな深い意味が込められていたのかーｗｗｗいや冗談です。まあ、買って読んで見ます。
＞2. （略
まあ、これは読む気だった。
＞3. こっ（略
thx
＞4.なん（略
いやぁ。これ全部書き途中＆自分用メモみたいだわ。文章としては非常に読みにくい。
パターン説明の８割がソースコードで解説とかｱﾘｴﾅｽ。ﾜｹﾜｶﾗﾅｽ。
0604デフォルトの名無しさん
2005/06/28(火) 23:35:100605デフォルトの名無しさん
2005/06/28(火) 23:37:40正直に言え。おまえはソースなんてろくすっぽ読めない素人だろ？
証拠のソース出せずに荒れ、UML設計でいいから出せと言われてまた荒れ、
挙句にソースで解説されても判らねぇ？はぁ？
おまえには、ここで議論する資格ねぇんだよ。
さっさと巣に戻って、プルプルプルプル一晩中震えてろって
0606デフォルトの名無しさん
2005/06/28(火) 23:39:15（ ´,_ゝ｀）ﾌﾟ
0607デフォルトの名無しさん
2005/06/28(火) 23:40:200608デフォルトの名無しさん
2005/06/28(火) 23:41:21現在、ソースも読めない素人が粘着中です。
粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。
=================================================================
0609デフォルトの名無しさん
2005/06/28(火) 23:43:11そーゆーこと。
さっさとこいつをアクセス禁止にしないと、
プログラム板の荒れが収まりようがない
のは周知の事実
0610デフォルトの名無しさん
2005/06/28(火) 23:43:390611582
2005/06/28(火) 23:43:48なにぃ！J2EEパターンとかいう本があったのね。
これはめっさ読みたい。ありがとう。
>>605
おおぅ、なんか荒れてるなぁ（´∀｀；）
漏れはむしろこのスレでソースコード書いてた奴さね。
まあ、議論する資格なさそうだから消えるよ。
0612582
2005/06/28(火) 23:44:220613デフォルトの名無しさん
2005/06/28(火) 23:51:26自分でDLLが無いと動かないＭＦＣアプリ作っておいて
ユーザに押し付けて、動かないのをユーザのせいにする奴とにてるよ。
この場合ってＭＦＣのＤＬＬが無くても動くように作るのが普通だよね？
結局さ、議論スレで強引に自分の気にいった本を読むように押し付ける奴ってこういう奴なんだよ。
俺等が読んで無い本はお前にとってＭＦＣのＤＬＬなんだろ？ｗ
じゃあさ、ＤＬＬが必要なくても動くようにしてこいよｗ
0614デフォルトの名無しさん
2005/06/28(火) 23:53:24と、ソースも読めない厨房が寝言をほざいてます（笑
無視無視
0615デフォルトの名無しさん
2005/06/28(火) 23:54:36玄人のフリをする痛いスレ
0616デフォルトの名無しさん
2005/06/28(火) 23:55:17耳や尻尾をみつけた時は黙って自分の胸に仕舞っとけ。
気付いてる奴はとっくに気付いてて発言者の特定に使ってるんだから
そういう発言は邪魔になる。無くて七癖文章の癖ってなｗ
0617デフォルトの名無しさん
2005/06/28(火) 23:58:26議論をするにはいくらかの前提が必要だ。敷居と言い直してもいい。
必要と発言するにも、不要と発言するにも、最低限それについて知
っていなければ議論にならない。
0618デフォルトの名無しさん
2005/06/28(火) 23:59:22図星突かれて、ファビョ（火病）って改行連発しちゃった？
0619デフォルトの名無しさん
2005/06/29(水) 00:00:420620デフォルトの名無しさん
2005/06/29(水) 00:01:49ＭＦＣのＤＬＬはユーザが自分で入れておくべきだと。そういうことか。
まあ、流行らないものって全部そうだよ。
MSが出したManagedなんとかっていうゴミもこんな感じで流行らないし。
勝手に敷居を作るのはかまわないけど、みんなの同意もなしじゃ
独りよがりと言われてもしょうがないよね？
0621デフォルトの名無しさん
2005/06/29(水) 00:03:210622デフォルトの名無しさん
2005/06/29(水) 00:05:04同意。そして、>>608に賛成。
0623デフォルトの名無しさん
2005/06/29(水) 00:05:37図星を突かれると、瞬間的に脳が火病って途端に話が非論理的になるからな。
0624デフォルトの名無しさん
2005/06/29(水) 00:06:30かつての「ねぇ」遣いは、多少マトモな事を言う糞粘着院生だったんだけどねぇ（藁
今の「ねぇ」遣いは、皆が一番嫌っているコテハンの多くを駆使してる基地外だからなぁ（ｗ
0625デフォルトの名無しさん
2005/06/29(水) 00:07:35さっさと報告しろ
0626デフォルトの名無しさん
2005/06/29(水) 00:09:45アレは瞬間湯沸かし器だから、一発で判る。
たぶんそのうち、脳溢血で逝くだろう。その日を楽しみにしている。
煽って煽って喧嘩ばかりの荒んだ毎日。可哀想な人生だね。同情するよ
0627デフォルトの名無しさん
2005/06/29(水) 00:10:36そう人にＤＬＬの挿入を押し付けるなよｗ
俺等が入れたくねぇって言ってるんだから。
むしろてめぇの方がＤＬＬが必要ないように実行ファイル作ってこいよｗ
0629デフォルトの名無しさん
2005/06/29(水) 00:11:48DLLに関する議論はスレ違いです。
適切なスレに移動したらいかがですか？
頭悪いから理解できないかな？
0630デフォルトの名無しさん
2005/06/29(水) 00:12:51じゃぁさっさと読め。
読み終えるまで発言するな。
他のレス番使った発言も一切するな。
0631デフォルトの名無しさん
2005/06/29(水) 00:16:10例え話がぴったりだったからそんな的外れないい逃れするの？
君さっき改行連発してた人だよね？
もしかして、ファビョ（火病）った？ｗ
0632デフォルトの名無しさん
2005/06/29(水) 00:17:15と、ソースも読めない厨房が寝言をほざいてます（笑
無視無視
0633582
2005/06/29(水) 00:18:24＞他のレス番使った発言も一切するな。
これだけは言わせてもらうけど、漏れずっと名前欄に「582」って入れてる奴だよ。
他は俺の書込みではない。
0634デフォルトの名無しさん
2005/06/29(水) 00:19:24じゃぁさっさと読め。
読み終えるまで発言するな。
以下、1000番まで同様な繰り返し。(省略)
0635デフォルトの名無しさん
2005/06/29(水) 00:20:190636デフォルトの名無しさん
2005/06/29(水) 00:21:09くそ！ＤＬＬが無いと！俺のアプリがうごかねぇよ！
早く入れろよ！馬鹿！
もしかして、ＶＢのランタイムの方？ぷｗ
0637デフォルトの名無しさん
2005/06/29(水) 00:22:05それがおもしろいんだろ
もう、必死でしょう・・・最近のデザパタ厨
0638デフォルトの名無しさん
2005/06/29(水) 00:23:280639デフォルトの名無しさん
2005/06/29(水) 00:23:36現在、ソースも読めない素人が、話題をずらそうと必死に粘着中です。
粘着が巣に戻ってプルプルプルプル震えだすまで放置しましょう。
=================================================================
0640582
2005/06/29(水) 00:23:55君のための議論スレでもないのに自治活動お疲れさん。
つーか、ここはアンチデザパタさんと「デザパタは本当に必要か」議論するスレだと思ったんけど。
このスレに書込むには>>596を読めと？それはアンチデザパタさんが読むかな？
まあいいや、くだらないことだわ。
0641デフォルトの名無しさん
2005/06/29(水) 00:26:520642デフォルトの名無しさん
2005/06/29(水) 00:26:56それでもまだ自作自演で粘着してくる >>582のキチガイっぷりにひどく感心
0643デフォルトの名無しさん
2005/06/29(水) 00:29:30>それはアンチデザパタさんが読むかな？
それならそれでろくに理解しようともせずにデザパタ不要と喚いてる厨であることがわかるので好都合
0644デフォルトの名無しさん
2005/06/29(水) 00:30:51人間との言葉のやり取りに激しい飢餓感を感じ、
コケにされてもキチガイ扱いされてもスレにすがりつく疎外された人間
(例: ひきこもり、アル中患者、禁治産者)の類だろ、奴は
0645デフォルトの名無しさん
2005/06/29(水) 00:35:34てゆうか、はやく学校卒業しろよｗ
みんな深夜まで仕事しててマジでぶっちゃけそんな本読んでる奴いないからｗ
みんなそれぞれ家庭があったり他に趣味があったり、プログラム１つとっても設計に
時間を費やせる奴ってそんなにいないぞ。
２年ぐらいかけてGoF本読むのが精一杯な奴多いんじゃねーかな？（俺は学生の頃読んだけど）
現場でプログラマの仕事の作業量みれば、
こんなの（デザパタ）流行らねーってわかるんだよ。
それじゃなくても不勉強な奴多いのに。
こんなの読むわけないだろｗアフォかっつーのｗ
0646デフォルトの名無しさん
2005/06/29(水) 00:44:15キチガイの発言の特徴は、時代感覚がズレまくっているあたりだな。
例えば先週か今週、本屋に行って雑誌売り場覗いてれば、
そんなキチガイみたいな書き込みはしないと思うけど。
0647デフォルトの名無しさん
2005/06/29(水) 00:45:58もう最近ではそれと意識されずに使われてる事の方が多い。
0648デフォルトの名無しさん
2005/06/29(水) 00:49:04素人乙
0649デフォルトの名無しさん
2005/06/29(水) 00:51:35でも、アレは酷だよな。パターンを知らない人間には意図が読めない
から、無駄に持って回った複雑な設計にしか見えない。ｹﾞｷﾑｺﾞｽｗ
0650デフォルトの名無しさん
2005/06/29(水) 00:58:24まあ、現場で働いてる人間にそんなもん読む暇があるかどうかがわからない人間にはわからないだろうなｗ
たくさんの人に伝えなきゃ意味の無いものはそんなに複雑であっちゃいけないんだよ。
本を読め→読みました！→言っていることがわかりました。
なんて流れなかっただろ？
逆に俺の方から本の推薦をしたら、お前はきっと嫌がるだろう。
そんなこともわからない奴が設計について語ったって役に立たないことはわかるだろ。
誰もついていかないよ。
基本的に嫌じゃん。知識が無いのを馬鹿にされるのって。
必ず自分の知らない分野で仕返しされるじゃん。
個人ってそんなに万能じゃないじゃん。
お前も人を馬鹿にするとき、自分の知ってる分野をあげてそれについて語って、
相手がそれについての知識があさいとここぞとばかりに「勉強してくださいよｗ」とかいって
本を薦めて議論に勝った気になるのよくやってるじゃん。
これってされたほうの気持ち考えたことある？
この先、その調子で仲間とうまくやれる自信ある？
0651582
2005/06/29(水) 01:00:43まあそうだねぇ。時間ないよなぁ。最近、本買うのも慎重になってきたし。
変な本読まされて時間を無駄にする事ほど苦痛なものはない。
でもデザパタはなかなかいいもんだと思うよ。一部だけのパターンは。
>>649
おお、それ激しく同意。以前、勉強をかねてJavaのソースコード解析してたけど、
Socketクラス辺りとかﾜｹﾜｶﾗﾅｽｗｗｗ(SocketImplとかSocketImplFactoryとかの変なクラス)
デザパタ知ってああそうなんだってすげぇとか感動した。
0653デフォルトの名無しさん
2005/06/29(水) 01:09:07この腐りきったメンタリティはとても日本人の物とは思えない。
0654デフォルトの名無しさん
2005/06/29(水) 01:11:020655デフォルトの名無しさん
2005/06/29(水) 01:15:08同一人物じゃね？何か直感的にそんな気がした。時期的に一致しすぎてる。
0656デフォルトの名無しさん
2005/06/29(水) 01:16:22かかって来い(げらぷ
まじ。結構俺って万能なのね、下らない話題以外は
0657デフォルトの名無しさん
2005/06/29(水) 01:16:36訂正しる！
0658デフォルトの名無しさん
2005/06/29(水) 01:22:58社交辞令で「・・・自信ありません」くらいの事を言う可愛げはあるけど、
それが社交辞令だってことくらい、ちゃんと見抜け。
コミュニケーションの為に、相手が想定しているであろうプレゼンをする事で、
たとえそのプレゼンが偽りであっても、以降のコミュニケーションがうまく進む、
そういった効果を狙っているだけだよ、実際。
10年前に嫌々関わったOO分野だが、
いい加減 GoFも流し読みできないレベルの奴と関わるのには飽き飽きした。
もしOO分野に関わるということが、GoFも読めない猿にGoFを説得する事を意味するのであれば、
OO分野にはもうかかわりたくも無い
0659デフォルトの名無しさん
2005/06/29(水) 01:29:160660デフォルトの名無しさん
2005/06/29(水) 01:32:31にほんごのどくかいりょくがたりません。もっとがんばりましょう
0661デフォルトの名無しさん
2005/06/29(水) 01:37:00今cppll探して読んでみたが、実名らしき物をシグニチャに書いてるね。
メルアドも。
違う人だったらいけないのでここには晒せないが、もし本人だったら
間抜け過ぎだね。
0662デフォルトの名無しさん
2005/06/29(水) 01:39:50cppllってなんじゃらほい。
ここのOCaml厨房は、単にOCamlとMLって単語を連発するだけの池沼だよ。
0663デフォルトの名無しさん
2005/06/29(水) 01:42:29http://www.tietew.jp/cppll/
ここ。
C++のML。
後は悪いけど、自分で探してちょ。ヒントは、ごく最近の投稿。
0664デフォルトの名無しさん
2005/06/29(水) 01:42:45むしろ >>655, >>651あたりが
この板でOCaml厨と呼ばれている厨房の希ガス
0665デフォルトの名無しさん
2005/06/29(水) 01:46:16OCaml厨呼ばわりするのもなかなか厨房じみた妄想だ。
今現在２ちゃんで、「ML」と「OCaml」というキーワード使って荒らしやってるのは、
かつてRubyやHSPで荒らしやってたキチガイだろ。
0666デフォルトの名無しさん
2005/06/29(水) 01:47:56http://www.tietew.jp/cppll/archive/12065
こいつのことか？
0667デフォルトの名無しさん
2005/06/29(水) 01:51:40な言語について熱く語る香具師は、数えるほどしかいないね。
２ｃｈ内なら同一人物の可能性もあるけど。だからどうしたって
聞かれると、別に何もないけどな。
0668デフォルトの名無しさん
2005/06/29(水) 01:54:04そうかぁ？
俺が学生の頃は、Haskelｌが動くPCなんてなかったから、
OCamlかGoferで自己学習・・・ってのがデフォだったけどね。
0669デフォルトの名無しさん
2005/06/29(水) 01:54:46明らかにレベルが違うじゃん。
そもそもの不満点(というか単なる愚痴に見えるが･･･)からして、コードが
書けない人間からは決して生まれない類のものだし、その改善法と問題
点も把握できてる。
具体的な事は何一つ書けない某彼と一緒にするのは、あまりにも酷だ。
0670デフォルトの名無しさん
2005/06/29(水) 01:58:44理由：OCamlに関する話題は、全て同一人物が行っていると妄想する程のキチガイだから。
0671デフォルトの名無しさん
2005/06/29(水) 01:59:260672デフォルトの名無しさん
2005/06/29(水) 02:00:55具体的に何が面白いか、説明してみな。
0673デフォルトの名無しさん
2005/06/29(水) 02:10:52それが人に物を聞く態度かい。横柄な奴には教えてやらないよ。ベーだ。
0674デフォルトの名無しさん
2005/06/29(水) 02:12:290675デフォルトの名無しさん
2005/06/29(水) 02:22:38あなたの発言は、一昨日昼飯を一緒に食った人物と同じ、
特徴的な思考パターンが見られるので、非常に興味深い。
その件について、いずれ話し合おう
0676デフォルトの名無しさん
2005/06/29(水) 02:25:58>>650が現れるのは、非常に興味深い現象である。
0677デフォルトの名無しさん
2005/06/29(水) 02:27:56それも今度説明しましょう。リアルの方で
0678デフォルトの名無しさん
2005/06/29(水) 09:12:14リアルで特定されてる？ﾜﾛﾀ!!
0679デフォルトの名無しさん
2005/06/29(水) 12:42:54実際にソース組む人の立場になれば、未だに構造化手法も
有効だし、オブジェクト指向も大切だし、デザインパターンも、
亜蛇煎るプログラミングも有効だし、UMLも有効だし、
フローチャートも有効だし、ウォータフォールモデルも有効だし、
データモデリングも有効だし、どれ一つを取っても捨てていい
技術は無いんだよね。
もちろん、今時フローチャートでシステムレベルの記述を
する事は避けた方が良いし、フローチャートじゃあ記述出来ない
けれど、メソッドの中の人を記述する必要が有る時にはやっぱり
フローチャートが一番しっくりくるし、メソッド一つ一つを見れば、
構造化で培ってきた関数化の技術が生きるしさ。
新しい技術は取り入れるもので、捨て去るのはなかなか難しいよ。
もちろん、GoFのパターンカタログを一生懸命勉強すればデザインパターン
を身に付けられると思う馬鹿は、幸せに生きてれば良いけど。
0680デフォルトの名無しさん
2005/06/29(水) 13:28:150681デフォルトの名無しさん
2005/06/29(水) 13:29:09いらねーよこんなの orz
0682デフォルトの名無しさん
2005/06/29(水) 13:31:580683デフォルトの名無しさん
2005/06/29(水) 13:37:45お前何才よ？ロートルプログラマか？ｗ
年取りすぎて会社じゃもうどこも雇ってもらえないから、家で妄想の毎日か。
0684デフォルトの名無しさん
2005/06/29(水) 14:40:13679じゃないけど、結構あるよーこういう現場。
まだ679は新旧混合で選択しようってんだからいい方だよ。
0685デフォルトの名無しさん
2005/06/29(水) 14:47:14あれはホントにお絵かきで終わっちゃうからなぁ。
PAD図だったらプログラムの構造が保たれているからまだマシなんだけど。
# でも実際には使ってないけどね。
UMLのクラス図なんかもリバースエンジニアリング出来ないとお絵かきで終わっちゃう。
0686デフォルトの名無しさん
2005/06/29(水) 19:22:49はっきり言ってアセンブラならまだしも
今時の高級言語なら、フローチャートに落とすことによって
何かがわかりやすくなったりすることはありえない
0687681
2005/06/29(水) 20:35:12C で PAD を教えてきた先生も居たけど、ぶっちゃけ PAD だと関数出てきたあたりからお手上げ状態
構造化チャートは、オブジェクト指向まで考えるともう使えないでし
折角なんで愚痴らせてもらうと
ハード系の某先生「これからは最低でもオブジェクト指向が出来ないと」
んで、出てきたのがコレ
class Sample {
public void input(String filename) { /* filename で指定したファイルを読み込む */ }
public void process() { /* input で読み込んだデータを処理 */ }
public void output() { /* process で書き換えたデータを表示する */ }
}
……まあ、若い先生方にはしっかりした人が多いんで、まだ救いがあるんですが OTL
0688デフォルトの名無しさん
2005/06/29(水) 21:44:54結構同意。
0689デフォルトの名無しさん
2005/06/29(水) 22:22:42ってオチがままある
0690デフォルトの名無しさん
2005/06/30(木) 01:12:18状況によっては古い技術の方が、効力を発揮したりするしね。
色々な知識を持って、あらゆる状況に対応できることが大切だと思う。
0691デフォルトの名無しさん
2005/06/30(木) 01:27:38Cで構造体のメンバとして関数ポインタ持たせて
偽多態みたいなのは良くやるが、
クラスや継承までエミュレートしたことはないなあ。
後、構造体の先頭レイアウトだけ合わせてポインタ渡しとかはありがちだな。
なんかOOというより苦し紛れのテクニック、という気分もするが。
0692デフォルトの名無しさん
NGNGCしか使えない現場なの？
0693デフォルトの名無しさん
2005/06/30(木) 01:37:35少なくとも俺が入社したころ（そんなに昔ではないのだが）は
Windows3.1、VC++1.0が現役だったし
C + SDKで組まれてるプログラムが珍しくなかったんですわ
0694デフォルトの名無しさん
2005/06/30(木) 01:39:02その手の仕事はCが普通じゃまいか。
別に制御屋さんとかじゃなくてもC触る機会、結構あるでよ。
0695デフォルトの名無しさん
NGNGよほど速度や資源を求めない限りはCオンリーは嫌ぽ。
# apacheのsoはよくわからんす。
0696デフォルトの名無しさん
2005/06/30(木) 02:19:55apacheのモジュールは、いわゆるプラグインみたいなもんだす。
soはshared object(library)、いわゆるDLLね。
アプリじゃなくてDLL書く場合はCで書くことは珍しくないと思うよ今でも
0697デフォルトの名無しさん
2005/06/30(木) 02:28:33DLL書く場合でもC++のが楽でいい。
0698デフォルトの名無しさん
2005/06/30(木) 02:32:47C++だとスタートアップコードが必要になったりしてちょっとヤじゃない？
もともとC++用のDLLならいいけれど
Cインタフェースを公開するDLLなら、Cで書いて、しかもlibcに依存しない
形にしたい
0699デフォルトの名無しさん
2005/06/30(木) 08:39:28一刻も早く地上から消え去って欲しい。
0700デフォルトの名無しさん
2005/06/30(木) 09:42:29Cと一緒にお前も消えろ。
0701デフォルトの名無しさん
2005/06/30(木) 14:20:49というか、あーでもない、こーでもないって、
ころころ設計変えるのが、楽しいのに。
漏れの楽しみ取らないでくださいよ。
0702デフォルトの名無しさん
2005/06/30(木) 14:36:11いもしない人間を想定して適当なことを言うのはやめましょう
0703デフォルトの名無しさん
2005/06/30(木) 15:11:34学生時代、pad2psというソフトをつかってソースからPAD図生成してました。
レポート書くのに助けられたなぁ・・・今は使ってないけど。
0704デフォルトの名無しさん
2005/06/30(木) 21:03:09５行で終わるようなものを５０行ぐらいかけてなにやってんだか分からないようなダサダサソースはうんざりするでしょ。
0705デフォルトの名無しさん
2005/06/30(木) 21:17:370706デフォルトの名無しさん
2005/07/01(金) 01:45:06それはCも使えてないってことだろ。
0707デフォルトの名無しさん
2005/07/01(金) 02:00:070708デフォルトの名無しさん
2005/07/01(金) 09:37:08じゃあおまいさんはC++もjavaもC#も使えるような環境において積極的にC言語を選択するか？
0709デフォルトの名無しさん
2005/07/01(金) 10:05:400710デフォルトの名無しさん
2005/07/01(金) 17:07:331)shell等の外のプログラムから部品として呼び出すことを想定したコマンド・
フィルタ風のプログラムなら、少なくともJavaやC#は「絶対に」使わない。
ツールボックスアプローチの部品としては、起動遅いのは致命的。
2)C向けのDLLは大抵Cで書くな。
libc使ってしまうと、クライアントコードとlibcのバージョン合わせる必要が
生じてウザい。これ、Win32の話ですが。
3)俺は書かないけど、オープンソースでなるべく広い環境で使われたいと願う
コードを記述するなら、Cのが今でも多いだろ。環境をそもそも特定できない
から、だが。
0711デフォルトの名無しさん
2005/07/01(金) 17:09:10なるほど。そうかそうか、よーくわかったぞ。それは面白い考えだ。
0712デフォルトの名無しさん
2005/07/01(金) 17:28:26せっかく真面目に答えてやっとるのになんだ、その人を小ばかにしたような
態度は。それで優位に立ってるつもりなのかね、チミは。
反論があるならもっとマジメにやれ。
0713デフォルトの名無しさん
NGNGインターフェースはCで提供して、
実装はC++ってのもやっぱ無理ですか？
0714デフォルトの名無しさん
2005/07/01(金) 18:19:01だってお前の意見になんか全然興味ないもん。
0715デフォルトの名無しさん
2005/07/01(金) 18:33:41可能か不可能かといえば可能。extern "C"すればいいだけだから。
0716デフォルトの名無しさん
2005/07/01(金) 18:34:20なら下らん一言でスレ汚さずに単にスルーしろよ
0717デフォルトの名無しさん
2005/07/01(金) 18:39:47うるせぇーよ。ぼけ、氏ね ( ´∀`)
0718デフォルトの名無しさん
2005/07/01(金) 18:46:300719デフォルトの名無しさん
NGNGそれでも>>710の言うようなlibcのバージョン合わせる必要ありますか？
>>718
嫌いじゃないが。
0720デフォルトの名無しさん
2005/07/01(金) 20:36:27OOPな時点でツー〜ーチなん違うん？
0721デフォルトの名無しさん
2005/07/01(金) 20:46:21libcのバージョンは、合わせる必要はある。Cを使おうがC++を使おうが
関係ない。Cの方がlibc非依存にしやすいというだけ。
たとえばDLLが(VC++6以前の)MSVCRT.DLLを利用しているならば、
クライアントプログラムもMSVCRT.DLLを用いなければならない。
ま、実際には合わせなくとも動作する場合もある。DLLのインタフェース
や何やってるかによるんだが。
ファイルポインタ、ファイルデスクリプタ、ロケール、errnoのような
CRTオブジェクトの受け渡し、あるいは一方でmalloc()したメモリの
他方でのfree()、といったことをやる場合は、バージョン合わせないと
完璧にマズい。
0722デフォルトの名無しさん
2005/07/01(金) 21:05:28UNIXのツールボックスアプローチってのは、シェルという糊言語を用いて、
部品になる小さくて独立したプログラム群を組み合わせることで
仕事を実現する手法のことなんだが。
プログラムが分かれてるから完全に疎結合。で、標準入出力、パイプ、
コマンドライン引数、戻り値といった単純でwel-definedな仕組みを用いて
それを組み合わせていく。
概念的にはOOとは全く関係ないし、Smalltalkとか見ても、OOはむしろ
モノリシックで巨大なものを指向する傾向があるんじゃないか。
むしろLISPに似ているというか。
0723デフォルトの名無しさん
2005/07/01(金) 21:17:37＞概念的にはOOとは全く関係ないし
疎結合という面と、独立したプログラムという面から見て、オブジェクト指向に通じる物があるかと思ってた
0724デフォルトの名無しさん
2005/07/01(金) 21:20:50クラスは>>722の中段で書かれてる要素を全て満たしてると思う。
「である。」とは思わないけど、「の様な振る舞いを持たせる事もできる。」と思う。
0725デフォルトの名無しさん
2005/07/01(金) 21:53:44コマンドパターン風に実装したクラスがプログラムのかわりで、
それを実行時ロードとかまあそんな感じかな。
0726デフォルトの名無しさん
2005/07/01(金) 21:58:220727デフォルトの名無しさん
2005/07/01(金) 22:02:59すまん大して興味が無いのでちゃんと見てないんだが
要するに、コマンド実行するたびにVMロードされちゃたまらんワケで、
同一VM上でコマンドを実行するのが、Javaで「使い物になる」シェル風の
環境を作る大前提。
find . -name '*.html' -exec rm {}
とかそんなことをやると、それこそうんざりするほど大量の子プロセスが
生成されて実行されるのがシェルの世界だからな。
その辺は、antのタスクの考え方と同じ。要するに、インタラクティブに
実行できてmake作業に特化してないant＋αみたいなもんじゃないかな。
0728デフォルトの名無しさん
2005/07/01(金) 22:11:51あれはCで書かれてるから、Javaみたいに実行時ロードできないんだよな
ってどんどんスレ違いの世界に
0730スレ違いですが
2005/07/02(土) 01:06:25・こんなんあったね。漏れも一個くらいはインストールした覚えがある。
JDistro jsh : A Un*x-lke shell written in pure Java. Java Web Start対応
http://www.jdistro.com/jsh/
COLLIN Gerard's jsh: the opensource java application launcher ! Java Web Start対応
http://gerard.collin3.free.fr/
TeaShell: 複数のJavaアプリケーションを一つのJavaVMで動かすJavaシェル
http://www.vector.co.jp/soft/other/java/se089271.html
・その他国内某所で Java シェルOS開発というスレが立ち上がってるのを発見したんだけど、
そこの1、一体何作ろうとしてんのか、よくわかんないや(OSによらず使い慣れたシェル環境を提供するって何？)
・JDK1.6では、Oracle JavaVM流のapplication partitioningの仕組みが導入されるそうなんで、
JavaVMプロセスを多数起動しなくても、いろいろな事がやりやすくなるね。(本来はAppServer向け機能だけど)
0731デフォルトの名無しさん
2005/07/02(土) 01:17:07少なくともこのスレと関連のあることをいってくれないと。
リンクの貼り付けだけだと荒らしに見える。
0732本ｽﾚ住人
2005/07/02(土) 04:01:40UNIXシェルとコマンドによる祖結合プログラミングは、
デザインパターンと並んでソフトウェア工学上重要な話題です。
Javaにおいてどのような試みがなされているか、
そして、Javaサーバ〜Webサービスの基盤 (アプリケーション・パーティショニング)が、
UNIXシェルの基盤にもなりうる、という話題を振ったつもりですが。
もしかして、ここは似非スレだから、似非話題以外はスレ違いなのかな（藁
0733デフォルトの名無しさん
2005/07/02(土) 08:27:03>OSによらず使い慣れたシェル環境を提供するって何？
OSによるshellの方言を吸収しようという意味じゃないすか。
0734デフォルトの名無しさん
2005/07/02(土) 11:19:11>デザインパターンと並んでソフトウェア工学上重要な話題です。
だから何？ｽﾚ違いに変わりない事に気付けよバカ。
0735デフォルトの名無しさん
2005/07/02(土) 12:29:02気付いてないのは恐らく君だけ
0736デフォルトの名無しさん
2005/07/02(土) 13:17:27早く本スレ帰ればいいじゃん。
過疎スレ帰れよｗ
＃デザパタなんてどうせやってる奴いないからこないだろうけどｗぷｗ
>>731と>>734は別人ね。俺は>>731。
0737デフォルトの名無しさん
2005/07/02(土) 14:58:05どうでもいいレスでageてるし
0738デフォルトの名無しさん
2005/07/02(土) 15:56:530739デフォルトの名無しさん
2005/07/02(土) 16:17:40じゃあ、早く本スレ帰んな。
0740デフォルトの名無しさん
2005/07/02(土) 16:18:59http://pc8.2ch.net/test/read.cgi/pcnews/1120271067/
また中国です。
0741152
2005/07/02(土) 16:23:42そんなことしてる暇あるならコード書けってかんじだよなぁ
0742デフォルトの名無しさん
2005/07/02(土) 16:44:15それ、東アジアニュース+でガイシュツだよ。
中国と韓国からのケーブルは切断しなきゃダメだね。
0743デフォルトの名無しさん
2005/07/02(土) 17:20:280744デフォルトの名無しさん
2005/07/02(土) 19:21:30なんつーか、どっちも死ねよと。
0745デフォルトの名無しさん
2005/07/02(土) 21:52:290746デフォルトの名無しさん
2005/07/03(日) 18:40:06賛成の方も反対の方も、このスレで自分は賛成か反対かをお書きください。
プログラム技術板に強制ID制を導入すべきか否か
http://etc4.2ch.net/test/read.cgi/vote/1118144381/
理由などの記入は別に構いません。
<<賛成>>か<<反対>>かだけ御記入頂ければ結構です。
ちなみに、当たり前ですが運営の方にIPが見えているので、1日ごとにIDが変わるからといって多重投稿しないでください。
0747デフォルトの名無しさん
2005/07/10(日) 14:08:52ここに粘着してた頭のおかしいデザパタ信者が集中砲火浴びたっぽいなｗ
いつも都合の悪い話題が出ると自分の発言を軌道修正するから
あいつ嫌われるだろうなと思ったら滅多撃ちにされてるなｗ
0748デフォルトの名無しさん
2005/07/10(日) 14:35:430749デフォルトの名無しさん
2005/07/10(日) 16:25:41いや、向こうのスレで
2005/06/23(木) 23:12:19
周辺から糞化してたから見て無かったんで・・・
0750デフォルトの名無しさん
2005/07/10(日) 16:28:28つか、あのスレ自体、信者vsアンチの構図が無くなった時点で全く意味がない。
デザパタ自体は誰も仕事でなんか使ってないから、デザパタ自体のことを語るのはおもしろくない。
0751デフォルトの名無しさん
2005/07/10(日) 17:21:15仕事してる俺たちゃ、
あんたみたいな無職野郎と違って
暇じゃないのよ
0752デフォルトの名無しさん
2005/07/10(日) 20:26:09J2EEアプリやったことがないのに
＞ デザパタ自体は誰も仕事でなんか使ってない
なんて断言するなよ。無知丸出し。
0753デフォルトの名無しさん
2005/07/10(日) 20:33:18JavaAPI のレベルでも、既にパターンを見つけることも出来るんですが
0754デフォルトの名無しさん
2005/07/10(日) 20:42:17APIで使われているかどうかじゃなくて、自分が作成するアプリの設計に適用するかどうかを言ったつもりだった。
まあ、ヤツはJavaすらやったこと無いんだろうけど。
0755デフォルトの名無しさん
2005/07/10(日) 20:53:25ああん了解
0756デフォルトの名無しさん
2005/07/10(日) 21:04:29もっとも、趣味グラムの場合、単に完成を急ぎたいからそうするだけな
んだけど・・・・・・要はcommons-loggingの悪用と同じ。
詳細決まってないとこは空箱でも詰めとけｗ
0757デフォルトの名無しさん
2005/07/10(日) 21:06:19誰もというのは言いすぎだが、ほぼ正しい。
１．使ってないやつ 70%
２．使ってプロジェクトに混乱を起こすやつ 25%
３．正しく理解して設計に応用するやつ 5%
もちろん俺は３
0758デフォルトの名無しさん
2005/07/10(日) 21:09:590759デフォルトの名無しさん
2005/07/10(日) 21:13:49１．使わされてる奴：70%
２．使わせてる奴：20%
３．（ ﾟдﾟ）ﾎﾟｶｰﾝ：10%
もちろん俺は１orz
0760デフォルトの名無しさん
2005/07/10(日) 21:20:250761デフォルトの名無しさん
2005/07/10(日) 21:27:59大規模プロジェクトでは「知らずに使われてる奴」は多そうだね。
0762デフォルトの名無しさん
2005/07/10(日) 21:38:19継承、多態なんてまずは使わないで設計できるかを考えるべき。
その上で、どうしようもない場合は、継承、多態を使う。
で、継承、多態を使う場合も、基本的なTemplate Methodとかはともかく、
基本的にデザパタは使わないで設計を考える。
それでも必要の時だけデザパタを使うと。
極力シンプルを目指して、リファクタリングをして、継承、多態を減らすと。
つまり、デザパタは基本的に不要！
0763デフォルトの名無しさん
2005/07/10(日) 21:41:19＞どうしようもない場合は、継承、多態を使う
「構造が簡潔になる場合は〜」 に訂正して欲しいこと以外は同意
0764デフォルトの名無しさん
2005/07/10(日) 21:47:170765デフォルトの名無しさん
2005/07/10(日) 21:48:270766デフォルトの名無しさん
2005/07/10(日) 22:42:491987 OOPSLAのGamma以前のレベルで進化が止まってるわ。
>>765
あんたもデザパタなんて保守的な事言わず、J2EEパターン、.NETパターン、PoEAAにESBって
どんどん話題振らなきゃ。
0767デフォルトの名無しさん
2005/07/10(日) 22:53:18それらはデザインパターンとは呼ばないのか？
0768デフォルトの名無しさん
2005/07/10(日) 22:54:370769デフォルトの名無しさん
2005/07/10(日) 22:57:07によれば、パターンの適用範囲はデザインだけではないね
0770デフォルトの名無しさん
2005/07/10(日) 23:08:00一応、口ではそんなんデザパタに含んでると反論するが、
実際のパターン名はシングルトンにファクトリー、テンプレートメソッドくらいしか出てこないのが、
隔離スレ・クオリティ（藁
0771デフォルトの名無しさん
2005/07/11(月) 01:10:18議論を持ち出せば「お前、レベルが低い」とか、馬鹿だなんだと罵り、
どこのサイトのなんの記事を熟読してから書き込めなどといって書き込み排除。
別にいいじゃんレベル低かろうが。
もっと気軽な議論スレがほしい。
正直この状態じゃ何も議論できない気がする。
デザパタ初心者スレでも建てっかな。
0772デフォルトの名無しさん
2005/07/11(月) 01:11:570773デフォルトの名無しさん
2005/07/11(月) 01:13:16デザパタ => オブジェクト指向
に変えても読めてしまう。
そういうことですか？>>762
0774デフォルトの名無しさん
2005/07/11(月) 01:35:37>正直この状態じゃ何も議論できない気がする。
お前の脳みそはまだそんなこと考えてるのかとｗ
>>757
>３．正しく理解して設計に応用するやつ 5%
これは嘘。
5%もいるわけない。
デザパタはネタ。
実際のプロジェクトでは使ってるところは存在しない。
0775デフォルトの名無しさん
2005/07/11(月) 01:37:22何のための隔離スレだかわかってる？
0776デフォルトの名無しさん
2005/07/11(月) 01:43:27そんなわけない。
俺がいる会社でも使ってるし、知り合いのいる会社でも普通に使うし。
ホントに無知だな。かわいそうに。
0777デフォルトの名無しさん
2005/07/11(月) 01:56:08はじめはアンチだけをここに隔離する目的だったんだけど、
アンチがいなくなったら本スレが過疎スレになっちゃったから今となっては微妙一色ｗ
折角、隔離スレとしてアンチ同士で楽しくやろうと思ってたのに
本スレが過疎スレになったから信者がこっちにまできて非常に邪魔。
はっきりいうけど、本スレが盛り上がらないのは、
本当はデザパタなんて誰も使ってないから、話す話題がない。
技術としても不確定で誰が正しくて間違っているか特定させる手段が無いから、
パターンブームにのってエセ研究者気取りがいいたい放題。
議論も「いかにして相手を言い負かすか」が焦点になっててまったく本質に触れようとしない。
>>776
君こそ、知らないの？
デザパタなんて狭い世界の話なんだよｗ
0778デフォルトの名無しさん
2005/07/11(月) 01:56:48そんなにいうなら本スレ盛り上げてきてよｗ
ま、誰もこないだろうけどさｗ
0779デフォルトの名無しさん
2005/07/11(月) 02:10:51「存在しない」から「狭い世界」へ修正ですか？ｗ
次は「特定の分野では使われている」に修正して
さらには「○○では使われていない」に修正ですか？
どこかの議員さんみたいですね。
0780デフォルトの名無しさん
2005/07/11(月) 02:11:39だって、使って当たり前、使われ方もほぼ決まっているのに何を今更議論するのさ？
0781デフォルトの名無しさん
2005/07/11(月) 02:13:08＞ はじめはアンチだけをここに隔離する目的
ちがうだろ？
デザパタが必要か要らないかの議論をするのがこのスレの目的。
本スレはデザパタありきでの議論が目的。
0782デフォルトの名無しさん
2005/07/11(月) 02:37:38荒らし風情がひらきなおるんじゃねぇ〜よ、クズめ
0783デフォルトの名無しさん
2005/07/11(月) 02:40:48某スレで、またぞろakon叩きするバカが発生してたけど、
あんたらのコミュニティは一体どうなってるの？
0784デフォルトの名無しさん
2005/07/11(月) 02:47:100785デフォルトの名無しさん
2005/07/11(月) 02:59:150786デフォルトの名無しさん
2005/07/11(月) 03:10:490787デフォルトの名無しさん
2005/07/11(月) 03:14:460788デフォルトの名無しさん
2005/07/11(月) 03:36:40そーゆー前向きな活動は本来、
ML上で署名付きで行うべきものではないか？
その署名が偽りであったとしても、誰も気付かないのだし。
匿名掲示板で本音のぶつかり合いを期待するのは、
虫のいい考えだと思う。blog立てろよ(ｵﾚﾓﾅｰ
0789788
2005/07/11(月) 03:43:05・情報システム板
・プログラム技術板
・プログラマー板
・ゲーム製作板
・セキュリティ板
他
を常時巡回して荒らしをやっているんで、
多くの人が、ここではもうコミュニケーションが機能しないものとして見放している。
考えても見ろよ、あれだけあちこちで話題になっているRubyのスレが
この板に一個もない。原因は何故だと思う？
例の粘着とおぼしき人物が「Rubyキチ」とかいうコテハンで何年もしつこい荒らし行為を行って、
さすがのMatzも手を引いたからだ。
こんなゴミタメで、鬱憤晴らしと気まぐれな独り言以外、何ができようか？
なんちゃって
0790788
2005/07/11(月) 03:46:34ちょっと考え直してみたら、俺もよくわけの判らんレスを付けてしまった。
貴方が「気楽に議論できるデザパタスレが欲しい」と思うのなら、立てたらいい。
掲示板のスレ立て制限以外、誰もスレ立てを制限する事などできないのだから。
0791デフォルトの名無しさん
2005/07/11(月) 07:20:45その割には本スレで馬鹿と盛り上がってたじゃんｗ
0792デフォルトの名無しさん
2005/07/11(月) 07:39:21こっちでもあっちでもまともな議論はできていない。
0793デフォルトの名無しさん
2005/07/11(月) 07:48:40>こっちでもあっちでもまともな議論はできていない
まともな議論なんて無駄。
デザパタ自体の存在意義について触れた時点で荒らしがはじまる。
0794デフォルトの名無しさん
2005/07/11(月) 08:24:22世の中に役に立つ概念があるというだけで、
腹が立つんだろうね(藁
0795771
2005/07/11(月) 14:41:48新しいスレ建てるほどのことではないんだよね。
ほぼ重複だし。叩かれそう。なのでやっぱりいいです。
>>792
馬鹿でも、どうしようもない議論でもいいじゃないか。
そこをおまいのような理解してる奴がうまく啓蒙してあげればいいんじゃないか
>>793
まあ馬鹿同志、無駄な議論してるんで生暖かく見守っててくだされヽ（´ー｀）ﾉ
0796デフォルトの名無しさん
2005/07/11(月) 14:55:100797デフォルトの名無しさん
2005/07/11(月) 15:11:19他の人が迷惑する。
0798デフォルトの名無しさん
2005/07/11(月) 15:28:470799デフォルトの名無しさん
2005/07/11(月) 15:30:240800デフォルトの名無しさん
2005/07/11(月) 16:53:59お前のルールに他の人間を全部従わせるつもりか。カス。
0801デフォルトの名無しさん
2005/07/11(月) 17:03:490802デフォルトの名無しさん
2005/07/11(月) 17:41:48>IDが必要なのはこのスレだけだろ。
そうでもない。
0803デフォルトの名無しさん
2005/07/12(火) 23:36:08本スレ盛り上げろよな。まあ、おまえらアフォどもには無理だろうけど。
0804デフォルトの名無しさん
2005/07/12(火) 23:45:43こんなやり方あるんだね、みたいな。そんな軽い気持ちで使えばイイんじゃねーの？
ほとんどの場合でそのまま使えねーんだし。
0805デフォルトの名無しさん
2005/07/13(水) 00:21:37お前ほどアフォではない。残念。
0806デフォルトの名無しさん
2005/07/13(水) 00:24:52おまいほど暇人でわない
0807デフォルトの名無しさん
2005/07/13(水) 00:35:21元から話題が無い（涙
0808デフォルトの名無しさん
2005/07/13(水) 00:41:35まぁ話題がない、などと言う奴は中身からっぽなんだろうが。
Martin Fawlerの一連の著作やら、DSLやMDAとの絡みやら、
設計レベルのパターン言語について語るべき事はたくさんある。
問題は、書き込みが少ないこと。
0809デフォルトの名無しさん
2005/07/13(水) 00:42:58あと、書き込み少ないって、某荒らしが粘着してるネタスレと比較しての話だ。
某荒らしが一切書き込みをやめてくれれば、また盛り上がれるスレだと思うよ。
0810デフォルトの名無しさん
2005/07/13(水) 01:16:57やはりお前らアフォどもに本スレを盛り上げるのは無理ってことだな。
隔離スレで内容のない話をしてろ、アフォども。
0811デフォルトの名無しさん
2005/07/13(水) 02:14:11勝利宣言か。本当に日本人ですか？
0812デフォルトの名無しさん
2005/07/13(水) 23:08:14信者だって本当に実在しているのかも疑問。
0813デフォルトの名無しさん
2005/07/14(木) 11:18:53>デザパタ使ってる奴なんてハナっから存在しない。
という事にしないと、理解できない自分がｶﾜｲｿｽ、と。
0814デフォルトの名無しさん
2005/07/14(木) 11:40:110815デフォルトの名無しさん
2005/07/14(木) 12:57:250816デフォルトの名無しさん
2005/07/14(木) 20:00:390817デフォルトの名無しさん
2005/07/14(木) 21:14:38シングルトンはもういいってｗ
0818デフォルトの名無しさん
2005/07/14(木) 21:44:28君がそれしか知らないのは判ったから。
0820808
2005/07/15(金) 01:30:190821デフォルトの名無しさん
2005/07/15(金) 07:45:18オマエモナーｗ
0822819
2005/07/15(金) 09:59:55いや、あの、きみの>>808の一行目のレスするあたり対してレベルが変わらない気がｽ('A`)
きみのその一言がなければ、おお。とか思った。思われただろうに。
つか、>>820自体のレスも対してレベ（略
>>821
（ﾟ∀ﾟ）ｵｳﾖ!!
0823デフォルトの名無しさん
2005/07/15(金) 11:06:37Abstract Factoryでした。
まあこれも使いやすい方なので
じまんにはならんでしょうけど！
0824デフォルトの名無しさん
2005/07/15(金) 14:35:21釣られて出てくる「くだらない煽りヤロウ」。
0825デフォルトの名無しさん
2005/07/17(日) 18:36:19interpreter パターンを知らずに使ってる人は意外と多いかもしれない
なにせ、
Window_X = 120
Window_Y = 100
とかの初期化用スクリプト組んで、config.ini って名前付けるけでも interpreter の思想は受け継がれているからな
【この程度の事で interpreter パターンなどと勿体ぶった言い方を俺はしたくないですが】
0826デフォルトの名無しさん
2005/07/17(日) 21:32:52お前は本当になにもわかってねぇウンチングスタイルだな。
0827デフォルトの名無しさん
2005/07/17(日) 22:26:33再帰下降型パーサなら簡単に書けるけど、
正規表現のように状態遷移マシンつかったり、
JavaやCのようにあるていど大きな規模の構文を効率的に扱うには、
ちょっと寸足らず・・・
つか、実装は別の方法でやって、表面的なインタフェースはinterpriterパターンといったところか。
ってGoFがゆってた
0828825
2005/07/18(月) 18:30:54『処理内容のハードコーティングを避け、必要ならカスタマイズ可能に』
ってのが第一条件で、別に実装方式は問わなかった筈
その気になれば BF を組み込む程度でも interpreter になりそうで
0829デフォルトの名無しさん
2005/07/18(月) 18:35:170830デフォルトの名無しさん
2005/07/18(月) 22:39:54BNF (Backus-Naur Form)じゃなくて？
0831デフォルトの名無しさん
2005/07/18(月) 22:48:10http://pc8.2ch.net/test/read.cgi/tech/1036013915/l50
0832デフォルトの名無しさん
2005/07/19(火) 00:19:44うほっｗｗｗ
0833デフォルトの名無しさん
2005/11/24(木) 02:13:02開発ってか設計がめんどうなんだけど・・・
0834デフォルトの名無しさん
2005/11/24(木) 08:00:24VCしかないシステムの拡張やらされた時には前任者に殺意を覚えたぞ。
0835デフォルトの名無しさん
2005/11/24(木) 08:35:41一度、プログラマが10人以上いるプロジェクトで
すべての処理を一つのクラスにつっこむ実装をしてみるとわかるよ
0836デフォルトの名無しさん
2005/11/24(木) 14:05:48> デザパタで成功してるのはstlのイテレータくらい。
なんでイテレータだけなんだ？
JavaのIteratorのほかにObserver、I/OのDecoratorとかはどうよ？
> MFCやWTLはチェーンやらデコレータやらがとっちらかってて、
> どうしてもキショイコードになる。
0837デフォルトの名無しさん
2005/11/24(木) 16:50:37M：機能本体
V：出力
C：入力と制御（メインループとか）
で良いの？
正直、よく分からんのだが・・・
0838google って知ってる？
2005/11/24(木) 19:03:03調べる気のない人は
一生解らないままでいて下さい。
0839デフォルトの名無しさん
2005/11/27(日) 01:16:05ﾋﾄﾞｽ
0840デフォルトの名無しさん
2005/11/27(日) 08:33:23デザパタ信者ってこんなのばっかだよ。
教えないんじゃなくて「知らない」or「自分の勝手な解釈で覚えたと思い込んでる」から説明なんてできない。
もし、説明なんかして他の人間と解釈が違っていたら、自分が理解していないことがばれちゃうから、
そういう危ない橋は渡らないのが奴等の処世術。
デザパタなんてオブジェクト指向すら無視してるんだから、当然オブジェクト指向すら理解してない。
で、なんだかんだ苦しくなると「デザパタは全く新しい〜」とか御馬鹿なこと言い出す始末。
これが前スレからの流れ。
0841デフォルトの名無しさん
2005/11/27(日) 08:49:45∧∧ / :
(,,ﾟДﾟ/ :
＿ / つ/） ＿ :
〜（⌒）__） /| ,, :
￣￣￣￣￣|/,,,
〜〜〜〜〜〜〜〜〜〜〜
0842デフォルトの名無しさん
2005/11/27(日) 15:34:19による自作自演か。
>>838の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね。
0843デフォルトの名無しさん
2005/11/27(日) 16:04:25による自作自演か。
>>840の言うとおりなんだけどね。
ちょっと調べればMVCで実際に設計する方法がわかるのにね
0844デフォルトの名無しさん
2005/11/27(日) 17:29:00調べても理解出来なかった というパターンもありうる。
0845デフォルトの名無しさん
2005/11/27(日) 17:33:38我々は選ばれた人間なのですね！
0846デフォルトの名無しさん
2005/11/27(日) 22:59:43一人神グラマがいれば、そいつを基準に周りがまねたら良いから不要
一人ではまだ頼りない感じの人達をまとめ上げるために必要なものだ
0847838
2005/11/28(月) 12:18:29> >>838==>>842
残念ながら違いますよ。間抜け。
> ちょっと調べればMVCで実際に設計する方法がわかるのにね
判っているなら、そうしなさい。
0849デフォルトの名無しさん
2005/11/30(水) 23:57:52∧∧ / :
(,,ﾟДﾟ/ :
＿ / つ/） ＿ :
〜（⌒）__） /| ,, :
￣￣￣￣￣|/,,,
〜〜〜〜〜〜〜〜〜〜〜
0850デフォルトの名無しさん
2005/12/01(木) 05:51:30V vsialbasic使いは
C CやC♯は使えません。
MVCで
webは何となく分かるけど
javaのクラス設計で考えたら
Vはインターフェイスとして
Mが実装で
Cはインスタンス化＝利用するクラス？
結城先生の本買った方が良いのかな・・・・
高いしな
0851デフォルトの名無しさん
2005/12/01(木) 07:53:240852デフォルトの名無しさん
2005/12/04(日) 21:08:410853デフォルトの名無しさん
2005/12/04(日) 21:17:040854デフォルトの名無しさん
2005/12/04(日) 23:05:160855デフォルトの名無しさん
2005/12/09(金) 00:50:56> >>837==>>840
も実は違うんだが・・・
ちょっとからかっただけ
オマイってからかうとオモシロイナw
必死に反応してくれてw
0856デフォルトの名無しさん
2005/12/09(金) 10:59:080857デフォルトの名無しさん
2005/12/10(土) 00:21:15頭のいい奴は、つられたりしないわけだから
気をつけてればいいのさ
0858デフォルトの名無しさん
2005/12/11(日) 17:38:28同感です。昔、GOF 本を読んでクラスを使って実装した strategy パターンのコードを単純化して言ったら、関数ポインタの設定値の切り替えだけになっちゃいました。
それから GOF 本を真剣に読む気持ちがなくなりました。
0859デフォルトの名無しさん
2005/12/11(日) 17:58:58デザパタの存在意義が「技術ブレークスルー」だと勘違いしている
馬鹿がまた一人。
0860デフォルトの名無しさん
2005/12/11(日) 17:59:31デザインパターンに過剰な期待をしていないか？
「単なる○○じゃん」「同感」という発言は、
デザインパターンの目的・役割を取り違えてないか？
デザインパターンは、別に
「そこらのエンジニアが考えつかないような素晴らしい夢のパターン集」
でもなんでもないぞ。
誰でもやっている・よく使われる設計手法に名前を付けてカタログ化したものでしかない。
エンジニア間の共通認識化・共通語化するのが目的。
0861デフォルトの名無しさん
2005/12/11(日) 18:14:570862デフォルトの名無しさん
2005/12/11(日) 19:33:05・・・
このクラスはGoFの○○パターンの××です．
@see □□
@see △△
とか書いて有ればクラス図見なくても設計意図と構造が解る
ってのもデザインパターンとして用語と設計が定義して有るおかげよね．
0863デフォルトの名無しさん
2005/12/11(日) 19:40:58ぶっちゃけ言いたい。
構造が分かっても用途が分からないドキュメントは糞。
0864デフォルトの名無しさん
2005/12/11(日) 20:16:20￣￣￣￣
＞構造が分かっても用途が分からないドキュメントは糞。
￣￣￣
ここでもエンジニア間の共通認識化・共通語化をする必要がありそうだな
0865デフォルトの名無しさん
2005/12/11(日) 20:24:19共通的に使える設計で出てくるパターンは、
資産化しなさいよーという教えです。
0866デフォルトの名無しさん
2005/12/11(日) 20:28:27適用できるなら適用すればいいだけかと
0867デフォルトの名無しさん
2005/12/11(日) 21:01:21詭弁のガイドライン
6.一見、関係がありそうで関係のない話を始める
16.全てか無かで途中を認めないか、あえて無視する
17.勝手に極論化して、結論の正当性に疑問を呈する
あたりか
0868デフォルトの名無しさん
2005/12/11(日) 21:02:12>構造が分かっても用途が分からないドキュメントは糞。
そんな当たり前のことを偉そうになに突っ込んでるんだよｗ
0869デフォルトの名無しさん
2005/12/11(日) 21:23:54まんまデザパタのことだな。
0870デフォルトの名無しさん
2005/12/11(日) 21:27:250871デフォルトの名無しさん
2005/12/26(月) 18:26:38ここのアンチの人ってオブジェクト嗜好だよね。
憂鬱本読んでわかった気になってるパターンか。
0872デフォルトの名無しさん
2006/02/21(火) 23:48:17内部設計というか、プログラムのインターフェース設計ってどうやってます？
自分の経験では、共通化の行き過ぎによるメンテナンスの低下が多くのプロジェクトで見られます。
簡単にいうと、こういうことです。
処理Ａ、処理Ｂ、処理Ｃがあったとして、この３つは横展開の関係にあります。
３つも実装するのは大変なので、全て共通化して実装した（methodX(A）のように１つのメソッドで処理Ａ〜Ｃを行い、どれを行うかは引数で指定する）。
ただし、メンテナンス作業を繰り返すうちに、If (処理Ａの時のみ）...のような記述が増え、所謂マカロニソースになってしまった。
最初から処理Ａ、処理Ｂ、処理Ｃは別々に実装すべきだった。
もちろん共通化すべき部分はあるので、下請け処理の共通部品を作るべきだが、
大元の処理は分けて実装すべきだった。
なんで、こんな失敗するんでしょう？
最初からＡ〜Ｃはほとんど同じ実装で済むと思っていたのが、
想定外のバグ、仕様漏れ、仕様変更等により、Ａ〜Ｃが乖離した結果、マカロニ化してしまうんですね。
けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様どうやって設計してますか？
0873デフォルトの名無しさん
2006/02/21(火) 23:49:16けれど、「想定外」のことを想定して設計なんてできないんですよ。
皆様どうやって設計してますか？
0874デフォルトの名無しさん
2006/02/21(火) 23:59:09>どれを行うかは引数で指定する
これが間違ってると思う
0875大根
2006/02/22(水) 00:00:29ご回答ありがとうございます。
すいません、新スレ立てさせていただきました。
デザインパターンとは違う話題なので。。。
0876デフォルトの名無しさん
2006/02/22(水) 16:53:470877デフォルトの名無しさん
2006/02/23(木) 18:31:510878デフォルトの名無しさん
2006/02/23(木) 18:48:42名前を付けて普及させ、技術者間の共通認識にするところまでやってはじめて価値が出る。
どんなに優れた設計でも『オレ様パターン』じゃ意味ないんだよ。
0879デフォルトの名無しさん
2006/02/23(木) 19:12:09その点において最大の価値がある。
>>877
全パターンをただ一人で考案した
というのはとても信じられない
0880責任転嫁マン
2006/02/24(金) 01:07:28確か、５スレ目まで言ってたので、「【GoF】Design Pattern 6」とかで。
0881デフォルトの名無しさん
2006/02/25(土) 00:39:28デザパタなんて使ってる会社無いっていってるだろ。
だいたいGoF本なんてもう絶版だろ？ﾜﾛｽ
オブジェクト指向が理解できない奴ほど食いつくんだよな
いい加減にオブジェクト指向理解しろって
オブジェクト指向言語がメジャーになってから何年経つんだよﾃﾗﾜﾛｽ
0882デフォルトの名無しさん
2006/02/25(土) 00:47:09JavaでサーバサイドシステムをJ2EEパターンを使わないで作ってる会社なんて無いよｗ
0883デフォルトの名無しさん
2006/02/25(土) 00:54:09はぁ？なにそれ？
0884デフォルトの名無しさん
2006/02/25(土) 01:39:23「？」の後は１つ空白を入れろ 話はそこからだ
ただし」が続く場合はいらないぞ
0885デフォルトの名無しさん
2006/02/25(土) 02:42:03うるせえよ
氏ね
0886デフォルトの名無しさん
2006/02/25(土) 10:49:04言われたとおりに書いてればおｋなドカタには不要なモノだよ
0887デフォルトの名無しさん
2006/02/25(土) 10:56:55コンビニのアルバイトみたいに、接客対応マニュアル
を用意してくれたってことでしょ
0888デフォルトの名無しさん
2006/02/25(土) 12:43:07共通の認識がないとこういう符丁は成立しない。デザパタも似た様なもんだｗ
0889デフォルトの名無しさん
2006/02/25(土) 18:16:18あるなら本でも読んでみようという気になるかも
0890デフォルトの名無しさん
2006/02/25(土) 18:35:05こうしてこっちはあーしてこういう風に作ろう が これしよう と単純に考えられる
ライブラリでデザインパターンになってるものがあるから、それを簡単に理解できるようになる
0891デフォルトの名無しさん
2006/02/25(土) 19:02:37ほとんどないしなあ。今ひとつ食指が動かない
0892デフォルトの名無しさん
2006/02/25(土) 19:24:15, -‐−-､ ヽ∧∧∧ // |
. /////_ﾊ ヽ＜ 釣れた！＞ ハ
ﾚ//ｊ け ,fjlﾘ / ∨∨V ヽ h. ﾟl;
ﾊｲｲﾄ､"ヮノﾊ // |::: ｊ ｡
/⌒ヽヾ'ﾘ、 // ヾ､≦ '
. { j｀ｰ' ﾊ // ヽ∧∧∧∧∧∧∨/
ｋ〜'ｌ ﾚﾍ. ,r'ス ＜ 初めてなのに ＞
| ヽ ＼ ト､ ヽ-kヾｿ ＜ 釣れちゃった！＞
. l ＼ ｀ｰ‐ゝ-〈/´ / ∨∨∨∨∨∨ヽ
l `ー-､___ﾉ
ﾊ ´￣｀ 〈/‐-､
0893デフォルトの名無しさん
2006/02/25(土) 19:42:26考察段階でつまずくんじゃなくて、考察内容自体を短縮するんじゃないか？
0894デフォルトの名無しさん
2006/02/25(土) 20:53:19動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
んだけど。
0895デフォルトの名無しさん
2006/02/25(土) 20:56:16>動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
>思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
入るわけない
誰がそんなこと言ったの？
0896デフォルトの名無しさん
2006/02/25(土) 20:57:450897デフォルトの名無しさん
2006/02/25(土) 21:05:590898デフォルトの名無しさん
2006/02/25(土) 21:30:330899デフォルトの名無しさん
2006/02/25(土) 21:41:49そういうことが本当に分からないなら勉強する気も起きないだろうしやんなくていい
釣りかな
0900デフォルトの名無しさん
2006/02/25(土) 21:51:18無限の関数名が出来そうだけど
0901デフォルトの名無しさん
2006/02/25(土) 22:04:06「こういうときはこうする」というチップス集としても役立つ。
自分で考える手間が減るだろ？
専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
機能として実装するだろ？
そういう部分で「よくやる手法」としてのチップス集にはなる。
あるいは機能の重複をどう効率よく実装するか、とか。
・・・無理矢理かな？
0902デフォルトの名無しさん
2006/02/25(土) 22:11:07変数名をプロジェクトで決まった用語のローマ字方式でつけてて
開発の途中でダサいって理由で英語で付け変えた変数名も、
誰も読めないって理由で結局対応表が必要になった。
これはデザパタにもいえることだけど余計な手間増やしてない？
みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
アレを覚えることで得られるメリットも開発に参加する人数の大半をサポートしていなければ
その説得力は無いも同然。
デザパタがいいという人間はデザパタを知ってる人間とかしか開発がしたくなくなるとかいう呪い付き。
やっぱり駄目じゃねぇのかな？
0903デフォルトの名無しさん
2006/02/25(土) 22:16:55＞専門分野のソフトウェアにしたって、入出力やイベントハンドリングなんかは
＞機能として実装するだろ？
この辺がどう効率的になるのかわかんないんだ。現状でもコーディング
の時間以外はコストかからんしライブラリやフレームワークがあればそれ
も軽減できる。
＞「こういうときはこうする」というチップス集としても役立つ。
チップスの数って数えられるほどに押さえられるもんなのか？
そういわれると問題に対して適用する手法はそんなにない
ような気もしてきた。
0904デフォルトの名無しさん
2006/02/25(土) 22:59:21無限ってことはないでしょ 使われなくなったら消えるし
良く使われる部分にそれがあると楽になるんじゃないか
良く使われる部分でもその名前が知られてなければしょうがないというのは……
まあ自分で考える時に使うということで
gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
0905デフォルトの名無しさん
2006/02/25(土) 23:20:01>gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
そう。
プロジェクトで結構手間がかかるのは
個人個人の認識の仕方を確認し、それを共通認識までもってくことだからな。
その手間をぶっちぎって、「デザインパターン読んでください」なんて突き放してうまくいくわけがない。
中国語と英語を話す国に
「今日から日本語が母国語になります。ええ、決まったことですからしょうがないですね。」
なんてふっかける行為となんら代らない。
0906デフォルトの名無しさん
2006/02/25(土) 23:21:10それこそがデザパタの適用ｗ
0907デフォルトの名無しさん
2006/02/25(土) 23:22:01これはなんとなく分かるけど
＞使われなくなったら消えるし
＞gotoよりforループだ ってぐらいのものじゃないと意味がないってことか？
スマンが何を言ってるのか不明。
0908デフォルトの名無しさん
2006/02/25(土) 23:22:12勉強する環境やらお金やらは問題ないかもしれんだけどやるか？やらんだろ？
0909デフォルトの名無しさん
2006/02/25(土) 23:25:47＞それこそがデザパタの適用ｗ
おれデザパタとか意識してないよ。
こういうときはこれ（ライブラリでも手法でも）を使う、ってのは
大概苦労せずに出てくるけど
0910デフォルトの名無しさん
2006/02/25(土) 23:25:51＞ その説得力は無いも同然。
わかってんじゃん。
＞ みんなの共通認識っていうけど、別にあの本はネットで公開されてるわけでも
＞ そこまで普及してるわけでも、開発のすべてをカバーしてるわけでもない。
俺の周囲は常識としてあたりまえに知っているけどな。
デザパタを知らないDQNばかりの開発者だらけの現場だとそうなる。
･･･とは言え、分野にもよるのだろう。
J2EEアプリの開発者達は知っていて当たり前。知らなければDQNと言われても仕方ない。
他の分野だとJ2EEアプリほどアプリ全体の作りがパターン化しないと思われるから
デザパタが普及する必要性は低くなるだろう。
0911デフォルトの名無しさん
2006/02/25(土) 23:31:49J2EEなんて狭い世界にしかいないからそんなんなんだよｗ
0912デフォルトの名無しさん
2006/02/25(土) 23:54:14アルゴリズムにも名前が付いてる。バブルソートだとかクイックソートだとか？
OODにも名前を付けてみた。それがデザインパターン。
>>905
デザパタがあるから不親切なのか？不親切な奴はデザパタの有無とは無
関係に不親切だぞ？
もしデザパタがなかったなら、ソース読めと突き放されるだけだと思うが？
全部暗記しないと話にならない？ありえん。
全てのデータ構造を知ってるか？全てのアルゴリズムを知ってるか？
少なくとも俺が知る限り、そんな奴はいない。
重要なのは、名前は目次になるってこと。
名前を得られれば、その実装なり実装例なりを得られる。ないと困るだろ？
0913デフォルトの名無しさん
2006/02/26(日) 01:05:34使われなくなったら消えるっていうのはそのままだ
誰も使わないデザインパターンは消え去るでしょ？ 言葉と同じ
gotoとforループは機能と認知度のことで例としてあげた
gotoでforと同じ機能が実現できるけど、forを使う
それは便利で、そして誰でも知ってるからか という話
そんなに分かりにくかったかな……
0914デフォルトの名無しさん
2006/02/26(日) 01:44:57>ないと困るだろ？
別に困らない。
むしろ、勝手に名前をつけて共通認識にもなってないのに使ってくる奴のがウザイ。
0915デフォルトの名無しさん
2006/02/26(日) 01:58:36ってやつもウザイ。
0916デフォルトの名無しさん
2006/02/26(日) 03:15:27でも、仕事でそういう状況のときってどうするのが適切なのかな？
例えば、
Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはステートパターン」
Ｂ：「なにそれ？」
Ａ：「デザインパターンという・・・というわけですよ」
Ｂ：「なんかよくわからないけど、そのパターンがどうしてここで使っててそれで間違った組み方じゃないって言えるの？」
Ａ：「だから、デザインパターンの・・・はこういう・・・のときに使うのが・・・なわけですよ。」
Ｂ：「どして？さっぱりわかんね。そもそも、そのステートパターンとかよくわからないし。何がよくてどうしてそのパターンを使いたいの？」
ってなったときね。
ここで本を渡して「はい、自分で勝手に調べてね」っていうとすげーヤナ奴じゃない？
上司でもないのに変な用語使って勝手に仕事増やしてる痛い奴であることに間違いは無いよ。
やっぱり無難にそのパターンの詳細を説明することになると思うけどそれだと別にそのクラスの仕組みを説明すればいいんであって
べつにパターンとかいう必要ねぇし。と思う。
これってデザパタ知ってる奴同士でも同じじゃね？
0917デフォルトの名無しさん
2006/02/26(日) 03:40:56Ａ：「あ、ここはステートパターン」
Ｂ：「なるほどね」
- 完 -
0918デフォルトの名無しさん
2006/02/26(日) 03:42:02それ、前提が間違ってるわ。
配列で済むとこにリスト使ってたら、そりゃただの馬鹿だろ？
デザパタも同じで、不要なとこで使ってたらただの馬鹿だ。
試しにさ、リストを使う妥当な理由があるという前提の下で
リストを知らない者にリストという単語を使う事なくそのデー
タ構造を説明するというシチュエーションで話作ってみてよ。
0919デフォルトの名無しさん
2006/02/26(日) 03:42:140920デフォルトの名無しさん
2006/02/26(日) 04:17:280921デフォルトの名無しさん
2006/02/26(日) 05:09:22クラスの仕組みを説明したときに、それにこういう名前がついてるっていえばいいんじゃないか？
名前の説明が追加されても大差ないし、次があれば楽に説明できる
それとその例だとAさんが説明したのにBさんが分かってないようだが
Aさんの説明が悪いか、Bさんに理解する気がないかのどちらかだ
0922デフォルトの名無しさん
2006/02/26(日) 08:51:14916じゃないけどやってみた
Ｂ：「これなんでこんな変な組み方してんの？」
Ａ：「あ、ここはリスト構造」
Ｂ：「なにそれ？」
Ａ：「要素をインデックスじゃなくて、次へのポインタで指すデータ構造です」
Ｂ：「……ああなるほど、これだとデータ挟んだり抜いたり、配列でやりにくいことが楽に出来るんだ」
例えが分かり易すぎて引き合いにはなりませんですた。
デザパタが物議をかもすのは、ひとつの名前に対しての内容が
人によってはアンバランスに感じるほど詰まってるからじゃねーの？
おれはデザパタ知らん人間ね。
0923デフォルトの名無しさん
2006/02/26(日) 08:51:24どのように細分化していくかって話もあるだろう？ （つまり境界線をどこに引くか）
>>894
＞ 例えばデザパタを習得していると、音声認識とか不可逆圧縮アルゴリズム、
＞ 動画再生ルーチン、将棋の強いアルゴリズムとか楽々こなせるほどの
＞ 思考手法が手に入るの？（コーディングとかマンパワー的なものは除いて）
そういった思考手法そのものが手に入るのではなく、そういった思考手法と他の機能が
どのように連携するのかを考え、適切なクラス分割が行えるようになる。
例えば、将来的に音声認識アルゴリズムを（クラスを追加するだけで）ばっさり他のものと
入れ替えることが簡単に行えるようになるわけ。
＞ こういう専門分野以外はソフト構築の考察時間なんかほとんどゼロだと思う
＞ んだけど。
ソフトが行っている内容は考察するほどもない簡単なものかもしれんが、
将来どういった仕様変更があるのか（どの部分を入れ替えられるようにするのか）について
は色々考えるべき点が多いぞ。
0924デフォルトの名無しさん
2006/02/26(日) 09:02:06＞入れ替えることが簡単に行えるようになるわけ。
別にデザパタ知らんでも簡単に入れ替えられるんだな。
＞将来どういった仕様変更があるのか
仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。
つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
組み方してるんだろう。
素直に組んでれば改変追加etc、何も問題ないと思うんだけど。
0925デフォルトの名無しさん
2006/02/26(日) 09:20:16＞ 別にデザパタ知らんでも簡単に入れ替えられるんだな。
そういう人にとってはデザパタって「共通の名前」という以外の意味はないんでしょうな。
＞ 仕様変更要求に対して、「面倒くさいなあ」以外に困ったことなんてないんです。
その「面倒くさいなぁ」ってーのはどんな感覚？
Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？
Ａの機能を呼び出したりする部分を一切変更することなく、Ｂの機能を実現したクラスの
追加だけで対応できているんであれば、あんたはかなりの実力者だ。
＞ つーか仕様変更で困っていると言う話を聞くたびに不思議。いったいどんな
＞ 組み方してるんだろう。
仕様変更が起こった場合、変更とは直接関係のない部分（上記で言うところのＡの機能を
呼び出している部分）まで修正が及ぶため、そこも含めてテストをやり直さなければなら
なくなるのが普通。 これによって工数が無茶苦茶増える。
＞ 素直に組んでれば改変追加etc、何も問題ないと思うんだけど。
客先からの要求ヒアリングでも、「どこに仕様変更が起こりそうか」なんてことは
ほとんど聞けないのが実態。 素直に組むことで問題が解決される例はほとんどない。
0926デフォルトの名無しさん
2006/02/26(日) 11:14:54＞その「面倒くさいなぁ」ってーのはどんな感覚？
単に仕事が増えてゴルア。精神的な問題のみ
＞Ａという要求がＢという要求に変わった時、クラスの「追加だけ」で対処できる？
クラスかどうかはともかく、変更の規模によって
・Aを多少改造（現機能も維持したまま条件判断で追加のケース）
・Aをまるまる残してBを追加。
関係ないけど、どっちのケースもAの動作はとりあえず残しておく。
元に戻したい時ってのは常にあるから。容量が厳しい場合はケースバイケース
＞変更とは直接関係のない部分（Ａの機能を呼び出している部分）まで修正が及ぶ
AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
変えたところをテストするのはしゃーないじゃん
まったく関係ないところはあたりまえだが変更など皆無。
＞「どこに仕様変更が起こりそうか」予測できない
だから、変更を許容せよ、がおれの組む時の一番頭にあること。
プログラムを仕事にしてから一番学んだのはそれだね。
0927デフォルトの名無しさん
2006/02/26(日) 11:58:16戻すなんて手間じゃないだろうに。
…じゃなくて。冷静になろう。
話がデザパタから微妙にずれてきてる。
これはニュアンス的にはリファクタリングのネタだよな。
0928925
2006/02/26(日) 12:11:13＞ AをBに変えるならAを呼び出しているところは全然無関係だとはいえないよ。
そうとも言えないんじゃない？
AとかBとかの機能と、それを呼び出す部分のインタフェースをうまく設計すると
AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
無くなるわけです。
さらに、Aのインスタンスを生成する部分に工夫を加えておくと、設定ファイルを
いじるだけでAのインスタンスでもBのインスタンスでも生成できるようになるん
ですな。 コードに手を加える（修正する）必要が無くなるんです。
＞ 変えたところをテストするのはしゃーないじゃん
その通り。 だから修正部分が減るとテスト工数が激減することになる。
＞ だから、変更を許容せよ、がおれの組む時の一番頭にあること。
デザパタ（というかオブジェクト指向原則の多く）が言っているのはまさにそこ。
変更を許容する以上、変更点を局所化することこそを考えるべきではないで
しょうか？
0929デフォルトの名無しさん
2006/02/26(日) 12:14:07＞ 話がデザパタから微妙にずれてきてる。
＞ これはニュアンス的にはリファクタリングのネタだよな。
いや、ずれてないと思うぞ。
デザパタを利用することでリファクタリングも楽になるという点で、関連はあるが。
0930デフォルトの名無しさん
2006/02/26(日) 12:22:05スレ違いごめんよ
＞ソース管理ツールくらい使ってるだろうし、
＞戻すなんて手間じゃないだろうに。
単純に戻すとかいう問題じゃなくて、どっちも使いたいとかなる
場合もあるからプログラム的に共存させておくことを念頭におい
て作っている
>>928
＞AがBに変わったとしても、
もちろん外見が同じなら何も変更はしないよ。
ただそうじゃない場合もあるし。（まれと言えばまれ）
まあ、
＞設定ファイル
それをもっと進めている。外見のインターフェースがまったく
変わったとしてもコードのビルドしなおしなんてやんない。
ビルドしなおすのはまったく新しい機能追加と
大好きな最適化やる時だけ
0931925
2006/02/26(日) 12:38:28＞ もちろん外見が同じなら何も変更はしないよ。
＞ ただそうじゃない場合もあるし。（まれと言えばまれ）
外見（つまりインタフェース）を同じになるようにするってーのが、システムを設計する
際の肝であり、GoF本が主張している「インタフェースに対して設計する」ということで
すね。
「そうじゃない場合もあるし」というのは、まだまだ精進する余地があるってことでしょう。
（とはいえ、完璧に予想するなんて、神にしかできないだろうが。w）
そういった観点から見た場合、デザパタは「変化しそうな部分の外見（インタフェース）を
汎用的な形に変形するための設計をカタログ化」したものと言えるんじゃないかな。
デザパタを使うと無意味なクラスが多くできるとか、デザパタを用いて失敗したという
のは、こういった変形を必要以上にシステム内に持ち込んだり、誤った変形をしてしまった
結果に起因するのではないかと言ってみる。
0932デフォルトの名無しさん
2006/02/26(日) 17:15:45>AがBに変わったとしても、Aを呼び出しているところにいっさい手を加える必要は
>無くなるわけです。
これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
0933デフォルトの名無しさん
2006/02/26(日) 19:37:56＞ これってソースコードだけの話であってテストは必要になるから手間としては全く意味ない。
ふっ、、、甘いな。
テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？
0934デフォルトの名無しさん
2006/02/26(日) 21:52:34ひょっとして、ここは笑いどころだったのか？
ソースコードだけの話って、ソースコードいじると色々とたちの悪い問題が出てくるんだが。
0935デフォルトの名無しさん
2006/02/26(日) 22:08:040936デフォルトの名無しさん
2006/02/26(日) 23:47:30>テストが必要になるとすれば、正しいインスタンスが生成されていることの確認だけだろう？
そのテストってどうやるの？
何を証明すればキチンとした動作になってると言えるのかわからない。
とりあえず全パターン出して、今回の変更で変わる部分を抜き出さないとテストは終わらない。
そういうふうに人に説明しにくい仕組みしてしまうよりは、ベタで書いたほうが早いと思う。単純に。
0937デフォルトの名無しさん
2006/02/27(月) 01:46:030938デフォルトの名無しさん
2006/02/27(月) 01:48:050939デフォルトの名無しさん
2006/02/27(月) 02:58:03それを含めて全パターンだしても>>936のいってることは代わらないと思う。
0940デフォルトの名無しさん
2006/02/27(月) 06:41:210941デフォルトの名無しさん
2006/02/27(月) 07:48:49＞ そのテストってどうやるの？
＞ 何を証明すればキチンとした動作になってると言えるのかわからない。
そんなことを聞くあなたは、ひょっとするとテストの際、毎回全てのケースをテストしているのかい？
（まぁ、xUnit 等をうまく使えば、そういったことも可能だし、効率もさほど低下しないだろうから、
毎回全てのケースをテストすることに対して否定はしないが。）
答えは色々あるだろうが、正しいインスタンスが生成されているかどうかを確認したいのならば
クラスBのコンストラクタが起動された際にコンソールメッセージを出すようにするというのは
一つの手じゃないか？ まぁ、この手の方法は組織によって向き不向きがあるんだろうけど。
それよりも >>932 は >>934 の言ってたソースコードを触った時の危険性を認識しなさ過ぎ。
たいていの厄介なバグは、新規機能に作り込んでしまうのではなく、新規機能を追加した時に
既存機能側をいじり壊して作り込んでしまうものです。
0942デフォルトの名無しさん
2006/02/27(月) 08:30:390943デフォルトの名無しさん
2006/02/27(月) 09:12:00俺は絶対事故らない、、、とみんな思ってる。
0944デフォルトの名無しさん
2006/02/27(月) 10:31:57車の方はやばいと思って運転するのやめた）
0945デフォルトの名無しさん
2006/02/28(火) 03:01:40必要だと思わないのであれば別に無理して覚える必要はないんじゃない？
俺は面白かったから勉強したけど。
俺が得られたメリットは、コードの整理がうまくなったってことかな。
昔、色々コード書いてて、規模が大きくなればなるほど、整理の方法がわからず、
コードが汚くなることが悩みだったが、デザパタ覚えたことで少し改善した感じ。
あと「カタログ化して、みんなの共通の認識とする」っていうのはあんまメリットない気がする。
デザパタしらん人には無意味だし。ただの浮いてる奴としか見られない。
0946デフォルトの名無しさん
2006/02/28(火) 20:30:50デザパタないと、共通認識にはできないから俺はそっちの方が重要だと思う
データ構造とアルゴリズム みたいな本がいっぱいあるけど
クラス構造とアルゴリズム になるのがデザパタだろう
どちらも丸暗記する必要はないけどな
0947デフォルトの名無しさん
2006/02/28(火) 22:12:300948デフォルトの名無しさん
2006/03/01(水) 01:13:50つーかもう本でてないしｗ
流行りも廃れたしｗ
あのぶ厚い本を一冊読むことを強制するってのは流行らないと思うわ。
なんかもうちょっとお手軽なのじゃないとねぇ。
0949デフォルトの名無しさん
2006/03/01(水) 01:23:54もう少し本屋にいった方がいいと思う
0950デフォルトの名無しさん
2006/03/01(水) 06:29:12オススメは何？
0951デフォルトの名無しさん
2006/03/01(水) 14:20:46うーん、無理だろう。
プログラム勉強するようになっていきなりデザインパターン勉強する奴とかいないだろ。
「関数で処理を分けるのは、なぜ必要なんですか」っていうレベルからだろうし。
１００人のプログラマがいても２０人くらいしか知ってる奴は期待できないとおもう。
それを２０人の都合で、８０人に本よめっていうのはわがまますぎだと思う。
所詮たよれるのは自分です。なんつって。
>>948
まあ、とりあえず、デザパタは得て損はないと思うよ。
ただ全部が全部、よいパターン／読んで欲しいパターンだとはいえないんだけど。
0952デフォルトの名無しさん
2006/03/01(水) 15:17:11100人いたら半数以上は言われたとおりに部品製造していればいいコーディング担当だろうし。
設計を担当するアーキテクトチームなら常識的に知ってて当然だとは思う。
設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題。
使う・使わない・どこにどう適用するかは別問題として。
0953デフォルトの名無しさん
2006/03/01(水) 20:36:03俺は結城さんの読んで覚えた、お勧め
読んではいないが、最近だと変なねーちゃん表紙のやつ評判よかったような
0954デフォルトの名無しさん
2006/03/05(日) 18:13:55>設計について議論しなければいけない人間同士でデザパタが共通認識でないのは問題
なんで？
0955デフォルトの名無しさん
2006/03/05(日) 20:08:18アーキテクトにとっては、良し悪し・使うべき/使わないべきまで含めて知ってて当然の知識だからな。
デザパタも知らない、共通の概念のない非常識な人間が寄ってたかって設計したシステムなど、お里が知れるわｗ
0956デフォルトの名無しさん
2006/03/05(日) 23:34:37・・・それは思いこみであって現実の正しい認識であるとは思えないけどね。
0957デフォルトの名無しさん
2006/03/05(日) 23:39:43具体的な根拠がなにも示されて無いな。
本当に理系の人間なのかどうか疑問
>>956
ね。
なんか思い込み強いよね。
0958デフォルトの名無しさん
2006/03/06(月) 00:19:40「知りもしない」ってのは、土方コーダーならともかく
アーキテクトとしては激しく問題があると思われ。
知った上で使う・使わないは別問題だがな。
0959デフォルトの名無しさん
2006/03/06(月) 00:43:55形式だけ学んだので不必要に濫用する。
このパターンが少なくない気がする。
デザパタの粒度ってアーキテクトレベルなんかな？
どちらかと言うとプログラミング(詳細設計から下)レベルに思うんだが。
0960デフォルトの名無しさん
2006/03/06(月) 06:35:25デザパタなんていつ必須事項になったんだか。
オブジェクト指向でもなんでもないし。
すっげどうでもいい部分の寄せ集めじゃん。
>知った上で使う・使わないは別問題だがな
これでデザパタは使えないって結論に至った人間をどうやって説得するのか？
0961デフォルトの名無しさん
2006/03/06(月) 06:43:31＞ 知ったつもりになって使ったつもりになる。
＞ 形式だけ学んだので不必要に濫用する。
＞ このパターンが少なくない気がする。
ここのところは同意。 しかし、デザパタの真意はアーキテクトレベルにあると思うぞ。
それをコーディングの定石集だと誤解しているﾔｼが多すぎ。
>>960
＞ オブジェクト指向でもなんでもないし。
オブジェクト指向原理主義ですか？
90年代前半の呪縛に捕らわれてますな。
0962デフォルトの名無しさん
2006/03/06(月) 13:23:31＞すっげどうでもいい部分の寄せ集めじゃん。
そうかね？JavaとかC#とかの標準ライブラリ（java.langとかjava.ioとか）は、
デザパタを基準に作られてると思うけど、あれもすっげどうでもいい使えないライブラリかね？
あれらを見たときなかなかいいもんだと感じたもんだが。
まあ、良いか悪いかの感じ方は、人それぞれとは思うけどね。
>>961
俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
あそこまで本の中身がソースコードだらけにはならないと思う。
0963962
2006/03/06(月) 13:28:47アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。
0964961
2006/03/06(月) 15:08:20＞ 俺も>>959と同じくプログラミングレベルの概念だと思うのだが、
＞ デザパタの本は色々読んだが、アーキテクトレベルの説明をする本だとするならば、
＞ あそこまで本の中身がソースコードだらけにはならないと思う。
デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
ことを明確にしている点が肝なんだと考えています。
そういった意味では、本の中身をあそこまでソースコードだらけにしてしまう必要はなか
ったんじゃないかな。 （クラス図とせいぜい状態遷移図があれば十分だったはず。）
実は「GoF本の翻訳がイマイチで理解しづらかった」→「みんなソースコードに頼ろうと
する」というだけなのではないかと。
（かの結城氏もJavaで書かれてないから判りにくいんだと誤解していたし。）
そもそもデザパタがプログラミングレベルの概念だったとしたら、もっと色々な言語が
シンタックスシュガーとしてデザパタ構文を採用してるんじゃないか？
＞ まあ、俺がアーキテクトという言葉をよく理解していないからかもしれんがな。
＞ アーキテクトという言葉は正直、抽象的すぎてなにをさしている言葉なのかわからんし。
アーキテクトほどいい加減な言葉もそうそうないと思う。
あれってプログラミングが設計工程に属していることを認めたくない連中が、
（彼らの言う）設計工程とプログラミング工程のギャップを埋めるために作り出した
役割なんだと思うな。
0965デフォルトの名無しさん
2006/03/06(月) 18:49:58>デザパタは、クラスの関連を用いることで、いかにして実装と抽象を切り離すのかという
>ことを明確にしている点が肝なんだと考えています。
よく考えると切り離す意味が全くわからないな。
0966デフォルトの名無しさん
2006/03/06(月) 19:20:35＞ よく考えると切り離す意味が全くわからないな。
変更に強くするため。
いくらクラスを作って「カプセル化」だと叫んでも、インタフェース部分に変更が
あると、そのクラスを変更した時、山火事のように影響度が飛び火して広がって
いく。
0967デフォルトの名無しさん
2006/03/06(月) 20:00:30変更に強いかどうかってそんなに重要かぁ？
俺には設計と実装がマッチしてない糞みたいなソースができるような気がするぜ。
つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
一致してることの方が何倍も大事なことのように思えるんだけど。
0968デフォルトの名無しさん
2006/03/06(月) 20:01:59変更されたらそれに合わせて変更が必要になってもいいんじゃないの？
ってこと。
てゆうか、設計が変更されたのに実装がそのまんまっておかしいｗ
0969デフォルトの名無しさん
2006/03/06(月) 20:16:10設計と実装はそんなに離れない 離れたらその設計参考にされてない
変更に強いって言うのは変更箇所が少ない、影響範囲が小さいってこと
釣りなのかマジなのか……
0970962
2006/03/06(月) 20:21:39まあ、デザパタを覚えることで利点を感じなければ覚える必要は無いと思うけどね。
あと、「設計変更による変更に強い」というよりは、
設定ファイルや、オプションによる処理の変更には強くできるね。
一行変えるくらいで後々の処理を大きく変えることができるとか。
設計変更されたら実装かえるのは当然だぁね。
0971962
2006/03/06(月) 20:35:48＞つーかさ、変更に強いかどうかじゃなくて、もっと大事なこととして設計と実装とみんなのイメージが
＞一致してることの方が何倍も大事なことのように思えるんだけど。
こりゃ同意だな。実装はともかく、設計（インターフェース）は、
万人がイメージしやすい＆理解しやすいことが望ましい、というかそうすべきであると思う。
デザパタのほとんどのパターンは、実装の変更を容易にすることを目的としているかな。
例えば、データを読込＆保存する処理をしたい場合に、保存する手法は何でもよいというとき、
その中身の実装は、普通にファイルで保存したり、ＤＢにしたり、ＸＭＬにしたり、
と後々実装を変えたい、または、コマンドラインオプションや設定ファイルによって変えたいと
思った場合の変更に強くすることができるかと。
0972デフォルトの名無しさん
2006/03/06(月) 20:44:47ひょっとしたらアンチデザパタってﾔｼは、設計時に無茶苦茶にデザパタを
適用した結果、設計結果とみんなのイメージが乖離してしまったという
暗い過去を持っているんｼﾞｬﾏｲｶ？
0973デフォルトの名無しさん
2006/03/07(火) 00:18:43>デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
>つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。
>ですから、プログラム例を｢完成品」として見るのではなく、今後「機能を拡張していくもの」
>｢変更を加えていくもの」として見るようにしましょう。
> ・どのような機能が拡張される可能性があるか？
> ・その機能拡張を行うときに修正が必要になるのはどのクラスか？
> ・修正が不要なのはどのクラスか？
>このような観点でデザインパターンを見ると、理解が深まるでしょう。
0974デフォルトの名無しさん
2006/03/07(火) 00:36:28極めて重要だと思う。特に脱ウォーターフォールを標榜する今後のJavaの開発形態としては特に。
と、いうかJavaの抽象化フレームワークやJunitやEclipseの強力なリファクタリング機能が
何の為に存在するのかといったら、やっぱ「変更しないのが前提」、っていうウォーターフォールの一番駄目駄目な
部分を徹底的に唾を吐き、"いかにソースを良くしていくか"、"｢動いているソースは駄目ソースでも触るな」じゃなく
「ガリガリ直してどんどん洗練されたソースにリファクタリング」していくか"、
"余計なドキュメント製造に掛かるコストをカットする事で生ずるリスクをどこで吸収できるか"
等にあるわけで。
変更に強い、というのは客の仕様を満たすのと同じくらい重要だと思う。
0975デフォルトの名無しさん
2006/03/07(火) 00:49:56一方のアーキテクトはアンチパターンを認識・検出・除去することが出来る。
残りのアーキテクトは日々新たなアンチパターンを生産することが出来る。
後者多すぎ。
0976デフォルトの名無しさん
2006/03/07(火) 03:20:30いや、だから、どんな変更に強いってのか謎。
変更したらさ、設計がかわるんだよね？
ここはいいよね？
影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
要はメインじゃなくて付加価値みたいなもんでしょ？
それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
プログラムってのはそれだけで気持ち悪いと思うんだ。
おそらく、みて理解のしやすいソースにはなっていない。
0977デフォルトの名無しさん
2006/03/07(火) 07:30:31＞ いや、だから、どんな変更に強いってのか謎。
「十分予測できるが、現時点では詳細が不明な変更」ですな。
そこを押さえずに何でもかんでも変更可能にしてやろう、あるいはとにかくデザパタを
適用しようという発想がいかんのです。
＞ 変更したらさ、設計がかわるんだよね？
＞ ここはいいよね？
ここはＯＫ。 マクロな視点で見れば必ず設計は変わる。 しかしミクロな視点で
構成要素を一つずつ見ていき、影響が出る構成要素の数を極力減らす努力が
必要。
＞ 影響範囲が最小っていったって、それってどんな変更をするかによってわからないよね？
変更内容が判らないというのであれば、その通り。 しかし裏を返せば、変更の匂いが
するところに対してデザパタを適用できるということ。
伝家の宝刀はここぞという時にしか抜いてはならない（とはいえ意外と多かったりするがなw）。
＞ 普通にそれぞれのクラスに閉じ込めるように作っていれば結果的に変更時の影響範囲が最小になってるって話だよね。
それはダウト。 現状の静的なスナップショットを取っているだけのデザイナは、松竹梅で
言えば梅レベル。 そもそも現状のスナップショットをいくら睨んで見ても、そのどの部分が
変わりそうなのかといった情報は読みとれないものだ。 つまり「普通にそれぞれのクラスを
閉じこめるように作っていく」だけでは全然不足というわけだ。
0978デフォルトの名無しさん
2006/03/07(火) 07:31:26>>976
＞ 要はメインじゃなくて付加価値みたいなもんでしょ？
システムを作るだけ作ってそのまま逃げるような開発をするのであれば、現状のスナップ
ショットのみを用いて設計してもいいかもしれない。 （開発中に入ってくる要求変更と戦う
必要はあるが。） しかしその後の保守を考えると、変更に対する強度は極めて重要な
ことになるのだ。
＞ それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞ プログラムってのはそれだけで気持ち悪いと思うんだ。
＞ おそらく、みて理解のしやすいソースにはなっていない。
おそらく君が過去に接したシステムというのは伝家の宝刀を濫用したものなんだろう。
デザパタを適切に使用した場合のクラス図は、現状のスナップショットがどうなっている
のかという情報だけでなく、今後どういった部分が変化しそうなのかという情報もはっきりと
伝える判りやすいものになるのだ。
0979デフォルトの名無しさん
2006/03/07(火) 07:33:10＞ 要はメインじゃなくて付加価値みたいなもんでしょ？
＞ それを勘違いしてこっちをメインにして変な仕組み入れてわざわざインターフェースとむりやり切り離してる
＞ プログラムってのはそれだけで気持ち悪いと思うんだ。
＞ おそらく、みて理解のしやすいソースにはなっていない。
俺も最近流行りのDIコンテナを利用した実装とインタフェースを分ける設計をみて
そう感じることがよくある。
IDEのデバッガでも追いづらいし、開発の効率を下げている一面もあるよな。
クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
やりやすい点ぐらいか・・・
オブジェクト指向本来のインタフェースの用途ではなく、
言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
0980デフォルトの名無しさん
2006/03/07(火) 07:51:27＞ そこで結城先生の登場ですよ。
＞
＞ >デザインパターンの目標の１つは、プログラムを再利用可能にすることです。
＞ >つまり、どうやってプログラムを｢部品」として再利用するかを考えているのです。
注意すべきはここでの「部品」，「再利用」という表現ですな。
A, B, C, D, E, F, Gという7つのクラスで構成されたシステムがあったとする。
普通に「部品」というと、例えばCとかDというクラスを思い浮かべ，「再利用」というと
そういったクラスを他のシステムから利用することを想像してしまいがちになる。
しかし、デザパタのいう「部品」、「再利用」は違う。
デザパタでいう「部品」というのは、「Cというクラスから見た場合はA, B, D, E, F, Gと
いう6つのクラス」であり、Cが変更になった時にこれら6つのクラスに影響を与える
ことなく、「このシステム自体から見て6つのクラスを再利用する」ということだ。
0981デフォルトの名無しさん
2006/03/07(火) 08:01:01＞ クラスの入れ替えが容易であるメリットは、ユニットテストの時にモックパターンで
＞ やりやすい点ぐらいか・・・
ユニットテスト時にモッククラスと入れ替えることができるということは、将来そのクラスに
対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
＞ オブジェクト指向本来のインタフェースの用途ではなく、
＞ 言語機能としてのインタフェースの機能を逆手に取ったような手法とも感じる。
あなたの考えるオブジェクト指向本来のインタフェースの用途って何でしょう？
実装とインタフェースは無理矢理分けられてるのではなく、本来これらは別々のもので
あるべきなんじゃないかい？
0982デフォルトの名無しさん
2006/03/07(火) 12:17:18DIコンテナ使わないチームと使ったチームで比べられればいいけどね。
俺はもうDIコンテナなしの開発は考えたくないです。
まぁDIスレ(typoしてるが)でやるのが適切な話題だし、
あっち過疎ってるから盛り上げて欲しいってのが本音。
0983デフォルトの名無しさん
2006/03/07(火) 16:36:13＞対して変更があった場合、保守コストが引き下げられるということを意味しているはず。
タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
よくあるのかな？
0984962
2006/03/07(火) 18:00:51DIコンテナって使うとソース見やすくなったりとかするの？
DIコンテナって要は実装クラスをnewする部分をファクトリーじゃなくて、設定ファイルに書くみたいなやつだよね？
設定ファイルの情報を反映させたいときは再起動が必要みたいだから、
ファクトリーで書くのとあんま変わってないのであまり利点を感じないのだが…。コンパイルは不要だろうけど。
0985981
2006/03/07(火) 19:20:50＞ タテマエとしてはよく見る意見だが、実際にそのようなシチュエーションは
＞ よくあるのかな？
意外とよくある。 新規開発の際、客先がちゃんと要求を出せてない部分が
開発途中にガンガン決まっていくんだが、デザパタ使ってると楽に対応でき
るぞ。 その都度リファクタリングしてもいいんだが、新規開発時だとユニット
テストデータもちゃんと揃ってないから、その手があまり使えないんだわ。
どの部分が曖昧なのか、ちゃんと客先ヒアリングして頭使わないとダメだけどね。
0986デフォルトの名無しさん
2006/03/07(火) 19:29:23デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
0987デフォルトの名無しさん
2006/03/07(火) 19:55:010988デフォルトの名無しさん
2006/03/07(火) 20:10:10極端から極端に走らなくてもいいじゃん
仕様に載ってない機能を搭載し、ファイル以外にDBやgmailやSubversionも保存先として使えるようにして
隠しオプションでどんな仕様にも即対応！ みたいのはそりゃだめだ
デザパタは問題の解決法として書かれていて
その問題があるときは割と的確な粒度の解決だと思うがどうだ？
あれでもまだ余分かな？
0989981
2006/03/07(火) 20:23:57＞ 変更自体はよくあるんだが……その変更が、デザパタで吸収可能なものなのかは不明
＞ デザパタ使う時点で、ある程度変更内容を予想してなきゃいかんと思う
結構大変だけどね。 客先が「XXがYYという風に変わりそうだ」なんて自分から教えて
くれることはほとんどないけど、「ここがこうなるとかいうこと考えられます？」といった
聞き方を続けてると、答え方の雰囲気から変更されそうなところが見えてくる場合が多し。
で、実際に変更が発生すると、「実はそういうこともあろうかと、、、」と徳川機関長モードに
入る。
0990デフォルトの名無しさん
2006/03/07(火) 23:54:24この話題、DIスレにコピペしてもフォローしてくれますか？
(スレタイの意味での)デザパタとは全然関係ないと思うし。
＞ソース見やすくなったりとかするの？
それはないです。
>988
＞的確な粒度の解決だと思うがどうだ？
当方もそういう意識ですね。
そういう意味でもアーキテクトと言うよりは、
プログラミングレベルの話題だと思う。
フレームワーク作成チームが知っておくべきプラクティス。
0991962
2006/03/08(水) 01:21:50＞この話題、DIスレにコピペしてもフォローしてくれますか？
いやいいっすわ。DIスレみてたら同じ疑問を持っている人がいて勉強になりました。
ありがとう。あっ、でもやっぱり聞いてみようかな。
>>986
漏れの理解ではだけど、デザパタは実装の入れ替えが容易というのが売りだと思ってるから、
プログラムのやることが変わったらデザパタで組もうがなんだろうが変更する量はさほど変わらないと思う。
ただプログラムのやることは同じだけど実装を変える。
例えばパフォーマンスアップのために仕様変更するというのであれば、
それは実装の変更であるから、そういう変更には予想してなくとも強くなれると思う。
0992デフォルトの名無しさん
2006/03/08(水) 01:40:16ボタンクリックしたら、そのクリックしたメッセージが降りてくるその場所に
その処理が記述してあってほしい。（関数とかクラスとか）
そうでないと他の人間の書いたソースなんて追えない。
降りてきたメッセージをさらにどっかに飛ばす処理なんか入ってるともう駄目。
すげー面倒臭い。どうにかしてくれ。
単純に、ただ単純に書いて欲しい。
それだけ・・・それだけなんだ・・・orz
0993986
2006/03/08(水) 01:43:31たとえ話になるけど 「１００Ｖコンセントがあれば、殆どの電化製品に対応できる」 とか考えて実装してると、
いざ 「実は、この家電アース線がついてるんだけど……」 ってなったときに、コンセント側も改造しなくちゃいけないな、
って話をしてみた。
アース線無い家電製品のみに限定するなら、いくらでも変更は可能。変更に強い。
ただしアース線だとか外国用の特殊形状だとかが変更で出てくると面倒になるってことで、
どこまで変更を予測するか〜って話だ。
ちなみに↑は Strategy を想定してみた。
解決策としては、Adapter が使えれば手っ取り早い。
どうでも良い。次ぎスレたのむ。
0994962
2006/03/08(水) 02:08:21基本的には単純なものは単純に書くよｗｗ 必要になったときにしかデザパタは適用しないよ。
処理をたらいまわしにしている人のソースに悩まされてるの？たまにいるわなぁ。
デザパタだとかいって何でもかんでもたらいまわし処理書く人は。俺も追えない。30秒で諦める自信ある。
必要になった場合に適用すると効果を発揮するというのに、むやみに使うのは毒でしかない。
やるべき処理を素直にコードにすることが一番の解だというのに。
0995デフォルトの名無しさん
2006/03/08(水) 02:22:21とあるベンダが俺様フレームワークを作成して
基本設計の説明に加えて
「ここはあのパターン、ここにはあのパターンを使ってる。」
みたいなことをのたまって
最後にパターン名と適用の有無からなる
2列23行の表を見せて、こんなにたくさん○が付いてますよ
(使った(ことになってる)パターンを○でカウントする。)
みたいな感じで胸を張ってた。
手段が目的にすり替わってしまうと大体ロクな結果を導かんよね。
アンチパターンの表を作るのは意味があるかも知れん。
なんか盛り上がってきたし次スレ欲しいなあ。
0996デフォルトの名無しさん
2006/03/08(水) 03:02:510997962
2006/03/09(木) 03:33:360998962
2006/03/09(木) 03:39:13＞またの機会にどうぞ。。。
「【GoF】デザインパターン 6」で建てようとしたけど駄目でした orz
建てて誘導したいけど残り２レスしかない・・・。
0999デフォルトの名無しさん
2006/03/09(木) 04:28:57「【GoF】デザインパターン 6
http://pc8.2ch.net/test/read.cgi/tech/1141846078/
1000デフォルトの名無しさん
2006/03/09(木) 04:29:411001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。