07/09/08 19:28:12
>>711 逃げ( ´,_ゝ`)ﾌﾟッ
714:仕様書無しさん
07/09/08 19:30:43
>>713
いいぜ、別にｗ
俺、お前がオブジェクト指向理解できなくても全然困んねーもんｗ
715:仕様書無しさん
07/09/08 19:31:43
この程度のことでビビって逃げるようじゃだめだぞ。
716:仕様書無しさん
07/09/08 19:34:18
今日は煽りに来ただけだしなｗ
昔、みたスレどうなってるかなｗと
まあ、よく見たら昔みたスレはこっちじゃなかったんだけどなｗ
717:仕様書無しさん
07/10/05 13:53:52
privateの必要性がよう分からない
getter、setterでアクセスするなら同じだろ
718:仕様書無しさん
07/10/05 14:37:53
アクセッサを介すんだから、そこで色々できるでしょ。
int getValue() {
return hoge && huga && hage ? _value : -1;
}
だとか。
719:仕様書無しさん
07/10/05 15:43:12
>717
全部publicで書かれたコードを一度でも触れば、いかに糞かがわかる。
720:仕様書無しさん
07/10/05 22:14:59
>>717
破滅の序曲を聞いたｗ
過去何人がそれで死んだことかｗ
まあ、体験するしかないと思う
721:仕様書無しさん
07/10/05 22:28:21
class A
{
private:
int hoge;
public:
void SetHoge(int newHoge)
{
if ( newHoge < 0 )
{
hoge = 0;
} else if ( newHoge > 150 )
hoge = 150;
}
}
};
int main()
{
A a;
// a.hoge = 2000;
a.SetHoge(2000);
return 0;
}
722:仕様書無しさん
07/10/05 22:30:55
if ( newHoge < 0 )
{
hoge = 0;
} else if ( newHoge > 150 )
hoge = 150;
} else {
hoge = newHoge;
}
723:仕様書無しさん
07/10/06 10:00:39
>>717
構造体を先に作って、ほとんど全てのメンバに getter/setter を書くようなら、メリットは少ないかもね。
これは逆で、クラスとしてのインターフェースを先に書いてから、実装に必要なメンバを追加していく。
それで getter/setter ばかりになっても、それは結果。
724:仕様書無しさん
07/10/06 10:32:00
そうそう
この変数はこの関数を通してしかアクセスされませんよ
（する必要がありませんよ、した場合の動作は意図していませんよ・・・等）
って制限を与えることによってプログラムの構造を単純にするのが本当の役目なんだよな
メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない
クラスの仕様として外部からアクセスする必要がないことを明示的にするためのもんといった方がわかりやすいだろうか？
setだけのもんがあってもいいし、getだけのもんも当然ある
725:仕様書無しさん
07/10/06 13:13:13
> メンバの変数全部にsetget作りまくるのはアフォ、なんもわかってない
クラスを、データの入れ物と機能とに完全に分離したがる人は多いけど
だいたいこのパターンだな
726:仕様書無しさん
07/10/06 15:53:27
セッターなんて、いつ変更されても構わないものしか付けられないし
ゲッターでもオブジェクトとか配列の公開は、実質的に変更出来ることが多いので怖い
その「怖い」という発想が出てこないのが OOP に浸かった俺には不思議なんだ
本当に公開にできるフィールドなんて極々一部だと思うんだぜ
727:仕様書無しさん
07/10/06 17:06:11
Hiroyuki = new Hiroyuki();
は、解るんですが、
Person someone = new Hiroyuki();
が、良くわかりません。
出来る、というのは解るんですが、これをやると何がどう得になるんでしょうか。
728:727
07/10/06 17:35:30
すいません。下の間違いです。。
Hiroyuki hiroyuki = new Hiroyuki();
729:仕様書無しさん
07/10/06 17:58:10
#include <iostream>
class Person {
public:
virtual void SayName(void) const = 0;
};
class Hiroyuki : public Person {
public:
void SayName(void) const { std::cout << "My name is Hiroyuki" << std::endl; }
};
class Takumi : public Person {
public:
void SayName(void) const { std::cout << "My name is Takumi" << std::endl; }
};
int main() {
Person *p[2] = {0};
p[0] = new Hiroyuki;
p[1] = new Takumi;
for (int i = 0; i < 2; i++)
{
p[i]->SayName();
delete p[i];
}
return 0 ;
}
730:仕様書無しさん
07/10/06 18:05:04
>>728
改行多すぎって怒れれたから変なフォーマットになってしまったけど、
注目すべきは p[i]->SayName();。
実装されてないPersonのメンバ関数を使ってるけど、実行結果はこうなる。
My name is Hiroyuki
My name is Takumi
実際呼ばれているのはHiroyukiとTakumiのSayName()が呼ばれる。
異なるクラスのメンバ関数を同じ形で呼び出しているということ。
つまり、呼び出す側を共通化できる点が便利ってことかな。
731:727
07/10/06 21:17:26
>>730
レスありがとうございます。
説明で何となく解ったのですが、どんな場面で使うんでしょうか。
上の通り、と言われれば確かにそうだとは思うんですが、何となくまだ自分の中で理解が漠然としていまして。。
732:仕様書無しさん
07/10/06 21:46:17
>>731
これはポリモーフィズムとか多態性と呼ばれている性質です。
わたしよりずっと説明の上手な人がいろいろ書かれているので、
Googleなどで検索して調べてみて下さい。
例えばこんなのはどうかな。コードの例がさっきはC++で、これのはJavaですが・・
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
733:仕様書無しさん
07/10/06 21:51:41
例えば、読む負担が軽くなる。
List を派生させた AbstractList, ArrayList, LinkedList, Vector があったとき、
ArrayList arraylist = new AbstractList();などとする場合に比べ、
List list = new ArrayList();などとした場合は、
「具体的な実装について考えなくていいよ、
Listのことだけはともかくするよ」という読み方になる。
新しく何か定義したときも、
List list = new AtarasikuNanikaList();
これから下のソースは、以前Listとしてそのまま使える。
また、メソッドの引数で考えた時に、
void printList(LinkedList linkedlist)とした場合にくらべ、
void printList(List list)とした場合には、
obj.printList(new ArrayList())や、obj.printList(new Vector());
としても呼べる。
具体的な例を見つめながらプログラミングをするのは負担になる。
抽象化して、インタフェースに対してプログラミングできれば、
読む負担が減ったり、実装を入れ替えたりできてうれしい。
734:仕様書無しさん
07/10/06 22:55:42
>>731
まあ、普通に考えてお前がよくわからんと思ったのと
同じように他の奴も思うわけだ
こういうソースの書き方が業務で使われてたのは俺はみたことないけどな
ソースは他人が読めてナンボだと思うぜ
もちろん読む側のスキルをある程度要求することもあるがな
てか、これはスキルっていうよりあらかじめ実装の対象物の構造が頭に入ってる奴で
かつ、こういう組み方を日常にしてる奴しかこのソースは読め無いと思うんだ
かなり読める人間を限定してしまうと思うぜ
実際この構造を知らずにこのソースの構造から対象物の構造を理解するって話になると
かなり困難だと思うのは俺だけだろうか？
735:sage
07/10/06 23:25:56
>>731
うんこの色したボタンとちんこの色したボタンがある
どっちもボタンなんで動作は基本的に同じ。
これらのボタンをウインドウに配置するための
setButtonという関数があったとする
もし抽象クラスを用いないのなら
setButton(うんこボタン button);
setButton(ちんこボタン button);
という二つのメソッドをつくらんとならないが、うんこボタンとちんこボタンがボタンという抽象クラスから継承されていれば
setButton(ボタン button);
というメソッドがあるだけで、
ボタン button1 = new うんこボタン();
ボタン button2 = new ちんこボタン();
setButton(button1); //OK
setButton(button2); //OK
となるだろ？
さらに、小島よしおボタンとかアサヒスーパードライボタンとか、ボタンの数がものすごい増えていったとき
オーバーロードで解決しようとすると、ボタンの種類の数だけ関数書かなきゃならんけど、
抽象クラスにしておけば、ボタンをうけとる関数を書くだけでOK
素敵じゃね？
736:仕様書無しさん
07/10/06 23:28:02
クラスライブラリだと、ふつーに使われてるだろ?
SQL Server用の SqlConnection や SqlCommandをnewしてるけど、
ロジックはIDbConnection や、IDbCommandを使って組んで、ほかのDBになっても対応できるようにするとか。
737:仕様書無しさん
07/10/06 23:34:54
>>736
一般的に普及されてて使い方に特に解説がいらないもんならそうだけどね
自分ライブラリで自分仕様のクラスまでそうやって作ってしまっていいのかどうなのかってのは判断できんな
仕様書書いてどこまで説明できるか？ってところじゃない？
ソースそのまま渡して理解はされないと思う
738:仕様書無しさん
07/10/07 00:12:14
>>735
色は継承じゃなくてボタンの属性でよくね？ 白いちんこの奴もいれば、黒光りしてる奴もいるだろうし。
うんこにしたって(以下自粛...
739:仕様書無しさん
07/10/07 01:49:25
この場合属性でいいんだが、物のたとえだよ
それにしたってボタンの上をドラッグしまくるとだんだんおっきくなるボタンかもしれないし、調子が悪いと水みたいになるボタンかもしれないじゃん？
……まじめな話するとMFCデフォのボタンとオーナードローのボタンとか、ラジオボタンとチェックボックスとか、そういう意味での違いということでひとつお願いします
740:仕様書無しさん
07/10/07 02:36:43
現実的な話をするとクラスをメンバの変数でもつようにしたほうが経験上うまくいく
ＭＦＣみたいに構造から継承使うように作ってあったらそれに従うしかないけどな
継承すると同名の関数のくせに別の動作をするもんが大量に派生することになる
どれを呼び出してどの関数を通っているのか把握するのがかなり困難になってしまうところも注意
継承は実装の手間が減るだけでそれほどいい技術じゃない
大規模になるほど使わないほうがうまくいく場合のほうが俺は多いと思う
それと別に継承を使うやり方だけに言えることじゃないけど
あんまり部品を使いまわすとその部品が不良品だったときの影響力はあまりにもでかい
その部品の信頼度とかも考慮して、この辺もよく考えたほうがいいところ
741:仕様書無しさん
07/10/07 03:04:37
>>727
これはようするに抽象化とか一般化とかいうやつだ。
正方形は長方形の特殊なありかたで、長方形は四角形の特殊なあり方。
正方形より長方形、長方形よりも四角形の方が、より一般的とか抽象的とか言う。
Hiroyuki は Person の一部で、Person は Hiroyuki や Yakin らを一般化（抽象化）したもの。
そして、これらに応じて分類(classify)したものをクラスという。
同じ対象を捉えても、分類の仕方はいくつもある。だから設計は多様で、巧拙があり、より良い設計は困難である。
具体的な例が挙がっているので、それでわかるならそれでいい。
742:仕様書無しさん
07/10/07 08:41:10
>>740
実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
継承の本質的な意味は特定の振る舞いを変えることであって、実装を使いまわすための技術ではないでしょ。
実装を継承するならprivate継承すればいい話で、しかしprivate継承するならコンポジットする(メンバ変数として持つ）方がいいに決まってる
結合度ぜんぜん違うからね。
上記のような意味で継承を否定するなら、それはそもそもオブジェクト指向にそぐわない設計/実装をしているし
そういう環境に身をおいているという意味で不幸だな。
MFCのように特定のイベントを継承して実装するモデルよりJavaのなんちょれリスナーを登録するとかC#のデレゲートでイベントを表すという
コンポジット志向のほうが優れてるが、それだって根底にあるのは継承であって、単純にメンバ変数として持ってるわけじゃない。
イベントっていう基底クラスの振る舞いを変えた何かを持たせるわけだろ。
抽象クラスの振る舞いを再定義するのは、動作は違えど、期待される振る舞いが実装されることが前提で、そのコードの詳細を読まなければプログラムがかけないというのは困った話。
こういう問題は、オペレータオーバーロードでも同じだし、getXとか書いてあるのにXをgetしてくるわけでもないメソッドとかと同じだよ
継承による影響範囲の話も同じで、重複したコードを無くそうと思ったらコンポジットでも構造化でもなんでも、どこかに切り分けるわけだが
それらが不良品だったときの影響範囲も大してかわらん。むしろ利点は不良品だったとき一箇所直せば全部直るというプログラムの基本に話は戻る。
743:仕様書無しさん
07/10/07 09:21:00
>>742
影響範囲の話はリスク管理だろ？
投資で一点投資をしないで分散投資をするときの話と似ている
744:仕様書無しさん
07/10/07 09:23:26
>>742
>実装の手間が減るだけというのは、それこそ実装のための継承であって、本来オブジェクト指向のための継承じゃなくね？
オブジェクト指向の継承って何を狙ってやるもんなの？
メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないものってなに？
745:仕様書無しさん
07/10/07 09:37:53
オブジェクト指向は「考え方」で、それを実装に適用したのが、
プログラミング言語が備えている継承機能（Java の exteds とか）。
でも、この「考え方」は上流工程のモデリングにも適用できる。
オブジェクト指向は目的でなくて手段
746:仕様書無しさん
07/10/07 13:19:24
＞メンバ変数でもつ形じゃなくてわざわざ継承をしないと表現できないもの
７４５さんのおっしゃる通り（自分の勝手な解釈が入ってますが・・）、分析を踏まえて実装するわけですから、
継承すべきものは継承し、メンバ変数でもつべきものはメンバ変数でもてばいいのでは？
メンバ変数でもつべきものを継承したり、継承すべきものをメンバ変数でもつべきではないですね。
他にも、関連はメンバ変数（ポインタ）で持つべきものだし。
例えばFileクラスとExcelWorkBookクラスというのがあったとする。
FileがOpenしたり、Saveしたり、Closeしたりできる一般的なファイルをあらわすクラスなら、
ExcelWorkBookはFileを継承する。
一方、ExcelWorkBookに他のファイルを埋め込める機能があれば、埋め込むファイルをFileクラス型メンバ変数で持つ。
ExcelWorkBookが他のファイルとリンクや参照を貼る場合は、それらをFileクラス型ポインタメンバ変数として持つ。
747:仕様書無しさん
07/10/07 17:43:44
>>746
で？なんか長いけど継承すべきものって？何？
748:仕様書無しさん
07/10/07 18:23:28
age
749:仕様書無しさん
07/10/07 18:56:54
>>747
継承はテンプレートメソッドパターンみたいに
サブクラスを実装させつつ型にはめたい場合に使うのがいいかも
750:仕様書無しさん
07/10/07 19:01:13
>>746
実装時の話ならば好きなものをメンバにすればよい。
ただし、インターフェースが先に決まっているのなら。実装からインターフェースが導かれるのは逆。
あと、ExcelWorkBook が File を継承するってのはどうか。
File を引数に取るメソッドが ExcelWorkBook にあるとか、SerializedExcelWorkBook クラスがあるとか、そんなところでは。
リンクも File ではなくもっと抽象的なものだろう。
751:仕様書無しさん
07/10/07 21:26:08
>>743
それはリスク管理でもなんでもない
似たようなコードを色々なところに分散して書くことがリスク管理になるのか？
ようするに基底クラスを変えると影響する範囲が大きいからテストがめんどくせーとかそういう話だろ
そりゃコピペ推奨しているようなもんじゃん。
たしかにコピペで似たようなものが大量にあれば、影響する範囲はそのコピペのうちの１つを使ってる部分だけになるが
他のコピペコードも潜在的にバグを内包しているわけであって、リスクを管理しているわけではなく、見てみぬふりをしているだけ。
いつ爆発するかもわからない爆弾を大量に抱え込んでるようなもんじゃん。
そいつはあんまりよろしくないと思うんだがな
>>744
継承使わなきゃ表現できないものは、後から拡張するとき。
標準入力から入力を受け付けて、それをファイルに出力するクラスがあったとして
入力をTCPやUDPからも受け取れるようにしたい場面に遭遇したとするじゃん
このクラスはもう安定動作しているので修正させないようにしたい場合、またはコンパイル後のバイナリでしか存在させず
そもそも修正できないようにする場合は、そのクラスの使い手側はメンバ変数に持たせることはできないよなそもそも。
だから、そのクラスはもともと外部から拡張できるような構造として設計/実装しておく必要がある。
だけど、そのクラスを作成するときは、いったいどんな入力が増えるのかわからない。
だったらどうするの？
って時は入力ストリームという抽象化されたメンバ変数を持っておいて、あとから入力ストリームを継承したなんらかの入力クラスを渡せるようにしておくようにする
ここには継承が使われているけど、これを継承を使わないでメンバ変数を保持する形でどう表すの？
コードが編集できる場合も同様で、ある特定の動作に対応させたいからとメンバ変数をもこもこ増やし、
そのメンバ変数を使うためのコードをクラスに追加しまくっていったら、馬鹿みたいにでかいクラスになって涙を流すことになる
だから継承とコンポジットをうまく使って正しくコンポーネントとして切り分けておくことが重要ですよ
752:仕様書無しさん
07/10/07 23:33:57
>>751
前半の話はあくまで別の奴が
別の奴の作ったコード（つまり把握できてないコードを）をどこまで使いまわすかって話だぜ
１人の人間がよく知ったコードを使いまわす分には１つでいいんじゃね？
後半の話は後から拡張するときってのはおかしくね？
本来する形があるけどしょうがなく継承を使うっていう風に聞こえるけど
そんな都合で設計がかわってしまうのはおかしいと思うぜ
753:仕様書無しさん
07/10/07 23:36:35
継承による拡張ポイントは、はじめから想定しておく必要がある
これ常識な
754:仕様書無しさん
07/10/08 00:24:56
でも実際問題としてそれは難しい。
最初から無駄に投機的な継承構造とか作りこんでると、
逆ににっちもさっちも行かなくなる場合もある。
755:仕様書無しさん
07/10/08 00:28:40
>>752
あくまで継承でしか表現できない、もしくは表現することが辛い場面の話な
継承は設計段階でするかしないかってのを決めるのが大前提だが744にレスるのに
そういうこといったって、絶対納得しないと思うんだよね
だから、継承でしかできなさそうな場面を上げてみただけ。
継承のほうが優れている場面てのは必ずしも拡張だけではないのは当然だよ
前半の話は、
「このクラスよくわかんないけどとりあえずそれっぽい動作しているから継承して俺カスタムにしてやれ」
と、そういうのを繰り返していると基底クラスのコードが変わったときに破滅するってパターンは確かに駄目だと思うよ
だけど、そういう使い方をするやつが馬鹿で、やっちゃだめな継承NO1だと思うだよね
元の投資の話からすれば、よくわからないけど似たような基底クラスが大量にあるから、リスク管理のためにその大量にある基底クラスからいくらか適当に選んで同じようなサブクラスをいっぱいつくって分散投資しといたほうがいいってことだろ？
それはどうかんがえても妙な話で、そもそもよくわからんクラス使うなってことにならんか？
よくわかってるけど不良品（バグ）があるって場合なら、そのバグを修正すればいいわけで、影響範囲がでかいほうが望ましいと思うんだけど。
756:755
07/10/08 00:32:26
>>755
後半の話は間違い
よくわからないものはそもそも使うなという話でサブクラス云々は関係ありませんでした
757:仕様書無しさん
07/10/08 01:59:13
お前らこんなところで長文かいてる暇があったら書籍の一冊でも余分に読んだほうが身のためだ。
駄文練って悦に入っている間にも刻一刻と残りの寿命と人生の可能性が減り続けているんだぞ。
758:仕様書無しさん
07/10/08 02:18:06
金稼ぎたいなら、能力つけて勝つしかないだろ。
能力無い奴はヒラでも管理職でも将来なんかないよ。
759:仕様書無しさん
07/10/14 09:38:08
>754
そこで共通性・可変性分析ですよ。
>757
そんな757のお薦めの一冊を是非。
760:仕様書無しさん
07/10/14 17:53:55
>>742
おまえさんの話は、一見もっともらしいんだが、
コーディングできねぇ奴の空理空論が一箇所見えている。
イベントクラスって、そもそも単なるデータクラスであって、
あれ自体がイベントを制御してるわけじゃねぇ、
ただハンドラークラスがイベントクラスを認識してるから、
イベントのバリエーションはイベントを実装継承/インタフェース継承しなきゃなんねぇ。
そんな低レベルなミスを犯すお前は口先野郎ケッテェだな
761:仕様書無しさん
07/10/14 18:05:05
こんなとこまで出張して、初心者のあげあしとって喜んでんじゃねえよｗこのブタｗ
762:仕様書無しさん
07/10/14 19:57:07
ろくなコーディング経験も無いままこんな所で講釈垂れてるのは、
初心者どころか
単なる ネットソフィスト、ネット弁慶 の類い
でしょうね。
そんな身の程知らずな輩はズタボロの袋にされて当然かと。
763:仕様書無しさん
07/10/14 21:18:04
きゅん萌えうぜ
764:仕様書無しさん
07/10/14 21:21:07
↑まともな反論もできない
ネット依存性人格荒廃者
765:sage
07/10/14 23:31:15
お前馬鹿か？
イベントに何がくるかわかんねえからイベント自体を分離するための構造としてデレゲートやらなんちょれリスナーがあるんだろ？
インターフェイスだろうがデレゲートだろうがそれらを継承することは間違ってないしオブジェクト指向の考えにのっとってんだろ？
それすらしないでお前全部ifとかswitchで書けってーの？それこそ馬鹿の極みだと思うんだけど。
がんばった所で関数ポインタだろ。関数ポインタつったらデレゲートじゃん。
何のためにWIN32のメッセージディスパッチャがC#のWinFormでイベントベースになったと考えるの？
それのどこがコーディング経験も無いにつながるのかさっぱりわからん
そういうものは実際にはやくにたたないっていいたいの？
ようするにデレゲートもsignal/slotも関数オブジェクトも役にたたないっていいたいの？
766:仕様書無しさん
07/10/14 23:38:28
>>765
横から突っ込むけど、オブジェクト指向と関係あんの？それ？
雑誌の記事に騙されて無い？
言語ってさ、いままで「制限」を付けることで進化してきたんだぜ
これから何かができるようになる進化は何かがおかしい
お前のしたいことって俺にはvoid*にしか見えないんだけど？
安全性の違いはわかるけど、じゃ、それがどれくらいっていうと大して違いがないように見える
設計が下手糞なのを汎用性の向上の問題にすり替えて逃げてるように見える
767:仕様書無しさん
07/10/14 23:46:20
きゅん萌え自演スンナ
つかおまいら委譲イベントモデルって言葉しってっか？ｗ
768:仕様書無しさん
07/10/14 23:59:22
なんだこの宗教論争
769:仕様書無しさん
07/10/15 00:33:26
>>765-766
イベントクラスの継承と
イベントリスナーの話を整理して語る能力のない
キチガイ発見
770:仕様書無しさん
07/10/15 00:41:52
>>765
郵便ポストの型の話と郵便物の型の話をゴッチャに語った挙げ句に
郵便ポスト内部に宛先別仕分け装置を付けろとかデムパ受信したり、
それは私設私書箱でいいはずだとか
どんだけ話が発散してるんだこのキチガイは
キチガイって、無様だな
771:仕様書無しさん
07/10/15 00:47:26
どのイベントをひろってどれを捨てるか判断する主体が
ハンドラからリスナに移ったてことが要点なんだろ
772:仕様書無しさん
07/10/15 00:47:39
キチガイ>>765は、まずは
イベントと
イベントリスナーが
別の存在である事を再確認して
>>742を書き直せ。
今のお前は言葉遣いもいい加減な認識のままデタラメをしゃべって、
大人に相手にされずヒステリーを起こしている、
言葉を覚えたての赤ん坊
みたいな微笑ましい存在でしかない。
773:仕様書無しさん
07/10/15 00:51:15
>>771
キチガイよ
そんな10年も前に普及済みな知識でﾑｷになるなって
774:仕様書無しさん
07/10/15 00:53:12
知識じゃねっつの文脈の話してんのコンテキストのよ
わかっか？きゅん萌え
775:仕様書無しさん
07/10/15 01:07:39
キチガイさんにも判るように、アンタの話のデタラメさ加減を解説してやろう（なんて親切なんだ俺って
①> イベントっていう基底クラスの振る舞いを変えた何かを持たせるわけだろ。
何度も言っているが、イベントは単なるデータクラスであって、
振る舞いを持つのはハンドラー/リスナー側だ。
②> MFCのように特定のイベントを継承して実装するモデルより
それ、イベントの継承よりも、イベント「処理(＝リスナー、デレゲート)」の継承が本質だろ。
理由は①の解説を参照。
③>Javaのなんちょれリスナーを登録するとかC#のデレゲートでイベントを表すという
コンポジット志向のほうが優れてるが、
> それだって根底にあるのは継承であって、単純にメンバ変数として持ってるわけじゃない。
お前は継承とメンバ変数で議論をしたいようだが、
お前の言っている事例は「委譲」の事例だ。(この辺ものすごくど素人くせえ)
776:仕様書無しさん
07/10/15 01:08:41
ついでに言うと、リスナーやデレゲートでイベント「処理」 を委譲し、
ついでにお前さんの認識外にある「イベントディスパッチャー」相当のクラスも独自実装すれば、
イベントの継承＝イベントの型継承などどーでもよくなる。
なぜなら、イベントが特定の型を継承する必要があるのは、
ライブラリに作りつけの「イベントディスパッチャー」相当のクラスが
特定の型しか認識しない(パラメータとして受け取れない)からだ。
このあたり、自分でシステム互換のイベント配送機構を独自実装してみれば、
話はよく判るはずだ。
777:仕様書無しさん
07/10/15 01:13:08
自分で手を動かしもせず
ネット上の知識だけでいっぱしの論客を気取るデタラメ人間は
火達磨にされてもしょうがないと思った(ﾆﾔﾆﾔ
778:仕様書無しさん
07/10/15 01:24:29
しょうもねえことで偉そうにしてるお前がまず死ねよ
きゅん萌え
文脈無視して、くだらねえあげあし取りに終始
建設的なことは一切いえずできずで、会社からお払い箱
それがお前だｗ
779:仕様書無しさん
07/10/15 01:38:01
継承vsインスタンス変数論争でお前の出している例は、
委譲だよ委譲。全然筋違いの例だしてくるから議論が発散するんだよ。
議論の流れの異常さに気付かないお前は異常者そのものだ
780:仕様書無しさん
07/10/15 01:42:52
>>776
だから、そんなの結果的に型を誤魔化したかっただけの話だろ？
void*でいいじゃん
781:仕様書無しさん
07/10/15 01:50:18
>>780
キチガイに構うのやめとけ
あと、void*でいいじゃんって意味わからん
キティがいってるイベントって、リスナに送るパラメータのこと
782:仕様書無しさん
07/10/15 01:50:25
↑典型的なバカ
783:仕様書無しさん
07/10/15 02:00:32
>>780-781みたいなキチガイが
一流研究者にタメ口きいてくるのって
なんだか滑稽だな
>>1
あんた、知りたがり屋さんだねぇ
784:仕様書無しさん
07/10/15 02:01:01
>>781
だからさ、その一連の仕組みまるごと説明すると
「型の誤魔化しをして見た目の設計がすっきりするため」のもんなのよ
そんなのなんのためにやってんの？アホ？って話を俺はしてるの
785:仕様書無しさん
07/10/15 02:03:03
おまえの知能レベルには、MS-BASICがお似合いだ
786:仕様書無しさん
07/10/15 02:04:56
>>784
OCPってしってっか？
787:仕様書無しさん
07/10/15 02:09:31
少なくとも同じことをやるだけなら
void*で十分だね
初めの４バイトをＩＤにして後はＩＤごと決まったフォーマットにしておけば「ハイ、完成」
別にクラス弄ってヘンテコな設計して無理やり汎用性なんてつけなくていいよ
言語に型なんてなかった頃は全部ＩＤ＋ＸＸＸの組み合わせだろ
788:仕様書無しさん
07/10/15 02:15:35
すきにしろとしか
789:仕様書無しさん
07/10/15 02:17:19
OCP以前に抽象データ型もしらねえか
790:仕様書無しさん
07/10/15 02:19:21
>>789
関係無し
ＩＤ＋ＸＸＸ
に勝るデータありませんからｗ
これは言語に型ができた理由を理解できない奴に反論は不可能だから面白い
791:仕様書無しさん
07/10/15 02:21:40
キチガイ警報発令！
関数ポインターだとか、型を誤魔化すだとか、
キチガイの発言はつくづくセンスねえなあ
792:仕様書無しさん
07/10/15 02:22:49
もおええわ
キチガイばっか
793:仕様書無しさん
07/10/15 02:25:21
>>791
じゃあ、なんで型を誤魔化すコードを推奨してるの？
そんなもん一生懸命勉強してる奴まとめて馬鹿にしか見えない
雑誌の提灯記事に騙されてるんだよお前等
なんで言語に型ができたの？
どうしてお前等はそれをなんとか誤魔化そうと必死なの？
結論からいうと型を誤魔化して汎用性というやり方はそれ自体がＮＧなんだよ
言語は制限をつける形で進化してきたんだ
その進化の道筋を知らないで結果だけ見るから型が邪魔に思えるんだ
こと言語に関して「～ができるようになる」ってのはありえないって頭に叩き込んどけ
794:仕様書無しさん
07/10/15 02:27:30
おまえ論点ブレ過ぎだわバーカ
そんなだから誰にもまともに相手にされないんだよ
795:仕様書無しさん
07/10/15 02:28:50
キチガイ対決wktk
796:仕様書無しさん
07/10/15 02:30:05
>>794
アレアレ？
反論できないの？
ボディに食らったパンチが足に来てるｗ
797:仕様書無しさん
07/10/15 02:30:45
幼稚園生(>>793)が
勝手に創作した独自用語で一貫性のない主張を繰り返す痛いスレ
798:仕様書無しさん
07/10/15 02:32:28
型をごまかしてるってのが良くわからないなあ
ちょっと具体的にコードで表現してみてよ
と煽ってみる
799:仕様書無しさん
07/10/15 02:32:45
>>797
はぁ？俺はわけわからない言葉なんて使ったりしないもんねー
お前じゃあるまいしｗ
俺はいつでも誰にでもわかる言葉を使って話してるぜ
言い掛りはやめてくれよ
嘘吐き君♪
800:仕様書無しさん
07/10/15 02:32:46
仕事のねぇ>>793は、
幼稚園レベルの議論で深夜も夜更かしする暇があって、
いいでちゅねぇ
801:仕様書無しさん
07/10/15 02:32:47
おまぃらOOスレでも暴れてる２人だろ
802:仕様書無しさん
07/10/15 02:33:36
♪印はキチガイコテのしるし
803:仕様書無しさん
07/10/15 02:34:37
>>793のキチガイっぷりにwktk
804:仕様書無しさん
07/10/15 02:34:56
>>798
じゃあ、その前に俺の質問に答えてくれるかな？
なんでさ、「イベント」を執拗に分離して汎用性を上げようとするのかな？
805:仕様書無しさん
07/10/15 02:36:07
イベントとリスナーの区別すらついてない幼稚園生
806:仕様書無しさん
07/10/15 02:37:36
>>801
違うぜ
俺は近年めっきり減ってしまったＯＯ原理主義者なんで
多分この板にも１人しかいないと思われる
ＯＯを理解できない馬鹿が書いた本が世に溢れる前なんで比較的マトモにＯＯが扱えるほうかと・・・
明らかにオブジェクトを扱って無いオブジェクト指向を信仰してるアフォが増えてて嘆いているｗ
わかれよｗ感覚でよｗｗｗ
807:仕様書無しさん
07/10/15 02:38:00
幼稚園生だから、用語遣いがデタラメなのは赦してやれ(w
808:仕様書無しさん
07/10/15 02:38:22
>>805
今の議論でそんな区別なくていいよね？
なんでそんなこと持ち出すの？馬鹿？
809:仕様書無しさん
07/10/15 02:38:39
幼稚園生だから、用語遣いがデタラメなのは赦してやれ(w
810:仕様書無しさん
07/10/15 02:39:37
>>809
おやおや？ｗあんまり悔しくて同じレスを連投ですかｗ
811:仕様書無しさん
07/10/15 02:40:31
頭が馬鹿なやつほど
デタラメな用語使いをして
相手に意図が伝えられずにヒステリー起こすのなw
哀れ
812:仕様書無しさん
07/10/15 02:40:45
はんどらかわとりすなかわで
じっそうするひとちがかったらどうする？
それともVB6まんせーってこと？
と煽ってみる
813:仕様書無しさん
07/10/15 02:42:20
>>811-812
あれあれ？話題が違うところへいっちゃったよ？
本題では勝負にならないから違うところへ逃げて見た？ｗ
哀れーｗ
814:仕様書無しさん
07/10/15 02:43:03
はんどらとりすながおなじやくめをするものだときっかない馬鹿
815:仕様書無しさん
07/10/15 02:43:14
稀に見る名勝負だな
816:仕様書無しさん
07/10/15 02:45:26
深夜に馬鹿議論するほど暇な
社会生活不適合者がただいま暴れておりますｗｗｗ
817:仕様書無しさん
07/10/15 02:45:28
>>814-815
あれあれ？もしかして自分の常識も壊されちゃってレスで
煽って優位にたってるかのように見せないとプライドが保て無い？ｗ
818:仕様書無しさん
07/10/15 02:46:18
>>816
オマエモナーｗ
819:仕様書無しさん
07/10/15 02:46:27
もったいぶらねえで1レスで全部出し切れや
とっくに底の浅さは割れてんだこのド素人が
と煽ってみる
820:仕様書無しさん
07/10/15 02:47:27
>>819
君はさっさと俺の質問に答えてよソース出してほしいんでしょｗ
821:仕様書無しさん
07/10/15 02:47:30
どーでもいいべ
822:仕様書無しさん
07/10/15 02:47:32
キチガイはさっさと頸動脈切って永眠しちまえよ
823:仕様書無しさん
07/10/15 02:48:18
>>821
ならなんでレス付けるの？ｗぷぷぷｗ
必死にしがみついててミジメーｗ
824:仕様書無しさん
07/10/15 02:49:58
明日朝は役員会で忙しいんで寝る
キチガイはさっさと首吊ってくれ。約束だよ。
825:仕様書無しさん
07/10/15 02:50:06
キチガイバトルかみあってねーよ
なんとかしろ
826:仕様書無しさん
07/10/15 02:52:15
>>824
君の用事なんて興味ないなぁーｗ
なんで理由を言ってから立ち去るのかなぁ？ｗ
別に聞いてもいないのに「役員会」とかさも自分がどこかの偉い人みたいに言っていくなんて悲しすぎるｗ
うきゃーｗｗｗおもしろいｗ
827:仕様書無しさん
07/10/15 02:54:00
キチガイ常駐警報発令
828:仕様書無しさん
07/10/15 02:54:54
キチガイ同士なかよくしろ
829:仕様書無しさん
07/10/15 02:57:22
>>827
このageとsageがセットの人って１人でしょ？
なんで２人いるフリするの？ｗ
病気？ｗ
それとも本当にシンクロしてんの？きんもー☆
830:仕様書無しさん
07/10/15 03:03:13
幼稚園生を納得させるには、幼稚園生と同じ目線で物事を語ってやればよい。
誰しもかつては幼稚園生だった時代があるだろうから、
その当時の思考形態を思い出すのは不可能ではない。
これに対して、キチガイを納得させるのは存外に難しい。
何故ならキチガイの思考論理など正常な社会人には知る由もないカオスであり、
無理に思考をトレースしたらこちらまでカオスに飲み込まれてしまう。
従って、キチガイが視線を合わせたり議論を挑んできたら
躊躇わずその場を立ち去る
…これが常識人の振る舞いというものです。
失敬
831:仕様書無しさん
07/10/15 03:16:32
>>830
あー、で、本題へのレスはしないんだ？
やっぱできないからかな？ｗ
ま、賢明かな
これで負けちゃったらプライドズタズタだもんねぇｗ
832:仕様書無しさん
07/10/15 03:18:10
↑キチガイ常駐警報発令中
833:仕様書無しさん
07/10/15 03:21:07
動的言語の型管理と大差ないアイデアを自慢気に晒して、
言語に型など不要だと言い切るのは
まごうことなきキチガイ
834:仕様書無しさん
07/10/15 07:44:09
>>833
はぁ？は？はぁ？
なにいってんの？
アイディア？
は？
なに？
全然話の主旨が違ーう
全然わかってなーい
日本語大丈夫？
あのレス見てそういうこというって相当頭悪いと思うよｗ
835:仕様書無しさん
07/10/15 08:14:49
キチガイの断末魔をお送りしました。
836:仕様書無しさん
07/10/15 08:21:15
>>835
話題に絡めないなら無理してレスつけなくていいんだよｗ
837:仕様書無しさん
07/10/15 08:31:15
まだやってらキチ共
838:仕様書無しさん
07/10/15 12:51:22
別にあなたにレスしてもらわなくてもいーんですよｗ
839:仕様書無しさん
07/10/18 01:23:51
ちょっと叩き過ぎたか・・・ｗ
840:仕様書無しさん
07/10/18 15:45:50
言語に型など一切要らないと断言するキチガイが
今週も誰にも相手にされずに
寂しがっておりますｗ
バカなんだから黙っときゃえぇーのに(ﾆｶﾞﾜﾗ
841:仕様書無しさん
07/10/18 21:50:16
>>840
お前、全然人の話聞けないのなｗ
誰もそんなこと言ってないのに
842:仕様書無しさん
07/10/19 10:01:10
このスレを昨日初めて発見。ちょっと気になる所にレスしとく。
リスコフ置換原則については>>344が正しくて>>345は間違い。
Base classを使って正しく動作する所にDerived classを持っていっても正しく動かなければならないって原則。
843:仕様書無しさん
07/10/19 22:59:29
>>842
ただ、>>345みたいにやっとくと型が隠蔽できて幸せになれる。
これはLSPを少し発展させた考え。
844:仕様書無しさん
07/10/20 02:16:01
意味不明なんだけど
845:仕様書無しさん
07/10/20 02:30:21
リスコフ自身がLSPに関して振る舞いが変わらない置換可能な性質が望ましいって書いてるのに
それが間違いだってどういう理屈なんだよ
846:仕様書無しさん
07/10/20 05:56:50
>>843
>型が隠蔽できて幸せになれる。
呼び出し側で、
>ガンダム.出す()
と記述した段階で、すでに型が露出してしまっているのでは？
型を隠蔽するというのは、呼び出し側では、
ロボット出す()
と記述しておいて、出るのはロボットかガンダムかわからないけれど、
ロボットにしか依存していない記述をしているから、
どちらがでても問題ない、ということでは？
その上で、戻される全ての具象クラスは、
ロボットクラスと同じ性質を備えるべきだ、というのが LSP なんでないの？
847:843
07/10/21 16:15:16
>>846
本当だ。
345を誤解してた。
LSPを発展させた考えってのは、
利用側には派生クラスの存在を隠蔽する
(可能ならアクセス不可にする)
って考えだ。
LSPについては、実は皆殆ど同じ事を言っているような…
848:仕様書無しさん
07/10/21 20:06:30
>>845
>>345で>>344の定義が間違っていると主張しているので、両方正しいということはない。
両方間違っているという可能性ならあるが。
849:仕様書無しさん
07/10/21 20:06:58
実際のプログラミングでは、最初から派生クラスがそろってるなんてことはないわけで、
戦争初期、ザクしかないころは、
class ムサイ {
ザク ザク発進 { ・・・ ｝
void 戦闘準備() {
・・・
ザク 一番機 = ザク発進()；
・・・
でよかったわけでしょう。
ところが、ザクとは違うグフが出てくると、MS という抽象クラスが必要になって、
class abstruct MS { ～ }
class ザク extens MS { ～ }
class グフ extens MS { ～ }
として、
class ムサイ {
MS MS発進 { ・・・ ｝
class 戦闘準備() {
・・・
MS 一番機 = MS発進()；
・・・
としなければならなくなる。
一度こうしておけば、
class ドム extens MS { ～ }
が出現したときは、ムサイクラスはそのまま書き換えずに使えると。
850:仕様書無しさん
07/10/21 20:08:37
あかん、修正
× class 戦闘準備() {
○ void 戦闘準備() {
851:仕様書無しさん
07/10/21 20:14:12
ガンダムで喩えられてもさっぱりわかりませんｗ
852:仕様書無しさん
07/10/21 20:18:19
ザクやグフしかでてこない文章を読んで、ガンダムの話だとわかるのにか？
853:仕様書無しさん
07/10/21 20:19:11
いやムサイがなんだかわからんのだｗ
854:仕様書無しさん
07/10/21 20:29:56
某Google にて・・・
リスコフの置換原則 に一致する日本語のページ 約 380 件中 1 - 20 件目 (0.18 秒)
ムサイ に一致する日本語のページ 約 209,000 件中 1 - 20 件目 (0.18 秒)
855:仕様書無しさん
07/10/21 20:31:21
ガノタ死ね
856:仕様書無しさん
07/10/22 01:33:01
オブジェクト指向っぽく書いてみたけど、
複数のクラスが最終的に1つのクラスに包含されちゃったんだけど・・・
で、最後に残ったクラスがGUIとグラフィックを受け持つクラスとやり取り
するプログラムになったんだけど、オブジェクト指向になってると思う？
857:仕様書無しさん
07/10/22 01:41:11
ぶっちゃけ、MVCで作ると、コントローラはそんな感じになる。
しかし、データ構造を持つクラスは残るはずだが・・・。
858:仕様書無しさん
07/10/22 06:59:03
おまいらの話はオーバーライドで解決。
859:仕様書無しさん
07/10/22 16:23:03
Evaで例えて下さい＞＜
860:仕様書無しさん
07/10/22 16:39:15
えーと、ざっと読み返してみたら、>>248が元凶の模様。>>248は間違い。
それと他の新しいSub Classを作る必要が出てきたから、メソッドを引き上げましょうとかいうのはLSPとは何の関係もありません。
861:仕様書無しさん
07/10/22 20:33:38
>>859
だから、
class ゲンドウ {
ユイ ユイちょっと来い { ・・・ ｝
void 準備() {
・・・
ユイ ユイ = ユイちょっと来い()；
・・・
であるばあいに、
class レイ extends ユイ implements clonable ・・・・ { }
とすれば、ユイちょっと来い() が返すのがユイであろうとレイであろうと、
何番目だろうと、ゲンドウには問題ない・・・と。
862:仕様書無しさん
07/10/22 20:46:31
綾波 extends リリスは魂を持っていてリリスの振る舞いを損なわない＝LSPを守っている
初号機 extends リリスは魂のない器でパイロットが必要＝LSPに違反している
863:仕様書無しさん
07/10/22 21:26:01
エヴァヲタもうぜーということがわかった
864:仕様書無しさん
07/10/22 21:28:52
LSPも理解できない低能が必死↑
865:仕様書無しさん
07/10/22 21:40:11
>>861
そのクラス根本的におかしいだろ
866:仕様書無しさん
07/10/22 21:56:21
クロエ、Twenty Fourでたとえてくれ、頼む
867:仕様書無しさん
07/10/22 21:59:21
>>863
じゃあお前は何で例えればうざくないんだ？
868:仕様書無しさん
07/10/22 23:35:33
class レイ extends リリス
{
public void insert(ゲンドウ ゲンドウ) {
}
}
class シンジ extends リリス
{
}
レイ レイ = new レイ();
シンジ シンジ = new シンジ();
レイ.insert(シンジ);
レイにinsert出来ません＞＜
869:仕様書無しさん
07/10/23 01:14:11
ほんとエヴァオタってうざいなｗ
870:仕様書無しさん
07/10/23 01:17:38
俺今OOの極意をつかんだかもしれん。
class リリス extends ゲンドウ {}
ほらね！
871:仕様書無しさん
07/10/23 02:46:57
>>868
class レイ extends リリス
{
public void insert(リリス ゲンドウ) {
}
}
class シンジ extends リリス
{
}
レイ レイ = new レイ();
リリス シンジ = new シンジ();
レイ.insert(シンジ);
これでレイにインサート出来るよ！
872:仕様書無しさん
07/10/23 09:37:55
なんだこの流れはｗ どうしょうもねぇ。
873:仕様書無しさん
07/10/23 22:54:05
> レイ.insert(シンジ);
どうみても、レイがinsertしています。本当にありg（ry
874:仕様書無しさん
07/10/23 23:49:27
これはひどい
875:仕様書無しさん
07/10/24 12:20:18
国内でオブジェクト指向の最高権威って今誰なんだろう？
そいつに聞くのがてっとり早そうだ。
前橋とか？
876:仕様書無しさん
07/10/24 20:03:00
class ムサイ
｛
private
MS ms[最大搭載数]
搭乗員 man「最大登場数」
パイロット pailot[最大等乗数]
現在搭載数、現在乗員数、現在待機数
自爆（）；
public
収容（MS)
収容（搭乗員）
収容（パイロット）
発進（MS)
降りる（搭乗員）
降りる（パイロット）
｝
収容（MS）
｛
ms[]=MS;
if(もう無理==man.判断（ms[]）){
自爆（）
｝
｝
判断（MS）
｛
パイロット交換？
pailot.交代（ms[]）
MS破損？
man.修理（ms[]）
｝
どうよ？ クラスの作り方とか内部処理とか問題があるとこ指摘してください＞＜
877:仕様書無しさん
07/10/24 21:24:42
モジュールって何？
878:仕様書無しさん
07/10/24 22:13:58
>>876
>>877
うぜえ消えろ
879:仕様書無しさん
07/10/25 14:04:59
>>875
前橋がＯＯの権威なら、この世にＯＯも権威もなくなるよ…… orz
880:仕様書無しさん
07/10/25 14:09:33
>>879
前橋よりマシなひとって誰？
誰を出しても駄目出しくらいそうだけど
881:仕様書無しさん
07/10/25 19:14:47
メジャー度から考えて憂鬱本の中のひとだろ。
って国内の話だったな。あれ日本人か？
882:仕様書無しさん
07/10/26 00:04:59
ま た 自 画 自 賛 か
883:仕様書無しさん
07/10/26 00:16:47
常識的に考えて国内で1番OOわかっている奴っていうなら
まつもとだろ
次点で前橋、憂鬱本のTucker、赤坂、うださの中のひとのlsってところ
884:仕様書無しさん
07/10/26 04:07:55
>>876
いろいろおかしい。
一つ具体的に言うと×pailot ○pilot
885:仕様書無しさん
07/10/26 08:21:51
青木淳
結城晶
牛尾剛
886:仕様書無しさん
07/10/26 14:31:09
久野さん
887:仕様書無しさん
07/10/27 07:27:43
>>886
久野ｾｿｾｲ？それはどうだろう…
888:仕様書無しさん
07/10/27 11:06:13
大滝 みや子、日高 哲郎だろう。
>>887
横だが違うのなら代案を頼む
>>885
結城晶？バーチャ？
結城昌？小説家？
結城浩？
889:仕様書無しさん
07/11/25 19:21:36
時々、迷うときがあるんだが、
外からデータを取ってきて、メンバー変数に値を設定する場合、
getXXX
か
setXXX
か、おまいらならどっちにする？
取得という意味ならgetだし、設定という意味ならset。
ちなみにこのメソッドで、その値を返す場合と返さない場合とがあるし、
外部から呼べる場合とprivateメソッドの場合とがある。
890:仕様書無しさん
07/11/25 19:29:00
>Give one entity one cohesive responsibility
891:仕様書無しさん
07/11/25 19:49:40
>>889
load
892:仕様書無しさん
07/11/25 20:52:00
refresh
893:仕様書無しさん
07/11/25 22:04:48
getter/setter以外ではget/setは使わん
894:889
07/11/26 22:27:25
Thanx
895:仕様書無しさん
08/01/08 11:33:32
某大学、某教授が教える Java の授業。
クラスは１つ、メソッドは input, process, output の３つ。
なんというテンプレ (ﾟдﾟ)
896:仕様書無しさん
08/01/08 21:53:26
すごいなー
そんな授業を修了して、
「ボクはJava使えます」とか言っちゃう香具師が居るわけだｗ
897:とっさん新人
08/02/03 10:48:32
基本的なところですいませんが、ファクトリパターンって
リフレクションＡＰＩ使わないと出来ないんですか？
898:仕様書無しさん
08/02/03 10:54:22
>>897
別に
899:仕様書無しさん
08/02/06 09:01:35
>>897
アブストラクトファクトリ？
具象ファクトリの生成を(リフレクション使った)生成メソッドにやらせるんじゃなく
直接生成すればおｋ。
パターンってのは必ず同じように実現しなきゃいけないってわけじゃない。
でも、意志疎通の妨げにならないよう気を配る必要はある。
900:仕様書無しさん
08/04/29 16:31:17
魚を包丁で切って複数の切り身に変換されるようなケースを
モデリングしたいのですが、どうすればよいのでしょうか。
要するにオブジェクトを複数に分断するようなケースです。
普通に考えると包丁オブジェクトが魚オブジェクトを削除して
切り身オブジェクトを生成することになりそうですが
包丁が魚を消すというのがイマイチな感じがします。
できれば、包丁はオブジェクトを細かく分けるという処理にしたいのです。
901:仕様書無しさん
08/04/29 17:39:35
ほぉ、ちょーですか？
902:仕様書無しさん
08/04/29 17:40:16
>普通に考えると包丁オブジェクトが魚オブジェクトを削除して切り身オブジェクトを生成
普通か?
ステータスパターンみたいな感じで 魚, 複数の切り身(コンポジット?) が同じインタフェースになってればいいんじゃね？
包丁オブジェクトの意味がよくわからないが
903:仕様書無しさん
08/04/29 17:52:01
>>900 要件が不十分
1匹の魚からとれる切り身の数に制限はあるか？
切り身に包丁をいれてさらに切り身がとれるか？
切り身を一枚だけ切り取った魚の残りは果して魚オブジェクトか切り身オブジェクトか？
魚は全て切り身に分割されるのか、それとも頭や尻尾、骨など、他のオブジェクトも存在するのか？
切り取った切り身をまた返すことで、魚オブジェクトは復活する？
つぅか、これ一体何やりたいの？
魚クラスが一定数までの切り身クラスのインスタンスを返すファクトリメソッド備えた、シングル
トンパタンとの組合せじゃダメ？
トリメソッドパタンの組合せじゃダメ？
904:900
08/04/30 08:46:44
レス感謝です!!
魚を使った例えが余計でしたね
豆腐のほうがいいですね
豆腐をスライサーでカットするとき
豆腐オブジェクト（１丁２００ｇ）
スライサーオブジェクト（入力：豆腐、出力：スライス豆腐（複数））
としたとき、スライサーオブジェクトの中で
どのように記述すればよいか、ということです。
スライスサイズ(10g)は、スライサーオブジェクトに設定できるようにします。
スライサーの出力として分断されたオブジェクトにしたいのですが
Tofu[] tofuArray = slicerObj.do(TofuObj);
とするとTofuObjをSlicerの中でdeleteしたいのですが
開発言語がjavaだったりすると、deleteがないので
上記式をコールした後に
TofuObjが使用できてしまうことが、非常にいやなのです。
分かりにくくてすみませんです
905:>904
08/04/30 11:21:08
だから903読めよw
906:900
08/04/30 11:44:13
すいません
イマイチ意味がわからなかったもので・・・
ちゃんと答えますね
>1匹の魚からとれる切り身の数に制限はあるか？
まず、実際の魚から切り身の数に限界なんてありますか？
ないですよね
>切り身を一枚だけ切り取った魚の残りは果して魚オブジェクトか切り身オブジェクトか？
切り身です。しかし切り身であって魚であるのです。
魚の例を出したのは失敗でした。
豆腐なら何回切ってもサイズが違う豆腐ですよね？
>魚は全て切り身に分割されるのか、・・・
豆腐の例でお願いします
>切り取った切り身をまた返すことで、魚オブジェクトは復活する？
できれば、刻んだ豆腐を再度練り直して固める再生マシンを作れるなら
再生マシンに複数の豆腐を入れることで、大きな豆腐になることも考えられます。
>つぅか、これ一体何やりたいの？
最終的には食品工場のエミュレートです
>魚クラスが一定数までの・・・
一定ではないです。あくまで指定サイズ（仕様）に会わせた加工を
実現できないと困ります。ただしメモリ云々というのは別問題として。
>トリメソッドパタン
すいません、これ知りません。
教えてください(><;)
907:902
08/04/30 12:04:02
だから 豆腐, スライス豆腐(コンポジット?) が同じインタフェースを持つオブジェクトとして扱えればいいんじゃないの？
908:900
08/04/30 12:13:25
つまり、分断される材料（即ち全ての材料）は
全てコンポジットとして考えるべき
ということでしょうか？
うーん、なるほど。
909:仕様書無しさん
08/04/30 19:11:56
OOには苦手な分野があります。それがこの手の処理、「変換」です。
本来のOOの考え方では、「豆腐」に「包丁」で切るメソッドを追加するべきですが、
「包丁で3つに切る」「包丁で縦横3列に切る」など、無限のメソッドが必要になってしまいます。
これを解消する方法として一般的に使われているのは、単なる変換関数です。
Javaの場合はstaticのメソッドとして実現されています。例としてはInteger.parseInt()などです。
C++の場合はマニュピレーターとして実現されています。cout << setw(2) << 1;などです。
これはOOとの考え方には反していますが、現実的な解決方法として広く使用されています。
910:仕様書無しさん
08/04/30 19:48:57
>「変換」
>902 にも書いてあるが
一定数までのクラスの複数インスタンスを返すファクトリメソッド備えればいいってばYO
911:仕様書無しさん
08/04/30 21:18:45
その場合、切られる前の豆腐の生存期間はどのように
なるのでしょうか？
912:sage
08/04/30 21:48:23
豆腐を包丁で切る場合は豆腐の中にではなく
包丁クラスに材料を切るという動作があるべきじゃないのか？
913:仕様書無しさん
08/04/30 22:29:09
そもそも包丁なんていらねべ、男なら手刀だろが
914:仕様書無しさん
08/05/01 00:33:25
包丁はアクターだろ
915:仕様書無しさん
08/05/01 15:36:06
豆腐を分割するのに、包丁である必要があるかどうかだろう
そもそも工場のエミュレートなら、包丁じゃなく、
分割するシステムと捉えればいいわけで、
変換関数かまして、出力が分割結果のarrayである、
で、わりあい素直にまとまるんじゃね？
916:仕様書無しさん
08/05/01 17:14:36
>915
>904 に書いてある通り
切った豆腐がスライサーからArray型で出力されるのはよいが
スライサーに入力した豆腐が生存し続けることが問題のようだ
917:仕様書無しさん
08/05/01 17:46:17
>916
"スライサー"に渡す"豆腐"を保持しているのは誰だ？
そいつが"スライサー"のはずがないよな？
918:仕様書無しさん
08/05/01 18:16:44
スライサーから出てくるのは入力した豆腐の変形でしょ？
スライサーに入力した豆腐が入力元に残るのはおかしいよね？
919:仕様書無しさん
08/05/01 18:22:31
いちいち現実世界のモノに対応させて考えていると、
OOPの旨みを知るのに遠回りになる。
非OOPやりまくって不便さを味わったほうがマシ。
920:仕様書無しさん
08/05/01 18:35:00
結局、無理ってことかね
921:仕様書無しさん
08/05/03 00:52:13
切られたら豆腐のサイズを縮小して豆腐自体を保持するまな板オブジェクトかなんかに
もう一個サイズをの小さい豆腐を追加するだけじゃねえの？
922:仕様書無しさん
08/05/04 16:50:49
入力した豆腐インスタンスは、
スライサーによって破砕されるんだから、
スライサーが解放しちまっていいんじゃね？
何を迷ってるのかよくわからんよ
923:仕様書無しさん
08/05/04 20:36:12
javaはdeleteが無いから
解放できんのよ
ポポーン
924:仕様書無しさん
08/05/04 23:35:20
>>919
同意。
現実世界を抽象化するのがオブジェクト指向の本質。
オブジェクト指向を説明するのに現実世界を例にすること自体が間違い。
これでは、いつまでたってもオブジェクト指向を理解できない。
>>900
もっと抽象的に考えれば良いと思う。
スライサーは本当に必要なのか？
現実の世界では、スライサーがないと豆腐は綺麗に切れないかもしれないが、
抽象世界では、スライサーがなくても豆腐は分割できるし、元の豆腐を
いちいち削除しなくても良い。
たとえば、
「豆腐オブジェクトA -> 豆腐オブジェクトA, 豆腐オブジェクトB」
となっても良いと思う。（仕様次第だけど）
※ 豆腐クラスには、サイズに関する属性があり、分割後に
豆腐オブジェクトAは、半分のサイズになるとか・・・。
tofuObujectB = tofuObujectA.remove(tofuObujectA.size()/2);
※ tofuObujectAは、サイズ0の豆腐もあり得る。
※ tofuObujectAからtofuObujectAの半分のサイズだけ取り出して
tofuObjectBを生成する（特殊なクローン）感じになるけどね。
925:仕様書無しさん
08/05/05 16:05:54
皆さん、色々とレスしてくれて感謝です
>スライサーは本当に必要なのか？
工場のエミュレートであるならば
必要なんじゃない？
装置エミュレートしなくて、工場エミュレートって南下変
926:仕様書無しさん
08/05/05 18:10:46
916 ：仕様書無しさん：2008/05/01(木) 17:14:36
>915
>904 に書いてある通り
切った豆腐がスライサーからArray型で出力されるのはよいが
スライサーに入力した豆腐が生存し続けることが問題のようだ
917 ：仕様書無しさん：2008/05/01(木) 17:46:17
>916
"スライサー"に渡す"豆腐"を保持しているのは誰だ？
そいつが"スライサー"のはずがないよな？
と思うのだが
927:仕様書無しさん
08/05/05 18:33:34
スライサーの責務は？スライスするサイズを設定できたり、カッターの
動作速度を設定できたりする必要があるの？
工場をエミュレートって、工場の中にあるいろいろな装置がグラフィカルに
たとえば３Dで動く画像をユーザに見せるとかするの？それなら、スライサー
は必要だと思うが・・・。
豆腐を分割するということに関しては、スライサーオブジェクトはそれほど
重要ではないと思う。
いずれにせよ、工場オブジェクトが外部システム（アクター）とどのように
コラボレーションするのか？を明確にしないと、意図したアドバイスを
受けられないと思う。
「何を設計するのか？」と「何を設計しないのか？」を整理したほうが
良いんじゃないか。
928:仕様書無しさん
08/05/05 20:09:10
>>926
>スライサーに入力した豆腐が生存し続けることが問題
「概念上の豆腐オブジェクトの生存」と「言語上のオブジェクト
（メモリ管理）」を強く結び付けて考えることはしてはいけない。
> "スライサー"に渡す"豆腐"を保持しているのは誰だ？
> そいつが"スライサー"のはずがないよな？
豆腐は「ロット」で管理され、ロットは「ロット管理オブジェクト」か
何かでさらに管理されるんだろうな・・・。
そんでもって、ロットは、工程を追うごとに状態を変えていくわけ。
ロットには豆腐をどのようにカットするかといった情報（レシピ）が
付いてるんだろうな。
で、スライサーでカットされると、「カット前」状態から「カット済み」
状態に状態が遷移するわけ。
カット済み状態のロットで、Printメソッドを実行すると、カットされた
豆腐のリストがプリントされるってな感じじゃないのか？
929:仕様書無しさん
08/05/05 20:54:40
分かりやすくて吹いた
オブジェクト指向 - アンサイクロペディア
URLﾘﾝｸ(ja.uncyclopedia.info)
930:仕様書無しさん
08/05/05 22:00:28
工場をエミュレートする目的なんて
どうせ作業効率化だろうから
装置の消費電力とか、歩留まりとか、作業時間を計算するための動作時間
とか設定が必要なんだろうな、って思たよ。
ひとつ思うのが豆腐オブジェクトをスライサーに渡して、使用済みになった
豆腐オブジェクトは、やっぱ機能できないようになるべきじゃないのか？
ロットで管理するのもよいかもしれないが、
豆腐オブジェクト自身に状態を管理するメンバ変数があれば
それだけでよさそう
931:928
08/05/05 22:28:16
>>930
ロット管理ってのは少し飛躍しすぎたな。
>豆腐オブジェクト自身に状態を管理するメンバ変数があれば
>それだけでよさそう
確かに、豆腐オブジェクトの属性として状態を持たせても良いと思う。
今のところの情報だけだと普通そうなるんだろうな。
ちょっと深読みして
「大豆」->「洗った大豆」->「ゆでた大豆」->「液状の大豆」->「切る前の
豆腐」->「切った豆腐」->「容器に入った豆腐」
と変化していくなら、豆腐オブジェクトだけで表現しきれないと思って
「ロット」という概念を取り入れたんだけどね。
※分析中毒かもしれんが・・。
932:仕様書無しさん
08/05/08 00:40:38
うちの４０くらいのVB上がりの人は、たぶんオブジェクト指向という言葉も知らずにC#やってるよ。
それでもなんとかやってるみたいよ。
staic メソッド量産して。
933:仕様書無しさん
08/05/24 12:25:27
単一債務と単一責務をググッたらこんなの見つけたんだが。
URLﾘﾝｸ(www.h.tera-house.ac.jp)
934:仕様書無しさん
08/06/04 17:59:18
staicって何？
935:仕様書無しさん
08/06/04 22:49:16
staicに決まってるじゃないか
936:仕様書無しさん
08/06/05 22:18:46
staicなオレの生き様
937:仕様書無しさん
08/06/05 22:46:41
当たり前だな。
ぐへへへ
938:仕様書無しさん
08/06/08 22:24:59
いままでC#やらVBでコードを書くときに、イベントハンドラにロジックをベタ書きしてたけど、
これじゃいけないと思って、いまやってるプロジェクトでは、MVCの変形らしい、MVP(Model-View-Presenter)パターンと
いうので書いてみたけど、なんていうか、すごい手間がかかった。
どこまでをロジックで書いて、どこまでをViewで書くかとか、試行錯誤が多かったからそれで余計疲れたってのも
あるけど、それにしても手間がかかりすぎって印象だった。
オブジェクト指向っぽく書いて、unitとか導入まで考えてたけど、とてもそこまで手が回らないって感じ。
世間じゃ、まじでViewとロジックの分離とかやってるの?
939:仕様書無しさん
08/06/08 22:32:58
>>938
普通にやる
つーか、やらないと後で困る
試行錯誤が発生するのは、慣れの問題
いつも分離して書いていれば、そのうちそれが普通になるし、
歳を食えば食うほど、分離して責任範囲を明確化するとか、
Unitテストでコア部分の実装を保証するとかやらないとやってられなくなる
OOPは年寄りに優しいからなｗ
940:仕様書無しさん
08/06/08 22:54:57
ロジックとビューの分離なんて、構造化分析/設計の時代から言われてる
ことなのに、VB厨は時代に取り残されているというより最初から時代に
ついていっていないんだな。
941:仕様書無しさん
08/06/08 22:58:43
構造化プログラミングすらしない・できない人たちのためにオブジェクト指向があるんだと最近思うんだ
942:仕様書無しさん
08/06/09 00:03:29
オブジェクト指向の前に型理論
943:仕様書無しさん
08/06/10 19:06:49
エージェント指向がいいと思うよ。
みんな人に置き換えて、中の人の仕事を書き出すのさｗ
944:仕様書無しさん
08/06/10 19:55:26
そのうち、一人で全部の仕事をやって鬱になる人とか発生するわけですね、わかります！
945:仕様書無しさん
08/06/10 22:51:10
全員に指示を出しても
８割が働いて２割が怠ける法則も発動ですね。わかります。
946:仕様書無しさん
08/06/11 19:18:45
結局、エージェント内部が全実装なので何の解決にもなって無いというオチ。
それどころか、人工知能だよその要求仕様はｗ
947:仕様書無しさん
08/06/12 00:28:06
動的オブジェクト指向を教えてください。
948:仕様書無しさん
08/06/12 14:20:25
3本柱（今でもいうの？）を覚えてください。
949:仕様書無しさん
08/06/12 18:39:55
何の？
950:仕様書無しさん
08/06/12 18:48:33
>>949
？？？？？？？？？？？？？？
951:仕様書無しさん
08/06/12 21:22:00
よし、スルー。
952:仕様書無しさん
08/06/13 00:09:33
手塚に何か言われたのか
953:仕様書無しさん
08/07/27 01:11:14
それ自身はオブジェクト指向というよりオブジェクトベースだけど、PowerShellはOOPを理解するのにとてもいいと思う
954:仕様書無しさん
08/08/16 15:49:13
>>916-923
豆腐の話ってメモリマネージャで
メモリの切り出しみたいなことじゃないの？
955:仕様書無しさん
08/11/11 00:26:34
クラス図を書けって宿題が出て困ってます
ポーカーゲームの「ディーラー」の属性は
「所属店」って書いて間違いじゃないですか？
956:仕様書無しさん
08/11/11 00:33:22
それでいい。
お前天才じゃないか？
957:955
08/11/11 00:40:40
>>956さん
正直属性とかよくわかんなくて・・・
レスありがとうございました、これで自信を持って提出できます
958:仕様書無しさん
08/11/16 16:28:47
なぁ、俺にオブジェクト指向でのプログラム再利用と関数化でのプログラム再利用の違いを説いてみやがれ。
ちなみにPHP最近はじめた俺です。
959:仕様書無しさん
08/11/22 03:58:29
長文ゴメン
・関数化でのプログラム再利用
→
後に関数を修正したい場合、そのまま修正するか、
或いは、良く似た関数を追加することになる。
前者の場合で影響範囲が大きい場合にテストが心配。
後者の場合、良く似ている別の処理であるため、
その違いの認識が容易でない。保守が心配。
安易なコピー＆ペーストによって類似ソースが大量に発生しそう。
開発者が一人であるならともかく、複数の場合は深刻。
（安易なコピー＆ペーストをされたら、オブジェクト指向言語でも深刻ですが）
古い世代の言語においては、汎用的な関数を作成したつもりでも
「複数スレッドから同時実行」といったコンセプトでは正常動作しない
ケースも多く、現代の複雑なプログラム開発に耐えられるか疑問。
・オブジェクト指向の場合（俺はJavaしかわからん）
→
新しい仕様について、どのクラスに仕事をさせるか？
ということをあらかじめ想定してからコードを書く。
既存のクラスを修正する？継承？オーバーロード？オーバーライド？
昔に比べて若干選択肢が増えている。
同時実行に関しては、インスタンスを複数個作成し、
個別にメソッドを実行するという記述が容易。
古い世代の言語とは一線を画するかな、と思う。
960:仕様書無しさん
08/11/22 09:31:52
c++だとオブジェクト指向とか意識してなくても関数の
オーバーロードが使えるし、意識してリエントラントに作らなければ
Javaだろうが何だろうがマルチスレッドで動かせば破綻する。
で、オブジェクト指向って何がありがたいんですか？
961:仕様書無しさん
08/11/22 13:15:21
>>960
つひろみちゅ
962:仕様書無しさん
08/11/22 14:28:38
ライブラリの処理の中で一部分だけ処理を変えたい場合に
その部分がオーバーライド可能な関数だとサクッと片付けられるよな
963:仕様書無しさん
08/11/22 14:35:38
C++使ってるけど、
グローバル変数とかstatic変数とかが大量に使われてるので
マルチスレッドで動かせば変な動きになるだろうな。
964:仕様書無しさん
08/11/22 15:40:31
synchronous 修飾子とかつけておしまいとか。
965:仕様書無しさん
08/11/23 19:42:33
>>960
インスタンス化したオブジェクトをコネコネして目的を達成できる。
インターフェイスに着目して、実装から離れたレベルで、
コネコネさせあうことについて集中できる。
思考の中心にオブジェクトが座るようになる。
966:仕様書無しさん
08/11/30 12:46:14
>>963
そこでMutexとSemaphoreの出番ですよ
967:仕様書無しさん
08/11/30 17:59:03
というかマルチスレッドとオブジェクト指向って完全に直交した議論のような。
968:仕様書無しさん
09/03/13 00:49:29
OOすべきプログラミングと非OOすべきプログラムの境界線ってどこらへんなんですか？
あとOOの使用を吟味する意味でも軽くプロトタイプを書いて、本設計するとうまくいくんですかね？
969:仕様書無しさん
09/03/14 14:37:35
そうはっきり色分けできるもんじゃないとおもうけどな。
970:仕様書無しさん
09/03/14 15:37:14
現場の人間と話し合え
971:仕様書無しさん
09/04/18 12:37:50
ThoughtWorksアンソロジーの第5章ってこのスレ的にどうなんでしょう。
なんか第4,第5正規形なノリを想起しました。
setterの不必要な公開はともかく、インスタンス変数2つまでとか理想論な気がします。
顧客情報を表すクラスを考えて、一体どれだけのクラスが必要になるんだろうと。
972:仕様書無しさん
09/04/29 21:39:22
>>963
そんなにグローバル変数とか使う事あるか？通常のプラットフォーム向け
じゃまず必要ないし、ドライバ関連でも、グローバル変数とそれにアクセスする
関数だけをファイルスコープで纏めて可能な限り干渉を避るから影響はわずかだぞ。
関係ないが、staticメンバー関数は使うがstatic変数は殆ど使わん。概ね関数の方は
friendメンバー代わり。staticメンバーを巧く使ってるやつっている？
973:仕様書無しさん
09/04/29 21:45:21
>>968
メッセージングが必要か否か。
メッセージを送る必要が無ければ、
処理を確定して書けば良い。
まぁ、メッセージを送る必要が
あるってのはそもそもメッセージを送る
対象が不確定である事の裏返しなんだけどな。
974:仕様書無しさん
09/05/09 21:59:32
OOとはなんぞ？なんて2005年前後までのネタが未だに続いてんだな。
975:仕様書無しさん
09/05/10 01:31:33
構造化プログラミングも明示されてないしな。そろそろ20年位経つか。