オブジェクト指向・嗜好・試行・至高・歯垢・伺候
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/10/23(日) 18:59:30オブジェクト指向を何度も試行したり、
オブジェクト指向は至高のものだと考えたり、
オブジェクト指向は歯垢のように無駄だと思う人が
オブジェクト指向に伺候する人に喧嘩売ったりするスレです。
前スレ
オブジェクト指向・嗜好・試行・至高・歯垢
http://pc8.2ch.net/test/read.cgi/tech/1049778124/l50
誰も立てないので立てました。
重複していましたら、削除依頼をお願いします。
0002デフォルトの名無しさん
2005/10/23(日) 19:03:220003前スレ987-988
2005/10/23(日) 19:07:54strategy くらい分かってるよヽ(｀Д´)ノ
強引に全部まとめようとすると失敗しやすいってことを言っただけだよ。
っていうか、ミサイルをまとめるとか言い出したのは俺じゃないよ｡･ﾟ･(ﾉД`)･ﾟ･｡
0004デフォルトの名無しさん
2005/10/23(日) 19:16:19まあ、無理な一般化をするなというのには同意。
で、そんな例を持ち出して何を言いたかったのやら。
うまくポリモーフィズムを使えれば
場合によっては使われない無駄な変数を持たなくて良かったり
分散しがちな条件分岐をまとめられたりする。
0005デフォルトの名無しさん
2005/10/23(日) 19:27:25文章読んでるとなんかＣ言語的なメモリコスト寄りの発想だな。
ポリモいらない君じゃないけどそれってオブジェクト指向なんかな。
00064
2005/10/23(日) 19:32:12んー、そういう言い方の方がポリモいらない君には分かりやすいと思って。
C言語的メモリコストというより、データベースの正規化の話に近いかも知れない。
0007デフォルトの名無しさん
2005/10/23(日) 21:46:17オブジェクト指向とはちょっと離れるってこと？
0008デフォルトの名無しさん
2005/10/23(日) 21:51:03継承の is-a 関係により子クラスを親クラスと同一化することによって、脳内メモリを節約することが目的。
00094
2005/10/23(日) 22:03:15必ずしもそうとは言えないんじゃないかな。
どういう単位でオブジェクト(ないしクラス)を分割すればいいか、
オブジェクト同士がどういう関連を持てばいいのか、という話につながるし。
ある程度正規化されていた方がスッキリはする。良いか悪いかはケースバイケースだけど。
0010デフォルトの名無しさん
2005/10/23(日) 22:04:23継承の仕組みはわかるけど。
使い方がＣ言語的に見るのだけど。
0012デフォルトの名無しさん
2005/10/23(日) 22:30:30だって、始めに設計ありきじゃない？
うまくまとまるかどうかは結果であって目的じゃないと思うのだけど。
00134
2005/10/23(日) 22:45:33ええと、それがC言語的なの？
> うまくまとまるかどうかは結果であって目的じゃないと思うのだけど。
現実主義的で共感しなくもないのだけど、何をもってうまくまとまるとするかに寄るし、
うまくまとめる必要を感じることはあるかな。
0014デフォルトの名無しさん
2005/10/23(日) 23:33:08じゃあ、前スレのホーミングミサイルとミサイルってどういう扱いになるの？
0015792
2005/10/23(日) 23:33:56おいらはパターン２（粒度を荒くする）パターンが好きですな。
荒いスケールを基本クラスにして、詳細は派生クラス群で実装。
（クラス間の処理はコールバックとかシグナルで対応）
VCLとかwxWidgetとかメジャーなGUIフレームワークはそうかな？
……ただ、こんな重たいフレームワーク作るのは大変だから、
〆切のキツい時は無理だろうな……
00164
2005/10/24(月) 00:16:20前スレ987-988の話？ それともその前にやっていたやつの話？
何についてかよく分からないのではっきりとした事は言えないけど、
そのゲームには非ホーミングミサイルとホーミングミサイルしか無いの？
その他の分類は一切無いの？
非ホーミングミサイルは追跡対象が無いホーミングミサイルと考えてもいいの？
そこまで単純ならわざわざ分ける必要は無いんじゃない？
大事なのは対象となる問題領域内で一般化できそうかを判断する事。
その問題領域が曖昧だとなかなか難しいけどね。
特にゲームなんか「その方が面白いから」と言う理由で簡単に変わってしまう。
だから一度判断した事を変更していく手法（リファクタリングとか）が注目される。
っていうか何で俺に聞くんだろう。
0017デフォルトの名無しさん
2005/10/24(月) 00:52:19>っていうか何で俺に聞くんだろう。
たまたまいたからｗ
オブジェクト指向的な設計をしてから、一般化だと思うんだけど。
設計をした時点だとホーミングミサイルとミサイルってどういう扱いになるの？
0018デフォルトの名無しさん
2005/10/24(月) 00:56:17設計にもよるんじゃない？ 答えは１つじゃないだろう。
0020デフォルトの名無しさん
2005/10/24(月) 02:49:350021デフォルトの名無しさん
2005/10/25(火) 03:53:25http://pc8.2ch.net/test/read.cgi/gamedev/1005576459/
0022デフォルトの名無しさん
2005/10/26(水) 08:12:21あれ使えよ
0023デフォルトの名無しさん
2005/10/27(木) 22:54:04あるとする
s.x（）とすれば
ある条件Ｊの時は、Ａ・ＢにメソッドＸ１を
非Ｊの時は、Ｃ・ＤにメソッドＸ２を使いたい
また、s.y（）とすれば
ある条件Ｋの時は、Ａ・ＣにメソッドＹ１を
非Ｊの時はＢ・ＤにメソッドＹ２を使いたい
この場合、どう暮らす設計すれば良いんだろう？
0024デフォルトの名無しさん
2005/10/27(木) 22:56:25○
ある条件Ｋの時は、Ａ・ＣにメソッドＹ１を
非Ｋの時はＢ・ＤにメソッドＹ２を使いたい
0025デフォルトの名無しさん
2005/10/27(木) 23:04:41Mediatorパターン？
0026デフォルトの名無しさん
2005/10/27(木) 23:04:54１行目がやたら問題を難しくしているんだが。
ちなみに java に限定すれば S.x() と S.y() は A, B, C, D でオーバーライドされるから、S の x() が実行されるとは限らない。
C++ or C# で x(), y() を非 vertual にすれば良いんだけど。
002726
2005/10/27(木) 23:09:00＞Ａ・ＢにメソッドＸ１
ってコレは a.x1() に b.x1() のことか？
Ａ・Ｂのインスタンスは誰が持ってるんだ？それとも this なのか？
0028デフォルトの名無しさん
2005/10/27(木) 23:30:05クライアント側のコードが
S *s=S_Factory()；
s.x()；
の時に・・・・って感じです
0029デフォルトの名無しさん
2005/10/27(木) 23:35:03s->x();
ですね。
>>28はjavaとごっちゃになってる orz
0030デフォルトの名無しさん
2005/10/27(木) 23:37:10＞S *s=S_Factory()；
この S_Factory は、ABCDS のいずれかを返すの？
んで、
＞s->x();
は、結局どういうときに x1, x2 に分岐するの？
0031デフォルトの名無しさん
2005/10/27(木) 23:42:00メソッドX/Yをどこに持たせれば良いか？
とか、もっと踏み込んで、ABCDの継承関係を見直すべきか？
とかです。
0032デフォルトの名無しさん
2005/10/27(木) 23:44:14メソッド x, y は S にあるんじゃないの？
0033デフォルトの名無しさん
2005/10/27(木) 23:49:52YES
＞は、結局どういうときに x1, x2 に分岐するの？
簡略化の為、「bool ::isｋ()」の 戻り値で分岐とします
0034デフォルトの名無しさん
2005/10/27(木) 23:52:34そうするならば
条件Ｊ・Ｋの時に、ABCDは、どうすれば良いか？？って事です
0035デフォルトの名無しさん
2005/10/27(木) 23:58:47A a = new A();
a.x();
のとき、もし条件が非Ｊだったら何が起こるの？
そこが良くわからない。
0036デフォルトの名無しさん
2005/10/28(金) 00:03:31必ず、「S *s=S_Factory()；」としたいところなんですが
> A a = new A();
> a.x();
の場合は、何も起こらない、としたいです
0037デフォルトの名無しさん
2005/10/28(金) 00:29:57S *s = new A();
s->x();
かつ非Ｊの時には何が実行される？
……っていうか、何を想定しているのかさっぱり分からん
0038デフォルトの名無しさん
2005/11/06(日) 15:17:33途中参加で申し訳ないが派生クラスＡ、Ｂ、Ｃ、Ｄいらないんじゃないの？
要はX１、X２、Y１、Y２をJ、Kで使い分ければいいだけなんだろ？
内部クラスにするかどうかは別として、javaだと以下のような感じで行けないか。
interface Exe { public void exec(); }
public class S {
private Exe x1 = new Exe() { public void exec() { /* x1 */ } };
private Exe x2 = new Exe() { public void exec() { /* x2 */ } };
private Exe y1 = new Exe() { public void exec() { /* y1 */ } };
private Exe y2 = new Exe() { public void exec() { /* y2 */ } };
public void x() { if (J) x1,exec(); else x2.exec(); }
public void y() { if (K) y1,exec(); else y2.exec(); }
}
0039デフォルトの名無しさん
2005/12/19(月) 22:34:49最近はPHPでの仕事がほとんどです．
oopバージンな僕が，oopを正しくマスターするためには，PyかJどちら
から始めたらいいでしょうか．
アドバイスをお願いします．
友人からはSを進められたりしたんですが，
ちょっと調べてみたら変態的なのと使える場が少なそうなので，
やはり，すこしは実用性のあるPyかJをやりたいと思います．
よろしくお願いします．
0040デフォルトの名無しさん
2005/12/19(月) 22:37:010041デフォルトの名無しさん
2005/12/19(月) 22:45:50Rは不吉臭がする
0042デフォルトの名無しさん
2005/12/19(月) 22:49:490043デフォルトの名無しさん
2005/12/19(月) 22:58:360044私もoopチェリー
2005/12/19(月) 23:10:23新たに覚えるシンタックスも少ないし、書籍が豊富。
0045デフォルトの名無しさん
2005/12/19(月) 23:14:420046デフォルトの名無しさん
2005/12/19(月) 23:46:030047デフォルトの名無しさん
2005/12/20(火) 00:02:59入出力あたりはともかくとして<stdlib.h>あたりはmalloc系以外C++でも<cstdlib>と名を変えながらも重宝する。
0048デフォルトの名無しさん
2005/12/20(火) 22:40:000049デフォルトの名無しさん
2005/12/20(火) 23:13:19Smalltalk？
0050デフォルトの名無しさん
2005/12/20(火) 23:19:12>>49が正解か。
0051デフォルトの名無しさん
2005/12/25(日) 20:57:23さあ突っ込めヽ( ´ー｀)ノ
0052デフォルトの名無しさん
2005/12/25(日) 21:00:060053デフォルトの名無しさん
2005/12/29(木) 17:30:40ちょっとは風通しも良くなるんじゃないだろうか。
案外ブランチして本家抜きで開発が進んだりしてな。
0054デフォルトの名無しさん
2005/12/30(金) 09:50:21今はもうほとんど人ができると考えていいのでしょうか？
0055デフォルトの名無しさん
2005/12/30(金) 10:18:54分野にもよりますが、残念な事にまともにOOPできている人間はごく少数です。
OOの習得は、基礎概念を学んだ後「アジャイルソフトウェア開発の奥義」と「リファクタリング」、GOF本くらい読んでおけば
容易なはずですが、大半のプログラマは何百ページもある字ばっかりの本を読めるほど頭が良くありません。
0056デフォルトの名無しさん
2005/12/30(金) 11:12:38回答ありがとうございます。
やっぱりまだ敷居は高いんですね。
0057デフォルトの名無しさん
2005/12/30(金) 18:20:53463 名前： 仕様書無しさん 投稿日： 2005/12/29(木) 19:36:23
>>461
http://tito.fc2web.com/2ch/tech/index.html
http://tito.fc2web.com/2ch/tech/index.html#d0e2176
憂鬱なプログラマのためのオブジェクト指向開発講座 ― C++による実践的ソフトウェア構築入門
Tucker (著)
翔泳社(1998) ISBN:4-8813-5619-4
デザパタはあくまでパターンなのでオブジェクト指向の理論とは関連が薄いから
実質2ch一番人気のオブジェクト指向本となる。
別スレで同じような質問あった。
どうせなら一番人気の本教えとく。
0058デフォルトの名無しさん
2005/12/30(金) 21:48:09サンクスです。
レビュー評価いいですね。
0059デフォルトの名無しさん
2005/12/31(土) 05:09:46憂鬱本はタイトルの割にぜんぜん実践じゃない。あくまでもOOの基礎概念について説明した本。
｢アジャイルソフトウェア開発の奥義｣マジおすすめ。
0060デフォルトの名無しさん
2006/01/10(火) 22:24:39ってゼミの教授に聞かれたから、抽象って答えたんだけど間違ってた？
0061デフォルトの名無しさん
2006/01/11(水) 00:14:370062デフォルトの名無しさん
2006/01/11(水) 11:13:58長い？
0063デフォルトの名無しさん
2006/01/11(水) 12:26:40てか、一言でってのが無茶な質問な気がする。
0064デフォルトの名無しさん
2006/01/11(水) 12:52:320065デフォルトの名無しさん
2006/01/11(水) 12:56:460066デフォルトの名無しさん
2006/01/11(水) 16:38:550067デフォルトの名無しさん
2006/01/11(水) 18:59:300068デフォルトの名無しさん
2006/01/11(水) 19:41:500069デフォルトの名無しさん
2006/01/15(日) 17:35:51オブジェクト単位でわけりゃオブジェクト指向でしょ？
何をオブジェクトとするか？抽象的かどうか？
ってのはあくまで設計が上手い下手の話になるから違うんじゃない？
例えば、ただの関数一覧をオブジェクトとしてまとめてもそいつがオブジェクトと言えば
オブジェクト指向でいいんじゃね？（設計的にいいとか悪いとかはおいておいて）
0070デフォルトの名無しさん
2006/01/15(日) 22:18:08オブジェクト単位に分けるってことも現実の抽象化ってことだし
当然、設計段階での抽象化もあるし、色んなレベルでの抽象ってのが
オブジェクト指向の核となってるんじゃないかと思って「抽象」と言ったんだけど。
まぁ、屁理屈ですね…
0071デフォルトの名無しさん
2006/01/16(月) 01:01:42責任の分割と明確化
>66と似ているけどちょっと違う
0072デフォルトの名無しさん
2006/01/21(土) 00:16:00>責任の分割と明確化
それは設計で「そうあるべき」って内容であって本質じゃないな。
0073デフォルトの名無しさん
2006/01/21(土) 01:19:21007471
2006/01/21(土) 02:51:57「そうあるべき」という理想も本質の一つだと思うけど？ 唯一の本質とは言わんけどね。
0075デフォルトの名無しさん
2006/01/27(金) 00:01:09一度慣れるとオブジェクト指向以外でプログラム書けなくなりますね。
もっとも私がオブジェクト指向で書けるようになるまで4年もかかってしまったが。
とにかく、意味が分からなくとも説明書なり他人のコードを参照して沢山コードを書け。
そうすれば、いつかオブジェクト指向の考え方というものを理解できるであろう。
0076デフォルトの名無しさん
2006/02/04(土) 01:46:24高凝集度と疎結合
0077デフォルトの名無しさん
2006/02/27(月) 02:39:53処理はバンバン書き込んじゃっていいの？
1つ上の、ファサードとかサービスって言われる層に、処理が集中しがちなんだが
まだまだ勉強不足なのかなぁ・・・
0078デフォルトの名無しさん
2006/02/28(火) 14:07:08＞ドメインとかビジネスオブジェクトといわれる層にはそのクラスに関連する
＞処理はバンバン書き込んじゃっていいの？
まず例を出せ、話はそれからだ。
0079デフォルトの名無しさん
2006/03/11(土) 00:48:16ファウラーがドメインオブジェクトにバンバン書き込めって
いってるから俺はそうしてる。
なにしろサービスよりドメインのほうがテストケース書きやすいし。
0080デフォルトの名無しさん
2006/04/16(日) 14:15:560081デフォルトの名無しさん
2006/06/13(火) 00:56:01脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html
このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpin
0082デフォルトの名無しさん
2006/06/25(日) 22:46:390083デフォルトの名無しさん
2006/07/01(土) 00:08:16↓
単純なモジュールの集合体にすればメンテが容易になる（構造化）。
↓
変数と、それを扱う関数をひとまとめにして独立性を高める（カプセル化）。
↓
モジュールの機能を賢くすれば、コードを書き換えずに再利用できる（ちょっと肥大化）。
↓
コードを書き換える必要がない≒コードを書き換えてはいけないという雰囲気になり、
モジュールに機能を追加したい場合はクラスを継承する（さらに肥大化）。
↓
プロジェクトの途中で仕様が変更になったが、それまで使っていたクラスは充分テストされており、
書き換えるとまたテストし直さなければいけないので、継承して新たなクラスを作る（たかが肥大化）。
↓
次期プロジェクトでも、それまで使っていたクラスを継承して実装する（されど肥大化）。
↓
基底クラスでバグが見つかる。
↓
クラスを継承してなんとか帳尻合わせをする（もうなんでもいいやって感じで肥大化）。
↓
こっちが立てばあっちが立たずで、また問題が発覚する。
↓
やっぱり基底クラスから根本的に直さなければいけないのでは？
↓
でもそうすると継承したクラスが全部影響受けちゃうじゃない？
↓
身動きがとれなくなる。
↓
納期が迫ってくる。
↓
担当者が行方不明になる。
0084デフォルトの名無しさん
2006/07/01(土) 00:10:03代わりにボンクラ投入。
↓
１から仕事を教えてやる必要あり。
↓
コードをさんざん汚して、ボンクラ去って行く。
↓
ボンクラ作戦失敗。
↓
外注に丸投げ。
↓
外注が火を噴く。
↓
チョン企業に丸投げ。
↓
法則発動。
↓
バグはなかったことにして日程優先でとにかく納品。
↓
不具合発覚。
0085デフォルトの名無しさん
2006/07/01(土) 00:10:35記者会見。
↓
他社に責任転嫁。
↓
国会に呼ばれる。
↓
信用失墜
↓
売上大幅減
↓
株価下落
↓
株主総会
↓
粉飾決算
↓
タイーホ
↓
再就職できず
↓
生活苦
↓
消費者金融
↓
多重債務
↓
中央線
途中まではマジ。
いったいどこで方向を誤ったのだろうか。
0086デフォルトの名無しさん
2006/07/01(土) 00:40:540087デフォルトの名無しさん
2006/07/01(土) 07:39:49せめて青木ヶ原しか1人静かになれるところにして。
0088デフォルトの名無しさん
2006/07/01(土) 11:03:190089デフォルトの名無しさん
2006/07/01(土) 23:01:04それ以降はネタというか、希望的観測ならぬ、自虐的観測です。
幸い、うちにはチョン語を話せる人がいないので、
そこから下に進まずに済んでいます。
日本語が通じる代理店みたいなものはないのかとか、いろいろ模索しましたが、
「日本企業でも火を噴くのに、国民性が異なる人に依頼できるのか」ということになり、
結局その時点でプロジェクトはポシャりました。
まぁ教訓としては、
(1)闇雲にクラス継承を重ねないこと
(2)「コードを書き換えずに流用」にあまりこだわらないこと
(3)複雑なクラスにドキュメントがないのは最悪なこと
とくに(2)は、チェック項目を減らすことが目的だったはずなのに、
コード書き換えを回避するために継承を重ね、
結果的にチェック項目が増えてしまい、本末転倒でした。
■ このスレッドは過去ログ倉庫に格納されています