オブジェクト指向・嗜好・試行・至高・歯垢・伺候

オブジェクト指向を激しく嗜好したり、
オブジェクト指向を何度も試行したり、
オブジェクト指向は至高のものだと考えたり、
オブジェクト指向は歯垢のように無駄だと思う人が
オブジェクト指向に伺候する人に喧嘩売ったりするスレです。


前スレ

オブジェクト指向・嗜好・試行・至高・歯垢
http://pc8.2ch.net/test/read.cgi/tech/1049778124/l50

誰も立てないので立てました。
重複していましたら、削除依頼をお願いします。

結局ポリモいらない君は世界に１つだけのオブジェクト

>>前スレ998
strategy くらい分かってるよヽ(｀Д´)ノ
強引に全部まとめようとすると失敗しやすいってことを言っただけだよ。

っていうか、ミサイルをまとめるとか言い出したのは俺じゃないよ｡･ﾟ･(ﾉД`)･ﾟ･｡

>>3
まあ、無理な一般化をするなというのには同意。
で、そんな例を持ち出して何を言いたかったのやら。

うまくポリモーフィズムを使えれば
場合によっては使われない無駄な変数を持たなくて良かったり
分散しがちな条件分岐をまとめられたりする。

>>4
文章読んでるとなんかＣ言語的なメモリコスト寄りの発想だな。
ポリモいらない君じゃないけどそれってオブジェクト指向なんかな。

>>5
んー、そういう言い方の方がポリモいらない君には分かりやすいと思って。
C言語的メモリコストというより、データベースの正規化の話に近いかも知れない。

>>6
オブジェクト指向とはちょっと離れるってこと？

>>7
継承の is-a 関係により子クラスを親クラスと同一化することによって、脳内メモリを節約することが目的。

>>7
必ずしもそうとは言えないんじゃないかな。
どういう単位でオブジェクト(ないしクラス)を分割すればいいか、
オブジェクト同士がどういう関連を持てばいいのか、という話につながるし。
ある程度正規化されていた方がスッキリはする。良いか悪いかはケースバイケースだけど。

>>8
継承の仕組みはわかるけど。
使い方がＣ言語的に見るのだけど。

>>10
なぜ

>>11
だって、始めに設計ありきじゃない？
うまくまとまるかどうかは結果であって目的じゃないと思うのだけど。

>>12
ええと、それがC言語的なの？

> うまくまとまるかどうかは結果であって目的じゃないと思うのだけど。

現実主義的で共感しなくもないのだけど、何をもってうまくまとまるとするかに寄るし、
うまくまとめる必要を感じることはあるかな。

>>13
じゃあ、前スレのホーミングミサイルとミサイルってどういう扱いになるの？

987
おいらはパターン２（粒度を荒くする）パターンが好きですな。
荒いスケールを基本クラスにして、詳細は派生クラス群で実装。
（クラス間の処理はコールバックとかシグナルで対応）
VCLとかwxWidgetとかメジャーなGUIフレームワークはそうかな？

……ただ、こんな重たいフレームワーク作るのは大変だから、
〆切のキツい時は無理だろうな……

>>14
前スレ987-988の話？　それともその前にやっていたやつの話？
何についてかよく分からないのではっきりとした事は言えないけど、
そのゲームには非ホーミングミサイルとホーミングミサイルしか無いの？
その他の分類は一切無いの？
非ホーミングミサイルは追跡対象が無いホーミングミサイルと考えてもいいの？
そこまで単純ならわざわざ分ける必要は無いんじゃない？

大事なのは対象となる問題領域内で一般化できそうかを判断する事。
その問題領域が曖昧だとなかなか難しいけどね。
特にゲームなんか「その方が面白いから」と言う理由で簡単に変わってしまう。
だから一度判断した事を変更していく手法（リファクタリングとか）が注目される。

っていうか何で俺に聞くんだろう。

>>16
>っていうか何で俺に聞くんだろう。
たまたまいたからｗ

オブジェクト指向的な設計をしてから、一般化だと思うんだけど。
設計をした時点だとホーミングミサイルとミサイルってどういう扱いになるの？

>>17
設計にもよるんじゃない？　答えは１つじゃないだろう。

>>17
どんなゲームなのか詳しく分析するのが先です(笑)
ごめん、もっと続けたいけど俺はもう寝る。

ミサイルがスーパクラスなるか、ミサイルにセンサーオブジェクトを委譲させるか

oOoゲームの設計について語るスレoOo
http://pc8.2ch.net/test/read.cgi/gamedev/1005576459/

ミサイルって、、弾幕ライブラリってあるだろ？
あれ使えよ

基底クラスＳがあって、其処からの派生クラスＡ、Ｂ、Ｃ、Ｄが
あるとする
s.x（）とすれば
ある条件Ｊの時は、Ａ・ＢにメソッドＸ１を
非Ｊの時は、Ｃ・ＤにメソッドＸ２を使いたい
また、s.y（）とすれば
ある条件Ｋの時は、Ａ・ＣにメソッドＹ１を
非Ｊの時はＢ・ＤにメソッドＹ２を使いたい

この場合、どう暮らす設計すれば良いんだろう？

間違えた
○
ある条件Ｋの時は、Ａ・ＣにメソッドＹ１を
非Ｋの時はＢ・ＤにメソッドＹ２を使いたい

>>23
Mediatorパターン？

条件が良くわかんないが、１行目はクラス設計とは言わんのか？
１行目がやたら問題を難しくしているんだが。

ちなみに java に限定すれば S.x() と S.y() は A, B, C, D でオーバーライドされるから、S の x() が実行されるとは限らない。
C++ or C# で x(), y() を非 vertual にすれば良いんだけど。

ん？　上手く読み取れて無い予感。

＞Ａ・ＢにメソッドＸ１
ってコレは a.x1() に b.x1() のことか？
Ａ・Ｂのインスタンスは誰が持ってるんだ？それとも this なのか？

メソッドＸ１は同じ振る舞いをします

クライアント側のコードが
S　*s=S_Factory()；
s.x()；
の時に・・・・って感じです

C++風だと
s->x();
ですね。
>>28はjavaとごっちゃになってる　orz

C++ か。

＞S　*s=S_Factory()；
この S_Factory は、ABCDS のいずれかを返すの？
んで、

＞s->x();
は、結局どういうときに x1, x2 に分岐するの？

＞条件が良くわかんないが、１行目はクラス設計とは言わんのか？
メソッドX/Yをどこに持たせれば良いか？
とか、もっと踏み込んで、ABCDの継承関係を見直すべきか？
とかです。

>>31
メソッド x, y は S にあるんじゃないの？

＞この S_Factory は、ABCDS のいずれかを返すの？
YES

＞は、結局どういうときに x1, x2 に分岐するの？
簡略化の為、「bool　::isｋ()」の 戻り値で分岐とします

>>32
そうするならば
条件Ｊ・Ｋの時に、ABCDは、どうすれば良いか？？って事です

>>34
A a = new A();
a.x();

のとき、もし条件が非Ｊだったら何が起こるの？
そこが良くわからない。

>>35
必ず、「S　*s=S_Factory()；」としたいところなんですが
> A a = new A();
> a.x();
の場合は、何も起こらない、としたいです

んじゃもう１個質問

S *s = new A();
s->x();

かつ非Ｊの時には何が実行される？
……っていうか、何を想定しているのかさっぱり分からん

>>23
途中参加で申し訳ないが派生クラスＡ、Ｂ、Ｃ、Ｄいらないんじゃないの？
要は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(); }
}

CとLispとPHPを主に使っています．
最近はPHPでの仕事がほとんどです．

oopバージンな僕が，oopを正しくマスターするためには，PyかJどちら
から始めたらいいでしょうか．
アドバイスをお願いします．

友人からはSを進められたりしたんですが，
ちょっと調べてみたら変態的なのと使える場が少なそうなので，
やはり，すこしは実用性のあるPyかJをやりたいと思います．

よろしくお願いします．

Rにしとけ

その中ならPyかな
Rは不吉臭がする

pyってドキュメント読みにくくね？

C++にでもしとけ

Javaがいいんじゃないの？
新たに覚えるシンタックスも少ないし、書籍が豊富。

C++なら実際にプログラムを作るときにいざとなればCの書き方へ逃げられる。

にげるんじゃない

書き方で逃げないとしてもライブラリを１から知りなおす必要が無いというのは悪くない。
入出力あたりはともかくとして<stdlib.h>あたりはmalloc系以外C++でも<cstdlib>と名を変えながらも重宝する。

Rはやっぱり教祖様にぬかずくカルトだから？

ごめん、Sって何？
Smalltalk？

Schemeかと思ってたがよく考えたらあんまりOOじゃねえな。
>>49が正解か。

Subjective-C

さあ突っ込めヽ( ´ー｀)ノ

いやぁ、おれS言語だとばっかり思ってました

Rubyも海外での利用が広まっているようなので
ちょっとは風通しも良くなるんじゃないだろうか。
案外ブランチして本家抜きで開発が進んだりしてな。

プロの方の何割ぐらいがOOPできるのでしょうか？
今はもうほとんど人ができると考えていいのでしょうか？

>>54
分野にもよりますが、残念な事にまともにOOPできている人間はごく少数です。
OOの習得は、基礎概念を学んだ後「アジャイルソフトウェア開発の奥義」と「リファクタリング」、GOF本くらい読んでおけば
容易なはずですが、大半のプログラマは何百ページもある字ばっかりの本を読めるほど頭が良くありません。

>>55
回答ありがとうございます。
やっぱりまだ敷居は高いんですね。

>>56
463 名前： 仕様書無しさん 投稿日： 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一番人気のオブジェクト指向本となる。

別スレで同じような質問あった。
どうせなら一番人気の本教えとく。

>>57
サンクスです。
レビュー評価いいですね。

>>57
憂鬱本はタイトルの割にぜんぜん実践じゃない。あくまでもOOの基礎概念について説明した本。
｢アジャイルソフトウェア開発の奥義｣マジおすすめ。

オブジェクト指向って一言で言ってどういうこと？
ってゼミの教授に聞かれたから、抽象って答えたんだけど間違ってた？

俺だったら『現実世界のモデル化手法』で済ます。賛否あるだろうが。

メッセージのやりとりにより進行するプログラミング手法

長い？

今時のノウハウ集

てか、一言でってのが無茶な質問な気がする。

隠蔽と操作

情報隠蔽と情報操作

役割分担

概念によるプログラムの切り分け

>>66に1票

>>60
オブジェクト単位でわけりゃオブジェクト指向でしょ？
何をオブジェクトとするか？抽象的かどうか？
ってのはあくまで設計が上手い下手の話になるから違うんじゃない？
例えば、ただの関数一覧をオブジェクトとしてまとめてもそいつがオブジェクトと言えば
オブジェクト指向でいいんじゃね？（設計的にいいとか悪いとかはおいておいて）

>>69
オブジェクト単位に分けるってことも現実の抽象化ってことだし
当然、設計段階での抽象化もあるし、色んなレベルでの抽象ってのが
オブジェクト指向の核となってるんじゃないかと思って「抽象」と言ったんだけど。
まぁ、屁理屈ですね…

>60
責任の分割と明確化
>66と似ているけどちょっと違う

>>71
>責任の分割と明確化
それは設計で「そうあるべき」って内容であって本質じゃないな。

契約プログラミング

>72
「そうあるべき」という理想も本質の一つだと思うけど？ 唯一の本質とは言わんけどね。

オブジェクト指向とはプログラマとして解脱することなり。
一度慣れるとオブジェクト指向以外でプログラム書けなくなりますね。
もっとも私がオブジェクト指向で書けるようになるまで4年もかかってしまったが。

とにかく、意味が分からなくとも説明書なり他人のコードを参照して沢山コードを書け。
そうすれば、いつかオブジェクト指向の考え方というものを理解できるであろう。

>>60
高凝集度と疎結合

ドメインとかビジネスオブジェクトといわれる層にはそのクラスに関連する
処理はバンバン書き込んじゃっていいの？
1つ上の、ファサードとかサービスって言われる層に、処理が集中しがちなんだが
まだまだ勉強不足なのかなぁ・・・

>>77
＞ドメインとかビジネスオブジェクトといわれる層にはそのクラスに関連する
＞処理はバンバン書き込んじゃっていいの？

まず例を出せ、話はそれからだ。

>>77
ファウラーがドメインオブジェクトにバンバン書き込めって
いってるから俺はそうしてる。
なにしろサービスよりドメインのほうがテストケース書きやすいし。

object is poormans closer!!!!!!!!!!!!

トラックバック:http://app.blogs.itmedia.co.jp/t/trackback/4088073

脱オブジェクト指向のススメ
ttp://blogs.itmedia.co.jp/tamaki/2006/06/post_57ab.html


このイーキャッシュの代表取締役玉木の発言がおかしいから
このスレからpin

どうおかしいのか具体的に言ってみたまえ。

ソフトを多機能化しようとすると構造が複雑になる。
　　↓
単純なモジュールの集合体にすればメンテが容易になる（構造化）。
　　↓
変数と、それを扱う関数をひとまとめにして独立性を高める（カプセル化）。
　　↓
モジュールの機能を賢くすれば、コードを書き換えずに再利用できる（ちょっと肥大化）。
　　↓
コードを書き換える必要がない≒コードを書き換えてはいけないという雰囲気になり、
モジュールに機能を追加したい場合はクラスを継承する（さらに肥大化）。
　　↓
プロジェクトの途中で仕様が変更になったが、それまで使っていたクラスは充分テストされており、
書き換えるとまたテストし直さなければいけないので、継承して新たなクラスを作る（たかが肥大化）。
　　↓
次期プロジェクトでも、それまで使っていたクラスを継承して実装する（されど肥大化）。
　　↓
基底クラスでバグが見つかる。
　　↓
クラスを継承してなんとか帳尻合わせをする（もうなんでもいいやって感じで肥大化）。
　　↓
こっちが立てばあっちが立たずで、また問題が発覚する。
　　↓
やっぱり基底クラスから根本的に直さなければいけないのでは？
　　↓
でもそうすると継承したクラスが全部影響受けちゃうじゃない？
　　↓
身動きがとれなくなる。
　　↓
納期が迫ってくる。
　　↓
担当者が行方不明になる。

　　↓
代わりにボンクラ投入。
　　↓
１から仕事を教えてやる必要あり。
　　↓
コードをさんざん汚して、ボンクラ去って行く。
　　↓
ボンクラ作戦失敗。
　　↓
外注に丸投げ。
　　↓
外注が火を噴く。
　　↓
チョン企業に丸投げ。
　　↓
法則発動。
　　↓
バグはなかったことにして日程優先でとにかく納品。
　　↓
不具合発覚。

　　↓
記者会見。
　　↓
他社に責任転嫁。
　　↓
国会に呼ばれる。
　　↓
信用失墜
　　↓
売上大幅減
　　↓
株価下落
　　↓
株主総会
　　↓
粉飾決算
　　↓
タイーホ
　　↓
再就職できず
　　↓
生活苦
　　↓
消費者金融
　　↓
多重債務
　　↓
中央線

途中まではマジ。
いったいどこで方向を誤ったのだろうか。

多重債務までマジなのね・・・あと賽の目1を出せば楽になれるよ

中央線は迷惑だからやめてくれ。
せめて青木ヶ原しか1人静かになれるところにして。

マグロになると足止め食らって迷惑する人多いからね。

実際は外注までです。
それ以降はネタというか、希望的観測ならぬ、自虐的観測です。
幸い、うちにはチョン語を話せる人がいないので、
そこから下に進まずに済んでいます。
日本語が通じる代理店みたいなものはないのかとか、いろいろ模索しましたが、
「日本企業でも火を噴くのに、国民性が異なる人に依頼できるのか」ということになり、
結局その時点でプロジェクトはポシャりました。

まぁ教訓としては、
(1)闇雲にクラス継承を重ねないこと
(2)「コードを書き換えずに流用」にあまりこだわらないこと
(3)複雑なクラスにドキュメントがないのは最悪なこと

とくに(2)は、チェック項目を減らすことが目的だったはずなのに、
コード書き換えを回避するために継承を重ね、
結果的にチェック項目が増えてしまい、本末転倒でした。