トップページ⇒tech
1001コメント438KB

-OOP限定-プログラム設計相談室

レス数が900を超えています。1000を超えると表示できなくなるよ。
0001デフォルトの名無しさん2005/09/24(土) 16:35:59
全部publicでいいじゃん！ってならないようにするスレです。
0809デフォルトの名無しさん2012/06/24(日) 18:50:30.45
>>724
>staticメソッドを使う場合は 上手く継承できない。
SingletonとMonostateの比較でよく言われるけど、これってどういう現象を指してるんだ？
0810デフォルトの名無しさん2012/06/24(日) 18:59:22.93
>>808
いったいそれのどこがOOPなんだ
0811デフォルトの名無しさん2012/06/24(日) 23:23:53.51
>>810
オブジェクトで振る舞いを定義してるところ。
どうでもいいが、WindowsのWindowClassってのは、
Windowsの中じゃ唯一まともにOOPを実現できてるところよ。
CreateWindowでオブジェクトを作り、SendMessage,
PostMessageで、Smalltalkや、Objective-Cと同じ
メッセージパッシング機構を実現した。
どんくさい環境での妥協案ではあったが、なんとか
そこだけはパロアルトの意志を継いでる。
0812デフォルトの名無しさん2012/06/24(日) 23:29:41.95
そうだね
継承も出来るし
0813デフォルトの名無しさん2012/06/24(日) 23:30:19.65
そう？個人的にはWindowsのAPIって全体的にOOPしてると思うよ
ポインタや参照をハンドルって形にしてるだけで
全然別種のオブジェクトを同じAPIで使用や解放する辺りも多態っぽい
0814デフォルトの名無しさん2012/06/24(日) 23:31:14.63
>Windowsの中じゃ唯一まともにOOPを実現

COMの方だろ。
0815デフォルトの名無しさん2012/06/24(日) 23:31:44.91
>PostMessageで、Smalltalkや、Objective-Cと同じ
>メッセージパッシング機構を実現した。

全然違うｗｗｗ
0816デフォルトの名無しさん2012/06/25(月) 00:39:40.40
どこが？
object x:10 y;10. 形式じゃないとメッセージ文に非ずと？
重要なのは、メッセージをメソッドと独立したデータとして扱える点だろ。
0817デフォルトの名無しさん2012/06/25(月) 00:41:41.10
>>814
COMはC++風OOPで、Smalltalk系統とは違うからなぁ
0818デフォルトの名無しさん2012/06/25(月) 00:49:21.57
>>814
WindowsというかWinAPIね。
0819デフォルトの名無しさん2012/06/25(月) 01:03:23.54
>>813
Windowと違ってユーザーが拡張できんからねぇ。
WindowClassなら、他のOOと同じく、移譲・集約・継承による
拡張ができるじゃん。当然、既存のウィンドウの子ウィンドウを
差し替えられて、ブリッジパターンの様な事すら可能だ。
しかもプロセス間においてもメッセージ送信が可能でSmalltalkや
Objecitive-Cのメッセージパッシングに非常に近い。
0820デフォルトの名無しさん2012/06/25(月) 20:38:03.60
SmalltalkやObjective-Cって、PostMessageの様な
メッセージの遅延送信ができてキューイングも出来るんだよな
よく似てる
0821デフォルトの名無しさん2012/06/25(月) 20:49:25.95
>>820
はぁ？
0822デフォルトの名無しさん2012/06/26(火) 05:01:54.69
嘘を嘘と見抜けない人は2chに向いてない
0823デフォルトの名無しさん2012/06/26(火) 06:47:27.14
NSInvocationをキューに突っ込んでやればいいぶん
汎用性が段違いだがな
0824デフォルトの名無しさん2012/07/01(日) 17:54:50.46
質問スレで質問してたのですが、場違いっぽくて触ってももらえませんでした。
移動してきました、よろしくお願いします。

スレ立てるまでもない質問はここで 119匹目
http://toro.2ch.net/test/read.cgi/tech/1337067149/912

912 名前：デフォルトの名無しさん[sage] 投稿日：2012/06/30(土) 09:43:05.16
observerパターンで大規模なmodelとviewを繋いでいるとき、更新を通知されたviewは
どのようにしてmodelの変更を取得するべきでしょうか？

model小規模な場合は、逐一全部読み直してもいいと思うのですが、
たとえば、例として、リモートで複数人のユーザによる同時編集が可能な
テキストエディタの実装を考えた場合、以下の点が問題になると思います。

・更新予定箇所の予測は不可能
・1文字更新が入るたびにすべてを読み直すことは、現実的に不可能

解決方法として、

・push型observerにして、commandパターン的な発想で差分を通知する
・更新IDを保持していて、通知時に保持しているIDからの差分をダウンロードする

あたりを考えたのですが、model,view双方の実装が若干複雑になってしまいます。
modelをシンプルに保ちたい場合、なにか賢い解決策はないものでしょうか？
0825デフォルトの名無しさん2012/07/02(月) 01:36:36.57
テキストエディタなら無限undo実装するんだろう？
それ流用すればいいだけじゃないかな
0826デフォルトの名無しさん2012/07/02(月) 09:49:31.91
>>824
俺だったら後者の差分ダウンロードにして、
リアルタイム同期が必要になったら差分ダウンロード型のままcomet化する

上で出てるけどundoとかもあるから、どのみちヒストリ型にしておいた方が
後々高機能化にも良いんじゃないかな？
0827デフォルトの名無しさん2012/07/03(火) 06:46:41.83
そもそも、画面に表示してなきゃいけない文字も多くないだろうに。
画面から何文字必要なのか送ってやりゃトラフィックも多くはならんだろ。
あと、メモ帳ならベクター系のデータ構造じゃなく、行単位とか
n KByte単位のブロック構造をリストでつないでデータを管理してるはずだろ。
ビューにキャッシュさせて編集が影響したブロックだけ転送してやればいい。
ビューはモデルとの同期は必須だが、別にデータをもってちゃいかんわけじゃないから。
0828uy ◆pdu1UZmweE 2012/07/03(火) 11:20:47.25
ふと思ったんだけど、
オブジェクト指向厨にテトリスを作らせたら

■■
■■　　←このブロックをどこまで細分化する？

↑　ちゃんとやるなら　こうなるんだろうが
class Block_main　← 4つの塊
　class Block_object　← 1個1個のブロック
　end
end

テトリスごときでどんどんソース冗長していくよね

ほんとにオブジェクト指向はゴミだなと実感する
0829デフォルトの名無しさん2012/07/03(火) 11:36:09.49
ゴミが設計するとそうなる
0830uy2012/07/04(水) 10:28:04.55
>>829
この問題はゴミとか関係ないよ

一番いいのはオブジェクト指向では作らないことだが、
オブジェクト指向厨はさてどうするのか
最後まで完璧にオブジェクト指向をつらぬけば>>828こうなる
ある意味、優秀だからこそそこまで貫ける
しかしオブジェクト指向でテトリスかくんだったら途中で妥協して

class Block_main
end
のクラスのみで作ったほうがソースはマシになる
0831デフォルトの名無しさん2012/07/04(水) 10:38:17.31
自分がゴミじゃないとよく喚くゴミ。
0832デフォルトの名無しさん2012/07/04(水) 11:34:26.13
>>830
OOは全てをオブジェクトにするのでなく
問題領域をオブジェクトにするもの

1個1個のブロックをオブジェクト化して何の「問題」を解決するのか？
問題領域を考えずに闇雲にオブジェクト化すれば何の役にも立たないゴミが出来上がる

つまり>>828は貫くとか妥協とかでなく単にOOを理解していない奴が書くゴミ設計
0833デフォルトの名無しさん2012/07/04(水) 13:51:48.30
ブロック同士の相互作用としてテトリスのロジックを記述するのが理想だが俺には無理
0834デフォルトの名無しさん2012/07/04(水) 21:11:36.30
Factoryの生成物として、オブジェクトの配列を返す場合
ファクトリークラスのインターフェイスは、

1 std::vector<IHoge*> createProduct();
2 std::vector<std::shared_ptr<IHoge>> createProduct();

どっちがいいんでしょうか。
心情的には、2にしたいんですが、いかんせんかっこわるい気がします
0835uy ◆pdu1UZmweE 2012/07/04(水) 23:24:42.44
＞832
ほんっとーにわかってないゴミだな
■　←　これひとつで画像オブジェクト1個なわけで
当然その画像オブジェクトを格納する為の変数が必要になる
それを配列で管理するか、クラスオブジェクト*4で管理するかという話

問題領域ｗ　とかいう話ではなくて
お前は問題が発生してから設計しなおすのかよバカ

理想は■1つ1つをクラスオブジェクトにして、x,y座標を持たせてタスクにする事だろう

>>833
そういう事
普通に考えたら面倒で無理だ


優秀な奴ほど完璧にやろうとしてこれにハマる

>>832
みたいなゴミには縁の遠い話か
0836デフォルトの名無しさん2012/07/04(水) 23:34:14.56
と自己弁護を重ねるゴミ
0837デフォルトの名無しさん2012/07/04(水) 23:37:47.68
優秀なやつは適切な妥協ができる人間だから
こんなショーもないことでハマらないよ
0838デフォルトの名無しさん2012/07/04(水) 23:46:04.12
>>832
あぼ〜んになってる奴を擁護するわけじゃないが、
振る舞いを変えたいものは、振る舞いを変える単位で
オブジェクト化すべきで、別にブロックがオブジェクトでも構わんと思うぞ。
例えば、ブロックを単純な点からアニメーションアイコンにしたい場合、
ブロックを差し替え可能なオブジェクトにしておいて、
アニメーションブロックオブジェクトに変えることが出来る。
オブジェクトを使わずベタ書きしていれば、ブロック周りの操作を
書きなおさなきゃならないが、オブジェクトなら新しいファクトリークラスと
アニメーションブロッククラスの作成、そしてそれらを組み合わせるコードだけで済む。

あと、デザパタ本じゃ、理想は文字一つ一つもオブジェクトであるべきだとか言ってたしな。
0839uy2012/07/04(水) 23:54:51.69
>>837
適切な妥協をしてしまう奴は、技術者としては優秀だけど
処理能力的にはスペックが低い

>>838
文字一つ一つもオブジェクトってそれはFONT読み込みとFONTの作り方を知らないただのバカだろ


本当に優秀であれば妥協したテトリス設計と
妥協しないテトリス設計の両方をかけるのであまり俺様には関係ない話
>>838
こういうこの程度の話題に長文書いてしまう奴にとっては、大変重要な問題かもしれないが
コイツはおそらく妥協しないソースコードをかくタイプの奴であろう
そしてテトリス程度（笑）で2000行とか超えるソースコードをかいてしまう
0840デフォルトの名無しさん2012/07/05(木) 00:09:23.31
>>839
おまえよりは優秀
0841uy2012/07/05(木) 00:31:45.21
（笑）
0842デフォルトの名無しさん2012/07/05(木) 06:55:23.86
優秀な香具師は車輪の再発明なんてしません
0843uy2012/07/15(日) 03:06:36.61
キリッ
0844デフォルトの名無しさん2012/07/15(日) 11:12:26.16
ＯＯＰの説明の時に馬鹿の一つ覚えみたく

動物から派生させて、人、クジラ
図形から派生させて、三角形、円

なんて説明するひとって馬鹿なの？

実際にＵｎｉｘ上でプログラムを作成する際に
それらの例があてはまるか？
0845デフォルトの名無しさん2012/07/15(日) 11:23:53.28
>図形から派生させて、三角形、円
描画用ならこれはよくあるぞ
0846デフォルトの名無しさん2012/07/15(日) 11:25:44.58
ねぇよ

ObjectARXみてみろよ

実際にそんな実装はありえない
0847デフォルトの名無しさん2012/07/15(日) 11:28:03.53
>>846
http://msdn.microsoft.com/ja-jp/library/system.windows.shapes.shape(v=vs.100).aspx
0848デフォルトの名無しさん2012/07/15(日) 11:30:48.87
>>846
http://developer.android.com/reference/android/graphics/drawable/shapes/Shape.html
0849デフォルトの名無しさん2012/07/15(日) 11:31:46.13
>>847
インタプリタに興味はない
0850デフォルトの名無しさん2012/07/15(日) 11:36:09.75
>>849
http://doc-snapshot.qt-project.org/5.0/qabstractgraphicsshapeitem.html
0851デフォルトの名無しさん2012/07/15(日) 11:38:45.15
>>849
http://msdn.microsoft.com/ja-jp/library/dd372272(v=vs.85)
0852デフォルトの名無しさん2012/07/15(日) 11:39:34.17
>>850
Ｃ＋＋に興味はない
0853デフォルトの名無しさん2012/07/15(日) 21:34:05.04
>>852
お前に興味はない
0854デフォルトの名無しさん2012/07/16(月) 02:21:07.20
>>834
そのポインタ入ったvectorはどのくらい広範囲にコピーされるの？
0855デフォルトの名無しさん2012/07/16(月) 11:53:47.76
再発明ってなんですか？
0856デフォルトの名無しさん2012/07/16(月) 12:00:33.44
辞書にはない
0857デフォルトの名無しさん2012/07/16(月) 19:47:07.72
>>845
実際問題現実じゃ使いづらい。
aut painter = meta->CreatePathPainter();
painter->PathMove( Vector<2>( 10, 10 ) );
painter->PathTo( Vector<2>( 10, 10 ) );
painter->PathCurve( Vector<2>( 10, 10 ) );

aut painter = meta->CreateFigurePainter();
painter->DrawRect( Point<2>( 0, 1 ), Point<2>( 0, 0 ), Point<2>( 1, 1 ) );

実際こんな感じで描画用インターフェース作って、
描画デバイス別に実装変える形式になるからな。
メタ情報を維持したままデバイスに書き込んでやらないと、
メタ情報が劣化するんで描画速度が落ちたり容量が増えたり不便なことになる。
0858デフォルトの名無しさん2012/07/16(月) 19:57:11.16
>>857
ほっといてやれよ

サンプルコードを動かしてるだけでOOPやってると勘違いしてるｱﾌｫなんてｗ
0859デフォルトの名無しさん2012/07/16(月) 22:51:47.20
>>857
で、現に非常によく使われてることについてどう思うの?
0860デフォルトの名無しさん2012/07/17(火) 04:59:12.42
定義だけしてあって実用性が殆ど無い。
Qtにしろ、Androidにしろ、CanvasやQPainterばかりが強化され
利用されてるのが現実。確かに複合図形をオブジェクト化する事には
メリットがあるが、単純図形をオブジェクトにしたってすぐにCanvasや
QPainterにあたる描画インターフェースに取り残される。
あくまでも入門者向けのおもちゃだ。
0861デフォルトの名無しさん2012/07/17(火) 05:39:03.62
>>859
数えるほどしか使われていないだけで非常によく使われているわけではない
0862デフォルトの名無しさん2012/07/17(火) 11:40:10.25
描画に関してはなぁ。下手にOOP持ち込んで抽象化目指すより、
いつでももっと目指すべきもんがあるからなぁ。速度な。
だって目標とする速度がでなきゃぁ製品としてリリースできないもの。全部ダメだもの。
0863デフォルトの名無しさん2012/07/17(火) 12:20:48.53
http://msdn.microsoft.com/ja-jp/library/dd316578#feedback
こういうのはアリだと思う
カスタム実装不可らしいから描画に関しては中で汚いことしてるんだろうけど
0864デフォルトの名無しさん2012/07/17(火) 20:46:11.45
>>862
ピクセルレベルで仮想関数つかってるならまだしも、大抵問題になる事はないぞ。
DirectXなんてそこらじゅう仮想関数だらけだ。
0865デフォルトの名無しさん2012/07/18(水) 21:17:31.93
>>854
生成以降、vector自体のコピーはないです。
利用者（といっても、自分）にstd::shared_ptrと打たせるのがなんか嫌なだけなんですけど
0866デフォルトの名無しさん2012/07/19(木) 06:42:26.11
スマポの有無ごときで普通格好がどうのとか気にせんから好きにしろとしか言えんな。
個人的には、どっかの名前空間でtypedefしたりする。

namespace SharedPointer
{
　　typedef boost::shared_ptr<::Product> Product;
}

using SharedPointer::Product;
std::vector<Product> product;
0867デフォルトの名無しさん2012/07/22(日) 01:41:09.36
>>865
そんな程度の理由でshared_ptr否定とか、どんだけ規模小さいコード書きしかしてないんだよｗ

キー入力が面倒くさいからって変数を全部1文字にするのと大差ない理由じゃねーかｗ
0868デフォルトの名無しさん2012/07/22(日) 10:53:07.55
>>834
かっこ悪いかどうかを気にするんなら、
俺ならもっと単にシンプルにするな。

Hoge *HogeFactory::create();

こんだけ。もちろん、パラメータを取るオーバーロードメソッドも必要に応じてつくる。
XxxFactory::create()はXxx *を返す。これだけ。
vectorだの、shared_ptrなどは出てこない。

ファクトリ、というクラスの本懐を果たす。
0869デフォルトの名無しさん2012/07/22(日) 11:44:45.94
それ一つあればレンジアルゴリズムと組み合わせられるからshared_ptrバージョンだろうが、vectorバージョンだろうがその組み合わせだろうが簡単に作れそう
std::vector<Hoge*> hs = replicate([](){ return HogeFactory(); }) | copied;
0870デフォルトの名無しさん2012/07/22(日) 12:33:07.38
↑に話題が出てるけど、図形を扱う際のクラスって構成するのがいいの？
直線、円、円弧、楕円、矩形、ペジェ　、、、

これらに存在する属性をすべて包括した、図形クラスをつくって派生させるの？

クラス 図形
{
開始点,終了点、長辺半径、短辺半径、開始角度、終了角度、通過点、通過点数
仮想 描画する(描画先)
};

クラス 直線 : 図形{ 上書　描画する(描画先)}
クラス 円 　 : 図形{ 上書　描画する(描画先)}
・・・

直線には関係ない、長辺半径等が含まれて無駄だと思うんですが・・・

どのような形がセオリーですか？
0871デフォルトの名無しさん2012/07/22(日) 13:43:35.53
ちょっと図形に色々持たせ過ぎじゃね？
図形には本当に基本的なものだけで、あとは複数のサブクラスに共通的な属性を
インターフェイスや中間的なクラスとしたり
纏めたものをひとつの属性として定義して保持じゃないのかな
0872デフォルトの名無しさん2012/07/22(日) 14:09:15.26
>>870
そもそもなんのためにclass化したいんだよ。
普通classを利用する側の都合でclass化するんじゃないのか。
図形classを利用する側に開始点だの通過点だの派生でもたせりゃ十分で不要だろ。
0873デフォルトの名無しさん2012/07/22(日) 14:11:07.19
×図形classを利用する側に開始点だの通過点だの派生でもたせりゃ十分で不要だろ。
○開始点だの通過点だの派生でもたせりゃ十分で図形classには不要だろ。
0874デフォルトの名無しさん2012/07/22(日) 16:26:23.50
クラス 図形 {　仮想 描画する(描画先) };

クラス 直線 : 図形
{
開始点,終了点
上書　描画する(描画先)
};

クラス 円 　 : 図形
{
中心点,長辺半径、短辺半径
上書　描画する(描画先)
};

クラス 円弧 　 : 図形
{
中心点,長辺半径、短辺半径、開始角度、終了角度
上書　描画する(描画先)
};

こんな感じにして、図形の管理はベクタ<図形へのﾎﾟｲﾝﾀ> 図形達で管理しています。

このベクタのある要素の開始点、終了点を変更しようとすると

直線へのポインタ あ ＝ 動的キャスト<直線へのポインタ>(図形達[n])；

あ が NULLじゃなかったら
あ->開始点.X = 1;

となりいちいち、キャストしなきゃいけない

これってどうですか？
0875デフォルトの名無しさん2012/07/22(日) 16:41:56.86
親classのpointerに子の所有権を持たせない。
子固有の操作がしたいなら、子の集合を別途管理しとけばいい。

std::list< Line > lines;
std::list< Ellipse > ellipses;
std::list< Paintable* > figures;

lines.push_back( Line() );
figures.push_back( &lines.back() );

ellipses.push_back( Ellipses() );
figures.push_back( &ellipse.back() );
0876uy2012/07/22(日) 23:53:31.26
相変わらずOOスレはかっわいそうなことになってんな
0877デフォルトの名無しさん2012/07/22(日) 23:57:36.79
で、お前はソフトの1本でもリリースできたか？
早くこらのスレが黒歴史になってコテ付けて書き込んだことを絶対公言できないようになれよ
0878デフォルトの名無しさん2012/07/23(月) 00:12:44.61
>>868
生ポインタをあつかう理由がまったくないのでそのファクトリー関数はshared_ptrを返すように書き換える
0879デフォルトの名無しさん2012/07/23(月) 00:46:46.47
>>874
クラス 描画先
{
public:
　描画する(直線);
　描画する(円);
　描画する(円弧);
　描画する(図形)
　{
　　assert(0);
　}
};

クラス 直線 : 図形
{
　上書 描画する(描画先)
　{
　　描画先.描画する(this);
　}
};
0880デフォルトの名無しさん2012/07/23(月) 00:59:40.57
>>879
なんの解決にもなってないだろ
あとそういう描画にダブルディスパッチはやめたほうがいい
拡張性が下がる
0881デフォルトの名無しさん2012/07/23(月) 01:03:41.02
要素と描画は完全に分離したほうがいいな。

数値はintとかdouble出あつかうとして、点のクラスが必要。

点の集合である基本線のクラス、それらを複数集合した図形クラス。


上記の操作や描画は、それらを利用して処理するようにしたほうがいい。
0882デフォルトの名無しさん2012/07/23(月) 01:05:04.40
直線と円弧を考えると

直線には不要なメンバ（角度、中心点）がありますよね

直線と円弧の親クラスに角度、中心点もメンバとして入れるか否かを聞きたいです。
0883デフォルトの名無しさん2012/07/23(月) 01:07:45.88
直接クラスを相互参照させたダブルディスパッチはやめれ
せめて図形側を抽象化クラスにして単方向の参照にしたほうがいい
あと、ダブルディスパッチするなら"描画する(図形)"は要らんだろ
0884デフォルトの名無しさん2012/07/23(月) 01:09:12.32
>>880
LokiのCyclic Visitorのような物を使えば、拡張性は逆に上がるとおもうけど。
>>879だと描画先だけど、オブジェクトに対する操作をストラテジパターン的に扱えるようになるし。
0885デフォルトの名無しさん2012/07/23(月) 01:11:06.51
>>881
目的をBitmap限定にするならそれでもいいかもしれんが、
バックエンドをOpenGLやSVGみたいなベクターグラフィックにするならアウト。
SSEつかって描画したいってケースでも使えない。
単に描画指示情報と、レンダラーに分離したほうがまだ意味がある。
0886デフォルトの名無しさん2012/07/23(月) 01:13:02.54
>>884
>>874の悩みになんの解決にもなってないって話。
0887デフォルトの名無しさん2012/07/23(月) 01:17:18.70
> クラス 直線 : 図形
横槍だがこの表現自体が気に入らん

クラス ウィンドウ : 図形
とか作るのか？

クラス ウィンドウ : 描画要素
クラス 直線 : 描画要素
でいいだろ。(実際にはPaintableみたいな名前)
図形は図形で境界管理とか位相管理とか別の継承ツリーになるはずだ。
0888デフォルトの名無しさん2012/07/23(月) 01:20:28.23
位相管理？
0889デフォルトの名無しさん2012/07/23(月) 01:24:06.47
>>886

struct line_mover : public visitor
{
　void visit(直線)
　{
　　直線.開始点.x = 1;
　}
　void visit(円){} // visitorで何もしないデフォルトの実装を用意してもよし
　void visit(円弧){}
};

図形.accept(line_mover());

じゃ、だめなん？
0890デフォルトの名無しさん2012/07/23(月) 01:27:31.94
+=か、Moveみたいな移動関数にベクターを与えられたら移動するとか
行列に合わせて拡大するとか。尤も厳密な位相調整はレンダラーの方でやるだろうから
相対的な大きさや位置の調整しかやる事ないだろうけど。
0891デフォルトの名無しさん2012/07/23(月) 01:29:13.13
>>889
ダブルディスパッチ使ってるだけでさっきのと意味合いが全然変わってんじゃん
0892デフォルトの名無しさん2012/07/23(月) 01:32:52.47
>>889
そんな手間の掛る事するぐらいなら>>875でいいだろ
0893デフォルトの名無しさん2012/07/23(月) 01:53:43.91
そもそも問題が具体的じゃないから解決策が定まらない。
まず、何と何に出力したいの？それから何と何から入力したいの？
どういう加工をしたいの？そこをはっきりさせないと万能な解決策なんて無い。
だいたいOOをしたくてコードを書くんじゃなく、ある目的のソフトを書く上でOOを取り入れてるだけな筈だ。
0894デフォルトの名無しさん2012/07/23(月) 18:56:43.98
派生クラスに存在する全ての属性を、親クラスに持たせますか？
クラスAには属性aが存在するが、クラスBには不要な属性
0895デフォルトの名無しさん2012/07/23(月) 19:04:02.18
俺の経験上、そういうのってクラス化が丸ごと間違ってた、
という場合が多々ある。

サブクラスのことを知っている親クラスなんて腐ってるし、
サブクラスのことを配慮した親クラスも結局足をひっぱる。

言ってる意味が分からないならそのままつっぱしればいい。
半年後に気付く。
0896デフォルトの名無しさん2012/07/23(月) 19:24:37.02
Ruby ダックタイピング再考ですね
わかります
0897デフォルトの名無しさん2012/07/23(月) 21:04:58.50
Rubyは蛇足だろ
ダックタイプできない言語のほうがむしろ少数派なんだから
0898デフォルトの名無しさん2012/07/24(火) 02:09:24.52
>>885
なんでアウトかしらんが、全部分離しろ。
0899デフォルトの名無しさん2012/07/25(水) 19:39:31.86
>>898
点の集合体はベクターに出来んだろうが
0900デフォルトの名無しさん2012/07/26(木) 01:40:58.86
任意の方向のベクターに変換すれば。


描画に制限があるからって、データ側が描画側の都合にあわせてどうする。

点集合を描画に必要なデータに変換する機能を作ってそっちにまかせて抽象化しろ。
0901デフォルトの名無しさん2012/07/26(木) 06:19:35.38
非現実的。妄想ならブログに書いてろ。
0902uy2012/07/27(金) 02:29:56.69
まだクラスとか使ってるんだ
0903uy2012/08/03(金) 12:55:23.92
ゲームでOO不要だなってやればやるほど実感する

結局ゲーム内オブジェクトって「物」じゃねーもん
もっといえば「オブジェクト（種類付）」じゃないよ

ゲーム内で使うオブジェクトっていうのは、
種類、区別のないオブジェクトだよ

class Block 　←　はい、この時点で設計間違ってます

class Node　　　←　正解
class Obj　　　←　正解


一は全で、全は一　の状態にさせないと、まともなゲームプログラムはかけない
確実にハードコーディングになる
0904デフォルトの名無しさん2012/08/03(金) 22:50:20.26
uyちゃんゲーム語っちゃってるけど何本売れたの?
0905デフォルトの名無しさん2012/08/04(土) 12:21:51.14
気持ち悪いから二度と話かけんな
0906デフォルトの名無しさん2012/08/05(日) 01:08:26.62
ファイル、テクスチャ、フォント


ゲームじゃ使わないのかもしれんが、これらはオブジェクトとして扱えたほうが良い。
0907uy2012/08/05(日) 06:58:45.91
そういう根拠のないゴミ発言いらない
ゲームで使わないものはない
使い方が違う
0908デフォルトの名無しさん2012/08/05(日) 11:51:52.89
だから何本売れたんだよ
レス数が900を超えています。1000を超えると表示できなくなるよ。