07/04/13 12:45:42
ラッセルもﾋﾞｸｰﾘ
436:仕様書無しさん
07/04/13 13:35:12
>URLﾘﾝｸ(book.geocities.jp)
＞前出のようにクラスを具現化したものはオブジェクトですから
＞インスタンスはオブジェクトを指して使う言葉という事になります。
本当にあ(ry
437:仕様書無しさん
07/04/13 14:32:09
URLﾘﾝｸ(www.google.com)
438:仕様書無しさん
07/04/13 14:32:20
「クラスを具現化したもの」なら「インスタンス」の方が適切だな
439:仕様書無しさん
07/04/13 14:32:47
>>436
お前があ（ｒｙ
440:仕様書無しさん
07/04/13 14:37:57
>>438同意
おバカさまはクラス・オブジェクトが存在するような言語では
クラス⊂オブジェクト
なのを知って、クラス＝オブジェクトという妄念を得たのではないか？
441:仕様書無しさん
07/04/13 15:06:14
>>415
シカト？
442:仕様書無しさん
07/04/13 15:15:10
しょうがねえな。
>>415
おまえもｽﾚﾀｲ100回音読の刑に処す。
443:仕様書無しさん
07/04/13 16:54:02
>>おじゃば
おじゃばさまはようやくコテの付け方を覚えたか
おじゃばさまが愚か者であることは皆知ってるから謝る必要は無い
それより、俺愚かだからお舞ら教えろと言った方が良いぞ
444:仕様書無しさん
07/04/13 17:57:05
おいおじゃば、また名前付け忘れてるだろ
445:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 21:58:45
>>401
死ねよ
てめーわよ
446:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 22:02:25
>>431
じつはＭＳのＶＣ＋＋初期のライブラリのマニュアルではクラスとインスタンスをごっちゃにしてる。
ＭＳのマニュアル読むべし。
ＭＳ自体判ってなかった。
447:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/13 22:07:45
それからＭＳのＶＣ＋＋でコントロールなどを自動生成すると
呼び出し元の情報が埋め込まれてしまって部品化されていない。
そのコントロールをおいたダイアログ上からしか呼び出せなかったりする。
これはクラスの親子関係と呼び出しの親子関係をごっちゃにした結果である。
448:仕様書無しさん
07/04/13 22:24:02
なんつーか詭弁もいいとこだな
449:おじゃばさま
07/04/13 22:31:08
>424
クラスの爆発的増加はシステムによっては発生する。
継承を用いた方式では古典的な名前を用いた分類で対応する。
つまり、クラス名をRecUserExとかRecUserAndProductなどにして、関連性を見せる。
また複雑な結合に対しては、Viewを作成し、そのView名に関連したクラスを作る事でメンテナンス性を
確保する。ただそれほど良い方法でないのも認めているので、OO以外の考慮に対しては異存はない。
>432
SQLサーバの方は詳しくは知らないので、他の人に聞いた方がいい。
ただSQLサーバの方はデバッカも充実していて、他のMS製品とも相性がいいので、PL/SQLほど避ける
必要はないと思う。
>リンク厨
広い意味ではクラスもインスタンスも、オブジェクトなので解釈が分かれる。
だから誰かが間違っていると言うつもりはない。それぞれの意見にはそれなりの主張がある。
ただ、リンク張って満足している輩は、もう少し頭を使う訓練をしたほうがいいと思う。
450:仕様書無しさん
07/04/13 22:50:31
バカ
451:仕様書無しさん
07/04/13 22:59:10
だいたい思い出した、おまえさんの方法論。
ただそれがなんでここまで崩れてボロボロになってるのか、
それはよく判らない。
おまえ結局、大きなトラウマを持っていて、
ネットワーク上で暴れないと気が済まないんだろ。
もうやめておけ。こんな戯れ文書き散らかしても
おまえ自身がボロボロになるだけだ。
452:仕様書無しさん
07/04/13 22:59:31
バカ
453:仕様書無しさん
07/04/13 23:00:18
ﾁﾝﾎﾟ
454:おじゃばさま
07/04/13 23:08:45
>451
誰に言っているのだ？
俺か？リンク厨か？
455:仕様書無しさん
07/04/13 23:10:24
バカ
456:仕様書無しさん
07/04/13 23:11:34
おバカさまﾀｲｰﾎ
457:仕様書無しさん
07/04/13 23:19:33
＿
＼.＼ バカでもチンポでもいいから勝手にやってくれ
|＿|
／ ＼ ／＼＿
| ／ ／ ♯＼＿＿
| ./ / ※ ♯ ※＼＿＿＿＿
／ ,＼＿/ / ♯ ※ ♯ .／ ／
／＿＿＿/ ￣￣￣￣￣￣￣￣￣ ／
458:仕様書無しさん
07/04/13 23:22:39
めんどくせーから全部グローバル変数でいいよ
459:仕様書無しさん
07/04/14 01:20:00
DLLってCとC＋＋（OOスタイル）のどっちで書いた方がいいの？
今の現場でC＋＋わかる人いないんだけど、
できるならC＋＋でもいいよ（保守性などをふまえてて、物ができればなんでもいいよ）、って言われてて。
教えてｴﾛい人
460:仕様書無しさん
07/04/14 01:32:18
アセンブラ
461:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/14 01:33:38
自分の得意なほうでいいんじゃない？
462:392
07/04/14 01:40:19
高度すぎるのかなんなのか分かりませんけど、
ココ電球さんは言ってる忌みがよく分かりません。（何が言いたいのかもなぞです、すみません）
おじゃばさんは叩かれてるけど言ってる忌みは分かります。
＞おじゃばさん、他ヒント頂いたｴﾛい方々
ヒントありがとうです。
まだ迷い中・考え中ですけど、
方向性が見つかったのでうれしいです。
でもストアドはデバッグが大変なのか・・・（知識不足で申し訳）
一度に４万件ぐらいのレコードあるんですが、う～ん・・・
つか、これはスレ違いだからいいっす！サンキューです！
463:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/14 04:37:12
おじゃば自演すんなよ おまい
464:仕様書無しさん
07/04/14 07:50:13
クラス＝オブジェクト、であれば
hogeクラスのfugeオブジェクト
とかいう書き方が日本語としておかしいことになります。簡単ですね。
ひょっとして、おじゃばさまは職場で
boke(クラス名)オブジェクトのkasuインスタンス
などと説明してるんでしょうか･･･それは恥ずかしいんじゃ･･･
465:仕様書無しさん
07/04/14 11:18:06
>>459
俺はC++で書いてラッパー関数作って extern "C" でレギュラーDLLとしてエクスポートしてる。
466:仕様書無しさん
07/04/14 22:35:41
だいたい、「狭い意味でクラス＝オブジェクト(型)」とか言い切って
つっこまれたら「広い意味で全部オブジェクト」かよ。
Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
「おじゃばさま」って名前はもうやめたら？馬鹿なんだし。
467:仕様書無しさん
07/04/14 22:41:46
あいつあれでも、業務コンサル会社のCEOだそうです。
全然評判聞かないけどｗ
468:仕様書無しさん
07/04/14 22:42:59
は？Javaのクラスはオブジェクトだろ普通に。
Object o = String.class;
469:仕様書無しさん
07/04/14 22:52:18
暇暇コンサル
470:仕様書無しさん
07/04/14 22:53:11
特技：初心者教育
471:仕様書無しさん
07/04/14 23:03:09
知能および性格が著しく劣悪な池沼が
誰かに構ってほしくて暴れているようです。
スルーでお願いします。
472:仕様書無しさん
07/04/15 19:40:36
ロジックのセンスがない椰子がほとんどの業界で
オブジェクト指向など100年早いね。
473:仕様書無しさん
07/04/16 12:55:43
暴れるぞ＾
474:おじゃばさま
07/04/16 12:56:17
>463
自演してない。
一応、電球の発言を簡単に説明しておくと、
446の発言趣旨は言語開発元のMSですら、オブジェクトとインスタンスの定義が曖昧だと言うことで、
447でその例して、オブジェクトの親子関係と、呼び出し元先関係を混同していると言っているのだろう。
>464
何が恥ずかしいのか分からない。
>466
>Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
466の言うオブジェクトの定義が分からない。俺も468と同意見。
475:仕様書無しさん
07/04/16 16:56:35
それが属しているのがobjectクラスを基底にするクラスであることと、
その属しているクラスがオブジェクトであることは違うだろうよ･･･
本気でわかんないんだな、おじゃば。>468はどーみても釣りだろ。
476:仕様書無しさん
07/04/16 18:33:45
は？Java知ってっか？
Object o1 = new String();
Object o2 = String.class;
477:おじゃばさま
07/04/16 18:55:48
>475
オブジェクト指向の「オブジェクト」を最も良く表した物が、Javaの「Object」だと思うが。
釣りじゃないんじゃね？476でも言っているし。
478:仕様書無しさん
07/04/16 19:38:50
オブジェクト指向は理想と現実のギャップが大きいよ。
479:仕様書無しさん
07/04/16 19:41:52
たとえば？
480:仕様書無しさん
07/04/16 22:39:35
オブジェクト指向におけるオブジェクトの定義が
"コンピュータ上におけるクラスのインスタンス"なんだが。
コンピュータとは無関係に定義される抽象的な対象もオブジェクトって言われるから紛らわしいけど、
まともな本や論文ならオブジェクトはクラスのインスタンスの意味で使われてるよ。
481:仕様書無しさん
07/04/16 22:52:22
クラスもメタクラスのインスタンスなんだぜ
482:仕様書無しさん
07/04/16 22:59:51
Javaで例えるとこうか？
Object o1 = new String();
Object o2 = String.class;
Class c = String.class;
483:仕様書無しさん
07/04/16 23:00:36
実際にプログラミングあんまりしないからわからんが
カプセル化しないとバグ増えたりするのかね
484:仕様書無しさん
07/04/16 23:06:29
ただ単にカプセル化すりゃいいってもんじゃあないな。
オブジェクトがぶっ壊れないように、アクセッサでガードしなきゃ。
485:仕様書無しさん
07/04/16 23:56:12
だからよ。つくんのに、じかんがかかりすぎんだよ。プログラムなんて糞だぜ。
1年かけて作っても、独りよがりのものしか作れ無かったよ。
とっととやめちまえ。
486:仕様書無しさん
07/04/16 23:57:57
>>484の人気に早くも嫉妬
487:仕様書無しさん
07/04/17 00:02:54
遠慮せず突っ込みたまえ。
488:仕様書無しさん
07/04/17 00:05:38
>485
時間が掛かる時に使うと良い感じ。
OOに速さはあんまり求めない方がいいよ。
処理速度も開発速度も。
489:仕様書無しさん
07/04/17 00:20:27
処理速度も開発速度も、現実問題OOとあんまり関係ないよ。
手続き型で書いたRubyと、OOで書いたC++の
どっちが速い？
OOで書いたRubyと、手続き型で書いたC++の
どっちが早くできる？
490:仕様書無しさん
07/04/17 00:23:25
スクリプト言語と・・・
もう帰っていいよキミ
491:仕様書無しさん
07/04/17 00:31:05
>>490
おまえ国語力ないな
492:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/17 00:43:12
アクセッサなんか９９％使わない。
疲れて書かなくなったころ書いたのに必要だったり、上位層で書くの忘れてたのに必要だったりする。
必要になってから書いても遅くない。
493:仕様書無しさん
07/04/17 00:50:14
じゃあRubyでアクセサ無しでコード書いてくれ
494:仕様書無しさん
07/04/17 00:53:10
>>493
グローバル変数【これを君にあげましょう。】
495:仕様書無しさん
07/04/17 00:54:02
>>492
必要になってから書いても遅くないってことは、無いよりあったほうがいいってことか？
496:仕様書無しさん
07/04/17 00:57:12
＞アクセッサなんか９９％使わない。
使わないっておかしいだろ。
フィールドがprivateなら使わざるを得ない。
フィールドをpublicにしても９９％問題ない、ならまだ意味はわかるが。
497:仕様書無しさん
07/04/17 00:59:03
相変わらずOOの「設計」についてはスルーされてんだな
498:仕様書無しさん
07/04/17 01:00:47
だから、
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
クラス=型(+メソッド）
オブジェクト=インスタンス=実体（値+メソッド参照)
つまりクラスをnewしてメモリ確保したのがインスタンスでありオブジェクト。
499:仕様書無しさん
07/04/17 01:02:33
オブジェクト指向に設計と実装を隔てる垣根など無い。
500:仕様書無しさん
07/04/17 01:03:36
とりあえずnewしとけばおｋなスレはここですか？
501:仕様書無しさん
07/04/17 01:06:08
SDP原則により、自作クラスはnew禁止な。よく覚えとけ。
502:仕様書無しさん
07/04/17 01:06:20
>>499
とりあえずクラス図ぐらいは書いとけよな
「ソースが最新です」な奴はOOの利点捨てとるやろ
503:仕様書無しさん
07/04/17 01:08:16
>>501
全部クラスメソッドっすかｗ
504:仕様書無しさん
07/04/17 01:08:23
OOの利点って？
505:仕様書無しさん
07/04/17 01:13:49
メッセージ・UML・モデル化
506:仕様書無しさん
07/04/17 01:16:17
>>505
利点か？どうみてもなんかの手段だろ
なんの手段なんだ？
507:仕様書無しさん
07/04/17 01:21:20
OO＝手段じゃん
499が設計をそんまま実装概念に落とせるって話なら
それでいんじゃね？
あんまかみつくなよ。茶でものもうや
508:仕様書無しさん
07/04/17 01:24:24
>>507
わりい。噛み付いたつもりはない。
クラス図書くと何がいいのか、単純な興味から聞いてみただけ。
509:仕様書無しさん
07/04/17 01:30:14
しっかりしたクラス図があった場合、
メンテ・拡張が入る場合にクラス図を見れば、
どこに手を入れればいいかそれなりに分かる。
ソースをいきなり見るような無駄は無くなる。
なんでもかんでもpublicなんてことをやると手間がかかってしょーがない
つか、良識のあるPGはそんなことせんし
510:仕様書無しさん
07/04/17 01:38:56
クラス図メンテのコスト＜ソース見るコスト
って常に成り立つかなあ。ちょっと懐疑的。
オプソなんてクラス図ついてないのばっかだけど、
どこ拡張すればいいかなんてすぐわかるし。
511:仕様書無しさん
07/04/17 01:44:50
そりゃソース見るのに慣れてるだけの話
512:仕様書無しさん
07/04/17 01:50:21
ついでに言えば、OOは手段なだけ。
オブジェクト間をメッセージでつなげる。これが本質。
この分析をモデル化するだけなんやし。
コーディングも設計の一環でコンパイルが製造って言うならまあありかもしれんけど。
513:仕様書無しさん
07/04/17 01:56:09
ケイのほうのオブジェクト指向のメリットはいまだにわからん。
514:仕様書無しさん
07/04/17 01:57:03
さらに寝る前のついでに言えば、
たとえば地図とかのシステム作る場合なんかだと、
地図にもいろいろ種類あって、道路地図・地形地図・分布地図？とかあると思うんやけど
それぞれがクラス化されてればソース見なくても
「地図に信号足して」
なんて話になれば道路地図クラスやな、となんとなく分かる。
grepもいいけどソースだけで業務概念が分かるかどうかは微妙やね。
515:仕様書無しさん
07/04/17 06:06:36
ところで、Java ってスクリプト言語みたいに
MyClass obj = new MyClass();
Class klass = obj.class;
MyClass obj2 = new klass();
みたいな事って出来たっけ？
516:仕様書無しさん
07/04/17 08:59:18
真性のバカと判定
517:仕様書無しさん
07/04/17 10:17:35
>>516
だがBakaクラスのインスタンスにis_baka()をしても「バカじゃない！」って文字列が返ってくるんだろうな
518:仕様書無しさん
07/04/17 13:02:33
>>513
これは読みましたか？
URLﾘﾝｸ(www.purl.org)
キーコンセプトはメッセージングを介した徹底した動的性の追求です。
（現在主流のオブジェクト指向では、意味も分からず「オブジェクトへのメッセージ送信」と
お題目化されたり、ポロモルフィズムに包含されたりひどいことになっていますが…）
他の言語では（動的性に関しては）LISPのそれに近いですね。
言語以外では生物のしくみやネット（特にインターネット）に似せています。
変化に強いシステム（たとえば、止めることなしに走らせつつ拡張したり、
修正できたりする…など）を実現できる…というのが、まあ、メリットでしょう。
たとえば、これを実践しているSmalltalkは30年来、再起動ということを
数えるほどしかしていません。生命、インターネットもしかりですね。
519:仕様書無しさん
07/04/17 14:18:15
手段って。
何を実願するための手段なの？
520:仕様書無しさん
07/04/17 14:53:48
>>515は何でも発想してみるのはいいけど、
そんな簡単なコードは実際に実行してくれ。
少なくとも、newのオペランドは基本型かクラス（又はその配列）であって、
インスタンス（ここではklass）ではない。
521:仕様書無しさん
07/04/17 16:03:35
>>520
もしJavaでクラスがオブジェクトだと言うなら
コレもできるか？と思ってね。
PythonやRubyだと完全にクラスはオブジェクトだから
そういうことが出来てしまう。
そもそもクラス定義文自体が単に
クラス型のオブジェクトが変数や定数に入るだけだし。
522:おじゃばさま
07/04/17 19:21:04
俺はクラス図とかUMLを保守資料として残す意味はないと思っている。
仕様変更が入った場合、最も効率のいい方法は、作った本人に修正させる事だ。その場合、クラス図は不要だ。
「当たり前だ、作った人がいないから問題なんだ！！」と言う抗議が聞こえてくるが、その通りだ。
ここで他人が修正する上で、注意しなければならない点は2つある。
・最初から作るより、ある物を修正する方がスキルが必要。
・知らないシステムを修正する場合は、修正量にかかわらず、ある一定の時間（コスト）が必要。
上記の内容を、ぶっちゃけて言い替えると以下のようになる。
・ソース読めない奴には修正させるな。
・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
と言う事で、結果的にクラス図は不要になる。
ちなみにメンテナンスされない保守資料は不要どころか有害である。
UMLやクラス図はコーディング完了時に破棄するのが望ましい。
523:仕様書無しさん
07/04/17 19:37:38
>>521 リフレクション使えば
MyClass obj2 = klass.newInstance();
という書き方はできる。
524:おじゃばさま
07/04/17 19:42:51
ところでオマエラ、
「要求仕様聞いただけでソースコードが人」とか、
「ソースコード見ると、脳内で実行が始まる人」とかいない？
そういう事ってあるよな？
525:おじゃばさま
07/04/17 19:44:00
「要求仕様聞いただけでソースコードが見える人」な。、
526:仕様書無しさん
07/04/17 19:49:53
Doxygen使えよ。ソースからきれいなクラス図をつくってくれるぞ。ソースから
作るから、当然ドキュメントとしては最新状態が反映されたものになる。
ソースだけ読んで構造理解するよっか、クラス間の関連を掴むには便利。
527:仕様書無しさん
07/04/17 20:06:20
>>523
こうな
MyClass obj2 = (MyClass)klass.newInstance();
528:仕様書無しさん
07/04/17 20:07:44
>>526
それだと細かすぎんだよな。結局ソースみたほうがはやかったりする。
529:仕様書無しさん
07/04/17 20:19:08
クラスが何百もあるシステムの全体掴むのに一からソース読んでると辛くね？
530:仕様書無しさん
07/04/17 20:20:05
>>おじゃば
おじゃばが設計書読まない口頭主義なのは良く分かったが、
UMLはあくまでも分析なんよ。
顧客からの承認はどうすんだよ。結局なんちゃら仕様書ってのを作るんだろ
その一つがUMLなだけ。
それとも何か？いきなりコーディングか？
＞・ソース読めない奴には修正させるな。
＞・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
＞と言う事で、結果的にクラス図は不要になる。
「ということで」、の意味がわからん
要はUMLを使いこなせて無いだけじゃん
531:仕様書無しさん
07/04/17 20:24:28
ソース＝仕様書と言ってるJava厨がいるスレはここですか？
532:仕様書無しさん
07/04/17 20:35:40
オブジェクト指向開発はなぜ流行らないの？スレで
UMLを使いこなせて無いだけじゃん
はないだろ。常識的に考えて。
533:仕様書無しさん
07/04/17 21:31:41
UMLは実装前の設計時「のみ」で使うべき「モデリング」
実装が始まったらどうでもいいです
実装が終わったらrationalやらroseやらdoxygenで抽出
実装と同時にuml書くなんて馬鹿、大馬鹿、死ねって感じｗ
534:仕様書無しさん
07/04/17 21:58:28
死ね。
535:仕様書無しさん
07/04/18 00:32:58
C++って変体言語だろ。
javaかdelphiにしろ。
536:仕様書無しさん
07/04/18 00:35:52
今日は基地が沸いてるな
537:仕様書無しさん
07/04/18 01:25:36
今日は？ 今日もだろ
538:仕様書無しさん
07/04/18 01:36:02
こっちの板はもちろんそれがデフォ。
539:仕様書無しさん
07/04/18 09:42:13
>>533
ラウンドトリップしないの？
540:仕様書無しさん
07/04/18 10:09:16
>>530
相手するだけ無駄。
541:仕様書無しさん
07/04/18 11:07:43
>>530
>おじゃばが設計書読まない口頭主義なのは良く分かったが、
自分は単に「ソースコード至上主義」と読みましたが
542:仕様書無しさん
07/04/18 14:12:33
>>541
>>おじゃばが設計書読まない口頭主義なのは良く分かったが、
>自分は単に「ソースコード至上主義」と読みましたが
自分は単に「統合失調症」と思ってましたが
543:仕様書無しさん
07/04/18 22:43:50
おじゃば、悲惨だな・・
530にあっさり論破され、基地にからかわれ・・
まあ、実力以上の無理せんでガンガレ
544:仕様書無しさん
07/04/18 23:13:43
流行ってるだろ。
545:仕様書無しさん
07/04/18 23:35:00
むしろ大流行かと
546:仕様書無しさん
07/04/19 00:01:17
むしろ大発生だろ おじゃばみたいなしったかが
547:仕様書無しさん
07/04/19 00:11:43
オブジェクト指向のメリットがあるないで未だにもめてるこのスレで
UMLのメリットを自明であるように語るのは明らかに違うだろ。
クラス図を読むのはソース読むことよりかなり難しいのだが、おそらく
それすら知らないで、クラス間の関連がソース読まなくても視覚的に
わかるよわーいなんてレベルの奴らがUMLゆってるだけと感じてしまう。
具体的にUMLのメリットを示すべし。
548:仕様書無しさん
07/04/19 01:03:43
ソースより読みにくいクラス図なんて、むしろいらない。
549:仕様書無しさん
07/04/19 08:39:12
いるいる！>>547や>>548みたいな偽装連中！
自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
ってアランケイがゆってた
550:仕様書無しさん
07/04/19 08:50:22
>>547
クラス図だけ見てわかるような気にさせてしまうのが、問題なのかも。
551:おじゃばさま
07/04/19 09:41:54
>530
顧客からの了承でUMLなんか見せない。
顧客に見せるのは画面仕様書や画面遷移図などになるが、それもサンプル画面を作った方が正確で早い。
まあ、提出書類は決まっている場合も多いから、作らなければならない事も多いが、コーディング先でも
全然問題ないな。
UMLは新人や新しく入った人にプログラムを説明する時とか、複雑な処理を整理して考える時などに
使っている。UMLで顧客に説明？クラス図とかシーケンス図とか見せて説明するのか？
逆に聞きたいのだが、画面仕様ならともかく、顧客にクラス図やシーケンス図見せて分かるのか？
>531
「ソース＝仕様書」だよ。
何かおかしいのか？
>533
同意
552:仕様書無しさん
07/04/19 09:59:20
沖縄県の方へ（命に関わる注意事項です）
沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度 沖縄」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…
※一国二制度
簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
そして中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。
今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
553:仕様書無しさん
07/04/19 10:10:07
>>549
>自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
>ってアランケイがゆってた
kwsk
554:仕様書無しさん
07/04/19 11:46:00
>551
お前読解力ねーな・・・マジで
あとトリップつけろって
何回言われてもできないとかアホの典型か
555:仕様書無しさん
07/04/19 16:14:51
「ソース＝仕様書」
は正しい。
しかしながらその正論が通るところは少ないね。
556:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/19 19:06:39
ソースに仕様を全部書く
557:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/19 19:07:13
贅沢は言わないからマジックナンバーにコメントふってくれや
558:仕様書無しさん
07/04/19 19:57:12
お前は今すぐ死んでくれや
559:おじゃばさま
07/04/19 20:59:59
>554
理解力？何が言いたいのか分からないな。
俺が保守ドキュメントにUMLは不要だと言ったのを、554が全てのドキュメントが不要だと言ったと
勘違いしたのか？
ところでOOでメッセージがどうのとか言っていた人がいたが、何の事？
560:仕様書無しさん
07/04/19 21:13:55
むかしむかし、あるところに、OOでメッセージがどうのとか言っていた人
がおったそうな。
561:仕様書無しさん
07/04/19 22:23:44
オブジェクト同士のメッセージのことだろ
普通じゃん
さすが仕様書読まない奴だけあるなｗｗ
562:仕様書無しさん
07/04/19 22:42:35
>>551
うちは顧客にもUML（PJ内での拡張版）で説明する。
確かにサンプル画面は見てくれだけなら速いが、詰めが甘い。
そこでUMLで業務分析をした上で了承を取らんと。
コーディングが先でUMLを後で作るって時点で、おかしいだろ。
なんで分析ツールがあとで出てくるんだ？後だしならいらんし。そんなもん見らんわ。
つかさあ、担当者変わったあとでカスタマイズが入る度にソース全部追っかけてんのか？
めんどくない？
ソース＝仕様書ってのはオッケーだと思うが、
そのソース（仕様書）の分析をせずにコーディングするんだろ？
そこが謎。
あと他の奴も言ってるが、偽者うっとーしいからトリつけてくれや
563:仕様書無しさん
07/04/19 22:57:29
要求仕様書→UMLモデリング→顧客へ確認OK？→実装→だろ？
564:仕様書無しさん
07/04/19 22:57:53
クラス図でも、分析モデルと実装モデルとは用途がちがうぞ。
565:仕様書無しさん
07/04/19 23:01:11
UMLって描くのめんどいね
566:仕様書無しさん
07/04/19 23:02:40
>>563
スレタイ【OOD/P】の意味わかるか？
567:仕様書無しさん
07/04/19 23:03:36
話題沸騰ポットを知ってるか？
568:仕様書無しさん
07/04/19 23:08:39
>>566
OOAの話題はおいや？
569:仕様書無しさん
07/04/19 23:11:38
>>568
どうぞ
570:仕様書無しさん
07/04/19 23:15:49
OOD⊇OOAなんだけど？
571:仕様書無しさん
07/04/19 23:16:44
ポットの水とかお湯とかって本質的に不要だろｗ
572:仕様書無しさん
07/04/19 23:29:57
全然おもしろくないｗ
573:仕様書無しさん
07/04/19 23:31:13
ｗついてるやん
574:仕様書無しさん
07/04/19 23:35:01
>>559
お前まさか読めんのか？
「読解力」だよ
575:仕様書無しさん
07/04/20 11:41:34
>>559
>何が言いたいのか分からないな。
ばかだからでは？
576:仕様書無しさん
07/04/20 12:44:32
核心を突いてやるなってｗ
577:おじゃばさま ◆GxjxF3yEw6
07/04/20 22:53:29
>575
575の意見を思考停止という。
575はただの煽りとしても、思考停止を確信と核心する576には脱力だな。
まあ馬鹿じゃないんだろうけど、考えない癖がついているんだろうな。
でも何も考えない方が幸せになれるから、それはそれでいいのかもしれない。幸せになれよ。
578:仕様書無しさん
07/04/20 22:55:46
厨房だな・・・・
579:仕様書無しさん
07/04/20 22:57:15
アドレナリン中毒の愚かな野生動物だからな。
580:仕様書無しさん
07/04/21 00:38:13
>577
おもしろくありません
もうすこしがんばりましょう
581:仕様書無しさん
07/04/21 01:18:03
何だかんだ言って、技術ってすぐに過去のものになっちまうよな
582:仕様書無しさん
07/04/21 01:26:46
とはいえ今ある技術について行かなきゃ、次の技術が理解できないしな
583:575
07/04/21 01:42:47
>>577
そう、ただの煽りです。
でも、見たままの感想ですよ。
自分では気づいていない (莫迦故に) でしょうけれど。
>思考停止を確信と核心する
ほら。
584:仕様書無しさん
07/04/21 01:46:12
つまらん
585:仕様書無しさん
07/04/21 01:52:40
鳥付けてんのは偽もんだろ
モノホンは鳥も付けれんほど馬鹿だから
586:仕様書無しさん
07/04/21 02:02:47
アドレナリンからかうと面白いな。
アフォな事言い出してる所に水を向けると
10も20もレスを返してくる。
心にゆとりがないというか、
愚かで劣等感に苛まれている可哀想な人というかｗ
587:仕様書無しさん
07/04/21 02:06:05
おじゃばが食いつけそうなネタふることさえ出来なくなっちゃったの？
かわいそうにｗ
588:仕様書無しさん
07/04/21 02:46:25
・基本的にスルー力が足りないのだと思う。
・「荒しに反応するのは荒し」という経験則が、
荒し検出に非常に有効である事が再確認できた。
・同様に「キ○○○という単語に過剰反応を示す奴は、
たいてい本人がキ○○○」という経験則が得られた。
589:仕様書無しさん
07/04/21 03:12:24
オブジェクト指向で説明せよ
590:仕様書無しさん
07/04/21 03:19:09
猫はにゃーにゃーと鳴き
犬はわんわんと鳴き
蝙蝠は黙して語らなかった
591:仕様書無しさん
07/04/21 10:40:03
キチガイ、キチガイ、キチガイ、これがオブジェクト思考でつ
592:仕様書無しさん
07/04/21 11:03:19
VIPと間違えた。
593:仕様書無しさん
07/04/21 17:30:29
オブジェクト指向での製造方法を学ぶためには、
どういう点に注意したらいいですか？
クラスやインスタンスや継承など言語技術は理解していますが、
どうしても機能重視になってしまいがちで、
本質的に間違ってるという気持ちがあります。
594:仕様書無しさん
07/04/21 17:36:46
ほんとにやる気あるなら、メイヤーのオブジェクト指向入門よめ
595:仕様書無しさん
07/04/21 17:38:56
>>593
使う言語に応じてチームが使いやすいように設計すればいいよ
オブジェクト指向に本質とか意味ないし
但し一人よがりな設計はやめよう。チーム全体で理解出来るようにね
って書くと口だけで実践ともなってない奴とかがしゃしゃりでてくるんだろうけどなww
596:仕様書無しさん
07/04/21 19:04:00
なんだ似非コンサルの事か。
自覚症状があるならさっさと引退すればいいのに。
597:仕様書無しさん
07/04/22 07:56:46
>>581
技術って集中を分散の間を
ぐるぐる回っているだけだから、
止っていたら戻ってくるよ。
598:仕様書無しさん
07/04/22 09:31:34
シンプルに考えることを常に心掛けること。
デザインパターンが素晴らしいのもシンプルな考え方だからだね。
流行りものは、そこから概念だけを見切って、自分のフォースに取
り込むこと。がんばれ。
599:仕様書無しさん
07/04/22 09:45:26
「概念だけを見切って、自分のフォースに取り込む」＝半島人が俺様解釈でパクる行為のこと
600:仕様書無しさん
07/04/22 10:06:34
俺様解釈が新しいパラダイム生む。
601:仕様書無しさん
07/04/22 10:30:46
池沼の戯言
602:仕様書無しさん
07/04/22 11:37:15
最初からＯＯで入るからでしょ。
ＯＯが生まれた理由も価値もわからず、ＯＯを習うから結局、ＯＯが生まれることになった原因と同じような
ことを繰り返している。
gotoレスが叫ばれた時代と同じ。なにも考えずなにも疑問に思わないやつが使ってるから結局、元の木阿弥。
603:仕様書無しさん
07/04/22 15:13:56
価値が分かるの４０代？
604:仕様書無しさん
07/04/22 16:41:40
そんなことないだろ、新興会社でなきゃ、古い顧客も抱えてるから自然に触れるだろ過去のシステムも
605:仕様書無しさん
07/04/22 17:23:46
ウインドウ＝スレッドと思ってる香具師。
606:仕様書無しさん
07/04/22 20:05:01
モードレスダイアログのウィンドウプロシージャって別スレッドだっけ？
607:仕様書無しさん
07/04/22 20:31:16
だめりゃコリャｗ
608:仕様書無しさん
07/04/22 21:15:29
>>602
なんで伏字なんだよ。
と誤解されるのが日本で流行らない理由だな。きっと。
609:仕様書無しさん
07/04/22 21:16:48
せめて半角英数で書けばいいものを
610:おじゃばさま ◆GxjxF3yEw6
07/04/23 09:50:46
>593
言語仕様を理解しているなら次は「物をクラスで表現する事」だ。
まあ概念を説明しても今までと同じになってしまうので、実装方法から説明しよう。
機能で考えるてしまうと言うので、非OOでのC言語は理解していると仮定する。
まず構造体の要素を、クラスのprivateのフィールド変数に定義する。
次にそれぞれの変数のゲッターセッターを作る。そして機能毎に考えていた関数を分解して、
ゲッターとセッターの中に入れ込む。ちなみに機能毎に考えていた関数と、入れ込むゲッターは1:1に
なるとは限らない。どうしても入らない部分は、適当なメソッドを作って入れておく。
すべてのクラス分けが終わったら、一旦休憩した後に、もう一度クラスを見直す。
この時にクラスに相応しくないフィールド変数やメソッドがないか確認する。
例えば「商品クラス」に「顧客」の情報が入っていないかなどの確認だ。
ここで相応しくないと思った変数やメソッドは、相応しいクラスに移動する。適切にメソッドを作って
あれば、フィールド変数と関連するメソッドの移動だけで済む。ここでメソッドを移動しようとすると
別の変数を参照していて移動出来ないとか発生するが、これがうまくメソッド分けされていない部分である。
もう一度その部分を考え直して分離する。分離した時に前より複雑にならないように心掛ける。
611:仕様書無しさん
07/04/23 10:09:54
堕ちコン
612:おじゃばさま ◆GxjxF3yEw6
07/04/23 19:30:33
次に重要なのは「仕様変更を繰り返す」事だ。仕様変更を行う度にクラスを見直す事になるが、
正しく抽象化されていると、変更を繰り返しても構造が悪化しない。
悪化どころか、仕様変更の度に抽象度が増して、洗練されて行くのを感じるようになるだろう。
まあ、これを体感出来るようになるのは、普通の人で1～2年ぐらいかかるから焦る必要はない。
ちなみにデザインパターンや専門書は、上記の抽象化をマスターしてから見た方がいい。
抽象化も知らずにいきなりデザインパターンや専門書を見て、OOを理解出来る人などいないと思う。
613:仕様書無しさん
07/04/23 21:25:09
で？
このコテの文章って冗長なだけで
主観ばっかで何が言いたいかわからん
614:仕様書無しさん
07/04/23 22:28:40
作文だろ。文章能力を2chを使って養ってんだと思う。
素養の無さからくる整合性の欠落や、曖昧さ、そして中々上達
しないその様は見ていて痛々しいが、本人も一生懸命らしい。
ま、ほっといておいてやれ。
多分、この人の周りには、彼以上に優秀な人がいないのだろう。
そういう環境に長年浸って、自分を人一倍優秀だと勘違いして
しまったのだと思う。ある意味可哀想ではある。
615:仕様書無しさん
07/04/23 23:53:44
>>610
private変数のゲッターやセッターを作るんだったら
最初からpublicにすればいいと思ったのですが、
何か間違っているでしょうか？
ゲッター・セッターメソッドがづらづらと並ぶことにもなりますし、
変数が直接触れない以外、メリットがよく分かりません。
616:仕様書無しさん
07/04/23 23:55:51
>>610
アクセッサにロジック入れるのかよ(゜д゜)
617:仕様書無しさん
07/04/24 00:01:57
>>615
いやそうじゃない。private変数にはカプセル化の利点がある
いまさらそんな事言うまでもないがな。
つまりだ、お前は根本的に考え方が間違っている
りかい出来るまでは、オブジェクト指向の本を読みあさるんだ。
だんかいを踏んで、徐々に理解した方が今後の為にもなる。
なん度も繰り返しオブジェクト指向で考えれば必ず身に付くから。がんがれ
618:仕様書無しさん
07/04/24 00:06:43
>>617
レスありがとうございます。
ゲッターとセッターはprivate変数１個に対して１つずつ書くのですか？
これはカプセル化はカプセル化ですが、必要性がよく分からず・・・
private
int a;
int b;
public
getA();
getB();
setA();
setB();
619:仕様書無しさん
07/04/24 00:11:14
オブジェクト指向の本を読みあさった俺でも、
setter、getterをづらづら並べ、それをカプセル化言うのは何かが違うと感じる。
620:仕様書無しさん
07/04/24 00:20:08
気分的にはもうちょっと壊滅的に壊れてほしいな
ずいぶん手間隙かけたんだし
621:仕様書無しさん
07/04/24 00:23:39
つーか、どこの莫迦が getter/setter なんて発想をし始めたんだろう。
インスタンスの「状態」を戻す、あるいは変更するのが目的なんだから
内部変数と対応している必要なんざこれっぽっちもないってのに。
622:仕様書無しさん
07/04/24 00:27:58
>>621
入れ物として使われ始めたのはbeansからじゃね？
623:仕様書無しさん
07/04/24 02:59:00
極論すれば、Publicにするのは、インターフェースに限定するのが理想的。
内部変数はPrivateにして、公開しないのが原則。しかし場合によっては、
クラス内部でカウントされた値や、集計値などを公開する必要があるだろう。
その場合は、その値を、ゲッターとして実装し公開する。セッターはそのク
ラスの要件として必要な場合に限り公開する。
セッターは、グローバル変数に匹敵するぐらい危険な要素を孕んでいるこ
とを認識するべき。常に外部からの変更の可能性を考慮しないとならない
ため、人がコードを読む際にかかるストレスも大きくなる。private変数は
クラス外部からの変更の可能性は排除できるので、スコープを絞って集中
してコードを追うことができる。またメンバ変数は、そのクラスの機能を実現
するための必要最低限のものだけにするべき。当たり前だが、計算に使う
一時変数等をメンバ変数にしてはいけない。これもコードの可読性に関わっ
てくる。不要な情報は極力排除し、クラスのメンバとするべきではない。
OOの手法は開発時というより寧ろ、変更や保守性、拡張性といった方面での
貢献が大きいものだと思う。ゲッター、セッターを使うことで、値の代入に
対する仕様の変更があった場合に、その対応ロジックを１箇所に集中するこ
とができる。ゲッター、セッターを使わず直接代入していた場合、その代入
箇所すべてを変更しなければならないかもしれない。いわば事前にかけてお
く保険みたいなものだ。変更や保守がされないソフトウェアというものはな
いのだから。
624:仕様書無しさん
07/04/24 03:24:29
つーか、そんなに直代入使うか？
OOPやってると、セッタ自体滅多に使わないと思うんだが。
625:624
07/04/24 03:45:06
ちと言葉足らずか。
単に値チェックして代入するだけのセッタなんて使うか？
って訂正しとく。
626:仕様書無しさん
07/04/24 09:15:50
様々な言語で提供されるほとんどの文字列クラスにセッターがないことに気づいているか。
文字列長？ そんなもの内部で適切に管理されている。中身を変更したい？ copy-on-writedだ。
つまりよい設計とはそういうものだ。必要の無いものは提供しない。よく分からないけどこの
メソッドはPublicにした方がいいかなぁ。と思うならPublicにするな。公開する時は信念をもって
公開しろ。無計画にメソッドやプロパティを公開してはならない。徒に混乱の種をばらまくような
ものだ。
627:おじゃばさま ◆GxjxF3yEw6
07/04/24 09:51:46
>615
ちょっと説明が足りなかったようだ。
確かに値を設定／取得するだけのメソッドなら、publicにしたのと変わらないと思うかもしれない。
しかしそれは慣れないうちは最初にそうした方がいいと言う事で、作った後から要らない物は削除したり
統合したりして構わない。
例えば、セッターが10個あるとしよう。もし文字列を読み込んで分解して、それぞれを設定する場合しか
なかったとする。その場合いはセッター10個を削除して「void setRecord(String rec)」の1つにしてもいい。
また、設定ファイルを表すPropertyFileと言うクラスを作ったとする。
内容は「No:RECORD」が数十行続くレコードだったとしよう。
読み込みはファイル、取得はNoを指定してRECORDを取得するだけだとする。
その場合、セッターを全て廃止して「boolean read(String fname)」にして、ゲッターを
「String getRecord(int no)」の1つに集約してもいい。
慣れているならゲッターやセッターを作らずに、最初からこれでも良い。
これが進むと変数が隠蔽され、抽象化が進む。
628:仕様書無しさん
07/04/24 10:32:35
腐れコテがコテを付けたり外したりしながら独り言を書くスレ
629:仕様書無しさん
07/04/24 11:51:28
相変わらず主観だらけで冗長なだけ
挙げ句どっちかっつーと個人の感想止まりやんｗ
630:おじゃばさま ◆GxjxF3yEw6
07/04/24 19:16:08
>629
うるせーバカ。少しは頭使え、カス。
と、簡潔に書いてみた。
631:仕様書無しさん
07/04/24 19:19:37
de?
632:仕様書無しさん
07/04/24 19:25:47
>>630
うるせーバカ。少しは頭使え、カスキチオジャバ
633:仕様書無しさん
07/04/24 19:30:43
>>627
そのような”機能分類”したメソッドが存在するのは
すでに今まで自分でもうやってた手法です。
レコード文字列渡して必要なところだけセットする、とか。
もちろんprivateにするべきところ（と思ったところ）はそうしていました。
でも、これってオブジェクト指向って言うのでしょうか？
構造化プログラムとの違いがよく分からなくって・・・
違いといえばクラスと構造体ぐらいで、
構造体自体が関数持ってますよ（クラスで操作しますよ）、
ってぐらいしか違いが無いように思えるんです。
634:仕様書無しさん
07/04/24 19:34:01
>>630
昔の口調に戻ったな。うんうん。
やっぱりお前の知能程度にはそれくらいが丁度いい。
635:仕様書無しさん
07/04/24 19:37:21
>>633
もう1段階上の抽象化があるのだよ
636:仕様書無しさん
07/04/24 20:21:27
ちゅうしょーかっ！ ってタカアンドトシもゆってた。
637:仕様書無しさん
07/04/24 20:29:03
>>628
要するに基地害の寝言スレ
638:仕様書無しさん
07/04/24 22:43:03
つまりは良く考えて作りなさいよ。ということだな。
639:仕様書無しさん
07/04/24 22:58:18
そうそう。お前の親に言っとけ
640:仕様書無しさん
07/04/24 23:03:48
ほんとになぁ・・・
641:仕様書無しさん
07/04/24 23:16:26
setter,getter作るだけでカプセル化とか、setter,getterを必ず作るとかいうアホが湧いとるな
とくにわけの分からんクソコテ
痛い突っ込みされてまたわけのわからんこと言うとる
中途半端にOOを知ってる奴が一番タチが悪い
642:仕様書無しさん
07/04/24 23:17:09
でも構造化設計が最高！ソースも見やすいしね。
オブジェクト指向は、部品だらけで、組合せがソースから見えないよ！
643:仕様書無しさん
07/04/24 23:20:18
ソースをテキストで作るのはもう古いのでは？！
644:仕様書無しさん
07/04/24 23:33:45
>643
これからの時代はパンチカードだな
645:仕様書無しさん
07/04/25 00:31:55
縦読みが３０分も放置されてる・・・
646:仕様書無しさん
07/04/25 03:34:45
>645
どれ？
647:おじゃばさま ◆GxjxF3yEw6
07/04/25 09:28:37
>633
メソッドが機能になるのは正しい。次に問題になるのが「クラスが物を表しているか」だ。
これがオブジェクト指向と呼ばれる所以になる。誰かが言っていたもう一段階の抽象化も多分これだろう。
落ち着いてクラスを見て、クラスが「商品」や「利用者」などの物になっていて、それらに関連する
フィールド変数とメソッドで構成されているればOKだ。
そして前にも書いたが、そうなるように変数やメソッドを移動する。
構造化の考えだと機能重視になって、クラスが「書き込み」や「計算」などの機能になって、単に書き込み
メソッドを集めたメソッド集や、計算を集めたメソッド集になってしまう事がある。これはNGだ。
ただし分かりにくいのは、「物」と言ってもまれに目に見えない物をクラスにする必要があると言う事だ。
前のオセロの例で言うと、「ゲームのルール」などである。
またまれに、機能なのか物なのか微妙な物や、ある場合では物になる機能などもある。
例えば先ほどの「書き込み」もWriter（書き込む人）などにして、物として扱う場合もある。
まあこのあたりは最初から考えると分からなくなるので、そういう場合もまれにあるという認識だけあればいい。
648:仕様書無しさん
07/04/25 10:44:27
>>633
な？訊くだけ無駄だったろ？
649:仕様書無しさん
07/04/25 11:11:18
糖質との会話は、はたで見てる分にはとても滑稽だ。
常に話題がずれていき、二度と元の話に戻ってこない。
650:仕様書無しさん
07/04/25 11:13:42
>>648
同意。
>>647のようなレスでは出来上がったものを「盲人象をなでる」様に評しているだけに過ぎない。
>>633は（ここでの表現を使えば）「もう一段上の抽象化」をなしえるための方法論、
およびその方法論の背景となるパラダイム自体をたずねているのに
全く回答になっていない。
素直に「わかりません」と回答するほうが簡潔でわかりやすいワイ
651:仕様書無しさん
07/04/25 11:37:18
>>649
へー等質なんだ。
652:仕様書無しさん
07/04/25 11:49:50
アホコテのひとは3行で的確にまとめるように努力してみては。
あまりにもイミフで哀れ。
653:仕様書無しさん
07/04/25 11:54:17
確かに。
自分が言いたいことをダラダラ書いているだけだから読む気がしない。
読む側の事を考えていない。
まさにコーダー。
コミュニケーション出来ないのは自明だが、コードも冗長なんだろうなと思ってしまうね。
654:仕様書無しさん
07/04/25 12:30:07
構造化設計でいう所謂モジュールと、オブジェクト指向のクラスとの一番の
大きな違いはその集合体のインスタンスを生成できるかできないかじゃまいか。
複数のインスタンスを生成しないでいい、つまり一つのインスタンスだけでい
い場合はモジュール的な使い方とほぼ同じだと思う。
その場合は、メンバを全てクラスの静的メンバにするとか、シングルトンパ
ターンやモノステートパターンにするとかOO的な工夫はあるけど、つまりは
メソッドやプロパティを集めたモジュールと同じような使い方になる。
655:仕様書無しさん
07/04/25 13:12:44
デザインパターンなんか実際に使ってる人いるの？
業務系だけ？
656:仕様書無しさん
07/04/25 13:27:57
>>654
うん。
インスタンスを複数作れるという点が大きな違いではなかろうか
657:仕様書無しさん
07/04/25 13:34:30
>>655
君のように理解できてない人は使ってないでしょうね、少なくとも。
658:仕様書無しさん
07/04/25 13:54:31
657は理解できてるように思えないけど
理解できてる人はどこに使ってるの？
659:仕様書無しさん
07/04/25 16:37:00
例えば、商品リストを表現しようとすると、構造化の場合、商品という構造体と
その商品構造体の集合を保持するリストや配列、そしてそれらを検索したり、
追加したりするアルゴリズムをいっしょくたにして管理してしまいがちになるけど、
オブジェクト指向の場合、商品クラスとリストクラスを使ってそれぞれの特性や
役割を分離して表現できるんだな。つまり、構造化の場合、本来役割の違う
データ構造同士が密接に結合してしまいがちだが、きれいにクラス設計された
オブジェクト指向では、クラス同士が疎結合となり、それぞれの役割が明確にな
るため、保守性や拡張性が向上するんだな。しかし、設計や実装が汚いとメリット
を充分に享受できないどころか、人によってはＯＯアレルギーを招きかねない。
構造化の場合もいえることだが、ＯＯの有効性を充分に生かすためには、きれ
いな設計と実装が必須となる。
660:仕様書無しさん
07/04/25 21:03:18
>>655
「OOPに慣れた奴は自然と使ってるパターンがあるが名前が無く
どういうパターンと言われても説明が長くなる」
というモノに名前を付けたのがデザパタだろ？
だからちゃんと使えてる奴は意識せずとも使ってるのさ
661:おじゃばさま ◆GxjxF3yEw6
07/04/25 22:40:32
>653
PGなら誰でも分かるぐらいに簡単に説明したつもりだが、あれでも分からないのか？
いくらなんでも分からない訳ないだろう。つーか読んでないだろ？
662:仕様書無しさん
07/04/25 22:54:33
>>661
そもそも読む気が起こらない上によく分からん。
663:おじゃばさま ◆GxjxF3yEw6
07/04/25 23:01:45
>654
そのような事をHPで言っている人がいたが、いまいち意味が分からなかった。
集合体のインスタンスを生成出来るかどうか？
Cは構造体のインスタンスを生成出来るし、Javaはクラスのインスタンスを生成出来るから、
どちらも集合体のインスタンスは生成出来ると思うが、集合体のインスタンスって何だ？
「シングルトンの場合はモジュールと同じような使い方になる」？
シングルトンは構造化だと言っているのかな？staticメソッドじゃなくてか？
664:仕様書無しさん
07/04/25 23:07:29
>>654
「オブジェクト指向のクラス」という考え方が間違い。
言語のコードなどどうでもよい。
概念レベルで設計できるのがオブジェクト指向の素晴らしさなのだから。
665:仕様書無しさん
07/04/25 23:14:02
概念レベルで設計できないパダワン達が言語機構のポリモフィズムを乱用し、
そのうえスレッドを乱発するから、もう何がどうなっているのかわけわからんｗ
ちゃんとコンピュータサイエンスを学ぼうよ。
666:仕様書無しさん
07/04/25 23:17:45
もうオブジェクト指向スパゲッティはたくさんだ！！！！！！！！！！！！！！！
667:仕様書無しさん
07/04/25 23:21:16
オブジェクティブスパゲッティーでマンプクプクｗ
668:仕様書無しさん
07/04/25 23:22:48
現実的に生産性は最悪だな。オブジェクト指向。流行らなくていいよ。もうｗ
669:仕様書無しさん
07/04/25 23:27:57
何百も派生クラス作るんじゃないよ。まったく。属性で対応できるだろｗ
670:おじゃばさま ◆GxjxF3yEw6
07/04/25 23:28:27
>662
それなら読まずに、Java使ってCの構造化手法でシステム作って、その後にどんどん機能拡張してみるといい。
恐ろしいほどにスパゲティー化するだろうから。
671:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/25 23:34:18
／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
| 先輩、言われたとおりすべての変数にゲッターとセッターつけました
＼
￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ／￣￣￣￣￣￣￣￣￣￣￣￣￣
（ ・∀・） ∧ ∧ ＜ マクロで組んでどうすんだよ
（ ⊃ ） ( ；ﾟДﾟ) ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
￣￣￣￣￣ （つ＿つ＿＿
￣￣￣日∇￣＼| VISTA |＼
￣ ======= ＼
672:仕様書無しさん
07/04/25 23:41:26
ここには神レベルのプログラマが二人も降臨しているんだから
みんな有り難く拝聴するんだ！カスのあおりはスルーだ！
673:仕様書無しさん
07/04/25 23:45:11
主張するとたたかれるのが２ｃｈ。ま、主張するより叩く方が気楽で安全だわな。
で、主張するものがいなくなると、ぱったりと寂れるのがこのスレの特徴でもある。
674:仕様書無しさん
07/04/25 23:52:26
プログラム？ポリモーフィズム？ぷっw、俺様は概念を理解してるからね
そんな末端の瑣末な事柄には興味ないなぁ。チミたち、まだまだだね。
もちょっと勉強しようね。
って言っとけば、とりあえず王様気分でいられる。ま、なんの意味も無い
書き込みだけどね。
675:仕様書無しさん
07/04/25 23:52:59
変数は必ず関数経由でアクセスする、これがOOですよね先生！
676:仕様書無しさん
07/04/25 23:55:26
>>663
もう一度言おう。
>いまいち意味が分からなかった。
ばかだからでは？
>Cは構造体のインスタンスを生成出来るし
だから何？
CはOOPLではないが(厳密にはC++も違うかも知れん)、OOPができないわけではないし
そもそも複数のインスタンスが生成できることと構造化パラダイムとは何の関係もない。
677:仕様書無しさん
07/04/25 23:58:44
糖質スレ
678:仕様書無しさん
07/04/26 00:00:54
複数のインスタンスが生成できることはOOPパラダイムの一部だもんね
679:仕様書無しさん
07/04/26 00:02:23
構造体の領域をメモリに確保することと、インスタンスを生成することを
同義とみなす偉大なるおじゃばさま。
680:仕様書無しさん
07/04/26 00:12:16
意味論つまらん
>>633に戻ってほしい
681:仕様書無しさん
07/04/26 00:13:54
複数インスタンス厨連投うぜええええ
682:仕様書無しさん
07/04/26 00:21:11
大体、複数インスタンスってなんなんだよ
インスタンスなんだから複数ある前提に決まってんじゃねえか
683:仕様書無しさん
07/04/26 00:25:25
package Ojavasama;
sub new {
my $class = shift;
bless {},$class;
}
sub Kakiko {
return 'ぐだぐだぐだぐだ....';
}
1;
684:仕様書無しさん
07/04/26 00:28:43
javaworldに記事を書いた前橋が沸いてるのか？
685:仕様書無しさん
07/04/26 00:35:44
URLﾘﾝｸ(kmaebashi.com)
前橋確定
686:仕様書無しさん
07/04/26 06:24:56
夢見過ぎだぞ。高弘大丈夫か？
687:仕様書無しさん
07/04/26 07:07:48
今はまだベッドの上で長い長い夢を見てるの。
でも、きっと彼は帰ってくる…いいえ、絶対帰って来ます！
だから、今はそっとしておいて…お願いです。
688:仕様書無しさん
07/04/26 07:08:58
糖質は大変だな
689:仕様書無しさん
07/04/26 07:19:27
ねーねーおかーさん
とーしつってなあに？
690:おじゃばさま ◆GxjxF3yEw6
07/04/26 09:41:17
>666
オブジェクト指向のスパゲッティー化で嫌いになった人が結構いるって事か。
レガシーCの上級者が最初に作ったJavaプログラムに多い。
しかし成功より失敗からの方が多くを学べるから、オブジェクト指向をマスターするにはいい環境だよ。
>676
ところでパラダイムって何？
>685
そうそう、このHP。
マルチインスタンスがどうの以外は問題ないと思うが、肝心のオブジェクト指向はマルチインスタンスと
言うのが意味分からない。多分インスタンスの意味が違っていると思うが、クラスやオブジェクトに
読み替えてもちょっと意味がずれてる。
他で見かけない意見だから654はHPの作者じゃないか？よかったら説明してくれ。
691:仕様書無しさん
07/04/26 11:31:21
お前の言いたいことのほうがよくわからん
692:仕様書無しさん
07/04/26 11:40:02
コンピュータサイエンス（笑）
693:仕様書無しさん
07/04/26 14:10:34
詳細設計や実装には強いが分析をあまり重視しないBooch法。
問題領域を調査する手法を提供する反面、解決領域が弱いOMT。
そして、解決領域での利便性に比べて問題領域が重視されないOOSE Objectory。
これらを１つの一貫した統一アプローチへ統合したスリーアミーゴはつくづく偉大
だと思う。残念ながらその理念を理解し使いこなしている人が少ないの現状は、
非常に残念だ。
694:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/26 18:48:08
OO厨の糞ソース読んでたら 血を抜かれたみたいにぐったり。
OOちゅ死ね
695:654
07/04/26 19:04:54
ちがうよ、俺はそこの作者じゃない。
つか、どこに、「オブジェクト指向はマルチインスタンス」って書いてあんだよ。寧ろそこ
の作者の言ってることと逆じゃねぇか。
同一クラスのインスタンスが常に複数生成される訳じゃないだろ。例えばWinアプリ
とか作るときでも、生成するアプリクラスのインスタンスは1個だけだろ。その場合は
別に無理にクラスにしなくてもエントリポイント(WinMain)と初期化ルーチンとかメッセー
ジループを用意してやればいいんだけど、ただ全体的にOO設計で統一した方が分か
り易いし、いろいろ都合がいいからアプリケーションクラスなんてものを作って、その
インスタンスを１個だけ用意してるわけだろ。他にもマネージャクラスとか、リソース管
理クラスとか、インスタンスを1個しか使わないケースはいろいろあるわな。
つまり必ずしもインスタンスは複数生成するものじゃない。じゃなきゃ、シングルトン
とかモノステートなんか不要だからな。必要があるからそのための手法があるわけだ。
696:仕様書無しさん
07/04/26 19:12:34
文章的特徴が一緒なので、自作自演どころか単なる独り言にしか見えない。
697:仕様書無しさん
07/04/26 19:13:39
文体を微妙に変えている所がまた泣けるな
698:仕様書無しさん
07/04/26 19:25:12
つーかなにこの改行
読みにくいってレベルじゃねーぞ
699:654
07/04/26 19:42:42
>>698
全員が自分と同じ環境で2chを見てると信じて疑わない莫迦に言われたくない。
つか、お前の改行も変だぞ。句読点をつけないのとその文体の特徴から今までの
カキコもバレバレだし。
700:仕様書無しさん
07/04/26 19:43:58
なあ、アンタ、何逆ギレしてんの？
701:仕様書無しさん
07/04/26 20:18:23
即答だなw
702:おじゃばさま ◆GxjxF3yEw6
07/04/26 20:49:11
>695
俺はオブジェクト指向かどうかと、インスタンスが複数生成できるかは関連がないと思っているのだが、
そこの所はどうなのだろうか？
703:654
07/04/26 21:03:41
インスタンスを生成できないオブジェクト指向なんて俺は使いたくない。
クラス(変数とメソッドの塊)のオブジェクト、つまりインスタンス（構造体
じゃないよ）の生成は非ＯＯでも擬似的にやれなくもないが、よっぽどうま
くやらないと本来の主眼である保守性や拡張性、可読性を損なうことになる。
つか、そこまでやっちゃうともはやＯＯだろう。cのmallocはデータ領域の
生成であって、インスタンスの生成じゃないからな。おわかり？
704:仕様書無しさん
07/04/26 21:09:48
42 654 sage 2007/04/26(木) 21:06:59
ぱんつとパンティーじゃ全然ちがうんだよ、ヴぉけ。
705:仕様書無しさん
07/04/26 21:24:24
既出だったらすまないけど、前橋和弥（ポインタ本の人）のOOP論についてはどう思う？
俺はこの人のOOP論は倒錯してると思うんだけど。
どう倒錯してるかは気が向いたら書きたいと思うけど、簡単に言えば言語のOO化の
副産物に過ぎないものをOOPの主目的と取り違えている。
その倒錯は恐らく、「図解の技術」― 分かり易い設計図の書き方に関する技術であるOOを、
要は人間の脳へのアプローチであるOOを、「工法」― 地震に強いとか防音といった
新しい機能を実現するための技術、要はコンピュータへのアプローチと混同し
取り違えているところから来ていると思われる。
706:仕様書無しさん
07/04/26 21:44:14
>>705
おいクソコテ付け忘れてるぞ
707:仕様書無しさん
07/04/26 22:41:25
えっとですね、おじゃばさんに質問していた件ですけど、
オブジェクト指向ってもうすこし具体的に何がいいかってのが知りたいんです。
たとえばJavaの場合だと、
newしてほったらかしのガーベジコレクタとかは確かに便利ですし、
呼び出し元関数の変数アドレスが呼び出し元で確保できてるのも便利です。
でも、これってJava言語仕様の話であって、
オブジェクト指向とは関係ないですよね。
自分が便利だと思ってるのがそのへん（プログラマがメモリ意識しなくてよい点）なので、
オブジェクト指向が便利なのではなく、Java言語（ＶＭ？）の恩恵が高いってのが
目立ってて、オブジェクト指向自体でうれしいってことが見えないんです。
今C++の業務やってるんですけどnewしてdeleteは当たり前ですし、
オブジェクト指向言語って？？？って感じで・・・
すみません、うまく伝えられなくって・・・
708:仕様書無しさん
07/04/26 22:42:32
あ、５行目間違いです・・
呼び出し先のアドレスが、呼び出し元でも残ってる、って意味です。。
709:仕様書無しさん
07/04/26 23:56:48
>>707
継承や多態は恩恵だと思わないか？
710:仕様書無しさん
07/04/27 01:11:09
データ構造に対するオペレーションが複雑になった時にそれをクラスの挙動
として集約できるのはそれだけでメリットじゃなかろうか、後プログラムの設計時
にあるデータ集合を取りまとめてより1段上の階層でのオブジェクト関係で取り扱う
場合にも集約し易いし、概念的な取り扱いを自然に表現する上で多態なんかも便利
だしメンテもし易い
上手く表現できないけど自分の場合そんな感じ、自分もメインはC++で使っているので
所有権は明確にしなきゃいけない事が多いけど、それでも便利だと思う＞OOP機能
711:仕様書無しさん
07/04/27 01:30:52
数学で行列やベクトルが何故便利なのかという質問と同じような話な気がする。
事前に演算体系(=クラス設計)を定義する事で実際は複雑な計算(=プログラム)
を如何に表面上簡潔に表現(=プログラム作成)するかというような。
OOP機能はそういった演算体系(=プログラム内の抽象化構造)の階層化を比較的
自然に表現できるし、逆にそういった機能(例ではベクトルや行列計算が無くても
四則演算のみで解決できるような問題)が必要無い規模では余りメリットが見えて
こないかも。
712:仕様書無しさん
07/04/27 02:01:04
プログラムをOOP機能を使ってで作成する場合、クラス設計に要する思考は対象
となるアルゴリズムよりも一段メタ的な所にシフトして設計し、その後対象
アルゴリズムにシフトダウンする必要があると思うのだけど、この思考の切り替え
の部分が(自分の経験では)人により差異があるように見受けられるのでオブジェクト
指向が難しいと言われる一因ではないかと思う。
ただ幾ら慣れても切り替えのコストは0では無いので自分の場合も数10～数100行
程度の雑用プログラムを書き殴るのであればクラス機能とか使わない方が楽だけど、
それ以上もしくはメンテナンス効率なんかを考えるとOOP機能は便利。
713:仕様書無しさん
07/04/27 02:04:41
思う
思う
思う
('A`)ｳﾞｧｰ
714:仕様書無しさん
07/04/27 02:28:55
>>646
>>617
715:仕様書無しさん
07/04/27 02:30:17
これまた判りやすい
薄っぺらな自作自演
716:仕様書無しさん
07/04/27 02:32:15
用語使いが特殊というか変だ
717:仕様書無しさん
07/04/27 02:50:10
高弘隔離病棟
718:仕様書無しさん
07/04/27 03:39:52
710=711=712
別段自演の意図では無く思いついたまま書いただけだけど、自演っぽく映ったの
ならスマヌ
719:仕様書無しさん
07/04/27 05:31:28
>>707
俺様的には気軽に型を作りまくれる辺りだな
Cで調子こいて構造体作りまくると
操作する為の関数が多くなる
まぁそこまではどっちも似たようなモンだけど
それら自作構造体の内容を全部文字列として標準出力したいとすると…
OOPL:
各クラスでtoString()オーバーライドして
出力ルーチンは単にtoString()して出力するだけでいいんじゃね？
あれだよあれ、多態ってヤツだよ
非OOPL:
型判定して型にそった文字列化の関数呼ぶ？
でもソレちと行数が多いな…つーかこんなに構造体作ったの誰だよ
つーワケで自作型作りまくるなら断然OOPLだな
別にOOでない使い方だって出来るんだしぃ？
720:仕様書無しさん
07/04/27 07:05:12
非OOPL:
extern int print(struct foo);
extern int print(struct hoge);
extern int print(struct fuga);
721:仕様書無しさん
07/04/27 07:55:23
非OOPL
template<typename T>
void print(T x){printString(toString(x));}
722:仕様書無しさん
07/04/27 08:15:52
「プログラミング作法」の Rob Pike 先生によるOO信者批判
URLﾘﾝｸ(hisashim.livejournal.com)
私はオブジェクト指向設計の熱心なファンではない。私はOOで作られた美しいものを
いくつか見てきたし、自分でもOOなものを若干手がけさえしたけれど、OOは単に問題に
対してアプローチする方法のひとつでしかない。ある問題に対しては理想的な方法だが、
別の問題に対してはそれほど合った方法ではない。（中略）
オブジェクト指向設計の推進者たちは、ひと塊の木材が持つ美しさが作業を始める前に
自ら姿を現すのを待っている、木彫りの名人のように思えるときがある。「おや、見てくれよ。
木をこう回転させたら、木目が座席の角度にちょうどうまく合った角度で流れるよ、ねえ？」
素晴らしい、いい椅子だ。でも自分が座っているときに木目が気になるだろうか？ そして
次回は？ やらなければならないことが、どんな木材にも隠されていないことがときどきある。
OOは、インターフェイスが自然に幅広い範囲の型に適用できるような問題には素晴らしく
適しているが、ポリモーフィズムを扱うにはあまり適さないし（コレクションをOO言語に
持ち込もうと画策する動きは、見ていると仰天することばかりだし、一緒に作業をすると
なるとひどい目にあいかねない）、ネットワークコンピューティングには抜群に不向きだ。
私が、問題によって言語を使い分け、そしてさらには -- しばしば -- ひとつの問題を解決
するために複数の言語で書かれたソフトウェアを組み合わせる、そういったことをする
権利を保留しているのは、このことが理由だ。
723:仕様書無しさん
07/04/27 09:06:20
たっ、…たとえだよ、たーとーえ！
俺様だってＣ言語ぐらい知ってらい！
ほら、もっと何かあるだろ？
でもC++なんてずるい…
724:おじゃばさま ◆GxjxF3yEw6
07/04/27 10:14:53
オブジェクト指向の利点は変更に対する強さだ。
つまり正しく設計されたOOプログラムは変更を繰り返しても、構造が悪化せずむしろ洗練されていく。
Cの構造化でも正しく組めば悪化しないと言うかもしれないが、確かにうまく組めば悪化しないだろう。
しかし構造化Cで悪化しない場合は、設計者が経験豊富で、変更を見越した設計を行っている場合が
ほとんどだ。OOの場合は変更を見越していなくても、OOの方針に従っていれば少ない修正量で構造を悪化
させずに機能追加できる。
あと仕様が明確でなくても作りやすいのがOOの特徴だ。
非OOの場合は仕様が全部見えてないと作りにくい。後から追加された仕様で作り直しに近くなったりする。
OOの場合は分かっている所から作り始めても、OOの方針に従っていれば、修正量は少ない。
ただ設計者が追加を正確に見越していれば、非OOでも問題なく作れる。
例を示すと、CとJavaでDBを使ったアプリを作っていたとする。
営業が「ORACLEは高いからPostgresにする事に決まったよ。」と言ったら、Cの方はDBを変更する事を
見越した設計にしていない限り、作り直しになる。Javaなら少し修正するだけだ。
また営業が「もっと売りたいな、64ビットSolarisでも、32ビットLinuxでも動くようにしておいて。」
なんて言ったとする。64/32の互換を考慮した設計なら非OOでも問題ないが、多くの場合は分かりにくい
バグに悩まされることになる。
725:仕様書無しさん
07/04/27 10:23:27
なぜOOだとバカでも変更に強い設計が出来るんだ？って説明がないぞ。
どっちかっていうとOOってバカでも能書きが言えて素人をだませる、
という主張にしか見えないなぁ。
726:仕様書無しさん
07/04/27 10:48:57
>>725
同意。事象の表明を書くのは良いがそれだけじゃ意味が無いワイ
やれば誰でも実感できるレベルの話だけをながながと読まされるこっちの身にもなってみろ。
>>724よ、>>725の指摘した点に自分の考察なり見解なりを書いてみろよ。
お前の観察日記を読むために来てるんじゃない
727:仕様書無しさん
07/04/27 10:50:24
バカにOO与えると
泥沼になる
728:仕様書無しさん
07/04/27 11:32:25
>>726
>ながながと読まされるこっちの身にもなってみろ。
おじゃばファンでもないのに、なんで読むのさ。
729:仕様書無しさん
07/04/27 12:10:29
ぶっちゃけ日記はblogでやってろってなレベル＞アホコテ
730:726
07/04/27 12:18:56
>>728
そりゃぁ。
>ながながと読まされるこっちの身にもなってみろ。
とレスするためさ
731:仕様書無しさん
07/04/27 13:41:25
>>724をリファクタリングしてみた。
ＯＯは仕様変更に強く、変更の繰り返しで寧ろ構造が洗練されていく。
また、分かっている所から作り始められるので、仕様が不明確でも作り易い。
対して、非ＯＯの場合は、熟練者が変更を見越した設計をしていない限り、
修正は困難になる。
例えば、対象DBやＯＳが変更になる場合でも、OOだと、少しの修正で済むが、
非ＯＯでは変更が考慮されていない場合、バグに悩まされることになる。
・・・纏めてみても、結局何を言いたいのかよくわからんな。ＯＯの利点を強調
したいのか、非OOでもうまく設計されていれば問題無いと言いたいのか。
732:仕様書無しさん
07/04/27 14:26:52
くだらないあげあしとりばっか
あきらかにおじゃば以下
733:仕様書無しさん
07/04/27 14:52:07
>>725-726
正論。
>>724は信念を語っているだけで、
その信念の合理性を客観的示す事ができない。
つまり宗教なんだ
734:仕様書無しさん
07/04/27 14:59:21
>>733
そんなもの簡単に示せるわけがない
かいつまんでいうと、あげあしとりｳｾﾞｴ
735:仕様書無しさん
07/04/27 15:06:16
全体を批判することをいつから「あげあしとり」と呼ぶようになったんだ。
○○以下 という発言は「自分は○○です」と言っている様に読めるぞ。
かいつまんでいうと、ｵﾏｴが黙れ
736:仕様書無しさん
07/04/27 15:18:33
>>735
いや黙るべきはお前だ
対案のない批判なんか必要ない
737:仕様書無しさん
07/04/27 15:34:05
>>733
> >>724は信念を語っているだけで、
> その信念の合理性を客観的示す事ができない。
>>734
> >>733
> そんなもの簡単に示せるわけがない
> かいつまんでいうと、あげあしとりｳｾﾞｴ
信念の合理性を客観的に示す事ができない＝狂信者決定
738:仕様書無しさん
07/04/27 15:43:52
>>737
おまえの信念と客観的な合理性の提示よろ
739:仕様書無しさん
07/04/27 16:28:29
信念：
狂信者に対し、自分の信念を語る暇などない。
客観的合理性：
狂信者とは、己の考えの根本的正当性の確認努力や
他人に対する合理的説明努力を怠ったまま、
自分の考えが絶対正しいと主張する輩に対する
蔑称である。
そのような人物と時間を費やし議論を重ねても、
虚しい言葉が行き来するのみで
相互理解は極めて難しい。
従って、狂信者に対しては何も語らず、
ただ黙殺する事が、時間を有効に使う秘訣である。
740:仕様書無しさん
07/04/27 16:40:14
>>739
黙るっていったからには絶対黙れよ。
741:仕様書無しさん
07/04/27 16:56:19
次スレは
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発儲はなぜ黙らないの？★
ということでよろしいか？
742:仕様書無しさん
07/04/27 17:02:11
アンチでも信者でもいいけど、なんか中身のあるレスすれば？
あきらかにココ電以下
743:仕様書無しさん
07/04/27 17:02:11
あまりに>>724が哀れだから >>724を訂正してやろう。
1. OOであろうと構造化であろうと、下記二点
(1)高凝集性：プログラムの構成要素(変数,関数,etc.)の出現範囲を局所化する
(2)疎結合性：局所的なまとまりに対し適切なインタフェースをつける
を「実現」すれば、
「ある範囲」の変更要求に対しては、変更の影響を局所化でき、
拡張性/保守性の高い、いわゆる「変更に強い」プログラムを構築できる。
2. OOは、その種の局所化とインターフェース化について、
構造化よりも適切な道具を提供しており、
「それらの道具を適切に用いれば」、
上記二点を実現する際の設計負荷を和らげる事ができる。
問題は1(1)(2)の実現方法、2の道具の適切な使用方法にある。
OOであれば、熟練しなくとも1(1)(2)、2を実現できるなどというのは
妄言に過ぎない。
744:仕様書無しさん
07/04/27 17:04:50
>>724
高弘さぁ、レポート書くの苦手だろ。
お前の文章って怨念がにじみ出ていて、
全然客観的じゃない。
「理系の作文技術」でも読んで、レポート書く練習したらどう？
745:仕様書無しさん
07/04/27 17:10:24
おまえアホだろ
おじゃばは少なくとも「OOの方が低コスト」と主張している。
おまえの主張はまとはずれ。
746:仕様書無しさん
07/04/27 17:11:26
ことばたらずだった。
「変更に強い」プログラムをつくるためのコストな。
747:仕様書無しさん
07/04/27 17:12:28
>>743
客観性一切なし。もう黙れ。
748:仕様書無しさん
07/04/27 17:13:19
で>>743に要約したみたいな30年前の素朴な考え方じゃ
とっくに行き詰まりが生じていて、
だから落ちこぼれ業務システムの分野でも
DIコンテナやらサブジェクト指向が取り沙汰されてるんだろ。
749:仕様書無しさん
07/04/27 17:13:57
>>743
具体性も０
750:仕様書無しさん
07/04/27 17:14:16
>>747
とりあえずお前がバカだという事はよく判った。
>>747は罵詈雑言の口先野郎としてスルーする。
751:仕様書無しさん
07/04/27 17:14:53
もしかして、今ここで連続レスしてるのって、
池沼の方？
752:仕様書無しさん
07/04/27 17:16:48
>>748
アスペクト指向、サブジェクト指向はなかなか面白いよね。
業務システムを手続き処理に還元してグダグダにしちまう誰かとは
頭の出来が違うと思った。
753:仕様書無しさん
07/04/27 17:17:01
>>748
だから、の使い方が意味不明。
DIコンテナとサブジェクト指向が、どう行き詰まりを解決するのか書け。
754:仕様書無しさん
07/04/27 17:17:56
>>752
知ったか乙
755:仕様書無しさん
07/04/27 17:19:13
>>752
どこからアスペクト指向が出てくるのやら。
DIコンテナとアスペクト指向に、なにか関係があるとでもおもっているのだろうか。
知ったかJava厨乙
756:仕様書無しさん
07/04/27 17:19:31
バカ相手に講釈するのは時間の無駄。
お前お得意のゴッグルさんで@ITの記事でも読んでろ池沼ｗ
757:仕様書無しさん
07/04/27 17:20:58
高弘ってテンパるとすぐ罵詈雑言が出てきて、
元の話を棚上げしてくるからからかい易いな
758:仕様書無しさん
07/04/27 17:22:29
元のはなし： あげあしとりｲﾗﾈ
759:仕様書無しさん
07/04/27 17:23:22
>>756
知ったか確定乙
760:仕様書無しさん
07/04/27 17:23:37
元のはなし：高弘は言語も思考もカオス
761:仕様書無しさん
07/04/27 17:26:14
糖質からかうとおもしれぇな
デザパタ、リファクタ、構造化しか持ちネタねぇのかよターコ
762:仕様書無しさん
07/04/27 17:40:37
糖質の脳内では自分の疑問点を説明してくれない人は
全部「知ったか」と変換されます。
763:仕様書無しさん
07/04/27 17:42:43
闘牛状態だなｗ
764:仕様書無しさん
07/04/27 17:55:03
【レス抽出】
対象スレ： 【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
キーワード： 低コスト
抽出レス数：1
>>745はおじゃばの脳内主張をエスパーできるサイコ仲間かｗｗｗｗ
765:仕様書無しさん
07/04/27 18:16:59
元の話に出てこない単語が
いきなり飛び出すのは
このスレが糖質の自作自演だから
766:仕様書無しさん
07/04/27 18:54:19
野次までつまらなくなってきた
OOわからないなら他行けよ
767:仕様書無しさん
07/04/27 19:00:08
サイコをリアルタイムでからかえる
とても便利なインターネッツ
768:仕様書無しさん
07/04/27 19:18:16
DI： クラスの疎結合実装に役立つ
AOP： 個々のクラスが提供すべき機能を
複数の側面に分割して記述する事が可能になる。
結果として通常のクラス設計では複数のクラスに散らばってしまう
横断的関心事の局所化が可能になり、拡張性/保守性を高める事ができる。
769:仕様書無しさん
07/04/27 19:51:51
サブジェクト指向ってなぁに？ぐぐったら判るの？自分はわかんなかったなぁ。
#ぐぐっったら何でも判るんだったら「オブジェクト指向」も遭難じゃないの？
770:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:16:17
>725
バカでも変更に強い設計が出来るなんて言っていない。
そのシステムや業務の経験が浅いSEでも、OOをマスターしていれば、変更に強い設計が出来ると言っている。
>726
「やれば実感出来る話」を長々と書くのは、やらない人が多いからだ。
>731
その解析は正しい。
OOの利点を説明したのが前半。しかし非OOでもうまく設計されていれば問題無い言うのが後半。
OOの利点と、非OOとの違いを聞かれたのでそう答えた。
俺はOOで設計すれば全てOKなどと言うつもりはない。
「仕様が未確定で変更が多い」物にはOOが向く。逆に言うと「仕様が確定していて変更が少ない」なら
非OOの方がいい場合も多い。例えばドライバやハードに近いプログラムなどだ。
771:仕様書無しさん
07/04/27 21:35:07
いや、だから
バカでも能書きたれて素人をだませる
という主張に見えた、んじゃないの？
依然としてなぜ仕様変更に強い設計が経験が浅くてもできるの、
と言う説明が無いんだけど？
772:仕様書無しさん
07/04/27 21:39:02
ヒューリスティクスって知ってるか？
773:仕様書無しさん
07/04/27 21:40:52
また自作自演でレベル低下かｗ
774:仕様書無しさん
07/04/27 21:42:20
「やってみたらそうだったから」って話？
んなもん聞いてないだろ、ふつー。
775:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:42:33
>733
宗教でも何でもない。
Pro*Cのソースをpostgres用に修正するのと、JDBCのソースをpostgres用に修正するのはどちらが楽か？
設定ファイルに暗号過機能を追加するに、C構造化ソースと、JavaOOソースではどちらが楽か？
やった事のある人なら良く分かるだろう。
>743
実現法方については、すでに具体的なコーディング方法を書いた。
OOなら熟練しなくても良いなど言っていない。その業務には熟練しなくてもいいが、OOの習得は必要。
前にも書いたが、OO方針に従って、1～2年のプログラミング経験が必要。
>745
「OOの方が低コスト」などとは言っていない。
変更を繰り返す場合は、トータル的にOOの方が低コストになるが、初回の作成や変更の少ないプログラム
では、構造化の方が低コストになる。
776:仕様書無しさん
07/04/27 21:45:08
言い訳開始。
777:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:51:05
>771
「経験が浅い」って言ってるのは「プログラミング経験」じゃなくて、「業務経験」。
業務経験が浅くてもOOなら変更に強いプログラムを作れると言ったが、
OOのプログラミング経験が浅くても変更に強いプログラムが作れるとは言っていない。
778:おじゃばさま ◆GxjxF3yEw6
07/04/27 21:55:17
>774
実例じゃなくて論理を知りたいのか？
長く言うと読まなそうなので短く言うと、抽象化されていると交換が容易なのと、継承を使うと親クラスには
修正が入らないので、ソースが壊れないからの2点が大きい。
779:仕様書無しさん
07/04/27 21:57:04
＞業務経験が浅くてもOOなら変更に強いプログラムを作れる
だから、それがなぜかがねえだろ？
だれも「プログラミング経験」の話なんかしてない。誰だ？
逆に「プログラミング経験」があれば業務経験が浅くても
OOなら分析・実装しやすい、のなら話はわかりやすいだろ？
それがテクニックじゃないのかよｗ
780:仕様書無しさん
07/04/27 21:58:42
怒濤のようなアナクロニズム
781:仕様書無しさん
07/04/27 22:02:08
>>777
大当たりおめでとうｗ
なんだかOO利点を挙げようと頑張っているけど1～2年の経験は1～2年の経験だ
OOに限らず何事も3年続けてやっとその世界の入り口にたどり着く
3年続けられないならその世界はあきらめろ
782:仕様書無しさん
07/04/27 22:03:05
もうちょっと話に説得力を持たすための勉強をしろよ、おじゃば。
もうOOとかJavaは習得したんだろ？いいかげん日本語のほうをちゃんとｗ
ま、がんばんなよ。
783:仕様書無しさん
07/04/27 22:15:03
パソ通時代のログ読んでるのかと錯覚した
784:仕様書無しさん
07/04/27 22:18:04
涙はこれで拭いとけ（k
785:仕様書無しさん
07/04/27 22:36:46
こんな所で自作自演して一体誰が得するんだろうと思った
786:仕様書無しさん
07/04/27 23:02:37
自己満足だろ
787:仕様書無しさん
07/04/27 23:29:50
ジェダイのライトセーバーと同じで
選ばれし者だけがオブジェクト指向を活用できる。
だから本当の意味で流行らないわけだ。
そのことに早く気づこうな。
788:仕様書無しさん
07/04/27 23:58:34
おじゃばよフォースを使え。
789:仕様書無しさん
07/04/28 00:07:22
オセロの石やポットの水をオブジェクトにしているようでは
フォースをまとうことは叶わぬわ。
790:仕様書無しさん
07/04/28 00:25:25
どうしてみんなページ制御が下手なの？
一覧表のページめくりぐらいちゃんと作れなきゃ。だめよ。
791:仕様書無しさん
07/04/28 00:36:54
恥ずかしくなっちゃった？
792:仕様書無しさん
07/04/28 00:39:06
ページの概念をクラスにする。汎用的に使える。
793:仕様書無しさん
07/04/28 00:57:24
えっと、>>724のおじゃばさんの文面で、ちょっとヘンだな～って思うところがあります。
OOだと変更が入れば入るほど、洗練されていく、とありますけど、
なぜそうなるんですか？
これはOOの考え方によるものですか？それとも言語仕様も関わりますか？
コーディングって量が少なければ少ないほど、
丈夫なプログラムになるはずなんで、変更が増えるほど良くなる、ってのが分かりません。。。
あと、これはちょっと違うかな～って思うのがあります。
C言語だとDBが変わると修正が大きくJavaだと小さい、とありますが、
各DB＋言語で使用するライブラリを、DBの違いを吸収した関数を用意しておけば、
関数の呼び先の処理が変わるだけで言語の違いは無いと思うんです。
C言語で、Accessの接続（ODBCあたり？）→Oracleの接続（orlon関数、、かな？）
に変わったとしてもDB_Connect()って関数を呼ぶように作っておけば、
修正はこの関数だけで済みますよね？
バインド変数を使う・使わないとかはDB仕様なのでちょっと変更は必要かもしれませんけど、
Javaでも同じですし・・・
これはオブジェクト指向か構造化かの違いではなく、
単にセンスや考慮の話だと思うんです。
最初の洗練される、ってのも同じ話かな～って思ってしまって・・・
やっぱりOO分かってないんでしょうね・・・
あぅぅ、長くてすみません；；
794:仕様書無しさん
07/04/28 01:02:09
あとですね、
OOだと仕様不明点があって作れる、とありますが、
本来のOOってのはそれを設計段階で吸収し終わって、
それをそのままコーディングできるのが強みだと思ってたんですが、
これもやっぱり間違ってますか？・・・
OOとXPのプロトタイプは別の話のはずなんで、
なんか話がいろいろなってる印象があって・・すみません。。
795:仕様書無しさん
07/04/28 01:15:27
そろそろ我々は設計はヒューリステクスだという事実を認めなければならない。
あらゆる設計に通用する手法などないということを認めなければならない。
最適解など存在しない。しかし、限りなくそれに近づけることはできる。
人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
保障などないということを認めること。それでも涙しながら助け合うこと。
時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
我々はクリプトナイトを抱えたスーパーマンだということを、そして簡単に
裏切れるということを認めなければ。コンピュータを相手にしながら、結局、
人間を相手にしているのだということを、認めるしかないのだ。
796:仕様書無しさん
07/04/28 01:23:13
最適解どうのこうのいうような事してないんだろｗ
797:仕様書無しさん
07/04/28 03:46:06
>>793
多分、モジュールとして分割されている事とOO的な分割の
意味を混同しているんだろうと思われる。
たしかに、バイナリレベルで切り離されていれば
呼び出し等は何でも一緒になる。
ペナルティとしては細かいやり取りには向かないって事。
この辺は難度の高いプログラムを組まないとなかなか実感できないと思う。
ソースが洗練云々はプログラムの部品化(つまり共通化)が進むので
開発工程そのものがテスト工程も兼ねる事になるので品質が高くなるという事。
この辺も難度の高いプログラムを組まないとなかなか実感できないと思う。
798:仕様書無しさん
07/04/28 03:47:02
もうちょっとだけ追加説明をしてみる。
10000ステップの処理に追加処理として10000ステップあったとする。
べたCだと極端な話だけど
10000ステップコーディングした後に
10000*10000通りのテストが待っていて細かくチェックするしかなくなる。
これがOOPだと
元の10000ステップを修正して＋10000以下のコーディングをした後に
元の10000＋10000以下のテストをする事になる。
たいした違いがないように思えるが
これを繰り返すとCだと飽和していくけどOOPだと逆に収束していく。
要はOOPはステップ数を横軸にした場合
コストが収束に向かう関数曲線を描くけど
非OOPは飽和に向かう曲線を描くって話。
799:仕様書無しさん
07/04/28 03:48:23
おじゃば氏の示している内容はOOPを使って開発経験者なら
誰でも感じる事でむしろ当たり前の事が書かれている。
入門的な書籍等でも大体同じ事は書かれている。
それに食いついている人は実際にはあまりOOPを
扱ってない開発者なのだろう。
800:仕様書無しさん
07/04/28 04:04:49
>10000+10000うんぬん
どうしてOOだとそうなるのか、説明よろしく。
経験んちゃら、とかじゃなくて「わからなくて質問」してるのがいるんだし、
書籍にあるんなら、どの本か教えてやれよｗ
誰も食いついてなんかいねーよ、説明してくれと言ってる。
801:仕様書無しさん
07/04/28 04:20:27
>>800
お前、無知なのに生意気だなw
プログラムの部品化(つまり共通化)が進めば
テストされる回数もあがるだろ。
プログラムの品質はテスト回数に比例してあがる。
大規模openソースと企業のソースで適当に調べればわかる。
書籍は俺もかなり前の事なので、よく覚えていない。
お前はいちいち読んだ本の名前を覚えているのか?
初心者向けの本を適当に読めば書いてあるだろw
802:仕様書無しさん
07/04/28 05:03:29
読んだ本くらい覚えてるだろ、普通。この本のココを読んだらわかった、とか。
それ以前にどうして構造化がだめでOOだと部品化が進むのよ？
そんなにいいもんなら以下スレタイ、という話じゃないのか。
で、それは「どいつもこいつもOOを勉強しないから」とか
「どれだったか本に書いてあるもん」とか「おっきなとこでやってるから」
「やってみれば誰でもわかるよ」位の話を長文で技術用語(ﾌﾟ垂れ流しでやるから
「それってなんて宗教ｗ」「どこの壺売りよｗ」言われるんじゃないか。
803:仕様書無しさん
07/04/28 07:04:24
レベルの低い負け犬が30年前の概念を
独りで弄って悦んでる状態か
どうしようもねぇな
804:仕様書無しさん
07/04/28 07:05:52
> 食いついている人は実際にはあまりOOPを
> 扱ってない開発者なのだろう。
局所化と隠蔽(インタフェース化)
という二言で済む話を延々やってろキチガイ
805:仕様書無しさん
07/04/28 07:10:51
＋αがあるだろ
部品化がOOの特徴とかいう陳腐な＋αだがｗ
806:仕様書無しさん
07/04/28 07:25:22
>人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
>保障などないということを認めること。それでも涙しながら助け合うこと。
>時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
元々頭が弱い奴は、プログラミングの現場に来なければいいのに、と思う。
807:仕様書無しさん
07/04/28 08:19:55
局所化と隠蔽だけで行き着くところはオブジェクティブスパゲッティｗ
808:仕様書無しさん
07/04/28 08:44:47
ＧＷ中も糖質は２ちゃん張り付きなのか
809:仕様書無しさん
07/04/28 09:02:33
感性を形にできる。それがオブジェクト指向。
感性の良し悪しが、そのまま形になる。それがオブジェクト指向。
810:仕様書無しさん
07/04/28 09:07:01
文よりも図の方が直感的で分かりやすい。
つまり構造化よりもオブジェクト指向の方が直感的で分かりやすい。
811:仕様書無しさん
07/04/28 09:15:21
まずは構造化モデリングが正しく行えるように勉強しなさい。
オブジェクト指向はそれが出来るようになってからな。
812:仕様書無しさん
07/04/28 09:29:57
達人を目指すならアセンブリコードを学ぶこと。
コンパイラの勉強をすればアセンブリコードの知識も身に付くだろう。
グローバル変数、ローカル変数、スタック、ヒープメモリやアドレッシング、割り込み、スレッドなどなど
基本的な概念が正しく身に付く。
そうすることにより、今まで見えなかったり、感じなかったことが驚くほど分かるようになる。
オブジェクト指向もな。
813:仕様書無しさん
07/04/28 09:35:12
ソフトウェア設計はエンジン設計と同じだ。
部品一つ一つに情熱を注げ。美しさを追求しろ。
814:仕様書無しさん
07/04/28 10:04:45
>>812
やっぱドラゴンブックがいいの？
815:仕様書無しさん
07/04/28 11:24:10
この辺りから入門しなさい。
・URLﾘﾝｸ(www.atmarkit.co.jp)
・スモールコンパイラの制作で学ぶプログラムのしくみ
816:仕様書無しさん
07/04/28 11:51:49
ドラゴンはある程度分かってからな。
817:仕様書無しさん
07/04/28 12:05:12
こないだ中田育男教授の最終講義があったね。
「コンパイラとつきあって40年」
818:仕様書無しさん
07/04/28 12:12:12
入門用
・いまどきのプログラム言語の作り方
819:仕様書無しさん
07/04/28 12:35:39
いちおうマジレスしとくと
コンパイラの勉強なんてのは学生時代に済ましとくべきものだよ。
820:仕様書無しさん
07/04/28 12:37:48
笑えるじゃないか。
現在進行形でコンパイラのおべんきょしてる
40過ぎのじじぃが知ったかぶってる姿
821:仕様書無しさん
07/04/28 12:38:56
おまいするどいなｗ
822:仕様書無しさん
07/04/28 12:44:15
いちおうマジレスしとくと
オブジェクト指向の勉強なんてのは学生時代に済ましとくべきものだよ。
823:仕様書無しさん
07/04/28 12:48:06
うーんとね、
おいらの場合は学部３年の計算機実習で
その記事と同じ電卓コンパイラ＆VMやったね。
センセはソフトウェア・ツールの翻訳もやってた
木村研出身のひと。
再帰下降文法でうんちゃらかちゃらなんて恥ずかしいんで、
当時ちょこっといじってたPrologライクに、
演算子の優先順位と結合性決めて、演算子順位文法で提出したな。
趣味ではあとLisp VMとLisp コンパイラ。アーカイブっつう雑誌見て手作り。
Scheme VMは、Dylanのひとが作ってたX Schemeでおべんきょ。
Smalltalk VMあたりは・・・うーん・・・当時はVM仕様は判っても、
その上にのっかるImageがどうしようもなく入手困難だったから諦めたなぁ。
Smalltalk/V と GNU Smalltalk で雰囲気を想像する、という・・・
824:仕様書無しさん
07/04/28 12:52:01
いや思い違いか、
学部二年だな、そんな初心者勉強は。
学部三年ともなると専門教育が忙しくなって、
そんな他分野のお遊びに首突っ込む暇はなくなる、という
825:仕様書無しさん
07/04/28 12:53:32
>>820
50後半なんだな。
826:仕様書無しさん
07/04/28 12:55:08
誰が？
827:仕様書無しさん
07/04/28 13:01:07
いずれにせよ、向学心旺盛なのは誉めるべきだけど、
その手の専門課程では習ってて当たり前の事について
ハッタリこいてウダウダ言い出すと新人さんに舐められるよ
828:仕様書無しさん
07/04/28 13:05:58
でも、このスレでオブジェクト指向についての理解度を見てると
専門課程で何を学んできたのか疑問？？？
829:仕様書無しさん
07/04/28 13:07:28
マジッすか？
うちの大学の情報は院行かないとオブジェクト指向までやらないみたいだよ
それともプログラミング関連なんて独学でやってて、学部二年までにやっとくべきって事？
確かに中高ぐらいでC++やJavaの機能駆使して実用アプリつくりまくってる人たちが居ることから
考えるとそれぐらい出来て当たり前という気もするけど
830:仕様書無しさん
07/04/28 13:07:52
そうね。それはね。本で学んだ表層の知識だけで理解したと勘違いしてるだなぁ。
831:仕様書無しさん
07/04/28 13:10:02
技術を極めるには、師の元でOJTが一番だろ。
832:仕様書無しさん
07/04/28 13:11:21
>>828
それはお前の説明が基礎的な部分で変だから
とても低いレベルの突っ込みが入っているだけだろう。
レベルを高くしたいなら、基礎的な部分の説明は省いて
もっとレベルの高い話に専念するというのも一つの手だ。
まあお前が説明が下手糞なだけで、きちんとした基礎ができている
という仮定の上の話だがｗ
>>830
意味不明抽象煽り乙
これだから頭が悪い奴は
833:仕様書無しさん
07/04/28 13:11:39
マスターとパダワン。
834:仕様書無しさん
07/04/28 13:11:47
完璧に理解せんでもOOPの恩恵に肖れるだけで十分だと思うけど
理論ってそういうもんでしょ？
何を以って理解したとするのか
835:仕様書無しさん
07/04/28 13:12:10
ここまでのまとめをオブジェクト指向でよろ
836:仕様書無しさん
07/04/28 13:13:39
そんな下らない話題は誰も興味を持たない。
837:仕様書無しさん
07/04/28 13:13:42
ムキになるなよ。勉強不足が伝わってくるよｗ
838:仕様書無しさん
07/04/28 13:14:25
なんだ今日の粘着当番は知能が劣悪な池沼の方か
839:仕様書無しさん
07/04/28 13:15:06
ロジカルシンキングと同じ流れだな
誰でも無意識で行ってる事に関心を無駄に注いで、意味無く難しくみせてるだけ
もっと力抜けよ
840:仕様書無しさん
07/04/28 13:15:54
OOPの恩恵ってか。OOPで迷惑掛けられてる方が圧倒的に多いちゅうの！
841:仕様書無しさん
07/04/28 13:16:03
池沼の書き込みはひたすら無意味
バカなんだから書き込みやめればいいのに
842:仕様書無しさん
07/04/28 13:17:42
それは恩恵に気づいてないだけだろ
短所って長所より目立つもんだし
843:仕様書無しさん
07/04/28 13:19:00
>>842
学生さんですか？
仕事はそんなにあまくないのよ。
844:仕様書無しさん
07/04/28 13:20:37
50代後半でこのグダグダかよ
845:仕様書無しさん
07/04/28 13:21:24
例えば、Gap Bufferを知ってる方居ますか？
もし知らなかったら、もっと勉強したほうがいいよ。
846:仕様書無しさん
07/04/28 13:23:30
なんでエディタのデータ構造をそんな自慢したがるんだ
847:仕様書無しさん
07/04/28 13:24:30
一生懸命、検索中。。。
848:仕様書無しさん
07/04/28 13:25:43
いやさ、なんでそんな瑣末な知識を自慢しようとしてるの？って聞いてるの。
Emacsの構造に興味を持った事がある人なら大抵知ってるだろ
849:仕様書無しさん
07/04/28 13:25:52
>>843
詳しく
趣味レベルのアプリだとCからC++に移行して
かなりバグが減ったんだけど、その程度のメリットなんて雀の涙
ってほど業務用ソフトウェアってヤバイという事ですか？
850:仕様書無しさん
07/04/28 13:26:31
OJTでダメな先輩に洗脳されちまった廃人のテクニック自慢なんて
えてしてそんなレベルだ
851:仕様書無しさん
07/04/28 13:29:08
ここの記述は謎だな。
URLﾘﾝｸ(www.kmonos.net)
「時々「行=GapBufferOf文字、文書=LinkedListOf行」で使う、 という解説を目にすることがあるんですけど、 その構成は正直意味がわからんです。」
とか書きながら、説明の方はしっかり行＝GapBufferOf文字になっているというグダグダさ加減
852:仕様書無しさん
07/04/28 13:33:14
>>851
おまいが理解できていないことに気づかないか？
853:仕様書無しさん
07/04/28 13:34:03
>>848
検索乙
854:仕様書無しさん
07/04/28 13:36:21
なんだ理解できてない奴が表面上煽ってるだけか。
バカの相手して損したぜ
855:仕様書無しさん
07/04/28 13:39:42
ＧＷは楽しいね
856:仕様書無しさん
07/04/28 13:48:02
古い話題になるが
羽生田さんのAOSD解説はなかなか的を得ていたな。
ヤコブソンがユースケースをアスペクトと解釈してうんたらかたら。
違和感はない。
M$萩原さんのSoftware Factory解説の中のサブジェクト指向解説、
斜め読みした時はなかなかいい線行ってると思ったんだけど、
よくよく読んでみると何を言ってんだかわかんねぇな、相変わらず。
彼の話はいつも、断片的には素晴らしい事を言っているみたいな印象を
与えるんだけど、全体構造が不安定っつうか、全体構造の肝が
細部の仔細な事柄に依存していて、正しいかどうか判定し難いという・・・。
857:仕様書無しさん
07/04/28 13:52:16
萩原氏流のサブジェクト指向っつのは、
OOのドメインクラス＋FDDのフィーチャー
みたいな感じで不変部分と可変部分を分けましょうという話。
オブジェクト指向の業務システムは
処理がオブジェクトなんだぁ～！！！！なんて負け犬よりは
よっぽどまともに見える。
858:仕様書無しさん
07/04/28 14:02:29
楽しくないよ。
859:仕様書無しさん
07/04/28 14:10:13
マトモである事の方が重要だ
860:仕様書無しさん
07/04/28 14:23:12
楽しくてマトモであることが大切
861:仕様書無しさん
07/04/28 14:33:47
>>802
俺は覚えてない。
どうでも良いことはすぐに忘れるので
内容だけが頭に残るだけ。
それもそのときに重要と感じた部分以外は忘れてそうだけどな。
本のタイトルと情報のリンクは長くても一年前位までだな。
同じ内容が複数の本に載ってたりするのが
デフォルト状態だから覚える事に意味を感じない。
862:仕様書無しさん
07/04/28 14:37:28
どうでもいい話ばっかだな
863:仕様書無しさん
07/04/28 14:46:10
結局オブジェクト指向は、デザインパターンのセンスだけ修得すれば桶？
864:仕様書無しさん
07/04/28 14:46:35
>>804
数回書き込んだだけだろ。
食いついてくんな、キチガイ。
早く病院でカウンセリングを受けろYO!!
>>805
＋αを認めてるなら文句言うなYO!!
OOは魔法じゃないんだYO!!
>>813
同意。
別に俺はOO厨な訳じゃないので書いておく。
プログラムは効率のよい感じに書いてあれば
非OOPでも別に良いと思ってる。
それがOOPだといくらかしやすいよっていう簡単な話。
だから当然だけど非OOPで書き殴ったような糞コードを
書いてる人がOOPで書いても問題は解決しない。
865:仕様書無しさん
07/04/28 14:47:45
オブジェクト指向とは、処理対象に処理方法を割り振る方法論。
サブジェクト指向とは、オブジェクト指向を前提としつつ、
処理がオブジェクトに分散してしまう欠点を克服するために、
処理の主題(サブジェクト)に沿った処理記述を再導入しようという試み。
オブジェクトとサブジェクトは、AOPのweavingによって関連付ける。ｗ
866:仕様書無しさん
07/04/28 14:49:34
と、まあコレくらいの話ができないと21世紀らしくねぇんだな。
867:仕様書無しさん
07/04/28 14:51:07
>>865-866
そのレベルの話はもう2～3年前からさんざん行われているだろ。
このスレだけ30年前にタイムスリップしてるようだが
868:仕様書無しさん
07/04/28 14:51:44
サブジェクト指向ってコンサルが入れ食いしそうなネタだね。
おもしろそう。