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

1 名前：仕様書無しさん mailto:sage [2007/03/29(木) 01:28:08 ] 過去スレ 【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★4 pc11.2ch.net/test/read.cgi/prog/1173529414/ 【OOD/P】ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？★5 pc11.2ch.net/test/read.cgi/prog/1174746731/ スルー推奨ワード（相手をした場合は荒らしとみなされます） 電球、たかひろ 　このスレは設計、実装含めた形でのOOに関する話題について語り合う目的で立てています。 　なので設計だけ、実装だけといった縛りは特にありません。 　設計には方針レベルからデザインパターンなどの実装設計レベルまで幅広くあります。 　いままでの流れをみるかぎり、各々OOに対する考え方や適用レベルが異なるため、煽りや中傷のレスが書き込まれていますが、 　書き込む方はどのスコープでOOを適用するかを伝えた上で書き込むのが良いかと思います。 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 名前：仕様書無しさん mailto:sage [2007/04/08(日) 13:46:24 ] データベースの排他処理はOOとは別問題 371 名前：仕様書無しさん [2007/04/08(日) 13:51:54 ] >>361 Cだと継承できねーよ C++だろ。正確になっ。ココナッツ電灯。 372 名前：仕様書無しさん mailto:sage [2007/04/08(日) 14:49:56 ] どうでもいいけど 「データー」はねーって 　　　　 ↑ 変な読み方スレ逝け屑コテ 373 名前：仕様書無しさん mailto:sage [2007/04/08(日) 15:22:28 ] >>367 ダーティリード、反復不可読み取りの例か。 更新ロックで回避しても、他が待ちになってつかえるから、 中間表でもマスタでもいいが、タイムスタンプカラム、更新フラグカラムを作るわけだな。 374 名前：仕様書無しさん [2007/04/09(月) 13:15:09 ] 昔から「データー」という椰子にハイスキル無しは有名 375 名前：仕様書無しさん mailto:sage [2007/04/09(月) 17:21:44 ] 昔から揚げ足取りにハイスキル無しは有名 376 名前：仕様書無しさん mailto:sage [2007/04/09(月) 17:27:16 ] >>375 はつみみです。 377 名前：仕様書無しさん mailto:sage [2007/04/09(月) 18:35:51 ] 昔からOO厨にハイスキル無しは有名 378 名前：おじゃばさま [2007/04/09(月) 19:03:07 ] >334 最初は継承だけ知っていればいい。委譲だのデザインパターンなどは知らなくてもいい。 継承すら最初に継承を考慮して設計する必要もない。変更修正すると継承が必要になってくるので、 そこで使えばいい。 デザインパターンに当てはめればOOだと言うのは間違いだ。いまだにそう考えている人がいるが、 それは耐震素材を使えば、耐震建築物になると言っているのに等しい。 確立した方法はないとか、経験則しかないと言うのもちょっと違う。 重要なのは抽象化なのだが、確かに確立した方法（こうすべき）と言うのは俺も見つけていない。 しかしOOの方針（こうした方が良い）と言うのはあり、それで十分だ。 なぜならOOは修正範囲が狭いので、ある程度間違えていても後から修正が効く。 修正を繰り返せば抽象化が進み完成度が増す。だから「方法」より緩い「方針」で十分だ。 方針は説明しても「OOを理解している人にしか分からない」事が多くて意味がない。 だから俺は学習手順を教えている。内容は前にも言ったが、また今度説明しよう。 379 名前：仕様書無しさん mailto:sage [2007/04/09(月) 20:46:33 ] だからトリつけてこいよ。おじゃばさま何人もいるとわかったんだろ。 えらそうに講釈たれる前にそっからだ っても、おじゃばさま、がJava厨の共同コテならしかたないわなｗ 380 名前：仕様書無しさん mailto:sage [2007/04/10(火) 06:49:05 ] オブジェクト指向ができてきた理由も価値もわからずオブジェクト指向オブジェクト指向と言ってるだけだからだよ。 かつての構造化プログラミングのときのgotoのようだ。 結局、頭を使って組んでるやつは、なにを使っても保守性汎用性の高いプログラミングをしている 381 名前：仕様書無しさん mailto:sage [2007/04/10(火) 09:31:17 ] で、「ｵﾌﾞｼﾞｪｸﾄ指向開発はなぜ流行らないの？」については、OO語りは寝言ばっかりだからなのか？ 382 名前：仕様書無しさん mailto:sage [2007/04/10(火) 13:43:59 ] そもそも手法の一つとして使うものなのに 流行る流行らないで見てる時点でおかしいわな 383 名前：仕様書無しさん mailto:sage [2007/04/10(火) 14:06:10 ] 毒デムパコテ常駐スレ 詳しくは >>196 384 名前：仕様書無しさん mailto:sage [2007/04/10(火) 23:05:14 ] ただいまおまいら！ 思った以上に伸びててびっくりしたよ。 書いた事以外にも新人の信じられない行動はあるんだ。これを書いたところでネタとしか思われないと思って書かなかったけど書いてみる。 新人の力試すため一番最初にとりあえず基礎的な事をやらせてみてたんだ。 Hello Worldを出力、メソッド分け、条件分岐記述、ループ記述とかやらせて見て、どこまでできてどこからできないってのがわかったら教えなきゃいけない部分がわかると思って。 んでやらせてみたら怪しい書き方ながらもなんとかHello World出力は書けた。 俺「んじゃあ…今のちょっと怪しかったから自分の名前と年齢出力する記述を改行も使って書いてみ。」 新「えっと、よくわからないんすけど、なにからやるんすか？」 俺「とりあえずメソッド書いて」 新「はい」 カタカタカタ… 新「書きましたけど」 俺は愕然とした。そいつのディスプレイにはソース内にもろにカタカナで「メソッド」と打鍵されていたんだ。 Eclipseから露骨に赤文字で指摘されてるんだ。 そこで俺はこいつが前職でJAVAをやってたのが嘘だと確信した。 これを読んだおまいらの中には「それ絶対ネタだろ」とか思う奴もいるだろうが、 紛　れ　も　な　い　実　話 385 名前：仕様書無しさん mailto:sage [2007/04/11(水) 00:27:43 ] 新人の概要が先に欲しかった 初心者ならそんなもんだろとおも 386 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/11(水) 21:11:08 ] なぁ、コイツこれでトリつけたつもりなの？ 流石に笑えんのだが。 390 名前：おじゃばさま ◆Fy0HoitUDw mailto:sage [2007/04/11(水) 22:13:14 ] 偽者出現か。 しようがない奴だな。 >>387 身分詐称で通報しますた。 391 名前：仕様書無しさん mailto:sage [2007/04/11(水) 22:44:32 ] おじゃばさまは身分なのか 392 名前：仕様書無しさん mailto:sage [2007/04/11(水) 22:52:22 ] ＞おじゃば、他エロい人 OOでのDBテーブル操作方法を初心者な漏れに教えてちょ １．テーブル１つに対してクラスを１つ作った方がいいの？ ２．結合の場合はどうすんの？ ３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？ 393 名前：仕様書無しさん mailto:sage [2007/04/11(水) 22:58:49 ] ＞１．テーブル１つに対してクラスを１つ作った方がいいの？ >>350 ＞２．結合の場合はどうすんの？ 場合による ＞３．PL/SQLでのストアドプロシージャはどうやって組んだ方がいい？ 使うな 394 名前：仕様書無しさん [2007/04/11(水) 22:58:52 ] １．日本では一夫一妻制です。 ２．感染症予防に気をつけましょう。 ３．組み手は48手あります。あまり追求しないようにしましょう。 395 名前：仕様書無しさん mailto:sage [2007/04/11(水) 23:52:28 ] >>391 ｗｗ 396 名前：仕様書無しさん mailto:sage [2007/04/11(水) 23:53:40 ] >>393 >使うな その理由を、説明できるもんなら説明願います。 397 名前：仕様書無しさん mailto:sage [2007/04/11(水) 23:58:15 ] >>396 じゃあ使え 398 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/04/12(木) 00:12:37 ] >>396 １）　遅い。　劇重。　重さ１０倍。（当社比） 　　　使ったシステムは後で必ず後悔しているが、変更箇所が膨大になるので直せない。 ２）　テーブル名をキーワードに探したりすると漏れる。メンテナンスが把握できない場合がある。 399 名前：仕様書無しさん mailto:sage [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 mailto:sage [2007/04/12(木) 14:36:39 ] >>398 あー、あんたは答えなくていい。 402 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/12(木) 14:56:39 ] Factory+TableでDIパターンだろ 406 名前：仕様書無しさん mailto:sage [2007/04/12(木) 15:18:14 ] うん、そーやって自分自身のフレームワークを作る努力は大切だ。がんばれ 407 名前：仕様書無しさん mailto:sage [2007/04/12(木) 15:30:20 ] おじゃばさま製O/Rマッパに期待わくわく。 おじゃばさま ◆Fy0HoitUDwとは違うおじゃばさまなのか？ 408 名前：仕様書無しさん mailto:sage [2007/04/12(木) 15:34:55 ] >>404 俺用語使うな間抜け。 つか、外界とのI/FがSQLかどうかなどDBMSとは無関係だ間抜け。 409 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/12(木) 17:11:59 ] 動作が糞遅い。 411 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/12(木) 19:45:59 ] なんだよ。また口だけか 415 名前：仕様書無しさん [2007/04/12(木) 21:48:35 ] オラクルのストアドの作り方って、 SQLサーバーと似たようなもの？それとも、全然違うの？ 416 名前：仕様書無しさん [2007/04/12(木) 22:41:25 ] インスタンスとオブジェクトの違いってなんすか？ 417 名前：仕様書無しさん mailto:sage [2007/04/12(木) 22:53:56 ] >>409 バージョンカラム使った楽観的排他と比べてどうなん？ 418 名前：仕様書無しさん mailto:sage [2007/04/13(金) 00:16:14 ] ＞また、トリはパスワードがばれたし、伊賀者もいないみたいなので、とりあえずつけないでおく。 まあ、いろいろまずいからごまかしてる、でおｋ？ パスワードｗとやらは変えればいいじゃないか？ 同一人物では困る事情でもあるならべつだけどねｗ で、O/Rマッピングはうまくできたのかな？ 419 名前：仕様書無しさん mailto:sage [2007/04/13(金) 01:24:31 ] >416 オブジェクト： 　　　　オブジェクト指向における基本単位。「もの」の意味。 　　　　文字列だったり、リストだったり、型だったり、数値だったり 　　　　ボタンだったり、テキストボックスだったり 　　　　クラスだったり、メソッドだったり、何かのデータだったりする。 インスタンス： 　　　　あるクラスを基にして作られたオブジェクト。 　　　　「文字列クラスのインスタンス」なんて言ったりする。 420 名前：仕様書無しさん [2007/04/13(金) 01:41:33 ] オブジェクト指向以外禁止だからキツイ。 最近になって解ってきたけど多態性がポイントだな 421 名前：仕様書無しさん mailto:sage [2007/04/13(金) 06:55:25 ] >>392 　データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア 開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が 数多く巻き起こっている。 アプリケーション開発者の多くはRDB のことを裏側に隠しておくのにちょうどいいストレージ 装置だと思いがちだ。 capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL 422 名前：仕様書無しさん mailto:sage [2007/04/13(金) 06:57:31 ] > 同一人物では困る事情でもあるならべつだけどねｗ 同一人物だけど、同一人物ではないと思ってほしいだけだろ。 素性はバレバレだがｗ 423 名前：仕様書無しさん mailto:sage [2007/04/13(金) 07:04:25 ] マーチンの言うトランザクションスクリプトには、 ピン(凝ったＳＱＬやストアドプロシージャ使いまくり)から キリ(構造化プログラミングで処理を書きまくり)まで いろいろなケースが含まれる。 424 名前：仕様書無しさん mailto:sage [2007/04/13(金) 08:32:41 ] >>423 そだね、今はSQLJとかC#ストアードプロシージャとかパススルーあるしね、Martin Fowlerは あらかじめOOPSにバイアスを掛けた見方（偏った？）を前提に、あの文章を書いてると思う 手続き型プログラミングでも問題が無いところを、わざわざロジックとデータロード操作と 切り分けて同一ソースへのアクセスの際の利便性を強調しているが、1度しか使用され ないデータ抽出と集計するロジックを別クラスとした場合、見る人により不明瞭だろう >>413 OODの問題として捕らえると1：1もしは1：Nとした場合の爆発的なクラス増加と、継承を 使用する前提とした場合の見通しの悪さがある、一般的にプログラマーは同じ処理を他人 より短く速く短時間で書ける事を誇りにするから、継承を使いたがる気持ちが分からないでもない 確かにいまどきは1：1で設計するのがほとんどであろう、ただ結合の場合においてはそのやり方では 疑問が残る、パフォーマンスとソースのメンテナンス性はトレードオフではないのだからOOP以外の策も 今後考慮されるべきであろう >>398 簡潔すぎると一般の人には分かりませんよ・・ 425 名前：仕様書無しさん mailto:sage [2007/04/13(金) 09:16:07 ] きみの文章はヘタクソだ 要点を簡潔に書く訓練をしたまえ 426 名前：仕様書無しさん mailto:sage [2007/04/13(金) 09:19:14 ] 妄想を暗黙の了解事項として書くから 主旨の読み取れない意味不明な文章になるのだと思う 427 名前：仕様書無しさん mailto:sage [2007/04/13(金) 09:34:59 ] いいから藻前ら句読点つけろ。 428 名前：おじゃばさま [2007/04/13(金) 09:41:32 ] >416 広い意味では同じ物として扱われる場合があるが、狭い意味で以下の通り。 オブジェクト=クラス=型 インスタンス=値 つまりクラスがオブジェクトで、クラスをnewしてメモリ確保したのがインスタンス。 429 名前：仕様書無しさん mailto:sage [2007/04/13(金) 11:53:17 ] まだ鳥の付け方もわからんのか 流石アホコテ 430 名前：おじゃばさま ◆Fy0HoitUDw [2007/04/13(金) 12:10:48 ] 私は愚か者です 首吊ってきますｗ 431 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/13(金) 12:30:35 ] あるひとは「もの」の本質は「おなじようなものを集めた集合」にあるといい また別のあるひとは「もの」は「おなじようなものを集めた集合に属する要素」だという。 どちらも正しい。 しかし、「もの」とは「おなじようなものを集めた集合」そのものに等しいなどという戯言は 笑止千万 434 名前：おじゃばさま ◆Fy0HoitUDw mailto:sage [2007/04/13(金) 12:31:21 ] 愚かですいません 435 名前：仕様書無しさん mailto:sage [2007/04/13(金) 12:45:42 ] ラッセルもﾋﾞｸｰﾘ 436 名前：仕様書無しさん mailto:sage [2007/04/13(金) 13:35:12 ] >ttp://book.geocities.jp/bits_of_java/java/lang/instance/index.html ＞前出のようにクラスを具現化したものはオブジェクトですから ＞インスタンスはオブジェクトを指して使う言葉という事になります。 本当にあ(ry 437 名前：仕様書無しさん mailto:sage [2007/04/13(金) 14:32:09 ] 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 名前：仕様書無しさん mailto:sage [2007/04/13(金) 14:32:20 ] 「クラスを具現化したもの」なら「インスタンス」の方が適切だな 439 名前：仕様書無しさん mailto:sage [2007/04/13(金) 14:32:47 ] >>436 お前があ（ｒｙ 440 名前：仕様書無しさん mailto:sage [2007/04/13(金) 14:37:57 ] >>438同意 おバカさまはクラス・オブジェクトが存在するような言語では 　クラス⊂オブジェクト なのを知って、クラス＝オブジェクトという妄念を得たのではないか？ 441 名前：仕様書無しさん [2007/04/13(金) 15:06:14 ] >>415 シカト？ 442 名前：仕様書無しさん mailto:sage [2007/04/13(金) 15:15:10 ] しょうがねえな。 >>415 おまえもｽﾚﾀｲ100回音読の刑に処す。 443 名前：仕様書無しさん [2007/04/13(金) 16:54:02 ] >>おじゃば おじゃばさまはようやくコテの付け方を覚えたか おじゃばさまが愚か者であることは皆知ってるから謝る必要は無い それより、俺愚かだからお舞ら教えろと言った方が良いぞ 444 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [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 名前：仕様書無しさん mailto:sage [2007/04/13(金) 23:19:33 ] 　　　　　＿ 　　　　　＼.＼ 　　　　　バカでもチンポでもいいから勝手にやってくれ 　　　　　　 |＿| 　　　　　／　　＼　／＼＿ 　　　　　|　　　　／　／　♯＼＿＿ 　　　　　|　　　./　　/　　※　♯　※＼＿＿＿＿ 　　　／ ,＼＿/　　/　♯　　※　　♯　　　.／ ／ 　 ／＿＿＿/　　　￣￣￣￣￣￣￣￣￣ ／ 458 名前：仕様書無しさん [2007/04/13(金) 23:22:39 ] めんどくせーから全部グローバル変数でいいよ 459 名前：仕様書無しさん mailto:sage [2007/04/14(土) 01:20:00 ] DLLってCとC＋＋（OOスタイル）のどっちで書いた方がいいの？ 今の現場でC＋＋わかる人いないんだけど、 できるならC＋＋でもいいよ（保守性などをふまえてて、物ができればなんでもいいよ）、って言われてて。 教えてｴﾛい人 460 名前：仕様書無しさん mailto:sage [2007/04/14(土) 01:32:18 ] アセンブラ 461 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/04/14(土) 01:33:38 ] 自分の得意なほうでいいんじゃない？ 462 名前：392 mailto:sage [2007/04/14(土) 01:40:19 ] 高度すぎるのかなんなのか分かりませんけど、 ココ電球さんは言ってる忌みがよく分かりません。（何が言いたいのかもなぞです、すみません） おじゃばさんは叩かれてるけど言ってる忌みは分かります。 ＞おじゃばさん、他ヒント頂いたｴﾛい方々 ヒントありがとうです。 まだ迷い中・考え中ですけど、 方向性が見つかったのでうれしいです。 でもストアドはデバッグが大変なのか・・・（知識不足で申し訳） 一度に４万件ぐらいのレコードあるんですが、う〜ん・・・ つか、これはスレ違いだからいいっす！サンキューです！ 463 名前：ココ電球（∩T∀T)y-~~~~ 　 ◆tIS/.aX84. [2007/04/14(土) 04:37:12 ] おじゃば自演すんなよ　おまい 464 名前：仕様書無しさん mailto:sage [2007/04/14(土) 07:50:13 ] クラス＝オブジェクト、であれば hogeクラスのfugeオブジェクト とかいう書き方が日本語としておかしいことになります。簡単ですね。 ひょっとして、おじゃばさまは職場で boke(クラス名)オブジェクトのkasuインスタンス などと説明してるんでしょうか･･･それは恥ずかしいんじゃ･･･ 465 名前：仕様書無しさん mailto:sage [2007/04/14(土) 11:18:06 ] >>459 俺はC++で書いてラッパー関数作って extern "C" でレギュラーDLLとしてエクスポートしてる。 466 名前：仕様書無しさん mailto:sage [2007/04/14(土) 22:35:41 ] だいたい、「狭い意味でクラス＝オブジェクト(型)」とか言い切って つっこまれたら「広い意味で全部オブジェクト」かよ。 Smalltalkならともかく、Javaではクラスはオブジェクトではない。当たり前に。 「おじゃばさま」って名前はもうやめたら？馬鹿なんだし。 467 名前：仕様書無しさん mailto:sage [2007/04/14(土) 22:41:46 ] あいつあれでも、業務コンサル会社のCEOだそうです。 全然評判聞かないけどｗ 468 名前：仕様書無しさん mailto:sage [2007/04/14(土) 22:42:59 ] は？Javaのクラスはオブジェクトだろ普通に。 Object o = String.class;

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef