1 名前:仕様書無しさん mailto:sage [2007/03/29(木) 01:28:08 ] 過去スレ 【OOD/P】オブジェクト指向開発はなぜ流行らないの?★4 pc11.2ch.net/test/read.cgi/prog/1173529414/ 【OOD/P】オブジェクト指向開発はなぜ流行らないの?★5 pc11.2ch.net/test/read.cgi/prog/1174746731/ スルー推奨ワード(相手をした場合は荒らしとみなされます) 電球、たかひろ このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。 なので設計だけ、実装だけといった縛りは特にありません。 設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。 いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、 書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。
267 名前:仕様書無しさん [2007/04/05(木) 21:33:14 ] ひょっとしてアンテナ100本立ってる?
268 名前:ワロス mailto:ワロス [2007/04/05(木) 21:35:05 ] ネタがワンパターン しょーもねぇガキだな
269 名前:仕様書無しさん [2007/04/05(木) 21:44:02 ] 面白い?
270 名前:仕様書無しさん [2007/04/05(木) 21:58:38 ] スレタイのオブジェクト指向開発はなぜ流行らないの からすると、未だに非オブジェクト指向開発が主流ってことかな お舞ら、OODなんてやってないのか? 実はお舞らって、DQN指向開発まんせーじゃね
271 名前:仕様書無しさん [2007/04/05(木) 22:06:04 ] 面白い?
272 名前:仕様書無しさん [2007/04/05(木) 22:10:46 ] 今日は、伊賀知己はまだか
273 名前:仕様書無しさん [2007/04/05(木) 22:17:02 ] VBってさ、一部、オブジェクト思考でないの? テキストボックスとか、ラベルとか。
274 名前:仕様書無しさん [2007/04/05(木) 22:23:52 ] ありゃ、コンポーネント嗜好を追求してんじゃね 別名ポトッペッタ嗜好とも言う
275 名前:仕様書無しさん [2007/04/05(木) 22:31:24 ] JAVAとVB系って、どっちが勝ちますかね? 10年後・20年後、どっちが残ってるでしょうか?
276 名前:仕様書無しさん mailto:sage [2007/04/05(木) 22:41:34 ] 2〜5年後 JAVAがメジャーになりすぎて VBの開発とかメンテとか移植ができるひとの希少価値が高まる。 10年後。 別言語にJAVAの資産は受け継がれる。 VBのサポートは打ち切られるが、VBerの希少価値は高まり続ける。 20年後 VBerは国宝級に崇拝される。
277 名前:仕様書無しさん [2007/04/05(木) 22:45:13 ] 補足 10年後はC#が帝王として君臨 20年後、しらね
278 名前:仕様書無しさん [2007/04/05(木) 22:59:28 ] C丼はないだろ
279 名前:仕様書無しさん [2007/04/05(木) 23:02:01 ] C丼 C# C♯
280 名前:仕様書無しさん mailto:sage [2007/04/05(木) 23:12:15 ] イベントドンブリ
281 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/05(木) 23:15:19 ] JavaはMSに捨てられてサーブレットと携帯アプリに特化して生き残ってるだけ JAVAアプリケーションの案件なんてあるの?
282 名前:仕様書無しさん mailto:sage [2007/04/05(木) 23:25:23 ] >>281 現状しかみえてないお前は10年後乞食になっている。
283 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/05(木) 23:27:28 ] じゃあなんで5年前のOO厨誰も生き残ってないんだよ?
284 名前:仕様書無しさん [2007/04/05(木) 23:28:18 ] クラスのインスタントを生成するとだな、それがオブジェになるわけだ。
285 名前:仕様書無しさん mailto:sage [2007/04/05(木) 23:45:34 ] さびれて温泉街のようなうらぶれっぷりだな。
286 名前:仕様書無しさん [2007/04/05(木) 23:46:43 ] VB系(VB/VB.NET)のエキスパートになるべきか、 それとも、他の言語(java/c#)にも手を出すか? 皆さんは、どっち選ぶ?
287 名前:仕様書無しさん mailto:sage [2007/04/05(木) 23:52:21 ] 二者択一かよ
288 名前:仕様書無しさん [2007/04/05(木) 23:55:33 ] VBでエキスパートってかw
289 名前:仕様書無しさん [2007/04/05(木) 23:58:14 ] JavaとUMLが好きなやつって何であんなにキモいんだろう?
290 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:09:44 ] ITドカタって何であんなにキモイんだろう?
291 名前:仕様書無しさん [2007/04/06(金) 00:11:50 ] JavaとUMLが好きなITドカタって何であんなにキモいんだろう?
292 名前:仕様書無しさん [2007/04/06(金) 00:14:20 ] ここに常駐してる人って理由抜きでキモイ。
293 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:16:28 ] >>286 両方できて当然。各1日でマスターできなければこの先道はない。
294 名前:仕様書無しさん [2007/04/06(金) 00:16:46 ] >>292 ここに常駐し、かつ、JavaとUMLが好きなITドカタよりマシだろ
295 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:17:23 ] ねえ、マスター作ってやってよ
296 名前:仕様書無しさん [2007/04/06(金) 00:21:05 ] 話題が貧困なちゃねらーほど存在価値の低いものはない。
297 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:31:50 ] これって本当? jibun.atmarkit.co.jp/lcareer01/rensai/career42/data42.html
298 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:35:31 ] 話題が飛躍しすぎててつまんねーよ。
299 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:36:45 ] コテハンさんもコテハン叩きさんも そろそろ落ち着いて建設的な話しましょう。
300 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:42:47 ] つ www.amazon.co.jp/o/ASIN/4569577482/
301 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/06(金) 00:44:32 ] じゃあマジックナンバーとラベルの誤謬について
302 名前:仕様書無しさん mailto:sage [2007/04/06(金) 00:47:49 ] むしろこっちに詳しく書いてある つ www.amazon.co.jp/o/ASIN/4569654657/
303 名前:仕様書無しさん mailto:sage [2007/04/06(金) 01:07:16 ] どうも底辺の人が来ちゃってるようだな
304 名前:仕様書無しさん mailto:sage [2007/04/06(金) 01:10:23 ] おまいらループしすぎ まずはユースケースの有効性について
305 名前:仕様書無しさん mailto:sage [2007/04/06(金) 01:12:24 ] まずは嫁 つ www.amazon.co.jp/dp/4413070569/
306 名前:仕様書無しさん [2007/04/06(金) 11:06:20 ] VB系しか知らない男は、 今後、どういう風にスキルアップしていくのが理想?
307 名前:仕様書無しさん [2007/04/06(金) 11:15:51 ] 伊賀知己のアホはオサンスレで引き受けるから おまいらゆっくり楽しめな。たまにはジャワぽんのためになる事をしようと思う。
308 名前:仕様書無しさん [2007/04/06(金) 11:59:23 ] >>304 アクターに目や口を書いて笑いをとる
309 名前:仕様書無しさん mailto:sage [2007/04/06(金) 12:41:10 ] >>307 つ www.amazon.co.jp/dp/4872331265/
310 名前:おじゃばさま [2007/04/06(金) 18:59:14 ] そういえば誰かがOO型クラス分割の利点を説明しろとか言っていたな。説明しておく。 C言語で非OOプログラミングでコーディングしていて、ずっと仕様変更を繰り返していると、 ソースコードがぐちゃぐちゃになって、結局あるタイミングで作り直しになったという経験はないか? なんでそうなるのかと考えてみよう。 a() b() c() と関数があり、それに機能で関数を作って、 d() を追加したとする。 a()、b()でこの機能を使用する場合、多くの場合、a()とb()にはif文が入ってd()を呼び出すことになる。 ここで問題なのは、if文を追加した時点で以前のa()、b()とは処理が違ってしまっていて、 前のようには使えなくなっているという事である。 それにより、別の場所からa()をd()の機能無しで使いたい場合、またa()に新たにif文を追加する事になる。 かくしてこのプログラムはスパゲッティーの道をたどる事になる。
311 名前:仕様書無しさん mailto:sage まず 日本語勉強 汁 [2007/04/06(金) 19:21:34 ] パロパロ
312 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/06(金) 19:48:59 ] 物事を自分で考えられる人はOO厨にならない。 いま残ってるのは教条主義者だけだ
313 名前:仕様書無しさん mailto:sage [2007/04/06(金) 19:49:53 ] で?
314 名前:おじゃばさま [2007/04/06(金) 20:03:13 ] ではどうすればいいか? 理想的なのは、a()はd()の機能有りでも無でも使えて、さらにa()には修正が入らない事である。 もしこれが実現出来れば、スパゲティーコードとはオサラバである。 まあ、OOを知っている人なら分かると思うが、OOではa()の拡張、機能のオーバーライドで実現出来る。 ここがオブジェクト指向の最重要点である。やりたいことは単純なのである。 しかし問題がある。 今までの非OOでの組み方でこれをやろうとすると、出来ないのである。 もう少し正確に言うと、出来るのだが間違えても気が付きにくい。 最初は問題なく見えても、変更を繰り返すうちにまた破綻する。 どう組めば破綻しないかと言うと、これがOOを知らない者には理解しにくい。 一言で言えば、抽象化なのだが、これを聞いて分かる人などいないだろう。 まあ、組み方は後で説明するとして、オブジェクト指向の利点は分かってもらえただろうか?
315 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:10:58 ] だめだこりゃ
316 名前:おじゃばさま [2007/04/06(金) 20:14:36 ] ところで電球はCコードに修正を繰り返して破綻したコードを見た事がないのか? どうすればこれをなくせるかと考えた事はないのか?
317 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:15:23 ] 誰かどうにかしろよ この自己主張禿しすぎな勘違いコテ2匹
318 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:15:44 ] ヒント:モジュール機構さえあればその件はおk
319 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:16:12 ] とりあえずsageろ>アホコテ共
320 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:16:19 ] >>317 任せた
321 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:17:09 ] 勘弁してくれよ こんなの触りたくねーし
322 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:17:28 ] |\___/| | .| | Θ Θ | / ̄ ̄ ̄ ̄ ̄ ̄ ̄ | .| < ∈AA∋ ∧∧ \_______ (゚‥゚ ) ( ゚Д゚) ∪∪|___⊃ ⊃ /|__.| |__|\ | | | | \_| | ノ ノ \_| \_ノ| | | |
323 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:18:35 ] Haskellの代数的データ型で、クラスインスタンスをメンバ(?)にするにはどうすればいいんですか?
324 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:25:00 ] トリがついてるだけココ電のほうがましな気がする。 おじゃばってひょっとしてトリップ知らないんじゃないのか。
325 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:26:56 ] >322 どっちがココでどっちがおじゃば?
326 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:44:55 ] オブジェクト開発は俺みたいに頭がよくないとできない
327 名前:仕様書無しさん mailto:sage [2007/04/06(金) 20:47:54 ] 機能変更のたびに継承しろってか? どういう覚え方したらこんな独りよがりの考え方になるんだ。
328 名前:仕様書無しさん [2007/04/06(金) 21:00:52 ] |\___/| | .| | Θ Θ | / ̄ ̄ ̄ ̄ ̄ ̄ ̄ | .| < OOとは機能変更のために継承をすることである ∈AA∋ ∧∧ \_______ (゚‥゚ ) ( ゚Д゚) ∪∪|___⊃ ⊃ /|__.| |__|\ | | | | \_| | ノ ノ \_| \_ノ| | | |
329 名前:仕様書無しさん [2007/04/06(金) 21:01:04 ] 粘土みたいに手でさわって作れるプログラム言語作ってくれ
330 名前:おじゃばさま [2007/04/06(金) 21:02:29 ] >324 トリ知らない。教えてくれ。 >326 OO出来ますって言う人は多いが、「変更にたびに完成度が増していく」ってのを実感している人は少ない。 これを話しても、仕事が出来て大量にソース組んでいる人しか同意を得られない。 才能だけでも、努力だけでもダメだって事だろ。 >327 それは誤解だ。全ての継承でやれって話ではない。 その方法が状況によって違うから、難しいんだよ。
331 名前:仕様書無しさん mailto:sage [2007/04/06(金) 21:09:25 ] トリップの付け方もわからん 挙げ句付け方をぐぐって調べることも出来ん そんなアホが説教してもなぁ
332 名前:OJAVAさま ◆Fj1.051clU [2007/04/06(金) 21:12:37 ] |\___/| | .| | Θ Θ | / ̄ ̄ ̄ ̄ ̄ ̄ ̄ | .| < 鳥つけてみたよ、すごいだろ ∈AA∋ ∧∧ \_______ (゚‥゚ ) ( ゚Д゚) ∪∪|___⊃ ⊃ /|__.| |__|\ | | | | \_| | ノ ノ \_| \_ノ| | | |
333 名前:仕様書無しさん mailto:sage [2007/04/06(金) 21:39:45 ] >>323 class Animal a where call :: a -> String data Dog = Dog instance Animal Dog where call _ = "bowwow" data Sparrow = Sparrow instance Animal Sparrow where call _ = "cheep" data AnimalH = forall a. Animal a => AH a animals = [AH Sparrow, AH Dog, AH Sparrow] main = mapM_ (putStrLn . (\ (AH x) -> call x)) animals
334 名前:仕様書無しさん mailto:sage [2007/04/06(金) 21:41:42 ] ・・・まあ確かに構造化言語においては 仕様変更に対応するために、そのプログラムの構造から変更しなくてはならないケースはある。 そうしないと(このスレ流行の言葉で言うと)破綻するからね。 でも継承とか委譲(とか「なんちゃらパターン」)の使い分けがわからない。 >>330 「状況によって違う」というのは、 「確立した方法論は無い」とか「経験則しかない」と解釈してよいのか?
335 名前:仕様書無しさん mailto:sage [2007/04/06(金) 21:43:59 ] ヒント:その件はモジュール機能導入でおk
336 名前:仕様書無しさん mailto:sage [2007/04/06(金) 21:45:35 ] >>323 存在量化(existential quantification)を使わない方法。 data Animal = Animal { animalCall :: String } dog :: Animal dog = Animal { animalCall = "bowwow" } sparrow :: Animal sparrow = Animal { animalCall = "cheep" } animals :: [Animal] animals = [sparrow, dog, sparrow] main = mapM_ (putStrLn . animalCall) animals クラス階層が必要ないなら、こっちが扱いやすいと思う。
337 名前:333 mailto:sage [2007/04/06(金) 21:47:24 ] animals :: [Animal] animals = [AH Sparrow, AH Dog, AH Sparrow] -- www
338 名前:仕様書無しさん mailto:sage [2007/04/06(金) 23:00:47 ] このスレには実は3人の住人しかいない
339 名前:仕様書無しさん mailto:sage [2007/04/06(金) 23:04:16 ] その3人とは>>338 、>>338 の脳内のお友達、>>338 の別人格、の事である
340 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/06(金) 23:25:21 ] かわいそうなOO厨の人たち・・・
341 名前:仕様書無しさん mailto:sage [2007/04/06(金) 23:50:36 ] 自覚が無いって恐ろしいな
342 名前:仕様書無しさん [2007/04/07(土) 00:59:56 ] >>341 おまいもしっかり自覚するように
343 名前:仕様書無しさん mailto:sage [2007/04/07(土) 01:55:37 ] 1つのファイルに数種類のレコードが1行以上存在するとした場合、 そのファイルを解析して3つのテーブルを更新するものとする。 この条件に最適なクラスとインターフェースを全て挙げよ。 IT/○ro課題より
344 名前:仕様書無しさん [2007/04/07(土) 06:20:45 ] オブジェクト指向以前に、利用する掲示板のFAQも読まない奴が 技術者面して他人に教えをたれようとすんな。糞。あげ。 >info.2ch.net/guide/faq.html#C7
345 名前:仕様書無しさん mailto:sage [2007/04/07(土) 06:52:26 ] 使いこなせず負け犬の遠吠えを繰り返すアホコテが1匹 使いこなしたつもりで勘違い講釈を続けるアホコテが1匹 何をやらせてもアホはアホのままって見本みたいな奴らだったな
346 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/07(土) 09:37:41 ] >>343 なにその糞問題 作ったやつ馬鹿じゃねーの?
347 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/07(土) 09:44:26 ] 問題は3行目だ 作るのか?作るんだったら俺クラスあげたって名前みんな違うからしょうがないし ライブラリ引っ張ってくるだけのものを言ってるのなら それだけのやつって事だな。 この条件に最適 ってのもDQN的に意味不明だな 「この条件でプログラムを組む場合使うクラス」なら判るが さらに「最適」っておまい決められるのかよ
348 名前:仕様書無しさん mailto:sage [2007/04/07(土) 11:16:44 ] >>343 俺はOODはイマイチよく解らんが 思い付く限りでやってみる。 数種類のレコードってことは 複数のレコード形式が雑じったファイルかな? テーブル3種は甲乙丙と名付けたとして… このファイル形式を扱うクラス レコードインターフェース 各レコード形式のクラス テーブル基底クラス 甲クラス 乙クラス 丙クラス
349 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/07(土) 12:13:30 ] テーブルと1:1でクラス作るのは、初めて組んだときやったけど 効率悪いわ、結合が増えてモジュールが破綻しそうになるわでやってないな。 Join文なんかつかえないわなー おこちゃまプログラミング
350 名前:仕様書無しさん mailto:sage [2007/04/07(土) 12:20:06 ] テーブルとクラスを1:1にしていいのはASP.NETだけ
351 名前:仕様書無しさん mailto:sage [2007/04/07(土) 13:11:17 ] TableModuleとかいうパターンだな
352 名前:仕様書無しさん [2007/04/07(土) 19:55:33 ] 再利用は不効率だから
353 名前:仕様書無しさん mailto:sage [2007/04/07(土) 19:56:29 ] 不幸率ってなんだよ非効率だろ
354 名前:仕様書無しさん mailto:sage [2007/04/07(土) 20:12:29 ] 非行率ってなんだよ国公立だろ
355 名前:仕様書無しさん mailto:sage [2007/04/08(日) 02:30:28 ] ねえねえココ電球〜〜
356 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/08(日) 03:40:55 ] はい?
357 名前:仕様書無しさん mailto:sage [2007/04/08(日) 04:06:03 ] >>356 /\___/\ /'''''' ''''''::\ |(へ), 、(へ)、.| ふふ、呼んでみただけ♪ | ,,ノ(、_, )ヽ、,, .:| | `-=ニ=- ' .:::::| \ `ニニ´ ._/ (`ー‐--‐‐―/ ).|´ | | ヽ| ゝ ノ ヽ ノ  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
358 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/08(日) 05:10:46 ] うー
359 名前:仕様書無しさん mailto:sage [2007/04/08(日) 09:58:22 ] 電球は、徹夜だったのか? 歳なんだから無理するなよ
360 名前:仕様書無しさん mailto:sage [2007/04/08(日) 10:51:21 ] さぁ、ザリガニのスーパークラスは、カニか?エビか? どっち?
361 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/08(日) 11:37:51 ] Cだと多重継承が許されるのです
362 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/08(日) 11:44:20 ] 思い出したが、結合の概念はずっと前から持っていた。 自分の頭の中で連結と読んでいたけど、 データベースのデータには確率的にぼやけているデーターがある。 量子力学の電子の雲の図を思い浮かべてもらうといい。 不確定性状態のデーターを参照しているデーターも不確定となる。 リレーショナルDBがOOと相性が悪いのはOOが不確定性データーを扱えないからともいえると思う。
363 名前:仕様書無しさん mailto:sage [2007/04/08(日) 11:57:55 ] nullってあるじゃん
364 名前:仕様書無しさん mailto:sage [2007/04/08(日) 12:01:45 ] 不確定な仕様しか出せないから不確定要素とかいう表現が出てくる 要件が確定してたらザリガニはエビかカニかなんていうどうでも良い名詞並べたいだけの考え方なんて出てこないよ
365 名前:仕様書無しさん mailto:sage [2007/04/08(日) 12:05:20 ] SQLのNULLは「不明(unknown)」「非適用(not applicable)」の意味で使われます。
366 名前:仕様書無しさん mailto:sage [2007/04/08(日) 12:25:42 ] 今のOOではクラスの構造は設計時に決まってしまうため、 AクラスとBクラスから、両方の属性を併せ持つCクラス を動的に生成できないからな。 SQLでは結合や射影を使って何通りものオブジェクトを動 的に生成できる。所謂パラダイムミスマッチ。
367 名前:ココ電球(∩T∀T)y-~~~~ ◆tIS/.aX84. [2007/04/08(日) 13:04:53 ] ちげーよ マルチクライアントだと常に誰かがデーターを変更している可能性があるから 今読んだデーターが次の瞬間もデータベース上のデーターと一致しているとは限らないということ。