05/08/24 14:22:48
派生 基本という用語がでているが
UML命名規則に従って統一しないか
派生する, 継承, 拡張 -> 汎化
派生 -> サブクラス
基本 -> スーパークラス
メンバ変数, フィールド, プロパティ -> 属性( 注 : C#の属性と間違えないように !)
メンバ関数, メソッド, サブルーチン -> 操作
364:仕様書無しさん
05/08/24 14:32:36
>>363
どうでもいい
365:仕様書無しさん
05/08/24 16:19:29
どうでもよくない！ ｶﾞｼｬﾝ！
366:仕様書無しさん
05/08/24 16:36:01
>>363
お断りだ。
367:仕様書無しさん
05/08/24 17:25:47
とりあえず
オブジェクト -> おっぱい
でいいんじゃない
368:仕様書無しさん
05/08/24 19:19:53
もうこのスレ終わりか。
8なんたらも講義の続きができないみたいだからな。
369:仕様書無しさん
05/08/24 20:43:22
>>363
「派生する, 継承, 拡張」は、「汎化」の逆の方を言うんじゃなかったっけ？
370:仕様書無しさん
05/08/24 20:58:21
派生・継承は「特化」。たしかに汎化とは逆の筈
371:仕様書無しさん
05/08/25 01:05:00
お前ら愚鈍どもに聞きたい
最高ですかーーー？
372:仕様書無しさん
05/08/25 01:08:00
>>362
いや、デスマの原因は営業の交渉能力に依存する。
営業がバカであればデスマは簡単に起こる。うちのバイト先がもろにそうだ。
バイト先を見て思ったが
バカに営業はやらせないほうがええな。
バカに営業やらせるとできないこともすぐできると大嘘ばかりつく。
バカな営業をクビにしたいところだが、そいつ、会社役員なので
それができない。しかも威張ってる。最悪だ。
そのとき思ったよ、
技術がろくに解ってない奴なんかに営業なんて絶対やらせるべきじゃないと悟ったね。
技術が解ってない奴は中身が見えてないから
どんなものでも魔法のようにすぐに簡単にできると勘違いしている。
顧客がバカでも営業が賢ければ多少は救いようがあるのに
営業がバカで威張ってるからこの会社はいつもデスマで土日も休みがない。
しかも残業代は一切無いし(嘲笑
ああ、こんな会社の社員じゃなくてよかったw
373:仕様書無しさん
05/08/25 01:08:29
>>366
UMLに逆らう奴は氏ね
374:仕様書無しさん
05/08/25 01:12:01
UML命名規則が嫌ならJavaキーワードに従おう
拡張, 派生 -> 継承
子クラス, 派生クラス ->サブクラス
基本クラス、親クラス -> スーパークラス
純粋仮想関数 -> 抽象メソッド またはabstractを使って表現
メンバ関数、操作 -> メソッド
メンバ変数、プロパティ、属性 -> フィールド
C#の属性、Javaのアノテーション -> アノテーション または@を使って表現
375:仕様書無しさん
05/08/25 01:15:16
不変クラスの作り方
setterメソッドは使用禁止。
インスタンスフィールドはすべてfinal宣言し
コンストラクタを呼び出した時点で
すべてのインスタンスフィールドへの代入を直ちに完了させる。
getterメソッドを用意する。
メソッドの操作によってオブジェクトの中身が変更されることはあってはならない。
一度生成したオブジェクトは、その後、いかなるメソッドを呼び出しても
メソッド呼び出し後、呼び出し前とでは全く同じオブジェクトになり
Object#equals()を呼び出しても必ずtrueになるようにする。
クラスはfinal宣言する。
376:仕様書無しさん
05/08/25 22:11:08
委譲の話が異常に盛り上がったので、以上で終了します。
377:仕様書無しさん
05/08/25 22:17:18
>>376
頼むから死んでくれ
378:仕様書無しさん
05/08/26 00:02:13
>>377
ブ・ラジャー！！
379:仕様書無しさん
05/08/26 04:25:16
>>376
だめだ。許さん！ ﾋﾞｼｯ! ｶﾞｶﾞｯ!
380:仕様書無しさん
05/08/26 04:26:49
委譲 -> Delegation
集約 -> Aggregation
コンポジション集約 -> Compisition
継承 -> Generalization, Extension, Inheritance
381:仕様書無しさん
05/08/26 23:49:23
>>379
100万円差し上げますのでどうか許してください
382:仕様書無しさん
05/08/28 11:33:26
100万円？
匿名掲示板でそんなこといっても信じねぇぞｺﾞﾙｧ
100万円に相当する情報を匿名掲示板に無料でばらまいてみろ。
マスコミに目が届くほど100万円に相当する力を発揮してみろ。
383:仕様書無しさん
05/08/28 15:22:41
子供銀行券の100万円に決まってんだろうが
何あつくなってんのﾁﾐ
384:仕様書無しさん
05/08/28 17:40:08
なぁ…つまらない奴の存在ってのは罪だと思うんだが、どうだろう。
385:仕様書無しさん
05/08/28 18:38:19
「あぁ、お前のことか」と言う
386:仕様書無しさん
05/08/28 20:29:17
>>385
ちょっと長いよ
387:仕様書無しさん
05/08/29 00:10:24
がっかりだぜ
388:仕様書無しさん
05/08/30 23:39:50
お前らは今までに食ったパンの枚数を覚えているのか？
時は今！
場所はここだ！
389:仕様書無しさん
05/08/31 14:17:27
時は宇宙、所は未来
390:仕様書無しさん
05/08/31 16:19:00
時間と空間は等価ってヤツですね！
391:仕様書無しさん
05/08/31 23:09:32
いや、上手くないし。
なんだその得意げな顔は。
392:仕様書無しさん
05/09/01 03:48:38
やれやれだぜ
393:仕様書無しさん
05/09/01 04:00:32
394:仕様書無しさん
05/09/02 18:57:55
緊急アンケート開始
あなたは
１、クンニ派？
２、指派？
395:仕様書無しさん
05/09/03 17:20:09
３，ちんこ派
396:仕様書無しさん
05/09/03 17:31:46
４．おもちゃ派
397:仕様書無しさん
05/09/03 17:55:25
オブジェクト指向の講義の続きまだー？
398:仕様書無しさん
05/09/03 18:01:08
５．貝合わせ派
399:仕様書無しさん
05/09/04 03:39:48
６、はぐれ刑事、童貞派
400:仕様書無しさん
05/09/04 03:57:03
７．貧乳支持派
401:仕様書無しさん
05/09/04 12:08:50
それは「微乳」と呼ぶのだ
402:仕様書無しさん
05/09/07 15:35:21
8. あなたの尻の穴を舐めさせてください派
403:仕様書無しさん
05/09/07 20:48:01
毎度毎度、迷惑メールはフィルタリングでゴミ箱逝きのメール環境だが、
なんとなくゴミ箱の迷惑メールを見てみたら笑えるのが来たので報告します。
≪日本人以外の女性も多数在籍中≫
※日本在住の女性中心です。
URLﾘﾝｸ(1191.jp)
逆援・エッチなチャットや電話、メール交換・1-対-1 のセックス・秘密の関係・SM調教・女装や男装・・・・・・・から選んでピッタシの女性をお探し下さい。
URLﾘﾝｸ(1191.jp)
お試し登録の方に完全10000万円分差し上げます。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
●NO.I don't veceive your mail●
sweet_as_candy_700@yahoo.fr
●今後、受信を拒否する場合は●
sweet_as_candy_700@yahoo.fr
ちなみに、クリックしてしまうとどうなるか分からないので自己責任乙。
404:仕様書無しさん
05/09/07 20:55:22
> お試し登録の方に完全10000万円分差し上げます。
この部分が意味不明で凄過ぎです。1億円もらえるっぽいです。
405:仕様書無しさん
05/09/18 12:17:30
この前はじめてオブジェクト指向のプログラムの作り方教わったけど
ハッキリ言ってオブジェクト指向ってショボイね。
もっと凄いもんかと思ってた。
406:仕様書無しさん
05/09/18 12:18:03
>>405
いやいや、作るのは大変なんですって。
407:仕様書無しさん
05/09/18 12:21:46
作るの大変だしメンテもそれほど楽とは言えない。
開発者のオナニーの塊がオブジェクト指向ということで結論は出ている。
408:仕様書無しさん
05/09/18 12:23:52
イメージの出来てない人間のやるオブジェクト指向は似非だ
似非オブジェクト指向は本当にひどいプログラムを生み出す
409:仕様書無しさん
05/09/18 13:53:13
>>405
>この前はじめてオブジェクト指向のプログラムの作り方教わったけど
OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。
410:仕様書無しさん
05/09/18 13:59:36
OOPSは教わった
411:仕様書無しさん
05/09/19 18:05:49
＞ OO を知らずに OOP だけ教わったんじゃあ、話になりませんね。
実際には、OOPを習って自分で書いてみて初めてOOが理解できるという構図が一般的。
なぜならOOだけ勉強してもあまりにも概念的過ぎるから。
とりあえずOOPでOOしないで組んでみて、それをOOに直していくっていうのがいまフィリピンで大ブーム。
できる奴ならOOAとOODをやって、OOPはほかにまわす。これが南アでひそかなブーム。
412:仕様書無しさん
05/09/19 19:02:36
まあ、OOだけ知ってるってやつよりはOOPだけ知ってる、ってやつのほうが仕事しやすいけど。
413:仕様書無しさん
05/09/19 19:42:11
「OOP だけ知ってる」 ってやつは大抵 「とにかくクラスを１つでも作れば OOP」 って思ってる奴だと思う
414:仕様書無しさん
05/09/19 20:27:54
んなこたあないだろう。
OOP知ってる、って言う場合、
大抵Javaや.netのプロジェクトにPGとして参加したことがあるやつだろ。
415:413
05/09/19 20:37:13
む、実は学生だからその辺良くわかんない
何というか、俺はみたことあるのよ
クラス１つ作って input, process, output の３つの引数なしメソッドを追加して 「これが OOP だ」 って言っちゃった人を
しかもその人、java の継承については差分プログラミングの部分しか説明して無いし
あれじゃ講義に出た人は、絶対に曲解しただろうに
416:仕様書無しさん
05/09/19 21:57:19
OOだけ知ってる奴→「みかんは果物の継承でだなぁ…」とかいう受け売りを得意げにばらまく。プログラムは組まない。
OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。
417:仕様書無しさん
05/09/19 22:05:39
>>416
＞OOPだけ知ってる奴→C++をベターCとして使う。Javaを関数型言語として使う。
ごめんよくわかんない
418:仕様書無しさん
05/09/19 22:11:56
OOPってOOも含むんじゃないの？
419:仕様書無しさん
05/09/19 22:15:11
>>416
>OOPだけ知ってる奴→C++をベターCとして使う。
これは出来るが・・・
>Javaを関数型言語として使う。
これは無理。原理的に。
420:仕様書無しさん
05/09/19 22:35:46
DelphiをVisual Pascalとして使う
って言い回しがあったなあ（涙）。
421:仕様書無しさん
05/09/19 23:30:41
>>418
OO を使ってプログラミングすることを OOP と言うんだ
422:仕様書無しさん
05/09/19 23:32:05
OO －継承→ OOP
423:仕様書無しさん
05/09/19 23:34:28
継承じゃないだろ
424:仕様書無しさん
05/09/19 23:35:26
集約？
やっぱ継承じゃね？
425:仕様書無しさん
05/09/19 23:41:27
OOP is OO …… なのか？
OO は概念、OOP はプログラミングテクニックだから、俺は継承じゃないとは思ったが
426:仕様書無しさん
05/09/19 23:41:51
プログラムの側から見れば
プログラム → OO
オブジェクト指向の側から見れば
OO → OOP
切り口をどちらに取るかによって関係が変わるけど
オブジェクト指向は抽象クラスであって
OOPという具体的な形にしないと使えないと思われ
427:仕様書無しさん
05/09/19 23:43:43
＞プログラム → OO
プログラム → OOP
に訂正
428:仕様書無しさん
05/09/20 00:18:16
切り口の意味がわかんないっす
429:仕様書無しさん
05/09/20 00:25:06
クラス分けするときの見方のこと
どういった側面から物事を見るかで
クラスの分け方が変わってくると思う
>>426の例でいえば
プログラムを元に考えるかオブジェクト指向を元に考えるかで
どちらが基本クラスになるかが変わってくる
この辺の考え方はこれで合ってるよね？
430:仕様書無しさん
05/09/20 00:30:13
ごめん。俺の考えと異なるからうまくわかんないわ (-∀-)
俺は最初の段階でプログラムの完成図を OO でマッピングしちゃうから
431:仕様書無しさん
05/09/20 00:32:15
俺も我流だから自信ないんだよね・・・
パス。
432:仕様書無しさん
05/09/22 19:02:38
OOとは～とか、OOが分かったとか、漠然としすぎだよな。
デザパタで無理やりJavaってみて初めてCと違うと気づく。これでいいんじゃね？
433:仕様書無しさん
05/09/22 19:19:44
そだね
434:仕様書無しさん
05/09/23 09:52:25
結局必然性が感じられないから、いつまでたっても理論家の一人よがりに見えるんだろうな。
実際に使ってみれば、本当に綺麗なプログラムってやつが記述できるんだが。
いかんせん、規模がでかくて、構造が複雑で、変更や拡張を前提としているプログラムでないと、
ひたすら「余計な手間」に見えてしまうというのは、確かに効果が見えにくいかも知れない。
見えやすい効果としては、今までライブラリの中に漫然と並んでいた関数郡が、
階層化された構造の中にある、ってだけでも恩恵あると思うんだが。
でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ
435:仕様書無しさん
05/09/23 11:14:52
＞でもそれで魅力を語ろうとすると、「いや、それはOOの本質じゃない」とか言われるんだろうなｗ
俺はそれが本質だと思う
どんな手法も結局整理整頓の方法の一つだと思う
436:仕様書無しさん
05/09/23 11:34:38
>>434-435
そういう議論になっても、「本質」という言葉の定義が各自バラバラだから
議論がかみ合わないｗ
437:仕様書無しさん
05/10/22 16:48:11
ｽﾚﾘﾝｸ(tech板:5-7番)
438:仕様書無しさん
05/10/27 16:50:37
初心者です。
オブジェクト指向って皆さんはどのようにして勉強されたのですか？
やはり何か書籍とか読んだのですか？
439:仕様書無しさん
05/10/27 16:52:31
何年も掛けて慣れた
440:仕様書無しさん
05/10/27 17:17:00
C++やJAVAを使っているだけでオブジェクト指向と言ってる人もいれば、
ちゃんと考え方まで取り入れて設計している人までさまざまですね。
実際はどちらが多いのでしょうね？
441:仕様書無しさん
05/10/27 17:24:58
絶対に前者
442:仕様書無しさん
05/10/27 17:31:05
>>440
８０：２０の法則に乗っ取ってるかも。かも。
443:仕様書無しさん
05/10/27 17:41:12
UML描ける人はオブジェクト指向してると思っていいのかな？
今、勉強中だけど。。。
444:仕様書無しさん
05/10/27 17:45:39
ゆるさん
445:仕様書無しさん
05/10/27 17:46:42
どゆこと？
446:仕様書無しさん
05/10/27 18:12:10
指向って言葉の意味を考えれば
厳密な定義があろうはずもないじゃないか
447:仕様書無しさん
05/10/27 18:16:13
厳密な定義が無くても、それなりの概念はあると思うのだが。
でなきゃ、OOP言語やら書籍など巷にあふれないもんな。
オブジェクト指向に挫折した人って、
そう言い訳していつも逃げてるのかしら？？？
煽ってんじゃないのよ。
避けてる人、挫折した人の本音が知りたいのよ。
448:1/2
05/10/27 18:29:46
いまさらだが、上がってたのでロボットクラスに関してレス
結局目的が定義されずに分類だけ進んでる事が問題。
public 出るもの 出す() メソッドが、
ロボットたるもの、何かを出せてしかるべきだ。
というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。
しかし、
ドラえもん：便利な道具を出してマスターを助ける。
ガンダム：宇宙空間で敵と戦う。
のようなコンセプトであるならば、出す()メソッドを抽象化する必要性があまりない。
どちらかというと継承ではなく、ロボットクラスをハードウェアとして、委譲して持っているべきではないか。
449:2/2
05/10/27 18:31:11
実際のOO開発では、現実世界で考えられる振る舞いを全て実装する事はなく、
プロジェクトにあった必要最小限なものだけを実装するわけだが、ここで現実世界とのギャップが出てくる。
たとえば、上の例でロボットを新しく追加したいが、出す()メソッドが必要ない。（出すものがない）といった仕様変更が来た場合どうだろう。
現行のプログラミングでは全てロボットは何かを出せる。として設計してあった場合に困った事になる。
つまり、OO設計とは、現実世界の「一部」を抽出する行為であり、
その一部の範囲に含まれない仕様変更があった場合に破綻をきたす。
しかし大きなプロジェクトほど、ありえない仕様変更が多い。
現実世界を完全に投影できれば最強だが、一部しか実装しない場合は破綻する可能性がある。
ならば変なルールなど作らずに、修正の容易な（影響範囲が少なくてすむ）設計でもいいのではないか？
という意見もなくなくなくなくなくない？と思ったりもする。
450:仕様書無しさん
05/10/27 18:43:51
どこのスレでロボットが出てきたのかと思えば、このスレだったのか。忘れてたな。
＞ロボットたるもの、何かを出せてしかるべきだ。
＞というコンセプトで設計されているなら、出てくるものが道具でもビームでも置換原則は守れている。
『何も出さないロボット』 が登場し、親クラスが想定していない動作……
例えば null を出す場合や、例外を搬出する等を行った時には、リスコフ置換原則は守られていない。
逆に、親クラスで 『何も出さないときには例外を出す』 とか定義しているなら、
実は置換原則は守られていたりする。
# ちなみに、親クラスに 『出す』 が無い場合には、置換原則はそもそも関係ない。
意外と親クラスがどこまで物を考えているかに関係しちゃったりするんだよなぁ。
けど、親クラスの変更は子クラスまで伝播するから、親クラスを改変しないことを第一に考えるべきかと思ったり。
451:仕様書無しさん
05/10/27 19:55:37
>>414
ハッタリC言語厨は>>413に挙げられる例を醸し出す香具師が多いのも事実なわけで
452:仕様書無しさん
05/11/06 04:58:20
ていうか、オブジェクト指向を理解もして無いﾔｼが、
挫折した腹いせに「OOPは無駄」とか必死に言ってるのがｱﾜﾚｿｽ。
453:仕様書無しさん
05/11/06 13:00:53
>>452
…と、ﾏﾙﾁしてる君の方が必死に見える。
454:仕様書無しさん
05/11/06 13:15:07
まあ、ダメな人間ってのは、何をやらせても自分のせいではなく、周りのせいだと思うものだし。
自分の置かれている状況と、チーム内の人間と、開発体制と仕様書にけちつけて自己弁しつづけるよな。
455:仕様書無しさん
05/11/14 13:15:43
オブジェクト指向プログラミングの場合、
マスターファイルをトランザクションファイルで更新するというプログラムは
どうやって組むんですか？
456:仕様書無しさん
05/11/14 14:35:45
仕様による。
457:仕様書無しさん
05/12/26 11:53:40
あんなにクリスマス～って騒いでても、
一瞬の出来事だったね。
今度は大晦日～って盛り上がるんだろうけど、
来週の今頃って、もう来年だよ。
それも、既に元旦過ぎてる。
458:仕様書無しさん
05/12/29 01:45:24
『オブジェクト指向でなぜつくるのか』
つー本読んだが・・・やっぱ理解できない
このシリーズの中でこの本だけ判り難いとおもた
今日
459:仕様書無しさん
05/12/29 16:18:16
とりあえず、このスレ見ててオブジェクト指向が理解できて無い奴は
憂鬱本は読んだ上で言ってるんだよな？
460:仕様書無しさん
05/12/29 16:19:06
つーか、次回から最低でも憂鬱本の紹介はテンプレに入れろ。
461:仕様書無しさん
05/12/29 19:16:21
憂鬱本って？
462:仕様書無しさん
05/12/29 19:36:19
ぐぐったら１・２・３番目に出てくるじゃないか
463:仕様書無しさん
05/12/29 19:36:23
>>461
URLﾘﾝｸ(tito.fc2web.com)
URLﾘﾝｸ(tito.fc2web.com)
憂鬱なプログラマのためのオブジェクト指向開発講座 ― C++による実践的ソフトウェア構築入門
Tucker (著)
翔泳社(1998) ISBN:4-8813-5619-4
デザパタはあくまでパターンなのでオブジェクト指向の理論とは関連が薄いから
実質2ch一番人気のオブジェクト指向本となる。
464:461
05/12/29 20:03:53
サンクスです
アマゾンの書評みたら。。。
『全米が泣いた！！』みたいな感じでｗ
明日から読んでみよう
でもってまだわかんなかったら
ここに粘着
465:仕様書無しさん
05/12/30 11:26:57
古め（？）の本が多いみたいだから
モダンな ooもどうぞ
例えば
URLﾘﾝｸ(www.amazon.co.jp)
466:仕様書無しさん
05/12/30 11:28:46
オブジェクト指向なんて全然大したこと無いよ
ようは関数の概念をちょっと弄って使いづらくしただけ
オブジェクト指向考えた奴ってアホだな
467:仕様書無しさん
05/12/30 13:11:14
>>466←こういうのもう相手にしなくていいっしょ？ｗ
468:461
06/01/03 15:08:24
憂鬱本読み終わりました
目から鱗でした
でも、図が書けない実装できない
急に面白くない状態になりました
469:仕様書無しさん
06/01/06 06:55:37
アナリシスパターンとかよく使うんですか？
470:仕様書無しさん
06/01/06 09:53:37
仕事で？使わないよ
471:仕様書無しさん
06/01/06 19:29:36
アナル挿すパターン
472:仕様書無しさん
06/01/06 21:25:37
イベントドブリン型も知らないで何がオブジェクト指向だか・・
最近の若いプログラマーは流行だけを追いかけて頭でっかちで全然使い物にならん
473:仕様書無しさん
06/01/06 21:29:22
ドブリンかい
474:仕様書無しさん
06/01/06 23:15:51
全然関係ないけどドリブンってドライブの過去分詞だけど、
微妙に直感的じゃないんだよな。
イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。
厨房のころ「イベントドンブリ？なんかよくわかんね」って投げ出した思い出あり。
475:仕様書無しさん
06/01/06 23:19:29
>>474
>イベント駆動とかイベントドライブとかの名前にしたほうが全然わかりやすかったと思う。
安心しろ。
それは、お前に説明する為に作られた言葉ではないから。
476:仕様書無しさん
06/01/06 23:42:28
イベントドブリン型も知らないで何がオバジェクト指向だか・・
最近の若いプログラモーは流行だけを追いかけて頭とっかちで全然使い物にならん
477:仕様書無しさん
06/01/06 23:47:32
今時イベントドリブンを知らんプログラマなんかいるのか？
478:仕様書無しさん
06/01/06 23:49:08
だから、
イベント【ドブリン】じゃなくてイベント【ドリブン】だって。
まぁ、コピペの釣りだからしかたないか。
479:仕様書無しさん
06/01/06 23:49:35
イベント丼か
480:仕様書無しさん
06/01/06 23:49:51
>>477
あまりにもありふれすぎててその名前を聞かないだけだと思うんだが。
481:仕様書無しさん
06/01/07 00:39:50
きちんとインストロールしないからだ
482:仕様書無しさん
06/01/07 00:50:48
>>476
たしかに自己満足のコード書いて自慢する新人が増えてるね
俺の配下からは追い出してやったけど
483:仕様書無しさん
06/01/07 01:15:08
イベントドンブリ
484:仕様書無しさん
06/01/07 09:36:57
>>1
とりあえずどんなOSでもいいからGUIシステム実装してみろや、出来上がるころには確実に身についているはず。
485:仕様書無しさん
06/01/08 16:56:05
つか、何故オブジェクト指向スレにきてイベント丼の話をしだすのか不明。
あんなの適当にめっさげが降ってくるだけじゃん。
スウィッチケースでテキトーにわけて処理核だけじゃん。
何えばってんの？この人。
頭弱いんじゃない？
豆腐だな豆腐。
486:仕様書無しさん
06/01/08 18:39:11
>>485 m9（＾Д＾）ﾌﾟｷﾞｬｰ
487:仕様書無しさん
06/01/10 11:36:50
>>485
>あんなの適当にめっさげが降ってくるだけじゃん。
めっさげてｗ
マッサージの読み方も知らんのかｗｗ
488:仕様書無しさん
06/01/10 14:17:30
うますぎて付いていけん
489:仕様書無しさん
06/01/10 14:44:23
「冬厨になりきって冬を満喫するスレ」かと思った
490:仕様書無しさん
06/01/10 16:09:00
自分は、「降ってくる」ではなくて「上がってくる」という感覚なのですが。
491:仕様書無しさん
06/01/10 19:34:50
>>490
マジレスですか？
Win32APIをベタで書きで、「降ってくる」ようなイベントの記述もあったような希ガス(めちゃ汚いソースだが)
じゃばらーのイベントのイメージはやっぱり「上がってくる」って感じ？
492:仕様書無しさん
06/01/10 23:03:24
「上がってくる」のは例外かな・・・
俺は後で呼んでもらうために参照を渡しておく程度の感覚しかない
493:仕様書無しさん
06/01/31 09:03:26
エロで検索してたら良スレﾊｹｰﾝ
494:彦麻呂
06/02/26 20:08:09
うわぁーーー
プログラムの 分割民営化やー
495:仕様書無しさん
06/03/23 14:11:05
オブジェクト指向を理解できないやつは、どんな仕事も非効率な無能人間。
496:仕様書無しさん
06/03/23 23:27:03
コボラーのことか？
497:仕様書無しさん
06/03/24 01:05:59
うわぁーーー
プログラムのノルディック復号や
498:仕様書無しさん
06/03/24 02:16:24
うわぁーーー
プログラムの年末工事や
499:仕様書無しさん
06/04/23 15:28:47
ロボットの話に戻るけど、
顧客から「ガンダムやドラエモンからも白い物を出させたい」って
言われたらどうするの？
500:仕様書無しさん
06/04/23 15:37:31
ロボットクラスの出るものをコレクションにすればいいのかな？
これだとスーパークラスを変更しなくちゃならないけど。
501:仕様書無しさん
06/04/23 17:06:35
「これ、何に見えます？」
「えぇ～っ飛行機をロボットにぃ！？」
502:仕様書無しさん
06/04/23 22:03:18
>>501
二重継承ですか。
503:仕様書無しさん
06/04/24 11:05:41
>>499
しごく
504:仕様書無しさん
06/04/24 22:10:25
白いものって、白けりゃ何でもいいのか？
煙くらいなら、デフォでガンダムとか出るんじゃまいか？ｗ
505:仕様書無しさん
06/06/13 01:03:37
トラックバック:URLﾘﾝｸ(app.blogs.itmedia.co.jp)
脱オブジェクト指向のススメ
URLﾘﾝｸ(blogs.itmedia.co.jp)
このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpinする。
オブジェクト指向のことをまったくわかっていません。
というか、かなり勘違いしています。
そのくせにオブジェクト指向を否定しています。
あまりにも突っ込みどころが満載です。
これで代表取締役が務まるのですから
思いっきり叩いてやっちゃってください
506:仕様書無しさん
06/06/13 11:42:23
>>505
「IT」業界の人の言う事ですから
コンピュータ業界とは違う常識があるんでしょう。
507:仕様書無しさん
06/06/14 22:48:06
読みやすいプログラムとか、拡張しやすいプログラムにしようとすると
知らないうちにオブジェクト指向的なものになることが結構あるんだがな・・・
508:仕様書無しさん
06/06/15 00:31:31
>>505
んー結構あってんじゃない？
なんか間違ってる？
なんか最近オブジェクト指向って言葉を拡大解釈してる奴がいてうざいけど
オブジェクト指向自体は何も生まんし、生産性なんかあがらんし、再利用なんて狙ってないし、
ただ、ただ、単にオブジェクト単位でクラス作ろうぜってだけなんだけど。
なんか、これ以外の意味をもたせることに必死なボーヤがいるようなんだよね。
オブジェクト指向自体はオブジェクト単位でクラス作るってただそれだけしか説明してないし、
こう作るとうまくいくっぽいよ。マジで。としかいってない。
なにせ、しょっぱなはシミュレーション用に作られたもんでオブジェクトごとに作るといいっぽいよってホントただそれだけで
別に何がどうとかカニがどうとかそんなもんはこれっぽっちもなかったはずだよ。
509:仕様書無しさん
06/06/15 09:11:18
>>508
ラリった中年のような文章だ。
510:仕様書無しさん
06/06/15 20:21:17
508は最初の最初は避妊に失敗して産まれたんだけど、
そのうちに偉大な人間になるようにと願をかけられて、
結局今のていたらくがあるわけだ。
511:仕様書無しさん
06/06/15 21:52:30
508が痛すぎる件について
ネタか釣りかコボラーだよな、な？
512:おじゃばさま
06/06/16 09:11:47
オブジェクト指向で再利用を狙っていない？
確かにオブジェクト指向を信仰している奴は多いが、再利用を狙っていないと言うのはおかしいな。
元々は再利用のための技術だぞ、それも「Windowプログラム」のな。
構造化CでWinやXのWindowアプリケーションをつくってみろ、そうすれば分かる。
今はそれが他のプログラムにも転用されているがな。
513:仕様書無しさん
06/06/16 09:38:06
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.rubyist.net)
オマエラが好きそうな厨房系天才プログラマの２人も同じようなこと言ってるけど
これについてはどう思うんだ？
514:仕様書無しさん
06/06/16 21:26:07
やねうらおは所詮8bitアセンブラで思考が止まっちゃったような人だからな～・・・
515:仕様書無しさん
06/06/16 21:32:15
>>512
嘘吐くな。
オブジェクト指向は元々はシミュレーションのためのもの。
再利用しやすいってのはあくまでおまけ。
516:仕様書無しさん
06/06/16 22:23:40
再利用つうのは大昔からソフト業の悲願なんだよ。
おまけであろうがなかろうが「再利用可能」つうのは
何よりも大きなウリなんだ。
もちろん「可能である」ということは
「誰にでも再利用可能なものを作る事ができる」
という事では無いことは御承知だと思うけど。
517:仕様書無しさん
06/06/16 22:34:42
>>516
それ、お前の勝手な考えだろ？
再利用なんてのはプロジェクトが完全に終わってからでないと
それがよかったか悪かったなんて判断できないだろ。
ＡクラスとＢクラスの両方で使われているＣクラスが
プロジェクトの最後までＡクラスとＢクラスの両方で使われる保障なんてそうそうあるもんじゃない。
ちょっとした仕様変更で
Ａクラスで必要なＣクラスとは似て非なるＡＣクラス、
Ｂクラスで必要なＣクラスとは似て非なるＢＣクラスが
いつどういう形で必要になるかは正直予想できない。
このとき、ＡＣとＢＣが共通のつもりで使っていたＣクラスを継承することで
できるかどうかだってやっぱりわからない。
また、再利用ができたって、だからどうしたって思うんだがな。
具体的に何がどういいんだ？
メリットとそれと同じ数のデメリットを抱えるだけの話であっていいだけでは終わらない話だと思うんだがね。
ただ、まったくやらないという話ではなくて、あくまでシステム的に自然とそうなるものであって
再利用を狙ってやるようなことは「俺は」無いけどね。
518:仕様書無しさん
06/06/16 23:05:08
>>517
>それ、お前の勝手な考えだろ？
匿名掲示板は自分が思う事を書く場所さ。
「勝手な考えだ」と思うならそう思いなさい。それはお互い様だ。
OOPLを広める為に「これは再利用可能なプログラムを書くことができます」
という表現が多用されたのは事実だよ。
>具体的に何がどういいんだ？
俗に言うアプリケーションコンテナを使った事はありますか？
519:仕様書無しさん
06/06/16 23:09:37
>>518
質問に質問で返すアホとは会話できません。
520:仕様書無しさん
06/06/16 23:56:13
一つのファイルで複数のオブジェクトプログラムが作れる→なんか楽→ｳﾏｰ
という漏れの考えは間違ってますか？
521:仕様書無しさん
06/06/17 00:42:37
オブジェクト指向って、別に具体的なメリットを求めてるわけではないと思う。
手続き型よりオブジェクト指向のほうが直感的だと思う人がいて、そして
そういう人たちにとって直感性に優れることから、派生的になにがしかの
メリットが得られるという感じ。
522:仕様書無しさん
06/06/17 01:00:05
>>521
そうそうそんな「感じ」。
その「感じ」ってのをつかむのが一部の人間にとっちゃ難しいってのがオブジェクト指向だと思うんだよね。
はじめシミュレーションで活躍してたってところからなんとなくイメージしてみてよって感じだが。
ホント大事なのはこの「感じ」って部分だと思う。
523:仕様書無しさん
06/06/17 11:28:47
>>515
>オブジェクト指向は元々はシミュレーションのためのもの。
と強弁してるのは多分君だけ。
事実だとしても、「元々」 が今の話にどう関係してくるんだ？
524:仕様書無しさん
06/06/17 13:35:50
>>523
なにそれ？
今と昔でオブジェクト指向の意味が違うとか言い出す気？
525:仕様書無しさん
06/06/17 13:46:03
>>523
URLﾘﾝｸ(ja.wikipedia.org)
これが最初だボーヤ。
526:仕様書無しさん
06/06/17 13:51:20
>>524
十数年も経てば違って来ているとしても不思議はない。
増してや、お前のいう「シミュレーション」以外に応用しようとするなら。
527:仕様書無しさん
06/06/17 13:52:45
…Simula かよ…
そりゃ OOPL の始まりであって
OO の最初じゃないだろうに。
528:仕様書無しさん
06/06/17 14:00:01
>>526
じゃあ、何を規準に正しいとするわけ？
まあ、変わったと主張するとしても今と昔でどう変わったのかも知っておいたほうがいいんじゃないの？
俺は最近のオブジェクト指向を唱える奴ってのは
はっきりいって勘違いした、間違ったままのことを言ってる奴が多いと思うね。
まあ、雑誌とかでも平気でそういうことが書かれてるからそれが正しいと思っちゃうのかもしれんけど。
いま、ものすごくごちゃごちゃになってるよね？
オブジェクト指向って結局なんなの？ってのがわからないのをいいことにみんながみんなテキトウなこと言ってるから。
始めは
開発の動機は、ある制限化におかれたモデル群の全体の挙動をどう記述するか、というものである。
気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が自然で取り扱いやすい。
その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が必要となる。
こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
ってことなんだよ。
そんな難しいこと書いてないだろ？
もしかしてちょっといいんじゃね？程度だ。
別に開発期間がどうだとか、再利用がどうだとか、そこまで計算されてねぇよ。
529:仕様書無しさん
06/06/17 14:01:10
>>527
はぁ？ちゃんと読んでよ。
なお、Simula当時「オブジェクト指向」という言葉はまだない。
この用語はアラン・ケイがSmalltalkの概念として70年代ごろに使い出したのが始まりといわれている。
従ってその意味ではSmalltalkが世界最初のオブジェクト指向言語であり、
Simulaは「オブジェクト指向として再認識が可能な最古の言語」ということができる。
530:仕様書無しさん
06/06/17 16:55:28
>>529
そうだね。クラスやオブジェクトは、実はオブジェクト指向とは関係ないところで考え出された。
ストラウストラップは C に「Simula のクラス」を使って、抽象データ型、つまり、ユーザーが型を
定義できる機能を付加した。これがオブジェクト指向プログラミングのスタート。
それとは別にアラン・ケイの「メッセージング」というパラダイムに基づくオブジェクト指向がある。
この２つがごっちゃにされているから、言語間宗教戦争とか、おかしなことになるんだ。
URLﾘﾝｸ(d.hatena.ne.jp)
「オブジェクト指向の概念の発明者は誰ですか？」
531:仕様書無しさん
06/06/17 17:23:39
アランケイのオブジェクト指向とSIMULAのオブジェクト指向は別物だな。
アランケイのオブジェクト指向はなんか複雑なだけで恩恵は無い気がする。
532:仕様書無しさん
06/06/17 17:26:34
俺はストラウストラップ自身もSIMULAのオブジェクト指向（？）は理解できてなかったと思うけどね。
なんかいってること違うしね。
533:仕様書無しさん
06/06/17 18:59:03
いや。理解するも何も、Simula にオブジェクト指向はないんだって。
クラスやオブジェクトを拝借したストラウストラップがリスペクトして「オブジェクト指向言語」だと
言っているだけで。本当は、彼のオブジェクト指向にてらしても、Simula はその範疇にない。
534:仕様書無しさん
06/06/17 19:00:53
>>531
アランケイのオブジェクト指向は単純だと思う。なんでもメッセージ、それだけ。
あえて難しくいうと、疎結合とか、徹底した動的性なんだけど、まあいいや。
535:仕様書無しさん
06/06/17 21:30:24
>>533
いや、でも>>528の気体分子の例は明らかにオブジェクト指向だと思う。
これをオブジェクト指向といわずに何をオブジェクト指向と呼ぶのか？ってぐらい。
536:おじゃばさま
06/06/20 08:14:01
>528
とても参考になりました。
528の言う事が非常に納得できるので、シミュレーション派に寝返らせていただきます。
シムラ万歳！！
537:仕様書無しさん
06/06/21 13:07:17
Cでオブジェクト指向プログラミングするとしたらどうなるのよ
ひとつの処理をファイルに纏めるの???
グローバル変数をstaticで宣言するの???
set_**** って感じで上の変数に入れるの???
教えて
538:仕様書無しさん
06/06/21 13:09:47
>>537
// コンストラクタ
FILE* fopen(const char* filename, const char* opt);
// デストラクタ
int fclose(FILE* fp);
539:537
06/06/21 13:26:18
なるほど
例えば リスト処理の時もあちこちにコードを書かないで
add()
del()
と書けばいいのですね?
リストからtitleの値を取り出すとき
get_title(list)
とするか
list -> title
とするかどっちがいいですか?
540:仕様書無しさん
06/06/21 15:22:51
知らんがな
541:仕様書無しさん
06/06/21 15:48:45
晒しage
542:537
06/06/22 11:02:55
回答待ちage
543:sage
06/06/22 14:26:24
sage
544:sage
06/06/22 15:27:35
sage
545:仕様書無しさん
06/06/22 19:58:11
>>542
別に普通にできるじゃん。
そんなのもわからないならはやく死ねよ。
546:仕様書無しさん
06/06/22 21:12:07
>>542
あーお前さんの言う
「オブジェクト指向プログラミング」
ってのが何を想定してるのかがわからんのだが
データとメソッドの融合は無理すりゃCでもできるけどメリットない
けど「オブジェクト指向設計」は十分Cでもメリットある
無論「オブジェクト指向言語」を使ったほうが
設計と実装の乖離が少ない分メリットは大きいが
547:仕様書無しさん
06/06/22 23:21:18
URLﾘﾝｸ(www.sage-p.com)
548:仕様書無しさん
06/06/22 23:50:54
>>542
こんな感じで構造体の中身を外部から隠して抽象データ型を表現するのは、
オブジェクト指向が流行る前からあったテクニックだよ。
ヘッダファイル(list.h)
typedef struct list *LIST;
LIST list_make(初期化パラメータ);
int list_free(LIST);
char *list_title(LIST);
int list_add(LIST, x);
int list_delete(LIST, x);
本体ファイル(list.c)
struct list
{
char *title;
…;
};
char *list_title (LIST l) { return l->title; }
int list_add (LIST l) { … }
int list_delete (LIST l) { … }
549:537
06/06/23 10:16:44
よくわからんが
>>538
みたいな感じで書けばいいの?
550:仕様書無しさん
06/06/23 14:17:00
>>549
Cでオブジェクト指向風のコードを書くなら、Cの構造体はC++のように必要なメンバ変数だけ
隠したり公開したり出来ないんで、パフォーマンス的にシビアな場面でない限り、>>539の前者のように
実装は完全に隠して関数を通してだけアクセス出来るようにしたほうが安全で変更に強い。
551:仕様書無しさん
06/06/23 14:48:53
>>550
C++ でいう viratual を実装するのに 関数へのﾎﾟｲﾝﾀをﾒﾝﾊﾞに持たせたことはあるが…
直接呼出しの obj_ptr->func() よりも、
関数呼び出しｽﾀｲﾙの func(obj_ptr) で記述するほうが、間違えﾄﾗｯﾌﾟしやすいしね。
設計&整理の手法を真似て、記述法は真似ない というあたりが落とし所かな？ と思った
# 単継承限定でも C++ to C ｺﾝﾊﾟｲﾗ があれば良かったんだけどね…
552:仕様書無しさん
06/06/28 06:09:46
age
553:仕様書無しさん
06/06/28 21:09:10
>>551
ポインタの保持はグローバル変数やgotoと並ぶ大罪だぞ。
javaはこれを無くすためにごちゃごちゃやってあるが、
逆にインスタンスがよくわからなくなって失敗してるがｗ
554:仕様書無しさん
06/06/29 06:45:53
>>553
ﾊｧ?
555:仕様書無しさん
06/06/29 06:56:49
>>553
ゲームだとDirectXでD3DDeviceを各クラスで保存しちゃって
Alt+Tabでロストしたとき、どうしようもなくなっちゃうお馬鹿なプログラムがよくある。
556:仕様書無しさん
06/06/29 11:06:16
ヒープ(?)を指すポインタとstaticな関数ポインタを
ごっちゃにしてしまうような人が来るのは、
やはり無闇にageた所為でしょうか?
557:仕様書無しさん
06/06/30 03:11:45
>>556
すいません。>>553の「ポインタの保持」だけに脊髄反射しました。
558:仕様書無しさん
06/08/18 00:54:46
ネットで「オセロをオブジェクト指向で考える」と言うのをよく見かけます。
盤面オブジェクトってのが出てきて、石の状態は盤面オブジェクトが管理
していたりします。
プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです。
不自然じゃないですか？
現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います。
このギャップは何なのでしょうか。
このギャップがオブジェクト指向の理解を妨げているのではないでしょうか。
559:仕様書無しさん
06/08/18 01:33:28
世界の切る際に、切ることに何を求めるか。
大抵は ある程度の規模・期間で作るときのコスト低減を狙うと思うので
それを実現するために（多様な）プレイヤ実装を念頭において
盤面オブジェクトに 現実にはプレイヤにある機能を移すんじゃないかなと。
560:仕様書無しさん
06/08/18 07:18:59
>>558
それは動作じゃね？
まず、設計時点ならそれぞれの情報を
各オブジェクトが内包している状態さえクラスで表現できればいい。
例えば盤に並んでるオセロの石が表か裏か配置されているかどうか
配置されてるならどこに配置されてるかってのを表現できればいい。
>プレイヤーオブジェクトの役割といえば、次の一手を考えるだけです
>現実世界では、石の管理もルール解釈も次の一手もプレイヤーが行います
これはセンスだな。
オブジェクト指向ってのはあくまでできるだけオブジェクト単位で処理するってことしかいってない。>>525参照。
つまりクラスにわけた時点でオブジェクト指向は終わっている。
別にわかり易くなるならプレイヤーと審判、オセロの石管理者みたいなのを用意してもいい。
561:増殖するオブジェクト
06/09/02 13:39:26
オブジェクト指向とは何か？
宗教です。
562:増殖するオブジェクト
06/09/02 13:42:51
これからは自律オブジェクト指向の時代だよ？
オブジェクトは意思を持ってます。
オブジェクトは自らのバイナリイメージを書き換えて成長します。
でも、環境の変化に弱く、環境(CPU)が変わると息絶ることがあります。
563:増殖するオブジェクト
06/09/02 13:45:48
自律オブジェクトは生みの親の顔を覚えています。
親の電子証明書を期限切れにすると成長が止まります。
ウィルスではありません。
自律品種改良です。
564:仕様書無しさん
06/09/02 16:12:06
全く無知の俺が
２ヶ月でC++をマスターする。
その為に独習C++と言う本を買って来たぜｗ
さぁて早速始めてみるか…
つかCは飛ばしたけどこの本の内容…理解出来るかな…
565:仕様書無しさん
06/09/02 16:33:53
>>564
出来るよ。マスター出来ないとは思うけど。
一通り読み終わるには２ヶ月で十分な時間だよ。
で、それから、いろいろ作るうちに少しずつ理解できるからがんばれ～って俺は思う。
566:仕様書無しさん
06/09/02 17:37:39
>>564
なんで憂鬱本買ってこなかったんだ。
URLﾘﾝｸ(www.amazon.co.jp)
人気書籍ぐらい調べてから勉強はじめろよ。
567:仕様書無しさん
06/09/02 17:52:22
憂鬱本はC++をマスターするための本じゃないし。
568:仕様書無しさん
06/09/02 17:56:41
>>567
色んな本を読むべきだと思うよ。
色んな本を読むのはいいことだ。
物事を色んな視点から見る目を養ってくれる。
１つの本だけを集中的に読んでもそれは１人の人間だけの考えを深く知るに過ぎない。
569:仕様書無しさん
06/09/02 18:41:26
>>565
この本Cを読者が知ってる者とします…
って書いてあったが大丈夫かな…
まぁ頑張ります
>>566-567
オブジェクト指向がなんたらって奴はこの本読み終わったらやろうと思う
>>568
㌧
色んな本を読んでみるよ
頑張ります！
570:仕様書無しさん
06/09/02 18:48:30
>>569
本の読み方が下手糞。
はじめに２～３冊買って見比べながら読むのが効率のいい読み方。
571:仕様書無しさん
06/09/30 02:27:51
>>565
君の書き込みを読んで俺は、ふーんと思った。
572:仕様書無しさん
06/09/30 17:35:49
「脱オブジェクト指向のススメ」
URLﾘﾝｸ(blogs.itmedia.co.jp)
573:仕様書無しさん
06/10/01 00:14:34
>>572
玉木 栄三郎 （ たまき えいざぶろう ）
イーキャッシュ株式会社代表取締役。
創業に技術担当非常勤取締役として参加するもその後経営不振により、製品開発、営業を担当するようになり、気が付けば代表取締役に。
業績のV字回復を達成するも、株主と社員に挟まれる中間管理職として日々苦悩している。
略歴など
1972年。香川県生まれ。
麻布大学獣医学部獣医学科卒（獣医師免許取得）
東京医科歯科大学医学部大学院博士課程修了（学位取得セズ）
動物病院勤務医、フリーランスエンジニア、大手メーカーなどを経て現職。
2006年1月より、Microsoft Regional Director に就任。
574:仕様書無しさん
06/10/07 02:04:25
最近参画したプロジェクトでは、
データを保持するクラスのメソッドはgetterとsetterのみが許されていて
値をいじるのは制御側という構造になってて
ちょっと萎えた
575:仕様書無しさん
06/10/12 20:34:26
VBでボタンクリックしたらクリックイベントが実行されるだろ
それがイベントドリブンだ
576:仕様書無しさん
06/10/16 02:25:30
腹をくだすと下痢になるだろう。
それがトイレットゲリベンだ。
577:仕様書無しさん
06/10/16 02:45:31
びみょ
おもろない
578:仕様書無しさん
06/10/27 22:16:21
>>572
その内容は、なんちゃってオブジェクト指向マスターに対する皮肉だと思われ。
579:仕様書無しさん
06/11/02 10:52:09
きのうオブジェクト指向が理解できた
半年かかった
580:仕様書無しさん
06/11/02 11:50:45
>>1
感謝するぜ。
大昔にＣ言語をちょとかじって構造化やカプセル化といったことは
概念的に理解した後、しばらくＶＢ漬けになってんで
いわゆるオブジェクト指向の考え方がとんとわからない
浦島太郎状態だったんだけど
なんとなく色々理解できてきたよ。
なんていうか新しい概念とかそういう捉え方ではなく
何々の発展形って表現してもらえると非常に自分には
わかりやすい！
とにかくありがとさん！！！
581:仕様書無しさん
06/11/07 14:23:38
>>528
>>530
参考になりました。
オブジェクト指向プログラミングに関する理解、知識が深まりました。
582:仕様書無しさん
06/11/12 11:05:47
オブジェクト指向で重要なんは、
Ｃだろうが、Ｃ＋＋だろうが、Ｃ＃だろうが、
ＶＢ（ここじゃ.netに限定）だろうが、
１ソースファイルには機能に限定したもんしか、
書かんことが重要や
その意味ではクラスを定義できる言語は
綺麗なソースになりやすいんや
Ｃはグローバル変数をexternするなんてことすると
読みにくてかなわん
583:仕様書無しさん
06/11/12 11:28:09
そんなアセンブラの時代から当然の、オブジェクト指向と何の関係もない話を
何を得意げにいってるんだろうな。
いや、というかexternが問題だという奴初めてみたよ。w
それが問題なら最初からファイルスコープっていう概念がないC#とかVBは
もっと問題じゃん。
584:仕様書無しさん
06/11/12 12:05:50
>>583
お前も得意気だな
585:仕様書無しさん
06/12/09 13:27:34
素人が作ったソースのカプセル化、隠蔽にメリット無し。
586:仕様書無しさん
06/12/16 20:30:01
それやってるうちに学んでいって上達していくんだから、
メリットなしというのは本末転倒。
587:仕様書無しさん
07/01/01 00:10:40
同意
588:仕様書無しさん
07/01/01 13:24:07
間違いに気付かずにそれを覚えられたら大変だな。
メリットなしというより、大きな賭けなのでは？
589:仕様書無しさん
07/01/02 01:23:09
どんな奴でも多かれ少なかれ間違って覚えてることはあるよ。
経験を積むうちに勝手に修正されていくから無問題
590:仕様書無しさん
07/01/04 19:55:17
OOに固有の話題ではないな
591:仕様書無しさん
07/01/27 22:35:57
クラス図を描ける便利なフリーウェアってあれば
教えてください。
592:仕様書無しさん
07/01/29 11:21:15
新Visual C++6.0入門 シニア編 林晴比古/著
新C言語入門 ビギナー編 林晴比古/著
を新入社員に薦めている会社ってありますか？
593:仕様書無しさん
07/01/29 11:40:55
>新Visual C++6.0入門 シニア編
新C言語入門 シニア編
です。
594:仕様書無しさん
07/01/29 12:11:07
>>593
うちの会社では「新Visual C++ .NET入門シニア編」を使ってます。
595:仕様書無しさん
07/01/29 18:24:13
何人かの知人に聞いたところ、
私のところもそうですが、林晴比古シリーズ使っている人が
多かったです。（なんで？そんなに良書なの？）
596:仕様書無しさん
07/01/29 20:06:46
ウチはハルヒ子禁止。
597:仕様書無しさん
07/01/30 18:54:39
>>596
何故？禁止にするのか！
598:仕様書無しさん
07/01/31 06:55:21
>>595
次のステップにいけない本だけどなｗ（書いてる本人が一番わかってるだろうけど）
とりあえず、使うだけだけどＭＦＣはそれじゃ組めない。
ちょっとだけ遠回りになるけどＷｉｎ３２ＡＰＩでのプログラムを理解しないとすぐにドツボにハマル。
本当にＶＣ＋＋が組めるようになりたいなら
「猫でもわかるWindowsプログラミング」がいいと思う。
何度も何度も理解できるまで繰り返し読むといいと思う。
599:仕様書無しさん
07/02/05 10:45:41
>>598
猫から出発した俺はいまだに MFC 使えない…
Doc View 構造を強要されるのが好かんな。
600:仕様書無しさん
07/02/12 15:37:49
割り込んで申し訳ないんですけど
オブジェクト指向用の宿題スレとかありますか？
ここで聞くとおそらく場違いだと思うので。
601:仕様書無しさん
07/02/12 16:51:46
プログラム板に行きなさい
602:仕様書無しさん
07/02/12 17:26:17
それがプログラム問題じゃなくて、
オブジェクト図を描けとか、国クラスと都市クラスの関係を表すクラス図を作れ。
とかそういうのばかりなんですよ。
それでもプログラム板になるんでしょうか？
603:仕様書無しさん
07/02/12 23:05:03
ム板でいいと思うけど、ム板のくだ質で追い出されたら情シス板にでも行ってみたら
604:仕様書無しさん
07/02/12 23:11:28
どうでもいいけど自力でやれよ
605:仕様書無しさん
07/02/12 23:25:30
>>603-604
ちょっと調べてみます、そちらの方を
自力でやってわからないところだから聞こうと思って
606:仕様書無しさん
07/02/12 23:27:39
宿題出した教師に聞け
607:仕様書無しさん
07/02/13 12:50:40
>>603
>情シス板にでも行ってみたら
就職相談板で何を訊けと。
608:仕様書無しさん
07/03/15 12:34:58
ｸｿみたいな憂鬱本にはﾏﾝｾｰしまくって
自分の気に入らない著作/blogへのﾈｯﾄ攻撃を推奨しちゃうｱｲﾂ、
いい加減なんとかならんのかなぁー
たかひろ、お前のことだよ
609:仕様書無しさん
07/03/24 11:57:40
シュミレーションで考えよう！
インスタントは実体であり、オブジェクトは概念だ。
デザインパターンでセンスを磨け。
610:仕様書無しさん
07/03/26 11:27:25
(´-`).｡oO（インスタント？）
611:仕様書無しさん
07/03/26 18:24:56
>610
ちゃんとシミュレーションにもツッコミ入れてよ；；
612:仕様書無しさん
07/03/26 23:22:33
やだぷー
613:仕様書無しさん
07/03/28 22:41:49
インスタントで考えよう！
3分で完成するという概念がオブジェクトだ。
しかし、3分も待たずに食べ始める、これが実態だ。
614:仕様書無しさん
07/03/28 22:47:27
さーて、おさんも逝った事だし、
これから暴れるでぇ～
615:仕様書無しさん
07/03/29 01:40:56
オブジェクト指向って言葉が悪い。
意味ワカンネーよ。
616:仕様書無しさん
07/03/29 23:13:04
オブジェクト指向はフォースだ。
617:sage
07/05/08 13:03:10
さっき雑誌見てたらアスペクト指向っていう言葉が載ってたんだけど、オブジェクト指向とどう違うわけ？
618:仕様書無しさん
07/05/08 16:12:42
ぐぐれ
619:仕様書無しさん
07/05/11 21:30:35
インスタントンだろ？トフーフトの
620:仕様書無しさん
07/05/12 14:32:35
オブジェクト指向をドラえもんや哺乳類を使って
説明されるのはあまり人気がないみたいだけど
昔ドラクエを使って説明してもらったら
俺でもわかったよ。
621:仕様書無しさん
07/05/13 21:55:12
884 ：仕様書無しさん：2007/05/11(金) 01:43:28
役者の演技による映画やドラマ作り＝オブジェクト指向開発
セルやクレイによるアニメ作り＝構造化開発
622:仕様書無しさん
07/05/15 09:23:33
>>621 下手に例えると迷宮入りの例。
623:仕様書無しさん
07/05/15 13:49:17
さぁみんな無知な俺に教えてくれ
そもそもオブジェクトって何なんだ？ｗｗｗｗｗ
学校の課題で出たんだがまったく持って説明の仕方がわからんｗｗｗｗｗ
624:仕様書無しさん
07/05/15 14:55:12
何の前提もなく「オブジェクトとは何か」という問いに答えるのは
何の前提もなく「権利とは何か」という問いに答えるようなもんだ。
課題出した阿呆つれて来い。説教してやるから。
625:仕様書無しさん
07/05/16 14:55:28
オブジェクトとは
自分とその外を区別できる（アイデンティティを持つ）
働きかけに反応することができる（メソッド）
内部情報を持つ（インスタンス変数）
626:仕様書無しさん
07/05/16 15:02:38
JIS X 3010:2003 (ISO/IEC 9899:1999) より抜粋
| 3.14 オブジェクト (object) その内容によって，値を表現することができる実行環境中の記憶域の部分。
| 参考 オブジェクトを参照する場合，オブジェクトは，特定の型をもっていると解釈してもよい
| (6.3.2.1 参照)。
627:仕様書無しさん
07/05/16 22:42:19
オブジェクト指向というか、ユーザクラスとかマネージャクラスとかは簡単にわかる。
継承を使ったコンテナ設計やGOFデザインパターンなんかも易しい。
でも、未だに関連クラスの抽出ができない。属性を持たせたクラスの実現方法が
わからない。（C#なんかだと言語仕様にあるよね。あれはアスペクト指向的で、いまいち
属性という認識が持てないけど。）
なんか、だんだん鬱になる。自分頭わるいのな。
628:仕様書無しさん
07/05/17 09:13:20
>>627 プロｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!
ユーザクラスって何？
あと、GOFのAbstract Factoryパターンがいつまでたっても（笑）
わからないのですが、あれって簡単に言うとどんなもんですか？
たとえばFactory Methodパターンだと、
「インスタンス化をサブクラスに任せる」ってので十分に分かる。
629:627
07/05/17 20:31:24
>>628
AクラスとBクラスがあって、AクラスにもBクラスにも非常に便利な関数があったとする。
>>628がAクラスの関数とBクラスの関数を、新しく作ったCクラスで呼びたい場合に使う。
AクラスもBクラスもインスタンスとしても無害か、あるいは静的な関係である必要がある。
Abstract Factoryを継承してCクラスを作る設計として、A、B共にインスタンスとして存在
しても問題がないならOK。
実際には、散らばりだした関数を無理やりまとめたりする時につかうパターン・・・、てか
普通に考えればこのパターンになる。まさに有名パターン。
自分はAbstract Factoryクラスを導出しないで多重継承してしまう派。
630:仕様書無しさん
07/05/17 21:36:43
AbstractFactoryはDIで代替できる
631:628
07/05/18 10:08:19
>>629 完全に間違っているのでは？
（いえ、俺が間違ってる可能性が高いですが（笑））
GoFのAbstract Factoryパターンってのはまず、
「互いに関連したり依存し合うオブジェクト群を、
その具象クラスを明確にせずに生成するための
インタフェースを提供する」とあります。
少なくとも「オブジェクト群」を（特に「群」に注目？）
「生成するためのインタフェース」が本質になっている予感。
などと言いつつ、ピンと来てない俺ですが。
ん？いや？「部品を生成する抽象Factoryクラス」てことか？
632:627
07/05/19 12:04:30
>>631
ん…間違ってなくね？
・「オブジェクト群」がインスタンスとは限らない
・Factoryはインスタンスを生成する責務は無い
という点でそういう点で、>>631と考えは違うんだけど。
前提も自分とは考えが違っていて、「互いに関連したり依存しあう」って部分は、個人的に
有っても無くても良い。互いに依存度があるなら、Factoryクラスの使い道が限定されて
「環境まとめクラス」みたいになっちゃう。ある意味AbstractFactoryの使い方かも知れないけど。
（※その場合はほぼ必然的にFactoryMethodも使うことになるよね？）
なので、あえてhaveの関係じゃなくてisの関係で書いてみたんだ。
少なくとも、散らばってしまった関数やクラスは「まとめれる」でしょ。
633:仕様書無しさん
07/05/19 12:25:06
>632
Factoryはインスタンスを生成する責務あります
631の通り
634:仕様書無しさん
07/05/19 12:26:21
>>632
おまいが間違ってる
635:627
07/05/19 12:30:08
>>633
あれ？よくインスタンスをFactoryに渡してたりしたんだけどなぁ。
別にFactoryは部品は組み立てても、部品そのものは具象化しなくても良いと思ってたが・・・。
636:627
07/05/19 12:57:33
>>634
理解間違っていたのかなぁ・・・。結城本でも買ってくる(´・ω・`)
FactoryのFactoryMethod化は必要ないと思っているし、使う側が
Factoryから返すオブジェクトをどう使うかだけの問題だと思ってたんけど。
良く、まとまって使わなきゃいけないクラスをFactoryに持たせて（実際にはFactoryを
継承した自分自身に持たせて）、自分自身をどっかのプロダクトに投げる使い方をするんよ。
これがAbstractFactoryのイメージでいたんだけどなぁ・・・。
というわけで間違っていたらすまん>>632
637:仕様書無しさん
07/05/19 15:11:45
>627が考えてるFactoryってなんだよｗ
638:628
07/05/19 18:04:17
> 少なくとも、散らばってしまった関数やクラスは「まとめれる」でしょ。
散らばった（？）ものをオブジェクトコンポジションだとか、
あるいは継承を使ってだとかでまとめ（？）たりするのは、
何と言いますかデザインパターンどうのこうのではなくて、
OOPにおけるフツーのこと、空気のようなものかもしれません。
> 理解間違っていたのかなぁ・・・。結城本でも買ってくる(´・ω・`)
結城本って、Java言語で学ぶデザインパターン入門ですか？
あの本は3800yenもする割に（個人的には）分かりにくかった気がします。
4800yenでオリジナル（を翻訳したやつ）が買えるのでそっちがオススメです。
難しくてとっつきにくいですが、詳細に、厳密に、漏れなく解説してくれてる感じです。
639:仕様書無しさん
07/05/19 20:14:29
>>638
> 何と言いますかデザインパターンどうのこうのではなくて、
> OOPにおけるフツーのこと、空気のようなものかもしれません。
デザインパターンというものも結局は空気みたいなものだよ。
一定の知能さえあれば誰でも思いつく。
変に神聖視して自分で壁を作らないほうがいいと思うが。
640:仕様書無しさん
07/05/19 21:02:27
コテ外しますね。
「本書で示すデザインパターンの中には、新しいものや有用性が未確認である
ものは１つもない。だが、そのほとんどは今まで文書化されていないものだ。
オブジェクト指向コミュニティにおいてよく知られているもの、うまくいった
オブジェクト指向システムの要素となっているものである。いずれも初心者が
容易に得られるものではない。したがって本書中のデザインパターンは新しい
ものではないが、我々はこれらのデザインパターンを、一貫した形式を持つカ
タログとして利用しやすいような形にまとめてみた。」
(「デザインパターン」より引用。)
このように、思いつく思いつかないではなくて、カタログ化、
それこどがメリットなんでしょう。カッチリしてるからこそ、
議論や設計の足がかりになるという。空気とは違って。
神聖視、といいますか、壁を低くして（？）といいますか、例えば、
「俺流Abstract Factoryパターン」だとか、
「たぶんAbstract Factoryパターン」とか、
「Abstract Factoryパターンの亜流」とか、
「何でもAbstract Factoryパターンだ発言」とかは排除したいですよね。
そうならないためのカタログ化、デザインパターンではないでしょうか。
641:仕様書無しさん
07/05/19 21:10:07
やはりこんな統一性のねーもんまったく役に立たんなｗ
個々のパターン見て信者同士でさえ意見が統一されてないのに
こんなもんが普及するわけがないｗ
開発だってうまくいくのか怪しいもんだなｗ
しかも、こんなローテク全然大局的じゃないけど役に立つのか？
使っても使わんでも変わらん結果になりそーｗ
ま、オブジェクト指向じゃないしねｗ
642:仕様書無しさん
07/05/19 22:51:49
ま、オブジェクト指向じゃない香具師しねｗ
643:636
07/05/20 00:23:23
友達と呑んでる間もAbstractFactoryが気になって、会話に集中できなかったじゃないか。
んで最後のコテ。
自分のFactoryの考えは、ただのインタフェースなんだわ。Factory側を抽象クラスに
するんではなくて、使う側のインスタンスで切り分ける方法が好みなので
AbstractFactoryもFactoryは一個のインタフェースとして作る事が多い。
理由は、クラス多くなるのメンドクセ。
結局デザパタ本は買わず、英語wikiの方でクラス図だけ見た。うむ・・・やっぱ大きく
間違ってなさそう。でもクラス構成は全然違った。FactoryがProductに具象クラスを
セットで渡せるメリットって何だろう・・・。自分自身投げた方がやっぱ作りやすいな。
カタログ化、ていう考えには全面的賛成。そうでもないと言葉通じないし。
そういう意味で、自分のやりかたは純粋なAbstractFactoryではなさそう。
最後になるけど、オブジェクト指向じゃない香具師し(ry
644:仕様書無しさん
07/05/20 00:48:21
デザパタなんてのはいらんと思うけどな
プログラムなんて所詮組めるようになっちまえばそれでお仕舞いじゃん
仕様がわかればもう実装できる
プログラミング的にこれ以上のレベルって必要あんの？
正直、後は設計やらなにやらより対象分野の仕様をどんだけ理解するか？
って話になっていくだけでこんなの必要ないと思うんだけど？
で、対象仕様をまんまプログラムのクラスに反映できればそれでもういいよな
なんでクラスの設計にこんな技巧をこらそうとするのか謎でしょうがない＞デザパタ
だいたいこんなプログラムの設計・実装なんぞに時間かけたって
他の仕様決定・評価期間がアフォみたいに長いんだから実装期間を２分の１にしたって
プロジェクトにはなんの利益もねーんだよｗバーカｗ
学者さんは一生机の上で図でも表でも好きなの描いててくださいｗ
645:仕様書無しさん
07/05/20 01:00:06
別にデザパタ使わないで上手くいっているんなら問題なくね？
>>644がここに来る理由こそ分からない。
でも、実装期間が２分の１になるんだったら・・・
『とても魅力的だと思わない？』
思わない？あぁ、頑張って稼いで下さいね。
646:仕様書無しさん
07/05/20 01:19:05
>>644
＞他の仕様決定・評価期間がアフォみたいに長いんだから実装期間を２分の１にしたって
＞プロジェクトにはなんの利益もねーんだよｗ
残業代が稼げると言う事なら同意。
いままではどうやって作るかに重点が置かれていたけど、
デザパタやOOPって、PGを作った人以外が理解しやすい様に作るという領域に入ってると思う。
647:仕様書無しさん
07/05/20 01:30:30
>>645
たしかに魅力はないな
開発はそんなに重要なファクターではないし
以前ほど汎用性だの開発速度だの問題にならなくなった
ていうか少なくとも設計でなんとかしようって動きはまったくなくなったな
プログラムの見積もり期間なんて決まらんと思ってたが
色々積みあがってくるとそういうのも相場が決まってくるもんなんだな
すげーきついって職場もかなり減ったように見えるっていうか派遣社員がいつかないんだろうなｗ
で外部から「いやー、お宅の環境厳しすぎなんすよｗみんなお宅は残業多すぎて嫌だって辞めちゃうでしょ？ハハハｗ」
なんていわれてきつい職場にはわざわざ人が集まらなくなったんだろうなｗ
648:仕様書無しさん
07/05/20 01:38:05
続き(>>647)
そのせいもあってこんなの考えなくてもフツーに作ってフツーに開発してりゃ
わざわざ頭使わんでもフツーに開発が終わるようになってきたって背景もあるんだろうな
カタログ化して単調作業にしたかった奴もいたんだろうけど
中国もインドもわざわざ日本にきてもしょうがないぐらい経済押せ押せムードだから
植民地政策もやっぱり失敗なんだろうｗ多分ｗなんでカタログ化も単調作業化もそう望まれてることじゃないとｗ
もちろん、できるかどうかは別にしてねｗ
ということもあってか、学者諸君のプログラマー単調作業化計画は時代のタイミングもあってか失敗したように見えるね
バブルの頃にやった工場のラインとかは強引に単調作業にしたみたいだけど
プログラムは形のないものだからねぇ
俺等プログラマの中にもプログラムは組めなくても口先から産まれてきたような奴もいてか
なかなかライン化は進まなかったんだろうね。
工場の職人気質の人みたいにおとなしくしてるわけじゃないしねｗま、いいんだか悪いんだかｗ
ま、結果として、プログラマの単価は高いまま維持できてるのはいいことだ。
しばらく余計なことすんなよお前等。っていっても誰も必要としてないかｗ
649:仕様書無しさん
07/05/20 13:09:38
まあなんていうか、「それ」が意味するところや意義を理解してもいない人間が
「それ」を否定するのは滑稽でしかないなw
デザパタというのは、あえて単純化すればコミュニケーションツールなのであって
テクノロジーではないのだが、そんなことも分かってないんだね。
昔偉い学者さんが、ソフトウェアの開発では人月の概念は成立しないといった。
必要なコミュニケーションの量が投入する人数に対して幾何級数的に増えてしまうからと。
デザパタっていうのはそのことに対する処方箋の一つなんだけどな。
650:仕様書無しさん
07/05/20 17:51:55
そりゃ全員がデザパタに精通していれば
効果があることに同意するけど。
そうなるための処方箋はあるのかい？
651:仕様書無しさん
07/05/20 18:06:18
結局さあ、デザパタとかそんなんは全部「基本」なんだよな。
逆にいえば、基本が理解できてない・実践できないレベルの奴らは
「仕事そのもの」ができてないわけ。気づいてないかも知れないけど。
たとえば「手続きの中では直接具象を扱わない」とかそういう基本な。
それが何の役に立つんだ？とかおこがましいと思えよ。まずは。
652:仕様書無しさん
07/05/20 19:37:52
デザパタが基本？あの本が何部売れたと思っている？
プログラマの総人口を知っていて言っているのか？
653:仕様書無しさん
07/05/20 19:56:31
プログラマの総人口なんて関係ないだろ
基本が出来ているプログラマは、平均的なプログラマより
かなり数が少ないと考えればよい
654:仕様書無しさん
07/05/20 20:14:49
>>653
逆転の発想ﾜﾛｽｗ
655:仕様書無しさん
07/05/20 22:50:20
デザインパターンは基本じゃないと思われる。
純粋にOO分析設計をつめていくと似たようなパターンってのが多々出てくるわけよ。
それを後から開発をする人が同じような局面で悩まなくて済むようにカタログ化しただけのもの。
正直この世界のPGって糞レベルばっかりだからそいつらにOOを理解しろって言うのはムリ。
OOを意識するのは設計する人と中心となるPGだけにするほうがいいよ。
656:仕様書無しさん
07/05/21 02:29:48
でも、デザインパターンを理解することと、設計で実践することは別もんだと思うぞ。
確かに、積極的に実践するのは設計者と中心のＰＧだけでいいかもしれんけど、
その他大勢にも「理解」だけはしてもらわないと・・・結局パターンを外れた
まずいコ－ドが出来上がってしまう。「あ、こういうパターンでやってるのか」
「じゃあ俺の部分もそれに従わないと」って感じで分かって欲しい。
期待しすぎなんだろか。
657:656
07/05/21 02:31:34
そういうのって、パターンの知識というより、コードの読解力があれば
出来ることだと思うんだけど。
658:仕様書無しさん
07/05/21 10:37:42
>>656
期待しすぎ。
具象から抽象を理解するのはその逆よりはるかに難しい。
貴方自身はそれが出来るのかな？
659:仕様書無しさん
07/05/21 12:41:40
>>658
おいおい本気かw
それこそ（普通に人間にとっては）逆だよ。
例えば、抽象度の順番は
感情 ＞ 愛 ＞ 俺の「この」気持ち
になるが、普通人はより抽象度の低いもの、つまり右の方から順に左に向かって
学習していくもんだ。
660:仕様書無しさん
07/05/21 13:15:04
脳内 ＞ ２次元 ＞ ３次元 ＞ 現実
661:658
07/05/21 14:16:20
>>659
ふーん。そうかぁ。本気なんだけどね。
自分は自分を基準に他者も同様だと考える錯誤をした？
抽象的なほうがわかりやすい自分は少数派なのかなぁ
もしかして・・・貴方は文科系？
662:仕様書無しさん
07/05/21 14:40:05
【オブジェクト指向】言語学習が先？概念学習が先？
ｽﾚﾘﾝｸ(tech板)l50
663:仕様書無しさん
07/06/02 11:07:26
表面上、ポインタを使わないサブルーチン間インターフェイスが上手に出来る仕組みが
クラスとか。
サブルーチン、メインルーチンの使いまわしを言語仕様にした継承とか。
その辺まで理解した。
カプセル化はモジュール指向で取り入れられた手法だからオブジェクト指向だけの物じゃない。
664:仕様書無しさん
07/06/04 10:48:23
>>663
>その辺まで理解した。
ぇー
665:仕様書無しさん
07/06/05 20:55:28
>>663
OOを学習するときには、既成の観念は害になるのでいったん捨てろ。
あんたがポインタやサブルーチンを学んだときのように
クラスや継承は、何度も使ってみて本質を見極めた方がいい。
666:仕様書無しさん
07/06/05 21:52:46
C++周辺の言語の場合、継承元のメンバを再利用する為の継承するんじゃなくて、
継承して出来たオブジェクトを、継承元のオブジェクトを扱うメソッドで同様に扱うために
継承を行う
って事だけは理解した
他にコンポジションとか色々あるけど、
俺の場合どれもこれも方法論、手法としてしか覚えられないわ(本質なんてわからね)
やっぱオブジェクト指向ってどうやって理解すればいいんでしょうね
667:仕様書無しさん
07/06/06 02:17:32
>>665
ポインタはアセンブラのアドレッシングの延長から覚え、
サブルーチンはBASICで学んだｗ
結局、最終的にニモニックになったらどうなるんだろう？
と考えてしまい、概念的な事は後回しになってしまうんだ。
既成の概念は邪魔なんだろうけど、OOの機能が標準装備ではない言語
との利点などを比べながら、動きを覚える段階だと思ってる。
最終的にどう動くのか？
Cで同じような処理を作ったらどうなるのか？
を考えてる。
668:仕様書無しさん
07/06/06 03:27:40
OOPLを覚えるのは非OOPLの経験が無い人のほうが早い
との話を思い出させる話であるな
669:仕様書無しさん
07/06/06 22:37:46
>>666
本質の何割かは理解してるんじゃない？
多態性は使っていくうちに便利さが実感できる。
自分が継承を使うときは親クラスのメソッドで
抽象メソッドを呼び出すとかはよく使うかな
670:仕様書無しさん
07/06/06 23:19:00
>>666
どうやって理解すれば、ってことは現時点でOOを理解してないってことだろうけど、
その理解っていうのはどの水準の話なの？
わざわざクラス使うメリットが分からない、ってレベルなのか、
もうちょっと高次元の設計とかデザインパターンの意義がわからないってレベルなのか。
671:仕様書無しさん
07/06/07 00:55:20
オブジェクト指向ってのがいろんな物、事を指すように思える。
デザパタを理解する事がOOPLを理解した事になるの？
よくわからんがしばらくはデザパタなんか勉強しない。
672:仕様書無しさん
07/06/07 01:00:19
＞デザパタを理解する事がOOPLを理解した事になるの？
ならんが、学習の一助になる。それだけだ。
673:仕様書無しさん
07/06/07 01:22:50
一助にもならないよ
674:仕様書無しさん
07/06/07 09:02:13
個人的にはデザパタとOOPLが一緒になってはじめて、
OOPの嬉しさが実感できたことを白状しておこう。
それまでは馬鹿みたいに「CでもOOPできる」とか、
「非OOPLでもOOPできる」とか気軽に口走って喜んでたｗ
OOPの嬉しさも、OOPLのあり難さも良くわかってなかったｗ
675:仕様書無しさん
07/06/28 10:42:40
オブジェクトが自身のクローンを作るメソッドって、
「クローナー」っていうの？
676:仕様書無しさん
07/06/28 12:58:42
clone で良いんじゃね？
677:仕様書無しさん
07/06/28 14:37:51
>675
Rubyではdupとcloneの２つが標準でObjectのメソッドだな。
通常使う分にはあんま変わらん程度だが、確か微妙に挙動が違う。
678:仕様書無しさん
07/08/26 11:49:02
やはりどちらもシャローコピーである点では同じなんだ。
679:仕様書無しさん
07/08/30 17:37:37
オブジェクト指向の諸原則(LSPとかOCPとか)も知らねぇような奴らがオブジェクト指向について語ってるのが一番の問題だと思う
俺は、オブジェクト指向の諸原則とデザインパターンの関係が理解できて初めてオブジェクト指向の基礎がわかったいえると思うんだか
680:679
07/08/30 17:51:27
とりあえず、オブジェクト指向とかデザインパターンとかがイマイチ分からないという奴には、
「デザインパターンとともに学ぶオブジェクト指向のこころ」
をお勧めしておく
681:仕様書無しさん
07/08/30 19:02:40
今度はね、デザパタを理解できずにデザパタを叩くやつが出るんだよ。
682:仕様書無しさん
07/08/31 12:49:46
OOとデザインパターンに何の関係が？
683:仕様書無しさん
07/08/31 14:48:31
略語から正式名称が逆引きできない俺がいる。
リスコフの置換原則とオープン・クローズド原則か……
684:679=680
07/08/31 20:06:09
デザインパターン→デザパタで。
この二つで意味が変わるなんて変だとは思うが。
685:仕様書無しさん
07/09/01 10:50:28
>>684
変わらん。
GoFの事なら「GoFの」と前置しとけ。
686:684
07/09/01 16:11:14
>685
すまんかった。
どうも会話中で広義のデザインパターンと狭義のデザインパターンがごっちゃになってて、
広義：デザインパターン
狭義：デザパタ
と勘違いしてしまった。
687:仕様書無しさん
07/09/03 11:53:48
「コンストラクタはオブジェクトを生成するものである」ってたまに見かけるけど間違いだよね？
688:仕様書無しさん
07/09/03 14:09:27
>>687
new Aなり、A.newなりで、オブジェクトが生成される時、
その初期化のために呼ばれるのがコンストラクタじゃね？
689:仕様書無しさん
07/09/03 17:39:10
>>687 に便乗質問
コンストラクタを使わないでオブジェクト生成ってできるの？
690:仕様書無しさん
07/09/04 10:29:15
JavaScriptのアレってコンストラクタと呼ぶのかな
691:仕様書無しさん
07/09/05 21:25:05
>>689
>>688で答えが出てますよ。
コンストラクタはインスタンスの生成を行うのではなくて生成時に行いたい処理を記述する場所です。
一般にコンストラクタには戻り値の指定が無い事からも分かりますよね？
692:仕様書無しさん
07/09/07 20:57:33
>>691
で、実際にコンストラクタの呼び出しを行わないでオブジェクトの生成ってどうやるの？
693:仕様書無しさん
07/09/07 21:32:06
サイズ計ってallocじゃだめ？
694:仕様書無しさん
07/09/08 02:04:11
>>692
デシリアライズとか
Java限定だけど
695:仕様書無しさん
07/09/08 05:38:31
というか、何の必要があるのかわからん。
引数なしのスカのコンストラクタつくるんじゃあかんのん？
696:仕様書無しさん
07/09/08 13:39:49
ああああああもう！小さい！小さいよお前ら！
何でそう用語の定義とか細かい実装テクに話が行っちゃうわけ？
そんなんじゃインドどころか中国朝鮮にすら負けるっつ-の！！
697:698
07/09/08 14:13:34
すまん誤爆した。
698:仕様書無しさん
07/09/08 14:14:32
用語の定義や、細かい話題を軽視すると、
>>696のような人間になってしまうので注意。
699:仕様書無しさん
07/09/08 14:15:44
>698-697
これは誤爆でつか
700:仕様書無しさん
07/09/08 15:06:17
>>696
そうなんだよね
オブジェクト指向わからん奴って思考がすっげーミクロなんだよね
大まかに物事をとらえることができない
最近減ってきたけどなんか変なテンプレート挙げて
「これがオブジェクト指向です！」とかいいだす奴前はいたしねｗ
日本人だからなのかなんなのかわからんけど
公式でこうって表せるもんじゃないだけにこの辺の理解がすっげ困難らしいｗ
毎度毎度オブジェクト指向関連のスレみて初っ端の違和感は
レスをつける奴の思考の狭さ
ソースコードの一部分を指して「ここ！ここ！ここがオブジェクト指向です！」って
表せるもんじゃねぇってのｗ
まあ、楽しいからセイゼイあがけやｗって感じｗ
701:仕様書無しさん
07/09/08 15:37:11
まあ、純粋科学や学問の世界ではそういう理屈もあるかもしれんが、
工学の世界は動いて何ぼだからな。
実装系の挙動はミクロの世界の話かもしれんけど、
マクロの話だけしてても、絵に描いた餅だしぃ。
702:仕様書無しさん
07/09/08 15:48:06
>>701
それは概要がわかった上での話しだろ？
いままでそう概要部分（イメージ）で間違えるってことがなかったから
ミクロな部分を重視した勉強でよかっただけだろ
物事を理解するときに
「こんなイメージｗ」って部分を間違えてるとミクロな内容を
とりこんでも頓珍漢なことをやってしまう
それは大まかな概要がわかってないから
それがオブジェクト指向関連のスレ
なんかねｗわかってない奴がしつこく居座る傾向がある
逆にわかった奴は何故かしばらく寄り付かない傾向があるように思う
俺も昔は必死に説得を試みたけど、こればっかりはね・・・ｗ
703:仕様書無しさん
07/09/08 15:48:57
Ｘとりこんでも
○とりくんでも
704:仕様書無しさん
07/09/08 16:02:27
>>702
うそつけ
説得なんて見たこと無い
705:仕様書無しさん
07/09/08 16:22:45
>>702
>「こんなイメージｗ」って部分を間違えてるとミクロな内容を
>とりこんでも頓珍漢なことをやってしまう
それでも、（合理的なコストで）動けば工学的には正しいでしょう。
実装は実際に動作させて、現実的な利益を得るためにあるのであって、
マクロな観点というのはそれを理論化して再現可能にするために存在するに過ぎない。
つまり、「マクロな理論とこういう点で食い違っている」なんて説得では
納得する人は少ないんでないかい。
マクロな理論を実現することが目的じゃないんだから。
つまり、オブジェクト指向は手段であって目的ではないわけ。
706:仕様書無しさん
07/09/08 18:18:39
>>705
そうやって理解できないいいわけをごちゃごちゃ考えてるからいつまでたっても（ｒｙ
707:仕様書無しさん
07/09/08 18:45:54
>>706
というか、君のその「理解」とやらは、何の役に立つの？
708:仕様書無しさん
07/09/08 19:04:58
>>707
理解すればわかるよｗ
709:仕様書無しさん
07/09/08 19:15:26
俺はオブジェクト指向をわかっている厨ﾃﾞﾀ━━━(ﾟ∀ﾟ)━━━!!!!
( ´,_ゝ`)ﾌﾟッ
710:仕様書無しさん
07/09/08 19:18:41
>>708
説得を試みたとかいってるけど、
その程度のことを言うことを「説得」と思ってるなら、
誰も納得しないのは当たり前では？
711:仕様書無しさん
07/09/08 19:20:16
>>710
あー悪いね
「説得」はもうやってないんだ
712:仕様書無しさん
07/09/08 19:25:33
なんというか、簡単に逆ギレするのは、ゆとり教育の弊害なのか。
713:仕様書無しさん
07/09/08 19:28:12
>>711 逃げ( ´,_ゝ`)ﾌﾟッ
714:仕様書無しさん
07/09/08 19:30:43
>>713
いいぜ、別にｗ
俺、お前がオブジェクト指向理解できなくても全然困んねーもんｗ
715:仕様書無しさん
07/09/08 19:31:43
この程度のことでビビって逃げるようじゃだめだぞ。
716:仕様書無しさん
07/09/08 19:34:18
今日は煽りに来ただけだしなｗ
昔、みたスレどうなってるかなｗと
まあ、よく見たら昔みたスレはこっちじゃなかったんだけどなｗ
717:仕様書無しさん
07/10/05 13:53:52
privateの必要性がよう分からない
getter、setterでアクセスするなら同じだろ
718:仕様書無しさん
07/10/05 14:37:53
アクセッサを介すんだから、そこで色々できるでしょ。
int getValue() {
return hoge && huga && hage ? _value : -1;
}
だとか。
719:仕様書無しさん
07/10/05 15:43:12
>717
全部publicで書かれたコードを一度でも触れば、いかに糞かがわかる。
720:仕様書無しさん
07/10/05 22:14:59
>>717
破滅の序曲を聞いたｗ
過去何人がそれで死んだことかｗ
まあ、体験するしかないと思う
721:仕様書無しさん
07/10/05 22:28:21
class A
{
private:
int hoge;
public:
void SetHoge(int newHoge)
{
if ( newHoge < 0 )
{
hoge = 0;
} else if ( newHoge > 150 )
hoge = 150;
}
}
};
int main()
{
A a;
// a.hoge = 2000;
a.SetHoge(2000);
return 0;
}
722:仕様書無しさん
07/10/05 22:30:55
if ( newHoge < 0 )
{
hoge = 0;
} else if ( newHoge > 150 )
hoge = 150;
} else {
hoge = newHoge;
}
723:仕様書無しさん
07/10/06 10:00:39
>>717
構造体を先に作って、ほとんど全てのメンバに getter/setter を書くようなら、メリットは少ないかもね。
これは逆で、クラスとしてのインターフェースを先に書いてから、実装に必要なメンバを追加していく。
それで getter/setter ばかりになっても、それは結果。
724:仕様書無しさん
07/10/06 10:32:00
そうそう
この変数はこの関数を通してしかアクセスされませんよ
（する必要がありませんよ、した場合の動作は意図していませんよ・・・等）
って制限を与えることによってプログラムの構造を単純にするのが本当の役目なんだよな
メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない
クラスの仕様として外部からアクセスする必要がないことを明示的にするためのもんといった方がわかりやすいだろうか？
setだけのもんがあってもいいし、getだけのもんも当然ある
725:仕様書無しさん
07/10/06 13:13:13
> メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない
クラスを、データの入れ物と機能とに完全に分離したがる人は多いけど
だいたいこのパターンだな
726:仕様書無しさん
07/10/06 15:53:27
セッターなんて、いつ変更されても構わないものしか付けられないし
ゲッターでもオブジェクトとか配列の公開は、実質的に変更出来ることが多いので怖い
その「怖い」という発想が出てこないのが OOP に浸かった俺には不思議なんだ
本当に公開にできるフィールドなんて極々一部だと思うんだぜ
727:仕様書無しさん
07/10/06 17:06:11
Hiroyuki = new Hiroyuki();
は、解るんですが、
Person someone = new Hiroyuki();
が、良くわかりません。
出来る、というのは解るんですが、これをやると何がどう得になるんでしょうか。
728:727
07/10/06 17:35:30
すいません。下の間違いです。。
Hiroyuki hiroyuki = new Hiroyuki();
729:仕様書無しさん
07/10/06 17:58:10
#include <iostream>
class Person {
public:
virtual void SayName(void) const = 0;
};
class Hiroyuki : public Person {
public:
void SayName(void) const { std::cout << "My name is Hiroyuki" << std::endl; }
};
class Takumi : public Person {
public:
void SayName(void) const { std::cout << "My name is Takumi" << std::endl; }
};
int main() {
Person *p[2] = {0};
p[0] = new Hiroyuki;
p[1] = new Takumi;
for (int i = 0; i < 2; i++)
{
p[i]->SayName();
delete p[i];
}
return 0 ;
}
730:仕様書無しさん
07/10/06 18:05:04
>>728
改行多すぎって怒れれたから変なフォーマットになってしまったけど、
注目すべきは p[i]->SayName();。
実装されてないPersonのメンバ関数を使ってるけど、実行結果はこうなる。
My name is Hiroyuki
My name is Takumi
実際呼ばれているのはHiroyukiとTakumiのSayName()が呼ばれる。
異なるクラスのメンバ関数を同じ形で呼び出しているということ。
つまり、呼び出す側を共通化できる点が便利ってことかな。
731:727
07/10/06 21:17:26
>>730
レスありがとうございます。
説明で何となく解ったのですが、どんな場面で使うんでしょうか。
上の通り、と言われれば確かにそうだとは思うんですが、何となくまだ自分の中で理解が漠然としていまして。。
732:仕様書無しさん
07/10/06 21:46:17
>>731
これはポリモーフィズムとか多態性と呼ばれている性質です。
わたしよりずっと説明の上手な人がいろいろ書かれているので、
Googleなどで検索して調べてみて下さい。
例えばこんなのはどうかな。コードの例がさっきはC++で、これのはJavaですが・・
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
733:仕様書無しさん
07/10/06 21:51:41
例えば、読む負担が軽くなる。
List を派生させた AbstractList, ArrayList, LinkedList, Vector があったとき、
ArrayList arraylist = new AbstractList();などとする場合に比べ、
List list = new ArrayList();などとした場合は、
「具体的な実装について考えなくていいよ、
Listのことだけはともかくするよ」という読み方になる。
新しく何か定義したときも、
List list = new AtarasikuNanikaList();
これから下のソースは、以前Listとしてそのまま使える。
また、メソッドの引数で考えた時に、
void printList(LinkedList linkedlist)とした場合にくらべ、
void printList(List list)とした場合には、
obj.printList(new ArrayList())や、obj.printList(new Vector());
としても呼べる。
具体的な例を見つめながらプログラミングをするのは負担になる。
抽象化して、インタフェースに対してプログラミングできれば、
読む負担が減ったり、実装を入れ替えたりできてうれしい。
734:仕様書無しさん
07/10/06 22:55:42
>>731
まあ、普通に考えてお前がよくわからんと思ったのと
同じように他の奴も思うわけだ
こういうソースの書き方が業務で使われてたのは俺はみたことないけどな
ソースは他人が読めてナンボだと思うぜ
もちろん読む側のスキルをある程度要求することもあるがな
てか、これはスキルっていうよりあらかじめ実装の対象物の構造が頭に入ってる奴で
かつ、こういう組み方を日常にしてる奴しかこのソースは読め無いと思うんだ
かなり読める人間を限定してしまうと思うぜ
実際この構造を知らずにこのソースの構造から対象物の構造を理解するって話になると
かなり困難だと思うのは俺だけだろうか？
735:sage
07/10/06 23:25:56
>>731
うんこの色したボタンとちんこの色したボタンがある
どっちもボタンなんで動作は基本的に同じ。
これらのボタンをウインドウに配置するための
setButtonという関数があったとする
もし抽象クラスを用いないのなら
setButton(うんこボタン button);
setButton(ちんこボタン button);
という二つのメソッドをつくらんとならないが、うんこボタンとちんこボタンがボタンという抽象クラスから継承されていれば
setButton(ボタン button);
というメソッドがあるだけで、
ボタン button1 = new うんこボタン();
ボタン button2 = new ちんこボタン();
setButton(button1); //OK
setButton(button2); //OK
となるだろ？
さらに、小島よしおボタンとかアサヒスーパードライボタンとか、ボタンの数がものすごい増えていったとき
オーバーロードで解決しようとすると、ボタンの種類の数だけ関数書かなきゃならんけど、
抽象クラスにしておけば、ボタンをうけとる関数を書くだけでOK
素敵じゃね？
736:仕様書無しさん
07/10/06 23:28:02
クラスライブラリだと、ふつーに使われてるだろ?
SQL Server用の SqlConnection や SqlCommandをnewしてるけど、
ロジックはIDbConnection や、IDbCommandを使って組んで、ほかのDBになっても対応できるようにするとか。
737:仕様書無しさん
07/10/06 23:34:54
>>736
一般的に普及されてて使い方に特に解説がいらないもんならそうだけどね
自分ライブラリで自分仕様のクラスまでそうやって作ってしまっていいのかどうなのかってのは判断できんな
仕様書書いてどこまで説明できるか？ってところじゃない？
ソースそのまま渡して理解はされないと思う
738:仕様書無しさん
07/10/07 00:12:14
>>735
色は継承じゃなくてボタンの属性でよくね？ 白いちんこの奴もいれば、黒光りしてる奴もいるだろうし。
うんこにしたって(以下自粛...
739:仕様書無しさん
07/10/07 01:49:25
この場合属性でいいんだが、物のたとえだよ
それにしたってボタンの上をドラッグしまくるとだんだんおっきくなるボタンかもしれないし、調子が悪いと水みたいになるボタンかもしれないじゃん？
……まじめな話するとMFCデフォのボタンとオーナードローのボタンとか、ラジオボタンとチェックボックスとか、そういう意味での違いということでひとつお願いします
740:仕様書無しさん
07/10/07 02:36:43
現実的な話をするとクラスをメンバの変数でもつようにしたほうが経験上うまくいく
ＭＦＣみたいに構造から継承使うように作ってあったらそれに従うしかないけどな
継承すると同名の関数のくせに別の動作をするもんが大量に派生することになる
どれを呼び出してどの関数を通っているのか把握するのがかなり困難になってしまうところも注意
継承は実装の手間が減るだけでそれほどいい技術じゃない
大規模になるほど使わないほうがうまくいく場合のほうが俺は多いと思う
それと別に継承を使うやり方だけに言えることじゃないけど
あんまり部品を使いまわすとその部品が不良品だったときの影響力はあまりにもでかい
その部品の信頼度とかも考慮して、この辺もよく考えたほうがいいところ
741:仕様書無しさん
07/10/07 03:04:37
>>727
これはようするに抽象化とか一般化とかいうやつだ。
正方形は長方形の特殊なありかたで、長方形は四角形の特殊なあり方。
正方形より長方形、長方形よりも四角形の方が、より一般的とか抽象的とか言う。
Hiroyuki は Person の一部で、Person は Hiroyuki や Yakin らを一般化（抽象化）したもの。
そして、これらに応じて分類(classify)したものをクラスという。
同じ対象を捉えても、分類の仕方はいくつもある。だから設計は多様で、巧拙があり、より良い設計は困難である。
具体的な例が挙がっているので、それでわかるならそれでいい。
742:仕様書無しさん
07/10/07 08:41:10
>>740
実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
継承の本質的な意味は特定の振る舞いを変えることであって、実装を使いまわすための技術ではないでしょ。
実装を継承するならprivate継承すればいい話で、しかしprivate継承するならコンポジットする(メンバ変数として持つ）方がいいに決まってる
結合度ぜんぜん違うからね。
上記のような意味で継承を否定するなら、それはそもそもオブジェクト指向にそぐわない設計/実装をしているし
そういう環境に身をおいているという意味で不幸だな。
MFCのように特定のイベントを継承して実装するモデルよりJavaのなんちょれリスナーを登録するとかC#のデレゲートでイベントを表すという
コンポジット志向のほうが優れてるが、それだって根底にあるのは継承であって、単純にメンバ変数として持ってるわけじゃない。
イベントっていう基底クラスの振る舞いを変えた何かを持たせるわけだろ。
抽象クラスの振る舞いを再定義するのは、動作は違えど、期待される振る舞いが実装されることが前提で、そのコードの詳細を読まなければプログラムがかけないというのは困った話。
こういう問題は、オペレータオーバーロードでも同じだし、getXとか書いてあるのにXをgetしてくるわけでもないメソッドとかと同じだよ
継承による影響範囲の話も同じで、重複したコードを無くそうと思ったらコンポジットでも構造化でもなんでも、どこかに切り分けるわけだが
それらが不良品だったときの影響範囲も大してかわらん。むしろ利点は不良品だったとき一箇所直せば全部直るというプログラムの基本に話は戻る。
743:仕様書無しさん
07/10/07 09:21:00
>>742
影響範囲の話はリスク管理だろ？
投資で一点投資をしないで分散投資をするときの話と似ている
744:仕様書無しさん
07/10/07 09:23:26
>>742
>実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
オブジェクト指向の継承って何を狙ってやるもんなの？
メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないものってなに？
745:仕様書無しさん
07/10/07 09:37:53
オブジェクト指向は「考え方」で、それを実装に適用したのが、
プログラミング言語が備えている継承機能（Java の exteds とか）。
でも、この「考え方」は上流工程のモデリングにも適用できる。
オブジェクト指向は目的でなくて手段
746:仕様書無しさん
07/10/07 13:19:24
＞メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないもの
７４５さんのおっしゃる通り（自分の勝手な解釈が入ってますが・・）、分析を踏まえて実装するわけですから、
継承すべきものは継承し、メンバ変数でもつべきものはメンバ変数でもてばいいのでは？
メンバ変数でもつべきものを継承したり、継承すべきものをメンバ変数でもつべきではないですね。
他にも、関連はメンバ変数（ポインタ）で持つべきものだし。
例えばFileクラスとExcelWorkBookクラスというのがあったとする。
FileがOpenしたり、Saveしたり、Closeしたりできる一般的なファイルをあらわすクラスなら、
ExcelWorkBookはFileを継承する。
一方、ExcelWorkBookに他のファイルを埋め込める機能があれば、埋め込むファイルをFileクラス型メンバ変数で持つ。
ExcelWorkBookが他のファイルとリンクや参照を貼る場合は、それらをFileクラス型ポインタメンバ変数として持つ。
747:仕様書無しさん
07/10/07 17:43:44
>>746
で？なんか長いけど継承すべきものって？何？
748:仕様書無しさん
07/10/07 18:23:28
age
749:仕様書無しさん
07/10/07 18:56:54
>>747
継承はテンプレートメソッドパターンみたいに
サブクラスを実装させつつ型にはめたい場合に使うのがいいかも
750:仕様書無しさん
07/10/07 19:01:13
>>746
実装時の話ならば好きなものをメンバにすればよい。
ただし、インターフェースが先に決まっているのなら。実装からインターフェースが導かれるのは逆。
あと、ExcelWorkBook が File を継承するってのはどうか。
File を引数に取るメソッドが ExcelWorkBook にあるとか、SerializedExcelWorkBook クラスがあるとか、そんなところでは。
リンクも File ではなくもっと抽象的なものだろう。
751:仕様書無しさん
07/10/07 21:26:08
>>743
それはリスク管理でもなんでもない
似たようなコードを色々なところに分散して書くことがリスク管理になるのか？
ようするに基底クラスを変えると影響する範囲が大きいからテストがめんどくせーとかそういう話だろ
そりゃコピペ推奨しているようなもんじゃん。
たしかにコピペで似たようなものが大量にあれば、影響する範囲はそのコピペのうちの１つを使ってる部分だけになるが
他のコピペコードも潜在的にバグを内包しているわけであって、リスクを管理しているわけではなく、見てみぬふりをしているだけ。
いつ爆発するかもわからない爆弾を大量に抱え込んでるようなもんじゃん。
そいつはあんまりよろしくないと思うんだがな
>>744
継承使わなきゃ表現できないものは、後から拡張するとき。
標準入力から入力を受け付けて、それをファイルに出力するクラスがあったとして
入力をTCPやUDPからも受け取れるようにしたい場面に遭遇したとするじゃん
このクラスはもう安定動作しているので修正させないようにしたい場合、またはコンパイル後のバイナリでしか存在させず
そもそも修正できないようにする場合は、そのクラスの使い手側はメンバ変数に持たせることはできないよなそもそも。
だから、そのクラスはもともと外部から拡張できるような構造として設計/実装しておく必要がある。
だけど、そのクラスを作成するときは、いったいどんな入力が増えるのかわからない。
だったらどうするの？
って時は入力ストリームという抽象化されたメンバ変数を持っておいて、あとから入力ストリームを継承したなんらかの入力クラスを渡せるようにしておくようにする
ここには継承が使われているけど、これを継承を使わないでメンバ変数を保持する形でどう表すの？
コードが編集できる場合も同様で、ある特定の動作に対応させたいからとメンバ変数をもこもこ増やし、
そのメンバ変数を使うためのコードをクラスに追加しまくっていったら、馬鹿みたいにでかいクラスになって涙を流すことになる
だから継承とコンポジットをうまく使って正しくコンポーネントとして切り分けておくことが重要ですよ