07/03/29 01:28:08
過去スレ
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4
ｽﾚﾘﾝｸ(prog板)
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5
ｽﾚﾘﾝｸ(prog板)
スルー推奨ワード（相手をした場合は荒らしとみなされます）
電球、たかひろ
このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。
なので設計だけ、実装だけといった縛りは特にありません。
設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。
いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、
書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。
2:仕様書無しさん
07/03/29 01:30:07
乙！
3:仕様書無しさん
07/03/29 01:30:39
JAVA案件て火噴いてるの多いがなんで？
4:仕様書無しさん
07/03/29 01:30:40
☆コテは書き込み禁止
5:仕様書無しさん
07/03/29 01:32:00
>>3
オブジェクト指向で作ることを目的にしちゃってるから。本来手段なのに。
6:仕様書無しさん
07/03/29 01:33:10
>>3
業務系案件のほとんどがJavaだから
7:仕様書無しさん
07/03/29 01:33:47
OOを理解できない理由
とりあえず列挙して、それなりに挙げ終わってから１つずつ判定しましょ
あと、できればマニアックな専門用語ではなくそれなりに分かる言葉で挙げていきましょ
１．疎結合が理解できてないから
２．練習量（実務経験・もしくはそれに類するもの）が少ないせい
３．Javaを習得していないから
４．プログラムに現実世界を投影しようとするから
５．クラス・継承・多態性・カプセル化などのオブジェクト技術概念のメリットを理解していないから
６．手段であるはずのオブジェクト指向なのに、OOで作ることが目的になったPJが多いから
７．言葉の洪水でやる気が無くなるから
８．大規模PJにより各担当箇所が結局OOではなく機能分岐してしまうから
９．偽装請負による技術者の定着性の無さや玉石混交化のため
10．DBを使う現場が多い中でトランザクションはOOと相性が悪いから
11．学習途中で諦める技術者が多いから
8:仕様書無しさん
07/03/29 01:36:37
高弘、スレ立て乙
今回はpart1やpart2のように、延々と長文で自作自演の押し問答すんなよ、
あれやると、コミュニケーションが成立しなくなるから迷惑だ。
9:仕様書無しさん
07/03/29 01:38:47
スルー推奨ワードを相手にしないようにお願いします
相手にした場合も荒らしとみなされます
10:仕様書無しさん
07/03/29 01:39:54
>>3
・Javaで基幹系大規模開発して名を上げようなどという高弘のように
無謀なバカが世の中にはわんさと居るから。
・Javaどころかオープン系の構築すらおぼつかないold COBOLerが
足を引っ張るから。
11:仕様書無しさん
07/03/29 01:40:35
もう、前スレ継続審議中のオセロ設計無し？
12:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/29 01:41:14
１２・ ＯＯ厨の能力と態度がアンバランスなのを見てああはなりたくないと思う
13:仕様書無しさん
07/03/29 01:41:22
>>8
俺も長文自作自演禁止に賛成。
自作自演中になんか発言すると、思い切りスルーしてくるから不愉快だ
14:仕様書無しさん
07/03/29 01:43:12
OOを理解できない理由
・高弘が大規模プロジェクトで似非オブジェクト指向を広めるから、
プロジェクトが失敗し、それに関わった人々がホンモノのOOまでも嫌いになる
15:仕様書無しさん
07/03/29 01:46:06
>>11
オセロは詳細設計っぽくなってきたくね？
16:仕様書無しさん
07/03/29 01:47:14
>>10
いきなり大規模開発にJava突っ込むのは、
泳げもしない奴をいきなり海に突き落とす位に無謀だ。
まずは新規サブシステム１個程度から始めて、
長期的に徐々に浸透させていくのが正道。
それを許さない状況があれば、その仕事は請けるな。
17:仕様書無しさん
07/03/29 01:49:55
>>15
あの設計はほとんど俺だけどな。
夜中に文章だけ書いてきて「設計でござい」ってしたり顔してた 前ｽﾚ193には
ホント絞め殺したろうかと思った。
・・・まあ時間見つけてクラス図とシーケンス図描いてやったけどな。AAでｗ
18:仕様書無しさん
07/03/29 01:50:56
>>7 のはよくできてるんで補完してって
建設的な話をしてけばいいんじゃね？
19:仕様書無しさん
07/03/29 01:52:24
☆お約束
高弘を相手にしないようにお願いします
相手にした場合も荒らしとみなされます
20:仕様書無しさん
07/03/29 01:52:34
>>15
もまぃえらいよ、いやホントに
素直に感心したし
ただ寝不足には気をつけないかんばい
21:仕様書無しさん
07/03/29 01:53:23
>>20
おい志村、志村、アンカーアンカー。(棒読み
22:仕様書無しさん
07/03/29 01:53:35
19 名前：仕様書無しさん[sage] 投稿日：2007/03/29(木) 01:52:24
☆お約束
高弘を相手にしないようにお願いします
相手にした場合も荒らしとみなされます
修正。
☆お約束
高弘関係者と電球関係者を相手にしないようにお願いします
相手にした場合も荒らしとみなされます
23:20
07/03/29 01:54:30
ぶｗ
アンカーミスったｗ
>>18な。
24:仕様書無しさん
07/03/29 01:54:50
問題は高弘の扱いだな
香具師がまた匿名で中傷活動を始めなければいいんだが
25:20
07/03/29 01:55:40
うｗｗ
さらにやらかしたｗｗ
>>17だった
今夜の梅酒はキクなあ
26:225
07/03/29 01:55:49
再訂正
☆お約束
高弘と豆蔵関係者を相手にしないようにお願いします
相手にした場合も荒らしとみなされます
27:仕様書無しさん
07/03/29 01:56:55
電波2ch.cgiみたいな具合だな。
ところどころ高弘風味になってて
28:仕様書無しさん
07/03/29 01:58:54
自演必死な奴がいるな
29:仕様書無しさん
07/03/29 02:02:49
>>28
自作自演乙。
おまえ暇なんだな
30:仕様書無しさん
07/03/29 02:03:04
>>17
お前さん設計だったのか、設計を公表するときはトリ付きでやったほうがいいな。
普段はトリなしで、必要なときはトリをつけるいいかも(設計者発言と判る）。
31:仕様書無しさん
07/03/29 02:10:05
>>30
頼むから下らない入門者用設計図で俺の手を煩わすな。
今後はAAEdit使って自分で書け
URLﾘﾝｸ(aaesp.tripod.co.jp)
あと、分析にしろ設計にしろ実装にしろ、
優劣はあるかもしれないし、その比較や議論も大事だけど、
次の事を守ってくれ。
1. 問題の要件定義を明確にしてから、分析/設計/実装に入る
2. 他人を無理に説得しようと思うな。回答は何通りでも有り得る。
ただ、その回答の差が、どうして発生したかを考えて議論しろ。
32:仕様書無しさん
07/03/29 08:45:10
>>31
結局自分で書いたんだから「俺の手を煩わすな」もなにも無いだろ、
という突っ込みどころはあるけど、
書きたい奴はAAEditな。
33:仕様書無しさん
07/03/29 08:49:38
俺はobject指向が理解できないんじゃなくて
コードが遅くなるからつかわないんだが。
34:仕様書無しさん
07/03/29 09:27:49
そもそもそのへんの会社や派遣プログラマに、積極的に良い物を作りたいいう動機がない。
OOPやアジャイル開発は、優れたアプローチっていうか、俺らからしたら常識なんだけど、
ゴミプログラマは勉強する手間より小手先で終わらせることを選ぶ。
理由は覚えるのがめんどくさいから。
ドラゴン桜の「目の前に川があって向こう岸に渡りたいときどうするか」っていう話。
凡人はずぶぬれになって渡る。東大生は周辺を探してぬれずに渡る方法を探す。
凡人は探す方が手間だしめんどくさいと思う。
東大生はぬれずに渡る方が楽する方法だと思う。
ホントに東大生がそうかどうかは別としてPGには当てはまる。
OOPやアジャイルなんかまわりくどいし覚える時間が手間だし開発遅くなるってのは、
まさにずぶ濡れで川渡る奴。
35:仕様書無しさん
07/03/29 11:42:07
ちゃんと教育せずに現場に放り込むのやめれｗ
36:仕様書無しさん
07/03/29 11:52:49
>>34
とFランク大出身者が申しておりますｗ
37:仕様書無しさん
07/03/29 12:07:49
>>36
Fランク大ってどこよ
38:34
07/03/29 12:19:02
う、確かにFランクだけどさ・・・プログラムはできるお。
一PGとしての結論は、
どんな優れた設計手法・開発手法があろうが、やる気のない奴はそれに従わない。
これは絶対不動。だからチーム開発でデスマは絶対になくならない。
自分がデスマらないための一番の方法は独立して無能PGと一緒に仕事しないこと。
39:仕様書無しさん
07/03/29 12:23:34
おじゃばさま、なんでこっちではコテ付けないの？
あと、あっち↓
ｽﾚﾘﾝｸ(prog板)
毎日毎日スローモーションでたらたら同じ質問繰り返されてもラチあかんから
さっさと質問出してくれ。
40:仕様書無しさん
07/03/29 12:29:30
今から勉強するならJavaと．NET（C#かVBあたり）どっちがええかいな。
一応コボル系PGッス。（OO可能なメーカー独自言語）
あと、デザインパターンを勉強したほうがいいのかな？
41:仕様書無しさん
07/03/29 12:31:17
>>38
>>35 ：仕様書無しさん ：2007/03/29(木) 11:42:07
> ちゃんと教育せずに現場に放り込むのやめれｗ
こっちもスルーせずに回答したらどうよ？
結局自分に都合の悪い現実は見ずに、妄想垂れ流してるだけだろお前
42:仕様書無しさん
07/03/29 12:32:04
初心者にデザパタを押し付けて失敗するのは高弘パターン
43:仕様書無しさん
07/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:仕様書無しさん
07/03/29 12:42:00
>>43
GoFのデザインパターンは、
Smalltalk～初期C++時代の遺物。
出版当時からだいぶ様変わりしたC++や、
出版後に出現したJava, C# とは
大きなセマンティック・ギャップがある。
45:仕様書無しさん
07/03/29 13:11:20
>>41
教育受けてないからできませんなんて言い訳だよ。できないからできないだけ。
バージョン管理してテスト書こうって言ったって派遣PGの寄せ集め集団がやるわけない。
お前こそ現場知ってるのかよ。
46:仕様書無しさん
07/03/29 13:18:13
>>45
>>35に直接言えバカ
47:仕様書無しさん
07/03/29 13:18:32
セマンティック・ギャップなんかねぇょ。
48:仕様書無しさん
07/03/29 13:31:15
初心者にデザパタを押し付けて失敗するのは高弘パターン
49:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/29 22:44:32
まいったぜ今日はデスマーチ残業だった。
50:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/29 22:50:14
地雷原を掘り返してしまったんだな。
ちょっとした仕様変更をやろうとしたら次から次から 汲めども尽きないバグの山。
元に戻して運用で対処してもらうことにした。
コマンドパターン厨の作品だ。
51:仕様書無しさん
07/03/29 23:12:41
あぼーん表示が増えていく増えていく
52:仕様書無しさん
07/03/29 23:25:25
オブジェクト指向を勘違いして石コロばかり作るから失敗するのだよ。
オブジェクトは物ではなくて概念なんだなこれが。
53:仕様書無しさん
07/03/29 23:25:59
つまらん
54:仕様書無しさん
07/03/29 23:33:10
ネ申の考え方なんだから誰でも理解できるわけではないよ。
そこんとこ早く気づかなきゃ。
55:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/29 23:38:28
コマンドパターンの多用は ＧＯＴＯ文スパゲッティに戻ってしまうことを指摘して置こう。
command.exec() の中を見るとまた command.exec() が書いてある。
なんだかわからん。
56:仕様書無しさん
07/03/29 23:38:35
自然言語処理やってる俺の別人格の中の人が、
品詞句に着目したオブジェクト抽出法と似たような話で
> とりあえず、ルネ・トムの「ことばのカタストロフィー」は、
> 言語モデル面では「格フレーム」もしくは「概念依存 (Conceptual Dependency)」に相当するアイデア
> を提供していると理解しました。
> もっとも、時空間プロセスのカタストロフィー理論的性質が、人間の時空間認識に大きな影響を与え、
> 最終的に「動詞と、動詞に付属する名詞の型」を類型化する、という説は飛躍があるような気がしました。
> 複雑系の話は興味深いのだけど、本当に言語理論と関係あるのかなぁ？
ってゆってた。
あと、格フレーム辞書見ると、動詞を中心にしてそこに(文法的に)付いてくる品詞/単語が分類されてて、
あれもソフトウェア・パターンに流用できねぇのかなぁ？って、ゆってた。別人格の中の人が。
57:仕様書無しさん
07/03/29 23:40:27
>>55
そうそう。まるでアセンブラ時代に戻ったような感じ。
58:56
07/03/29 23:43:33
Object⊃概念
概念⊃動詞、副詞
概念⊃名詞、形容詞
なんてやってったら、前者は手続き型、後者はデータ指向に近づくだけでしょ。
OOは、両方見てく主義。
だから、例えば「動詞と単語の結合パターン」なんかをネタにして展開してった方が
まだマシじゃねぇの、と言いたかった。
59:仕様書無しさん
07/03/29 23:54:03
あぁーウッゼェ
「Commandパターン・スパゲッティ」
それはクロージャ導入で解決する
60:仕様書無しさん
07/03/30 00:02:03
>>59
次に来るのは、
「クロージャ・スパゲッティ」
だけどなｗ
61:仕様書無しさん
07/03/30 00:09:06
なぜオブジェクト指向で作るの？ってところから始めないとね。
62:仕様書無しさん
07/03/30 00:09:40
人間買ってでもするのがクロージャってうちの母ちゃんがゆってた。
63:仕様書無しさん
07/03/30 00:13:27
かあちゃん、おれ外で違う女買ってもうた。
64:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 00:16:51
ＯＯちゅは９９％マルチスレッドプログラミング理解して無いからな。
65:仕様書無しさん
07/03/30 00:24:07
釣られるかよ
66:仕様書無しさん
07/03/30 00:27:42
この板はスレッドセーフではありません。
書き込む際は注意してくださ&ﾕｸ|1ﾒ・ﾇ$ﾙ・ｳ &l・
67:仕様書無しさん
07/03/30 00:43:54
>>66
ｽﾏｿ、書き込み被った
68:仕様書無しさん
07/03/30 00:45:33
釣り針が全部あぼ～ん表示されるので、
安全といえば安全。退屈といえば退屈。
話が通じる面白い奴こねぇかな
69:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 00:48:50
単なるスレッドセーフとマルチスレッドプログラミングはまるで違うもの。
入門者向けに「スレッドセーフ」を説明してる本があるけど、本格運用のでそんなの使ったら死ぬ。
70:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 00:50:22
オブジェクトを禁止ワードにしてるのか
えらいぞ
71:仕様書無しさん
07/03/30 01:00:51
バカが独りで暴れてる
72:仕様書無しさん
07/03/30 12:43:57
なんでこんな糞スレがもの凄い勢いで消費してるのか分からん。
オブジェクト指向やらなんだか知らないが、そういう物好きな人が増えたのか？
73:仕様書無しさん
07/03/30 12:48:32
>>72
オブジェクト指向の話をしているように見えるのか？
74:仕様書無しさん
07/03/30 13:17:39
オブジェクト指向を隠れ蓑にした世代間対立スレだろこれ？
技術者なんだから専門分野ができればそれでいいと思うんだけど。
75:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 19:04:18
専門分野に入れなかった人が落ちるところがＯＯ
76:仕様書無しさん
07/03/30 19:13:26
じゃCOBOLずーっとやってる人は元々こぼれですな
77:仕様書無しさん
07/03/30 19:14:16
宇宙開発からOOにわざわざ移った人は吹きこぼれか
78:仕様書無しさん
07/03/30 19:20:40
ココ電柱は専門分野から落ちこぼれてOOでも落ちこぼれか
くよくよすんな
79:仕様書無しさん
07/03/30 19:41:19
コボラーはSAPに行けばいいんだ。
COBOLに似た言語でOOも可能だぜ。
80:仕様書無しさん
07/03/30 20:09:36
いや、そこは突っ込む所じゃなくて
元々コボラ（ry
81:仕様書無しさん
07/03/30 20:20:26
意外と、ココ電ファン多いんだな、
たかひろファンと違い、ココ電ファンはまったりしてるな。
俺、思うに、ココ電の生息地って関西方面じゃね？ ね>>ココ電
82:仕様書無しさん
07/03/30 20:22:29
関西って仕事あるの？
83:仕様書無しさん
07/03/30 20:27:31
ITの仕事ならいくらでもあるぜ。
もちろんCOBOLの新規案件も
コボラー足りないらしい。
84:仕様書無しさん
07/03/30 20:57:01
age厨うぜぇ
85:仕様書無しさん
07/03/30 20:59:01
ひろたかくんのストーカじみた求愛行動で
どっかのバカの貞操が危険状態ですｗ
86:仕様書無しさん
07/03/30 21:33:28
URLﾘﾝｸ(www.youtube.com)
全然関係ないけど、東京都も大変だな
87:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 21:56:48
浅草在住
88:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 21:57:43
昨日は自動書記で書いたソースがバグってた。
今日上司の人にみつかってしまった。
89:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 21:58:55
コボラーは年収１０００万ですよ。
そこらの貧しいＯＯ厨が何を勘違いしてるんだか・・
90:仕様書無しさん
07/03/30 22:16:34
87 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん
88 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん
89 名前：あぼ～ん[あぼ～ん] 投稿日：あぼ～ん
91:仕様書無しさん
07/03/30 23:18:34
>>87
なにー、浅草の浅草寺境内か、いいな、川で花見や花火楽しめて、休みは花やしきか
ま、浅草ならCOBOL大好き、OO嫌い解るな
>>86 ワロタよ ココ電一票入れてやれ
92:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/30 23:25:42
花やしきは今有料ですよ。入場料
93:仕様書無しさん
07/03/31 00:39:18
花やしき子供の頃よく行った。入場料無料の頃。
そして大人たちは場外馬券場へ…
94:仕様書無しさん
07/03/31 07:22:04
閑話休題
そろそろ本題のオブジェクト指向について
95:仕様書無しさん
07/03/31 08:15:36
真面目な話なんだが、
UMLを理解＋利用せずにオブジェクト指向分析・設計やろうとしてるから
失敗プロジェクトが多発してんじゃまいか？
ただ、UMLを「技術者だけ」が理解しても客がわかんねーなら説明につかえねーしな
UMLを利用しないからプロジェクトは失敗するし、
客にUMLで説明できないからプロジェクトは失敗するし
・・・駄目じゃん
96:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/31 08:54:17
ＵＭＬはシステムの設計に必要なのではなくて
オブジェクト指向に必要なんだろ。
自己完結哲学にすぎない。
仕事ふやすなよ。
97:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/31 08:58:02
ああ、そうだ
ＯＯのシーケンス図は通信やハード設計からのパクリだから。
知らないやつが要るだろうから教えておく。
98:仕様書無しさん
07/03/31 08:59:15
相変わらず頭バカだな
99:仕様書無しさん
07/03/31 09:10:08
荒らしはスルーしましょう
100:仕様書無しさん
07/03/31 09:14:26
>>95
UML使わずにOOも何も無い
客側の担当者には前段で教えるしかない
それがSEの仕事
101:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/31 09:17:25
そうか ショックだったか。
広い分野を知ってればＯＯなんか朴理だらけで、オリジナルがぜんぜんなくて
呼び名を変えただけなのも多く、根拠の無い効能書きしか残らないことが判るんだが、
まずこれを初心者に伝えて無かったな。
初心者に引っかかるやつが多いのはそういうわけだ。
どうやって伝えるかな。
102:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/31 09:18:55
プロの技術者と初心者では ＯＯの説明読んでも受け取り方がぜんぜん違うんだよ。
103:仕様書無しさん
07/03/31 09:19:58
外資系と一緒に仕事したとき言葉は分かんないけど
UMLが理解できたときはちょっと感動した
104:仕様書無しさん
07/03/31 09:26:46
♀
♂
105:仕様書無しさん
07/03/31 09:44:51
たかくんはおまんこがだいすき
106:仕様書無しさん
07/03/31 10:46:34
さて、花見に行ってくるか
咲いてるかな～
107:仕様書無しさん
07/03/31 13:09:16
伊賀知己がここにこなくなってよかったね。平和が一番。
108:仕様書無しさん
07/03/31 15:01:08
俺だったら、オブジェクトをやる前に、
いまや使うだけと化した原点に帰って、
ＴＰモニタのソースでも読むぜ
109:仕様書無しさん
07/03/31 15:18:16
ＴＰモニタのソース読むと何かいいことあんの？
110:仕様書無しさん
07/03/31 17:02:32
まともなTPモニタのソースってオプソで出てたっけ？
TPモニタ呼出API、TPモニタ・サービスAPI 位しか見た覚えないけど。
111:仕様書無しさん
07/03/31 17:11:35
国内だとHくらいか
分散TPモニタのソースが
最新状態にメンテされてるのは
112:仕様書無しさん
07/03/31 17:54:49
>>102
STLとかBoostは糞でFA？？
113:仕様書無しさん
07/03/31 17:59:13
まるでココ電柱を口答試験してるみたいだなｗ
114:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/03/31 22:25:15
ＳＴＬは前スレでおれが言及したでそ
あほ
115:仕様書無しさん
07/03/31 23:28:53
はー？
116:仕様書無しさん
07/03/31 23:51:52
荒らしはスルー
117:仕様書無しさん
07/04/01 01:42:20
NG推奨ワード：tIS/.aX84.
118:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/02 01:06:59
まんどくさいからＶｅｃｔｏｒ使っちゃえーつってつかわね？
無いと大変なんだけど
119:仕様書無しさん
07/04/02 01:08:57
お前は何を言ってるんだ
120:仕様書無しさん
07/04/02 02:07:24
最近はもっぱらArrayListの方だな、使うのは。
121:仕様書無しさん
07/04/02 04:14:34
>119
誰も何も言ってないと思うが…
122:おじゃばさま
07/04/02 09:22:41
UMLってのは詳細設計や機能設計をするために、脳内で行っていたものを図にすることによって、
整理しようという目的の物だから、オブジェクト指向とは関係ない。
単にUMLの中にもオブジェクト指向に向く物があるというだけだ。
STLは熟練者の組んだCソースよりは遅いが、普通の人が自作するよりは早いし、汎用性がある。
STL無しでもOOで組めるが、STLを使った方が簡単に出来る。
ただし、コンストラクタの癖を理解し、リソース解放漏れに注意する必要がある。
123:仕様書無しさん
07/04/02 09:48:07
>>122 熟練者が自作する場合と比べて、STLの遅い所ってどんな所ですか？
124:仕様書無しさん
07/04/02 12:08:24
何このスレ
125:仕様書無しさん
07/04/02 13:01:16
現状は、低能が程度の低い釣りをして他の低能を釣るスレ
126:仕様書無しさん
07/04/02 17:41:06
>>122
おじゃば殿はSTLを語ってるが、C++も使うのか？
STLにあるものをわざわざ自作する人って、おじゃばだろ
おじゃばは必死に頑張ったが、結局、STLより早くかつ汎用性のあるものは出来なかったということだな。
127:仕様書無しさん
07/04/02 23:07:02
インスタントというぐらいだから、オブジェクト指向はうまい、はやい、やすいのか？
128:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/02 23:15:58
本に出てる概念を拾ってきて作るやつはアホ
俺なんかアセンブラ時代にＭＡＰ自分で考えたもんね
129:仕様書無しさん
07/04/02 23:44:47
荒らしやおじゃばの自己陶酔のせいでスレ内容のレベルが落ちたな
>>122おじゃば
当たり前のことを書き連ねて何がしたいの？
130:仕様書無しさん
07/04/03 11:25:40
荒し本人がよくいうよ。
まともな議論など、前スレ中ほどから絶えて久しいのに。
131:仕様書無しさん
07/04/03 11:46:18
>>130
>荒し本人がよくいうよ。
どういう電波を受信すると、こんな断定が出来るんだろう。
132:仕様書無しさん
07/04/03 11:58:05
毒電波発するのやめれ
133:仕様書無しさん
07/04/03 12:31:58
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) 奥様聞きました？荒しさんのたら今度は「毒デムパ」ですって
134:仕様書無しさん
07/04/03 12:45:16
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) あら奥さんご存知なかった？たかくんの来るスレはいつもこうなのよ
135:仕様書無しさん
07/04/03 13:00:34
NGワード推奨：おじゃばさま
136:仕様書無しさん
07/04/03 15:38:58
ここは、おじゃばさまに釣られるのをぐっとガマンするスレになりました。
137:仕様書無しさん
07/04/03 16:32:41
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) おくさん、見ました？たかくんたら関数言語スレでも拒否られてましてよ
138:おじゃばさま
07/04/03 17:40:50
>123
処理に特化した検索処理などだ。
例えば最終レコードへの検索ヒット率が高い処理などで、最後から検索するようなロジックにするなどだ。
>126
すでにある物は作らない。それがJavaクオリティー。
攻撃者のうちの一人は、俺を排除するためにわざと会話にならない書き込みをしていたそうだ。
無意味だしもう新学期なので、無意味な書き込みはやめると言う事で決着した。
ただもう一人いるみたいだな。偽コンサルっぽいのがもう一人らしい。たかくんか？
139:仕様書無しさん
07/04/03 17:43:30
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) あらヤダ！たかひろくんたら「おじゃばさま」名義でさんざん荒してたのをもう忘れちゃったみたい
140:仕様書無しさん
07/04/03 17:53:23
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) アラ、たまに居るわよ。多重人格っていうのかしら？ 被害妄想っていうのかしら？
141:仕様書無しさん
07/04/03 18:02:20
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) 居る居るぅー。他人に散々迷惑かけて、謝りもせず相手を悪者扱いしちゃう子。ダメよねぇそんな子って
142:仕様書無しさん
07/04/03 18:03:50
>>138
>例えば最終レコードへの検索ヒット率が高い処理などで、最後から検索するようなロジックにするなどだ。
よりにもよって、こんな例を出してくるとは莫迦極まれり。
reverse_iterator も知らずに STL を語ってたのか。
143:仕様書無しさん
07/04/03 18:06:07
( ´д)ヒソヒソ(´д｀)ヒソヒソ(д｀ ) ねぇねぇ、この子けぇじばんのタイトルも読めないのかしら。おばかさんね(ｷｬｯｷｬ
144:仕様書無しさん
07/04/03 18:31:00
ﾃﾗﾜﾛｽ
おじゃばフィルターに下記の文章を流し込むと、
>>138が出てくるのか。
これじゃ話が通じないわけだ
558 名前： 仕様書無しさん 投稿日： 2007/04/02(月) 10:08:55
おはよう。私は偽コンサルではない方だ。
私は会話が通じない人間ではない。
キミは、私が設計の説明をしている最中に
私の説明の主旨を無視して、
論点のずれた話題を延々と振って議論妨害してきた。
だから、私はキミの主旨を完全に無視して、
キミを排除する事に力を注いだ。
たったそれだけの話だ。
追伸
常連おさんから、キミの言動の傾向について話を聞いた。
結論として、キミはあまり良い評価を得ていない。
新年度に入った事だし、つまらぬ言い争いは止めないか？
145:仕様書無しさん
07/04/03 18:51:28
【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★3
ｽﾚﾘﾝｸ(prog板) (dat落ち)
770 名前： 仕様書無しさん [sage] 投稿日： 2007/03/09(金) 02:02:26
コードをコントロールする側・される側にキッチリ分解する。
で、コントロールされる側のコードを追加しようが変更しようが
コントロールする側のコードは二度と触らない。
これがバグをいれこまずに機能追加するための大原則で、ここが
わかってなきゃなんでデザインパターンがやくにたつのかわかりっこない。
146:仕様書無しさん
07/04/03 18:53:46
【OOP/D】ｵﾌﾞｼﾞｪｸﾄ指向を何故理解できないの？★5
ｽﾚﾘﾝｸ(prog板)
369 名前： 仕様書無しさん [sage] 投稿日： 2007/03/26(月) 15:32:13
・ゲーム盤 と 審判＆ルール
・審判 と ルール
・プレイヤ と 戦術
の分離理由
■マイクロカーネル・パターン あるいは
■「方針と実現の分離」原則
プログラム中に散在する「方針」と「実現」を分離する事で、
プログラムの複雑性を減らし、保守性や拡張性を高める方法。
147:仕様書無しさん
07/04/03 18:56:31
>>145の書き込み 2007/03/09(金) 02:02:26
>>146の書き込み 2007/03/26(月) 15:32:13
わずか16日間の間に、このスレにどのような劣化が発生したのか？
誰か説明よろ
148:仕様書無しさん
07/04/03 19:04:36
・アホコテ2匹＋αが荒らしまくった
・>1がアホだった
いじょ
149:仕様書無しさん
07/04/03 19:06:38
>>148
それは違う。
おじゃばが荒しをしたのが一つの原因だ。
150:仕様書無しさん
07/04/03 19:10:08
荒しをしたアホコテ2匹＝おじゃば、ココ
という意味だろ。
151:149
07/04/03 19:11:18
了解した
152:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/03 19:23:45
俺がいつ荒らしたよ
議論に負たＯＯちゅが「荒らしだ荒らしだ」って騒いでるだけだろ
153:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/03 19:26:24
基幹コテがいなくなると寂れちゃうし
154:仕様書無しさん
07/04/03 19:27:18
よーしわかったわかった
要するに >>145の中の文を書いたヒトは、
自分が(分散処理開発で)苦心惨憺して身に付けたノウハウ(>>145)が
実は分散処理の元祖で発明された概念(>>146)だと知って、
荒れ狂ってたわけね。
155:仕様書無しさん
07/04/03 19:30:53
おじゃばは Apple Darwin はムリとしても(w
せめて Linux Kernelソースくらいは目を通しておいた方がいい。
そんなの基礎教養だと思ってた。
156:仕様書無しさん
07/04/03 19:36:58
>>154
荒れ狂ってたのはおじゃばだろ。
あと、「分散処理の元祖が発明した」というよりは、
「それ以前からあったノウハウが、
分散処理の元祖の開発時に基本設計として採用された」
が正解。
物事は慎重に正確に書け
157:おじゃばさま
07/04/03 20:04:05
このスレの問題点はいくつかある。
まず、
「初心者に簡単に説明しようとする人」と「オブジェクト指向を深く理解しようとする人」の
2種類がいると言う事だ。
次に、
オブジェクト分割の際に、「機能や処理で分割しようとする人」がいると言う事だ。
オブジェクト指向ではオブジェクト（日本語だと難解だが物としておこう）で分割しなければならないが、
目に見えない物は機能との区別が非常に曖昧だ。そのため分割を間違える。
そのため、最初に誰かが簡単に説明すると、どんどん難しくなっていって、初心者はついていけなくなる。
そのうちOOと直接関係ないアーキテクチャパターンや、OO部品でしかないデザインパターンなどが飛び出し、
オブジェクトも機能も分からなくなって終了。
となっている。
158:仕様書無しさん
07/04/03 20:06:18
もう休んでイイよチミ
159:仕様書無しさん
07/04/03 20:09:19
一番の問題児が何言ってんだよ。アホか。
160:おじゃばさま
07/04/03 20:12:49
ちなみに146の言う方針と実現の分離は、分離の意味を誤解しているのではないかと思う。
クラスレベルの分離とシステムレベルの分離は違うのに、クラスレベルの分離に適用しているのではないか？
つまりABCと3つのクラスがあるとする。機能が1つ追加になった場合には、その機能でDクラスを
作ろうとするが、本当はその機能がAとBで使われているとしたら、Aを拡張したA'とBを拡張したB'を
作るべきだ。システムレベルで言えばこれも分離だが、これの区別がない人がいるのではないだろうか？
161:仕様書無しさん
07/04/03 20:14:52
おおぶじじゃぇくばとさしこまう
162:仕様書無しさん
07/04/03 20:16:11
つーかご高説垂れてるつもりで冗長なだけで中身がない文章しかかけないアホコテと
論破してるつもりで頭がおかしいとしか思えない勝利宣言繰り返すアホコテが
荒らしてる自覚がない事が最重要問題だと思う
163:仕様書無しさん
07/04/03 20:17:18
ちなみに機能と実装を分離する考え方のパターンがBridgeパターンだ。
164:おじゃばさま
07/04/03 20:21:16
第一、アーキテクチャパターンが悪い。
アーキテクチャパターンと言うのは、ただのアプリケーションの分類である。
適当なアプリケーションを解析して、これは○○パターンだねと分類しているだけである。
パターンになければ新しいパターンとして追加する。
作業的には終わりがないので、暇な学者が好んで研究する。
これは学問だ。
学問というのは、うまく利用出来ればそれなりの効果があるが、大抵はそのまま使えない。
だから初心者にアーキテクチャパターンやデザインパターンなどは勧めない。
165:仕様書無しさん
07/04/03 20:24:48
>>160
>>163
なんだ。デザパタスレで散々人の発言を妨害しまくっておいて
今更そんな事を言い出したのか。
つくづく腐った魂を持つ男だな、鈴木高弘。
166:仕様書無しさん
07/04/03 20:28:07
パターンなどと言わず方式とか様式とか法とかでいいじゃん。
しょせんやりかたなんだし。用語に当てはめて思考停止するパターンがｗ多いぞ。
167:仕様書無しさん
07/04/03 20:28:57
主張を唱えるだけでその根拠を述べないから、おじゃばさま
の意見には全く説得力がない。叩かれて当たり前。か、釣り。
168:おじゃばさま
07/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:仕様書無しさん
07/04/03 20:33:41
Beidgeパターンは捨てて、全てTemplate Methodパターンにしろと？
170:仕様書無しさん
07/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:仕様書無しさん
07/04/03 20:36:17
Bridgeパターン： 実装継承と機能継承の分離。
あるクラスをベースに、実装拡張と機能拡張を行う時に、
実装の詳細をインタフェースでカプセル化し、
機能側はこのインタフェース経由で機能記述、機能拡張を行う。
マイクロカーネルパターン：方針と実装の分離。
「方針」と「機能」は違う。
オセロ問題では、継承絡みの問題抜きで
ルールや戦略を分ける理由付けとして
ネットワーク分野でよく知られる
「方針と実装の分離」を引用した。
172:仕様書無しさん
07/04/03 20:50:09
都合が悪くなるとトンズラするおじゃばさま。そこがかわいい。
173:仕様書無しさん
07/04/03 20:52:57
今夜も精が出ますねぇ。
精が溜まり過ぎなんじゃないですか？
174:仕様書無しさん
07/04/03 20:57:21
>>169
デザパタスレの議論妨害厨乙。
なんでお前は元のパターンに戻ってっちゃうの？
今日はBridgeパターンを再勉強して、その成果を発表してたんじゃないの？
175:仕様書無しさん
07/04/03 21:02:49
Bridgeパターンをより判りやすく多少の皮肉の入った例で説明すると
「社会性」、これがブリッジに相当する。
実装側は、個々人それぞれに事情があるにせよ、
仕事では「社会性」を持って行動する。
(お子ちゃまは「社会性」が足りないので、
それぞれ個別の実装方法で一定の「社会性」を持つよう訓練される。)
機能側は、個々人の持つ「社会性」を前提に
各種の仕事を割り振る。それらの仕事にはバリエーションがある。
厳しい仕事では、個々人の社会性に欠陥があったら排除する。
これがBridgeパターン。
なお実際の仕事では、個々人の特性、社会性に適した仕事を割り当てる
のが望ましい。
加えて、一部の非常に親切な人は、個々人の社会性の実装上の欠陥
(例えば幼少時のうんたらかたらで性格がどうした)みたいなのを考慮して
実装を直す教育を仕事現場でやってくれる事もある。
頑張れ
176:仕様書無しさん
07/04/03 21:05:52
個人と仕事を結ぶブリッジが「社会性」
177:仕様書無しさん
07/04/03 21:13:13
おじゃば と 社会 を結ぶブリッジが「２ちゃん」
だがおじゃばはここは社会ではない事に気付いていない。
178:おじゃばさま
07/04/03 21:22:07
>170
実際にはそうなるかもしれない。
機能で新しく独立したクラスを作るべきでないと言いたかった。
>171
非常に不本意だが、マイクロカーネル・アーキテクチャパターンの検証をしてみるか。
俺も171も納得してないからな。初心者は無視してくれ。
----------------------------------------------------------------------------------
Microkernelアーキテクチャパターンは、
変更されるシステム要件への適合が求められるソフトウェアシステムに用いられ、
システムの核となる最小限の機能を、拡張機能や顧客依存部分から分離する。
また、さまざまな拡張機能を組み込んだり、その拡張機能が協調して動作できるような
調停機能を提供したりする、一種のソケットとしての役割も果たす。
----------------------------------------------------------------------------------
やはり俺的には「システム」の「機能分離」の話で、OOのクラス分けには関係ない気がする。
特に「ソフトウェアシステムに用いられ」、「拡張機能や顧客依存部分から分離」と言う所だ。
ここの「機能」の範囲がたまたまオブジェクトと一致する場合があるかもしれないが、
個々で言う「機能＝オブジェクト」ではないと思う。
179:仕様書無しさん
07/04/03 21:23:47
178 名前： あぼ～ん [あぼ～ん] 投稿日： あぼ～ん
あぼ～ん
180:仕様書無しさん
07/04/03 21:26:06
179 名前： あぼ～ん [あぼ～ん] 投稿日： あぼ～ん
あぼ～ん
181:仕様書無しさん
07/04/03 21:31:27
また一歩、退化への道を歩むおじゃば。
「アーキテクチャ・パターンはシステムレベルの話だから違～う」
「アーキテクチャ・パターンに載ってる記述以外は信用できな～い」
平鍋のハンドブックがバカなんだよな、
あんな的外れなイントロ文とシステムブロック図しか載せないから。
182:仕様書無しさん
07/04/03 21:33:10
賛否両論あるけど、デファクトの地位にあるMVCパターン。
これなんかも確かに「アーキテクチャ・パターン」に載ってるけど、
明らかにフレームワークのクラス設計レベルの話なんだよな。
183:おじゃばさま
07/04/03 21:41:31
------------------------------------------------------------------------
Bridgeパターン： 実装継承と機能継承の分離。
あるクラスをベースに、実装拡張と機能拡張を行う時に、
実装の詳細をインタフェースでカプセル化し、
機能側はこのインタフェース経由で機能記述、機能拡張を行う。
------------------------------------------------------------------------
JDBCやサーブレットのこと。
JDBCの場合は、ORACLEやPostgresに変更出来るようになっている。
サーブレットの場合は、TOMCATやWebLogicに変更出来るようになっている。
ただそれだけ。
社会性？
使えない実装を排除するためにインタフェースがあるなんて聞いたことないな。
184:仕様書無しさん
07/04/03 21:41:58
みんなばらばらのこと話して分散の研究か？
もうこれ以上話し合っても無駄だと気づけ
2chにオブジェクト指向は相応しくない！
185:仕様書無しさん
07/04/03 21:42:06
>>181
186:仕様書無しさん
07/04/03 21:44:35
おじゃばは学習能力の低い子だから相手すんな
187:仕様書無しさん
07/04/03 21:44:59
おじゃばさま、意見する時は根拠書けよ。
「～気がする」とか「かもしれない」って。女子高生かよ。
188:仕様書無しさん
07/04/03 21:45:51
おじゃばさま＝鈴木高弘＝大規模開発で基本設計ミスによりマルチスレッド絡みのデスマーチを起こした人物
189:仕様書無しさん
07/04/03 21:47:04
>187
そんな可愛くねぇよ
口だけの禿親父
190:仕様書無しさん
07/04/03 21:48:45
伊賀者参上！だなｗ
191:仕様書無しさん
07/04/03 21:55:07
おいおい、おじゃばさま、「JDBCやサーブレット」はBridgeパターンじゃないだろ。
192:おじゃばさま
07/04/03 22:01:43
アーキテクチャパターンと言うのは、たくさんのソフトウェアを解析して分類し、
その中から特徴や法則を見いだそうという学問だ。
だからアーキテクチャパターンの本を買って来て、その中のいくつかを暗記した所で意味はない。
コンサルが営業相手にプレゼンするには、アーキテクチャパターンで押せるが、
最近はプレゼンに第一線の技術者が出てくる場合があるから、痛い目にあるぞ。
193:仕様書無しさん
07/04/03 22:02:46
今日はここ最近になく大漁だな。よかったな、おじゃば。
194:仕様書無しさん
07/04/03 22:06:13
痛い目(･∀･)にある
195:仕様書無しさん
07/04/03 22:11:52
> 「方針」と「機能」は違う。
より詳しく説明すると、
「方針と実現の分離」では、まずは「方針」ありきで、次に「実現」側がそれを実現する。
主従関係がある。
「機能継承と実装継承の分離」は、まず「実装」ありきで、次にそれを利用して「機能」が記述される。
196:仕様書無しさん
07/04/03 22:18:41
俺が思うに、おじゃばってのは鈴木が、
その愚かな側面をオープンにしたものなのだと思う。
普段だったら口にできない初歩質問、判らない事、間違った考え方、
それらを見ず知らずの他人に晒して、フィードバックを得て、
そこから何かを学習しようとする・・・不毛な努力。
それでは、そんな不毛な努力に、何故付き合う人間が出てくるのか？
それは単に、彼が粘着し、罵倒し、荒しをし、その他醜悪な行為をして
数多くの心ある人々に「排除すべき対象」としてマークされ、
徹底的に叩かれる、その過程が、彼にとっての学習なんだ。
匿名掲示板上ですら素直に疑問や質問をできないとは、あわれな存在だ
197:仕様書無しさん
07/04/03 22:33:05
なるほどねぇ、そういうことか。しかし自分の勉強のために
嘘を吹聴するのはいかがなものかねぇ。
しかも、偉そうに、「だ・である」口調だぜ。あいつ。
198:仕様書無しさん
07/04/03 22:35:28
さすが伊賀者。分身の術も会得している。
199:仕様書無しさん
07/04/03 22:37:30
高弘> だからアーキテクチャパターンの本を買って来て、その中のいくつかを暗記した所で意味はない。
お前の普段の行動パターンがそうである事を、良く理解したｗ
あの本は単なるパターン集ではなく、
ソフトウェア・アーキテクチャに関する専門書だ。
パターン集部分には、真面目にアーキテクチャと取り組んできた人間なら
誰でも必ず触れた事のあるアーキテクチャ設計が含まれている。
更にvol2 (洋書)には、vol1(和書)で扱いのなかった、
Webアプリケーションのためのアーキテクチャ設計が多数含まれている。
こちらも、その分野を真剣にやっていた人間なら見覚えのあるパターンが多い。
200:197
07/04/03 22:38:06
は？ 俺は>>196じゃないよ。
おじゃばのあの口調こそ自演をカモフラージュするためのものかもな。
201:仕様書無しさん
07/04/03 22:39:12
「俺と高弘の間をジャマするな」が主張だからねー
誤解の無いように。
202:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/03 22:46:43
どっかからソースをコピペしてきてちょちょいと書き換えて使うのを何パターンつうの？
代表的なプログラミング技術なのに どの本見ても載ってないの
203:仕様書無しさん
07/04/03 22:49:22
>>202 ココ電球パターン。最近2chで知られるようになった。
204:仕様書無しさん
07/04/03 22:55:30
ココ電とおじゃば以外は、全部伊賀の人です。
205:仕様書無しさん
07/04/03 23:00:05
age進行？いいねぇ
206:仕様書無しさん
07/04/03 23:07:09
,.――-､
ヽ /￣￣￣｀ヽ、
| | （・）｡（･）|
| |＠＿,.--､_,> 甲賀者には負けられないでござる
ヽヽ＿＿＿ノ の巻
207:仕様書無しさん
07/04/03 23:10:41
そろそろ法則追加だな
208:仕様書無しさん
07/04/03 23:43:32
ファイルを読んでDBに書き込む
この場合クラスにするのはどれですか？
教えてエロい人
209:仕様書無しさん
07/04/03 23:53:19
ファイルを読んでDBに書き込むクラス
210:仕様書無しさん
07/04/03 23:53:51
おじゃばの中身のカスに詫び入れさせてきたｗ
奴はデスマ関係者にも詫び入れるべきだと思うけど
211:仕様書無しさん
07/04/03 23:56:51
>>209
真面目に答えれ。
212:仕様書無しさん
07/04/04 00:38:10
デスマ先生スレ
213:仕様書無しさん
07/04/04 00:48:37
たかひろ、たかひろ
うるさい奴等ウザイ
氏ね
214:仕様書無しさん
07/04/04 00:54:25
デスマ先生ご乱心？
215:仕様書無しさん
07/04/04 01:14:51
>>214
いちいち、くだらない事書き込むな
氏ね
216:仕様書無しさん
07/04/04 01:23:49
法則発動しまくりんぐ
もしかしてこれﾌｧﾋﾞｮｰﾝ ？
217:仕様書無しさん
07/04/04 01:41:42
御本人様火病り中ですか・・・
218:仕様書無しさん
07/04/04 02:10:37
デスマ先生がまだ頑張ってるぞ
おまいら応援行ってこい
ｽﾚﾘﾝｸ(tech板)l50
219:仕様書無しさん
07/04/04 02:24:08
#define private public
#define protected public
220:仕様書無しさん
07/04/04 02:27:30
>>178
俺が言っていたのは「方針と実現の分離」だ。
ビジネスロジックを疎結合に構成する方法として、
マイクロカーネルパターンの特徴「方針と実現の分離」を採用すれば良い
という文脈で、それを出したのだ。
おまえはいい年をして初心者騙して
醜態晒すんじゃねぇ。
221:仕様書無しさん
07/04/04 02:28:23
成り済ましって、だいたいこんな感じでおｋ？
222:仕様書無しさん
07/04/04 07:46:47
いつまでたっても、負けると将棋板ひっくり返すジジィだな高弘
223:仕様書無しさん
07/04/04 11:51:11
>>184
>みんなばらばらのこと話して分散の研究か？
ｗﾜﾛﾀ
224:おじゃばさま
07/04/04 19:58:49
>223
いや面白くない。
アーキテクチャパターンがオブジェクト指向と直接の関係がないと言う事が分かって、
たかひろが意図的に話題をずらしているだけだ。
225:仕様書無しさん
07/04/04 20:15:07
>>224＝おじゃばさま＝高弘
自問自答乙
226:おじゃばさま
07/04/04 20:42:30
>225
何だ俺を「たかひろ」や「伊賀知己」にして、自分はいなかった事にしたいのか？
俺は俺以外に人がいるのは分かるし、俺は他人に自作と思われようと全く気にしないから無意味だぞ。
で、もういいのか？
アーキテクチャパターンとOOは直接は関係ないと言うのは分かったか？
227:仕様書無しさん
07/04/04 20:43:45
ヒント：おじゃば知性90%ダウン
228:仕様書無しさん
07/04/04 20:44:49
ヒント：この子はおじゃばの役回りを理解できていない
229:ﾜﾛﾀ
07/04/04 20:47:40
ﾜﾛﾀ
230:仕様書無しさん
07/04/04 21:14:15
>>227 やあ、伊賀知己
相変わらず、すばやい粘着レスだな感心するよ
231:仕様書無しさん
07/04/04 22:54:07
マジメな質問で恐縮なんだけど、大体、main関数自体がOSの提供する
スレッドん中で動いてんのに、OSやライブラリの提供するスレッド機
能使わないってどういうこと？ ユーザプロセスでレジスタとか、ス
タックとか切り替えられんの？ ま、知らんで聞いてるが。できても
えらい面倒くさそうだな。こんなん簡単にできたらマジ尊敬するよ。
232:仕様書無しさん
07/04/04 22:54:57
あ、まちがった。おさんスレの方だった。ま、いっか・・・
233:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/04 22:56:44
Ｊａｖａの場合はＪａｖａのグリーンスレッドのほうが安定してるから。
234:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/04 23:25:00
ああ、あと、スレッド自作するのは
各スレッドを１：１で平行動作させたい場合だな。
235:とおりすがり・おさん
07/04/04 23:32:12
>>231
マルチスレッド・プログラミングではまった人が居ると聞いたので、
内部機構を考えてもらうネタとして考えた。
まずは安全牌の解。
デバッガのステップ実行割り込みのメカニズム使えば、
任意のポイントとタイミングで、レジスタ退避/復帰と実行ポイント変更と
スタック切換ができる。(こっちは概要調べただけで書いた事はない)
今なら例えばcygwin のgdbソースでも追っかけりゃ判るはず。
欠点は、gdbには詳しくなれるけど、マルチスレッド勉強には重過ぎる点。
次はもっと簡単だけど、かなりいい加減な方法。
後で書く。
236:とおりすがり・おさん
07/04/04 23:42:48
後で書く、とかいうとまた腐れが騒ぎ出して鬱陶しいんで、
要点だけ書いとくと、
・ノンプリエンティブ・マルチスレッドにする。(都合のいい時にしか切り替えない)
・レジスタ変数は一切使わないオプションでコード吐かせて(要コード・チェック)
レジスタ退避の事は一切忘れる。
(直前の実行ポイントは必ず、タスク切換関数の呼び出しスタックに保存される)
・スタック切換は、アセンブラで複数のスタック切換を書いてもいいんだけど、
それ以外のやり方として、スタックは一本にして、それを分割して使うやり方がある。
スタックポインタの操作は、alloca()関数とreturn駆使すればCで記述できる。(要コード・チェック)
237:とおりすがり・おさん
07/04/04 23:47:22
一番重要なポイント書き忘れてた。
・自作スレッドで実行させる関数上では、外部ライブラリ/OS機能は一切使わない。
(動作検証が面倒になって、「原理を学ぶ」という主旨に反するから)
238:仕様書無しさん
07/04/04 23:48:12
ほぇ～、なんか難しそうだけど、要はできるっつうことね。
そういえば、デバッガでもレジスタ弄れるもんなぁ。
メリットがいまいち分からんが、こんなん書ける奴はよっぽど
のマゾだな。コリャ。
239:仕様書無しさん
07/04/04 23:48:28
要コードチェックって何のコード？
240:とおりすがり・おさん
07/04/04 23:53:15
>>239
アセンブラのコード見て、
・「レジスタ変数退避が不要」にちゃんとなってるか （コンパイラオプションが正しいか）
・「スタックポインタの操作」が意図どおりちゃんと書けてるか (プログラマ側の責任)
をチェックしる
241:とおりすがり・おさん
07/04/04 23:55:31
言い忘れ。
簡単なレジスタ退避なら、setjump()使えばできるでしょ。
なんか32bit化の時に入った、OS向けの特殊なフラグは取れないかもだけど。
242:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 00:58:44
アセンブラで書けばいいだろ。
器用なことするな
243:仕様書無しさん
07/04/05 06:33:37
OOはどこいった？
244:仕様書無しさん
07/04/05 07:26:57
「奴」は当分、２ちゃんを見る気がしねぇんじゃねぇのか？
245:とおりすがり・おさん
07/04/05 08:15:47
>>236補足
・スタック切換～ベースポインタ操作だけは、Cじゃなくアセンブラを使う必要がある。
246:おじゃばさま
07/04/05 09:51:00
とりあえず、Cスレッドの話はおさんスレに任せるとして、OOの話に戻るか。
247:仕様書無しさん
07/04/05 12:46:14
また詐欺師か
248:仕様書無しさん
07/04/05 14:09:28
>>226
お前が誰かなど (一部の粘着ｸﾝを除いて) 興味などない。
ただ、
莫 迦 は 黙 っ て ろ。
249:おじゃばさま
07/04/05 18:59:51
>248
じゃ結局何が言いたいんだ？煽りとかじゃなくて、マジわかんね。
これだけ説明しても変わらないって事は、自分の意見が正しいと思っているって事だよな？
で、馬鹿な俺から皆を守り、正しい道に導くために戦ってると言うなら、その行動も納得出来る。
で、アーキテクチャパターンとOOの関係について、まともな回答をもらってないのだが。
方針と機能は違うとか、例を示しただけだとか。
248の断片的な主張を強引につなぐと、
「アーキテクチャパターンにある設計で作ることが、オブジェクト指向である」
と言うように聞こえるのだが、そう言いたいのか？
250:248
07/04/05 19:06:06
>>249
新ｽﾚになって初めて書き込んだ俺に訊くことか？
いつも思うことなんだが、
「自分以外はすべて同一人物として扱う」って
一種の心の病だよなあ。
251:仕様書無しさん
07/04/05 19:15:47
日本語でおｋ
252:仕様書無しさん
07/04/05 19:17:23
また、コテ忘れてるよオイ。
253:おじゃばさま
07/04/05 19:52:18
>250
誰？新スレで最初に書き込んだ内容が248？うーむ、なんだかわからんな。
まあいいや、248は見なかったことにするから、249も忘れてくれ。250も忘れるから。
254:仕様書無しさん
07/04/05 19:55:15
コテつけたり外したり、おじゃばさまも忙しいな。
255:仕様書無しさん
07/04/05 19:57:05
２ちゃんの荒しには三種類居る。
Type1. 池沼。
スレの議論内容を一切理解できないにも関わらず
昼夜を問わず延々何ヶ月もスレに常駐し、スレとは無関係な話や
目的不明な自作自演、成りすまし、罵倒発言や落書きを繰り返す、
一種の精神異常者だ。
[対策]スルー、コテハン化、ID制導入
Type2. 撹乱者(天然系、愉快犯系、etc.)
スレの内容や議論の目的をある程度は理解した上で、
瑣末な間違いや疑問でいちいち揚げ足取りをとったり、
参加者が同意している筈の議論の大前提を否定する事で、
議論を空転させ参加者を疲弊させ、最終的に議論の目的達成を阻む。
天然系の無意識発言が原因となる事もあるが、
その多くは、議論好き人種の愉快犯系的犯行である。
[対策]議論の前提/目的/経過/マナー等の再確認
Type3. 利害関係に基づくコミュニティ破壊者(嫉妬系、確信犯系、etc)
これが一番性質が悪い。
コミュニティの情報交換と価値創造に嫉妬心を抱いたり、
自らのハッタリ商売が成立しなくなるのを異常なまでに恐れて、
参加者を撹乱し/疲弊させ/やる気を失くさせ、コミュニティ崩壊を画策する輩。
Type3犯は手段としてType2, Type1を行って潜在荒しを扇動するが
動機と目的の邪悪さ・悪質さによって他と判別される。
256:仕様書無しさん
07/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:仕様書無しさん
07/04/05 20:14:55
python関連スレで2月中旬～3月下旬に沸いたデザパタ荒し厨、
こいつはType2～Type3だ。
隔離前後の本スレでのやりとりや、
中断後のやりとり(>>274-275,>>484,>>488-545)を見れば、
必然性や合理性に欠いており、その真意の程が図りかねる。
Haskellスレで3/31～4/1に沸いた実用言語厨も
同様にType2～Type3だ。
258:仕様書無しさん
07/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:仕様書無しさん
07/04/05 20:49:06
皆スルーしてんだからいちいち触るな
260:仕様書無しさん
07/04/05 20:52:09
>258
わざわざあぼ～んされてる文章掘り返すなよ…にしても
> 基幹コテがいなくなると寂れちゃうし
寂れっつーか、落ち着いた議論であって欲しいのだがな。
261:仕様書無しさん
07/04/05 20:53:40
じゃあ皆様、そろそろオセロ作りに戻りましょうか
262:仕様書無しさん
07/04/05 21:00:28
おじゃば、ココとか伊賀（版画？）、どいつも
名無しに向かって同一人物扱いするところが異常だ。
２ちゃんの流儀は連続して話したいときのみコテなりレス番つけるんだから
勘ぐりで話を続けるのが異常。
複数レスの発言者の同一性なんてはなからないのに、
なんで脳内で作るかなぁ
263:仕様書無しさん
07/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:仕様書無しさん
07/04/05 21:12:43
そうすると自分の仮想敵のイメージを固定しやすいからでそ
265:仕様書無しさん
07/04/05 21:15:44
今日も平和だな～
266:ﾜﾛｽ
07/04/05 21:19:11
-憂鬱なプログラマによるオブジェクト指向日記 過去ログ-
ＤＱＮのなかにも、どうしようもないＤＱＮというものがいる。
満足に食事すら与えなかったり、虐待を繰り返したりと、
親としての素質に欠ける人が確実にいる。
「親資格」なんてものを作って、親になれる人間を選別すれば、
残酷な家庭内での事件も減るだろう。
しかし、それは危険な思想だし、別な意味で残酷な世界だ。
ＤＱＮに生まれても、途中でＤＱＮから脱出できるような教育を施せる社会が、
今のところは現実的で、そして効果のある方法だろう。
ＤＱＮから子どもを産む権利を剥奪すれば、ＤＱＮ再生産を防ぐことはできる。
267:仕様書無しさん
07/04/05 21:33:14
ひょっとしてアンテナ100本立ってる？
268:ﾜﾛｽ
07/04/05 21:35:05
ネタがワンパターン
しょーもねぇガキだな
269:仕様書無しさん
07/04/05 21:44:02
面白い？
270:仕様書無しさん
07/04/05 21:58:38
スレタイのｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの
からすると、未だに非ｵﾌﾞｼﾞｪｸﾄ指向開発が主流ってことかな
お舞ら、OODなんてやってないのか？
実はお舞らって、DQN指向開発まんせーじゃね
271:仕様書無しさん
07/04/05 22:06:04
面白い？
272:仕様書無しさん
07/04/05 22:10:46
今日は、伊賀知己はまだか
273:仕様書無しさん
07/04/05 22:17:02
ＶＢってさ、一部、オブジェクト思考でないの？
テキストボックスとか、ラベルとか。
274:仕様書無しさん
07/04/05 22:23:52
ありゃ、コンポーネント嗜好を追求してんじゃね
別名ポトッペッタ嗜好とも言う
275:仕様書無しさん
07/04/05 22:31:24
ＪＡＶＡとＶＢ系って、どっちが勝ちますかね？
１０年後・２０年後、どっちが残ってるでしょうか？
276:仕様書無しさん
07/04/05 22:41:34
２～５年後
JAVAがメジャーになりすぎて
VBの開発とかメンテとか移植ができるひとの希少価値が高まる。
１０年後。
別言語にJAVAの資産は受け継がれる。
VBのサポートは打ち切られるが、VBerの希少価値は高まり続ける。
２０年後
VBerは国宝級に崇拝される。
277:仕様書無しさん
07/04/05 22:45:13
補足
１０年後はC#が帝王として君臨
２０年後、しらね
278:仕様書無しさん
07/04/05 22:59:28
C丼はないだろ
279:仕様書無しさん
07/04/05 23:02:01
Ｃ丼
Ｃ＃
Ｃ♯
280:仕様書無しさん
07/04/05 23:12:15
イベントドンブリ
281:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 23:15:19
ＪａｖａはＭＳに捨てられてサーブレットと携帯アプリに特化して生き残ってるだけ
ＪＡＶＡアプリケーションの案件なんてあるの？
282:仕様書無しさん
07/04/05 23:25:23
>>281
現状しかみえてないお前は１０年後乞食になっている。
283:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/05 23:27:28
じゃあなんで５年前のＯＯ厨誰も生き残ってないんだよ？
284:仕様書無しさん
07/04/05 23:28:18
クラスのインスタントを生成するとだな、それがオブジェになるわけだ。
285:仕様書無しさん
07/04/05 23:45:34
さびれて温泉街のようなうらぶれっぷりだな。
286:仕様書無しさん
07/04/05 23:46:43
ＶＢ系(VB/VB.NET)のエキスパートになるべきか、
それとも、他の言語(java/c#)にも手を出すか？
皆さんは、どっち選ぶ？
287:仕様書無しさん
07/04/05 23:52:21
二者択一かよ
288:仕様書無しさん
07/04/05 23:55:33
VBでエキスパートってかｗ
289:仕様書無しさん
07/04/05 23:58:14
JavaとUMLが好きなやつって何であんなにキモいんだろう？
290:仕様書無しさん
07/04/06 00:09:44
ＩＴﾄﾞｶﾀって何であんなにキモイんだろう？
291:仕様書無しさん
07/04/06 00:11:50
JavaとUMLが好きなＩＴﾄﾞｶﾀって何であんなにキモいんだろう？
292:仕様書無しさん
07/04/06 00:14:20
ここに常駐してる人って理由抜きでｷﾓｲ。
293:仕様書無しさん
07/04/06 00:16:28
>>286
両方できて当然。各１日でマスターできなければこの先道はない。
294:仕様書無しさん
07/04/06 00:16:46
>>292
ここに常駐し、かつ、JavaとUMLが好きなＩＴﾄﾞｶﾀよりマシだろ
295:仕様書無しさん
07/04/06 00:17:23
ねえ、マスター作ってやってよ
296:仕様書無しさん
07/04/06 00:21:05
話題が貧困なちゃねらーほど存在価値の低いものはない。
297:仕様書無しさん
07/04/06 00:31:50
これって本当？
URLﾘﾝｸ(jibun.atmarkit.co.jp)
298:仕様書無しさん
07/04/06 00:35:31
話題が飛躍しすぎててつまんねーよ。
299:仕様書無しさん
07/04/06 00:36:45
コテハンさんもコテハン叩きさんも
そろそろ落ち着いて建設的な話しましょう。
300:仕様書無しさん
07/04/06 00:42:47
つ URLﾘﾝｸ(www.amazon.co.jp)
301:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 00:44:32
じゃあマジックナンバーとラベルの誤謬について
302:仕様書無しさん
07/04/06 00:47:49
むしろこっちに詳しく書いてある
つ URLﾘﾝｸ(www.amazon.co.jp)
303:仕様書無しさん
07/04/06 01:07:16
どうも底辺の人が来ちゃってるようだな
304:仕様書無しさん
07/04/06 01:10:23
おまいらループしすぎ
まずはユースケースの有効性について
305:仕様書無しさん
07/04/06 01:12:24
まずは嫁
つ URLﾘﾝｸ(www.amazon.co.jp)
306:仕様書無しさん
07/04/06 11:06:20
ＶＢ系しか知らない男は、
今後、どういう風にスキルアップしていくのが理想？
307:仕様書無しさん
07/04/06 11:15:51
伊賀知己のアホはオサンスレで引き受けるから
おまいらゆっくり楽しめな。たまにはジャワぽんのためになる事をしようと思う。
308:仕様書無しさん
07/04/06 11:59:23
>>304
アクターに目や口を書いて笑いをとる
309:仕様書無しさん
07/04/06 12:41:10
>>307
つ URLﾘﾝｸ(www.amazon.co.jp)
310:おじゃばさま
07/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:仕様書無しさん
07/04/06 19:21:34
ﾊﾟﾛﾊﾟﾛ
312:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 19:48:59
物事を自分で考えられる人はＯＯ厨にならない。
いま残ってるのは教条主義者だけだ
313:仕様書無しさん
07/04/06 19:49:53
で？
314:おじゃばさま
07/04/06 20:03:13
ではどうすればいいか？
理想的なのは、a()はd()の機能有りでも無でも使えて、さらにa()には修正が入らない事である。
もしこれが実現出来れば、スパゲティーコードとはオサラバである。
まあ、OOを知っている人なら分かると思うが、OOではa()の拡張、機能のオーバーライドで実現出来る。
ここがオブジェクト指向の最重要点である。やりたいことは単純なのである。
しかし問題がある。
今までの非OOでの組み方でこれをやろうとすると、出来ないのである。
もう少し正確に言うと、出来るのだが間違えても気が付きにくい。
最初は問題なく見えても、変更を繰り返すうちにまた破綻する。
どう組めば破綻しないかと言うと、これがOOを知らない者には理解しにくい。
一言で言えば、抽象化なのだが、これを聞いて分かる人などいないだろう。
まあ、組み方は後で説明するとして、オブジェクト指向の利点は分かってもらえただろうか？
315:仕様書無しさん
07/04/06 20:10:58
だめだこりゃ
316:おじゃばさま
07/04/06 20:14:36
ところで電球はCコードに修正を繰り返して破綻したコードを見た事がないのか？
どうすればこれをなくせるかと考えた事はないのか？
317:仕様書無しさん
07/04/06 20:15:23
誰かどうにかしろよ
この自己主張禿しすぎな勘違いコテ2匹
318:仕様書無しさん
07/04/06 20:15:44
ヒント：モジュール機構さえあればその件はおｋ
319:仕様書無しさん
07/04/06 20:16:12
とりあえずsageろ＞アホコテ共
320:仕様書無しさん
07/04/06 20:16:19
>>317
任せた
321:仕様書無しさん
07/04/06 20:17:09
勘弁してくれよ
こんなの触りたくねーし
322:仕様書無しさん
07/04/06 20:17:28
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
323:仕様書無しさん
07/04/06 20:18:35
Haskellの代数的データ型で、クラスインスタンスをメンバ（？）にするにはどうすればいいんですか？
324:仕様書無しさん
07/04/06 20:25:00
トリがついてるだけココ電のほうがましな気がする。
おじゃばってひょっとしてトリップ知らないんじゃないのか。
325:仕様書無しさん
07/04/06 20:26:56
>322
どっちがココでどっちがおじゃば？
326:仕様書無しさん
07/04/06 20:44:55
オブジェクト開発は俺みたいに頭がよくないとできない
327:仕様書無しさん
07/04/06 20:47:54
機能変更のたびに継承しろってか？
どういう覚え方したらこんな独りよがりの考え方になるんだ。
328:仕様書無しさん
07/04/06 21:00:52
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜ OOとは機能変更のために継承をすることである
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
329:仕様書無しさん
07/04/06 21:01:04
粘土みたいに手でさわって作れるプログラム言語作ってくれ
330:おじゃばさま
07/04/06 21:02:29
>324
トリ知らない。教えてくれ。
>326
OO出来ますって言う人は多いが、「変更にたびに完成度が増していく」ってのを実感している人は少ない。
これを話しても、仕事が出来て大量にソース組んでいる人しか同意を得られない。
才能だけでも、努力だけでもダメだって事だろ。
>327
それは誤解だ。全ての継承でやれって話ではない。
その方法が状況によって違うから、難しいんだよ。
331:仕様書無しさん
07/04/06 21:09:25
トリップの付け方もわからん
挙げ句付け方をぐぐって調べることも出来ん
そんなアホが説教してもなぁ
332:OJAVAさま ◆Fj1.051clU
07/04/06 21:12:37
|＼＿＿＿／|
| .|
| Θ Θ | ／￣￣￣￣￣￣￣
| .| ＜ 鳥つけてみたよ、すごいだろ
∈AA∋ ∧∧ ＼＿＿＿＿＿＿＿
（ﾟ‥ﾟ ） （ ﾟДﾟ）
∪∪|＿＿_⊃ ⊃
／|＿_.| |＿_|＼
| | | | ＼_|
| ﾉ ﾉ ＼＿|
＼_ノ| |
| |
333:仕様書無しさん
07/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:仕様書無しさん
07/04/06 21:41:42
・・・まあ確かに構造化言語においては
仕様変更に対応するために、そのプログラムの構造から変更しなくてはならないケースはある。
そうしないと（このスレ流行の言葉で言うと）破綻するからね。
でも継承とか委譲（とか「なんちゃらパターン」）の使い分けがわからない。
>>330
「状況によって違う」というのは、
「確立した方法論は無い」とか「経験則しかない」と解釈してよいのか？
335:仕様書無しさん
07/04/06 21:43:59
ヒント：その件はモジュール機能導入でおｋ
336:仕様書無しさん
07/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
07/04/06 21:47:24
animals :: [Animal]
animals = [AH Sparrow, AH Dog, AH Sparrow]
-- www
338:仕様書無しさん
07/04/06 23:00:47
このスレには実は3人の住人しかいない
339:仕様書無しさん
07/04/06 23:04:16
その３人とは>>338、>>338の脳内のお友達、>>338の別人格、の事である
340:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/06 23:25:21
かわいそうなＯＯ厨の人たち・・・
341:仕様書無しさん
07/04/06 23:50:36
自覚が無いって恐ろしいな
342:仕様書無しさん
07/04/07 00:59:56
>>341 おまいもしっかり自覚するように
343:仕様書無しさん
07/04/07 01:55:37
１つのファイルに数種類のレコードが１行以上存在するとした場合、
そのファイルを解析して３つのテーブルを更新するものとする。
この条件に最適なクラスとインターフェースを全て挙げよ。
IT/○ro課題より
344:仕様書無しさん
07/04/07 06:20:45
オブジェクト指向以前に、利用する掲示板のFAQも読まない奴が
技術者面して他人に教えをたれようとすんな。糞。あげ。
>URLﾘﾝｸ(info.2ch.net)
345:仕様書無しさん
07/04/07 06:52:26
使いこなせず負け犬の遠吠えを繰り返すアホコテが1匹
使いこなしたつもりで勘違い講釈を続けるアホコテが1匹
何をやらせてもアホはアホのままって見本みたいな奴らだったな
346:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 09:37:41
>>343
なにその糞問題
作ったやつ馬鹿じゃねーの？
347:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 09:44:26
問題は３行目だ
作るのか？作るんだったら俺クラスあげたって名前みんな違うからしょうがないし
ライブラリ引っ張ってくるだけのものを言ってるのなら それだけのやつって事だな。
この条件に最適 ってのもＤＱＮ的に意味不明だな
「この条件でプログラムを組む場合使うクラス」なら判るが
さらに「最適」っておまい決められるのかよ
348:仕様書無しさん
07/04/07 11:16:44
>>343
俺はOODはイマイチよく解らんが
思い付く限りでやってみる。
数種類のレコードってことは
複数のレコード形式が雑じったファイルかな？
テーブル３種は甲乙丙と名付けたとして…
このファイル形式を扱うクラス
レコードインターフェース
各レコード形式のクラス
テーブル基底クラス
甲クラス
乙クラス
丙クラス
349:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/07 12:13:30
テーブルと１：１でクラス作るのは、初めて組んだときやったけど
効率悪いわ、結合が増えてモジュールが破綻しそうになるわでやってないな。
Ｊｏｉｎ文なんかつかえないわなー
おこちゃまプログラミング
350:仕様書無しさん
07/04/07 12:20:06
テーブルとクラスを１：１にしていいのはASP.NETだけ
351:仕様書無しさん
07/04/07 13:11:17
TableModuleとかいうパターンだな
352:仕様書無しさん
07/04/07 19:55:33
再利用は不効率だから
353:仕様書無しさん
07/04/07 19:56:29
不幸率ってなんだよ非効率だろ
354:仕様書無しさん
07/04/07 20:12:29
非行率ってなんだよ国公立だろ
355:仕様書無しさん
07/04/08 02:30:28
ねえねえココ電球～～
356:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 03:40:55
はい？
357:仕様書無しさん
07/04/08 04:06:03
>>356
/＼＿＿_／＼
／'''''' ''''''::＼
|（へ）, 、（へ）、.| ふふ、呼んでみただけ♪
| ,,ノ(、_, )ヽ、,, .:|
| ｀-=ニ=- ' .:::::|
＼ ｀ニニ´ .＿／
（｀ー‐--‐‐―/ ）.|´
| | ヽ|
ゝ ノ ヽ ノ
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
358:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 05:10:46
うー
359:仕様書無しさん
07/04/08 09:58:22
電球は、徹夜だったのか？
歳なんだから無理するなよ
360:仕様書無しさん
07/04/08 10:51:21
さぁ、ザリガニのスーパークラスは、カニか？エビか？ どっち？
361:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 11:37:51
Ｃだと多重継承が許されるのです
362:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 11:44:20
思い出したが、結合の概念はずっと前から持っていた。
自分の頭の中で連結と読んでいたけど、
データベースのデータには確率的にぼやけているデーターがある。
量子力学の電子の雲の図を思い浮かべてもらうといい。
不確定性状態のデーターを参照しているデーターも不確定となる。
リレーショナルＤＢがＯＯと相性が悪いのはＯＯが不確定性データーを扱えないからともいえると思う。
363:仕様書無しさん
07/04/08 11:57:55
nullってあるじゃん
364:仕様書無しさん
07/04/08 12:01:45
不確定な仕様しか出せないから不確定要素とかいう表現が出てくる
要件が確定してたらザリガニはエビかカニかなんていうどうでも良い名詞並べたいだけの考え方なんて出てこないよ
365:仕様書無しさん
07/04/08 12:05:20
SQLのNULLは「不明(unknown)」「非適用(not applicable)」の意味で使われます。
366:仕様書無しさん
07/04/08 12:25:42
今のOOではクラスの構造は設計時に決まってしまうため、
AクラスとBクラスから、両方の属性を併せ持つCクラス
を動的に生成できないからな。
SQLでは結合や射影を使って何通りものオブジェクトを動
的に生成できる。所謂パラダイムミスマッチ。
367:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:04:53
ちげーよ
マルチクライアントだと常に誰かがデーターを変更している可能性があるから
今読んだデーターが次の瞬間もデータベース上のデーターと一致しているとは限らないということ。
368:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:07:35
Ｊａｖａでも動的生成はできる。
プログラムでソースコード吐き出してコンパイラ呼んでＣｌａｓｓクラスで取り込むんだったとおもう たしか
369:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/08 13:08:21
ＪＩＴってのもあったな。
わすれたが
370:仕様書無しさん
07/04/08 13:46:24
データベースの排他処理はOOとは別問題
371:仕様書無しさん
07/04/08 13:51:54
>>361
Cだと継承できねーよ
C++だろ。正確になっ。ココナッツ電灯。
372:仕様書無しさん
07/04/08 14:49:56
どうでもいいけど
「データー」はねーって
↑
変な読み方スレ逝け屑コテ
373:仕様書無しさん
07/04/08 15:22:28
>>367
ダーティリード、反復不可読み取りの例か。
更新ロックで回避しても、他が待ちになってつかえるから、
中間表でもマスタでもいいが、タイムスタンプカラム、更新フラグカラムを作るわけだな。
374:仕様書無しさん
07/04/09 13:15:09
昔から「データー」という椰子にハイスキル無しは有名
375:仕様書無しさん
07/04/09 17:21:44
昔から揚げ足取りにハイスキル無しは有名
376:仕様書無しさん
07/04/09 17:27:16
>>375
はつみみです。
377:仕様書無しさん
07/04/09 18:35:51
昔からOO厨にハイスキル無しは有名
378:おじゃばさま
07/04/09 19:03:07
>334
最初は継承だけ知っていればいい。委譲だのデザインパターンなどは知らなくてもいい。
継承すら最初に継承を考慮して設計する必要もない。変更修正すると継承が必要になってくるので、
そこで使えばいい。
デザインパターンに当てはめればOOだと言うのは間違いだ。いまだにそう考えている人がいるが、
それは耐震素材を使えば、耐震建築物になると言っているのに等しい。
確立した方法はないとか、経験則しかないと言うのもちょっと違う。
重要なのは抽象化なのだが、確かに確立した方法（こうすべき）と言うのは俺も見つけていない。
しかしOOの方針（こうした方が良い）と言うのはあり、それで十分だ。
なぜならOOは修正範囲が狭いので、ある程度間違えていても後から修正が効く。
修正を繰り返せば抽象化が進み完成度が増す。だから「方法」より緩い「方針」で十分だ。
方針は説明しても「OOを理解している人にしか分からない」事が多くて意味がない。
だから俺は学習手順を教えている。内容は前にも言ったが、また今度説明しよう。
379:仕様書無しさん
07/04/09 20:46:33
だからトリつけてこいよ。おじゃばさま何人もいるとわかったんだろ。
えらそうに講釈たれる前にそっからだ
っても、おじゃばさま、がJava厨の共同コテならしかたないわなｗ
380:仕様書無しさん
07/04/10 06:49:05
オブジェクト指向ができてきた理由も価値もわからずオブジェクト指向オブジェクト指向と言ってるだけだからだよ。
かつての構造化プログラミングのときのgotoのようだ。
結局、頭を使って組んでるやつは、なにを使っても保守性汎用性の高いプログラミングをしている
381:仕様書無しさん
07/04/10 09:31:17
で、「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？」については、OO語りは寝言ばっかりだからなのか？
382:仕様書無しさん
07/04/10 13:43:59
そもそも手法の一つとして使うものなのに
流行る流行らないで見てる時点でおかしいわな
383:仕様書無しさん
07/04/10 14:06:10
毒デムパコテ常駐スレ
詳しくは >>196
384:仕様書無しさん
07/04/10 23:05:14
ただいまおまいら！
思った以上に伸びててびっくりしたよ。
書いた事以外にも新人の信じられない行動はあるんだ。これを書いたところでネタとしか思われないと思って書かなかったけど書いてみる。
新人の力試すため一番最初にとりあえず基礎的な事をやらせてみてたんだ。
Hello Worldを出力、メソッド分け、条件分岐記述、ループ記述とかやらせて見て、どこまでできてどこからできないってのがわかったら教えなきゃいけない部分がわかると思って。
んでやらせてみたら怪しい書き方ながらもなんとかHello World出力は書けた。
俺「んじゃあ…今のちょっと怪しかったから自分の名前と年齢出力する記述を改行も使って書いてみ。」
新「えっと、よくわからないんすけど、なにからやるんすか？」
俺「とりあえずメソッド書いて」
新「はい」
カタカタカタ…
新「書きましたけど」
俺は愕然とした。そいつのディスプレイにはソース内にもろにカタカナで「メソッド」と打鍵されていたんだ。
Eclipseから露骨に赤文字で指摘されてるんだ。
そこで俺はこいつが前職でJAVAをやってたのが嘘だと確信した。
これを読んだおまいらの中には「それ絶対ネタだろ」とか思う奴もいるだろうが、
紛 れ も な い 実 話
385:仕様書無しさん
07/04/11 00:27:43
新人の概要が先に欲しかった
初心者ならそんなもんだろとおも
386:仕様書無しさん
07/04/11 11:16:04
派遣でJava経験ありでそういうのが来ることもないとはいえないのがこの業界
387:おじゃばさま◇jpaavsas
07/04/11 20:46:31
>380
まさにその通りだ。
>381
OOは説明できなくても、感覚的にマスターしている人は多い。
そのため、流行っていると言うよりは、普及していると言えるだろう。
寝言が多いのは、引退SEや営業が偽コンサルをやっているためだろう。
>382
その通りだ。
仕様が明確で変更が少ないシステムなら、非OOの方が効率がいい場合も多い。
388:おじゃばさま◇jpaavsas
07/04/11 20:48:57
新人についてならこんな伝説を聞いた事がある。
上司「今日から新人が来る。パソコンは得意と言う話だ。」
先輩「そうですか楽しみですね。」
次の日----------------------------------------------------
新人「よろしくお願いします。」
先輩「これが君のマシンだよ。」
10分後----------------------------------------------------
新人「あのー、これどうやって電源入れるのでしょうか？」
先輩「え、電源ボタンはこれだけど．．．パソコン得意なんじゃないの？」
新人「スーパーマリオなら得意なんですけど。」
先輩「．．．それってファミコンじゃん。」
389:仕様書無しさん
07/04/11 21:11:08
なぁ、コイツこれでトリつけたつもりなの？
流石に笑えんのだが。
390:おじゃばさま ◆Fy0HoitUDw
07/04/11 22:13:14
偽者出現か。
しようがない奴だな。
>>387
身分詐称で通報しますた。
391:仕様書無しさん
07/04/11 22:44:32
おじゃばさまは身分なのか
392:仕様書無しさん
07/04/11 22:52:22
＞おじゃば、他エロい人
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ
１．テーブル１つに対してクラスを１つ作った方がいいの？
２．結合の場合はどうすんの？
３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
393:仕様書無しさん
07/04/11 22:58:49
＞１．テーブル１つに対してクラスを１つ作った方がいいの？
>>350
＞２．結合の場合はどうすんの？
場合による
＞３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
使うな
394:仕様書無しさん
07/04/11 22:58:52
１．日本では一夫一妻制です。
２．感染症予防に気をつけましょう。
３．組み手は48手あります。あまり追求しないようにしましょう。
395:仕様書無しさん
07/04/11 23:52:28
>>391
ｗｗ
396:仕様書無しさん
07/04/11 23:53:40
>>393
>使うな
その理由を、説明できるもんなら説明願います。
397:仕様書無しさん
07/04/11 23:58:15
>>396
じゃあ使え
398:ココ電球（∩T∀T)y-~~~~ ◆tIS/.aX84.
07/04/12 00:12:37
>>396
１） 遅い。 劇重。 重さ１０倍。（当社比）
使ったシステムは後で必ず後悔しているが、変更箇所が膨大になるので直せない。
２） テーブル名をキーワードに探したりすると漏れる。メンテナンスが把握できない場合がある。
399:仕様書無しさん
07/04/12 01:11:07
>>392
OOでのDBテーブル操作方法を初心者な漏れに教えてちょ
Ｑ１．テーブル１つに対してクラスを１つ作った方がいいの？
Ａ１．違う。パラダイムに沿ってクラスを作る。
テーブルが１つになることもあるし複数になることもある。
Ｑ２．結合の場合はどうすんの？
Ａ２．お好きに。
Ｑ３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
Ａ３．呼び出し元言語でハードコーディングしなくて良いようにするのがよい。
400:おじゃばさま
07/04/12 14:36:32
>392
まず、オブジェクト指向とSQLデータベースは相性が悪いと言う事を認識しておく必要がある。
そのため効率の悪い実装をしなければならない所があるが、そこは割り切る必要がある。
>１．テーブル１つに対してクラスを１つ作った方がいいの？
結果から言うと、テーブル1つに対してクラスは2個にするのが無難だ。
クラス2個と言うのはSQL実行用のクラスと、1レコード格納用のクラスだ。
OOの基本から言えばクラスは誰かが言っていた「パラダイム毎」になり、SQL実行用とレコード格納用
クラスは分けるべきではないだろう。しかし「パラダイム毎」と言うのは分かりにくく、
SQL実行用とレコード格納用クラスが1つになった物は、別の所で使いにくい。ここが相性の悪い所だ。
ここは割り切って、次のように設計する。
401:396
07/04/12 14:36:39
>>398
あー、あんたは答えなくていい。
402:仕様書無しさん
07/04/12 14:38:43
>>400
>SQLデータベース
なんだこりゃ。
403:おじゃばさま
07/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:おじゃばさま
07/04/12 14:55:09
>402
SQLのような文章解析型の制御を使ったDBを、SQLデータベースとした。
OOと「文章解析型の制御」は相性が悪い。同様の物にprintfなどがある。
405:仕様書無しさん
07/04/12 14:56:39
Factory+TableでDIパターンだろ
406:仕様書無しさん
07/04/12 15:18:14
うん、そーやって自分自身のフレームワークを作る努力は大切だ。がんばれ
407:仕様書無しさん
07/04/12 15:30:20
おじゃばさま製O/Rマッパに期待わくわく。
おじゃばさま ◆Fy0HoitUDwとは違うおじゃばさまなのか？
408:仕様書無しさん
07/04/12 15:34:55
>>404
俺用語使うな間抜け。
つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。
409:仕様書無しさん
07/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:仕様書無しさん
07/04/12 17:11:59
動作が糞遅い。
411:仕様書無しさん
07/04/12 17:59:59
誰も聞いてくれない話をここに放出して、気持ちよかったか？
412:おじゃばさま
07/04/12 18:22:37
>407
上記構造は実用的だが理想には遠い。個人でさらに良い方法を研究することを望む。
また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。
>408
>つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。
すまんが、何を言いたいのか分からない。
>409
OOの話とは関係ないが、巨大な中間表の結果から更新をするような設計自体が間違いの可能性が高い。
WEB等で途中に人の入力が介在する場合は、更新日時によるチェックを行うが、それ以外でフラグ等による
更新チェックを行う場合は少ない。まあ実際の使用例を聞いてみないと分からないが。
適切に正規化されている場合は、検索結果で更新する事はまれだし、適切にテーブル分けしてあれば、
レコードロックによる更新で影響を受ける範囲は少ない。
413:おじゃばさま
07/04/12 19:15:00
>392
>２．結合の場合はどうすんの？
簡単な結合の場合は、格納クラスと実行クラスをそれぞれextendsして、ベースクラスに項目を追加して
使用する。複雑な結合の場合は、新たにそれ専用のクラスを作る。
>３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？
まずストアドを使う意味を確認しておこう。
ストアドの利点としては、大量の検索を伴う集計処理や更新処理で使用する事により、
ネットワーク上を流れる大量の検索結果やSQL文を軽減する事にある。
参考までに、欠点はデバックが困難だということだ。
ちなみに、現代の高速ネットワークの上では、ストアドの利点はあまりない。
誰かが使うなと言った人はそのためだろう。
使う場合は、大量のまとまった処理に使う。数個のパラメータを渡して、ストアド内部で処理を行い、
ロールバックやコミットも内部で行い、結果をOK/NGで返すぐらいにするのが望ましい。
そうなると呼び出し側は1つの普通のクラスで構わない。
414:仕様書無しさん
07/04/12 19:45:59
なんだよ。また口だけか
415:仕様書無しさん
07/04/12 21:48:35
オラクルのストアドの作り方って、
SQLサーバーと似たようなもの？それとも、全然違うの？
416:仕様書無しさん
07/04/12 22:41:25
インスタンスとオブジェクトの違いってなんすか？
417:仕様書無しさん
07/04/12 22:53:56
>>409
バージョンカラム使った楽観的排他と比べてどうなん？
418:仕様書無しさん
07/04/13 00:16:14
＞また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。
まあ、いろいろまずいからごまかしてる、でおｋ？
パスワードｗとやらは変えればいいじゃないか？
同一人物では困る事情でもあるならべつだけどねｗ
で、O/Rマッピングはうまくできたのかな？
419:仕様書無しさん
07/04/13 01:24:31
>416
オブジェクト：
オブジェクト指向における基本単位。「もの」の意味。
文字列だったり、リストだったり、型だったり、数値だったり
ボタンだったり、テキストボックスだったり
クラスだったり、メソッドだったり、何かのデータだったりする。
インスタンス：
あるクラスを基にして作られたオブジェクト。
「文字列クラスのインスタンス」なんて言ったりする。
420:仕様書無しさん
07/04/13 01:41:33
オブジェクト指向以外禁止だからキツイ。
最近になって解ってきたけど多態性がポイントだな
421:仕様書無しさん
07/04/13 06:55:25
>>392
データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア
開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で
データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が
数多く巻き起こっている。
アプリケーション開発者の多くはRDB のことを裏側に隠しておくのにちょうどいいストレージ
装置だと思いがちだ。
URLﾘﾝｸ(capsctrl.que.jp)
422:仕様書無しさん
07/04/13 06:57:31
> 同一人物では困る事情でもあるならべつだけどねｗ
同一人物だけど、同一人物ではないと思ってほしいだけだろ。
素性はバレバレだがｗ
423:仕様書無しさん
07/04/13 07:04:25
マーチンの言うトランザクションスクリプトには、
ピン(凝ったＳＱＬやストアドプロシージャ使いまくり)から
キリ(構造化プログラミングで処理を書きまくり)まで
いろいろなケースが含まれる。
424:仕様書無しさん
07/04/13 08:32:41
>>423
そだね、今はSQLJとかC#ストアードプロシージャとかパススルーあるしね、Martin Fowlerは
あらかじめOOPSにバイアスを掛けた見方（偏った？）を前提に、あの文章を書いてると思う
手続き型プログラミングでも問題が無いところを、わざわざロジックとデータロード操作と
切り分けて同一ソースへのアクセスの際の利便性を強調しているが、1度しか使用され
ないデータ抽出と集計するロジックを別クラスとした場合、見る人により不明瞭だろう
>>413
OODの問題として捕らえると1：1もしは1：Nとした場合の爆発的なクラス増加と、継承を
使用する前提とした場合の見通しの悪さがある、一般的にプログラマーは同じ処理を他人
より短く速く短時間で書ける事を誇りにするから、継承を使いたがる気持ちが分からないでもない
確かにいまどきは1：1で設計するのがほとんどであろう、ただ結合の場合においてはそのやり方では
疑問が残る、パフォーマンスとソースのメンテナンス性はトレードオフではないのだからOOP以外の策も
今後考慮されるべきであろう
>>398
簡潔すぎると一般の人には分かりませんよ・・
425:仕様書無しさん
07/04/13 09:16:07
きみの文章はヘタクソだ
要点を簡潔に書く訓練をしたまえ
426:仕様書無しさん
07/04/13 09:19:14
妄想を暗黙の了解事項として書くから
主旨の読み取れない意味不明な文章になるのだと思う
427:仕様書無しさん
07/04/13 09:34:59
いいから藻前ら句読点つけろ。
428:おじゃばさま
07/04/13 09:41:32
>416
広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。
オブジェクト=クラス=型
インスタンス=値
つまりクラスがオブジェクトで、クラスをnewしてメモリ確保したのがインスタンス。
429:仕様書無しさん
07/04/13 11:53:17
まだ鳥の付け方もわからんのか
流石アホコテ
430:おじゃばさま ◆Fy0HoitUDw
07/04/13 12:10:48
私は愚か者です
首吊ってきますｗ
431:仕様書無しさん
07/04/13 12:14:26
>URLﾘﾝｸ(rina.nadenade.com)
＞中には「クラス=オブジェクト」というなかなか理解しがたい解釈をされる方もいて、
＞この人がまたソフトを飯の種にしているっぽいので頭が痛いです(笑)。
w
432:仕様書無しさん
07/04/13 12:21:44
>>415
も答えてください。
オラクルの現場、何故か、当たった事ないのです。
433:仕様書無しさん
07/04/13 12:30:35
あるひとは「もの」の本質は「おなじようなものを集めた集合」にあるといい
また別のあるひとは「もの」は「おなじようなものを集めた集合に属する要素」だという。
どちらも正しい。
しかし、「もの」とは「おなじようなものを集めた集合」そのものに等しいなどという戯言は
笑止千万
434:おじゃばさま ◆Fy0HoitUDw
07/04/13 12:31:21
愚かですいません
435:仕様書無しさん
07/04/13 12:45:42
ラッセルもﾋﾞｸｰﾘ