【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6

1 ：仕様書無しさん：2007/03/29(木) 01:28:08

過去スレ

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
http://pc11.2ch.net/test/read.cgi/prog/1173529414/

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5
http://pc11.2ch.net/test/read.cgi/prog/1174746731/

スルー推奨ワード（相手をした場合は荒らしとみなされます）
電球、たかひろ

　このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
　なので設計だけ、実装だけといった縛りは特にありません。
　設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。

　いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
　書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。

2 ：仕様書無しさん：2007/03/29(木) 01:30:07

乙！

3 ：仕様書無しさん：2007/03/29(木) 01:30:39

JAVA案件て火噴いてるの多いがなんで？

4 ：仕様書無しさん：2007/03/29(木) 01:30:40

　　　　☆コテは書き込み禁止

5 ：仕様書無しさん：2007/03/29(木) 01:32:00

>>3
オブジェクト指向で作ることを目的にしちゃってるから。本来手段なのに。

6 ：仕様書無しさん：2007/03/29(木) 01:33:10

>>3
業務系案件のほとんどがJavaだから

7 ：仕様書無しさん：2007/03/29(木) 01:33:47

OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ
あと、できればマニアックな専門用語ではなくそれなりに分かる言葉で挙げていきましょ

１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから
６．手段であるはずのオブジェクト指向なのに、OOで作ることが目的になったPJが多いから
７．言葉の洪水でやる気が無くなるから
８．大規模PJにより各担当箇所が結局OOではなく機能分岐してしまうから
９．偽装請負による技術者の定着性の無さや玉石混交化のため
10．DBを使う現場が多い中でトランザクションはOOと相性が悪いから
11．学習途中で諦める技術者が多いから

8 ：仕様書無しさん：2007/03/29(木) 01:36:37

高弘、スレ立て乙

今回はpart1やpart2のように、延々と長文で自作自演の押し問答すんなよ、
あれやると、コミュニケーションが成立しなくなるから迷惑だ。

9 ：仕様書無しさん：2007/03/29(木) 01:38:47

スルー推奨ワードを相手にしないようにお願いします
相手にした場合も荒らしとみなされます

10 ：仕様書無しさん：2007/03/29(木) 01:39:54

>>3
・Javaで基幹系大規模開発して名を上げようなどという高弘のように
　無謀なバカが世の中にはわんさと居るから。
・Javaどころかオープン系の構築すらおぼつかないold COBOLerが
　足を引っ張るから。

11 ：仕様書無しさん：2007/03/29(木) 01:40:35

もう、前スレ継続審議中のオセロ設計無し？

12 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/29(木) 01:41:14

１２・　ＯＯ厨の能力と態度がアンバランスなのを見てああはなりたくないと思う

13 ：仕様書無しさん：2007/03/29(木) 01:41:22

>>8
俺も長文自作自演禁止に賛成。
自作自演中になんか発言すると、思い切りスルーしてくるから不愉快だ

14 ：仕様書無しさん：2007/03/29(木) 01:43:12

OOを理解できない理由

・高弘が大規模プロジェクトで似非オブジェクト指向を広めるから、
　プロジェクトが失敗し、それに関わった人々がホンモノのOOまでも嫌いになる

15 ：仕様書無しさん：2007/03/29(木) 01:46:06

>>11
オセロは詳細設計っぽくなってきたくね？

16 ：仕様書無しさん：2007/03/29(木) 01:47:14

>>10
いきなり大規模開発にJava突っ込むのは、
泳げもしない奴をいきなり海に突き落とす位に無謀だ。
まずは新規サブシステム１個程度から始めて、
長期的に徐々に浸透させていくのが正道。
それを許さない状況があれば、その仕事は請けるな。

17 ：仕様書無しさん：2007/03/29(木) 01:49:55

>>15
あの設計はほとんど俺だけどな。
夜中に文章だけ書いてきて「設計でござい」ってしたり顔してた前ｽﾚ193には
ホント絞め殺したろうかと思った。
・・・まあ時間見つけてクラス図とシーケンス図描いてやったけどな。AAでｗ

18 ：仕様書無しさん：2007/03/29(木) 01:50:56

>>7　のはよくできてるんで補完してって
建設的な話をしてけばいいんじゃね？

19 ：仕様書無しさん：2007/03/29(木) 01:52:24

　　　　　　　　☆お約束
　　　　　　　　　　高弘を相手にしないようにお願いします
　　　　　　　　　　相手にした場合も荒らしとみなされます

20 ：仕様書無しさん：2007/03/29(木) 01:52:34

>>15
もまぃえらいよ、いやホントに
素直に感心したし
ただ寝不足には気をつけないかんばい

21 ：仕様書無しさん：2007/03/29(木) 01:53:23

>>20
おい志村、志村、アンカーアンカー。(棒読み

22 ：仕様書無しさん：2007/03/29(木) 01:53:35

19 名前：仕様書無しさん[sage] 投稿日：2007/03/29(木) 01:52:24

　　　　　　　　☆お約束
　　　　　　　　　　高弘を相手にしないようにお願いします
　　　　　　　　　　相手にした場合も荒らしとみなされます

修正。

　　　　　　　　☆お約束
　　　　　　　　　　高弘関係者と電球関係者を相手にしないようにお願いします
　　　　　　　　　　相手にした場合も荒らしとみなされます

23 ：20：2007/03/29(木) 01:54:30

ぶｗ
アンカーミスったｗ
>>18な。

24 ：仕様書無しさん：2007/03/29(木) 01:54:50

問題は高弘の扱いだな
香具師がまた匿名で中傷活動を始めなければいいんだが

25 ：20：2007/03/29(木) 01:55:40

うｗｗ
さらにやらかしたｗｗ
>>17だった
今夜の梅酒はキクなあ

26 ：225：2007/03/29(木) 01:55:49

再訂正
　　　　　　　　☆お約束
　　　　　　　　　　高弘と豆蔵関係者を相手にしないようにお願いします
　　　　　　　　　　相手にした場合も荒らしとみなされます

27 ：仕様書無しさん：2007/03/29(木) 01:56:55

電波2ch.cgiみたいな具合だな。
ところどころ高弘風味になってて

28 ：仕様書無しさん：2007/03/29(木) 01:58:54

自演必死な奴がいるな

29 ：仕様書無しさん：2007/03/29(木) 02:02:49

>>28
自作自演乙。
おまえ暇なんだな

30 ：仕様書無しさん：2007/03/29(木) 02:03:04

>>17
お前さん設計だったのか、設計を公表するときはトリ付きでやったほうがいいな。
普段はトリなしで、必要なときはトリをつけるいいかも(設計者発言と判る）。

31 ：仕様書無しさん：2007/03/29(木) 02:10:05

>>30
頼むから下らない入門者用設計図で俺の手を煩わすな。
今後はAAEdit使って自分で書け
　http://aaesp.tripod.co.jp/

あと、分析にしろ設計にしろ実装にしろ、
優劣はあるかもしれないし、その比較や議論も大事だけど、
次の事を守ってくれ。

1. 問題の要件定義を明確にしてから、分析/設計/実装に入る
2. 他人を無理に説得しようと思うな。回答は何通りでも有り得る。
　ただ、その回答の差が、どうして発生したかを考えて議論しろ。
　
　　

32 ：仕様書無しさん：2007/03/29(木) 08:45:10

>>31
結局自分で書いたんだから「俺の手を煩わすな」もなにも無いだろ、
という突っ込みどころはあるけど、
書きたい奴はAAEditな。

33 ：仕様書無しさん：2007/03/29(木) 08:49:38

俺はobject指向が理解できないんじゃなくて
コードが遅くなるからつかわないんだが。

34 ：仕様書無しさん：2007/03/29(木) 09:27:49

そもそもそのへんの会社や派遣プログラマに、積極的に良い物を作りたいいう動機がない。
OOPやアジャイル開発は、優れたアプローチっていうか、俺らからしたら常識なんだけど、
ゴミプログラマは勉強する手間より小手先で終わらせることを選ぶ。
理由は覚えるのがめんどくさいから。
ドラゴン桜の「目の前に川があって向こう岸に渡りたいときどうするか」っていう話。
凡人はずぶぬれになって渡る。東大生は周辺を探してぬれずに渡る方法を探す。
凡人は探す方が手間だしめんどくさいと思う。
東大生はぬれずに渡る方が楽する方法だと思う。
ホントに東大生がそうかどうかは別としてPGには当てはまる。
OOPやアジャイルなんかまわりくどいし覚える時間が手間だし開発遅くなるってのは、
まさにずぶ濡れで川渡る奴。

35 ：仕様書無しさん：2007/03/29(木) 11:42:07

ちゃんと教育せずに現場に放り込むのやめれｗ

36 ：仕様書無しさん：2007/03/29(木) 11:52:49

>>34
とFランク大出身者が申しておりますｗ

37 ：仕様書無しさん：2007/03/29(木) 12:07:49

>>36
Fランク大ってどこよ

38 ：34：2007/03/29(木) 12:19:02

う、確かにFランクだけどさ・・・プログラムはできるお。
一PGとしての結論は、
どんな優れた設計手法・開発手法があろうが、やる気のない奴はそれに従わない。
これは絶対不動。だからチーム開発でデスマは絶対になくならない。
自分がデスマらないための一番の方法は独立して無能PGと一緒に仕事しないこと。

39 ：仕様書無しさん：2007/03/29(木) 12:23:34

おじゃばさま、なんでこっちではコテ付けないの？
あと、あっち↓
　　http://pc11.2ch.net/test/read.cgi/prog/1174837272/

毎日毎日スローモーションでたらたら同じ質問繰り返されてもラチあかんから
さっさと質問出してくれ。

40 ：仕様書無しさん：2007/03/29(木) 12:29:30

今から勉強するならJavaと．NET（C#かVBあたり）どっちがええかいな。
一応コボル系PGッス。（OO可能なメーカー独自言語）

あと、デザインパターンを勉強したほうがいいのかな？

41 ：仕様書無しさん：2007/03/29(木) 12:31:17

>>38

>>35 ：仕様書無しさん：2007/03/29(木) 11:42:07
> ちゃんと教育せずに現場に放り込むのやめれｗ

こっちもスルーせずに回答したらどうよ？
結局自分に都合の悪い現実は見ずに、妄想垂れ流してるだけだろお前

42 ：仕様書無しさん：2007/03/29(木) 12:32:04

初心者にデザパタを押し付けて失敗するのは高弘パターン

43 ：仕様書無しさん：2007/03/29(木) 12:35:51

406 名前：おじゃばさま投稿日： 2007/03/26(月) 19:27:28
　初心者にデザパタ覚えろと言う偽コンサルは
　攻撃対象なので覚悟しておいた方がいい。

433 名前：仕様書無しさん [sage] 投稿日： 2007/03/26(月) 20:11:08
　> 初心者にデザパタ覚えろと言う奴
　
　これは　元豆蔵似非コンサル高弘の発言だな。

487 名前：仕様書無しさん [sage] 投稿日： 2007/03/26(月) 21:30:37
　>>471
　あれには俺もビビった。
　
　仮にも金払ってプロを雇ってて、
　そんな低レベルな勉強会に時間を費やすとは何事か、と。
　案の定、勉強会は大盛下がり大会。
　直後に下請けからクレームが入って、勉強会は取りやめになった。
　
　やっぱね、それくらい知ってて常識だよな、
　と思ってたら、後で衝撃の事実。
　
　その「金払って雇ってるプロ」連中、
　デザパタ使ってる振りしてただけで、
　実は全然使いこなせてない。
　
　そんな現場にデザパタ持ち込むなよ～ってオチ

44 ：仕様書無しさん：2007/03/29(木) 12:42:00

>>43
GoFのデザインパターンは、
Smalltalk～初期C++時代の遺物。
出版当時からだいぶ様変わりしたC++や、
出版後に出現したJava, C# とは
大きなセマンティック・ギャップがある。

45 ：仕様書無しさん：2007/03/29(木) 13:11:20

>>41
教育受けてないからできませんなんて言い訳だよ。できないからできないだけ。
バージョン管理してテスト書こうって言ったって派遣PGの寄せ集め集団がやるわけない。
お前こそ現場知ってるのかよ。

46 ：仕様書無しさん：2007/03/29(木) 13:18:13

>>45
　>>35に直接言えバカ

47 ：仕様書無しさん：2007/03/29(木) 13:18:32

セマンティック・ギャップなんかねぇょ。

48 ：仕様書無しさん：2007/03/29(木) 13:31:15

初心者にデザパタを押し付けて失敗するのは高弘パターン

49 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/29(木) 22:44:32

まいったぜ今日はデスマーチ残業だった。

50 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/29(木) 22:50:14

地雷原を掘り返してしまったんだな。
ちょっとした仕様変更をやろうとしたら次から次から　汲めども尽きないバグの山。
元に戻して運用で対処してもらうことにした。
コマンドパターン厨の作品だ。

51 ：仕様書無しさん：2007/03/29(木) 23:12:41

あぼーん表示が増えていく増えていく

52 ：仕様書無しさん：2007/03/29(木) 23:25:25

オブジェクト指向を勘違いして石コロばかり作るから失敗するのだよ。
オブジェクトは物ではなくて概念なんだなこれが。

53 ：仕様書無しさん：2007/03/29(木) 23:25:59

つまらん

54 ：仕様書無しさん：2007/03/29(木) 23:33:10

ネ申の考え方なんだから誰でも理解できるわけではないよ。
そこんとこ早く気づかなきゃ。

55 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/29(木) 23:38:28

コマンドパターンの多用は　ＧＯＴＯ文スパゲッティに戻ってしまうことを指摘して置こう。
command.exec() の中を見るとまた　command.exec() が書いてある。
なんだかわからん。

56 ：仕様書無しさん：2007/03/29(木) 23:38:35

自然言語処理やってる俺の別人格の中の人が、
品詞句に着目したオブジェクト抽出法と似たような話で

> とりあえず、ルネ・トムの「ことばのカタストロフィー」は、
> 言語モデル面では「格フレーム」もしくは「概念依存 (Conceptual Dependency)」に相当するアイデア
> を提供していると理解しました。
> もっとも、時空間プロセスのカタストロフィー理論的性質が、人間の時空間認識に大きな影響を与え、
> 最終的に「動詞と、動詞に付属する名詞の型」を類型化する、という説は飛躍があるような気がしました。
> 複雑系の話は興味深いのだけど、本当に言語理論と関係あるのかなぁ？

ってゆってた。
あと、格フレーム辞書見ると、動詞を中心にしてそこに(文法的に)付いてくる品詞/単語が分類されてて、
あれもソフトウェア・パターンに流用できねぇのかなぁ？って、ゆってた。別人格の中の人が。

57 ：仕様書無しさん：2007/03/29(木) 23:40:27

>>55
そうそう。まるでアセンブラ時代に戻ったような感じ。

58 ：56：2007/03/29(木) 23:43:33

Object⊃概念
概念⊃動詞、副詞
概念⊃名詞、形容詞

なんてやってったら、前者は手続き型、後者はデータ指向に近づくだけでしょ。
OOは、両方見てく主義。
だから、例えば「動詞と単語の結合パターン」なんかをネタにして展開してった方が
まだマシじゃねぇの、と言いたかった。

59 ：仕様書無しさん：2007/03/29(木) 23:54:03

あぁーウッゼェ

「Commandパターン・スパゲッティ」
それはクロージャ導入で解決する

60 ：仕様書無しさん：2007/03/30(金) 00:02:03

>>59
次に来るのは、
「クロージャ・スパゲッティ」
だけどなｗ

61 ：仕様書無しさん：2007/03/30(金) 00:09:06

なぜオブジェクト指向で作るの？ってところから始めないとね。

62 ：仕様書無しさん：2007/03/30(金) 00:09:40

人間買ってでもするのがクロージャってうちの母ちゃんがゆってた。

63 ：仕様書無しさん：2007/03/30(金) 00:13:27

かあちゃん、おれ外で違う女買ってもうた。

64 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 00:16:51

ＯＯちゅは９９％マルチスレッドプログラミング理解して無いからな。

65 ：仕様書無しさん：2007/03/30(金) 00:24:07

釣られるかよ

66 ：仕様書無しさん：2007/03/30(金) 00:27:42

この板はスレッドセーフではありません。
書き込む際は注意してくださ&ﾕｸ|1ﾒ・ﾇ$ﾙ・ｳ &l・

67 ：仕様書無しさん：2007/03/30(金) 00:43:54

>>66
ｽﾏｿ、書き込み被った

68 ：仕様書無しさん：2007/03/30(金) 00:45:33

釣り針が全部あぼ～ん表示されるので、
安全といえば安全。退屈といえば退屈。

話が通じる面白い奴こねぇかな

69 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 00:48:50

単なるスレッドセーフとマルチスレッドプログラミングはまるで違うもの。
入門者向けに「スレッドセーフ」を説明してる本があるけど、本格運用のでそんなの使ったら死ぬ。

70 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 00:50:22

オブジェクトを禁止ワードにしてるのか

えらいぞ

71 ：仕様書無しさん：2007/03/30(金) 01:00:51

バカが独りで暴れてる

72 ：仕様書無しさん：2007/03/30(金) 12:43:57

なんでこんな糞スレがもの凄い勢いで消費してるのか分からん。
オブジェクト指向やらなんだか知らないが、そういう物好きな人が増えたのか？

73 ：仕様書無しさん：2007/03/30(金) 12:48:32

>>72
オブジェクト指向の話をしているように見えるのか？

74 ：仕様書無しさん：2007/03/30(金) 13:17:39

オブジェクト指向を隠れ蓑にした世代間対立スレだろこれ？
技術者なんだから専門分野ができればそれでいいと思うんだけど。

75 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 19:04:18

専門分野に入れなかった人が落ちるところがＯＯ

76 ：仕様書無しさん：2007/03/30(金) 19:13:26

じゃCOBOLずーっとやってる人は元々こぼれですな

77 ：仕様書無しさん：2007/03/30(金) 19:14:16

宇宙開発からOOにわざわざ移った人は吹きこぼれか

78 ：仕様書無しさん：2007/03/30(金) 19:20:40

ココ電柱は専門分野から落ちこぼれてOOでも落ちこぼれか
くよくよすんな

79 ：仕様書無しさん：2007/03/30(金) 19:41:19

コボラーはSAPに行けばいいんだ。
COBOLに似た言語でOOも可能だぜ。

80 ：仕様書無しさん：2007/03/30(金) 20:09:36

いや、そこは突っ込む所じゃなくて
元々コボラ（ry

81 ：仕様書無しさん：2007/03/30(金) 20:20:26

意外と、ココ電ファン多いんだな、
たかひろファンと違い、ココ電ファンはまったりしてるな。
俺、思うに、ココ電の生息地って関西方面じゃね？　ね>>ココ電

82 ：仕様書無しさん：2007/03/30(金) 20:22:29

関西って仕事あるの？

83 ：仕様書無しさん：2007/03/30(金) 20:27:31

ITの仕事ならいくらでもあるぜ。
もちろんCOBOLの新規案件も
コボラー足りないらしい。

84 ：仕様書無しさん：2007/03/30(金) 20:57:01

age厨うぜぇ

85 ：仕様書無しさん：2007/03/30(金) 20:59:01

ひろたかくんのストーカじみた求愛行動で
どっかのバカの貞操が危険状態ですｗ

86 ：仕様書無しさん：2007/03/30(金) 21:33:28

http://www.youtube.com/watch?v=oXux5e7SKV8
全然関係ないけど、東京都も大変だな

87 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 21:56:48

浅草在住

88 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 21:57:43

昨日は自動書記で書いたソースがバグってた。
今日上司の人にみつかってしまった。

89 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 21:58:55

コボラーは年収１０００万ですよ。
そこらの貧しいＯＯ厨が何を勘違いしてるんだか・・

90 ：仕様書無しさん：2007/03/30(金) 22:16:34

87 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん

88 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん

89 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん

91 ：仕様書無しさん：2007/03/30(金) 23:18:34

>>87
なにー、浅草の浅草寺境内か、いいな、川で花見や花火楽しめて、休みは花やしきか
ま、浅草ならCOBOL大好き、OO嫌い解るな
>>86　ワロタよ　ココ電一票入れてやれ

92 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/30(金) 23:25:42

花やしきは今有料ですよ。入場料

93 ：仕様書無しさん：2007/03/31(土) 00:39:18

花やしき子供の頃よく行った。入場料無料の頃。
そして大人たちは場外馬券場へ…

94 ：仕様書無しさん：2007/03/31(土) 07:22:04

閑話休題
そろそろ本題のオブジェクト指向について

95 ：仕様書無しさん：2007/03/31(土) 08:15:36

真面目な話なんだが、
UMLを理解＋利用せずにオブジェクト指向分析・設計やろうとしてるから
失敗プロジェクトが多発してんじゃまいか？

ただ、UMLを「技術者だけ」が理解しても客がわかんねーなら説明につかえねーしな
UMLを利用しないからプロジェクトは失敗するし、
客にUMLで説明できないからプロジェクトは失敗するし

・・・駄目じゃん

96 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/31(土) 08:54:17

ＵＭＬはシステムの設計に必要なのではなくて
オブジェクト指向に必要なんだろ。
自己完結哲学にすぎない。
仕事ふやすなよ。

97 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/31(土) 08:58:02

ああ、そうだ
ＯＯのシーケンス図は通信やハード設計からのパクリだから。
知らないやつが要るだろうから教えておく。

98 ：仕様書無しさん：2007/03/31(土) 08:59:15

相変わらず頭バカだな

99 ：仕様書無しさん：2007/03/31(土) 09:10:08

荒らしはスルーしましょう

100 ：仕様書無しさん：2007/03/31(土) 09:14:26

>>95
UML使わずにOOも何も無い
客側の担当者には前段で教えるしかない
それがSEの仕事

101 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/31(土) 09:17:25

そうか　ショックだったか。
広い分野を知ってればＯＯなんか朴理だらけで、オリジナルがぜんぜんなくて
呼び名を変えただけなのも多く、根拠の無い効能書きしか残らないことが判るんだが、
まずこれを初心者に伝えて無かったな。
初心者に引っかかるやつが多いのはそういうわけだ。
どうやって伝えるかな。

102 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/31(土) 09:18:55

プロの技術者と初心者では　ＯＯの説明読んでも受け取り方がぜんぜん違うんだよ。

103 ：仕様書無しさん：2007/03/31(土) 09:19:58

外資系と一緒に仕事したとき言葉は分かんないけど
UMLが理解できたときはちょっと感動した

104 ：仕様書無しさん：2007/03/31(土) 09:26:46

　♀
♂

105 ：仕様書無しさん：2007/03/31(土) 09:44:51

たかくんはおまんこがだいすき

106 ：仕様書無しさん：2007/03/31(土) 10:46:34

さて、花見に行ってくるか
咲いてるかな～

107 ：仕様書無しさん：2007/03/31(土) 13:09:16

伊賀知己がここにこなくなってよかったね。平和が一番。

108 ：仕様書無しさん：2007/03/31(土) 15:01:08

俺だったら、オブジェクトをやる前に、
いまや使うだけと化した原点に帰って、
ＴＰモニタのソースでも読むぜ

109 ：仕様書無しさん：2007/03/31(土) 15:18:16

ＴＰモニタのソース読むと何かいいことあんの？

110 ：仕様書無しさん：2007/03/31(土) 17:02:32

まともなTPモニタのソースってオプソで出てたっけ？
TPモニタ呼出API、TPモニタ・サービスAPI 位しか見た覚えないけど。

111 ：仕様書無しさん：2007/03/31(土) 17:11:35

国内だとHくらいか
分散TPモニタのソースが
最新状態にメンテされてるのは

112 ：仕様書無しさん：2007/03/31(土) 17:54:49

>>102
STLとかBoostは糞でFA？？

113 ：仕様書無しさん：2007/03/31(土) 17:59:13

まるでココ電柱を口答試験してるみたいだなｗ

114 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/03/31(土) 22:25:15

ＳＴＬは前スレでおれが言及したでそ
あほ

115 ：仕様書無しさん：2007/03/31(土) 23:28:53

はー？

116 ：仕様書無しさん：2007/03/31(土) 23:51:52

荒らしはスルー

117 ：仕様書無しさん：2007/04/01(日) 01:42:20

NG推奨ワード：tIS/.aX84.

118 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/02(月) 01:06:59

まんどくさいからＶｅｃｔｏｒ使っちゃえーつってつかわね？
無いと大変なんだけど

119 ：仕様書無しさん：2007/04/02(月) 01:08:57

お前は何を言ってるんだ

120 ：仕様書無しさん：2007/04/02(月) 02:07:24

最近はもっぱらArrayListの方だな、使うのは。

121 ：仕様書無しさん：2007/04/02(月) 04:14:34

>119
誰も何も言ってないと思うが…

122 ：おじゃばさま：2007/04/02(月) 09:22:41

UMLってのは詳細設計や機能設計をするために、脳内で行っていたものを図にすることによって、
整理しようという目的の物だから、オブジェクト指向とは関係ない。
単にUMLの中にもオブジェクト指向に向く物があるというだけだ。

STLは熟練者の組んだCソースよりは遅いが、普通の人が自作するよりは早いし、汎用性がある。
STL無しでもOOで組めるが、STLを使った方が簡単に出来る。
ただし、コンストラクタの癖を理解し、リソース解放漏れに注意する必要がある。

123 ：仕様書無しさん：2007/04/02(月) 09:48:07

>>122 熟練者が自作する場合と比べて、STLの遅い所ってどんな所ですか？

124 ：仕様書無しさん：2007/04/02(月) 12:08:24

何このスレ

125 ：仕様書無しさん：2007/04/02(月) 13:01:16

現状は、低能が程度の低い釣りをして他の低能を釣るスレ

126 ：仕様書無しさん：2007/04/02(月) 17:41:06

>>122
おじゃば殿はSTLを語ってるが、C++も使うのか？
STLにあるものをわざわざ自作する人って、おじゃばだろ
おじゃばは必死に頑張ったが、結局、STLより早くかつ汎用性のあるものは出来なかったということだな。

127 ：仕様書無しさん：2007/04/02(月) 23:07:02

インスタントというぐらいだから、オブジェクト指向はうまい、はやい、やすいのか？

128 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/02(月) 23:15:58

本に出てる概念を拾ってきて作るやつはアホ
俺なんかアセンブラ時代にＭＡＰ自分で考えたもんね

129 ：仕様書無しさん：2007/04/02(月) 23:44:47

荒らしやおじゃばの自己陶酔のせいでスレ内容のレベルが落ちたな

>>122おじゃば
当たり前のことを書き連ねて何がしたいの？

130 ：仕様書無しさん：2007/04/03(火) 11:25:40

荒し本人がよくいうよ。
まともな議論など、前スレ中ほどから絶えて久しいのに。

131 ：仕様書無しさん：2007/04/03(火) 11:46:18

>>130
>荒し本人がよくいうよ。
どういう電波を受信すると、こんな断定が出来るんだろう。

132 ：仕様書無しさん：2007/04/03(火) 11:58:05

毒電波発するのやめれ

133 ：仕様書無しさん：2007/04/03(火) 12:31:58

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　奥様聞きました？荒しさんのたら今度は「毒デムパ」ですって

134 ：仕様書無しさん：2007/04/03(火) 12:45:16

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　あら奥さんご存知なかった？たかくんの来るスレはいつもこうなのよ

135 ：仕様書無しさん：2007/04/03(火) 13:00:34

NGワード推奨：おじゃばさま

136 ：仕様書無しさん：2007/04/03(火) 15:38:58

ここは、おじゃばさまに釣られるのをぐっとガマンするスレになりました。

137 ：仕様書無しさん：2007/04/03(火) 16:32:41

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　おくさん、見ました？たかくんたら関数言語スレでも拒否られてましてよ

138 ：おじゃばさま：2007/04/03(火) 17:40:50

>123
処理に特化した検索処理などだ。
例えば最終レコードへの検索ヒット率が高い処理などで、最後から検索するようなロジックにするなどだ。

>126
すでにある物は作らない。それがJavaクオリティー。

攻撃者のうちの一人は、俺を排除するためにわざと会話にならない書き込みをしていたそうだ。
無意味だしもう新学期なので、無意味な書き込みはやめると言う事で決着した。
ただもう一人いるみたいだな。偽コンサルっぽいのがもう一人らしい。たかくんか？

139 ：仕様書無しさん：2007/04/03(火) 17:43:30

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　あらヤダ！たかひろくんたら「おじゃばさま」名義でさんざん荒してたのをもう忘れちゃったみたい

140 ：仕様書無しさん：2007/04/03(火) 17:53:23

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　アラ、たまに居るわよ。多重人格っていうのかしら？　被害妄想っていうのかしら？

141 ：仕様書無しさん：2007/04/03(火) 18:02:20

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　居る居るぅー。他人に散々迷惑かけて、謝りもせず相手を悪者扱いしちゃう子。ダメよねぇそんな子って

142 ：仕様書無しさん：2007/04/03(火) 18:03:50

>>138
>例えば最終レコードへの検索ヒット率が高い処理などで、最後から検索するようなロジックにするなどだ。
よりにもよって、こんな例を出してくるとは莫迦極まれり。
reverse_iterator も知らずに STL を語ってたのか。

143 ：仕様書無しさん：2007/04/03(火) 18:06:07

( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ )　ねぇねぇ、この子けぇじばんのタイトルも読めないのかしら。おばかさんね(ｷｬｯｷｬ

144 ：仕様書無しさん：2007/04/03(火) 18:31:00

ﾃﾗﾜﾛｽ

おじゃばフィルターに下記の文章を流し込むと、
>>138が出てくるのか。

これじゃ話が通じないわけだ

558 名前：仕様書無しさん投稿日： 2007/04/02(月) 10:08:55
おはよう。私は偽コンサルではない方だ。
私は会話が通じない人間ではない。

キミは、私が設計の説明をしている最中に
私の説明の主旨を無視して、
論点のずれた話題を延々と振って議論妨害してきた。

だから、私はキミの主旨を完全に無視して、
キミを排除する事に力を注いだ。
たったそれだけの話だ。

追伸
常連おさんから、キミの言動の傾向について話を聞いた。
結論として、キミはあまり良い評価を得ていない。

新年度に入った事だし、つまらぬ言い争いは止めないか？

145 ：仕様書無しさん：2007/04/03(火) 18:51:28

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
http://pc11.2ch.net/test/read.cgi/prog/1171808096/ (dat落ち)

770 名前：仕様書無しさん [sage] 投稿日： 2007/03/09(金) 02:02:26
コードをコントロールする側・される側にキッチリ分解する。
で、コントロールされる側のコードを追加しようが変更しようが
コントロールする側のコードは二度と触らない。
これがバグをいれこまずに機能追加するための大原則で、ここが
わかってなきゃなんでデザインパターンがやくにたつのかわかりっこない。

146 ：仕様書無しさん：2007/04/03(火) 18:53:46

【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を何故理解できないの？★5
http://pc11.2ch.net/test/read.cgi/prog/1175099288/

369 名前：仕様書無しさん [sage] 投稿日： 2007/03/26(月) 15:32:13
・ゲーム盤と審判＆ルール
・審判とルール
・プレイヤと戦術
の分離理由

■マイクロカーネル・パターン　あるいは
■「方針と実現の分離」原則
　プログラム中に散在する「方針」と「実現」を分離する事で、
　プログラムの複雑性を減らし、保守性や拡張性を高める方法。

147 ：仕様書無しさん：2007/04/03(火) 18:56:31

>>145の書き込み　2007/03/09(金) 02:02:26
>>146の書き込み　2007/03/26(月) 15:32:13

わずか16日間の間に、このスレにどのような劣化が発生したのか？

誰か説明よろ

148 ：仕様書無しさん：2007/04/03(火) 19:04:36

・アホコテ2匹＋αが荒らしまくった
・>1がアホだった

いじょ

149 ：仕様書無しさん：2007/04/03(火) 19:06:38

>>148
それは違う。
おじゃばが荒しをしたのが一つの原因だ。

150 ：仕様書無しさん：2007/04/03(火) 19:10:08

荒しをしたアホコテ2匹＝おじゃば、ココ
という意味だろ。

151 ：149：2007/04/03(火) 19:11:18

了解した

152 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/03(火) 19:23:45

俺がいつ荒らしたよ
議論に負たＯＯちゅが「荒らしだ荒らしだ」って騒いでるだけだろ

153 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/03(火) 19:26:24

基幹コテがいなくなると寂れちゃうし

154 ：仕様書無しさん：2007/04/03(火) 19:27:18

よーしわかったわかった

要するに >>145の中の文を書いたヒトは、

自分が(分散処理開発で)苦心惨憺して身に付けたノウハウ(>>145)が

実は分散処理の元祖で発明された概念(>>146)だと知って、

荒れ狂ってたわけね。

155 ：仕様書無しさん：2007/04/03(火) 19:30:53

おじゃばは Apple Darwin はムリとしても(w
せめて Linux Kernelソースくらいは目を通しておいた方がいい。

そんなの基礎教養だと思ってた。

156 ：仕様書無しさん：2007/04/03(火) 19:36:58

>>154
荒れ狂ってたのはおじゃばだろ。

あと、「分散処理の元祖が発明した」というよりは、
「それ以前からあったノウハウが、
分散処理の元祖の開発時に基本設計として採用された」
が正解。

物事は慎重に正確に書け

157 ：おじゃばさま：2007/04/03(火) 20:04:05

このスレの問題点はいくつかある。
まず、
「初心者に簡単に説明しようとする人」と「オブジェクト指向を深く理解しようとする人」の
2種類がいると言う事だ。

次に、
オブジェクト分割の際に、「機能や処理で分割しようとする人」がいると言う事だ。
オブジェクト指向ではオブジェクト（日本語だと難解だが物としておこう）で分割しなければならないが、
目に見えない物は機能との区別が非常に曖昧だ。そのため分割を間違える。

そのため、最初に誰かが簡単に説明すると、どんどん難しくなっていって、初心者はついていけなくなる。
そのうちOOと直接関係ないアーキテクチャパターンや、OO部品でしかないデザインパターンなどが飛び出し、
オブジェクトも機能も分からなくなって終了。
となっている。

158 ：仕様書無しさん：2007/04/03(火) 20:06:18

もう休んでイイよチミ

159 ：仕様書無しさん：2007/04/03(火) 20:09:19

一番の問題児が何言ってんだよ。アホか。

160 ：おじゃばさま：2007/04/03(火) 20:12:49

ちなみに146の言う方針と実現の分離は、分離の意味を誤解しているのではないかと思う。
クラスレベルの分離とシステムレベルの分離は違うのに、クラスレベルの分離に適用しているのではないか？
つまりABCと3つのクラスがあるとする。機能が1つ追加になった場合には、その機能でDクラスを
作ろうとするが、本当はその機能がAとBで使われているとしたら、Aを拡張したA'とBを拡張したB'を
作るべきだ。システムレベルで言えばこれも分離だが、これの区別がない人がいるのではないだろうか？

161 ：仕様書無しさん：2007/04/03(火) 20:14:52

おおぶじじゃぇくばとさしこまう

162 ：仕様書無しさん：2007/04/03(火) 20:16:11

つーかご高説垂れてるつもりで冗長なだけで中身がない文章しかかけないアホコテと
論破してるつもりで頭がおかしいとしか思えない勝利宣言繰り返すアホコテが
荒らしてる自覚がない事が最重要問題だと思う

163 ：仕様書無しさん：2007/04/03(火) 20:17:18

ちなみに機能と実装を分離する考え方のパターンがBridgeパターンだ。

164 ：おじゃばさま：2007/04/03(火) 20:21:16

第一、アーキテクチャパターンが悪い。
アーキテクチャパターンと言うのは、ただのアプリケーションの分類である。
適当なアプリケーションを解析して、これは○○パターンだねと分類しているだけである。
パターンになければ新しいパターンとして追加する。
作業的には終わりがないので、暇な学者が好んで研究する。
これは学問だ。
学問というのは、うまく利用出来ればそれなりの効果があるが、大抵はそのまま使えない。
だから初心者にアーキテクチャパターンやデザインパターンなどは勧めない。

165 ：仕様書無しさん：2007/04/03(火) 20:24:48

>>160
>>163
なんだ。デザパタスレで散々人の発言を妨害しまくっておいて
今更そんな事を言い出したのか。
つくづく腐った魂を持つ男だな、鈴木高弘。

166 ：仕様書無しさん：2007/04/03(火) 20:28:07

パターンなどと言わず方式とか様式とか法とかでいいじゃん。
しょせんやりかたなんだし。用語に当てはめて思考停止するパターンがｗ多いぞ。

167 ：仕様書無しさん：2007/04/03(火) 20:28:57

主張を唱えるだけでその根拠を述べないから、おじゃばさま
の意見には全く説得力がない。叩かれて当たり前。か、釣り。

168 ：おじゃばさま：2007/04/03(火) 20:29:21

俺は分かりやすく書いているつもりだが図がいいか？

class A{}
class B{}
class C{}

機能を追加（AとBで使う）

class A{}
class B{}
class C{}
class D{}

ではなく、

class A{}
class A' extends A{}
class B{}
class B' extends B{}
class C{}

にすべきだと言いたい。

169 ：仕様書無しさん：2007/04/03(火) 20:33:41

Beidgeパターンは捨てて、全てTemplate Methodパターンにしろと？

170 ：仕様書無しさん：2007/04/03(火) 20:36:14

>>168
>class A{}
>class A' extends A{}
>class B{}
>class B' extends B{}
>class C{}

class A{}
class A' extends A{}
class B extends A{}
class C{}
か
class A{}
class B extends A{}
class C{}
class D extends A{}

じゃないの？

171 ：仕様書無しさん：2007/04/03(火) 20:36:17

Bridgeパターン：実装継承と機能継承の分離。
　　　　　　　　　　　あるクラスをベースに、実装拡張と機能拡張を行う時に、
　　　　　　　　　　　実装の詳細をインタフェースでカプセル化し、
　　　　　　　　　　　機能側はこのインタフェース経由で機能記述、機能拡張を行う。

マイクロカーネルパターン：方針と実装の分離。

「方針」と「機能」は違う。
オセロ問題では、継承絡みの問題抜きで
ルールや戦略を分ける理由付けとして
ネットワーク分野でよく知られる
「方針と実装の分離」を引用した。

172 ：仕様書無しさん：2007/04/03(火) 20:50:09

都合が悪くなるとトンズラするおじゃばさま。そこがかわいい。

173 ：仕様書無しさん：2007/04/03(火) 20:52:57

今夜も精が出ますねぇ。
精が溜まり過ぎなんじゃないですか？

174 ：仕様書無しさん：2007/04/03(火) 20:57:21

>>169
デザパタスレの議論妨害厨乙。
なんでお前は元のパターンに戻ってっちゃうの？
今日はBridgeパターンを再勉強して、その成果を発表してたんじゃないの？

175 ：仕様書無しさん：2007/04/03(火) 21:02:49

Bridgeパターンをより判りやすく多少の皮肉の入った例で説明すると
「社会性」、これがブリッジに相当する。

実装側は、個々人それぞれに事情があるにせよ、
仕事では「社会性」を持って行動する。

(お子ちゃまは「社会性」が足りないので、
　それぞれ個別の実装方法で一定の「社会性」を持つよう訓練される。)

機能側は、個々人の持つ「社会性」を前提に
各種の仕事を割り振る。それらの仕事にはバリエーションがある。
厳しい仕事では、個々人の社会性に欠陥があったら排除する。

これがBridgeパターン。

なお実際の仕事では、個々人の特性、社会性に適した仕事を割り当てる
のが望ましい。
加えて、一部の非常に親切な人は、個々人の社会性の実装上の欠陥
(例えば幼少時のうんたらかたらで性格がどうした)みたいなのを考慮して
実装を直す教育を仕事現場でやってくれる事もある。

頑張れ

176 ：仕様書無しさん：2007/04/03(火) 21:05:52

個人と仕事を結ぶブリッジが「社会性」

177 ：仕様書無しさん：2007/04/03(火) 21:13:13

おじゃばと社会を結ぶブリッジが「２ちゃん」

だがおじゃばはここは社会ではない事に気付いていない。

178 ：おじゃばさま：2007/04/03(火) 21:22:07

>170
実際にはそうなるかもしれない。
機能で新しく独立したクラスを作るべきでないと言いたかった。

>171
非常に不本意だが、マイクロカーネル・アーキテクチャパターンの検証をしてみるか。
俺も171も納得してないからな。初心者は無視してくれ。
----------------------------------------------------------------------------------
Microkernelアーキテクチャパターンは、
変更されるシステム要件への適合が求められるソフトウェアシステムに用いられ、
システムの核となる最小限の機能を、拡張機能や顧客依存部分から分離する。
また、さまざまな拡張機能を組み込んだり、その拡張機能が協調して動作できるような
調停機能を提供したりする、一種のソケットとしての役割も果たす。
----------------------------------------------------------------------------------
やはり俺的には「システム」の「機能分離」の話で、OOのクラス分けには関係ない気がする。
特に「ソフトウェアシステムに用いられ」、「拡張機能や顧客依存部分から分離」と言う所だ。
ここの「機能」の範囲がたまたまオブジェクトと一致する場合があるかもしれないが、
個々で言う「機能＝オブジェクト」ではないと思う。

179 ：仕様書無しさん：2007/04/03(火) 21:23:47

178 名前：あぼ～ん [あぼ～ん] 投稿日：あぼ～ん
あぼ～ん

180 ：仕様書無しさん：2007/04/03(火) 21:26:06

179 名前：あぼ～ん [あぼ～ん] 投稿日：あぼ～ん
あぼ～ん

181 ：仕様書無しさん：2007/04/03(火) 21:31:27

また一歩、退化への道を歩むおじゃば。

「アーキテクチャ・パターンはシステムレベルの話だから違～う」
「アーキテクチャ・パターンに載ってる記述以外は信用できな～い」

平鍋のハンドブックがバカなんだよな、
あんな的外れなイントロ文とシステムブロック図しか載せないから。

182 ：仕様書無しさん：2007/04/03(火) 21:33:10

賛否両論あるけど、デファクトの地位にあるMVCパターン。

これなんかも確かに「アーキテクチャ・パターン」に載ってるけど、
明らかにフレームワークのクラス設計レベルの話なんだよな。

183 ：おじゃばさま：2007/04/03(火) 21:41:31

------------------------------------------------------------------------
Bridgeパターン：実装継承と機能継承の分離。
あるクラスをベースに、実装拡張と機能拡張を行う時に、
実装の詳細をインタフェースでカプセル化し、
機能側はこのインタフェース経由で機能記述、機能拡張を行う。
------------------------------------------------------------------------
JDBCやサーブレットのこと。
JDBCの場合は、ORACLEやPostgresに変更出来るようになっている。
サーブレットの場合は、TOMCATやWebLogicに変更出来るようになっている。
ただそれだけ。

社会性？
使えない実装を排除するためにインタフェースがあるなんて聞いたことないな。

184 ：仕様書無しさん：2007/04/03(火) 21:41:58

みんなばらばらのこと話して分散の研究か？
もうこれ以上話し合っても無駄だと気づけ
2chにオブジェクト指向は相応しくない！

185 ：仕様書無しさん：2007/04/03(火) 21:42:06

>>181

186 ：仕様書無しさん：2007/04/03(火) 21:44:35

おじゃばは学習能力の低い子だから相手すんな

187 ：仕様書無しさん：2007/04/03(火) 21:44:59

おじゃばさま、意見する時は根拠書けよ。
「～気がする」とか「かもしれない」って。女子高生かよ。

188 ：仕様書無しさん：2007/04/03(火) 21:45:51

おじゃばさま＝鈴木高弘＝大規模開発で基本設計ミスによりマルチスレッド絡みのデスマーチを起こした人物

189 ：仕様書無しさん：2007/04/03(火) 21:47:04

>187
そんな可愛くねぇよ
口だけの禿親父

190 ：仕様書無しさん：2007/04/03(火) 21:48:45

伊賀者参上！だなｗ

191 ：仕様書無しさん：2007/04/03(火) 21:55:07

おいおい、おじゃばさま、「JDBCやサーブレット」はBridgeパターンじゃないだろ。

192 ：おじゃばさま：2007/04/03(火) 22:01:43

アーキテクチャパターンと言うのは、たくさんのソフトウェアを解析して分類し、
その中から特徴や法則を見いだそうという学問だ。
だからアーキテクチャパターンの本を買って来て、その中のいくつかを暗記した所で意味はない。

コンサルが営業相手にプレゼンするには、アーキテクチャパターンで押せるが、
最近はプレゼンに第一線の技術者が出てくる場合があるから、痛い目にあるぞ。

193 ：仕様書無しさん：2007/04/03(火) 22:02:46

今日はここ最近になく大漁だな。よかったな、おじゃば。

194 ：仕様書無しさん：2007/04/03(火) 22:06:13

痛い目(･∀･)にある

195 ：仕様書無しさん：2007/04/03(火) 22:11:52

> 「方針」と「機能」は違う。

より詳しく説明すると、
「方針と実現の分離」では、まずは「方針」ありきで、次に「実現」側がそれを実現する。
主従関係がある。

「機能継承と実装継承の分離」は、まず「実装」ありきで、次にそれを利用して「機能」が記述される。

196 ：仕様書無しさん：2007/04/03(火) 22:18:41

俺が思うに、おじゃばってのは鈴木が、
その愚かな側面をオープンにしたものなのだと思う。

普段だったら口にできない初歩質問、判らない事、間違った考え方、
それらを見ず知らずの他人に晒して、フィードバックを得て、
そこから何かを学習しようとする・・・不毛な努力。

それでは、そんな不毛な努力に、何故付き合う人間が出てくるのか？
それは単に、彼が粘着し、罵倒し、荒しをし、その他醜悪な行為をして
数多くの心ある人々に「排除すべき対象」としてマークされ、
徹底的に叩かれる、その過程が、彼にとっての学習なんだ。

匿名掲示板上ですら素直に疑問や質問をできないとは、あわれな存在だ

197 ：仕様書無しさん：2007/04/03(火) 22:33:05

なるほどねぇ、そういうことか。しかし自分の勉強のために
嘘を吹聴するのはいかがなものかねぇ。
しかも、偉そうに、「だ・である」口調だぜ。あいつ。

198 ：仕様書無しさん：2007/04/03(火) 22:35:28

さすが伊賀者。分身の術も会得している。

199 ：仕様書無しさん：2007/04/03(火) 22:37:30

高弘> だからアーキテクチャパターンの本を買って来て、その中のいくつかを暗記した所で意味はない。

お前の普段の行動パターンがそうである事を、良く理解したｗ

あの本は単なるパターン集ではなく、
ソフトウェア・アーキテクチャに関する専門書だ。
パターン集部分には、真面目にアーキテクチャと取り組んできた人間なら
誰でも必ず触れた事のあるアーキテクチャ設計が含まれている。

更にvol2 (洋書)には、vol1(和書)で扱いのなかった、
Webアプリケーションのためのアーキテクチャ設計が多数含まれている。
こちらも、その分野を真剣にやっていた人間なら見覚えのあるパターンが多い。

200 ：197：2007/04/03(火) 22:38:06

は？俺は>>196じゃないよ。
おじゃばのあの口調こそ自演をカモフラージュするためのものかもな。

201 ：仕様書無しさん：2007/04/03(火) 22:39:12

「俺と高弘の間をジャマするな」が主張だからねー
誤解の無いように。

202 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/03(火) 22:46:43

どっかからソースをコピペしてきてちょちょいと書き換えて使うのを何パターンつうの？
代表的なプログラミング技術なのに　どの本見ても載ってないの

203 ：仕様書無しさん：2007/04/03(火) 22:49:22

>>202 ココ電球パターン。最近2chで知られるようになった。

204 ：仕様書無しさん：2007/04/03(火) 22:55:30

ココ電とおじゃば以外は、全部伊賀の人です。

205 ：仕様書無しさん：2007/04/03(火) 23:00:05

age進行？いいねぇ

206 ：仕様書無しさん：2007/04/03(火) 23:07:09

,.――――-､
　ヽ /￣￣￣｀ヽ、
　　| |　（・）｡（･）|
　　| |＠＿,.--､_,>　　　甲賀者には負けられないでござる
　　ヽヽ＿＿＿ノ　　　　　　　　　　　　　　　　　　　　　　　　　　の巻

207 ：仕様書無しさん：2007/04/03(火) 23:10:41

そろそろ法則追加だな

208 ：仕様書無しさん：2007/04/03(火) 23:43:32

ファイルを読んでDBに書き込む

この場合クラスにするのはどれですか？
教えてエロい人

209 ：仕様書無しさん：2007/04/03(火) 23:53:19

ファイルを読んでDBに書き込むクラス

210 ：仕様書無しさん：2007/04/03(火) 23:53:51

おじゃばの中身のカスに詫び入れさせてきたｗ

奴はデスマ関係者にも詫び入れるべきだと思うけど

211 ：仕様書無しさん：2007/04/03(火) 23:56:51

>>209
真面目に答えれ。

212 ：仕様書無しさん：2007/04/04(水) 00:38:10

デスマ先生スレ

213 ：仕様書無しさん：2007/04/04(水) 00:48:37

たかひろ、たかひろ
うるさい奴等ウザイ
氏ね

214 ：仕様書無しさん：2007/04/04(水) 00:54:25

デスマ先生ご乱心？

215 ：仕様書無しさん：2007/04/04(水) 01:14:51

>>214
いちいち、くだらない事書き込むな
氏ね

216 ：仕様書無しさん：2007/04/04(水) 01:23:49

法則発動しまくりんぐ

もしかしてこれﾌｧﾋﾞｮｰﾝ？

217 ：仕様書無しさん：2007/04/04(水) 01:41:42

御本人様火病り中ですか・・・

218 ：仕様書無しさん：2007/04/04(水) 02:10:37

デスマ先生がまだ頑張ってるぞ
おまいら応援行ってこい

http://pc11.2ch.net/test/read.cgi/tech/1172431242/l50

219 ：仕様書無しさん：2007/04/04(水) 02:24:08

#define private public
#define protected public

220 ：仕様書無しさん：2007/04/04(水) 02:27:30

>>178

俺が言っていたのは「方針と実現の分離」だ。
ビジネスロジックを疎結合に構成する方法として、
マイクロカーネルパターンの特徴「方針と実現の分離」を採用すれば良い
という文脈で、それを出したのだ。

おまえはいい年をして初心者騙して
醜態晒すんじゃねぇ。

221 ：仕様書無しさん：2007/04/04(水) 02:28:23

成り済ましって、だいたいこんな感じでおｋ？

222 ：仕様書無しさん：2007/04/04(水) 07:46:47

いつまでたっても、負けると将棋板ひっくり返すジジィだな高弘

223 ：仕様書無しさん：2007/04/04(水) 11:51:11

>>184
>みんなばらばらのこと話して分散の研究か？
ｗﾜﾛﾀ

224 ：おじゃばさま：2007/04/04(水) 19:58:49

>223
いや面白くない。
アーキテクチャパターンがオブジェクト指向と直接の関係がないと言う事が分かって、
たかひろが意図的に話題をずらしているだけだ。

225 ：仕様書無しさん：2007/04/04(水) 20:15:07

>>224＝おじゃばさま＝高弘

自問自答乙

226 ：おじゃばさま：2007/04/04(水) 20:42:30

>225
何だ俺を「たかひろ」や「伊賀知己」にして、自分はいなかった事にしたいのか？
俺は俺以外に人がいるのは分かるし、俺は他人に自作と思われようと全く気にしないから無意味だぞ。
で、もういいのか？
アーキテクチャパターンとOOは直接は関係ないと言うのは分かったか？

227 ：仕様書無しさん：2007/04/04(水) 20:43:45

ヒント：おじゃば知性90%ダウン

228 ：仕様書無しさん：2007/04/04(水) 20:44:49

ヒント：この子はおじゃばの役回りを理解できていない

229 ：ﾜﾛﾀ：2007/04/04(水) 20:47:40

ﾜﾛﾀ

230 ：仕様書無しさん：2007/04/04(水) 21:14:15

>>227　やあ、伊賀知己
相変わらず、すばやい粘着レスだな感心するよ

231 ：仕様書無しさん：2007/04/04(水) 22:54:07

マジメな質問で恐縮なんだけど、大体、main関数自体がOSの提供する
スレッドん中で動いてんのに、OSやライブラリの提供するスレッド機
能使わないってどういうこと？　ユーザプロセスでレジスタとか、ス
タックとか切り替えられんの？　ま、知らんで聞いてるが。できても
えらい面倒くさそうだな。こんなん簡単にできたらマジ尊敬するよ。

232 ：仕様書無しさん：2007/04/04(水) 22:54:57

あ、まちがった。おさんスレの方だった。ま、いっか・・・

233 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/04(水) 22:56:44

Ｊａｖａの場合はＪａｖａのグリーンスレッドのほうが安定してるから。

234 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/04(水) 23:25:00

ああ、あと、スレッド自作するのは
各スレッドを１：１で平行動作させたい場合だな。

235 ：とおりすがり・おさん：2007/04/04(水) 23:32:12

>>231
マルチスレッド・プログラミングではまった人が居ると聞いたので、
内部機構を考えてもらうネタとして考えた。

まずは安全牌の解。
デバッガのステップ実行割り込みのメカニズム使えば、
任意のポイントとタイミングで、レジスタ退避/復帰と実行ポイント変更と
スタック切換ができる。(こっちは概要調べただけで書いた事はない)
今なら例えばcygwin のgdbソースでも追っかけりゃ判るはず。
欠点は、gdbには詳しくなれるけど、マルチスレッド勉強には重過ぎる点。

次はもっと簡単だけど、かなりいい加減な方法。
後で書く。

236 ：とおりすがり・おさん：2007/04/04(水) 23:42:48

後で書く、とかいうとまた腐れが騒ぎ出して鬱陶しいんで、
要点だけ書いとくと、
・ノンプリエンティブ・マルチスレッドにする。(都合のいい時にしか切り替えない)
・レジスタ変数は一切使わないオプションでコード吐かせて(要コード・チェック)
　レジスタ退避の事は一切忘れる。
　(直前の実行ポイントは必ず、タスク切換関数の呼び出しスタックに保存される)
・スタック切換は、アセンブラで複数のスタック切換を書いてもいいんだけど、
　それ以外のやり方として、スタックは一本にして、それを分割して使うやり方がある。
　スタックポインタの操作は、alloca()関数とreturn駆使すればCで記述できる。(要コード・チェック)

　

237 ：とおりすがり・おさん：2007/04/04(水) 23:47:22

一番重要なポイント書き忘れてた。
・自作スレッドで実行させる関数上では、外部ライブラリ/OS機能は一切使わない。
　(動作検証が面倒になって、「原理を学ぶ」という主旨に反するから)

238 ：仕様書無しさん：2007/04/04(水) 23:48:12

ほぇ～、なんか難しそうだけど、要はできるっつうことね。
そういえば、デバッガでもレジスタ弄れるもんなぁ。
メリットがいまいち分からんが、こんなん書ける奴はよっぽど
のマゾだな。コリャ。

239 ：仕様書無しさん：2007/04/04(水) 23:48:28

要コードチェックって何のコード？

240 ：とおりすがり・おさん：2007/04/04(水) 23:53:15

>>239
アセンブラのコード見て、

・「レジスタ変数退避が不要」にちゃんとなってるか（コンパイラオプションが正しいか）
・「スタックポインタの操作」が意図どおりちゃんと書けてるか (プログラマ側の責任)

をチェックしる

241 ：とおりすがり・おさん：2007/04/04(水) 23:55:31

言い忘れ。
簡単なレジスタ退避なら、setjump()使えばできるでしょ。
なんか32bit化の時に入った、OS向けの特殊なフラグは取れないかもだけど。

242 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/05(木) 00:58:44

アセンブラで書けばいいだろ。
器用なことするな

243 ：仕様書無しさん：2007/04/05(木) 06:33:37

OOはどこいった？

244 ：仕様書無しさん：2007/04/05(木) 07:26:57

「奴」は当分、２ちゃんを見る気がしねぇんじゃねぇのか？

245 ：とおりすがり・おさん：2007/04/05(木) 08:15:47

>>236補足
・スタック切換～ベースポインタ操作だけは、Cじゃなくアセンブラを使う必要がある。

246 ：おじゃばさま：2007/04/05(木) 09:51:00

とりあえず、Cスレッドの話はおさんスレに任せるとして、OOの話に戻るか。

247 ：仕様書無しさん：2007/04/05(木) 12:46:14

また詐欺師か

248 ：仕様書無しさん：2007/04/05(木) 14:09:28

>>226
お前が誰かなど (一部の粘着ｸﾝを除いて) 興味などない。
ただ、
　　莫　迦　は　黙　っ　て　ろ。

249 ：おじゃばさま：2007/04/05(木) 18:59:51

>248
じゃ結局何が言いたいんだ？煽りとかじゃなくて、マジわかんね。
これだけ説明しても変わらないって事は、自分の意見が正しいと思っているって事だよな？
で、馬鹿な俺から皆を守り、正しい道に導くために戦ってると言うなら、その行動も納得出来る。
で、アーキテクチャパターンとOOの関係について、まともな回答をもらってないのだが。
方針と機能は違うとか、例を示しただけだとか。

248の断片的な主張を強引につなぐと、
「アーキテクチャパターンにある設計で作ることが、オブジェクト指向である」
と言うように聞こえるのだが、そう言いたいのか？

250 ：248：2007/04/05(木) 19:06:06

>>249
新ｽﾚになって初めて書き込んだ俺に訊くことか？

いつも思うことなんだが、
「自分以外はすべて同一人物として扱う」って
一種の心の病だよなあ。

251 ：仕様書無しさん：2007/04/05(木) 19:15:47

日本語でおｋ

252 ：仕様書無しさん：2007/04/05(木) 19:17:23

また、コテ忘れてるよオイ。

253 ：おじゃばさま：2007/04/05(木) 19:52:18

>250
誰？新スレで最初に書き込んだ内容が248？うーむ、なんだかわからんな。
まあいいや、248は見なかったことにするから、249も忘れてくれ。250も忘れるから。

254 ：仕様書無しさん：2007/04/05(木) 19:55:15

コテつけたり外したり、おじゃばさまも忙しいな。

255 ：仕様書無しさん：2007/04/05(木) 19:57:05

２ちゃんの荒しには三種類居る。

Type1. 池沼。

スレの議論内容を一切理解できないにも関わらず
昼夜を問わず延々何ヶ月もスレに常駐し、スレとは無関係な話や
目的不明な自作自演、成りすまし、罵倒発言や落書きを繰り返す、
一種の精神異常者だ。
[対策]スルー、コテハン化、ID制導入

Type2. 撹乱者(天然系、愉快犯系、etc.)

スレの内容や議論の目的をある程度は理解した上で、
瑣末な間違いや疑問でいちいち揚げ足取りをとったり、
参加者が同意している筈の議論の大前提を否定する事で、
議論を空転させ参加者を疲弊させ、最終的に議論の目的達成を阻む。
天然系の無意識発言が原因となる事もあるが、
その多くは、議論好き人種の愉快犯系的犯行である。
[対策]議論の前提/目的/経過/マナー等の再確認

Type3. 利害関係に基づくコミュニティ破壊者(嫉妬系、確信犯系、etc)

これが一番性質が悪い。
コミュニティの情報交換と価値創造に嫉妬心を抱いたり、
自らのハッタリ商売が成立しなくなるのを異常なまでに恐れて、
参加者を撹乱し/疲弊させ/やる気を失くさせ、コミュニティ崩壊を画策する輩。
Type3犯は手段としてType2, Type1を行って潜在荒しを扇動するが
動機と目的の邪悪さ・悪質さによって他と判別される。

256 ：仕様書無しさん：2007/04/05(木) 20:01:08

Type3犯罪者の発言事例

535 名前：仕様書無しさん投稿日： 2007/03/26(月) 22:56:55
みんな文句言って叩いていいものが出てこないかと待っている感じが滲み出ていて
笑える
俺としては、なぜ只で教える必要がある？って感じだ
まして２ｃｈでとかありえない
このスレが発端で２ｃｈネラーがOO得意になったりしたら市場価値は台無しだ
中には少しはわかっている奴もいるようだが、そこのところよく考えて発言するように

540 名前：仕様書無しさん投稿日： 2007/03/26(月) 23:05:25
>>538
違うな、『発言したいなら市場価値が上がるような権威のある場所でしろ』ってことだ
お前らはOOと2chが結びついて幸せなのか？
そこんとこよくドメイン分析するように

257 ：仕様書無しさん：2007/04/05(木) 20:14:55

python関連スレで2月中旬～3月下旬に沸いたデザパタ荒し厨、
こいつはType2～Type3だ。

隔離前後の本スレでのやりとりや、
中断後のやりとり(>>274-275,>>484,>>488-545)を見れば、
必然性や合理性に欠いており、その真意の程が図りかねる。

Haskellスレで3/31～4/1に沸いた実用言語厨も
同様にType2～Type3だ。

258 ：仕様書無しさん：2007/04/05(木) 20:46:28

147 ：仕様書無しさん：2007/04/03(火) 18:56:31
>>145の書き込み　2007/03/09(金) 02:02:26
>>146の書き込み　2007/03/26(月) 15:32:13

わずか16日間の間に、このスレにどのような劣化が発生したのか？

誰か説明よろ

148 ：仕様書無しさん：2007/04/03(火) 19:04:36
・アホコテ2匹＋αが荒らしまくった
・>1がアホだった

いじょ

152 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/03(火) 19:23:45
俺がいつ荒らしたよ
議論に負たＯＯちゅが「荒らしだ荒らしだ」って騒いでるだけだろ

153 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/03(火) 19:26:24
基幹コテがいなくなると寂れちゃうし

259 ：仕様書無しさん：2007/04/05(木) 20:49:06

皆スルーしてんだからいちいち触るな

260 ：仕様書無しさん：2007/04/05(木) 20:52:09

>258
わざわざあぼ～んされてる文章掘り返すなよ…にしても

> 基幹コテがいなくなると寂れちゃうし

寂れっつーか、落ち着いた議論であって欲しいのだがな。

261 ：仕様書無しさん：2007/04/05(木) 20:53:40

じゃあ皆様、そろそろオセロ作りに戻りましょうか

262 ：仕様書無しさん：2007/04/05(木) 21:00:28

おじゃば、ココとか伊賀（版画？）、どいつも
名無しに向かって同一人物扱いするところが異常だ。
２ちゃんの流儀は連続して話したいときのみコテなりレス番つけるんだから
勘ぐりで話を続けるのが異常。
複数レスの発言者の同一性なんてはなからないのに、
なんで脳内で作るかなぁ

263 ：仕様書無しさん：2007/04/05(木) 21:12:27

Type3荒しの発言事例

--------------------------------------------------------------------
535 名前：仕様書無しさん投稿日： 2007/03/26(月) 22:56:55
みんな文句言って叩いていいものが出てこないかと待っている感じが滲み出ていて
笑える
俺としては、なぜ只で教える必要がある？って感じだ
まして２ｃｈでとかありえない
このスレが発端で２ｃｈネラーがOO得意になったりしたら市場価値は台無しだ
中には少しはわかっている奴もいるようだが、そこのところよく考えて発言するように

--------------------------------------------------------------------
540 名前：仕様書無しさん投稿日： 2007/03/26(月) 23:05:25
>>538
違うな、『発言したいなら市場価値が上がるような権威のある場所でしろ』ってことだ
お前らはOOと2chが結びついて幸せなのか？
そこんとこよくドメイン分析するように

--------------------------------------------------------------------
python関連スレで2月中旬～3月下旬に沸いたデザパタ荒し厨、
こいつはType2～Type3荒しだ。

隔離前後の本スレでのやりとりや、
中断後のやりとり(>>274-275,>>484,>>488-545)を見れば、
必然性や合理性に欠いており、その真意の程が図りかねる。

--------------------------------------------------------------------
Haskellスレで3/31～4/1に沸いた実用言語厨も
同様にType2～Type3荒しだ。

--------------------------------------------------------------------
同様にデザパタスレで行われた議論妨害もType3荒しだ。

264 ：仕様書無しさん：2007/04/05(木) 21:12:43

そうすると自分の仮想敵のイメージを固定しやすいからでそ

265 ：仕様書無しさん：2007/04/05(木) 21:15:44

今日も平和だな～

266 ：ﾜﾛｽ：2007/04/05(木) 21:19:11

-憂鬱なプログラマによるオブジェクト指向日記　過去ログ-

ＤＱＮのなかにも、どうしようもないＤＱＮというものがいる。
満足に食事すら与えなかったり、虐待を繰り返したりと、
親としての素質に欠ける人が確実にいる。
「親資格」なんてものを作って、親になれる人間を選別すれば、
残酷な家庭内での事件も減るだろう。
しかし、それは危険な思想だし、別な意味で残酷な世界だ。

ＤＱＮに生まれても、途中でＤＱＮから脱出できるような教育を施せる社会が、
今のところは現実的で、そして効果のある方法だろう。

ＤＱＮから子どもを産む権利を剥奪すれば、ＤＱＮ再生産を防ぐことはできる。

267 ：仕様書無しさん：2007/04/05(木) 21:33:14

ひょっとしてアンテナ100本立ってる？

268 ：ﾜﾛｽ：2007/04/05(木) 21:35:05

ネタがワンパターン
しょーもねぇガキだな

269 ：仕様書無しさん：2007/04/05(木) 21:44:02

面白い？

270 ：仕様書無しさん：2007/04/05(木) 21:58:38

スレタイのｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの
からすると、未だに非ｵﾌﾞｼﾞｪｸﾄ指向開発が主流ってことかな
お舞ら、OODなんてやってないのか？
実はお舞らって、DQN指向開発まんせーじゃね

271 ：仕様書無しさん：2007/04/05(木) 22:06:04

面白い？

272 ：仕様書無しさん：2007/04/05(木) 22:10:46

今日は、伊賀知己はまだか

273 ：仕様書無しさん：2007/04/05(木) 22:17:02

ＶＢってさ、一部、オブジェクト思考でないの？
テキストボックスとか、ラベルとか。

274 ：仕様書無しさん：2007/04/05(木) 22:23:52

ありゃ、コンポーネント嗜好を追求してんじゃね
別名ポトッペッタ嗜好とも言う

275 ：仕様書無しさん：2007/04/05(木) 22:31:24

ＪＡＶＡとＶＢ系って、どっちが勝ちますかね？

１０年後・２０年後、どっちが残ってるでしょうか？

276 ：仕様書無しさん：2007/04/05(木) 22:41:34

２～５年後
JAVAがメジャーになりすぎて
VBの開発とかメンテとか移植ができるひとの希少価値が高まる。
１０年後。
別言語にJAVAの資産は受け継がれる。
VBのサポートは打ち切られるが、VBerの希少価値は高まり続ける。
２０年後
VBerは国宝級に崇拝される。

277 ：仕様書無しさん：2007/04/05(木) 22:45:13

補足
１０年後はC#が帝王として君臨
２０年後、しらね

278 ：仕様書無しさん：2007/04/05(木) 22:59:28

C丼はないだろ

279 ：仕様書無しさん：2007/04/05(木) 23:02:01

Ｃ丼
Ｃ＃
Ｃ♯

280 ：仕様書無しさん：2007/04/05(木) 23:12:15

イベントドンブリ

281 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/05(木) 23:15:19

ＪａｖａはＭＳに捨てられてサーブレットと携帯アプリに特化して生き残ってるだけ
ＪＡＶＡアプリケーションの案件なんてあるの？

282 ：仕様書無しさん：2007/04/05(木) 23:25:23

>>281
現状しかみえてないお前は１０年後乞食になっている。

283 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/05(木) 23:27:28

じゃあなんで５年前のＯＯ厨誰も生き残ってないんだよ？

284 ：仕様書無しさん：2007/04/05(木) 23:28:18

クラスのインスタントを生成するとだな、それがオブジェになるわけだ。

285 ：仕様書無しさん：2007/04/05(木) 23:45:34

さびれて温泉街のようなうらぶれっぷりだな。

286 ：仕様書無しさん：2007/04/05(木) 23:46:43

ＶＢ系(VB/VB.NET)のエキスパートになるべきか、
それとも、他の言語(java/c#)にも手を出すか？

皆さんは、どっち選ぶ？

287 ：仕様書無しさん：2007/04/05(木) 23:52:21

二者択一かよ

288 ：仕様書無しさん：2007/04/05(木) 23:55:33

VBでエキスパートってかｗ

289 ：仕様書無しさん：2007/04/05(木) 23:58:14

JavaとUMLが好きなやつって何であんなにキモいんだろう？

290 ：仕様書無しさん：2007/04/06(金) 00:09:44

ＩＴﾄﾞｶﾀって何であんなにキモイんだろう？

291 ：仕様書無しさん：2007/04/06(金) 00:11:50

JavaとUMLが好きなＩＴﾄﾞｶﾀって何であんなにキモいんだろう？

292 ：仕様書無しさん：2007/04/06(金) 00:14:20

ここに常駐してる人って理由抜きでｷﾓｲ。

293 ：仕様書無しさん：2007/04/06(金) 00:16:28

>>286
両方できて当然。各１日でマスターできなければこの先道はない。

294 ：仕様書無しさん：2007/04/06(金) 00:16:46

>>292
ここに常駐し、かつ、JavaとUMLが好きなＩＴﾄﾞｶﾀよりマシだろ

295 ：仕様書無しさん：2007/04/06(金) 00:17:23

ねえ、マスター作ってやってよ

296 ：仕様書無しさん：2007/04/06(金) 00:21:05

話題が貧困なちゃねらーほど存在価値の低いものはない。

297 ：仕様書無しさん：2007/04/06(金) 00:31:50

これって本当？
http://jibun.atmarkit.co.jp/lcareer01/rensai/career42/data42.html

298 ：仕様書無しさん：2007/04/06(金) 00:35:31

話題が飛躍しすぎててつまんねーよ。

299 ：仕様書無しさん：2007/04/06(金) 00:36:45

コテハンさんもコテハン叩きさんも
そろそろ落ち着いて建設的な話しましょう。

300 ：仕様書無しさん：2007/04/06(金) 00:42:47

つ http://www.amazon.co.jp/o/ASIN/4569577482/

301 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/06(金) 00:44:32

じゃあマジックナンバーとラベルの誤謬について

302 ：仕様書無しさん：2007/04/06(金) 00:47:49

むしろこっちに詳しく書いてある
つ http://www.amazon.co.jp/o/ASIN/4569654657/

303 ：仕様書無しさん：2007/04/06(金) 01:07:16

どうも底辺の人が来ちゃってるようだな

304 ：仕様書無しさん：2007/04/06(金) 01:10:23

おまいらループしすぎ

まずはユースケースの有効性について

305 ：仕様書無しさん：2007/04/06(金) 01:12:24

まずは嫁
つ　http://www.amazon.co.jp/dp/4413070569/

306 ：仕様書無しさん：2007/04/06(金) 11:06:20

ＶＢ系しか知らない男は、
今後、どういう風にスキルアップしていくのが理想？

307 ：仕様書無しさん：2007/04/06(金) 11:15:51

伊賀知己のアホはオサンスレで引き受けるから
おまいらゆっくり楽しめな。たまにはジャワぽんのためになる事をしようと思う。

308 ：仕様書無しさん：2007/04/06(金) 11:59:23

>>304
アクターに目や口を書いて笑いをとる

309 ：仕様書無しさん：2007/04/06(金) 12:41:10

>>307
つ　http://www.amazon.co.jp/dp/4872331265/

310 ：おじゃばさま：2007/04/06(金) 18:59:14

そういえば誰かがOO型クラス分割の利点を説明しろとか言っていたな。説明しておく。

C言語で非OOプログラミングでコーディングしていて、ずっと仕様変更を繰り返していると、
ソースコードがぐちゃぐちゃになって、結局あるタイミングで作り直しになったという経験はないか？
なんでそうなるのかと考えてみよう。
a()
b()
c()
と関数があり、それに機能で関数を作って、
d()
を追加したとする。
a()、b()でこの機能を使用する場合、多くの場合、a()とb()にはif文が入ってd()を呼び出すことになる。
ここで問題なのは、if文を追加した時点で以前のa()、b()とは処理が違ってしまっていて、
前のようには使えなくなっているという事である。
それにより、別の場所からa()をd()の機能無しで使いたい場合、またa()に新たにif文を追加する事になる。
かくしてこのプログラムはスパゲッティーの道をたどる事になる。

311 ：仕様書無しさん：2007/04/06(金) 19:21:34

ﾊﾟﾛﾊﾟﾛ

312 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/06(金) 19:48:59

物事を自分で考えられる人はＯＯ厨にならない。
いま残ってるのは教条主義者だけだ

313 ：仕様書無しさん：2007/04/06(金) 19:49:53

で？

314 ：おじゃばさま：2007/04/06(金) 20:03:13

ではどうすればいいか？
理想的なのは、a()はd()の機能有りでも無でも使えて、さらにa()には修正が入らない事である。
もしこれが実現出来れば、スパゲティーコードとはオサラバである。
まあ、OOを知っている人なら分かると思うが、OOではa()の拡張、機能のオーバーライドで実現出来る。
ここがオブジェクト指向の最重要点である。やりたいことは単純なのである。

しかし問題がある。
今までの非OOでの組み方でこれをやろうとすると、出来ないのである。
もう少し正確に言うと、出来るのだが間違えても気が付きにくい。
最初は問題なく見えても、変更を繰り返すうちにまた破綻する。
どう組めば破綻しないかと言うと、これがOOを知らない者には理解しにくい。
一言で言えば、抽象化なのだが、これを聞いて分かる人などいないだろう。
まあ、組み方は後で説明するとして、オブジェクト指向の利点は分かってもらえただろうか？

315 ：仕様書無しさん：2007/04/06(金) 20:10:58

だめだこりゃ

316 ：おじゃばさま：2007/04/06(金) 20:14:36

ところで電球はCコードに修正を繰り返して破綻したコードを見た事がないのか？
どうすればこれをなくせるかと考えた事はないのか？

317 ：仕様書無しさん：2007/04/06(金) 20:15:23

誰かどうにかしろよ
この自己主張禿しすぎな勘違いコテ2匹

318 ：仕様書無しさん：2007/04/06(金) 20:15:44

ヒント：モジュール機構さえあればその件はおｋ

319 ：仕様書無しさん：2007/04/06(金) 20:16:12

とりあえずsageろ＞アホコテ共

320 ：仕様書無しさん：2007/04/06(金) 20:16:19

>>317
任せた

321 ：仕様書無しさん：2007/04/06(金) 20:17:09

勘弁してくれよ
こんなの触りたくねーし

322 ：仕様書無しさん：2007/04/06(金) 20:17:28

　　　|＼＿＿＿／|
　　　|　　　　　　　.|
　　　|　Θ　　Θ　|　　　　　　／￣￣￣￣￣￣￣
　　　|　　　　　　　.|　　　　　＜　
　∈AA∋　　　∧∧　　　　　＼＿＿＿＿＿＿＿
　（ﾟ‥ﾟ）　　（ﾟДﾟ）
　　∪∪|＿＿_⊃　⊃
　／|＿_.|　　　 |＿_|＼
　|　 |　 |　　　　 |　＼_|
　|　ﾉ　ﾉ　　　　　＼＿|
　＼_ノ|　　　　　　|
　　　　|　　　　　　|

323 ：仕様書無しさん：2007/04/06(金) 20:18:35

Haskellの代数的データ型で、クラスインスタンスをメンバ（？）にするにはどうすればいいんですか？

324 ：仕様書無しさん：2007/04/06(金) 20:25:00

トリがついてるだけココ電のほうがましな気がする。
おじゃばってひょっとしてトリップ知らないんじゃないのか。

325 ：仕様書無しさん：2007/04/06(金) 20:26:56

>322
どっちがココでどっちがおじゃば？

326 ：仕様書無しさん：2007/04/06(金) 20:44:55

オブジェクト開発は俺みたいに頭がよくないとできない

327 ：仕様書無しさん：2007/04/06(金) 20:47:54

機能変更のたびに継承しろってか？
どういう覚え方したらこんな独りよがりの考え方になるんだ。

328 ：仕様書無しさん：2007/04/06(金) 21:00:52

　　　|＼＿＿＿／|
　　　|　　　　　　　.|
　　　|　Θ　　Θ　|　　　　　／￣￣￣￣￣￣￣
　　　|　　　　　　　.|　　＜　 OOとは機能変更のために継承をすることである
　∈AA∋　　　∧∧　　　　＼＿＿＿＿＿＿＿
　（ﾟ‥ﾟ）　　（ﾟДﾟ）
　　∪∪|＿＿_⊃　⊃
　／|＿_.|　　　 |＿_|＼
　|　 |　 |　　　　 |　＼_|
　|　ﾉ　ﾉ　　　　　＼＿|
　＼_ノ|　　　　　　|
　　　　|　　　　　　|

329 ：仕様書無しさん：2007/04/06(金) 21:01:04

粘土みたいに手でさわって作れるプログラム言語作ってくれ

330 ：おじゃばさま：2007/04/06(金) 21:02:29

>324
トリ知らない。教えてくれ。

>326
OO出来ますって言う人は多いが、「変更にたびに完成度が増していく」ってのを実感している人は少ない。
これを話しても、仕事が出来て大量にソース組んでいる人しか同意を得られない。
才能だけでも、努力だけでもダメだって事だろ。

>327
それは誤解だ。全ての継承でやれって話ではない。
その方法が状況によって違うから、難しいんだよ。

331 ：仕様書無しさん：2007/04/06(金) 21:09:25

トリップの付け方もわからん
挙げ句付け方をぐぐって調べることも出来ん
そんなアホが説教してもなぁ

332 ：OJAVAさま ◆Fj1.051clU ：2007/04/06(金) 21:12:37

　　　|＼＿＿＿／|
　　　|　　　　　　　.|
　　　|　Θ　　Θ　|　　　　　／￣￣￣￣￣￣￣
　　　|　　　　　　　.|　　＜　鳥つけてみたよ、すごいだろ
　∈AA∋　　　∧∧　　　＼＿＿＿＿＿＿＿
　（ﾟ‥ﾟ）　　（ﾟДﾟ）
　　∪∪|＿＿_⊃　⊃
　／|＿_.|　　　 |＿_|＼
　|　 |　 |　　　　 |　＼_|
　|　ﾉ　ﾉ　　　　　＼＿|
　＼_ノ|　　　　　　|
　　　　|　　　　　　|

333 ：仕様書無しさん：2007/04/06(金) 21:39:45

>>323
class Animal a where
call :: a -> String
data Dog = Dog
instance Animal Dog where
call _ = "bowwow"
data Sparrow = Sparrow
instance Animal Sparrow where
call _ = "cheep"

data AnimalH = forall a. Animal a => AH a
animals = [AH Sparrow, AH Dog, AH Sparrow]

main = mapM_ (putStrLn . (\ (AH x) -> call x)) animals

334 ：仕様書無しさん：2007/04/06(金) 21:41:42

・・・まあ確かに構造化言語においては
仕様変更に対応するために、そのプログラムの構造から変更しなくてはならないケースはある。
そうしないと（このスレ流行の言葉で言うと）破綻するからね。

でも継承とか委譲（とか「なんちゃらパターン」）の使い分けがわからない。
>>330
「状況によって違う」というのは、
「確立した方法論は無い」とか「経験則しかない」と解釈してよいのか？

335 ：仕様書無しさん：2007/04/06(金) 21:43:59

ヒント：その件はモジュール機能導入でおｋ

336 ：仕様書無しさん：2007/04/06(金) 21:45:35

>>323
存在量化(existential quantification)を使わない方法。

data Animal = Animal { animalCall :: String }

dog :: Animal
dog = Animal { animalCall = "bowwow" }

sparrow :: Animal
sparrow = Animal { animalCall = "cheep" }

animals :: [Animal]
animals = [sparrow, dog, sparrow]

main = mapM_ (putStrLn . animalCall) animals

クラス階層が必要ないなら、こっちが扱いやすいと思う。

337 ：333：2007/04/06(金) 21:47:24

animals :: [Animal]
animals = [AH Sparrow, AH Dog, AH Sparrow]

-- www

338 ：仕様書無しさん：2007/04/06(金) 23:00:47

このスレには実は3人の住人しかいない

339 ：仕様書無しさん：2007/04/06(金) 23:04:16

その３人とは>>338、>>338の脳内のお友達、>>338の別人格、の事である

340 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/06(金) 23:25:21

かわいそうなＯＯ厨の人たち・・・

341 ：仕様書無しさん：2007/04/06(金) 23:50:36

自覚が無いって恐ろしいな

342 ：仕様書無しさん：2007/04/07(土) 00:59:56

>>341　おまいもしっかり自覚するように

343 ：仕様書無しさん：2007/04/07(土) 01:55:37

１つのファイルに数種類のレコードが１行以上存在するとした場合、
そのファイルを解析して３つのテーブルを更新するものとする。
この条件に最適なクラスとインターフェースを全て挙げよ。

IT/○ro課題より

344 ：仕様書無しさん：2007/04/07(土) 06:20:45

オブジェクト指向以前に、利用する掲示板のFAQも読まない奴が
技術者面して他人に教えをたれようとすんな。糞。あげ。
>http://info.2ch.net/guide/faq.html#C7

345 ：仕様書無しさん：2007/04/07(土) 06:52:26

使いこなせず負け犬の遠吠えを繰り返すアホコテが1匹
使いこなしたつもりで勘違い講釈を続けるアホコテが1匹

何をやらせてもアホはアホのままって見本みたいな奴らだったな

346 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/07(土) 09:37:41

>>343
なにその糞問題
作ったやつ馬鹿じゃねーの？

347 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/07(土) 09:44:26

問題は３行目だ
作るのか？作るんだったら俺クラスあげたって名前みんな違うからしょうがないし
ライブラリ引っ張ってくるだけのものを言ってるのなら　それだけのやつって事だな。
この条件に最適　ってのもＤＱＮ的に意味不明だな
「この条件でプログラムを組む場合使うクラス」なら判るが
さらに「最適」っておまい決められるのかよ

348 ：仕様書無しさん：2007/04/07(土) 11:16:44

>>343
俺はOODはイマイチよく解らんが
思い付く限りでやってみる。

数種類のレコードってことは
複数のレコード形式が雑じったファイルかな？
テーブル３種は甲乙丙と名付けたとして…

このファイル形式を扱うクラス
レコードインターフェース
　各レコード形式のクラス
テーブル基底クラス
　甲クラス
　乙クラス
　丙クラス

349 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/07(土) 12:13:30

テーブルと１：１でクラス作るのは、初めて組んだときやったけど
効率悪いわ、結合が増えてモジュールが破綻しそうになるわでやってないな。
Ｊｏｉｎ文なんかつかえないわなー
おこちゃまプログラミング

350 ：仕様書無しさん：2007/04/07(土) 12:20:06

テーブルとクラスを１：１にしていいのはASP.NETだけ

351 ：仕様書無しさん：2007/04/07(土) 13:11:17

TableModuleとかいうパターンだな

352 ：仕様書無しさん：2007/04/07(土) 19:55:33

再利用は不効率だから

353 ：仕様書無しさん：2007/04/07(土) 19:56:29

不幸率ってなんだよ非効率だろ

354 ：仕様書無しさん：2007/04/07(土) 20:12:29

非行率ってなんだよ国公立だろ

355 ：仕様書無しさん：2007/04/08(日) 02:30:28

ねえねえココ電球～～

356 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 03:40:55

はい？

357 ：仕様書無しさん：2007/04/08(日) 04:06:03

>>356

　　　　/＼＿＿_／＼
　　／''''''　　　　　''''''::＼
　　|（へ）, 　　、（へ）、.| 　ふふ、呼んでみただけ♪
　　|　　 ,,ノ(、_, )ヽ、,,　.:|
　　|　　｀-=ニ=- '　 .:::::|
　　＼　　｀ニニ´　 .＿／
　　　（｀ー‐--‐‐―/ 　）.|´
　　　 |　　　　　　　|　　ヽ|
　　　ゝ　ノ　　　　ヽ　ノ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

358 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 05:10:46

うー

359 ：仕様書無しさん：2007/04/08(日) 09:58:22

電球は、徹夜だったのか？
歳なんだから無理するなよ

360 ：仕様書無しさん：2007/04/08(日) 10:51:21

さぁ、ザリガニのスーパークラスは、カニか？エビか？　どっち？

361 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 11:37:51

Ｃだと多重継承が許されるのです

362 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 11:44:20

思い出したが、結合の概念はずっと前から持っていた。
自分の頭の中で連結と読んでいたけど、
データベースのデータには確率的にぼやけているデーターがある。
量子力学の電子の雲の図を思い浮かべてもらうといい。
不確定性状態のデーターを参照しているデーターも不確定となる。
リレーショナルＤＢがＯＯと相性が悪いのはＯＯが不確定性データーを扱えないからともいえると思う。

363 ：仕様書無しさん：2007/04/08(日) 11:57:55

nullってあるじゃん

364 ：仕様書無しさん：2007/04/08(日) 12:01:45

不確定な仕様しか出せないから不確定要素とかいう表現が出てくる
要件が確定してたらザリガニはエビかカニかなんていうどうでも良い名詞並べたいだけの考え方なんて出てこないよ

365 ：仕様書無しさん：2007/04/08(日) 12:05:20

SQLのNULLは「不明(unknown)」「非適用(not applicable)」の意味で使われます。

366 ：仕様書無しさん：2007/04/08(日) 12:25:42

今のOOではクラスの構造は設計時に決まってしまうため、
AクラスとBクラスから、両方の属性を併せ持つCクラス
を動的に生成できないからな。
SQLでは結合や射影を使って何通りものオブジェクトを動
的に生成できる。所謂パラダイムミスマッチ。

367 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 13:04:53

ちげーよ
マルチクライアントだと常に誰かがデーターを変更している可能性があるから
今読んだデーターが次の瞬間もデータベース上のデーターと一致しているとは限らないということ。

368 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 13:07:35

Ｊａｖａでも動的生成はできる。
プログラムでソースコード吐き出してコンパイラ呼んでＣｌａｓｓクラスで取り込むんだったとおもう　たしか

369 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/08(日) 13:08:21

ＪＩＴってのもあったな。
わすれたが

370 ：仕様書無しさん：2007/04/08(日) 13:46:24

データベースの排他処理はOOとは別問題

371 ：仕様書無しさん：2007/04/08(日) 13:51:54

>>361
Cだと継承できねーよ
C++だろ。正確になっ。ココナッツ電灯。

372 ：仕様書無しさん：2007/04/08(日) 14:49:56

どうでもいいけど
「データー」はねーって
　　　　 ↑

変な読み方スレ逝け屑コテ

373 ：仕様書無しさん：2007/04/08(日) 15:22:28

>>367
ダーティリード、反復不可読み取りの例か。
更新ロックで回避しても、他が待ちになってつかえるから、
中間表でもマスタでもいいが、タイムスタンプカラム、更新フラグカラムを作るわけだな。

374 ：仕様書無しさん：2007/04/09(月) 13:15:09

昔から「データー」という椰子にハイスキル無しは有名

375 ：仕様書無しさん：2007/04/09(月) 17:21:44

昔から揚げ足取りにハイスキル無しは有名

376 ：仕様書無しさん：2007/04/09(月) 17:27:16

>>375
はつみみです。

377 ：仕様書無しさん：2007/04/09(月) 18:35:51

昔からOO厨にハイスキル無しは有名

378 ：おじゃばさま：2007/04/09(月) 19:03:07

>334
最初は継承だけ知っていればいい。委譲だのデザインパターンなどは知らなくてもいい。
継承すら最初に継承を考慮して設計する必要もない。変更修正すると継承が必要になってくるので、
そこで使えばいい。
デザインパターンに当てはめればOOだと言うのは間違いだ。いまだにそう考えている人がいるが、
それは耐震素材を使えば、耐震建築物になると言っているのに等しい。

確立した方法はないとか、経験則しかないと言うのもちょっと違う。
重要なのは抽象化なのだが、確かに確立した方法（こうすべき）と言うのは俺も見つけていない。
しかしOOの方針（こうした方が良い）と言うのはあり、それで十分だ。
なぜならOOは修正範囲が狭いので、ある程度間違えていても後から修正が効く。
修正を繰り返せば抽象化が進み完成度が増す。だから「方法」より緩い「方針」で十分だ。
方針は説明しても「OOを理解している人にしか分からない」事が多くて意味がない。
だから俺は学習手順を教えている。内容は前にも言ったが、また今度説明しよう。

379 ：仕様書無しさん：2007/04/09(月) 20:46:33

だからトリつけてこいよ。おじゃばさま何人もいるとわかったんだろ。
えらそうに講釈たれる前にそっからだ

っても、おじゃばさま、がJava厨の共同コテならしかたないわなｗ

380 ：仕様書無しさん：2007/04/10(火) 06:49:05

オブジェクト指向ができてきた理由も価値もわからずオブジェクト指向オブジェクト指向と言ってるだけだからだよ。
かつての構造化プログラミングのときのgotoのようだ。
結局、頭を使って組んでるやつは、なにを使っても保守性汎用性の高いプログラミングをしている

381 ：仕様書無しさん：2007/04/10(火) 09:31:17

で、「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？」については、OO語りは寝言ばっかりだからなのか？

382 ：仕様書無しさん：2007/04/10(火) 13:43:59

そもそも手法の一つとして使うものなのに
流行る流行らないで見てる時点でおかしいわな

383 ：仕様書無しさん：2007/04/10(火) 14:06:10

毒デムパコテ常駐スレ

詳しくは >>196

384 ：仕様書無しさん：2007/04/10(火) 23:05:14

ただいまおまいら！
思った以上に伸びててびっくりしたよ。
書いた事以外にも新人の信じられない行動はあるんだ。これを書いたところでネタとしか思われないと思って書かなかったけど書いてみる。

新人の力試すため一番最初にとりあえず基礎的な事をやらせてみてたんだ。
Hello Worldを出力、メソッド分け、条件分岐記述、ループ記述とかやらせて見て、どこまでできてどこからできないってのがわかったら教えなきゃいけない部分がわかると思って。
んでやらせてみたら怪しい書き方ながらもなんとかHello World出力は書けた。
俺「んじゃあ…今のちょっと怪しかったから自分の名前と年齢出力する記述を改行も使って書いてみ。」
新「えっと、よくわからないんすけど、なにからやるんすか？」
俺「とりあえずメソッド書いて」
新「はい」
カタカタカタ…
新「書きましたけど」

俺は愕然とした。そいつのディスプレイにはソース内にもろにカタカナで「メソッド」と打鍵されていたんだ。
Eclipseから露骨に赤文字で指摘されてるんだ。

そこで俺はこいつが前職でJAVAをやってたのが嘘だと確信した。
これを読んだおまいらの中には「それ絶対ネタだろ」とか思う奴もいるだろうが、

紛　れ　も　な　い　実　話

385 ：仕様書無しさん：2007/04/11(水) 00:27:43

新人の概要が先に欲しかった
初心者ならそんなもんだろとおも

386 ：仕様書無しさん：2007/04/11(水) 11:16:04

派遣でJava経験ありでそういうのが来ることもないとはいえないのがこの業界

387 ：おじゃばさま◇jpaavsas：2007/04/11(水) 20:46:31

>380
まさにその通りだ。

>381
OOは説明できなくても、感覚的にマスターしている人は多い。
そのため、流行っていると言うよりは、普及していると言えるだろう。
寝言が多いのは、引退SEや営業が偽コンサルをやっているためだろう。

>382
その通りだ。
仕様が明確で変更が少ないシステムなら、非OOの方が効率がいい場合も多い。

388 ：おじゃばさま◇jpaavsas：2007/04/11(水) 20:48:57

新人についてならこんな伝説を聞いた事がある。

上司「今日から新人が来る。パソコンは得意と言う話だ。」
先輩「そうですか楽しみですね。」
次の日----------------------------------------------------
新人「よろしくお願いします。」
先輩「これが君のマシンだよ。」
10分後----------------------------------------------------
新人「あのー、これどうやって電源入れるのでしょうか？」
先輩「え、電源ボタンはこれだけど．．．パソコン得意なんじゃないの？」
新人「スーパーマリオなら得意なんですけど。」
先輩「．．．それってファミコンじゃん。」

389 ：仕様書無しさん：2007/04/11(水) 21:11:08

なぁ、コイツこれでトリつけたつもりなの？
流石に笑えんのだが。

390 ：おじゃばさま ◆Fy0HoitUDw ：2007/04/11(水) 22:13:14

偽者出現か。
しようがない奴だな。

>>387
身分詐称で通報しますた。

391 ：仕様書無しさん：2007/04/11(水) 22:44:32

おじゃばさまは身分なのか

392 ：仕様書無しさん：2007/04/11(水) 22:52:22

＞おじゃば、他エロい人
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ
１．テーブル１つに対してクラスを１つ作った方がいいの？
２．結合の場合はどうすんの？
３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？

393 ：仕様書無しさん：2007/04/11(水) 22:58:49

＞１．テーブル１つに対してクラスを１つ作った方がいいの？
>>350

＞２．結合の場合はどうすんの？
場合による

＞３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
使うな

394 ：仕様書無しさん：2007/04/11(水) 22:58:52

１．日本では一夫一妻制です。
２．感染症予防に気をつけましょう。
３．組み手は48手あります。あまり追求しないようにしましょう。

395 ：仕様書無しさん：2007/04/11(水) 23:52:28

>>391
ｗｗ

396 ：仕様書無しさん：2007/04/11(水) 23:53:40

>>393
>使うな
その理由を、説明できるもんなら説明願います。

397 ：仕様書無しさん：2007/04/11(水) 23:58:15

>>396
じゃあ使え

398 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/12(木) 00:12:37

>>396
１）　遅い。　劇重。　重さ１０倍。（当社比）
　　　使ったシステムは後で必ず後悔しているが、変更箇所が膨大になるので直せない。

２）　テーブル名をキーワードに探したりすると漏れる。メンテナンスが把握できない場合がある。

399 ：仕様書無しさん：2007/04/12(木) 01:11:07

>>392
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ

Ｑ１．テーブル１つに対してクラスを１つ作った方がいいの？
Ａ１．違う。パラダイムに沿ってクラスを作る。
テーブルが１つになることもあるし複数になることもある。

Ｑ２．結合の場合はどうすんの？
Ａ２．お好きに。

Ｑ３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
Ａ３．呼び出し元言語でハードコーディングしなくて良いようにするのがよい。

400 ：おじゃばさま：2007/04/12(木) 14:36:32

>392
まず、オブジェクト指向とSQLデータベースは相性が悪いと言う事を認識しておく必要がある。
そのため効率の悪い実装をしなければならない所があるが、そこは割り切る必要がある。

>１．テーブル１つに対してクラスを１つ作った方がいいの？
結果から言うと、テーブル1つに対してクラスは2個にするのが無難だ。
クラス2個と言うのはSQL実行用のクラスと、1レコード格納用のクラスだ。
OOの基本から言えばクラスは誰かが言っていた「パラダイム毎」になり、SQL実行用とレコード格納用
クラスは分けるべきではないだろう。しかし「パラダイム毎」と言うのは分かりにくく、
SQL実行用とレコード格納用クラスが1つになった物は、別の所で使いにくい。ここが相性の悪い所だ。
ここは割り切って、次のように設計する。

401 ：396：2007/04/12(木) 14:36:39

>>398
あー、あんたは答えなくていい。

402 ：仕様書無しさん：2007/04/12(木) 14:38:43

>>400
>SQLデータベース
なんだこりゃ。

403 ：おじゃばさま：2007/04/12(木) 14:51:45

「厳密なオブジェクト指向ではないではないか！！」と言われれば、確かにその通りだ。
実際にはもっとオブジェクト指向の書き方もあるが、実用性を考えて妥協している。

// レコード格納用
class RecUser{
　　private int id;
　　String name;
　　public int getId(){return id;}
　　public void setId(int i){id = i;}
　　public String getName(){return name;}
　　public void setName(String n){name = n;}
};

// SQL実行用
class ExeUser{
　　public int executeInsert(RecUser rec){...}
　　public int executeUpdate(RecUser rec){...}
　　public int executeDelete(RecUser rec){...}
　　// 検索用
　　public boolean executeSelect(...){...}
　　public RecUser next(){...}
　　// 一括検索用
　　public List executeList(...){...}
};

DBのopenやcommitなどはクラスを作成し、SQL実行用クラスのベースクラスにするといい。
検索に「検索用」と「一括検索用」があるのは、メモリ使用量を考慮しての事だ。
本来なら一括検索で全部リストに格納したいが、検索結果が数万件になったり、大量に同時アクセスが
想定される場合は、内部でResultSetを保持した「検索用」を使う。

404 ：おじゃばさま：2007/04/12(木) 14:55:09

>402
SQLのような文章解析型の制御を使ったDBを、SQLデータベースとした。
OOと「文章解析型の制御」は相性が悪い。同様の物にprintfなどがある。

405 ：仕様書無しさん：2007/04/12(木) 14:56:39

Factory+TableでDIパターンだろ

406 ：仕様書無しさん：2007/04/12(木) 15:18:14

うん、そーやって自分自身のフレームワークを作る努力は大切だ。がんばれ

407 ：仕様書無しさん：2007/04/12(木) 15:30:20

おじゃばさま製O/Rマッパに期待わくわく。

おじゃばさま ◆Fy0HoitUDwとは違うおじゃばさまなのか？

408 ：仕様書無しさん：2007/04/12(木) 15:34:55

>>404
俺用語使うな間抜け。
つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。

409 ：仕様書無しさん：2007/04/12(木) 15:58:21

結合に関しては、例えば100(record)×100(record)の検索より
100の中間表(もしくはview)を2つ作ってからスキャンかけたほうが、元のデータベースのパフォも総合的にみたパフォもいい(viewは大雑把に言うとメモリ上だから)。
更に、
begintrans→中間表作成→検索→更新→commit(rollback)
とやると、他のアクセスが詰まったりするので、
元表に更新(中)columnと、更新クライアント名column、(場合によって、更にタイムスタンプcolumn)。そして、
begintrans→中間表作成→元表の更新columnに更新フラグを立て、更新クライアント名columnに自分の番号(名前)を入れる→ここで一旦commit→あとはゆっくり中間表検索&更新処理→終わったらフラグを下ろす。
(更新フラグが立っているので他は更新できないルール(トランザクションのロックではない))。
この一回トランザクションを切るやり方はデッドロック回避にも使える。
また、別のやり方として、更新フラグ表(マトリックス表)見たいな表を作っておいたて似たような動作をさせたり、更にこれを自動化できるレプリケーションを使う手もある。
(そういえば、wait　for　graph(待ち合わせグラフ)とかいうデッドロック検出用のマトリックスを積んだDBもあるとかないとか)

410 ：仕様書無しさん：2007/04/12(木) 17:11:59

動作が糞遅い。

411 ：仕様書無しさん：2007/04/12(木) 17:59:59

誰も聞いてくれない話をここに放出して、気持ちよかったか？

412 ：おじゃばさま：2007/04/12(木) 18:22:37

>407
上記構造は実用的だが理想には遠い。個人でさらに良い方法を研究することを望む。
また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。

>408
>つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。
すまんが、何を言いたいのか分からない。

>409
OOの話とは関係ないが、巨大な中間表の結果から更新をするような設計自体が間違いの可能性が高い。
WEB等で途中に人の入力が介在する場合は、更新日時によるチェックを行うが、それ以外でフラグ等による
更新チェックを行う場合は少ない。まあ実際の使用例を聞いてみないと分からないが。
適切に正規化されている場合は、検索結果で更新する事はまれだし、適切にテーブル分けしてあれば、
レコードロックによる更新で影響を受ける範囲は少ない。

413 ：おじゃばさま：2007/04/12(木) 19:15:00

>392
>２．結合の場合はどうすんの？
簡単な結合の場合は、格納クラスと実行クラスをそれぞれextendsして、ベースクラスに項目を追加して
使用する。複雑な結合の場合は、新たにそれ専用のクラスを作る。

>３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
まずストアドを使う意味を確認しておこう。
ストアドの利点としては、大量の検索を伴う集計処理や更新処理で使用する事により、
ネットワーク上を流れる大量の検索結果やSQL文を軽減する事にある。
参考までに、欠点はデバックが困難だということだ。
ちなみに、現代の高速ネットワークの上では、ストアドの利点はあまりない。
誰かが使うなと言った人はそのためだろう。
使う場合は、大量のまとまった処理に使う。数個のパラメータを渡して、ストアド内部で処理を行い、
ロールバックやコミットも内部で行い、結果をOK/NGで返すぐらいにするのが望ましい。
そうなると呼び出し側は1つの普通のクラスで構わない。

414 ：仕様書無しさん：2007/04/12(木) 19:45:59

なんだよ。また口だけか

415 ：仕様書無しさん：2007/04/12(木) 21:48:35

オラクルのストアドの作り方って、
SQLサーバーと似たようなもの？それとも、全然違うの？

416 ：仕様書無しさん：2007/04/12(木) 22:41:25

インスタンスとオブジェクトの違いってなんすか？

417 ：仕様書無しさん：2007/04/12(木) 22:53:56

>>409
バージョンカラム使った楽観的排他と比べてどうなん？

418 ：仕様書無しさん：2007/04/13(金) 00:16:14

＞また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。
まあ、いろいろまずいからごまかしてる、でおｋ？
パスワードｗとやらは変えればいいじゃないか？

同一人物では困る事情でもあるならべつだけどねｗ
で、O/Rマッピングはうまくできたのかな？

419 ：仕様書無しさん：2007/04/13(金) 01:24:31

>416
オブジェクト：
　　　　オブジェクト指向における基本単位。「もの」の意味。
　　　　文字列だったり、リストだったり、型だったり、数値だったり
　　　　ボタンだったり、テキストボックスだったり
　　　　クラスだったり、メソッドだったり、何かのデータだったりする。

インスタンス：
　　　　あるクラスを基にして作られたオブジェクト。
　　　　「文字列クラスのインスタンス」なんて言ったりする。

420 ：仕様書無しさん：2007/04/13(金) 01:41:33

オブジェクト指向以外禁止だからキツイ。
最近になって解ってきたけど多態性がポイントだな

421 ：仕様書無しさん：2007/04/13(金) 06:55:25

>>392
　データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア
開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で
データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が
数多く巻き起こっている。

アプリケーション開発者の多くはRDB のことを裏側に隠しておくのにちょうどいいストレージ
装置だと思いがちだ。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

422 ：仕様書無しさん：2007/04/13(金) 06:57:31

> 同一人物では困る事情でもあるならべつだけどねｗ

同一人物だけど、同一人物ではないと思ってほしいだけだろ。
素性はバレバレだがｗ

423 ：仕様書無しさん：2007/04/13(金) 07:04:25

マーチンの言うトランザクションスクリプトには、
ピン(凝ったＳＱＬやストアドプロシージャ使いまくり)から
キリ(構造化プログラミングで処理を書きまくり)まで
いろいろなケースが含まれる。

424 ：仕様書無しさん：2007/04/13(金) 08:32:41

>>423
そだね、今はSQLJとかC#ストアードプロシージャとかパススルーあるしね、Martin Fowlerは
あらかじめOOPSにバイアスを掛けた見方（偏った？）を前提に、あの文章を書いてると思う

手続き型プログラミングでも問題が無いところを、わざわざロジックとデータロード操作と
切り分けて同一ソースへのアクセスの際の利便性を強調しているが、1度しか使用され
ないデータ抽出と集計するロジックを別クラスとした場合、見る人により不明瞭だろう

>>413
OODの問題として捕らえると1：1もしは1：Nとした場合の爆発的なクラス増加と、継承を
使用する前提とした場合の見通しの悪さがある、一般的にプログラマーは同じ処理を他人
より短く速く短時間で書ける事を誇りにするから、継承を使いたがる気持ちが分からないでもない

確かにいまどきは1：1で設計するのがほとんどであろう、ただ結合の場合においてはそのやり方では
疑問が残る、パフォーマンスとソースのメンテナンス性はトレードオフではないのだからOOP以外の策も
今後考慮されるべきであろう

>>398
簡潔すぎると一般の人には分かりませんよ・・

425 ：仕様書無しさん：2007/04/13(金) 09:16:07

きみの文章はヘタクソだ

要点を簡潔に書く訓練をしたまえ

426 ：仕様書無しさん：2007/04/13(金) 09:19:14

妄想を暗黙の了解事項として書くから
主旨の読み取れない意味不明な文章になるのだと思う

427 ：仕様書無しさん：2007/04/13(金) 09:34:59

いいから藻前ら句読点つけろ。

428 ：おじゃばさま：2007/04/13(金) 09:41:32

>416
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
オブジェクト=クラス=型
インスタンス=値
つまりクラスがオブジェクトで、クラスをnewしてメモリ確保したのがインスタンス。

429 ：仕様書無しさん：2007/04/13(金) 11:53:17

まだ鳥の付け方もわからんのか
流石アホコテ

430 ：おじゃばさま ◆Fy0HoitUDw ：2007/04/13(金) 12:10:48

私は愚か者です
首吊ってきますｗ

431 ：仕様書無しさん：2007/04/13(金) 12:14:26

>ttp://rina.nadenade.com/nackey/talks/nnn/2000/11-2.html
＞中には「クラス=オブジェクト」というなかなか理解しがたい解釈をされる方もいて、
＞この人がまたソフトを飯の種にしているっぽいので頭が痛いです(笑)。
w

432 ：仕様書無しさん：2007/04/13(金) 12:21:44

>>415
も答えてください。
オラクルの現場、何故か、当たった事ないのです。

433 ：仕様書無しさん：2007/04/13(金) 12:30:35

あるひとは「もの」の本質は「おなじようなものを集めた集合」にあるといい
また別のあるひとは「もの」は「おなじようなものを集めた集合に属する要素」だという。
どちらも正しい。

しかし、「もの」とは「おなじようなものを集めた集合」そのものに等しいなどという戯言は
笑止千万

434 ：おじゃばさま ◆Fy0HoitUDw ：2007/04/13(金) 12:31:21

愚かですいません

435 ：仕様書無しさん：2007/04/13(金) 12:45:42

ラッセルもﾋﾞｸｰﾘ

436 ：仕様書無しさん：2007/04/13(金) 13:35:12

>ttp://book.geocities.jp/bits_of_java/java/lang/instance/index.html
＞前出のようにクラスを具現化したものはオブジェクトですから
＞インスタンスはオブジェクトを指して使う言葉という事になります。

本当にあ(ry

437 ：仕様書無しさん：2007/04/13(金) 14:32:09

http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E3%81%A8%E3%82%A4%E3%83%B3%E3%82%B9%E3%82%BF%E3%83%B3%E3%82%B9&num=50

438 ：仕様書無しさん：2007/04/13(金) 14:32:20

「クラスを具現化したもの」なら「インスタンス」の方が適切だな

439 ：仕様書無しさん：2007/04/13(金) 14:32:47

>>436
お前があ（ｒｙ

440 ：仕様書無しさん：2007/04/13(金) 14:37:57

>>438同意

おバカさまはクラス・オブジェクトが存在するような言語では

　クラス⊂オブジェクト

なのを知って、クラス＝オブジェクトという妄念を得たのではないか？

441 ：仕様書無しさん：2007/04/13(金) 15:06:14

>>415
シカト？

442 ：仕様書無しさん：2007/04/13(金) 15:15:10

しょうがねえな。
>>415
おまえもｽﾚﾀｲ100回音読の刑に処す。

443 ：仕様書無しさん：2007/04/13(金) 16:54:02

>>おじゃば
おじゃばさまはようやくコテの付け方を覚えたか
おじゃばさまが愚か者であることは皆知ってるから謝る必要は無い
それより、俺愚かだからお舞ら教えろと言った方が良いぞ

444 ：仕様書無しさん：2007/04/13(金) 17:57:05

おいおじゃば、また名前付け忘れてるだろ

445 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/13(金) 21:58:45

>>401
死ねよ
てめーわよ

446 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/13(金) 22:02:25

>>431
じつはＭＳのＶＣ＋＋初期のライブラリのマニュアルではクラスとインスタンスをごっちゃにしてる。
ＭＳのマニュアル読むべし。
ＭＳ自体判ってなかった。

447 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/13(金) 22:07:45

それからＭＳのＶＣ＋＋でコントロールなどを自動生成すると
呼び出し元の情報が埋め込まれてしまって部品化されていない。
そのコントロールをおいたダイアログ上からしか呼び出せなかったりする。
これはクラスの親子関係と呼び出しの親子関係をごっちゃにした結果である。

448 ：仕様書無しさん：2007/04/13(金) 22:24:02

なんつーか詭弁もいいとこだな

449 ：おじゃばさま：2007/04/13(金) 22:31:08

>424
クラスの爆発的増加はシステムによっては発生する。
継承を用いた方式では古典的な名前を用いた分類で対応する。
つまり、クラス名をRecUserExとかRecUserAndProductなどにして、関連性を見せる。
また複雑な結合に対しては、Viewを作成し、そのView名に関連したクラスを作る事でメンテナンス性を
確保する。ただそれほど良い方法でないのも認めているので、OO以外の考慮に対しては異存はない。

>432
SQLサーバの方は詳しくは知らないので、他の人に聞いた方がいい。
ただSQLサーバの方はデバッカも充実していて、他のMS製品とも相性がいいので、PL/SQLほど避ける
必要はないと思う。

>リンク厨
広い意味ではクラスもインスタンスも、オブジェクトなので解釈が分かれる。
だから誰かが間違っていると言うつもりはない。それぞれの意見にはそれなりの主張がある。
ただ、リンク張って満足している輩は、もう少し頭を使う訓練をしたほうがいいと思う。

450 ：仕様書無しさん：2007/04/13(金) 22:50:31

バカ

451 ：仕様書無しさん：2007/04/13(金) 22:59:10

だいたい思い出した、おまえさんの方法論。
ただそれがなんでここまで崩れてボロボロになってるのか、
それはよく判らない。

おまえ結局、大きなトラウマを持っていて、
ネットワーク上で暴れないと気が済まないんだろ。
もうやめておけ。こんな戯れ文書き散らかしても
おまえ自身がボロボロになるだけだ。

452 ：仕様書無しさん：2007/04/13(金) 22:59:31

バカ

453 ：仕様書無しさん：2007/04/13(金) 23:00:18

ﾁﾝﾎﾟ

454 ：おじゃばさま：2007/04/13(金) 23:08:45

>451
誰に言っているのだ？
俺か？リンク厨か？

455 ：仕様書無しさん：2007/04/13(金) 23:10:24

バカ

456 ：仕様書無しさん：2007/04/13(金) 23:11:34

おバカさまﾀｲｰﾎ

457 ：仕様書無しさん：2007/04/13(金) 23:19:33

　　　　　＿
　　　　　＼.＼　　　　　バカでもチンポでもいいから勝手にやってくれ
　　　　　　 |＿|
　　　　　／　　＼　／＼＿
　　　　　|　　　　／　／　♯＼＿＿
　　　　　|　　　./　　/　　※　♯　※＼＿＿＿＿
　　　／ ,＼＿/　　/　♯　　※　　♯　　　.／／
　／＿＿＿/　　　￣￣￣￣￣￣￣￣￣／

458 ：仕様書無しさん：2007/04/13(金) 23:22:39

めんどくせーから全部グローバル変数でいいよ

459 ：仕様書無しさん：2007/04/14(土) 01:20:00

DLLってCとC＋＋（OOスタイル）のどっちで書いた方がいいの？
今の現場でC＋＋わかる人いないんだけど、
できるならC＋＋でもいいよ（保守性などをふまえてて、物ができればなんでもいいよ）、って言われてて。
教えてｴﾛい人

460 ：仕様書無しさん：2007/04/14(土) 01:32:18

アセンブラ

461 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/14(土) 01:33:38

自分の得意なほうでいいんじゃない？

462 ：392：2007/04/14(土) 01:40:19

高度すぎるのかなんなのか分かりませんけど、
ココ電球さんは言ってる忌みがよく分かりません。（何が言いたいのかもなぞです、すみません）
おじゃばさんは叩かれてるけど言ってる忌みは分かります。

＞おじゃばさん、他ヒント頂いたｴﾛい方々
ヒントありがとうです。
まだ迷い中・考え中ですけど、
方向性が見つかったのでうれしいです。

でもストアドはデバッグが大変なのか・・・（知識不足で申し訳）
一度に４万件ぐらいのレコードあるんですが、う～ん・・・
つか、これはスレ違いだからいいっす！サンキューです！

463 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/14(土) 04:37:12

おじゃば自演すんなよ　おまい

464 ：仕様書無しさん：2007/04/14(土) 07:50:13

クラス＝オブジェクト、であれば
hogeクラスのfugeオブジェクト
とかいう書き方が日本語としておかしいことになります。簡単ですね。
ひょっとして、おじゃばさまは職場で
boke(クラス名)オブジェクトのkasuインスタンス
などと説明してるんでしょうか･･･それは恥ずかしいんじゃ･･･

465 ：仕様書無しさん：2007/04/14(土) 11:18:06

>>459
俺はC++で書いてラッパー関数作って extern "C" でレギュラーDLLとしてエクスポートしてる。

466 ：仕様書無しさん：2007/04/14(土) 22:35:41

だいたい、「狭い意味でクラス＝オブジェクト(型)」とか言い切って
つっこまれたら「広い意味で全部オブジェクト」かよ。
Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
「おじゃばさま」って名前はもうやめたら？馬鹿なんだし。

467 ：仕様書無しさん：2007/04/14(土) 22:41:46

あいつあれでも、業務コンサル会社のCEOだそうです。
全然評判聞かないけどｗ

468 ：仕様書無しさん：2007/04/14(土) 22:42:59

は？Javaのクラスはオブジェクトだろ普通に。

Object o = String.class;

469 ：仕様書無しさん：2007/04/14(土) 22:52:18

暇暇コンサル

470 ：仕様書無しさん：2007/04/14(土) 22:53:11

特技：初心者教育

471 ：仕様書無しさん：2007/04/14(土) 23:03:09

知能および性格が著しく劣悪な池沼が
誰かに構ってほしくて暴れているようです。
スルーでお願いします。

472 ：仕様書無しさん：2007/04/15(日) 19:40:36

ロジックのセンスがない椰子がほとんどの業界で
オブジェクト指向など100年早いね。

473 ：仕様書無しさん：2007/04/16(月) 12:55:43

暴れるぞ＾

474 ：おじゃばさま：2007/04/16(月) 12:56:17

>463
自演してない。
一応、電球の発言を簡単に説明しておくと、
446の発言趣旨は言語開発元のMSですら、オブジェクトとインスタンスの定義が曖昧だと言うことで、
447でその例して、オブジェクトの親子関係と、呼び出し元先関係を混同していると言っているのだろう。

>464
何が恥ずかしいのか分からない。

>466
>Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。
466の言うオブジェクトの定義が分からない。俺も468と同意見。

475 ：仕様書無しさん：2007/04/16(月) 16:56:35

それが属しているのがobjectクラスを基底にするクラスであることと、
その属しているクラスがオブジェクトであることは違うだろうよ･･･
本気でわかんないんだな、おじゃば。>468はどーみても釣りだろ。

476 ：仕様書無しさん：2007/04/16(月) 18:33:45

は？Java知ってっか？

Object o1 = new String();
Object o2 = String.class;

477 ：おじゃばさま：2007/04/16(月) 18:55:48

>475
オブジェクト指向の「オブジェクト」を最も良く表した物が、Javaの「Object」だと思うが。
釣りじゃないんじゃね？476でも言っているし。

478 ：仕様書無しさん：2007/04/16(月) 19:38:50

オブジェクト指向は理想と現実のギャップが大きいよ。

479 ：仕様書無しさん：2007/04/16(月) 19:41:52

たとえば？

480 ：仕様書無しさん：2007/04/16(月) 22:39:35

オブジェクト指向におけるオブジェクトの定義が
"コンピュータ上におけるクラスのインスタンス"なんだが。
コンピュータとは無関係に定義される抽象的な対象もオブジェクトって言われるから紛らわしいけど、
まともな本や論文ならオブジェクトはクラスのインスタンスの意味で使われてるよ。

481 ：仕様書無しさん：2007/04/16(月) 22:52:22

クラスもメタクラスのインスタンスなんだぜ

482 ：仕様書無しさん：2007/04/16(月) 22:59:51

Javaで例えるとこうか？

Object o1 = new String();
Object o2 = String.class;
Class c = String.class;

483 ：仕様書無しさん：2007/04/16(月) 23:00:36

実際にプログラミングあんまりしないからわからんが
カプセル化しないとバグ増えたりするのかね

484 ：仕様書無しさん：2007/04/16(月) 23:06:29

ただ単にカプセル化すりゃいいってもんじゃあないな。

オブジェクトがぶっ壊れないように、アクセッサでガードしなきゃ。

485 ：仕様書無しさん：2007/04/16(月) 23:56:12

だからよ。つくんのに、じかんがかかりすぎんだよ。プログラムなんて糞だぜ。
1年かけて作っても、独りよがりのものしか作れ無かったよ。
とっととやめちまえ。

486 ：仕様書無しさん：2007/04/16(月) 23:57:57

>>484の人気に早くも嫉妬

487 ：仕様書無しさん：2007/04/17(火) 00:02:54

遠慮せず突っ込みたまえ。

488 ：仕様書無しさん：2007/04/17(火) 00:05:38

>485
時間が掛かる時に使うと良い感じ。
OOに速さはあんまり求めない方がいいよ。
処理速度も開発速度も。

489 ：仕様書無しさん：2007/04/17(火) 00:20:27

処理速度も開発速度も、現実問題OOとあんまり関係ないよ。

手続き型で書いたRubyと、OOで書いたC++の
どっちが速い？

OOで書いたRubyと、手続き型で書いたC++の
どっちが早くできる？

490 ：仕様書無しさん：2007/04/17(火) 00:23:25

スクリプト言語と・・・

もう帰っていいよキミ

491 ：仕様書無しさん：2007/04/17(火) 00:31:05

>>490
おまえ国語力ないな

492 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/17(火) 00:43:12

アクセッサなんか９９％使わない。
疲れて書かなくなったころ書いたのに必要だったり、上位層で書くの忘れてたのに必要だったりする。
必要になってから書いても遅くない。

493 ：仕様書無しさん：2007/04/17(火) 00:50:14

じゃあRubyでアクセサ無しでコード書いてくれ

494 ：仕様書無しさん：2007/04/17(火) 00:53:10

>>493
グローバル変数【これを君にあげましょう。】

495 ：仕様書無しさん：2007/04/17(火) 00:54:02

>>492
必要になってから書いても遅くないってことは、無いよりあったほうがいいってことか？

496 ：仕様書無しさん：2007/04/17(火) 00:57:12

＞アクセッサなんか９９％使わない。
使わないっておかしいだろ。
フィールドがprivateなら使わざるを得ない。

フィールドをpublicにしても９９％問題ない、ならまだ意味はわかるが。

497 ：仕様書無しさん：2007/04/17(火) 00:59:03

相変わらずOOの「設計」についてはスルーされてんだな

498 ：仕様書無しさん：2007/04/17(火) 01:00:47

だから、
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
クラス=型(+メソッド）
オブジェクト=インスタンス=実体（値+メソッド参照)
つまりクラスをnewしてメモリ確保したのがインスタンスでありオブジェクト。

499 ：仕様書無しさん：2007/04/17(火) 01:02:33

オブジェクト指向に設計と実装を隔てる垣根など無い。

500 ：仕様書無しさん：2007/04/17(火) 01:03:36

とりあえずnewしとけばおｋなスレはここですか？

501 ：仕様書無しさん：2007/04/17(火) 01:06:08

SDP原則により、自作クラスはnew禁止な。よく覚えとけ。

502 ：仕様書無しさん：2007/04/17(火) 01:06:20

>>499
とりあえずクラス図ぐらいは書いとけよな
「ソースが最新です」な奴はOOの利点捨てとるやろ

503 ：仕様書無しさん：2007/04/17(火) 01:08:16

>>501
全部クラスメソッドっすかｗ

504 ：仕様書無しさん：2007/04/17(火) 01:08:23

OOの利点って？

505 ：仕様書無しさん：2007/04/17(火) 01:13:49

メッセージ・UML・モデル化

506 ：仕様書無しさん：2007/04/17(火) 01:16:17

>>505
利点か？どうみてもなんかの手段だろ
なんの手段なんだ？

507 ：仕様書無しさん：2007/04/17(火) 01:21:20

OO＝手段じゃん
499が設計をそんまま実装概念に落とせるって話なら
それでいんじゃね？
あんまかみつくなよ。茶でものもうや

508 ：仕様書無しさん：2007/04/17(火) 01:24:24

>>507
わりい。噛み付いたつもりはない。
クラス図書くと何がいいのか、単純な興味から聞いてみただけ。

509 ：仕様書無しさん：2007/04/17(火) 01:30:14

しっかりしたクラス図があった場合、
メンテ・拡張が入る場合にクラス図を見れば、
どこに手を入れればいいかそれなりに分かる。
ソースをいきなり見るような無駄は無くなる。

なんでもかんでもpublicなんてことをやると手間がかかってしょーがない
つか、良識のあるPGはそんなことせんし

510 ：仕様書無しさん：2007/04/17(火) 01:38:56

クラス図メンテのコスト＜ソース見るコスト
って常に成り立つかなあ。ちょっと懐疑的。

オプソなんてクラス図ついてないのばっかだけど、
どこ拡張すればいいかなんてすぐわかるし。

511 ：仕様書無しさん：2007/04/17(火) 01:44:50

そりゃソース見るのに慣れてるだけの話

512 ：仕様書無しさん：2007/04/17(火) 01:50:21

ついでに言えば、OOは手段なだけ。
オブジェクト間をメッセージでつなげる。これが本質。
この分析をモデル化するだけなんやし。
コーディングも設計の一環でコンパイルが製造って言うならまあありかもしれんけど。

513 ：仕様書無しさん：2007/04/17(火) 01:56:09

ケイのほうのオブジェクト指向のメリットはいまだにわからん。

514 ：仕様書無しさん：2007/04/17(火) 01:57:03

さらに寝る前のついでに言えば、
たとえば地図とかのシステム作る場合なんかだと、
地図にもいろいろ種類あって、道路地図・地形地図・分布地図？とかあると思うんやけど
それぞれがクラス化されてればソース見なくても
「地図に信号足して」
なんて話になれば道路地図クラスやな、となんとなく分かる。
grepもいいけどソースだけで業務概念が分かるかどうかは微妙やね。

515 ：仕様書無しさん：2007/04/17(火) 06:06:36

ところで、Java ってスクリプト言語みたいに

MyClass obj = new MyClass();
Class klass = obj.class;
MyClass obj2 = new klass();

みたいな事って出来たっけ？

516 ：仕様書無しさん：2007/04/17(火) 08:59:18

真性のバカと判定

517 ：仕様書無しさん：2007/04/17(火) 10:17:35

>>516
だがBakaクラスのインスタンスにis_baka()をしても「バカじゃない！」って文字列が返ってくるんだろうな

518 ：仕様書無しさん：2007/04/17(火) 13:02:33

>>513
これは読みましたか？
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

キーコンセプトはメッセージングを介した徹底した動的性の追求です。
（現在主流のオブジェクト指向では、意味も分からず「オブジェクトへのメッセージ送信」と
　お題目化されたり、ポロモルフィズムに包含されたりひどいことになっていますが…）
他の言語では（動的性に関しては）LISPのそれに近いですね。
言語以外では生物のしくみやネット（特にインターネット）に似せています。

変化に強いシステム（たとえば、止めることなしに走らせつつ拡張したり、
修正できたりする…など）を実現できる…というのが、まあ、メリットでしょう。
たとえば、これを実践しているSmalltalkは30年来、再起動ということを
数えるほどしかしていません。生命、インターネットもしかりですね。

519 ：仕様書無しさん：2007/04/17(火) 14:18:15

手段って。
何を実願するための手段なの？

520 ：仕様書無しさん：2007/04/17(火) 14:53:48

>>515は何でも発想してみるのはいいけど、
そんな簡単なコードは実際に実行してくれ。

少なくとも、newのオペランドは基本型かクラス（又はその配列）であって、
インスタンス（ここではklass）ではない。

521 ：仕様書無しさん：2007/04/17(火) 16:03:35

>>520
もしJavaでクラスがオブジェクトだと言うなら
コレもできるか？と思ってね。
PythonやRubyだと完全にクラスはオブジェクトだから
そういうことが出来てしまう。

そもそもクラス定義文自体が単に
クラス型のオブジェクトが変数や定数に入るだけだし。

522 ：おじゃばさま：2007/04/17(火) 19:21:04

俺はクラス図とかUMLを保守資料として残す意味はないと思っている。
仕様変更が入った場合、最も効率のいい方法は、作った本人に修正させる事だ。その場合、クラス図は不要だ。
「当たり前だ、作った人がいないから問題なんだ！！」と言う抗議が聞こえてくるが、その通りだ。
ここで他人が修正する上で、注意しなければならない点は2つある。
・最初から作るより、ある物を修正する方がスキルが必要。
・知らないシステムを修正する場合は、修正量にかかわらず、ある一定の時間（コスト）が必要。
上記の内容を、ぶっちゃけて言い替えると以下のようになる。
・ソース読めない奴には修正させるな。
・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
と言う事で、結果的にクラス図は不要になる。
ちなみにメンテナンスされない保守資料は不要どころか有害である。
UMLやクラス図はコーディング完了時に破棄するのが望ましい。

523 ：仕様書無しさん：2007/04/17(火) 19:37:38

>>521 リフレクション使えば
MyClass obj2 = klass.newInstance();
という書き方はできる。

524 ：おじゃばさま：2007/04/17(火) 19:42:51

ところでオマエラ、
「要求仕様聞いただけでソースコードが人」とか、
「ソースコード見ると、脳内で実行が始まる人」とかいない？
そういう事ってあるよな？

525 ：おじゃばさま：2007/04/17(火) 19:44:00

「要求仕様聞いただけでソースコードが見える人」な。、

526 ：仕様書無しさん：2007/04/17(火) 19:49:53

Doxygen使えよ。ソースからきれいなクラス図をつくってくれるぞ。ソースから
作るから、当然ドキュメントとしては最新状態が反映されたものになる。
ソースだけ読んで構造理解するよっか、クラス間の関連を掴むには便利。

527 ：仕様書無しさん：2007/04/17(火) 20:06:20

>>523
こうな
MyClass obj2 = (MyClass)klass.newInstance();

528 ：仕様書無しさん：2007/04/17(火) 20:07:44

>>526
それだと細かすぎんだよな。結局ソースみたほうがはやかったりする。

529 ：仕様書無しさん：2007/04/17(火) 20:19:08

クラスが何百もあるシステムの全体掴むのに一からソース読んでると辛くね？

530 ：仕様書無しさん：2007/04/17(火) 20:20:05

>>おじゃば
おじゃばが設計書読まない口頭主義なのは良く分かったが、
UMLはあくまでも分析なんよ。
顧客からの承認はどうすんだよ。結局なんちゃら仕様書ってのを作るんだろ
その一つがUMLなだけ。
それとも何か？いきなりコーディングか？

＞・ソース読めない奴には修正させるな。
＞・作者とは別の人に修正させる場合は、解析期間を十分に取れ。
＞と言う事で、結果的にクラス図は不要になる。

「ということで」、の意味がわからん
要はUMLを使いこなせて無いだけじゃん

531 ：仕様書無しさん：2007/04/17(火) 20:24:28

ソース＝仕様書と言ってるJava厨がいるスレはここですか？

532 ：仕様書無しさん：2007/04/17(火) 20:35:40

オブジェクト指向開発はなぜ流行らないの？スレで

UMLを使いこなせて無いだけじゃん

はないだろ。常識的に考えて。

533 ：仕様書無しさん：2007/04/17(火) 21:31:41

UMLは実装前の設計時「のみ」で使うべき「モデリング」

実装が始まったらどうでもいいです

実装が終わったらrationalやらroseやらdoxygenで抽出

実装と同時にuml書くなんて馬鹿、大馬鹿、死ねって感じｗ

534 ：仕様書無しさん：2007/04/17(火) 21:58:28

死ね。

535 ：仕様書無しさん：2007/04/18(水) 00:32:58

C++って変体言語だろ。
javaかdelphiにしろ。

536 ：仕様書無しさん：2007/04/18(水) 00:35:52

今日は基地が沸いてるな

537 ：仕様書無しさん：2007/04/18(水) 01:25:36

今日は？　今日もだろ

538 ：仕様書無しさん：2007/04/18(水) 01:36:02

こっちの板はもちろんそれがデフォ。

539 ：仕様書無しさん：2007/04/18(水) 09:42:13

>>533
ラウンドトリップしないの？

540 ：仕様書無しさん：2007/04/18(水) 10:09:16

>>530
相手するだけ無駄。

541 ：仕様書無しさん：2007/04/18(水) 11:07:43

>>530
>おじゃばが設計書読まない口頭主義なのは良く分かったが、
自分は単に「ソースコード至上主義」と読みましたが

542 ：仕様書無しさん：2007/04/18(水) 14:12:33

>>541
>>おじゃばが設計書読まない口頭主義なのは良く分かったが、
>自分は単に「ソースコード至上主義」と読みましたが
自分は単に「統合失調症」と思ってましたが

543 ：仕様書無しさん：2007/04/18(水) 22:43:50

おじゃば、悲惨だな・・
530にあっさり論破され、基地にからかわれ・・
まあ、実力以上の無理せんでガンガレ

544 ：仕様書無しさん：2007/04/18(水) 23:13:43

流行ってるだろ。

545 ：仕様書無しさん：2007/04/18(水) 23:35:00

むしろ大流行かと

546 ：仕様書無しさん：2007/04/19(木) 00:01:17

むしろ大発生だろ　おじゃばみたいなしったかが

547 ：仕様書無しさん：2007/04/19(木) 00:11:43

オブジェクト指向のメリットがあるないで未だにもめてるこのスレで
UMLのメリットを自明であるように語るのは明らかに違うだろ。

クラス図を読むのはソース読むことよりかなり難しいのだが、おそらく
それすら知らないで、クラス間の関連がソース読まなくても視覚的に
わかるよわーいなんてレベルの奴らがUMLゆってるだけと感じてしまう。

具体的にUMLのメリットを示すべし。

548 ：仕様書無しさん：2007/04/19(木) 01:03:43

ソースより読みにくいクラス図なんて、むしろいらない。

549 ：仕様書無しさん：2007/04/19(木) 08:39:12

いるいる！>>547や>>548みたいな偽装連中！
自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
ってアランケイがゆってた

550 ：仕様書無しさん：2007/04/19(木) 08:50:22

>>547
クラス図だけ見てわかるような気にさせてしまうのが、問題なのかも。

551 ：おじゃばさま：2007/04/19(木) 09:41:54

>530
顧客からの了承でUMLなんか見せない。
顧客に見せるのは画面仕様書や画面遷移図などになるが、それもサンプル画面を作った方が正確で早い。
まあ、提出書類は決まっている場合も多いから、作らなければならない事も多いが、コーディング先でも
全然問題ないな。
UMLは新人や新しく入った人にプログラムを説明する時とか、複雑な処理を整理して考える時などに
使っている。UMLで顧客に説明？クラス図とかシーケンス図とか見せて説明するのか？
逆に聞きたいのだが、画面仕様ならともかく、顧客にクラス図やシーケンス図見せて分かるのか？

>531
「ソース＝仕様書」だよ。
何かおかしいのか？

>533
同意

552 ：仕様書無しさん：2007/04/19(木) 09:59:20

沖縄県の方へ（命に関わる注意事項です）

沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度　沖縄」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…

※一国二制度
　簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
　（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
　さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
　3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
　そして中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。

今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。

553 ：仕様書無しさん：2007/04/19(木) 10:10:07

>>549
>自分の勉強不足を棚に上げて「分からない！分からない！」と連呼
>ってアランケイがゆってた

kwsk

554 ：仕様書無しさん：2007/04/19(木) 11:46:00

>551
お前読解力ねーな・・・マジで
あとトリップつけろって
何回言われてもできないとかアホの典型か

555 ：仕様書無しさん：2007/04/19(木) 16:14:51

「ソース＝仕様書」
は正しい。
しかしながらその正論が通るところは少ないね。

556 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/19(木) 19:06:39

ソースに仕様を全部書く

557 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/19(木) 19:07:13

贅沢は言わないからマジックナンバーにコメントふってくれや

558 ：仕様書無しさん：2007/04/19(木) 19:57:12

お前は今すぐ死んでくれや

559 ：おじゃばさま：2007/04/19(木) 20:59:59

>554
理解力？何が言いたいのか分からないな。
俺が保守ドキュメントにUMLは不要だと言ったのを、554が全てのドキュメントが不要だと言ったと
勘違いしたのか？

ところでOOでメッセージがどうのとか言っていた人がいたが、何の事？

560 ：仕様書無しさん：2007/04/19(木) 21:13:55

むかしむかし、あるところに、OOでメッセージがどうのとか言っていた人
がおったそうな。

561 ：仕様書無しさん：2007/04/19(木) 22:23:44

オブジェクト同士のメッセージのことだろ
普通じゃん
さすが仕様書読まない奴だけあるなｗｗ

562 ：仕様書無しさん：2007/04/19(木) 22:42:35

>>551
うちは顧客にもUML（PJ内での拡張版）で説明する。
確かにサンプル画面は見てくれだけなら速いが、詰めが甘い。
そこでUMLで業務分析をした上で了承を取らんと。
コーディングが先でUMLを後で作るって時点で、おかしいだろ。
なんで分析ツールがあとで出てくるんだ？後だしならいらんし。そんなもん見らんわ。
つかさあ、担当者変わったあとでカスタマイズが入る度にソース全部追っかけてんのか？
めんどくない？

ソース＝仕様書ってのはオッケーだと思うが、
そのソース（仕様書）の分析をせずにコーディングするんだろ？
そこが謎。

あと他の奴も言ってるが、偽者うっとーしいからトリつけてくれや

563 ：仕様書無しさん：2007/04/19(木) 22:57:29

要求仕様書→UMLモデリング→顧客へ確認OK？→実装→だろ？

564 ：仕様書無しさん：2007/04/19(木) 22:57:53

クラス図でも、分析モデルと実装モデルとは用途がちがうぞ。

565 ：仕様書無しさん：2007/04/19(木) 23:01:11

UMLって描くのめんどいね

566 ：仕様書無しさん：2007/04/19(木) 23:02:40

>>563
スレタイ【OOD/P】の意味わかるか？

567 ：仕様書無しさん：2007/04/19(木) 23:03:36

話題沸騰ポットを知ってるか？

568 ：仕様書無しさん：2007/04/19(木) 23:08:39

>>566
OOAの話題はおいや？

569 ：仕様書無しさん：2007/04/19(木) 23:11:38

>>568
どうぞ

570 ：仕様書無しさん：2007/04/19(木) 23:15:49

OOD⊇OOAなんだけど？

571 ：仕様書無しさん：2007/04/19(木) 23:16:44

ポットの水とかお湯とかって本質的に不要だろｗ

572 ：仕様書無しさん：2007/04/19(木) 23:29:57

全然おもしろくないｗ

573 ：仕様書無しさん：2007/04/19(木) 23:31:13

ｗついてるやん

574 ：仕様書無しさん：2007/04/19(木) 23:35:01

>>559
お前まさか読めんのか？
「読解力」だよ

575 ：仕様書無しさん：2007/04/20(金) 11:41:34

>>559
>何が言いたいのか分からないな。
ばかだからでは？

576 ：仕様書無しさん：2007/04/20(金) 12:44:32

核心を突いてやるなってｗ

577 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/20(金) 22:53:29

>575
575の意見を思考停止という。
575はただの煽りとしても、思考停止を確信と核心する576には脱力だな。
まあ馬鹿じゃないんだろうけど、考えない癖がついているんだろうな。
でも何も考えない方が幸せになれるから、それはそれでいいのかもしれない。幸せになれよ。

578 ：仕様書無しさん：2007/04/20(金) 22:55:46

厨房だな・・・・

579 ：仕様書無しさん：2007/04/20(金) 22:57:15

アドレナリン中毒の愚かな野生動物だからな。

580 ：仕様書無しさん：2007/04/21(土) 00:38:13

>577
おもしろくありません
もうすこしがんばりましょう

581 ：仕様書無しさん：2007/04/21(土) 01:18:03

何だかんだ言って、技術ってすぐに過去のものになっちまうよな

582 ：仕様書無しさん：2007/04/21(土) 01:26:46

とはいえ今ある技術について行かなきゃ、次の技術が理解できないしな

583 ：575：2007/04/21(土) 01:42:47

>>577
そう、ただの煽りです。
でも、見たままの感想ですよ。
自分では気づいていない (莫迦故に) でしょうけれど。
>思考停止を確信と核心する
ほら。

584 ：仕様書無しさん：2007/04/21(土) 01:46:12

つまらん

585 ：仕様書無しさん：2007/04/21(土) 01:52:40

鳥付けてんのは偽もんだろ
モノホンは鳥も付けれんほど馬鹿だから

586 ：仕様書無しさん：2007/04/21(土) 02:02:47

アドレナリンからかうと面白いな。
アフォな事言い出してる所に水を向けると
10も20もレスを返してくる。

心にゆとりがないというか、
愚かで劣等感に苛まれている可哀想な人というかｗ

587 ：仕様書無しさん：2007/04/21(土) 02:06:05

おじゃばが食いつけそうなネタふることさえ出来なくなっちゃったの？
かわいそうにｗ

588 ：仕様書無しさん：2007/04/21(土) 02:46:25

・基本的にスルー力が足りないのだと思う。
・「荒しに反応するのは荒し」という経験則が、
　荒し検出に非常に有効である事が再確認できた。
・同様に「キ○○○という単語に過剰反応を示す奴は、
　たいてい本人がキ○○○」という経験則が得られた。

589 ：仕様書無しさん：2007/04/21(土) 03:12:24

オブジェクト指向で説明せよ

590 ：仕様書無しさん：2007/04/21(土) 03:19:09

猫はにゃーにゃーと鳴き
犬はわんわんと鳴き
蝙蝠は黙して語らなかった

591 ：仕様書無しさん：2007/04/21(土) 10:40:03

キチガイ、キチガイ、キチガイ、これがオブジェクト思考でつ

592 ：仕様書無しさん：2007/04/21(土) 11:03:19

VIPと間違えた。

593 ：仕様書無しさん：2007/04/21(土) 17:30:29

オブジェクト指向での製造方法を学ぶためには、
どういう点に注意したらいいですか？
クラスやインスタンスや継承など言語技術は理解していますが、
どうしても機能重視になってしまいがちで、
本質的に間違ってるという気持ちがあります。

594 ：仕様書無しさん：2007/04/21(土) 17:36:46

ほんとにやる気あるなら、メイヤーのオブジェクト指向入門よめ

595 ：仕様書無しさん：2007/04/21(土) 17:38:56

>>593
使う言語に応じてチームが使いやすいように設計すればいいよ
オブジェクト指向に本質とか意味ないし
但し一人よがりな設計はやめよう。チーム全体で理解出来るようにね
って書くと口だけで実践ともなってない奴とかがしゃしゃりでてくるんだろうけどなww

596 ：仕様書無しさん：2007/04/21(土) 19:04:00

なんだ似非コンサルの事か。
自覚症状があるならさっさと引退すればいいのに。

597 ：仕様書無しさん：2007/04/22(日) 07:56:46

>>581
技術って集中を分散の間を
ぐるぐる回っているだけだから、
止っていたら戻ってくるよ。

598 ：仕様書無しさん：2007/04/22(日) 09:31:34

シンプルに考えることを常に心掛けること。
デザインパターンが素晴らしいのもシンプルな考え方だからだね。
流行りものは、そこから概念だけを見切って、自分のフォースに取
り込むこと。がんばれ。

599 ：仕様書無しさん：2007/04/22(日) 09:45:26

「概念だけを見切って、自分のフォースに取り込む」＝半島人が俺様解釈でパクる行為のこと

600 ：仕様書無しさん：2007/04/22(日) 10:06:34

俺様解釈が新しいパラダイム生む。

601 ：仕様書無しさん：2007/04/22(日) 10:30:46

池沼の戯言

602 ：仕様書無しさん：2007/04/22(日) 11:37:15

最初からＯＯで入るからでしょ。
ＯＯが生まれた理由も価値もわからず、ＯＯを習うから結局、ＯＯが生まれることになった原因と同じような
ことを繰り返している。
gotoレスが叫ばれた時代と同じ。なにも考えずなにも疑問に思わないやつが使ってるから結局、元の木阿弥。

603 ：仕様書無しさん：2007/04/22(日) 15:13:56

価値が分かるの４０代？

604 ：仕様書無しさん：2007/04/22(日) 16:41:40

そんなことないだろ、新興会社でなきゃ、古い顧客も抱えてるから自然に触れるだろ過去のシステムも

605 ：仕様書無しさん：2007/04/22(日) 17:23:46

ウインドウ＝スレッドと思ってる香具師。

606 ：仕様書無しさん：2007/04/22(日) 20:05:01

モードレスダイアログのウィンドウプロシージャって別スレッドだっけ？

607 ：仕様書無しさん：2007/04/22(日) 20:31:16

だめりゃコリャｗ

608 ：仕様書無しさん：2007/04/22(日) 21:15:29

>>602
なんで伏字なんだよ。

と誤解されるのが日本で流行らない理由だな。きっと。

609 ：仕様書無しさん：2007/04/22(日) 21:16:48

せめて半角英数で書けばいいものを

610 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/23(月) 09:50:46

>593
言語仕様を理解しているなら次は「物をクラスで表現する事」だ。
まあ概念を説明しても今までと同じになってしまうので、実装方法から説明しよう。
機能で考えるてしまうと言うので、非OOでのC言語は理解していると仮定する。
まず構造体の要素を、クラスのprivateのフィールド変数に定義する。
次にそれぞれの変数のゲッターセッターを作る。そして機能毎に考えていた関数を分解して、
ゲッターとセッターの中に入れ込む。ちなみに機能毎に考えていた関数と、入れ込むゲッターは1:1に
なるとは限らない。どうしても入らない部分は、適当なメソッドを作って入れておく。

すべてのクラス分けが終わったら、一旦休憩した後に、もう一度クラスを見直す。
この時にクラスに相応しくないフィールド変数やメソッドがないか確認する。
例えば「商品クラス」に「顧客」の情報が入っていないかなどの確認だ。
ここで相応しくないと思った変数やメソッドは、相応しいクラスに移動する。適切にメソッドを作って
あれば、フィールド変数と関連するメソッドの移動だけで済む。ここでメソッドを移動しようとすると
別の変数を参照していて移動出来ないとか発生するが、これがうまくメソッド分けされていない部分である。
もう一度その部分を考え直して分離する。分離した時に前より複雑にならないように心掛ける。

611 ：仕様書無しさん：2007/04/23(月) 10:09:54

堕ちコン

612 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/23(月) 19:30:33

次に重要なのは「仕様変更を繰り返す」事だ。仕様変更を行う度にクラスを見直す事になるが、
正しく抽象化されていると、変更を繰り返しても構造が悪化しない。
悪化どころか、仕様変更の度に抽象度が増して、洗練されて行くのを感じるようになるだろう。
まあ、これを体感出来るようになるのは、普通の人で1～2年ぐらいかかるから焦る必要はない。

ちなみにデザインパターンや専門書は、上記の抽象化をマスターしてから見た方がいい。
抽象化も知らずにいきなりデザインパターンや専門書を見て、OOを理解出来る人などいないと思う。

613 ：仕様書無しさん：2007/04/23(月) 21:25:09

で？

このコテの文章って冗長なだけで
主観ばっかで何が言いたいかわからん

614 ：仕様書無しさん：2007/04/23(月) 22:28:40

作文だろ。文章能力を2chを使って養ってんだと思う。
素養の無さからくる整合性の欠落や、曖昧さ、そして中々上達
しないその様は見ていて痛々しいが、本人も一生懸命らしい。
ま、ほっといておいてやれ。
多分、この人の周りには、彼以上に優秀な人がいないのだろう。
そういう環境に長年浸って、自分を人一倍優秀だと勘違いして
しまったのだと思う。ある意味可哀想ではある。

615 ：仕様書無しさん：2007/04/23(月) 23:53:44

>>610
private変数のゲッターやセッターを作るんだったら
最初からpublicにすればいいと思ったのですが、
何か間違っているでしょうか？
ゲッター・セッターメソッドがづらづらと並ぶことにもなりますし、
変数が直接触れない以外、メリットがよく分かりません。

616 ：仕様書無しさん：2007/04/23(月) 23:55:51

>>610
アクセッサにロジック入れるのかよ(゜д゜)

617 ：仕様書無しさん：2007/04/24(火) 00:01:57

>>615
いやそうじゃない。private変数にはカプセル化の利点がある
いまさらそんな事言うまでもないがな。
つまりだ、お前は根本的に考え方が間違っている
りかい出来るまでは、オブジェクト指向の本を読みあさるんだ。
だんかいを踏んで、徐々に理解した方が今後の為にもなる。
なん度も繰り返しオブジェクト指向で考えれば必ず身に付くから。がんがれ

618 ：仕様書無しさん：2007/04/24(火) 00:06:43

>>617
レスありがとうございます。
ゲッターとセッターはprivate変数１個に対して１つずつ書くのですか？
これはカプセル化はカプセル化ですが、必要性がよく分からず・・・
private
int a;
int b;
public
getA();
getB();
setA();
setB();

619 ：仕様書無しさん：2007/04/24(火) 00:11:14

オブジェクト指向の本を読みあさった俺でも、
setter、getterをづらづら並べ、それをカプセル化言うのは何かが違うと感じる。

620 ：仕様書無しさん：2007/04/24(火) 00:20:08

気分的にはもうちょっと壊滅的に壊れてほしいな
ずいぶん手間隙かけたんだし

621 ：仕様書無しさん：2007/04/24(火) 00:23:39

つーか、どこの莫迦が getter/setter なんて発想をし始めたんだろう。
インスタンスの「状態」を戻す、あるいは変更するのが目的なんだから
内部変数と対応している必要なんざこれっぽっちもないってのに。

622 ：仕様書無しさん：2007/04/24(火) 00:27:58

>>621
入れ物として使われ始めたのはbeansからじゃね？

623 ：仕様書無しさん：2007/04/24(火) 02:59:00

極論すれば、Publicにするのは、インターフェースに限定するのが理想的。
内部変数はPrivateにして、公開しないのが原則。しかし場合によっては、
クラス内部でカウントされた値や、集計値などを公開する必要があるだろう。
その場合は、その値を、ゲッターとして実装し公開する。セッターはそのク
ラスの要件として必要な場合に限り公開する。

セッターは、グローバル変数に匹敵するぐらい危険な要素を孕んでいるこ
とを認識するべき。常に外部からの変更の可能性を考慮しないとならない
ため、人がコードを読む際にかかるストレスも大きくなる。private変数は
クラス外部からの変更の可能性は排除できるので、スコープを絞って集中
してコードを追うことができる。またメンバ変数は、そのクラスの機能を実現
するための必要最低限のものだけにするべき。当たり前だが、計算に使う
一時変数等をメンバ変数にしてはいけない。これもコードの可読性に関わっ
てくる。不要な情報は極力排除し、クラスのメンバとするべきではない。

OOの手法は開発時というより寧ろ、変更や保守性、拡張性といった方面での
貢献が大きいものだと思う。ゲッター、セッターを使うことで、値の代入に
対する仕様の変更があった場合に、その対応ロジックを１箇所に集中するこ
とができる。ゲッター、セッターを使わず直接代入していた場合、その代入
箇所すべてを変更しなければならないかもしれない。いわば事前にかけてお
く保険みたいなものだ。変更や保守がされないソフトウェアというものはな
いのだから。

624 ：仕様書無しさん：2007/04/24(火) 03:24:29

つーか、そんなに直代入使うか？
OOPやってると、セッタ自体滅多に使わないと思うんだが。

625 ：624：2007/04/24(火) 03:45:06

ちと言葉足らずか。
単に値チェックして代入するだけのセッタなんて使うか？
って訂正しとく。

626 ：仕様書無しさん：2007/04/24(火) 09:15:50

様々な言語で提供されるほとんどの文字列クラスにセッターがないことに気づいているか。
文字列長？そんなもの内部で適切に管理されている。中身を変更したい？ copy-on-writedだ。
つまりよい設計とはそういうものだ。必要の無いものは提供しない。よく分からないけどこの
メソッドはPublicにした方がいいかなぁ。と思うならPublicにするな。公開する時は信念をもって
公開しろ。無計画にメソッドやプロパティを公開してはならない。徒に混乱の種をばらまくような
ものだ。

627 ：おじゃばさま ◆GxjxF3yEw6 ：2007/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 ：仕様書無しさん：2007/04/24(火) 10:32:35

腐れコテがコテを付けたり外したりしながら独り言を書くスレ

629 ：仕様書無しさん：2007/04/24(火) 11:51:28

相変わらず主観だらけで冗長なだけ
挙げ句どっちかっつーと個人の感想止まりやんｗ

630 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/24(火) 19:16:08

>629
うるせーバカ。少しは頭使え、カス。

と、簡潔に書いてみた。

631 ：仕様書無しさん：2007/04/24(火) 19:19:37

de?

632 ：仕様書無しさん：2007/04/24(火) 19:25:47

>>630
うるせーバカ。少しは頭使え、カスキチオジャバ

633 ：仕様書無しさん：2007/04/24(火) 19:30:43

>>627
そのような”機能分類”したメソッドが存在するのは
すでに今まで自分でもうやってた手法です。
レコード文字列渡して必要なところだけセットする、とか。
もちろんprivateにするべきところ（と思ったところ）はそうしていました。

でも、これってオブジェクト指向って言うのでしょうか？
構造化プログラムとの違いがよく分からなくって・・・
違いといえばクラスと構造体ぐらいで、
構造体自体が関数持ってますよ（クラスで操作しますよ）、
ってぐらいしか違いが無いように思えるんです。

634 ：仕様書無しさん：2007/04/24(火) 19:34:01

>>630
昔の口調に戻ったな。うんうん。
やっぱりお前の知能程度にはそれくらいが丁度いい。

635 ：仕様書無しさん：2007/04/24(火) 19:37:21

>>633
もう1段階上の抽象化があるのだよ

636 ：仕様書無しさん：2007/04/24(火) 20:21:27

ちゅうしょーかっ！ってタカアンドトシもゆってた。

637 ：仕様書無しさん：2007/04/24(火) 20:29:03

>>628
要するに基地害の寝言スレ

638 ：仕様書無しさん：2007/04/24(火) 22:43:03

つまりは良く考えて作りなさいよ。ということだな。

639 ：仕様書無しさん：2007/04/24(火) 22:58:18

そうそう。お前の親に言っとけ

640 ：仕様書無しさん：2007/04/24(火) 23:03:48

ほんとになぁ・・・

641 ：仕様書無しさん：2007/04/24(火) 23:16:26

setter,getter作るだけでカプセル化とか、setter,getterを必ず作るとかいうアホが湧いとるな

とくにわけの分からんクソコテ
痛い突っ込みされてまたわけのわからんこと言うとる
中途半端にOOを知ってる奴が一番タチが悪い

642 ：仕様書無しさん：2007/04/24(火) 23:17:09

でも構造化設計が最高！ソースも見やすいしね。
オブジェクト指向は、部品だらけで、組合せがソースから見えないよ！

643 ：仕様書無しさん：2007/04/24(火) 23:20:18

ソースをテキストで作るのはもう古いのでは？！

644 ：仕様書無しさん：2007/04/24(火) 23:33:45

>643
これからの時代はパンチカードだな

645 ：仕様書無しさん：2007/04/25(水) 00:31:55

縦読みが３０分も放置されてる・・・

646 ：仕様書無しさん：2007/04/25(水) 03:34:45

>645
どれ？

647 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/25(水) 09:28:37

>633
メソッドが機能になるのは正しい。次に問題になるのが「クラスが物を表しているか」だ。
これがオブジェクト指向と呼ばれる所以になる。誰かが言っていたもう一段階の抽象化も多分これだろう。
落ち着いてクラスを見て、クラスが「商品」や「利用者」などの物になっていて、それらに関連する
フィールド変数とメソッドで構成されているればOKだ。
そして前にも書いたが、そうなるように変数やメソッドを移動する。
構造化の考えだと機能重視になって、クラスが「書き込み」や「計算」などの機能になって、単に書き込み
メソッドを集めたメソッド集や、計算を集めたメソッド集になってしまう事がある。これはNGだ。

ただし分かりにくいのは、「物」と言ってもまれに目に見えない物をクラスにする必要があると言う事だ。
前のオセロの例で言うと、「ゲームのルール」などである。
またまれに、機能なのか物なのか微妙な物や、ある場合では物になる機能などもある。
例えば先ほどの「書き込み」もWriter（書き込む人）などにして、物として扱う場合もある。
まあこのあたりは最初から考えると分からなくなるので、そういう場合もまれにあるという認識だけあればいい。

648 ：仕様書無しさん：2007/04/25(水) 10:44:27

>>633
な？訊くだけ無駄だったろ？

649 ：仕様書無しさん：2007/04/25(水) 11:11:18

糖質との会話は、はたで見てる分にはとても滑稽だ。
常に話題がずれていき、二度と元の話に戻ってこない。

650 ：仕様書無しさん：2007/04/25(水) 11:13:42

>>648
同意。
>>647のようなレスでは出来上がったものを「盲人象をなでる」様に評しているだけに過ぎない。
>>633は（ここでの表現を使えば）「もう一段上の抽象化」をなしえるための方法論、
およびその方法論の背景となるパラダイム自体をたずねているのに
全く回答になっていない。
素直に「わかりません」と回答するほうが簡潔でわかりやすいワイ

651 ：仕様書無しさん：2007/04/25(水) 11:37:18

>>649
へー等質なんだ。

652 ：仕様書無しさん：2007/04/25(水) 11:49:50

アホコテのひとは3行で的確にまとめるように努力してみては。
あまりにもイミフで哀れ。

653 ：仕様書無しさん：2007/04/25(水) 11:54:17

確かに。
自分が言いたいことをダラダラ書いているだけだから読む気がしない。
読む側の事を考えていない。
まさにコーダー。
コミュニケーション出来ないのは自明だが、コードも冗長なんだろうなと思ってしまうね。

654 ：仕様書無しさん：2007/04/25(水) 12:30:07

構造化設計でいう所謂モジュールと、オブジェクト指向のクラスとの一番の
大きな違いはその集合体のインスタンスを生成できるかできないかじゃまいか。
複数のインスタンスを生成しないでいい、つまり一つのインスタンスだけでい
い場合はモジュール的な使い方とほぼ同じだと思う。
その場合は、メンバを全てクラスの静的メンバにするとか、シングルトンパ
ターンやモノステートパターンにするとかOO的な工夫はあるけど、つまりは
メソッドやプロパティを集めたモジュールと同じような使い方になる。

655 ：仕様書無しさん：2007/04/25(水) 13:12:44

デザインパターンなんか実際に使ってる人いるの？
業務系だけ？

656 ：仕様書無しさん：2007/04/25(水) 13:27:57

>>654
うん。
インスタンスを複数作れるという点が大きな違いではなかろうか

657 ：仕様書無しさん：2007/04/25(水) 13:34:30

>>655
君のように理解できてない人は使ってないでしょうね、少なくとも。

658 ：仕様書無しさん：2007/04/25(水) 13:54:31

657は理解できてるように思えないけど
理解できてる人はどこに使ってるの？

659 ：仕様書無しさん：2007/04/25(水) 16:37:00

例えば、商品リストを表現しようとすると、構造化の場合、商品という構造体と
その商品構造体の集合を保持するリストや配列、そしてそれらを検索したり、
追加したりするアルゴリズムをいっしょくたにして管理してしまいがちになるけど、
オブジェクト指向の場合、商品クラスとリストクラスを使ってそれぞれの特性や
役割を分離して表現できるんだな。つまり、構造化の場合、本来役割の違う
データ構造同士が密接に結合してしまいがちだが、きれいにクラス設計された
オブジェクト指向では、クラス同士が疎結合となり、それぞれの役割が明確にな
るため、保守性や拡張性が向上するんだな。しかし、設計や実装が汚いとメリット
を充分に享受できないどころか、人によってはＯＯアレルギーを招きかねない。
構造化の場合もいえることだが、ＯＯの有効性を充分に生かすためには、きれ
いな設計と実装が必須となる。

660 ：仕様書無しさん：2007/04/25(水) 21:03:18

>>655
「OOPに慣れた奴は自然と使ってるパターンがあるが名前が無く
　どういうパターンと言われても説明が長くなる」
というモノに名前を付けたのがデザパタだろ？
だからちゃんと使えてる奴は意識せずとも使ってるのさ

661 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/25(水) 22:40:32

>653
PGなら誰でも分かるぐらいに簡単に説明したつもりだが、あれでも分からないのか？
いくらなんでも分からない訳ないだろう。つーか読んでないだろ？

662 ：仕様書無しさん：2007/04/25(水) 22:54:33

>>661
そもそも読む気が起こらない上によく分からん。

663 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/25(水) 23:01:45

>654
そのような事をHPで言っている人がいたが、いまいち意味が分からなかった。
集合体のインスタンスを生成出来るかどうか？
Cは構造体のインスタンスを生成出来るし、Javaはクラスのインスタンスを生成出来るから、
どちらも集合体のインスタンスは生成出来ると思うが、集合体のインスタンスって何だ？

「シングルトンの場合はモジュールと同じような使い方になる」？
シングルトンは構造化だと言っているのかな？staticメソッドじゃなくてか？

664 ：仕様書無しさん：2007/04/25(水) 23:07:29

>>654
「オブジェクト指向のクラス」という考え方が間違い。
言語のコードなどどうでもよい。
概念レベルで設計できるのがオブジェクト指向の素晴らしさなのだから。

665 ：仕様書無しさん：2007/04/25(水) 23:14:02

概念レベルで設計できないパダワン達が言語機構のポリモフィズムを乱用し、
そのうえスレッドを乱発するから、もう何がどうなっているのかわけわからんｗ
ちゃんとコンピュータサイエンスを学ぼうよ。

666 ：仕様書無しさん：2007/04/25(水) 23:17:45

もうオブジェクト指向スパゲッティはたくさんだ！！！！！！！！！！！！！！！

667 ：仕様書無しさん：2007/04/25(水) 23:21:16

オブジェクティブスパゲッティーでマンプクプクｗ

668 ：仕様書無しさん：2007/04/25(水) 23:22:48

現実的に生産性は最悪だな。オブジェクト指向。流行らなくていいよ。もうｗ

669 ：仕様書無しさん：2007/04/25(水) 23:27:57

何百も派生クラス作るんじゃないよ。まったく。属性で対応できるだろｗ

670 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/25(水) 23:28:27

>662
それなら読まずに、Java使ってCの構造化手法でシステム作って、その後にどんどん機能拡張してみるといい。
恐ろしいほどにスパゲティー化するだろうから。

671 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/25(水) 23:34:18

／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
|　先輩、言われたとおりすべての変数にゲッターとセッターつけました
＼
　￣￣￣|／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　∧＿∧　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　（　・∀・）　 ∧ ∧ ＜　　マクロで組んでどうすんだよ
　（　　⊃ ）　 ( ；ﾟДﾟ)　＼＿＿＿＿＿＿＿＿＿＿＿＿＿　
￣￣￣￣￣（つ＿つ＿＿　
￣￣￣日∇￣＼| VISTA |＼
　　　　　　￣　　　=======　　＼

672 ：仕様書無しさん：2007/04/25(水) 23:41:26

ここには神レベルのプログラマが二人も降臨しているんだから
みんな有り難く拝聴するんだ！カスのあおりはスルーだ！

673 ：仕様書無しさん：2007/04/25(水) 23:45:11

主張するとたたかれるのが２ｃｈ。ま、主張するより叩く方が気楽で安全だわな。
で、主張するものがいなくなると、ぱったりと寂れるのがこのスレの特徴でもある。

674 ：仕様書無しさん：2007/04/25(水) 23:52:26

プログラム？ポリモーフィズム？ぷっw、俺様は概念を理解してるからね
そんな末端の瑣末な事柄には興味ないなぁ。チミたち、まだまだだね。
もちょっと勉強しようね。
って言っとけば、とりあえず王様気分でいられる。ま、なんの意味も無い
書き込みだけどね。

675 ：仕様書無しさん：2007/04/25(水) 23:52:59

変数は必ず関数経由でアクセスする、これがOOですよね先生！

676 ：仕様書無しさん：2007/04/25(水) 23:55:26

>>663
もう一度言おう。
>いまいち意味が分からなかった。
ばかだからでは？
>Cは構造体のインスタンスを生成出来るし
だから何？
CはOOPLではないが(厳密にはC++も違うかも知れん)、OOPができないわけではないし
そもそも複数のインスタンスが生成できることと構造化パラダイムとは何の関係もない。

677 ：仕様書無しさん：2007/04/25(水) 23:58:44

糖質スレ

678 ：仕様書無しさん：2007/04/26(木) 00:00:54

複数のインスタンスが生成できることはOOPパラダイムの一部だもんね

679 ：仕様書無しさん：2007/04/26(木) 00:02:23

構造体の領域をメモリに確保することと、インスタンスを生成することを
同義とみなす偉大なるおじゃばさま。

680 ：仕様書無しさん：2007/04/26(木) 00:12:16

意味論つまらん
>>633に戻ってほしい

681 ：仕様書無しさん：2007/04/26(木) 00:13:54

複数インスタンス厨連投うぜええええ

682 ：仕様書無しさん：2007/04/26(木) 00:21:11

大体、複数インスタンスってなんなんだよ
インスタンスなんだから複数ある前提に決まってんじゃねえか

683 ：仕様書無しさん：2007/04/26(木) 00:25:25

package Ojavasama;

sub new {
my $class = shift;
bless {},$class;
}

sub Kakiko {
return 'ぐだぐだぐだぐだ....';
}

1;

684 ：仕様書無しさん：2007/04/26(木) 00:28:43

javaworldに記事を書いた前橋が沸いてるのか？

685 ：仕様書無しさん：2007/04/26(木) 00:35:44

http://kmaebashi.com/programmer/object/response3.html

前橋確定

686 ：仕様書無しさん：2007/04/26(木) 06:24:56

夢見過ぎだぞ。高弘大丈夫か？

687 ：仕様書無しさん：2007/04/26(木) 07:07:48

今はまだベッドの上で長い長い夢を見てるの。
でも、きっと彼は帰ってくる…いいえ、絶対帰って来ます！
だから、今はそっとしておいて…お願いです。

688 ：仕様書無しさん：2007/04/26(木) 07:08:58

糖質は大変だな

689 ：仕様書無しさん：2007/04/26(木) 07:19:27

ねーねーおかーさん
とーしつってなあに？

690 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/26(木) 09:41:17

>666
オブジェクト指向のスパゲッティー化で嫌いになった人が結構いるって事か。
レガシーCの上級者が最初に作ったJavaプログラムに多い。
しかし成功より失敗からの方が多くを学べるから、オブジェクト指向をマスターするにはいい環境だよ。

>676
ところでパラダイムって何？

>685
そうそう、このHP。
マルチインスタンスがどうの以外は問題ないと思うが、肝心のオブジェクト指向はマルチインスタンスと
言うのが意味分からない。多分インスタンスの意味が違っていると思うが、クラスやオブジェクトに
読み替えてもちょっと意味がずれてる。
他で見かけない意見だから654はHPの作者じゃないか？よかったら説明してくれ。

691 ：仕様書無しさん：2007/04/26(木) 11:31:21

お前の言いたいことのほうがよくわからん

692 ：仕様書無しさん：2007/04/26(木) 11:40:02

コンピュータサイエンス（笑）

693 ：仕様書無しさん：2007/04/26(木) 14:10:34

詳細設計や実装には強いが分析をあまり重視しないBooch法。
問題領域を調査する手法を提供する反面、解決領域が弱いOMT。
そして、解決領域での利便性に比べて問題領域が重視されないOOSE Objectory。
これらを１つの一貫した統一アプローチへ統合したスリーアミーゴはつくづく偉大
だと思う。残念ながらその理念を理解し使いこなしている人が少ないの現状は、
非常に残念だ。

694 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/26(木) 18:48:08

OO厨の糞ソース読んでたら　血を抜かれたみたいにぐったり。
OOちゅ死ね

695 ：654：2007/04/26(木) 19:04:54

ちがうよ、俺はそこの作者じゃない。
つか、どこに、「オブジェクト指向はマルチインスタンス」って書いてあんだよ。寧ろそこ
の作者の言ってることと逆じゃねぇか。
同一クラスのインスタンスが常に複数生成される訳じゃないだろ。例えばWinアプリ
とか作るときでも、生成するアプリクラスのインスタンスは1個だけだろ。その場合は
別に無理にクラスにしなくてもエントリポイント(WinMain)と初期化ルーチンとかメッセー
ジループを用意してやればいいんだけど、ただ全体的にOO設計で統一した方が分か
り易いし、いろいろ都合がいいからアプリケーションクラスなんてものを作って、その
インスタンスを１個だけ用意してるわけだろ。他にもマネージャクラスとか、リソース管
理クラスとか、インスタンスを1個しか使わないケースはいろいろあるわな。
つまり必ずしもインスタンスは複数生成するものじゃない。じゃなきゃ、シングルトン
とかモノステートなんか不要だからな。必要があるからそのための手法があるわけだ。

696 ：仕様書無しさん：2007/04/26(木) 19:12:34

文章的特徴が一緒なので、自作自演どころか単なる独り言にしか見えない。

697 ：仕様書無しさん：2007/04/26(木) 19:13:39

文体を微妙に変えている所がまた泣けるな

698 ：仕様書無しさん：2007/04/26(木) 19:25:12

つーかなにこの改行
読みにくいってレベルじゃねーぞ

699 ：654：2007/04/26(木) 19:42:42

>>698
全員が自分と同じ環境で2chを見てると信じて疑わない莫迦に言われたくない。
つか、お前の改行も変だぞ。句読点をつけないのとその文体の特徴から今までの
カキコもバレバレだし。

700 ：仕様書無しさん：2007/04/26(木) 19:43:58

なあ、アンタ、何逆ギレしてんの？

701 ：仕様書無しさん：2007/04/26(木) 20:18:23

即答だなw

702 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/26(木) 20:49:11

>695
俺はオブジェクト指向かどうかと、インスタンスが複数生成できるかは関連がないと思っているのだが、
そこの所はどうなのだろうか？

703 ：654：2007/04/26(木) 21:03:41

インスタンスを生成できないオブジェクト指向なんて俺は使いたくない。
クラス(変数とメソッドの塊)のオブジェクト、つまりインスタンス（構造体
じゃないよ）の生成は非ＯＯでも擬似的にやれなくもないが、よっぽどうま
くやらないと本来の主眼である保守性や拡張性、可読性を損なうことになる。
つか、そこまでやっちゃうともはやＯＯだろう。cのmallocはデータ領域の
生成であって、インスタンスの生成じゃないからな。おわかり？

704 ：仕様書無しさん：2007/04/26(木) 21:09:48

42　654　sage　2007/04/26(木) 21:06:59

　ぱんつとパンティーじゃ全然ちがうんだよ、ヴぉけ。

705 ：仕様書無しさん：2007/04/26(木) 21:24:24

既出だったらすまないけど、前橋和弥（ポインタ本の人）のOOP論についてはどう思う？
俺はこの人のOOP論は倒錯してると思うんだけど。

どう倒錯してるかは気が向いたら書きたいと思うけど、簡単に言えば言語のOO化の
副産物に過ぎないものをOOPの主目的と取り違えている。

その倒錯は恐らく、「図解の技術」―― 分かり易い設計図の書き方に関する技術であるOOを、
要は人間の脳へのアプローチであるOOを、「工法」―― 地震に強いとか防音といった
新しい機能を実現するための技術、要はコンピュータへのアプローチと混同し
取り違えているところから来ていると思われる。

706 ：仕様書無しさん：2007/04/26(木) 21:44:14

>>705
おいクソコテ付け忘れてるぞ

707 ：仕様書無しさん：2007/04/26(木) 22:41:25

えっとですね、おじゃばさんに質問していた件ですけど、
オブジェクト指向ってもうすこし具体的に何がいいかってのが知りたいんです。
たとえばJavaの場合だと、
newしてほったらかしのガーベジコレクタとかは確かに便利ですし、
呼び出し元関数の変数アドレスが呼び出し元で確保できてるのも便利です。
でも、これってJava言語仕様の話であって、
オブジェクト指向とは関係ないですよね。

自分が便利だと思ってるのがそのへん（プログラマがメモリ意識しなくてよい点）なので、
オブジェクト指向が便利なのではなく、Java言語（ＶＭ？）の恩恵が高いってのが
目立ってて、オブジェクト指向自体でうれしいってことが見えないんです。
今C++の業務やってるんですけどnewしてdeleteは当たり前ですし、
オブジェクト指向言語って？？？って感じで・・・
すみません、うまく伝えられなくって・・・

708 ：仕様書無しさん：2007/04/26(木) 22:42:32

あ、５行目間違いです・・
呼び出し先のアドレスが、呼び出し元でも残ってる、って意味です。。

709 ：仕様書無しさん：2007/04/26(木) 23:56:48

>>707
継承や多態は恩恵だと思わないか？

710 ：仕様書無しさん：2007/04/27(金) 01:11:09

データ構造に対するオペレーションが複雑になった時にそれをクラスの挙動
として集約できるのはそれだけでメリットじゃなかろうか、後プログラムの設計時
にあるデータ集合を取りまとめてより1段上の階層でのオブジェクト関係で取り扱う
場合にも集約し易いし、概念的な取り扱いを自然に表現する上で多態なんかも便利
だしメンテもし易い

上手く表現できないけど自分の場合そんな感じ、自分もメインはC++で使っているので
所有権は明確にしなきゃいけない事が多いけど、それでも便利だと思う＞OOP機能

711 ：仕様書無しさん：2007/04/27(金) 01:30:52

数学で行列やベクトルが何故便利なのかという質問と同じような話な気がする。
事前に演算体系(=クラス設計)を定義する事で実際は複雑な計算(=プログラム)
を如何に表面上簡潔に表現(=プログラム作成)するかというような。

OOP機能はそういった演算体系(=プログラム内の抽象化構造)の階層化を比較的
自然に表現できるし、逆にそういった機能(例ではベクトルや行列計算が無くても
四則演算のみで解決できるような問題)が必要無い規模では余りメリットが見えて
こないかも。

712 ：仕様書無しさん：2007/04/27(金) 02:01:04

プログラムをOOP機能を使ってで作成する場合、クラス設計に要する思考は対象
となるアルゴリズムよりも一段メタ的な所にシフトして設計し、その後対象
アルゴリズムにシフトダウンする必要があると思うのだけど、この思考の切り替え
の部分が(自分の経験では)人により差異があるように見受けられるのでオブジェクト
指向が難しいと言われる一因ではないかと思う。

ただ幾ら慣れても切り替えのコストは0では無いので自分の場合も数10～数100行
程度の雑用プログラムを書き殴るのであればクラス機能とか使わない方が楽だけど、
それ以上もしくはメンテナンス効率なんかを考えるとOOP機能は便利。

713 ：仕様書無しさん：2007/04/27(金) 02:04:41

思う
思う
思う

('A`)ｳﾞｧｰ

714 ：仕様書無しさん：2007/04/27(金) 02:28:55

>>646
>>617

715 ：仕様書無しさん：2007/04/27(金) 02:30:17

これまた判りやすい
薄っぺらな自作自演

716 ：仕様書無しさん：2007/04/27(金) 02:32:15

用語使いが特殊というか変だ

717 ：仕様書無しさん：2007/04/27(金) 02:50:10

高弘隔離病棟

718 ：仕様書無しさん：2007/04/27(金) 03:39:52

710=711=712
別段自演の意図では無く思いついたまま書いただけだけど、自演っぽく映ったの
ならスマヌ

719 ：仕様書無しさん：2007/04/27(金) 05:31:28

>>707
俺様的には気軽に型を作りまくれる辺りだな
Cで調子こいて構造体作りまくると
操作する為の関数が多くなる

まぁそこまではどっちも似たようなモンだけど
それら自作構造体の内容を全部文字列として標準出力したいとすると…

OOPL:
　　各クラスでtoString()オーバーライドして
　　出力ルーチンは単にtoString()して出力するだけでいいんじゃね？
　　あれだよあれ、多態ってヤツだよ

非OOPL:
　　型判定して型にそった文字列化の関数呼ぶ？
　　でもソレちと行数が多いな…つーかこんなに構造体作ったの誰だよ

つーワケで自作型作りまくるなら断然OOPLだな
別にOOでない使い方だって出来るんだしぃ？

720 ：仕様書無しさん：2007/04/27(金) 07:05:12

非OOPL:
extern int print(struct foo);
extern int print(struct hoge);
extern int print(struct fuga);

721 ：仕様書無しさん：2007/04/27(金) 07:55:23

非OOPL
template<typename T>
void print(T x){printString(toString(x));}

722 ：仕様書無しさん：2007/04/27(金) 08:15:52

「プログラミング作法」の Rob Pike 先生によるOO信者批判
http://hisashim.livejournal.com/69145.html

私はオブジェクト指向設計の熱心なファンではない。私はOOで作られた美しいものを
いくつか見てきたし、自分でもOOなものを若干手がけさえしたけれど、OOは単に問題に
対してアプローチする方法のひとつでしかない。ある問題に対しては理想的な方法だが、
別の問題に対してはそれほど合った方法ではない。（中略）

オブジェクト指向設計の推進者たちは、ひと塊の木材が持つ美しさが作業を始める前に
自ら姿を現すのを待っている、木彫りの名人のように思えるときがある。「おや、見てくれよ。
木をこう回転させたら、木目が座席の角度にちょうどうまく合った角度で流れるよ、ねえ？」
素晴らしい、いい椅子だ。でも自分が座っているときに木目が気になるだろうか？そして
次回は？やらなければならないことが、どんな木材にも隠されていないことがときどきある。

OOは、インターフェイスが自然に幅広い範囲の型に適用できるような問題には素晴らしく
適しているが、ポリモーフィズムを扱うにはあまり適さないし（コレクションをOO言語に
持ち込もうと画策する動きは、見ていると仰天することばかりだし、一緒に作業をすると
なるとひどい目にあいかねない）、ネットワークコンピューティングには抜群に不向きだ。
私が、問題によって言語を使い分け、そしてさらには -- しばしば -- ひとつの問題を解決
するために複数の言語で書かれたソフトウェアを組み合わせる、そういったことをする
権利を保留しているのは、このことが理由だ。

723 ：仕様書無しさん：2007/04/27(金) 09:06:20

たっ、…たとえだよ、たーとーえ！
俺様だってＣ言語ぐらい知ってらい！
ほら、もっと何かあるだろ？

でもC++なんてずるい…

724 ：おじゃばさま ◆GxjxF3yEw6 ：2007/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 ：仕様書無しさん：2007/04/27(金) 10:23:27

なぜOOだとバカでも変更に強い設計が出来るんだ？って説明がないぞ。
どっちかっていうとOOってバカでも能書きが言えて素人をだませる、
という主張にしか見えないなぁ。

726 ：仕様書無しさん：2007/04/27(金) 10:48:57

>>725
同意。事象の表明を書くのは良いがそれだけじゃ意味が無いワイ
やれば誰でも実感できるレベルの話だけをながながと読まされるこっちの身にもなってみろ。
>>724よ、>>725の指摘した点に自分の考察なり見解なりを書いてみろよ。

お前の観察日記を読むために来てるんじゃない

727 ：仕様書無しさん：2007/04/27(金) 10:50:24

バカにOO与えると
泥沼になる

728 ：仕様書無しさん：2007/04/27(金) 11:32:25

>>726
>ながながと読まされるこっちの身にもなってみろ。
おじゃばファンでもないのに、なんで読むのさ。

729 ：仕様書無しさん：2007/04/27(金) 12:10:29

ぶっちゃけ日記はblogでやってろってなレベル＞アホコテ

730 ：726：2007/04/27(金) 12:18:56

>>728
そりゃぁ。
>ながながと読まされるこっちの身にもなってみろ。
とレスするためさ

731 ：仕様書無しさん：2007/04/27(金) 13:41:25

>>724をリファクタリングしてみた。

ＯＯは仕様変更に強く、変更の繰り返しで寧ろ構造が洗練されていく。
また、分かっている所から作り始められるので、仕様が不明確でも作り易い。
対して、非ＯＯの場合は、熟練者が変更を見越した設計をしていない限り、
修正は困難になる。
例えば、対象DBやＯＳが変更になる場合でも、OOだと、少しの修正で済むが、
非ＯＯでは変更が考慮されていない場合、バグに悩まされることになる。

・・・纏めてみても、結局何を言いたいのかよくわからんな。ＯＯの利点を強調
したいのか、非OOでもうまく設計されていれば問題無いと言いたいのか。

732 ：仕様書無しさん：2007/04/27(金) 14:26:52

くだらないあげあしとりばっか
あきらかにおじゃば以下

733 ：仕様書無しさん：2007/04/27(金) 14:52:07

>>725-726
正論。

>>724は信念を語っているだけで、
その信念の合理性を客観的示す事ができない。
つまり宗教なんだ

734 ：仕様書無しさん：2007/04/27(金) 14:59:21

>>733
そんなもの簡単に示せるわけがない
かいつまんでいうと、あげあしとりｳｾﾞｴ

735 ：仕様書無しさん：2007/04/27(金) 15:06:16

全体を批判することをいつから「あげあしとり」と呼ぶようになったんだ。
○○以下　という発言は「自分は○○です」と言っている様に読めるぞ。
かいつまんでいうと、ｵﾏｴが黙れ

736 ：仕様書無しさん：2007/04/27(金) 15:18:33

>>735
いや黙るべきはお前だ
対案のない批判なんか必要ない

737 ：仕様書無しさん：2007/04/27(金) 15:34:05

>>733
> >>724は信念を語っているだけで、
> その信念の合理性を客観的示す事ができない。

>>734
> >>733
> そんなもの簡単に示せるわけがない
> かいつまんでいうと、あげあしとりｳｾﾞｴ

信念の合理性を客観的に示す事ができない＝狂信者決定

738 ：仕様書無しさん：2007/04/27(金) 15:43:52

>>737
おまえの信念と客観的な合理性の提示よろ

739 ：仕様書無しさん：2007/04/27(金) 16:28:29

信念：
狂信者に対し、自分の信念を語る暇などない。

客観的合理性：
狂信者とは、己の考えの根本的正当性の確認努力や
他人に対する合理的説明努力を怠ったまま、
自分の考えが絶対正しいと主張する輩に対する
蔑称である。
そのような人物と時間を費やし議論を重ねても、
虚しい言葉が行き来するのみで
相互理解は極めて難しい。
従って、狂信者に対しては何も語らず、
ただ黙殺する事が、時間を有効に使う秘訣である。

740 ：仕様書無しさん：2007/04/27(金) 16:40:14

>>739
黙るっていったからには絶対黙れよ。

741 ：仕様書無しさん：2007/04/27(金) 16:56:19

次スレは

【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発儲はなぜ黙らないの？★

ということでよろしいか？

742 ：仕様書無しさん：2007/04/27(金) 17:02:11

アンチでも信者でもいいけど、なんか中身のあるレスすれば？
あきらかにココ電以下

743 ：仕様書無しさん：2007/04/27(金) 17:02:11

あまりに>>724が哀れだから >>724を訂正してやろう。

1. OOであろうと構造化であろうと、下記二点
　　(1)高凝集性：プログラムの構成要素(変数,関数,etc.)の出現範囲を局所化する
　　(2)疎結合性：局所的なまとまりに対し適切なインタフェースをつける
　を「実現」すれば、
　「ある範囲」の変更要求に対しては、変更の影響を局所化でき、
　拡張性/保守性の高い、いわゆる「変更に強い」プログラムを構築できる。

2. OOは、その種の局所化とインターフェース化について、
　構造化よりも適切な道具を提供しており、
　「それらの道具を適切に用いれば」、
　上記二点を実現する際の設計負荷を和らげる事ができる。

問題は1(1)(2)の実現方法、2の道具の適切な使用方法にある。
OOであれば、熟練しなくとも1(1)(2)、2を実現できるなどというのは
妄言に過ぎない。

744 ：仕様書無しさん：2007/04/27(金) 17:04:50

>>724
高弘さぁ、レポート書くの苦手だろ。
お前の文章って怨念がにじみ出ていて、
全然客観的じゃない。
「理系の作文技術」でも読んで、レポート書く練習したらどう？

745 ：仕様書無しさん：2007/04/27(金) 17:10:24

おまえアホだろ
おじゃばは少なくとも「OOの方が低コスト」と主張している。
おまえの主張はまとはずれ。

746 ：仕様書無しさん：2007/04/27(金) 17:11:26

ことばたらずだった。
「変更に強い」プログラムをつくるためのコストな。

747 ：仕様書無しさん：2007/04/27(金) 17:12:28

>>743
客観性一切なし。もう黙れ。

748 ：仕様書無しさん：2007/04/27(金) 17:13:19

で>>743に要約したみたいな30年前の素朴な考え方じゃ
とっくに行き詰まりが生じていて、
だから落ちこぼれ業務システムの分野でも
DIコンテナやらサブジェクト指向が取り沙汰されてるんだろ。

749 ：仕様書無しさん：2007/04/27(金) 17:13:57

>>743
具体性も０

750 ：仕様書無しさん：2007/04/27(金) 17:14:16

>>747
とりあえずお前がバカだという事はよく判った。
>>747は罵詈雑言の口先野郎としてスルーする。

751 ：仕様書無しさん：2007/04/27(金) 17:14:53

もしかして、今ここで連続レスしてるのって、
池沼の方？

752 ：仕様書無しさん：2007/04/27(金) 17:16:48

>>748
アスペクト指向、サブジェクト指向はなかなか面白いよね。
業務システムを手続き処理に還元してグダグダにしちまう誰かとは
頭の出来が違うと思った。

753 ：仕様書無しさん：2007/04/27(金) 17:17:01

>>748
だから、の使い方が意味不明。
DIコンテナとサブジェクト指向が、どう行き詰まりを解決するのか書け。

754 ：仕様書無しさん：2007/04/27(金) 17:17:56

>>752
知ったか乙

755 ：仕様書無しさん：2007/04/27(金) 17:19:13

>>752
どこからアスペクト指向が出てくるのやら。
DIコンテナとアスペクト指向に、なにか関係があるとでもおもっているのだろうか。
知ったかJava厨乙

756 ：仕様書無しさん：2007/04/27(金) 17:19:31

バカ相手に講釈するのは時間の無駄。
お前お得意のゴッグルさんで@ITの記事でも読んでろ池沼ｗ

757 ：仕様書無しさん：2007/04/27(金) 17:20:58

高弘ってテンパるとすぐ罵詈雑言が出てきて、
元の話を棚上げしてくるからからかい易いな

758 ：仕様書無しさん：2007/04/27(金) 17:22:29

元のはなし：あげあしとりｲﾗﾈ

759 ：仕様書無しさん：2007/04/27(金) 17:23:22

>>756
知ったか確定乙

760 ：仕様書無しさん：2007/04/27(金) 17:23:37

元のはなし：高弘は言語も思考もカオス

761 ：仕様書無しさん：2007/04/27(金) 17:26:14

糖質からかうとおもしれぇな

デザパタ、リファクタ、構造化しか持ちネタねぇのかよターコ

762 ：仕様書無しさん：2007/04/27(金) 17:40:37

糖質の脳内では自分の疑問点を説明してくれない人は
全部「知ったか」と変換されます。

763 ：仕様書無しさん：2007/04/27(金) 17:42:43

闘牛状態だなｗ

764 ：仕様書無しさん：2007/04/27(金) 17:55:03

【レス抽出】
対象スレ：【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
キーワード：低コスト

抽出レス数：1

>>745はおじゃばの脳内主張をエスパーできるサイコ仲間かｗｗｗｗ

765 ：仕様書無しさん：2007/04/27(金) 18:16:59

元の話に出てこない単語が
いきなり飛び出すのは
このスレが糖質の自作自演だから

766 ：仕様書無しさん：2007/04/27(金) 18:54:19

野次までつまらなくなってきた
OOわからないなら他行けよ

767 ：仕様書無しさん：2007/04/27(金) 19:00:08

サイコをリアルタイムでからかえる
とても便利なインターネッツ

768 ：仕様書無しさん：2007/04/27(金) 19:18:16

DI：クラスの疎結合実装に役立つ
AOP：個々のクラスが提供すべき機能を
　　　　複数の側面に分割して記述する事が可能になる。
　　　　結果として通常のクラス設計では複数のクラスに散らばってしまう
　　　　横断的関心事の局所化が可能になり、拡張性/保守性を高める事ができる。

769 ：仕様書無しさん：2007/04/27(金) 19:51:51

サブジェクト指向ってなぁに？ぐぐったら判るの？自分はわかんなかったなぁ。
#ぐぐっったら何でも判るんだったら「オブジェクト指向」も遭難じゃないの？

770 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/27(金) 21:16:17

>725
バカでも変更に強い設計が出来るなんて言っていない。
そのシステムや業務の経験が浅いSEでも、OOをマスターしていれば、変更に強い設計が出来ると言っている。

>726
「やれば実感出来る話」を長々と書くのは、やらない人が多いからだ。

>731
その解析は正しい。
OOの利点を説明したのが前半。しかし非OOでもうまく設計されていれば問題無い言うのが後半。
OOの利点と、非OOとの違いを聞かれたのでそう答えた。
俺はOOで設計すれば全てOKなどと言うつもりはない。
「仕様が未確定で変更が多い」物にはOOが向く。逆に言うと「仕様が確定していて変更が少ない」なら
非OOの方がいい場合も多い。例えばドライバやハードに近いプログラムなどだ。

771 ：仕様書無しさん：2007/04/27(金) 21:35:07

いや、だから
バカでも能書きたれて素人をだませる
という主張に見えた、んじゃないの？
依然としてなぜ仕様変更に強い設計が経験が浅くてもできるの、
と言う説明が無いんだけど？

772 ：仕様書無しさん：2007/04/27(金) 21:39:02

ヒューリスティクスって知ってるか？

773 ：仕様書無しさん：2007/04/27(金) 21:40:52

また自作自演でレベル低下かｗ

774 ：仕様書無しさん：2007/04/27(金) 21:42:20

「やってみたらそうだったから」って話？
んなもん聞いてないだろ、ふつー。

775 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/27(金) 21:42:33

>733
宗教でも何でもない。
Pro*Cのソースをpostgres用に修正するのと、JDBCのソースをpostgres用に修正するのはどちらが楽か？
設定ファイルに暗号過機能を追加するに、C構造化ソースと、JavaOOソースではどちらが楽か？
やった事のある人なら良く分かるだろう。

>743
実現法方については、すでに具体的なコーディング方法を書いた。
OOなら熟練しなくても良いなど言っていない。その業務には熟練しなくてもいいが、OOの習得は必要。
前にも書いたが、OO方針に従って、1～2年のプログラミング経験が必要。

>745
「OOの方が低コスト」などとは言っていない。
変更を繰り返す場合は、トータル的にOOの方が低コストになるが、初回の作成や変更の少ないプログラム
では、構造化の方が低コストになる。

776 ：仕様書無しさん：2007/04/27(金) 21:45:08

言い訳開始。

777 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/27(金) 21:51:05

>771
「経験が浅い」って言ってるのは「プログラミング経験」じゃなくて、「業務経験」。
業務経験が浅くてもOOなら変更に強いプログラムを作れると言ったが、
OOのプログラミング経験が浅くても変更に強いプログラムが作れるとは言っていない。

778 ：おじゃばさま ◆GxjxF3yEw6 ：2007/04/27(金) 21:55:17

>774
実例じゃなくて論理を知りたいのか？
長く言うと読まなそうなので短く言うと、抽象化されていると交換が容易なのと、継承を使うと親クラスには
修正が入らないので、ソースが壊れないからの2点が大きい。

779 ：仕様書無しさん：2007/04/27(金) 21:57:04

＞業務経験が浅くてもOOなら変更に強いプログラムを作れる
だから、それがなぜかがねえだろ？
だれも「プログラミング経験」の話なんかしてない。誰だ？
逆に「プログラミング経験」があれば業務経験が浅くても
OOなら分析・実装しやすい、のなら話はわかりやすいだろ？
それがテクニックじゃないのかよｗ

780 ：仕様書無しさん：2007/04/27(金) 21:58:42

怒濤のようなアナクロニズム

781 ：仕様書無しさん：2007/04/27(金) 22:02:08

>>777
大当たりおめでとうｗ
なんだかOO利点を挙げようと頑張っているけど1～2年の経験は1～2年の経験だ
OOに限らず何事も3年続けてやっとその世界の入り口にたどり着く
3年続けられないならその世界はあきらめろ

782 ：仕様書無しさん：2007/04/27(金) 22:03:05

もうちょっと話に説得力を持たすための勉強をしろよ、おじゃば。
もうOOとかJavaは習得したんだろ？いいかげん日本語のほうをちゃんとｗ
ま、がんばんなよ。

783 ：仕様書無しさん：2007/04/27(金) 22:15:03

パソ通時代のログ読んでるのかと錯覚した

784 ：仕様書無しさん：2007/04/27(金) 22:18:04

涙はこれで拭いとけ（k

785 ：仕様書無しさん：2007/04/27(金) 22:36:46

こんな所で自作自演して一体誰が得するんだろうと思った

786 ：仕様書無しさん：2007/04/27(金) 23:02:37

自己満足だろ

787 ：仕様書無しさん：2007/04/27(金) 23:29:50

ジェダイのライトセーバーと同じで
選ばれし者だけがオブジェクト指向を活用できる。
だから本当の意味で流行らないわけだ。
そのことに早く気づこうな。

788 ：仕様書無しさん：2007/04/27(金) 23:58:34

おじゃばよフォースを使え。

789 ：仕様書無しさん：2007/04/28(土) 00:07:22

オセロの石やポットの水をオブジェクトにしているようでは
フォースをまとうことは叶わぬわ。

790 ：仕様書無しさん：2007/04/28(土) 00:25:25

どうしてみんなページ制御が下手なの？
一覧表のページめくりぐらいちゃんと作れなきゃ。だめよ。

791 ：仕様書無しさん：2007/04/28(土) 00:36:54

恥ずかしくなっちゃった？

792 ：仕様書無しさん：2007/04/28(土) 00:39:06

ページの概念をクラスにする。汎用的に使える。

793 ：仕様書無しさん：2007/04/28(土) 00:57:24

えっと、>>724のおじゃばさんの文面で、ちょっとヘンだな～って思うところがあります。

OOだと変更が入れば入るほど、洗練されていく、とありますけど、
なぜそうなるんですか？
これはOOの考え方によるものですか？それとも言語仕様も関わりますか？
コーディングって量が少なければ少ないほど、
丈夫なプログラムになるはずなんで、変更が増えるほど良くなる、ってのが分かりません。。。

あと、これはちょっと違うかな～って思うのがあります。
C言語だとDBが変わると修正が大きくJavaだと小さい、とありますが、
各DB＋言語で使用するライブラリを、DBの違いを吸収した関数を用意しておけば、
関数の呼び先の処理が変わるだけで言語の違いは無いと思うんです。

C言語で、Accessの接続（ODBCあたり？）→Oracleの接続（orlon関数、、かな？）
に変わったとしてもDB_Connect()って関数を呼ぶように作っておけば、
修正はこの関数だけで済みますよね？
バインド変数を使う・使わないとかはDB仕様なのでちょっと変更は必要かもしれませんけど、
Javaでも同じですし・・・

これはオブジェクト指向か構造化かの違いではなく、
単にセンスや考慮の話だと思うんです。
最初の洗練される、ってのも同じ話かな～って思ってしまって・・・
やっぱりOO分かってないんでしょうね・・・
あぅぅ、長くてすみません；；

794 ：仕様書無しさん：2007/04/28(土) 01:02:09

あとですね、
OOだと仕様不明点があって作れる、とありますが、
本来のOOってのはそれを設計段階で吸収し終わって、
それをそのままコーディングできるのが強みだと思ってたんですが、
これもやっぱり間違ってますか？・・・

OOとXPのプロトタイプは別の話のはずなんで、
なんか話がいろいろなってる印象があって・・すみません。。

795 ：仕様書無しさん：2007/04/28(土) 01:15:27

そろそろ我々は設計はヒューリステクスだという事実を認めなければならない。
あらゆる設計に通用する手法などないということを認めなければならない。
最適解など存在しない。しかし、限りなくそれに近づけることはできる。
人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
保障などないということを認めること。それでも涙しながら助け合うこと。
時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。
我々はクリプトナイトを抱えたスーパーマンだということを、そして簡単に
裏切れるということを認めなければ。コンピュータを相手にしながら、結局、
人間を相手にしているのだということを、認めるしかないのだ。

796 ：仕様書無しさん：2007/04/28(土) 01:23:13

最適解どうのこうのいうような事してないんだろｗ

797 ：仕様書無しさん：2007/04/28(土) 03:46:06

>>793
多分、モジュールとして分割されている事とOO的な分割の
意味を混同しているんだろうと思われる。
たしかに、バイナリレベルで切り離されていれば
呼び出し等は何でも一緒になる。

ペナルティとしては細かいやり取りには向かないって事。
この辺は難度の高いプログラムを組まないとなかなか実感できないと思う。

ソースが洗練云々はプログラムの部品化(つまり共通化)が進むので
開発工程そのものがテスト工程も兼ねる事になるので品質が高くなるという事。
この辺も難度の高いプログラムを組まないとなかなか実感できないと思う。

798 ：仕様書無しさん：2007/04/28(土) 03:47:02

もうちょっとだけ追加説明をしてみる。

10000ステップの処理に追加処理として10000ステップあったとする。
べたCだと極端な話だけど
10000ステップコーディングした後に
10000*10000通りのテストが待っていて細かくチェックするしかなくなる。
これがOOPだと
元の10000ステップを修正して＋10000以下のコーディングをした後に
元の10000＋10000以下のテストをする事になる。

たいした違いがないように思えるが
これを繰り返すとCだと飽和していくけどOOPだと逆に収束していく。

要はOOPはステップ数を横軸にした場合
コストが収束に向かう関数曲線を描くけど
非OOPは飽和に向かう曲線を描くって話。

799 ：仕様書無しさん：2007/04/28(土) 03:48:23

おじゃば氏の示している内容はOOPを使って開発経験者なら
誰でも感じる事でむしろ当たり前の事が書かれている。
入門的な書籍等でも大体同じ事は書かれている。
それに食いついている人は実際にはあまりOOPを
扱ってない開発者なのだろう。

800 ：仕様書無しさん：2007/04/28(土) 04:04:49

>10000+10000うんぬん
どうしてOOだとそうなるのか、説明よろしく。
経験んちゃら、とかじゃなくて「わからなくて質問」してるのがいるんだし、
書籍にあるんなら、どの本か教えてやれよｗ

誰も食いついてなんかいねーよ、説明してくれと言ってる。

801 ：仕様書無しさん：2007/04/28(土) 04:20:27

>>800
お前、無知なのに生意気だなw

プログラムの部品化(つまり共通化)が進めば
テストされる回数もあがるだろ。
プログラムの品質はテスト回数に比例してあがる。
大規模openソースと企業のソースで適当に調べればわかる。

書籍は俺もかなり前の事なので、よく覚えていない。
お前はいちいち読んだ本の名前を覚えているのか?
初心者向けの本を適当に読めば書いてあるだろw

802 ：仕様書無しさん：2007/04/28(土) 05:03:29

読んだ本くらい覚えてるだろ、普通。この本のココを読んだらわかった、とか。
それ以前にどうして構造化がだめでOOだと部品化が進むのよ？
そんなにいいもんなら以下スレタイ、という話じゃないのか。

で、それは「どいつもこいつもOOを勉強しないから」とか
「どれだったか本に書いてあるもん」とか「おっきなとこでやってるから」
「やってみれば誰でもわかるよ」位の話を長文で技術用語(ﾌﾟ垂れ流しでやるから

「それってなんて宗教ｗ」「どこの壺売りよｗ」言われるんじゃないか。

803 ：仕様書無しさん：2007/04/28(土) 07:04:24

レベルの低い負け犬が30年前の概念を
独りで弄って悦んでる状態か
どうしようもねぇな

804 ：仕様書無しさん：2007/04/28(土) 07:05:52

> 食いついている人は実際にはあまりOOPを
> 扱ってない開発者なのだろう。

局所化と隠蔽(インタフェース化)
という二言で済む話を延々やってろキチガイ

805 ：仕様書無しさん：2007/04/28(土) 07:10:51

＋αがあるだろ
部品化がOOの特徴とかいう陳腐な＋αだがｗ

806 ：仕様書無しさん：2007/04/28(土) 07:25:22

>人間の弱さを認めること。許すこと。許されること。誠意を示すこと。誠意に
>保障などないということを認めること。それでも涙しながら助け合うこと。
>時に厳しく、時に優しく、諭すこと。切り捨てること。柔軟に対応すること。

元々頭が弱い奴は、プログラミングの現場に来なければいいのに、と思う。

807 ：仕様書無しさん：2007/04/28(土) 08:19:55

局所化と隠蔽だけで行き着くところはオブジェクティブスパゲッティｗ

808 ：仕様書無しさん：2007/04/28(土) 08:44:47

ＧＷ中も糖質は２ちゃん張り付きなのか

809 ：仕様書無しさん：2007/04/28(土) 09:02:33

感性を形にできる。それがオブジェクト指向。
感性の良し悪しが、そのまま形になる。それがオブジェクト指向。

810 ：仕様書無しさん：2007/04/28(土) 09:07:01

文よりも図の方が直感的で分かりやすい。
つまり構造化よりもオブジェクト指向の方が直感的で分かりやすい。

811 ：仕様書無しさん：2007/04/28(土) 09:15:21

まずは構造化モデリングが正しく行えるように勉強しなさい。
オブジェクト指向はそれが出来るようになってからな。

812 ：仕様書無しさん：2007/04/28(土) 09:29:57

達人を目指すならアセンブリコードを学ぶこと。
コンパイラの勉強をすればアセンブリコードの知識も身に付くだろう。
グローバル変数、ローカル変数、スタック、ヒープメモリやアドレッシング、割り込み、スレッドなどなど
基本的な概念が正しく身に付く。
そうすることにより、今まで見えなかったり、感じなかったことが驚くほど分かるようになる。
オブジェクト指向もな。

813 ：仕様書無しさん：2007/04/28(土) 09:35:12

ソフトウェア設計はエンジン設計と同じだ。
部品一つ一つに情熱を注げ。美しさを追求しろ。

814 ：仕様書無しさん：2007/04/28(土) 10:04:45

>>812
やっぱドラゴンブックがいいの？

815 ：仕様書無しさん：2007/04/28(土) 11:24:10

この辺りから入門しなさい。
・ttp://www.atmarkit.co.jp/fjava/rensai4/compiler01/compiler01_01.html
・スモールコンパイラの制作で学ぶプログラムのしくみ

816 ：仕様書無しさん：2007/04/28(土) 11:51:49

ドラゴンはある程度分かってからな。

817 ：仕様書無しさん：2007/04/28(土) 12:05:12

こないだ中田育男教授の最終講義があったね。
「コンパイラとつきあって40年」

818 ：仕様書無しさん：2007/04/28(土) 12:12:12

入門用
・いまどきのプログラム言語の作り方

819 ：仕様書無しさん：2007/04/28(土) 12:35:39

いちおうマジレスしとくと
コンパイラの勉強なんてのは学生時代に済ましとくべきものだよ。

820 ：仕様書無しさん：2007/04/28(土) 12:37:48

笑えるじゃないか。
現在進行形でコンパイラのおべんきょしてる
40過ぎのじじぃが知ったかぶってる姿

821 ：仕様書無しさん：2007/04/28(土) 12:38:56

おまいするどいなｗ

822 ：仕様書無しさん：2007/04/28(土) 12:44:15

いちおうマジレスしとくと
オブジェクト指向の勉強なんてのは学生時代に済ましとくべきものだよ。

823 ：仕様書無しさん：2007/04/28(土) 12:48:06

うーんとね、
おいらの場合は学部３年の計算機実習で
その記事と同じ電卓コンパイラ＆VMやったね。
センセはソフトウェア・ツールの翻訳もやってた
木村研出身のひと。

再帰下降文法でうんちゃらかちゃらなんて恥ずかしいんで、
当時ちょこっといじってたPrologライクに、
演算子の優先順位と結合性決めて、演算子順位文法で提出したな。

趣味ではあとLisp VMとLisp コンパイラ。アーカイブっつう雑誌見て手作り。
Scheme VMは、Dylanのひとが作ってたX Schemeでおべんきょ。
Smalltalk VMあたりは・・・うーん・・・当時はVM仕様は判っても、
その上にのっかるImageがどうしようもなく入手困難だったから諦めたなぁ。
Smalltalk/V と GNU Smalltalk で雰囲気を想像する、という・・・

824 ：仕様書無しさん：2007/04/28(土) 12:52:01

いや思い違いか、
学部二年だな、そんな初心者勉強は。
学部三年ともなると専門教育が忙しくなって、
そんな他分野のお遊びに首突っ込む暇はなくなる、という

825 ：仕様書無しさん：2007/04/28(土) 12:53:32

>>820
50後半なんだな。

826 ：仕様書無しさん：2007/04/28(土) 12:55:08

誰が？

827 ：仕様書無しさん：2007/04/28(土) 13:01:07

いずれにせよ、向学心旺盛なのは誉めるべきだけど、
その手の専門課程では習ってて当たり前の事について
ハッタリこいてウダウダ言い出すと新人さんに舐められるよ

828 ：仕様書無しさん：2007/04/28(土) 13:05:58

でも、このスレでオブジェクト指向についての理解度を見てると
専門課程で何を学んできたのか疑問？？？

829 ：仕様書無しさん：2007/04/28(土) 13:07:28

マジッすか？
うちの大学の情報は院行かないとオブジェクト指向までやらないみたいだよ
それともプログラミング関連なんて独学でやってて、学部二年までにやっとくべきって事？
確かに中高ぐらいでC++やJavaの機能駆使して実用アプリつくりまくってる人たちが居ることから
考えるとそれぐらい出来て当たり前という気もするけど

830 ：仕様書無しさん：2007/04/28(土) 13:07:52

そうね。それはね。本で学んだ表層の知識だけで理解したと勘違いしてるだなぁ。

831 ：仕様書無しさん：2007/04/28(土) 13:10:02

技術を極めるには、師の元でOJTが一番だろ。

832 ：仕様書無しさん：2007/04/28(土) 13:11:21

>>828
それはお前の説明が基礎的な部分で変だから
とても低いレベルの突っ込みが入っているだけだろう。
レベルを高くしたいなら、基礎的な部分の説明は省いて
もっとレベルの高い話に専念するというのも一つの手だ。
まあお前が説明が下手糞なだけで、きちんとした基礎ができている
という仮定の上の話だがｗ

>>830
意味不明抽象煽り乙
これだから頭が悪い奴は

833 ：仕様書無しさん：2007/04/28(土) 13:11:39

マスターとパダワン。

834 ：仕様書無しさん：2007/04/28(土) 13:11:47

完璧に理解せんでもOOPの恩恵に肖れるだけで十分だと思うけど
理論ってそういうもんでしょ？
何を以って理解したとするのか

835 ：仕様書無しさん：2007/04/28(土) 13:12:10

ここまでのまとめをオブジェクト指向でよろ

836 ：仕様書無しさん：2007/04/28(土) 13:13:39

そんな下らない話題は誰も興味を持たない。

837 ：仕様書無しさん：2007/04/28(土) 13:13:42

ムキになるなよ。勉強不足が伝わってくるよｗ

838 ：仕様書無しさん：2007/04/28(土) 13:14:25

なんだ今日の粘着当番は知能が劣悪な池沼の方か

839 ：仕様書無しさん：2007/04/28(土) 13:15:06

ロジカルシンキングと同じ流れだな
誰でも無意識で行ってる事に関心を無駄に注いで、意味無く難しくみせてるだけ
もっと力抜けよ

840 ：仕様書無しさん：2007/04/28(土) 13:15:54

OOPの恩恵ってか。OOPで迷惑掛けられてる方が圧倒的に多いちゅうの！

841 ：仕様書無しさん：2007/04/28(土) 13:16:03

池沼の書き込みはひたすら無意味
バカなんだから書き込みやめればいいのに

842 ：仕様書無しさん：2007/04/28(土) 13:17:42

それは恩恵に気づいてないだけだろ
短所って長所より目立つもんだし

843 ：仕様書無しさん：2007/04/28(土) 13:19:00

>>842
学生さんですか？
仕事はそんなにあまくないのよ。

844 ：仕様書無しさん：2007/04/28(土) 13:20:37

50代後半でこのグダグダかよ

845 ：仕様書無しさん：2007/04/28(土) 13:21:24

例えば、Gap Bufferを知ってる方居ますか？
もし知らなかったら、もっと勉強したほうがいいよ。

846 ：仕様書無しさん：2007/04/28(土) 13:23:30

なんでエディタのデータ構造をそんな自慢したがるんだ

847 ：仕様書無しさん：2007/04/28(土) 13:24:30

一生懸命、検索中。。。

848 ：仕様書無しさん：2007/04/28(土) 13:25:43

いやさ、なんでそんな瑣末な知識を自慢しようとしてるの？って聞いてるの。
Emacsの構造に興味を持った事がある人なら大抵知ってるだろ

849 ：仕様書無しさん：2007/04/28(土) 13:25:52

>>843
詳しく
趣味レベルのアプリだとCからC++に移行して
かなりバグが減ったんだけど、その程度のメリットなんて雀の涙
ってほど業務用ソフトウェアってヤバイという事ですか？

850 ：仕様書無しさん：2007/04/28(土) 13:26:31

OJTでダメな先輩に洗脳されちまった廃人のテクニック自慢なんて
えてしてそんなレベルだ

851 ：仕様書無しさん：2007/04/28(土) 13:29:08

ここの記述は謎だな。
http://www.kmonos.net/wlog/39.php

「時々「行=GapBufferOf文字、文書=LinkedListOf行」で使う、という解説を目にすることがあるんですけど、その構成は正直意味がわからんです。」
とか書きながら、説明の方はしっかり行＝GapBufferOf文字になっているというグダグダさ加減

852 ：仕様書無しさん：2007/04/28(土) 13:33:14

>>851
おまいが理解できていないことに気づかないか？

853 ：仕様書無しさん：2007/04/28(土) 13:34:03

>>848
検索乙

854 ：仕様書無しさん：2007/04/28(土) 13:36:21

なんだ理解できてない奴が表面上煽ってるだけか。
バカの相手して損したぜ

855 ：仕様書無しさん：2007/04/28(土) 13:39:42

ＧＷは楽しいね

856 ：仕様書無しさん：2007/04/28(土) 13:48:02

古い話題になるが
羽生田さんのAOSD解説はなかなか的を得ていたな。
ヤコブソンがユースケースをアスペクトと解釈してうんたらかたら。
違和感はない。

M$萩原さんのSoftware Factory解説の中のサブジェクト指向解説、
斜め読みした時はなかなかいい線行ってると思ったんだけど、
よくよく読んでみると何を言ってんだかわかんねぇな、相変わらず。
彼の話はいつも、断片的には素晴らしい事を言っているみたいな印象を
与えるんだけど、全体構造が不安定っつうか、全体構造の肝が
細部の仔細な事柄に依存していて、正しいかどうか判定し難いという・・・。

857 ：仕様書無しさん：2007/04/28(土) 13:52:16

萩原氏流のサブジェクト指向っつのは、
OOのドメインクラス＋FDDのフィーチャー
みたいな感じで不変部分と可変部分を分けましょうという話。

オブジェクト指向の業務システムは
処理がオブジェクトなんだぁ～！！！！なんて負け犬よりは
よっぽどまともに見える。

858 ：仕様書無しさん：2007/04/28(土) 14:02:29

楽しくないよ。

859 ：仕様書無しさん：2007/04/28(土) 14:10:13

マトモである事の方が重要だ

860 ：仕様書無しさん：2007/04/28(土) 14:23:12

楽しくてマトモであることが大切

861 ：仕様書無しさん：2007/04/28(土) 14:33:47

>>802
俺は覚えてない。
どうでも良いことはすぐに忘れるので
内容だけが頭に残るだけ。
それもそのときに重要と感じた部分以外は忘れてそうだけどな。
本のタイトルと情報のリンクは長くても一年前位までだな。

同じ内容が複数の本に載ってたりするのが
デフォルト状態だから覚える事に意味を感じない。

862 ：仕様書無しさん：2007/04/28(土) 14:37:28

どうでもいい話ばっかだな

863 ：仕様書無しさん：2007/04/28(土) 14:46:10

結局オブジェクト指向は、デザインパターンのセンスだけ修得すれば桶？

864 ：仕様書無しさん：2007/04/28(土) 14:46:35

>>804
数回書き込んだだけだろ。
食いついてくんな、キチガイ。
早く病院でカウンセリングを受けろYO!!

>>805
＋αを認めてるなら文句言うなYO!!
OOは魔法じゃないんだYO!!

>>813
同意。

別に俺はOO厨な訳じゃないので書いておく。
プログラムは効率のよい感じに書いてあれば
非OOPでも別に良いと思ってる。

それがOOPだといくらかしやすいよっていう簡単な話。
だから当然だけど非OOPで書き殴ったような糞コードを
書いてる人がOOPで書いても問題は解決しない。

865 ：仕様書無しさん：2007/04/28(土) 14:47:45

オブジェクト指向とは、処理対象に処理方法を割り振る方法論。
サブジェクト指向とは、オブジェクト指向を前提としつつ、
処理がオブジェクトに分散してしまう欠点を克服するために、
処理の主題(サブジェクト)に沿った処理記述を再導入しようという試み。
オブジェクトとサブジェクトは、AOPのweavingによって関連付ける。ｗ

866 ：仕様書無しさん：2007/04/28(土) 14:49:34

と、まあコレくらいの話ができないと21世紀らしくねぇんだな。

867 ：仕様書無しさん：2007/04/28(土) 14:51:07

>>865-866
そのレベルの話はもう2～3年前からさんざん行われているだろ。
このスレだけ30年前にタイムスリップしてるようだが

868 ：仕様書無しさん：2007/04/28(土) 14:51:44

サブジェクト指向ってコンサルが入れ食いしそうなネタだね。
おもしろそう。

869 ：仕様書無しさん：2007/04/28(土) 14:56:42

>>863
結局何をしたいかによるんじゃないか？

それによって利点も違ってくるだろうし。
継承と多態と隠蔽が基本で後は使い方のテクニックだよ。

あと、基本を深く理解するために概念等を深く学ぶ
必要がある場合のある人もいるし、そうじゃない人もいるってだけ。

例で言えば、一つ数式があっったとする。
ある人は見ただけで理解できて、派生の数式も頭に思い浮かぶ。
ある人は派生の数式を見たときに元の数式も理解する。
ある人は問題集を解きまくったときに理解する。

オブジェクト指向ってそういうもんだと思うな。

870 ：仕様書無しさん：2007/04/28(土) 14:56:52

バカコンサルに関わるとこのあたりの話は全然できなくなるわけだが。
バカコンサルに関わる前に俺がやろうとしていた仕事

http://www.research.ibm.com/sop/

871 ：仕様書無しさん：2007/04/28(土) 15:05:36

>>865
>>866
何がしたいのかわからないけどw
効果的と思うなら自分で実証してレポートでも
あげれば良いんジャマイカ？

>>867
少なくてもC++のコンパイラは何回も改定されていて
今の状態に落ち着いたのは数年前レベルだよ。
C++仕様事態が落ち着くのに時間がかかっている。

872 ：仕様書無しさん：2007/04/28(土) 15:07:47

初心者はデザパタ勉強したほうが近道なんでしょうか？

873 ：仕様書無しさん：2007/04/28(土) 15:13:31

>>870
最初はOOPも効果が懐疑的でなかなか浸透しなかったもんだよ。
そういう中を先人達が開拓して進んでいった訳だから
お前も突き進めばいいんジャマイカ？頑張れ～
と無責任に応援するw

874 ：仕様書無しさん：2007/04/28(土) 15:14:33

無理だよ。こいつニートだもんｗ

875 ：仕様書無しさん：2007/04/28(土) 15:16:48

>>872
近道です。デザパタでセンスを磨いてください。

876 ：仕様書無しさん：2007/04/28(土) 15:18:08

>>872
書籍：オブジェクト指向のこころが近道への近道です。

877 ：仕様書無しさん：2007/04/28(土) 15:18:20

バカコンサルの手にどんな重要な指摘をしても通じない。だからバカはバカなまま一生を終えるしかない。

878 ：仕様書無しさん：2007/04/28(土) 15:18:38

>>872
本当に本物の初心者なら、どこから手をつければいいかは迷いどころだな。
デザパタから入るのだけは違うけどw
今のところ、言えるのはこんなもんかな。

879 ：仕様書無しさん：2007/04/28(土) 15:22:03

初心者はアンチパターンからw

880 ：仕様書無しさん：2007/04/28(土) 15:23:13

>>878
デザパタって常套手段を集めたものなのでしょう？
そこから手を広げるってのは間違ってないっと思うんですが
デザパタから入るのが大間違いって理由を教えてください

881 ：仕様書無しさん：2007/04/28(土) 15:24:48

>>878
デザパタから入るのは正解です。安心してください。
なんでもそうですが、スタイルを真似ることから始めるのは良いことです。

882 ：仕様書無しさん：2007/04/28(土) 15:27:55

>880

どうしてそうなっているのがよいのか、も分からずにスタイルだけ真似してる奴は
所詮偽者

ブランド品が買えない貧乏人w

883 ：仕様書無しさん：2007/04/28(土) 15:30:22

>>880
間違ってないと思うなら、そうすればいいじゃない。
貴方の情報が足りないので明確な事は言えない。

一つ例をあげると、本物の初心者には情報処理の基本や
コンピューターのしくみの理解も重要。

884 ：仕様書無しさん：2007/04/28(土) 15:34:59

>>881
そんなことはない。
初心者がプロ仕様の方法や道具を使っても
なんちゃってなだけで上達にはよくない。

学習という意味においては
段階によっていろいろと使い分けるべき。

885 ：仕様書無しさん：2007/04/28(土) 15:35:52

私の知識の程度としては
独習C、独習C++、STL標準講座と一通り軽くさらってきた程度です
計算機の知識としては教養程度の情報リテラシー、初歩的な情報数学を修めた程度
そろそろOO用の機能を効果的に利用して設計することも勉強したくなってきたので
デザパタに目を付けたのですが間違ってますか？

886 ：仕様書無しさん：2007/04/28(土) 15:48:25

>>885
学生さんみたいですね。
基本が抑えられていれば、特にやり方で問題は起きないのではないでしょうか？

887 ：仕様書無しさん：2007/04/28(土) 15:51:55

>>885
あと、そろそろ専門の知識の習得にも時間を割くと良いと思います。
進路によって必要な知識はかなり異なります、老婆心ながらですが…

888 ：仕様書無しさん：2007/04/28(土) 15:55:33

またデザパタか
高弘って難しい事言われて戸惑うと
すぐデザパタ議論を始めるからバカバカしいんだよ

889 ：仕様書無しさん：2007/04/28(土) 15:57:22

結論：>>1の近辺を除き、オブジェクト指向開発は普及している。
　　　　>>1の近辺でオブジェクト指向開発が流行らないのは、
　　　　>>1の性格と頭に問題があって、まともな人間が寄り付かないから。

終了

890 ：仕様書無しさん：2007/04/28(土) 15:57:40

>885
べつにいいんじゃねの？
「ハンマーを持った人は全てが釘に見えて叩きまくる」症候群にさえ気をつけてれば

1画面に収まらない"ハローワールド"には笑えない...

891 ：仕様書無しさん：2007/04/28(土) 15:58:55

>>889
とても判りやすい結論だ
おかしいと思ってたんだよね
彼の居るスレに限って、
いつも世間とずれた話ばかりしているから

892 ：仕様書無しさん：2007/04/28(土) 15:59:48

オブジェクト指向が判らないのは一部の池沼だけと結論が出たから、
次はもっと現代的な話題に移ろう。

893 ：仕様書無しさん：2007/04/28(土) 16:04:55

オブジェクト指向はどのような問題を抱えているか
その問題を解決するには、どういった手段をとればいいか

894 ：仕様書無しさん：2007/04/28(土) 16:13:43

なんだ？このスレを流したい流したいというふいんきは？

俺も手伝ってやろうｗ

895 ：仕様書無しさん：2007/04/28(土) 16:14:19

オブジェクト指向が抱える問題ではないかもしれないが、
底辺に居るオブジェクト指向コンサルにはこんなとんでもない奴が居る。
こいつらをどうやって排除すれば良いか話し合えば、少しは底辺のレベルも向上する事だろう。

事例１：OOPは理解できるが、OODを理解していない人間が
　　　　「設計レベルでデザパタを駆使する」という奇妙な概念を振り回して
　　　　現場を混乱に陥れる。
　　　　デザパタとはマイクロ・アーキテクチャ、イディオムレベルの事柄に過ぎず、
　　　　アーキテクチャや概要設計レベルに持ち込むべき概念ではない。

896 ：仕様書無しさん：2007/04/28(土) 16:15:54

設計とデザパタの接点と言えば、
せいぜいクラス設計とか詳細レベルの話だろう。
アーキテクチャを論じる場面でデザパタデザパタ煩い奴が居たら、
キチガイとして放り出すのが適切だ

897 ：仕様書無しさん：2007/04/28(土) 16:17:17

次スレタイトル：
【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの

898 ：仕様書無しさん：2007/04/28(土) 16:21:19

タイトル：【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★6
URL：http://pc11.2ch.net/test/read.cgi/prog/1175099288/
【糞スレランク：ＳＳ】
直接的な誹謗中傷：42/897 (4.68%)
間接的な誹謗中傷：599/897 (66.78%)
卑猥な表現：14/897 (1.56%)
差別的表現：33/897 (3.68%)
無駄な改行：2/897 (0.22%)
巨大なＡＡ：6/897 (0.67%)
by 糞スレチェッカー Ver0.73 http://kabu.tm.land.to/kuso/kuso.cgi?ver=73

899 ：仕様書無しさん：2007/04/28(土) 16:25:33

>>895
その考えには賛同できない。
デザパタは設計レベルで用いるのが正解です。
デザパタは概念なのだから。

900 ：仕様書無しさん：2007/04/28(土) 16:32:01

>>899
お前、信念表明しかできないヘタレだろ。
証明せよと言うとまたぞろ大規模開発をデスマーチ化するのが落ちだからなあ

901 ：仕様書無しさん：2007/04/28(土) 16:33:34

デザパタ使うのなんて、
せいぜいアーキテクチャ設計のサンプルコードや
クラス設計レベルの話だろ。

そこでマルチスレッドのノウハウもなく、
疎結合に関するノウハウもなく
ダメダメな結果を出したのが鈴木高弘

902 ：仕様書無しさん：2007/04/28(土) 16:34:30

> デザパタは概念なのだから。

違います。
デザパタは概念ではなく
クラス設計レベルのノウハウに過ぎません。

903 ：仕様書無しさん：2007/04/28(土) 16:46:23

デザパタデザパタ煩い奴に限って、
本当はデザパタをきちんと理解できていない。
例えばインタープリタパターンと言葉で言っても、
再帰下降パーサを理解できていなければ実装のしようがない。
要するに、鈴木高弘の言うデザパタとは
鈴木高弘本人が未だに理解できていないノウハウ、未来技術の総称ｗ

904 ：仕様書無しさん：2007/04/28(土) 16:47:11

UFOは宇宙人のデザパタ技術で実装されているんだね、きっとｗ

905 ：仕様書無しさん：2007/04/28(土) 16:48:08

大統一理論のキーはデザパタが握っているｗｗｗ
アインシュタインの宇宙定数はデザパタ２３パターンの事だｗｗｗｗｗｗｗ

906 ：仕様書無しさん：2007/04/28(土) 16:53:09

デザパタ＝クラス設計レベルのノウハウ　という勘違いｗ

907 ：仕様書無しさん：2007/04/28(土) 16:57:17

はいはい池沼は口が減らないなあ

バカだから単に争い事をしたいだけなんだろ

908 ：仕様書無しさん：2007/04/28(土) 17:01:13

池沼にとってデザパタとは
万物の根源であり
全ての事象が従うべき法則であり
池沼の人格の基礎となる
絶対不可侵の存在なのでしょうｗ

909 ：仕様書無しさん：2007/04/28(土) 17:24:37

What Is Software Design?
ソフトウェア開発では，「すべて」が設計プロセスの一部になっているという大きな問題があります。コーディングは設計であり，テスティングとデバッギングも設計の一部であり，私たちが一般的にソフトウェア設計と呼んでいるものもやはり設計の一部なのです。

910 ：仕様書無しさん：2007/04/28(土) 17:30:41

やっぱりね

お前の用語遣いは一般人のそれと激しく解離している
だからお前の周りはお前と話が通じない奴ばっかなんだ
おかしいのはお前自身だとはやく気付け

911 ：仕様書無しさん：2007/04/28(土) 17:38:43

なるほど。陳腐な知識しか持っていない低脳が
トンチンカンな用語遣いをして他人に怪訝な顔をされて
「オブジェクト指向は理解されていない」とか喚いているだけか。

akonの言う勘違いって要するにそのレベルの話か

912 ：仕様書無しさん：2007/04/28(土) 17:45:17

伊賀者元気だなｗ

913 ：仕様書無しさん：2007/04/28(土) 17:47:43

またお前の脳内友達の話題か
お前はリアルな友人が少ない割に
脳内友達には事欠かないようだなｗ

914 ：仕様書無しさん：2007/04/28(土) 17:49:03

伊賀者といえば忍者ハッタリくんの事？
ハッタリ最近元気ねぇな。また事業に失敗したのかｗ

915 ：仕様書無しさん：2007/04/28(土) 17:53:47

なにそれ
２年毎に会社から逃げ出している人の事？
今年もそろそろ逃げ出す時期だな

916 ：仕様書無しさん：2007/04/28(土) 18:46:35

ほんっと飽きないねえ
おんなじことばっかり延々と

917 ：仕様書無しさん：2007/04/28(土) 18:50:02

>909
もしお前が「ソフトウェア開発の全てが設計プロセスである」と主張したいのであれば、
グータラな大規模開発の影にかくれてこそこそオブジェクト指向もがきを続けるのではなく、
お前の考える開発プロセスの理論化と実践に努力を注ぐべきだろう。
そのような努力なしに上記の主張をするのは、お前自身の怠惰さを誤魔化すのが目的なのだろう。

918 ：仕様書無しさん：2007/04/28(土) 18:51:44

>>916
このスレの主は偏執狂だからな。
ちょっと目を離すと、延々同じ話を書き続ける。
たまに構ってやっても、大体同じパターンの反応しか示さない。
成長が止まった技術者というのは、こんなものなのだろう。

919 ：仕様書無しさん：2007/04/28(土) 18:52:50

>917

つ"Development Baseline"

920 ：仕様書無しさん：2007/04/28(土) 18:53:13

>>917
頭悪すぎてアンチ理論になった人だから
自分自身を正当化するための理論構築もタブーなんだろう。

921 ：仕様書無しさん：2007/04/28(土) 18:54:22

>>919
つお前の発言は常に意味不明。
　　ベースラインとは改善作業の基準の事だが
　　それが何か？

922 ：仕様書無しさん：2007/04/28(土) 18:59:05

ここのスレ主は了見が狭すぎる。

OO設計の議論してぇとか言い出すから
UMLまで書いて議論の土台を起こしてやれば
キチガイ呼んで来てスレを滅茶苦茶にするし、

スレ主の過去の設計の問題点を議論しようとすれば
人をキチガイ呼ばわりして延々と議論妨害を始めるし、

デザパタ、リファクタ、構造化以外にネタを持ってなさそうだから
新しい議論の核を投入してやっても、ロクに反応できず放置しちまうし。

いったいおまえって何のためにスレに粘着してるんだよ。
お前の人生が無意味だからといって、
その内側で発生した害毒を世の中に垂れ流し続けるのは正しくない。
さっさと人生を終了した方がいいよお前。

923 ：仕様書無しさん：2007/04/28(土) 19:00:14

休日の高弘いじりは愉しいなｗ

924 ：仕様書無しさん：2007/04/28(土) 19:03:05

>>921
要するに>>919は >>909がとてもユニークな考え方だと信じていて、
>>909の普及活動をしないと >>909をベースにした議論ができない
とか信じ込んでいるんだろう。
実際はそのような考え方など多くの人が理解しているのに(一部低学歴は除く)

925 ：仕様書無しさん：2007/04/28(土) 19:09:21

結局、不可知論者なのだろう。
自分のやっている事の不合理は決して自分の責任ではなく、
誰か頭がいい人が解決すべき問題だと考えて
いつまでたっても「こっちにいいヒントがあるらしい」とか
とんでもない方向指して、人々を混乱に陥れるだけの曲者。

926 ：仕様書無しさん：2007/04/28(土) 19:22:14

さっきからスレ主がどうのこうのいってるけどさあ、
このスレはおまえがたてたんじゃねえかよ
みんな次スレｲﾗﾈつってるのによおｗ

927 ：仕様書無しさん：2007/04/28(土) 19:24:28

↑この人を真犯人です゜

928 ：仕様書無しさん：2007/04/28(土) 19:25:39

>>923
ゴミみたいな人生もうやめちゃえば？ｗ

929 ：仕様書無しさん：2007/04/28(土) 19:26:09

俺もこのスレ要らねぇ

たまに高弘いぢりするくらいしか用はねぇ

930 ：仕様書無しさん：2007/04/28(土) 19:26:59

いいねえ
さっさと自殺しろよ

931 ：仕様書無しさん：2007/04/28(土) 19:28:58

これよりこのスレは
スレ主の人生の終了方法を議論するスレとなりますた。

932 ：仕様書無しさん：2007/04/28(土) 19:30:45

教会で異端尋問して破門後火炙り

933 ：仕様書無しさん：2007/04/28(土) 19:33:05

大規模開発現場でデスマの全責任おっかぶせて過労死

934 ：もっと効果的な方法があるだろｗ：2007/04/28(土) 19:40:44

>>1に書かれてるNGワードを連呼して、発狂死させる

935 ：仕様書無しさん：2007/04/28(土) 20:26:16

次スレ立てるやつ、NGワードにもうひとりの糞コテ名も突っ込んどいてね。

936 ：仕様書無しさん：2007/04/28(土) 20:27:03

おまえ発狂してるけど死んでないじゃん>>版画

937 ：仕様書無しさん：2007/04/28(土) 20:30:16

>>935
だから次スレいらねってw
もう糞スレたてんなボケ>>版画

938 ：仕様書無しさん：2007/04/28(土) 20:32:45

高弘が発狂し始めたｗ

939 ：とおりすがり：2007/04/28(土) 20:33:45

このスレ変

940 ：仕様書無しさん：2007/04/28(土) 20:38:02

ほとんどハッタリ一人の自作自演スレだからな
ハッタリの脳内世界全開の奇妙なワールドなのさ

941 ：仕様書無しさん：2007/04/28(土) 20:42:01

まったくだな。なにがサブジェクト指向だよw

942 ：仕様書無しさん：2007/04/28(土) 20:43:19

そうだな。ハッタリの脳内ではOOを超える方法論など
存在すら許されないんだもんな。

943 ：仕様書無しさん：2007/04/28(土) 20:46:23

ハッタリに足止め食らわせるのはとても簡単だ。
２ちゃんで煽りながら新しい話題を振れば、
必ずハッタリはその話題を否定してかかる。
そして今や、ハッタリと世間の技術的乖離は約30年。
もっともっと退化して、みんなを笑わせてクレ！ガンバ！

944 ：仕様書無しさん：2007/04/28(土) 20:53:50

いいか？次スレいらねーぞw
自分で立てといて
乙！とかきめえこといってんじゃねーぞ？w>>版画

945 ：仕様書無しさん：2007/04/28(土) 21:02:08

ここは糞スレ化するとほんとに速いなw
伊賀者とか鈴木とか誰の事だよ。
特に個人名出しちゃあかんだろ。

以前も書いたことあるけど、ほんとに氏ねよ。
粘着うざいよ。

946 ：仕様書無しさん：2007/04/28(土) 21:06:36

公人の名前が頻出するのはしょうがないだろ。
匿名であろうと社会的責任を持って発言してもらわないといかんからな

947 ：仕様書無しさん：2007/04/28(土) 21:08:11

>>944
お前が一番スレ立てフラグ立ってるじゃねぇ～か。
いいか、スレは絶対に立てるなよ！絶対だぞ！
もしスレが立ったら嵐まくってやるからな！ｗ

948 ：仕様書無しさん：2007/04/28(土) 21:08:56

946 名前：仕様書無しさん []：2007/04/28(土) 21:06:36
公人の名前が頻出するのはしょうがないだろ。
匿名であろうと社会的責任を持って発言してもらわないといかんからな

949 ：仕様書無しさん：2007/04/28(土) 21:10:13

いいかぁお前ら

絶対に次スレは立てるなよ

特にスレタイは

　　　　　【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの

こんなの絶対まずいって。いくらハッタリでも頭から湯気立てて怒るぞ

だから、次スレは絶対立てるな

950 ：仕様書無しさん：2007/04/28(土) 21:11:00

きみひとクン大人気だな

951 ：仕様書無しさん：2007/04/28(土) 21:12:48

次スレ

【OOD/A】偽ｵﾌﾞｼﾞｪｸﾄ指向ｺﾝｻﾙってなんで死滅しないの ★7
http://pc11.2ch.net/test/read.cgi/prog/1175099288/1

952 ：仕様書無しさん：2007/04/28(土) 21:14:07

>>947
俺はたてねーよ。
だれもたてねーよ。
お前以外はw>>版画

953 ：仕様書無しさん：2007/04/28(土) 21:15:29

>>952
しらじらしいぞハッタリ
もう立ってるじゃん

954 ：仕様書無しさん：2007/04/28(土) 21:16:38

ハッタリきみひとクン
結局誰かに構って欲しいんだね
さびしい人ｗ

955 ：仕様書無しさん：2007/04/28(土) 22:39:28

しかし、マジで、デザパタ＝クラス設計レベルのノウハウ　と思ってるのか？
とんでもない勘違いだぞ。

956 ：仕様書無しさん：2007/04/28(土) 22:48:19

元はITの外の世界の概念なんでそう思ってるわけじゃないけど
クラス設計レベルでの利用しかしてない俺は趣味ﾌﾟﾛｸﾞﾗﾏ

957 ：仕様書無しさん：2007/04/28(土) 22:55:57

937=944=947=952(自己レス自演乙)

958 ：仕様書無しさん：2007/04/28(土) 23:00:59

また代案を提示できないキチガイが活動開始か

959 ：仕様書無しさん：2007/04/28(土) 23:02:28

まぁ、素直に勉強し直すことだね。もう無理かもしれんが。

960 ：仕様書無しさん：2007/04/28(土) 23:08:24

キチガイ高弘的にはデザパタにどんな幻想を抱いちゃってるんだい？

どうせまた回答もせずに1000までゴネるだけだろうけど、一応聞いてやるよ

961 ：仕様書無しさん：2007/04/28(土) 23:10:47

詐欺師として材料が古すぎるんだよな
いまどきデザパタデザパタ喚いて、
その割に23パターン全て把握できてないのって
鈴木高弘くらいだろ

962 ：仕様書無しさん：2007/04/28(土) 23:10:53

新スレ

ｵﾌﾞｼﾞｪｸﾄ指向開発は構造化開発と何が違うの？★7
http://pc11.2ch.net/test/read.cgi/prog/1177769397/

963 ：仕様書無しさん：2007/04/28(土) 23:11:47

960も961も、おまぃらどっか行け
生産性の無い粘着厨房うざすぎ

964 ：仕様書無しさん：2007/04/28(土) 23:12:03

似非ｺﾝｻﾙちゃんは今
ドラゴンブックを読むのに必死。

この20年間一体何やってたのかと
問い詰めたい気分だ

965 ：仕様書無しさん：2007/04/28(土) 23:13:15

>>964
Fランク大学で留年してた落ちこぼれには
読破はムリだろう。
いや、読んだフリだけして中身は理解できていない
というパターンもあり得るがｗ

966 ：仕様書無しさん：2007/04/28(土) 23:18:04

詐欺師の人
そろそろ対案出さないと
詐欺がバレバレになるぞ

お前の脳内妄想をサクッとゲロッちまえよバーカ

967 ：仕様書無しさん：2007/04/28(土) 23:21:12

詐欺師がその生活の糧としている
詐欺ネタをゲロるわけねぇ～だろ

デザパタで金融証券向け大規模OO開発ができますって
これからも詐欺人生を続けていくつもりなのだから。

せめてM$のHﾜﾗ氏くらい高級な事言えば
もうちょっとマシなカモを引っ掛ける事ができるだろうに
よりによって「デザパタ」だぜぇ

968 ：仕様書無しさん：2007/04/28(土) 23:24:55

詐欺師というより勘違いだろう
本人がデザパタすらきちんと理解できていない事を判っていないのだから
騙すつもりじゃなく、本気で見当違いな事を言っているだけ。
一回話せばすぐ判る事だ

969 ：仕様書無しさん：2007/04/28(土) 23:28:21

基礎的な勉強ができていない人って
数少ない古臭い知識で全てを説明しようとするから
滑稽だね

970 ：仕様書無しさん：2007/04/28(土) 23:29:41

まぁ、素直に勉強し直すことだね>>鈴木

971 ：仕様書無しさん：2007/04/28(土) 23:30:51

【今日のレスの総括】
本題を忘れ会議が成り立たない連中

972 ：仕様書無しさん：2007/04/28(土) 23:31:37

よく分からんが、アンチな連中
必死だなｗ

973 ：仕様書無しさん：2007/04/28(土) 23:35:23

>>972
お前の言うアンチって誰の事？
お前の日本語能力が低いのはよく知っているけど。
話の筋すら追えないほどのナルシストなのか。
迷惑な人間だ

974 ：仕様書無しさん：2007/04/28(土) 23:38:22

必死だなｗｗｗ

975 ：仕様書無しさん：2007/04/28(土) 23:41:54

おっぱい大好き星人が降臨しないと
からかいがいがないな

池沼の相手はつまらん

976 ：仕様書無しさん：2007/04/29(日) 09:49:27

オブジェクト指向は勘違いが多いよね。

977 ：仕様書無しさん：2007/04/29(日) 09:50:30

複雑な問題を簡単化する技術のはずなのに、さらに複雑化させている。

978 ：仕様書無しさん：2007/04/29(日) 09:51:56

強力な概念だけに危険性を併せ持ってる。

979 ：仕様書無しさん：2007/04/29(日) 09:52:54

プログラムをクラスでパズル化するから手に負えない。

980 ：仕様書無しさん：2007/04/29(日) 09:56:44

そもそも技術は体系立てられたものなのだから、その体系を学ばず
いきなりオブジェクト指向は無理だろ。

981 ：仕様書無しさん：2007/04/29(日) 19:40:20

オブジェクト指向が有益じゃないなんて、理解できない奴の妬みだろ。
どこの世界にもいるな。素質が無いんだからこの仕事さっさとやめてくれれば
助かるんだが、そんな奴に限って管理職としてのさばるったりするから始末に
負えない。

982 ：仕様書無しさん：2007/04/29(日) 20:46:13

日頃のルサンチマンが爆発した模様です。

983 ：仕様書無しさん：2007/04/29(日) 21:30:42

>>981
同意だね。当人は素質がないことに気づいてないんだよね。
不思議だよね。

984 ：仕様書無しさん：2007/04/29(日) 23:00:23

どっかのキチガイが立てた次スレ、
リアルに壊れてる人が来ちゃったな

985 ：仕様書無しさん：2007/04/30(月) 00:16:43

OOを理解できない人はできる人を基地外や馬鹿扱いする傾向にあるようです。
また、子供言葉で叩くしか能が無く論理的に説明するのが苦手なようです。
まともに相手しても疲れるだけなので関わらない方が無難です。

986 ：仕様書無しさん：2007/04/30(月) 07:20:49

そういうレベルの壊れ方じゃないだろ

987 ：仕様書無しさん：2007/04/30(月) 07:23:04

相手のレベルにあわせて教えてやればいいのに、
OO理解できない奴は馬鹿、だもんね。
まあ、これじゃ流行るわけ無いよ。

988 ：仕様書無しさん：2007/04/30(月) 10:03:49

GWだな～

989 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/30(月) 10:57:51

システム工学はなぜ理解されないのか

そういやソフト屋さんは一番理解率低そうだな。

990 ：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. ：2007/04/30(月) 11:00:49

問題
コンピューターを使わない（使っていなかった）システムを三つ挙げよ。

答えられなかったらあなたは今後システムという言葉を使ってはなりません。

991 ：仕様書無しさん：2007/04/30(月) 11:06:59

船舶、航空機、製造業

992 ：仕様書無しさん：2007/04/30(月) 11:37:02

荒らしはスルーしれ

993 ：仕様書無しさん：2007/04/30(月) 11:47:40

質問の意味が不明瞭だな。意図を充分且つ簡潔に伝えられない奴は
独りよがりの設計したりコードを書く傾向がある。
システムの定義が曖昧だし、現存するという条件が無いから、狼煙、
荘園公領制、参勤交代　でいいか。

994 ：仕様書無しさん：2007/04/30(月) 11:51:11

分かっている人達の間では十分に流行ってるんだから
馬鹿はスルーでいいよ。馬鹿に流行らせる必要はない。

995 ：仕様書無しさん：2007/04/30(月) 13:04:45

オブジェクト指向が理解できてる香具師っているのか？
いないだろ。

996 ：仕様書無しさん：2007/04/30(月) 13:05:16

みんな理解できたと勘違いしてるだけさ。

997 ：仕様書無しさん：2007/04/30(月) 13:24:15

そのとおり。
おそらく各流派の開祖しか正しい理解を出来ていない
と。

998 ：仕様書無しさん：2007/04/30(月) 13:36:11

自演馬鹿。独りでやってろ。

999 ：仕様書無しさん：2007/04/30(月) 13:37:59

馬鹿は自分が理解できないものは、人も理解できていないと思うらしい。

1000 ：仕様書無しさん：2007/04/30(月) 13:39:35

生まれて初めての１０００ゲットォー＼^_＿^／

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。