【OOP】オブジェクト指向総合 part3【OOA/OOD】
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
2011/08/10(水) 22:21:57.31実質1
オブジェクト指向は馬鹿ご用達
http://hibari.2ch.net/test/read.cgi/tech/1309621283/
実質2
オブジェクト指向は遅い
http://hibari.2ch.net/test/read.cgi/tech/1293264747/
0002デフォルトの名無しさん
2011/08/10(水) 22:55:08.10ポニーテールうんたらかんたら
0003デフォルトの名無しさん
2011/08/10(水) 23:00:02.670004デフォルトの名無しさん
2011/08/11(木) 22:29:49.490005デフォルトの名無しさん
2011/08/12(金) 23:45:42.76getter否定派(実質2スレ986)
> 一応援護しとくと、getterを排除しとくメリットは、MVCやブロードキャスティングに利用することより、
> オブジェクト自身の判断で値の渡し方を判断するって事が大きい。
> object1.setValue(object2.getValue());なんて呼び出しじゃ、この値の渡し方を判断してるのは、
> object1でもobject2でもない。例えば、object1.toValue(object2);と渡せるようにしてやったとすると、
> 値の渡し方を判断するのは、object1になる。object1は、object2が持ってるメソッドの中で、
> 今の自分の状態で最も適切に渡せるものを選んで渡すことができる。
getter肯定派(実質2スレ991)
> view.reAcquisition(model) って呼び出しだと、値の受け取りを判断するのはviewになる
> reAcquisitionの中でviewはmodelが持ってるgetterの中で
> 今の自分の状態で最も適切に受け取れるものを選んで受け取ることができる
0006デフォルトの名無しさん
2011/08/12(金) 23:56:43.87getterじゃ無理だとは言わないから、
どういうふうに書くのか見せてよ。
Numeric method(Source source)
{
Numeric dest = new PackdNumeric( 255 ); // 255に数値を丸めるオブジェクト
source.toValue( dest );
return dest;
}
0007デフォルトの名無しさん
2011/08/12(金) 23:56:43.92> object1.setValue(object2.getValue());なんて呼び出しじゃ、この値の渡し方を判断してるのは、
> object1でもobject2でもない。例えば、object1.toValue(object2);と渡せるようにしてやったとすると、
そんなコードが使えるのは、object1とobject2が同じ、または互換性があるかのた場合のみだよ。
言い換えると、object1がobject2が何であるか知っている場合のみ有効な例外的な事例だよ。
全く違うもの、例えばobject1は動画再生のコンポーネント。
object2はsetValueとgetValueを持ったスライダークラス。
object1.toValue(object2)
さてこの場合一体何の値をどうするのかでしょうか？
動画の音量？ 動画の再生位置？ 明るさ？
知らない物同士を繋げる場合、getter/setterはどうしても必要。
object1.setValue(object2.getVolume())
0008デフォルトの名無しさん
2011/08/13(土) 00:00:29.76馬鹿だなぁ。getterじゃ難しい例（>>6がそれかどうかは興味無いけど）をいくら挙げても
getterを禁止する理由にはならないんだぜ？
そんな基本的な事すら分かってないアホだから突っ込まれてんだよ
0009デフォルトの名無しさん
2011/08/13(土) 00:11:53.01例がクソコード過ぎて、そっちのツッコミしかできんｗ
255に数値を丸めるオブジェクトではなく、
コンストラクタに与えられた引数に丸めるオブジェクトだろ？
ならばnew PackdNumeric( 255 ); の戻り値は、Numericではなく、
PackdNumeric packer = new PackdNumeric( 255 ); だろ？
で、このオブジェクトを使って丸めるのなら、
Numeric dest = packer.pack(Numeric src);
こうなるだろ？
で、packer.packの実装は
Numeric pack(Numeric src) {
int i = src.getValue();
int ret = i > 255 ? 255 : i;
return new Numeric(ret);
}
だろ。
比較演算子がオーバーライドされていて、Numericからintをとり出さなくても
そのまま比較できるというのなら、そのオーバーライドしているコードにgetterがあるよな？
俺にはこういうコードしかかけん。
Numeric methodが何をする関数なのか全く理解できん。
00109
2011/08/13(土) 00:14:36.53methodとかsourceとかPackedNumericとかtoValueとか
それらの仕事（何をする関数・クラスなのか）を
明確にしてくれ。でないとこんな答えしかできん。
0011デフォルトの名無しさん
2011/08/13(土) 00:16:33.68getとかどんなタイミングでも取得していいようなイベント名にするのか理解できない
現実は特定の瞬間しかダメなんしょ？
ダメなのになんでget作っちゃうの？
いい加減な仕事すんなよ
って程度
できるできないの話だったらできるよやりゃいいんじゃん
ただ、それはかなり仕事いい加減だよね？って話
0012デフォルトの名無しさん
2011/08/13(土) 00:17:22.87インターフェースぐらい守れよ。
Numeric method( Source )
お前のクソコードじゃこれすら守れないんだろ。
0013デフォルトの名無しさん
2011/08/13(土) 00:18:52.61ぜってーgetなんてイベントできねーからｗ
0014デフォルトの名無しさん
2011/08/13(土) 00:19:29.69だから、その前に、
そのコードの意味がわからん。
インターフェースが間違っていると
俺は言ってるだけだ。
クソコード出して、クソコードだけに通用する
話をされても意味はない。
0015デフォルトの名無しさん
2011/08/13(土) 00:20:35.64おいｗ
getterはgetという名前じゃないぞ。
getWidthとかgetHeightとか
具体的な名前だ。
0016デフォルトの名無しさん
2011/08/13(土) 00:21:40.44お前等がほしいのは構造体であってクラスのメソッドじゃないだろ
0017デフォルトの名無しさん
2011/08/13(土) 00:22:32.16StringBufferさん可哀想www
0018デフォルトの名無しさん
2011/08/13(土) 00:23:27.03> getter屋さんはこれをどう書くの？
クソコードのままのそのコードに対して
コメントをするとだな。
そのコードの範囲内に、値を取得（参照）するコードは
一つもないので、getterがでてこないのは当たり前だ。
0019デフォルトの名無しさん
2011/08/13(土) 00:23:45.05-OOP限定-プログラム設計相談室 スレに面白い例があった。
頑張れgetter
void change(RGB source)
{
RGB fillter1 = source;
HSV fillter2;
fillter1 = fillter1.To( new NegativePositive() );//ネガポジ
fillter2 = fillter1.To( new Edge(0.9) );//強調
fillter1 = fillter2.To( new Sepia() );//セピア
fillter1.To( this.color ); //最終結果をメンバーへ
}
0020デフォルトの名無しさん
2011/08/13(土) 00:24:14.59君の所の構造体は mutate した変数を自動的に undo manager に登録してくれるの?
0021デフォルトの名無しさん
2011/08/13(土) 00:25:44.66正論だなｗ
値を取得するコードがないのに
これをgetterを使って書けという方がどうかしてるｗ
0022デフォルトの名無しさん
2011/08/13(土) 00:26:39.10糞コードじゃん
出力結果をさらに入力に使うような変換にはまったく使えないのに
こんなとこ拡張してもなんの意味もない画像処理のがの字も見えてない真性の糞コード
0023デフォルトの名無しさん
2011/08/13(土) 00:28:41.410024デフォルトの名無しさん
2011/08/13(土) 00:31:01.640025デフォルトの名無しさん
2011/08/13(土) 00:32:40.82前スレにでてた、Sourceは、数値か文字列か不定だったろ。
Sourceの状態に従って文字や数値をNumericに取り込ませる処理は何処いったんだよ。
0026デフォルトの名無しさん
2011/08/13(土) 00:33:28.70MVCはMVCの話だろ。
0027デフォルトの名無しさん
2011/08/13(土) 00:33:38.39getter 否定派の人が主張する様な、データストアからデータを取ってくるのにイチイチ
callback を定義しないといけないというのは、あまり直感的じゃないと思うわ
0028デフォルトの名無しさん
2011/08/13(土) 00:34:38.68は？
fillter.To( device );
0029デフォルトの名無しさん
2011/08/13(土) 00:36:25.43> 前スレにでてた、Sourceは、数値か文字列か不定だったろ。
前スレにsourceなんて出てきていません。
0030デフォルトの名無しさん
2011/08/13(土) 00:37:16.13どのスレの話してんの？
0031デフォルトの名無しさん
2011/08/13(土) 00:37:17.87この問題はgetterやsetterをおざなりに用意しちまうことがダメだって話だろ
それとそのコードはなんか関係あるのか？（まったく関係ない気がすんぜ）
オブジェクト間のアクセスを限定することにカプセル化の意味があるってのに
全く無視してgetterやsetter用意しちゃうのはなんかちがくない？って話よ
また、はじめの手順に戻って落ち着いて設計したときにgetterやsetterなんてメソッドできんの？
ってことよな
0032デフォルトの名無しさん
2011/08/13(土) 00:39:44.09>オブジェクト間のアクセスを限定することにカプセル化の意味があるってのに
>全く無視してgetterやsetter用意しちゃうのはなんかちがくない？って話よ
これと
>また、はじめの手順に戻って落ち着いて設計したときにgetterやsetterなんてメソッドできんの？
>ってことよな
これは大分次元の違う話だと思うから、どっちかにした方が良いと思われ
0033デフォルトの名無しさん
2011/08/13(土) 00:39:59.76違う。特定の処理をgetter/setterを使わないで
できると言っているだけで、
じゃあその他の処理は？ 特定の処理ができたからって
getter/setterがいらないという理由にはならないよね。
って言ってるのに、それを無視してgetter否定し続けている
ってのがここまでの流れ。
0034デフォルトの名無しさん
2011/08/13(土) 00:40:58.70いや、設計ででた以外のことしちゃだめだろ？
その他って何？
0035デフォルトの名無しさん
2011/08/13(土) 00:43:22.18あのコードはオブジェクトを使う側は、オブジェクト同士でどう通信してるか隠蔽される。
getter/setterは、隠蔽されてる操作をオブジェクトが使う側が書く。
オブジェクトの判断で値を渡せなくなる。
0036デフォルトの名無しさん
2011/08/13(土) 00:45:07.74たとえばウインドウをリサイズするときにその中のオブジェクトの
リサイズをgetter/setterなくてもできるという主張をしている。
これは正しいとしてもだ。それはリサイズ時にgetter/setterが
必要ないということにすぎない。
その他の処理、たとえばボタンを押したときに
ウインドウのサイズの半分の大きさに小ウインドウのサイズを広げる
などという処理にはgetter/setterは必要。
このように、特定の処理で不要だからとって、
それをもって、すべての処理で不要と言っている
その理屈がおかしいという話。
0037デフォルトの名無しさん
2011/08/13(土) 00:45:55.70いる理由が、バカでも解る以外ない。
0038デフォルトの名無しさん
2011/08/13(土) 00:46:48.88Numeric getNumeric(), int getInt() ... ってgetter作るのの違いだな
型システムがnominalな言語なら前者もありだが、動的型やsubstructuralな言語なら後者だろ
俺は安易なcoercion嫌いだけど
0039デフォルトの名無しさん
2011/08/13(土) 00:49:57.23したらそれ個々のメンバにgetter/setterいれちゃうんじゃなくて
ウィンドウをリサイズするときに必要な情報の取得
（注：取得は取得だが個々の値ではない。あくまでウィンドウをリサイズするという目的の関連の実装である）って関数（イベント）作って
取得できるようにしないといけないんじゃない？
って話だよ
取得は取得
だけどそれはあくまで「ウィンドウをリサイズするために」という目的をもった値の受け渡しでないといけない
って考え方な
0040デフォルトの名無しさん
2011/08/13(土) 00:50:56.50墓穴ほったなｗ
いる理由はあるが、それをお前は馬鹿と言っているだけだろ。
本当に馬鹿なのはお前だ。
少なくともいる理由があることをお前は認めた。
004138
2011/08/13(土) 00:51:10.61Numeric method(Source source)
{
return new PackdNumeric(source.getNumeric(), 255);
}
0042デフォルトの名無しさん
2011/08/13(土) 00:52:43.48違う。intへの変換が必ず起きることは保証されない。
元がStringで受け取り手がStringならStringのまま。
元がintで受け取り手がintならintのまま。
0043デフォルトの名無しさん
2011/08/13(土) 00:57:17.49じゃ書いてみろ。toValueで代用できない方法でな。
0044デフォルトの名無しさん
2011/08/13(土) 00:58:58.44>だけどそれはあくまで「ウィンドウをリサイズするために」という目的をもった値の受け渡しでないといけないって考え方な
それは事前に全て設計が済んでないと無理でしょ
0045デフォルトの名無しさん
2011/08/13(土) 00:59:08.96自立して動いている。
たとえばコンボボックスだと
それ単体で選択したものを変更できる。
そういう場合何かが変更したら、何から何に変更したという
情報を他のオブジェクトに通知すればgetterは不要になる。
理屈ではそのとおりだが、これだとGUIコンポーネントが
持っている情報を変更したら、それごとに○○changeという
イベントが大量に必要になる。
これは現実的ではないので、GUIコンポーネントに何かの
変更が加わったら、change()というイベントを送る
changeの引数には、イベントを発生したオブジェクトsenderが存在する。
void change(Window sender) {
ここでsender.getXX()を呼び出してなにが変更したかを調べる。
}
0046デフォルトの名無しさん
2011/08/13(土) 01:00:38.60> じゃ書いてみろ。toValueで代用できない方法でな。
toValueってsetterじゃんｗ
0047デフォルトの名無しさん
2011/08/13(土) 01:01:50.47後から必要だって言われたら用意してやればいいじゃん
もちろんクラス図書いてなんのイベントなのかちゃんと決まってからね
こういうヌケ穴をボコボコ用意しちゃうと穴作ったぶんだけバグ増えるからね
0048デフォルトの名無しさん
2011/08/13(土) 01:02:01.53コギたねぇけど、こういう形か
Numeric method(Source source)
{
switch( source.getType() )
{
case STRING:
return new PackdNumeric(source.getString(), 255);
break;
case INT:
return new PackdNumeric(source.getInt(), 255);
break;
}
}
0049デフォルトの名無しさん
2011/08/13(土) 01:03:38.750050デフォルトの名無しさん
2011/08/13(土) 01:04:42.78getter が用意されていれば、model を使う側だけ変えれば良いけど、
listener 方式だと model の側も変えないといけない
試行錯誤しながらプロトタイプを作る場合には不向きだね
0051デフォルトの名無しさん
2011/08/13(土) 01:04:52.080052デフォルトの名無しさん
2011/08/13(土) 01:05:16.38ウィンドウのサイズを半分にしたいとき、
ウィンドウにサイズ変更イベントを投げて、
サイズ変更通知用コールバック呼んでもらって、
そのコールバックの中でウィンドウサイズを半分にする、
ってことだと思うけど、そういう実装にしちゃうと、
今度は、ウィンドウを半分のサイズにするって処理が分断されちゃう。
ウィンドウサイズ変更のコールバックが呼ばれたとき、
それが何の引き金で呼ばれたのか分からない。
ウィンドウサイズ半分ボタンが押されたからなのか、
マウスでウィンドウサイズを変えたからなのか、
はたまた他のスレッドで何かウィンドウサイズを変更するような処理が走ったのか、
分からないから、
ウィンドウサイズ半分ボタンが押される→コールバックでウィンドウサイズ半分って流れが確定しない。
結局、getter/setterとの違いは、
変更元の処理が分断するか、変更先の処理が分断するかの差でしかない。
0053デフォルトの名無しさん
2011/08/13(土) 01:07:03.13いや、getterでもModelのインターフェースも変えなきゃならんし、Viewの内部も変えなきゃならん。
0054デフォルトの名無しさん
2011/08/13(土) 01:07:22.73>試行錯誤しながらプロトタイプを作る場合には不向きだね
まあ、前スレでも書いたけどその辺は俺らとマイクロソフトの開発者（ライブラリ開発者という意味で）との違いだね
あくまで俺らは使う側、向こうはライブラリ開発だから当然
こういうのやりたきゃＭＳかＧｏｏｇｌｅにでも入るしかないんじゃない？割とガチで
0055デフォルトの名無しさん
2011/08/13(土) 01:07:45.00getStringとgetInt()がありでgetNumeric()は禁止ってどういう縛りだよ
0056デフォルトの名無しさん
2011/08/13(土) 01:08:56.46toValue(Numeric)が許されてgetNumeric()がダメな理由は？
0057デフォルトの名無しさん
2011/08/13(土) 01:09:46.12イベントモデルやネーミングコンベンションを理解しないといけない
それは getter / setter を理解するより遥かに面倒
0058デフォルトの名無しさん
2011/08/13(土) 01:09:46.70まあ、クラス図とその関連書いてイベント名決めろよｗ
理想の実装に必要なイベントあればいいからよ
そこにずらずら書いてある内容この問題じゃねーべ
0059デフォルトの名無しさん
2011/08/13(土) 01:11:04.24getter を追加するのは一瞬
イベントを定義してコールバックを登録するより遥かにラクチン
0060デフォルトの名無しさん
2011/08/13(土) 01:12:24.74ただ、そのイベント内で、イベントを送ってきた相手の
情報を取得するために、getterがあれば使いやすい。
サイズが変更したときに送ってくるのはサイズ情報だけ。
サイズ変更と同時にその他の情報を知りたい時は
getter使って取得した方が簡潔に書ける。
0061デフォルトの名無しさん
2011/08/13(土) 01:12:29.45サボってねーでちゃんと関連は一箇所に搾れよ
ＭＳのLockUnlock方式でもいいからよｗ（これも一応行儀はいいほうだと思う）
0062デフォルトの名無しさん
2011/08/13(土) 01:12:40.28だれもそんな糞コード書いてねーだろばーか
0063デフォルトの名無しさん
2011/08/13(土) 01:14:00.79効率重視なだけだよ
0064デフォルトの名無しさん
2011/08/13(土) 01:16:35.08class hoge : public hoge_interface
{
window w;
virtual void on_halfsize( SIZE *s ){};
void halfsize_window()
{
};
0065デフォルトの名無しさん
2011/08/13(土) 01:16:40.94じゃーそーゆーことなのかもな
あんまりオブジェクト指向意識して開発もしてねーだろ
（ってそれが悪いとは俺はおもっちゃいないけどね）
0066デフォルトの名無しさん
2011/08/13(土) 01:17:40.44>>56
>違う。intへの変換が必ず起きることは保証されない。
>元がStringで受け取り手がStringならStringのまま。
>元がintで受け取り手がintならintのまま。
0067デフォルトの名無しさん
2011/08/13(土) 01:19:05.68それ、全然答えになってないけど？
getNumeric()ってインターフェース持てない理由を教えてよ
0068デフォルトの名無しさん
2011/08/13(土) 01:19:51.58オブジェクト指向的に書いた方が良い所と、そうじゃない所ってあるじゃん
要は使い分け
0069デフォルトの名無しさん
2011/08/13(土) 01:19:59.00toValueさん涙目www
0070デフォルトの名無しさん
2011/08/13(土) 01:20:56.76getNumeric()から帰ってくるNumericは実際何で値を持ってるんだ？
0071デフォルトの名無しさん
2011/08/13(土) 01:21:34.01あんたが見る先は>>48だけど。
0072デフォルトの名無しさん
2011/08/13(土) 01:22:16.520073デフォルトの名無しさん
2011/08/13(土) 01:23:43.01現実から目を背けるなよ。
007464
2011/08/13(土) 01:23:57.63class hoge : public hoge_interface
{
window w;
virtual void on_halfsize( SIZE *s ){}; //コールバックされるメソッド
void halfsize_window()
{
w.do_halfsize_event( this );//on_halfsizeがコールバックされる
}
void hoge(){} etc...
};
こうなっていたとき、w.halfsize_event() が呼ばれてから直ぐに
on_halfsize() がコールバックされるとは限らない。めぐり巡ってhogeの別のメソッドが先に呼ばれるかもしれない。
これは、hogeの状態の整合性を壊す可能性がある。
windowは安心でも、今度は呼び出し元のhogeが危なくなる。
0075デフォルトの名無しさん
2011/08/13(土) 01:24:19.90//sourceが内部で文字列として持っている場合
Numeric getNumeric()
{
return new Numeric("10");
}
//sourceが内部で整数として持っている場合
void getNumeric()
{
return new Numeric(10);
}
0076デフォルトの名無しさん
2011/08/13(土) 01:26:03.04listener 派：「いやいや、こっちでよろしくやっておくから callback よこせよ」
getter 派：「getter の方がシンプルで良いだろ」
listener 派：「listener の方が内部構造を知らなくていいから良いだろ」
getter 派：「内部の複雑な所に踏み込むつもりはないから getter よこせ！」
listener 派：「何でも楽しようと思うなよ！！」
0077デフォルトの名無しさん
2011/08/13(土) 01:26:05.040078デフォルトの名無しさん
2011/08/13(土) 01:26:38.61本質的にはgetterだったんだよ。
getterってのは、何かを取得する関数全般のこと。
戻り値を返す関数すべてがgetterになりうる。
0079デフォルトの名無しさん
2011/08/13(土) 01:28:19.63Numericの中身が気になるとか、お前本当はオブジェクト指向分かってねーんじゃね？
0080デフォルトの名無しさん
2011/08/13(土) 01:29:31.04それじゃあ>>66は守れないわな。Numericが一旦否応なしにStringか、intに変えるわけだから。
そうでなけりゃ、Numericの中で2つの型をもって、受け取り側で、intとStringのどっちか取り出してもらうか。
あれ？構造体渡してんのとかわんね？しかも後者だと2つのコピーが発生してんじゃん。
0081デフォルトの名無しさん
2011/08/13(土) 01:30:19.54>>79
0082デフォルトの名無しさん
2011/08/13(土) 01:30:52.95getTypeとか作ればいいよ。
0083デフォルトの名無しさん
2011/08/13(土) 01:32:17.32そして>>48のカプセル化が破綻したコードに戻る
0084デフォルトの名無しさん
2011/08/13(土) 01:34:21.64コールバックで num.convertFrom(String) とか num.convertFrom(int) で受け取るのと
new Numeric(String) や new Numeric(int) とで何が違うん？まじで
0085デフォルトの名無しさん
2011/08/13(土) 01:34:24.081回間接的に不必要な変換される事はOO以前に無駄以外の何者でもないんだけど。
まだ数値や文字列程度なら大した問題にはならないが、画像とかだとコストがバカにならない。
0086デフォルトの名無しさん
2011/08/13(土) 01:35:13.56>>66
0087デフォルトの名無しさん
2011/08/13(土) 01:35:35.98>>84
0088デフォルトの名無しさん
2011/08/13(土) 01:38:16.84>>86
0089デフォルトの名無しさん
2011/08/13(土) 01:38:35.24>>87
0090デフォルトの名無しさん
2011/08/13(土) 01:38:57.47>>86
0091デフォルトの名無しさん
2011/08/13(土) 01:39:21.43>>90
0092デフォルトの名無しさん
2011/08/13(土) 01:39:44.07>>85
0093デフォルトの名無しさん
2011/08/13(土) 01:40:11.04>>89
0094デフォルトの名無しさん
2011/08/13(土) 01:40:56.40>>100
0095デフォルトの名無しさん
2011/08/13(土) 01:48:31.140096デフォルトの名無しさん
2011/08/13(土) 01:48:32.4724bit-24bit
16bit-24bit
24bit-16bit
16bit-16bit
各bit数が画像の色深度を表しているものとして、
このbit間の変換が可能なときNumeric固定方式で
何回複製と変換が必要になるでしょうね。
0097デフォルトの名無しさん
2011/08/13(土) 01:58:27.55Image 24bitの場合
24bit-24bit
16bit-24bit コピー
24bit-16bit コピー
16bit-16bit コピー
Image 16bitの場合
24bit-24bit コピー
16bit-24bit コピー
24bit-16bit コピー
16bit-16bit
Image 16bit&24bitの場合
24bit-24bit コピー
16bit-24bit コピー
24bit-16bit コピー
16bit-16bit コピー
0098デフォルトの名無しさん
2011/08/13(土) 02:12:42.93レジストリ
iniファイル
XML
JSON
で相互変換し、互換性がある限り属性を残し、
互換性がない部分は切り捨てと補完って仕様に
なってたら劣化しまくる。
0099デフォルトの名無しさん
2011/08/13(土) 03:05:07.60俺だったらConverterオブジェクトを作るかな。
それであとは
Image24 i24 = conv(i16, IMAGE16, IMAGE24) とか
Image24 i24 = conv(i16, IMAGE24) とか
Image24.convFrom(i16) とか
まあ変換を開始するメソッドなんてのは些細な問題なんでいいとして、
あとはFactoryから、変換元と変換先に対応したConverterオブジェクトを取得
そのオブジェクトが、i16からバイナリイメージをgetし
i24のバイナリイメージに変換してi24を作成してsetする。
こんな感じだろう。
Factoryを使っているのは、変換元から変換先に直接に変換できる
ロジックがあればそれを使い（高速）、できなければ中間形式を経由して
変換するような汎用的なロジックを使えるようにするため。
色深度だけじゃなくて、画像形式まで変換することを考慮した仕様ね。
Imageオブジェクト自身に直接変換ロジックを組み込んでしまうと
汎用性がなくなっちゃうから、変換ロジックは別クラスに分離し、
その別クラスにImageオブジェクトを渡して変換する所が味噌。
そのときImageオブジェクトのバイナリイメージをgetするためのgetterが必要になる。
0100デフォルトの名無しさん
2011/08/13(土) 03:12:44.02未知の形式に対応できないからね。つまりnew Numeric(ABCD)
なんてのは用意されてますか？って話。
conv(Image img) とかいう変換メソッドを作っておいて
Image24も Image16も ImageJPGも、Imageを継承していれば、
元がどんな形式であってもconvに渡せる。
ImageはgetBinaryImageメソッドを持っていて
内部のバイナリイメージにアクセスできる。
あとはconvメソッドは、変換元と変換先形式に対応した変換ロジックを
Factoryを呼び出して取得しそのロジックにImageを渡せばいい。
そのロジックは渡されたImageのバイナリイメージを
getBinaryImageを呼び出して取得し変換する。
0101デフォルトの名無しさん
2011/08/13(土) 03:27:52.49直接継承関係にない形式も変換したいのなら、
conv(Object img) こんなのでもいいけどね。
あとは実行時型情報を使って、型名を取得し
その型名に対応したConverterをFactoryから取得すればできる。
どちらにしろ、Conveterが画像オブジェクトから
データをgetすることには変わらないけど。
これをgetterを使わないで、実装するにはどうすればいいんだろうね。
スマートに実装できるのかな？
0102デフォルトの名無しさん
2011/08/13(土) 04:13:39.220103デフォルトの名無しさん
2011/08/13(土) 07:04:57.37インターフェースでやり取りするべきだよな
でも現実的に使い捨ててもいいようなものを作るなら
getter, setterなんて作らなくてもいいし
完璧に仕上げるべき部分と適当でいい部分を見極めて設計したほうがいいんじゃないのか
十年後も使ってそうな部分は完璧に設計してインターフェース層と
インプリメント層を分けてテストしまくりで作り上げて
なくなってそうな部分はVBであうあう言いながら適当に作っておけよ
客がバカなら外側だけを立派にして中で手抜きするんだ
0104デフォルトの名無しさん
2011/08/13(土) 07:12:29.87本質的にgetter/setterが向く用途はあるのだから
0105デフォルトの名無しさん
2011/08/13(土) 09:24:31.66JavaやC+なんかの手続き型言語は元々そういうもの。
それに、インターフェースを使った情報取得だと、
情報を取得する側のコールバックメソッドの呼び出し順が、
情報取得の対象のオブジェクトの実装に依存するから、
情報を取得する側のオブジェクトの整合性が破壊される危険がある。
これは丁度、getter/setter方式で情報取得の対象のオブジェクトの
メソッド呼び出し順が不定になって危険ってのと逆の現象。
getter/setter→呼び出し先が危険
コールバック→呼び出し元が危険
なわけだから、状況によって使い分けるのが賢い。
0106デフォルトの名無しさん
2011/08/13(土) 10:09:05.52スレッド間の排他、同期、っていう話じゃなくて？
そうじゃなくて、単一スレッドでの、
呼び出し順に正解不正解があるのが問題だとしたら、
それはよくある使いにくいだけの糞クラス。
0107デフォルトの名無しさん
2011/08/13(土) 10:19:46.70そんなのメソッド並べてくれたほうが明らかにわかりいいね
0108デフォルトの名無しさん
2011/08/13(土) 10:24:08.36名前に文句つけてるだけ？
オブジェクト指向理解してないな
イベントが確定してたらgetterなんて作らないだろ
仕様があいまいなまま作ろうとするからgetterなんてできちゃうんだろ
ってかお前は他の人より大分レベル低そうだからそれでいいやｗ
（どうせ微妙な違いだしｗ）
0109デフォルトの名無しさん
2011/08/13(土) 10:28:04.51奴らは画素一つ一つをオブジェクトにするらしいよ
0110デフォルトの名無しさん
2011/08/13(土) 10:28:13.19スレッドは強そうだから、代わりに弱そうなgetter/setterをいじめてるのか
まったく酷い話だ
0111デフォルトの名無しさん
2011/08/13(土) 11:22:21.95image24.pixels24To(new Pixels24To16Converter(image16));
pixels24To: arg.setPixels24(this.pixelBuffer);
setPixels24: this.image16.setPixels16(convertPixels24To16(arg));
とでもするんじゃないの
余計なコピーが発生する以外にgetterと何が違うのか知らないけど
0112デフォルトの名無しさん
2011/08/13(土) 11:37:32.09長すぎる変数名、クラス名、メドッド名、すべて設計の悪さを匂わしてる。
0113デフォルトの名無しさん
2011/08/13(土) 12:41:56.35> new Numeric(String) 、new Numeric(int) みたいなのだと、
> 未知の形式に対応できないからね。つまりnew Numeric(ABCD)
> なんてのは用意されてますか？って話。
Numeric には new Numeric(ABCD) は無いけど convertFrom(ABCD)はあるの？www
自分に都合の良い妄想見てんじゃねーぞ馬鹿が
でだ、Numeric みたいなクラスは immutable であることも珍しくないが、
その場合はどうするんだ？
>>41は immutable でも動くが>>6は動かねーぞ？
0114デフォルトの名無しさん
2011/08/13(土) 12:56:14.31n = new Numeric();
n.setValue(n)
やってることは、これと全く同じだからね。
そして、nから内部の値を取得するもの。
n.getValue() これはもちろんgetterだし、
n.getValueAsString() これも、nを文字列としてgetするからgetter
toValueも結局は、getter/setterを使っているのと一緒。
単に名前にget/setが入っていないだけ。
0115デフォルトの名無しさん
2011/08/13(土) 13:14:24.27イベントの利点はどこに行ったの?
0116デフォルトの名無しさん
2011/08/13(土) 15:02:44.58今年見たコードの中でもぶっちぎりで最低だ。
こいつまだ息してるの？
0117デフォルトの名無しさん
2011/08/13(土) 15:43:54.590118デフォルトの名無しさん
2011/08/13(土) 15:45:35.05通信の実装を表に出すなよ。それじゃgetterと変わらないだろ。
0119デフォルトの名無しさん
2011/08/13(土) 15:47:39.42setterはgetterの選択しないけど？
0120デフォルトの名無しさん
2011/08/13(土) 15:50:37.52未知は未知でいいんだよ。
元々渡す方も受け取る方もそれを前提にしていない。
送り側、受け取り側が新しい形式に対応するばあいは、
拡張したインターフェースを作って、それを実装するか、
必要となる他のインターフェースを新たに実装すれば済む。
0121デフォルトの名無しさん
2011/08/13(土) 15:51:43.37getterさんそこら中にいるから、そんなかのどっかに居るんじゃない。
0122デフォルトの名無しさん
2011/08/13(土) 15:52:39.87実装（コード）とデータの区別ついてる？
表に出すのはデータであって実装ではない。
しかも表に出しているのは、内部データではなくて
外部用のデータだ。
0123デフォルトの名無しさん
2011/08/13(土) 15:55:11.29意味が解からん。setterの中でgetter何度も呼ぶだけ無駄じゃん。
元となるオブジェクトの状態情報を取り出すgetterまで呼ぶんだろ>>48と同じじゃん。きたねぇ。
0124デフォルトの名無しさん
2011/08/13(土) 16:00:19.40> 送り側、受け取り側が新しい形式に対応するばあいは、
> 拡張したインターフェースを作って、それを実装するか、
> 必要となる他のインターフェースを新たに実装すれば済む。
なんかお前の作るクラスは一つのクラスに機能を
たくさん押し込み過ぎになりそうだな。
一つのクラスがたくさんのインターフェースを実装してるんだろ？ｗ
送り側、受け取り側が、どんどん対応形式を増やしていき、
どんなものでも変換できちゃう、
神のようなオブジェクトができあがりそうだｗ
あ、神オブジェクトってのは褒めてないからね。ぐぐってね。
0125デフォルトの名無しさん
2011/08/13(土) 16:19:48.18値を渡す側が、受け取り側に渡す判断基準は、受け取り側から一切アクセスできない。
値をどう渡すかは、飽くまで実装の問題。データではない。
0126デフォルトの名無しさん
2011/08/13(土) 16:22:47.43○値をどう渡すかは、あくまで仕様の問題。
なんもわかってないじゃねーか。
0127デフォルトの名無しさん
2011/08/13(土) 16:24:00.93ねえ渡す側と受け取る側に一切のコントラクトが無くて何をどうやって渡すの?
0128デフォルトの名無しさん
2011/08/13(土) 16:26:20.94"1つの事だけを上手くやれ"って話しらないの？Unix哲学とかであるけど。
画像処理するオブジェクトは、画像のプロフェッショナルでいい。
どういう形で値が渡されようと、内部で処理する分には全て画像として取り扱い、
入力変換以外では、一切画像に関係ないことはしない。
入力変換自体も画像オブジェクト自体が知っているべき事で、
他のオブジェクトが知っていてはいけない。それは画像オブジェクトの領域に
踏み込んだことになる。
素直に画像オブジェクトに変換を任せればいいだけ。
0129デフォルトの名無しさん
2011/08/13(土) 16:27:44.10話が何処とも繋がってないから意味がわからないよ。
0130デフォルトの名無しさん
2011/08/13(土) 16:32:54.05どこにコンストラクター使っちゃいけないって書いてあんの？>>19とか使いまくりじゃん。
0131デフォルトの名無しさん
2011/08/13(土) 16:39:47.60アホか>>48書いたのブロードキャスター君だろwww
0132デフォルトの名無しさん
2011/08/13(土) 16:41:38.84小さいインタフェースっていう観点。メイヤーのOOSCの60ページ目。
モジュール間の接続の数（これは「少ないインタフェース」の話題）でなく、
サイズについて、情報量は小さくすべきである、という話。
アクセッサが悪く見えるとき、
getGreenAppleTable, getAvocadoApricotMap, getStrawberryFigTree
, getOrangeSlot, getPersimmonChunk, geTraspberryThread
みたいなデッカイ粒をやりとりしてて、それが臭いのかもしれない。
もしここが、Javaでいうところのプリミティブ型程度のやりとりだったり、
せいぜいそこに、java.lang.*;程度のクラスのオブジェクトやり取りだったりすると、
カプセル化は守られたような気になるのではないか。
ゲッタセッタが悪く見えるとき、
実はインタフェースの大きさこそが問題だったりして。
0133デフォルトの名無しさん
2011/08/13(土) 16:44:18.19> "1つの事だけを上手くやれ"って話しらないの？
えぇ、だからどんな画像形式にも対応するのは
「一つの事」ではないのですよ。
たくさんの事をやれる、画像のプロフェッショナルなんてのを
作らないようにしようねｗ
0134デフォルトの名無しさん
2011/08/13(土) 16:44:27.97変換が余計にかかるみたいな妄言吐いてたけど、あれってどういう意味？
コールバックなら掛からないとでも？
頼まれもしないのに下らないゴミコード貼りまくってんだから、
コールバックだと変換かからないって示すコード貼ってみせてよ。
0135デフォルトの名無しさん
2011/08/13(土) 16:47:07.88だからその魔法の変換君をどうやって実装するのか知りたいんだけど
俺は画像処理としてのまともな速度とgetterなしを両立するには、データを巨大な値として>>111のように渡すく
らいしか思いつかないんだが、良い方法があるならぜひ教えて欲しい
0136デフォルトの名無しさん
2011/08/13(土) 16:48:34.03>>41>>75と比べて>>48が優れてる点って何だ？www
0137デフォルトの名無しさん
2011/08/13(土) 16:53:22.41脳みそお花畑で何も考えてないだけだと思うぞ。
試しにコード書かせてみたら良い。
0138デフォルトの名無しさん
2011/08/13(土) 16:55:32.55なんでpixel24Toって形式指定してる事がおかしいて思わないの？
コンストラクターが問題じゃなくて、toValueで隠蔽してたpixel24を表にだしてる事が問題なんだけど。
0139デフォルトの名無しさん
2011/08/13(土) 16:57:40.39コンストラクターっつうか>>48になる事が問題なんだろ。
0140デフォルトの名無しさん
2011/08/13(土) 17:00:12.51あれ？馬鹿には>>41は見えないの？
0141デフォルトの名無しさん
2011/08/13(土) 17:01:14.030142デフォルトの名無しさん
2011/08/13(土) 17:02:17.40Numeric getNumeric()
{
return new Numeric("10");
}
object.getNumeric().getInt();
object.getNumeric().getString();
こういう形式になんのか。
0143デフォルトの名無しさん
2011/08/13(土) 17:02:21.84何故コールバックだと変換が余分にかからないのか、とかの
質問に答えた方が良いよブロードキャスター君。
0144デフォルトの名無しさん
2011/08/13(土) 17:03:37.61最初からintが欲しければobject.getInt()だろ馬鹿
0145デフォルトの名無しさん
2011/08/13(土) 17:03:57.90そもそも設計がおかしい。
無理やりgetter排除しようという考えで作るから
設計がねじれるといういい例だ。
0146デフォルトの名無しさん
2011/08/13(土) 17:05:00.680147デフォルトの名無しさん
2011/08/13(土) 17:06:21.24確かに。ちょっと理解できないセンスだよな。
でも面白いからもっとヤレって思ってるw
0148デフォルトの名無しさん
2011/08/13(土) 17:06:46.20いや、それコンストラクターというよりgetNumericが問題だからな。
0149デフォルトの名無しさん
2011/08/13(土) 17:08:08.250150デフォルトの名無しさん
2011/08/13(土) 17:09:50.02なるほど。ではコールバックだと問題が発生しないって
コード使って説明してみて。
0151デフォルトの名無しさん
2011/08/13(土) 17:12:04.21変換オブジェクトは分離させて、
変換前と変換後の形式をもとにFactoryから
変換オブジェクトを取得して変換させろと。
0152デフォルトの名無しさん
2011/08/13(土) 17:14:44.07toValueの実装はどうなってるの？
getNumericはあったけどtoValueはまだ出てなかったよね？
0153デフォルトの名無しさん
2011/08/13(土) 17:16:55.14convertFrom( this.colorArray24 )
this.colorArray24 = colorArray; //colorArrayはconvertFromの引数
convertFrom( this.colorArray16 )
this.colorArray16 = colorArray; //colorArrayはconvertFromの引数
convertFrom( this.colorArray24 )
this.colorArray16 = //変換処理
convertFrom( this.colorArray16 )
this.colorArray24 = //変換処理
0154デフォルトの名無しさん
2011/08/13(土) 17:18:25.83前スレ>>994より
//object1が、内部で文字列として持っている場合
void toValue(Numeric target)
{
target.convertFrom( "100", 10 );
}
//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
target.convertFrom( 10 );
}
0155デフォルトの名無しさん
2011/08/13(土) 17:20:44.95てかコールバックつうよりダブルディスパッチだよな。
グダグダ議論するよりダブルディスパッチの記事調べたほうが早い。
0156デフォルトの名無しさん
2011/08/13(土) 17:24:33.29それってtoValue()の中身？
つまり source.toValue(obj) は source 自体も変える操作ってことでおk？
ぐだぐだ質問してスマン
0157デフォルトの名無しさん
2011/08/13(土) 17:27:46.09変えない。可能か不可能かといえば可能だけど、変える必要なんて無いし。
0158デフォルトの名無しさん
2011/08/13(土) 17:34:00.39まぁ、ダブルディスパッチの問題対応できなきゃgetterなら云々言っても仕方ないわな。
0159デフォルトの名無しさん
2011/08/13(土) 17:42:47.35実際には画像形式が基準ではないんだけどね。
例えば、PNG、BMPがそれぞれ24bit形式で値を持ってるなら
処理の内容変える必要はない。なのでPNGかBMPかで
メソッドを分ける必要もない。問題は、16bitだのアルファ値がつくだの
直接処理に影響する部分。そこだけ変換するインターフェースを持っていればいい。
もし、PNG、BMPを区別する必要があるんならそっちはそっちでインターフェース用意すればいいだけだし、
今まで24bit、16bitとかしか気にしてなかったオブジェクトが、PNGやBMPのインターフェースを持つ必要もない。
森羅万象変換する必要なんて無い。
0160デフォルトの名無しさん
2011/08/13(土) 17:53:11.23| はインターフェースを表すとする
オブジェクト1 | Numeric | オブジェクト2
ダブルディスパッチくんだとこんな感じか
オブジェクト1 | オブジェクト2
まあ増やせばおんなじだよな。
オブジェクト1 | オブジェクト2 | オブジェクト3
0161デフォルトの名無しさん
2011/08/13(土) 17:57:55.15ブロードキャストの話は、MVCの実装方法の話なのになんで
まだ引きずってんの？
0162デフォルトの名無しさん
2011/08/13(土) 17:58:51.73同じにはならねぇよ。
getterのNumericは処理しないだろ。
0163デフォルトの名無しさん
2011/08/13(土) 18:00:12.44Decoratorパターンは効率悪いってこと？
でも画像ならともかく、Numeric -> PackedNumeric では変換は走らないと思うぞ
野暮な突っ込みだが
0164デフォルトの名無しさん
2011/08/13(土) 18:03:37.26PackedNumericに値が入った時点で、丸められるし、
Numericの中身が整数型である保証はない。PackedNumericに
値を渡せられる何か。
0165デフォルトの名無しさん
2011/08/13(土) 18:05:29.020166デフォルトの名無しさん
2011/08/13(土) 18:08:50.43まあ、NumericとPackedNumericが内部で数値を表す
データ構造が違う可能性はあるけど、ちょっと苦しいだろ
速度が気になるところだけ>>6のように書いても良いんだし(>>41の方が記述は短い)
普通にImageだけに絞って話した方が良いと思うぞ
0167デフォルトの名無しさん
2011/08/13(土) 18:13:30.28やっぱりgetterが必要だと思うぞ
0168デフォルトの名無しさん
2011/08/13(土) 18:22:32.89ImageとかNumericどちらかで話をすると、Numeric固有Image固有で
話を進めてくる輩がいるしなァ。あと、別に数値で持ってないってことは珍しくないんだ。
例えば、
Fillter fillter = new Pack(100);
new FileValue( file1, "キー" ).toValue( fillter );
fillter.toValue( new FileValue( file2, "キー" ) );
だと、FileValueは中身ファイルだけ持ってりゃいいし。
>>167
Immutable自体は最初から諦めてるよ。
そんなもんで関数型言語とは相性の悪いやり方だけど。
0169デフォルトの名無しさん
2011/08/13(土) 18:51:43.51substringも、getSubstring()なの？
toStringもgetString()なの？
0170デフォルトの名無しさん
2011/08/13(土) 18:57:20.77俺はてっきりjava.beanの対象となるアクセサや、
プロパティ機能の事だと思ってたけど、そういう事だったんだな。
なるほど、どおりで食い違うわけだ。
0171デフォルトの名無しさん
2011/08/13(土) 19:07:08.01immutableは最適化に有利だしバグ防止に役立つし
諦めるには勿体無い気がするが、それはこちらが関数型言語の方が
好きなせいかもな
>>169
話題がGUIの話とか>>6とかで発散してるからなぁ
getXxxって名前がダサイのは同意するし
M→Vをgetterで書かれたら殺意を覚えるのも事実
0172デフォルトの名無しさん
2011/08/13(土) 19:10:12.76えーと、>>78に答えてあげてください
0173デフォルトの名無しさん
2011/08/13(土) 19:11:48.97プロパティーで書いてみたら入出力逆で気持ち悪くて仕方ないでござるの巻
source.toValue = dest;
0174デフォルトの名無しさん
2011/08/13(土) 19:13:51.00綺麗に見せようとするとC++の source >> dest; になるわな。
0175デフォルトの名無しさん
2011/08/13(土) 19:19:56.05関数型で不可能かというとそうでも無いけどね。
Type toValue(new Type())で引数で入ってきたもんコピーして
返せば良いわけだから。関数型言語なら仮想関数テーブルに当たる
部分を失わせず返す事ができるだろうから行けるっちゃいけるだろう。
0176デフォルトの名無しさん
2011/08/13(土) 19:39:42.16副作用無しならこうだよな
Numeric toValue (factory)
{
return factory(10); // factory は new PackedNumeric(255)をカリー化した関数
}
0177デフォルトの名無しさん
2011/08/13(土) 19:46:03.890178デフォルトの名無しさん
2011/08/13(土) 20:30:59.06> //object1が、内部で文字列として持っている場合
> void toValue(Numeric target)
> {
> target.convertFrom( "100", 10 );
> }
>
> //object1が内部で整数として持っている場合
> void toValue(Numeric target)
> {
> target.convertFrom( 10 );
やってることは、これだけでしょ？
target.convertFrom( "100", 10 );
target.convertFrom( 10 );
0179デフォルトの名無しさん
2011/08/13(土) 20:32:13.84これ、ただのsetterじゃねーの？
Numeric target = new Numeric();
target.setValue(10);
0180デフォルトの名無しさん
2011/08/13(土) 20:38:02.83ダブルディスパッチについてお勉強しまちょうね。
0181デフォルトの名無しさん
2011/08/13(土) 20:40:14.310182デフォルトの名無しさん
2011/08/13(土) 20:47:28.53お前にとっちゃプロパティー替わりじゃなくても全てセッターなんだろうな。
それともこんなふうに書けることを想像してんだろうか。
target.convertFrom = "1000", 10;
引数が2つに増えたぐらいだったら
target.onvertFrom[10] = "1000";
ぐらいは無理やり書けるか。
0183デフォルトの名無しさん
2011/08/13(土) 20:48:56.15へ？ それダブルディスパッチのつもりだったの？
それじゃ、今までの議論全て台無しじゃん。
ダブルディスパッチの、”ダブル” はどこにあるのかな？
もしこれがタブルディスパッチなら、convertFromの引数にthisがあるはず。
0184デフォルトの名無しさん
2011/08/13(土) 20:50:46.22戻り値がなければ全てsetter、戻り値があれば全てgetterらしいから。
0185デフォルトの名無しさん
2011/08/13(土) 20:52:25.72つーか、関数の特殊バージョンが、setter/getterだよ。
オブジェクト内部の状態を変更、もしくは取得する関数で
一番単純にしたものが、setter/getter
0186デフォルトの名無しさん
2011/08/13(土) 20:52:57.82Wikipediaに書いてある事がオマエの全てか。
toValue ← 一回目
convertFrom ← 二回目
別にthisを渡すことがダブルディスパッチの要件じゃねぇし。
0187デフォルトの名無しさん
2011/08/13(土) 20:54:49.88getter排除派は、プロパティー構文として機能しているものをgetter/setterと
呼んでるように見えるけど。
0188デフォルトの名無しさん
2011/08/13(土) 20:57:46.61なんのために実装の話なんてしてるの？
実装の話してる人はレベル低そうなんだけど
設計の話なのになんでいちいち実装出さないと話できないの？
0189デフォルトの名無しさん
2011/08/13(土) 21:00:35.000190デフォルトの名無しさん
2011/08/13(土) 21:01:13.44//object1が、内部で文字列として持っている場合
void toValue(Numeric target)
{
target.convertFrom( "100", 10 );
}
//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
target.convertFrom( 10 );
}
void toValue(Numeric target) ← このNumericの部分の型は
それぞれ違っていなければならないはず。
0191デフォルトの名無しさん
2011/08/13(土) 21:01:29.930192デフォルトの名無しさん
2011/08/13(土) 21:03:01.76Numericはインターフェースで実装は違う。
this渡すダブルディスパッチでも同じだったろ。
0193デフォルトの名無しさん
2011/08/13(土) 21:04:03.850194デフォルトの名無しさん
2011/08/13(土) 21:06:04.32toValueとそれ関連全てを。
一部分出すから誤解を与える。
0195デフォルトの名無しさん
2011/08/13(土) 21:11:52.95//sourceが内部で文字列として持っている場合
Numeric getNumeric()
{
return new StringNumeric("10"); // 内部で文字列で持ってるNumeric
}
//sourceが内部で整数として持っている場合
void getNumeric()
{
return new IntNumeric(10); // 内部で整数で持ってるNumeric
}
0196デフォルトの名無しさん
2011/08/13(土) 21:21:47.71要するに >>160 になるんだよな。
0197デフォルトの名無しさん
2011/08/13(土) 21:22:06.10> Numericはインターフェースで実装は違う。
じゃあ実装を書いてね。動かない実装風のものに興味はないから。
0198デフォルトの名無しさん
2011/08/13(土) 21:26:38.39それはディスパッチ（関数呼び出し）部分の話であって
最終的には、
classA {
public void func(ClassB b) {
ここでbから値を取得して、なにか処理する。
}
}
こういうことをするんだろ？
結局は、bにあるgetterを使って、bの状態を見ながら処理するわけで、
ダブルディスパッチがあれば、getterがいらないってことにはならないんだが？
0199デフォルトの名無しさん
2011/08/13(土) 21:31:35.96ダブルディスパッチはメソッド決定のメカニズムでしかないから、
その決定されたメソッド内で、
getter/setter使うか、それともコールバック式に引数で情報をもらうかは、
また別問題だよな。
0200デフォルトの名無しさん
2011/08/13(土) 22:06:41.98めんどくさいヤツだな。お前以外は解ってるよ。
http://ideone.com/mzkq1
>>199
もともとgetterはいらんし使わんでも書ける。さらに加え、
ダブルディスパッチなどでオブジェクト自身に判断させれば済む事を
外に晒してるってのがナイなって事で、ダブルディスパッチが出たの。
あくまで、getterのロスや、カプセル化の破綻を見せるための一例。
0201デフォルトの名無しさん
2011/08/13(土) 22:14:58.10>>198
0202デフォルトの名無しさん
2011/08/13(土) 22:16:05.41中身見て書いてんのか？
0203デフォルトの名無しさん
2011/08/13(土) 22:16:11.28ディスパッチは呼び出す関数を選択するとこまでのこと。
その後でどうせgetterを使用する。
ディスパッチでgetterがいらないからという理屈で
世の中からgetterすべてがいらないと結論づけるのは馬鹿。
0204デフォルトの名無しさん
2011/08/13(土) 22:16:34.54クラス名、メソッド名ともに、悪い結果しか残してないように見える。
すくなくとも、そうじゃないけないという説得力は伝わってこない。
0205デフォルトの名無しさん
2011/08/13(土) 22:19:07.88>public void func(ClassB b)
じゃなく
>public void func(Stirng a,Point, b)
てな形で直接ClassBの中身渡せばいいよな。
なんのためにワザワザClassBにgetter用意すんの？
0206デフォルトの名無しさん
2011/08/13(土) 22:20:27.62現に >>200 のコードじゃ一切必要ないけど。
0207デフォルトの名無しさん
2011/08/13(土) 22:21:55.69悪い結果って何？
あと補足程度に言うけど、>>200のクラスに今のメソッド以外のメソッドを追加しちゃいけないわけじゃないからな。
0208デフォルトの名無しさん
2011/08/13(土) 22:23:18.60>その後でどうせgetterを使用する。
それは書き方次第だろう。
必要な情報が引数で渡るようにしておいても良いし。
ただどうせ、追加の情報が欲しくなってgetter使うんだけどな。
あと、getter/setter否定派は、
obj1.get〜
obj2.get〜
何か計算
obj1.set〜
obj2.set〜
と言う風に複数のクラス間に処理が跨るときはどうするんだろう。
0209デフォルトの名無しさん
2011/08/13(土) 22:24:53.93不明瞭な単位でのクラスやメソッドを量産し、
いたずらにプロジェクトを混乱させること。
0210デフォルトの名無しさん
2011/08/13(土) 22:25:01.20お前はダブルディスパッチについて調べろ。
ダブルディスパッチとは、ClassB bの型情報をもとに呼び出す関数を
振り分けるのだからClassB がなければディスパッチできん。
classA {
public void func(ClassB b) {
ここで相手がClassBだった場合の処理
}
public void func(ClassC c) {
ここで相手がClassCだった場合の処理
}
}
0211デフォルトの名無しさん
2011/08/13(土) 22:26:25.25そもそも、そのset/get自体は無いからな。
もともとライブラリにあってもまぁそりゃ構わんけど。
結局>>200の方法なら影響しないでしょ。
0212デフォルトの名無しさん
2011/08/13(土) 22:26:37.73> 現に >>200 のコードじゃ一切必要ないけど。
それはそもそも、ダブルディスパッチを使う必要がないコードだからだよ。
0213デフォルトの名無しさん
2011/08/13(土) 22:27:34.68機能単位で別れてんじゃん。それ以外の何者でもない。
0214デフォルトの名無しさん
2011/08/13(土) 22:28:56.62>>186と>>200見たら？
0215デフォルトの名無しさん
2011/08/13(土) 22:30:03.44ダブルディスパッチはなんのために使うもんだと思ってんの？
クラスを識別するためとか、辞書に乗ってそうな説明はすんなよ。
0216デフォルトの名無しさん
2011/08/13(土) 22:36:13.35じゃあ、どう説明すればいいんだよｗ
そこは辞書にのってるような正しい説明を要求するべきだ。
0217デフォルトの名無しさん
2011/08/13(土) 22:37:48.97コールバック方式でも、多段的にコールバックすると、
破綻しちゃうんじゃないの？
何かの設定をするためにコールバックしてもらう。
他の情報も必要になって、その中から更に別のコールバックをしてもらう。
とか。
しかもJavaやC++だと、関数間でローカル変数を持ち越せないから、
処理に必要な一時変数をメンバ変数で受け渡し・・・。
呼び出し先のオブジェクトが多段的なコールバックに 対応している/していない の問題や、
そもそも呼び出し元のオブジェクトの処理がコールバックで分断されてスパゲッティ−化するとか。
一長一短に思えるけどネェ。
素直に、locker = obj.lock(); getter/setter locker.unlock();でも良いと思うけどなぁ。
0218デフォルトの名無しさん
2011/08/13(土) 22:47:04.01ほう。それじゃタイプレス言語じゃ
ダブルデイスパッチは不可能つて事になるな。
0219デフォルトの名無しさん
2011/08/13(土) 22:48:28.08釣りなら釣られたくないし、
本気なら俺が貴方に言うことは何も無い。
0220デフォルトの名無しさん
2011/08/13(土) 22:50:09.60ダブルデイスパッチはどういう時に使うか経験談で
説明も出来ないのに本にこう書いてあったから
間違いないと偉そうに説明するきかい。
0221デフォルトの名無しさん
2011/08/13(土) 22:52:11.490222デフォルトの名無しさん
2011/08/13(土) 22:53:57.90君にとっちゃコマンドパターンの
コマンドも釣りなんだろ。
意識の相違だからどうしょうもないな。
0223デフォルトの名無しさん
2011/08/13(土) 22:55:15.55タイプレス言語ってなに？
変数に型がない言語はあるが、
変数に入っている値に型があるのなら、ダブルディスパッチはできるよ。
ただその場合は、オーバーロードができないから、
関数名を分けるか。
func_b（値がClassBだった場合に呼び出される）
func_c（値がClassCだった場合に呼び出される）
funcという一つの関数で受け取って、
引数を見て、func_b、func_cに振り分けることになるけど。
0224デフォルトの名無しさん
2011/08/13(土) 22:56:29.48オブジェクト間に無駄なオブジェクトが存在するから、
あれを排除しない限りどうやっても無理。
0225デフォルトの名無しさん
2011/08/13(土) 22:57:35.24じゃ中身渡せばいいだけの話だよね。
0226デフォルトの名無しさん
2011/08/13(土) 22:58:44.64分かってるの一人くらいしかいないように見えるが。
一回目に呼ばれたメソッド内で、thisを渡すことにより、
型情報が使えるんで、もいいっかい委譲オブジェクトに対してオーバーロードされたメソッドから、
適切なのを選べるってことだぞ。this渡すことでその型が使えるのがポイントだぞ。
0227デフォルトの名無しさん
2011/08/13(土) 22:59:29.91すまん。ますますもって意味不明になってきたので打ち切りたい。
0228デフォルトの名無しさん
2011/08/13(土) 23:04:57.68中身見て、
switch（中身) {
○ならfunc_○
△ならfunc_△
□ならfunc_□
×ならfunc_×
}
ってコードを書かないといけなくなるけどねｗ
0229デフォルトの名無しさん
2011/08/13(土) 23:05:53.73だからそれじゃ静的型付け言語じゃないと出来ないだろ。
それからダブルデイスパッチは、マルチディスパッチや
シングルデイスパッチと同じ領域の話だ。
0230デフォルトの名無しさん
2011/08/13(土) 23:07:08.69>>200のコードのどこにそんな記述があった？
0231デフォルトの名無しさん
2011/08/13(土) 23:08:30.96出来なくはない。
ただし動的型付け言語だと、オーバーロードができないんで
swtichの嵐になる。
switchの嵐をどうせ書くのなら、
ダブルディスパッチなんてテクニックを使わずに、
呼び出し部分でswitch使って切り替えればすむから
意味が無いって話になるだけ。
0232デフォルトの名無しさん
2011/08/13(土) 23:10:05.02だから、頭使わずとりあえず書けるgetter/setterを書きまくるわけだ。
0233デフォルトの名無しさん
2011/08/13(土) 23:13:19.91ならねぇよ。
なんでダブルディスパッチなのか解ってないだろ。
object1とobject2でダブルディスパッチする場合、
お前の書いたswitchがobject1の仮想関数テーブルになる。
で、2回めのディスパッチがobject2の仮想関数テーブルになる。
関数のシグニチャがどうのは関係ないんだよ。
0234デフォルトの名無しさん
2011/08/13(土) 23:13:37.82またある人はなるべく複雑に、特殊な方法を選んで記述する。
0235デフォルトの名無しさん
2011/08/13(土) 23:30:10.81俺もそう思ってた
今回の議論でメソッド名なんてどうでもいいだろ
機能の問題
と思ってたんだけど、フィールドを取得するメソッド名の先頭にgetをつける、つけないを議論している人もいたのかw
0236デフォルトの名無しさん
2011/08/13(土) 23:31:11.45カプセル化される対象は、値を渡す側のオブジェクトの判断結果。
送り側が、受け取り側に渡した時点で、受け取り側には"値として"送り側の
判断結果が渡らない。受け取り側がわざわざフラグだの何だのにその結果を
記録しない限りは、その時点で送り側の情報は消えるんで、いくらコールバックしようが
カプセル化の破綻にはつながらないよ。
0237デフォルトの名無しさん
2011/08/13(土) 23:38:00.26そもそもダブルディスパッチというのは
こういうことをしたい時の話だ。
class Foo {
void func(Int i) {なんかの処理}
void func(Long l){なんかの処理}
}
※Int も LongもNumericを継承している。
Foo foo = new foo();
foo.func(new Int(1)); // OK ただのオーバーロードの呼び出し
foo.func(new Long(1)); // OK ただのオーバーロードの呼び出し
Numeric n = ？ // Int もしくは Long 実行時にならないとわからない。
foo.func(n); // NG なぜならこの場合は静的に決まるのでfoo.func(Numeric)と解釈される。
やりたいことは本質的にはこれであり、ダブルディスパッチは
これを型あり言語で実現するために用いられるテクニック。
0238デフォルトの名無しさん
2011/08/13(土) 23:38:32.56頑張ろうとした所でオーバーライドがないのだからswitchは絶対に必要になる。
実装は以下のようになる。
class Foo {
void func(v) {
switch(vの型は？) {
case(Int) {func_int(v);break;}
case(Long) {func_long(v);break;}
}
void func_int(v) {なんかの処理}
void func_long(v) {なんかの処理}
}
言い換えるとダブルディスパッチというのは、言語が持っている
オーバーロード機能（シグネチャによる呼び出し関数の自動振り分け）をうまく利用して、
switchコードによる手動振り分けコードを書かなくてよくしたものである。
0239デフォルトの名無しさん
2011/08/13(土) 23:49:59.90×頑張ろうとした所でオーバーライドがないのだからswitchは絶対に必要になる。
○頑張ろうとした所でオーバーロードがないのだからswitchは絶対に必要になる。
0240デフォルトの名無しさん
2011/08/13(土) 23:55:26.50なんでfunc_int,func_longをint型のオブジェクト、long型のオブジェクトが呼び出しちゃいかんのだ。
形式とかどうでもいいから、その結果発生する問題を言ってくれ。
0241デフォルトの名無しさん
2011/08/13(土) 23:58:51.59よく見たらコイツ間違えてんじゃん。
なんでFooの中でfunc_intとfunc_long呼び出してんだよ。
func(v)の中で呼び出すのは v.func_CategoryBar( this ); だろ
0242デフォルトの名無しさん
2011/08/14(日) 00:00:50.12偉い説法してるくせに何で"ディスパッチ"なのか理解してないのな。
0243デフォルトの名無しさん
2011/08/14(日) 00:08:47.65A.prototype.handleCategoryBar = function(bar){ ・・・処理・・・ }
B.prototype.handleCategoryBar = function(bar){ ・・・処理・・・ }
C.prototype.dispatchCategoryFoo = function(bar){ bar.handleCategoryBar( this ); }
var bar = new C();
bar.dispachCategoryFoo( new A() );
bar.dispachCategoryFoo( new B() );
0244デフォルトの名無しさん
2011/08/14(日) 00:14:40.92これは静的言語によるダブルディスパッチの
実装を書いたんじゃないよ。
ダブルディスパッチでやりたいこと(>>237)が何かと
それを動的言語(>>238)で実装した場合の話。
Javaっぽく見えるだろうけど、別にJavaということではない。
あとひとつ書き忘れた、静的言語によるダブルディスパッチは
実行時の型情報をしようしてないってことに注意。
実行時の型情報を使わないという制約のもとに、
「やりたいこと」を実現するときに使うのがダブルディスパッチ
0245デフォルトの名無しさん
2011/08/14(日) 00:18:26.04じゃあ貼ってみる。
>>6でやってるのはsetだからgetterだけでは効率よく書けないだけで
setterで書くとこんな感じ。
Numeric method(Source source)
{
Numeric dest = new PackedNumeric( 255 );
dest.setValue(source);
return dest;
}
//destが内部で文字列として持っている場合
void setValue(Source source)
{
this.x = source.getString();
/* 丸め処理 */
}
//destが内部で整数として持っている場合
void setValue(Source source)
{
this.x = source.getInt();
/* 丸め処理 */
}
0246デフォルトの名無しさん
2011/08/14(日) 00:23:01.29それ違ってるぞ。
最終的に実行したいのは、bar（Cクラス)で定義されたメソッドだよ。
まずCクラスに、
「引数にAクラスが渡された時の処理」
「引数にBクラスが渡された時の処理」を書く
そこがスタート。
あとはその処理を呼び出す方法を書く。
静的言語で実装したらそれがダブルディスパッチになる。
0247デフォルトの名無しさん
2011/08/14(日) 00:25:12.63結局わざわざget〜書く"必要ない"よな
0248デフォルトの名無しさん
2011/08/14(日) 00:32:06.68いや、>>243であってるよ。A,B,Cの比率を変えたら分り易くなるかもしれん。
A.prototype.handleCategoryBar = function(bar){ ・・・処理・・・ }
A.prototype.handleCategoryHoo = function(hoo){ ・・・処理・・・ }
B.prototype.handleCategoryBar = function(bar){ ・・・処理・・・ }
B.prototype.handleCategoryHoo = function(hoo){ ・・・処理・・・ }
C.prototype.dispatchCategoryFoo = function(foo){ foo.handleCategoryBar( this ); }
D.prototype.dispatchCategoryFoo = function(foo){ foo.handleCategoryHoo( this ); }
var bar = new C();
var hoo = new D();
bar.dispachCategoryFoo( new A() ); //AのhandleCategoryBarが呼ばれる
hoo.dispachCategoryFoo( new A() ); //AのhandleCategoryHooが呼ばれる
bar.dispachCategoryFoo( new B() );//BのhandleCategoryBarが呼ばれる
hoo.dispachCategoryFoo( new B() );//BのhandleCategoryHooが呼ばれる
0249デフォルトの名無しさん
2011/08/14(日) 00:34:06.630250デフォルトの名無しさん
2011/08/14(日) 00:36:14.73動的型でダブルディスパッチの例
言語はPythonっぽい何か
def method(src):
dest = Numeric()
src.toValue(dest)
return dest
def toValue(self, dest):
dest.hiQualityConvert(self)
# 他にlowQualityConvert, normalQualityConvert等が在り
# srcが自分の持ってるデータの精度によって選べる
def hiQualityConvert(self, src):
self.num = src.toString()
# destが文字列でデータを保持するときはtoString()を呼び出す
# 整数で保持するときはtoInt()を呼び出す
0251デフォルトの名無しさん
2011/08/14(日) 00:36:50.860252デフォルトの名無しさん
2011/08/14(日) 00:36:57.79逆にお前の言う静的ダブルディスパッチとやらを見てみたいわ。
今の話だと、単なるオーバーロードにしか見えんし。
0253デフォルトの名無しさん
2011/08/14(日) 00:39:44.96だから何で自分を渡す必要があんの？わざわざtoStringとか呼び出したりしてさ。
0254デフォルトの名無しさん
2011/08/14(日) 00:44:21.75def toValue(self, dest):
dest.hiQualityConvert(self,self.num)
def hiQualityConvert(self, num):
self.num = num
これでいいじゃん。
0255デフォルトの名無しさん
2011/08/14(日) 00:50:28.36srcとdestは常に同じ型の数値情報を持つのか？
0256デフォルトの名無しさん
2011/08/14(日) 00:53:54.05それを決めてんのは、def hiQualityConvert(self, num):というシグニチャじゃないのかい。
hiQualityConvertはsrcの時でも、srcがどういうメンバーを持っているか全く決めてないのかい？
toStringも失敗する可能性があるって事だよね。
0257デフォルトの名無しさん
2011/08/14(日) 00:59:59.37静的型言語の視点で動的型言語を語られてもなぁ……
0258デフォルトの名無しさん
2011/08/14(日) 01:03:47.86ダックタイピング可能だったとしても、何を持たなければいけないかルールを決めとくんじゃないのかい？
object.abs()を呼び出す事が解ってんのにabsを持たせることってルール決めないの？
0259デフォルトの名無しさん
2011/08/14(日) 01:19:58.28なんで渡す側が、intかStringに変換せにゃならんの？
受け取り側は、>>200の例のようなストリームで、文字列とも
数値とも関係ない形式かもしれないのに。
0260デフォルトの名無しさん
2011/08/14(日) 01:26:58.91基本的に、そういう保証が必要な場合は静的型付け言語を使う。
ObjC には protocol という Java の Interface みたいな仕組みがあるけど、別に強制じゃないし、
respondsToSelector: みたいなリフレクションの機能もあるけど、必須じゃないし、
テストケースを書きまくるという手もあるけど、実際そうするかどうかは人によるし。
静的言語と同じ仕組みを動的言語に求めるのは筋違い。
0261デフォルトの名無しさん
2011/08/14(日) 01:37:18.13> 逆にお前の言う静的ダブルディスパッチとやらを見てみたいわ。
> 今の話だと、単なるオーバーロードにしか見えんし。
実際やりたいことは単なるオーバーロードだよ。
だけど、静的言語のオーバーロードってのは
静的に呼び出すメソッドが決まるから、
値が動的に決まる場合には使えない。
それを突破する技術がダブルディスパッチなんだよ。
ダブルディスパッチが目的じゃない。
実行時に動的に決まる値でメソッドを切り替えられればいい。
それができない静的言語の欠点から生まれたのがダブルディスパッチ。
動的に決まる型を知ることができるなら不要な技術だよ。
今はリフレクションによって動的に決まる型から
処理を分けることも当たり前になってしまったけどね。
動的な型で判断することが許されるならダブルディスパッチは不要。
0262デフォルトの名無しさん
2011/08/14(日) 04:24:44.92getterのポテンシャルを追求してみた
言語はOCaml
type t = [`Int of int | `String of string]
class numeric (num:t) = object
method value = match num with
`Int x -> float_of_int x
| `String x -> float_of_string x
end
let convert src = new numeric src#value
let _ =
let src1 = object method value = `Int 1 end in
let src2 = object method value = `String "2" end in
let dest1 = convert src1 in
let dest2 = convert src2 in
print_float dest1#value;
print_float dest2#value
0263デフォルトの名無しさん
2011/08/14(日) 04:31:36.33getterはオブジェクトの状態を
取り出す方法でしょ。
それを否定する意味が分からないんだけど。
0264デフォルトの名無しさん
2011/08/14(日) 04:40:50.33int sum = a.getValue() + b.getValue();
こういうのを、
int value1;
a.sendValue(function (value) {value1 = value});
int value2;
b.sendValue(function (value) {value2 = value});
int sum = value1 + value2;
こんなふうに書く流派があるらしい。
0265デフォルトの名無しさん
2011/08/14(日) 04:49:05.47何のために？
0266デフォルトの名無しさん
2011/08/14(日) 04:51:59.32しらん。なんかgetterがなくても実装できるって話が
いつの間にか無くす事が目的になってしまって
getter不要原理主義者になったみたい。
0267デフォルトの名無しさん
2011/08/14(日) 08:46:55.04>>39
0268デフォルトの名無しさん
2011/08/14(日) 08:53:19.08横から見てたら、おまいらが面白半分で彼を煽って、
細道に追い込んで言ってしまったようにも見えるよｗ
0269デフォルトの名無しさん
2011/08/14(日) 08:56:47.04話してるうちに目的とか頭から全部消えてるじゃん
超馬鹿にしかみえないからそこんとこよろしくな！
0270デフォルトの名無しさん
2011/08/14(日) 08:58:38.64まぁ、そんなこったろうと思ったけど。
0271デフォルトの名無しさん
2011/08/14(日) 09:00:11.59馬鹿みたい
だいたいなんでオブジェクト指向の話でコードが必要なんだよ
死ね、早く死んじまえ
自害しろ
0272デフォルトの名無しさん
2011/08/14(日) 09:54:19.64きみのお家に警察来るよ。
0273デフォルトの名無しさん
2011/08/14(日) 10:18:48.59死ねで警察動いた事無いってｗ
0274デフォルトの名無しさん
2011/08/14(日) 10:23:31.82そこまで話し合うような内容か？
当たり前だけど、状況によって使い分ければ良い話ってだけなのに。
Windowsで言えば、ディバイスコンテキストはsetter/getterだし、
ウィンドウ関数ははコールバック方式だし、既に混在している。
コールバックでロックしてもらって、その中でsetter/getterって設計も有りなわけで。
0275デフォルトの名無しさん
2011/08/14(日) 10:42:13.220276デフォルトの名無しさん
2011/08/14(日) 10:45:44.110277デフォルトの名無しさん
2011/08/14(日) 10:48:49.26俺はやっぱり、お前等が彼を追い詰めたんだと思うよｗ
0278デフォルトの名無しさん
2011/08/14(日) 10:53:25.260279デフォルトの名無しさん
2011/08/14(日) 11:04:46.78言語的保証以前にある程度決めるだろ。
チームの取り決めとかじゃなくてさ、個人で組んでる時でもさ。
四則演算のあるメソッドにわざわざシーケンス型オブジェクト突っ込んだりすんの？
0280デフォルトの名無しさん
2011/08/14(日) 11:09:24.98目的の理解はそう離れてないが、
理解の根本がズレてる。
オーバーロード使わんでも結局>>248の書き方になるわけだし、
リフレクションやら仮想関数テーブル以外の具体的な型情報は
一切必要ない。
0281デフォルトの名無しさん
2011/08/14(日) 11:12:08.23初めて見るコードだな。
前スレにあったの？
0282デフォルトの名無しさん
2011/08/14(日) 11:14:50.09getterを使うとカプセル化されてるハズの中身がボロっとそとに出るんだけど、
getter派の人は何が何でもそこから目を背けたいんだってさ。
0283デフォルトの名無しさん
2011/08/14(日) 11:18:33.61戻り値を返さず引数を取るメソッド = setter
戻り値を返す関数 = getter
なんだってさ。
他の人はプロパティーに当たるものをsetter/getterって呼んでるはずなんだけど。
0284デフォルトの名無しさん
2011/08/14(日) 11:23:19.95操作の一種と取る人が混ざってて、さらにイベントなる物の解釈が
バラバラで話が発散してるだけだろ。
0285デフォルトの名無しさん
2011/08/14(日) 11:24:21.87ダブルディスパッチではその問題の解決にはならないけどね
switchをどこに押し付けるかだけの違い
0286デフォルトの名無しさん
2011/08/14(日) 11:25:31.49お前、カプセル化の意味勘違いしてね？
中身を一切出さないのがカプセル化じゃないよ。
出さなくていいものを出さないのがカプセル化であって、
getterはただのインターフェース。
そしてgetterは中身をそのまま出す必要もない。
中身が文字列であるものを、数値に変換して出すのもgetterでいい。
0287デフォルトの名無しさん
2011/08/14(日) 11:27:12.94結びついているものって勘違いしているのかｗ
getterの実装を
private int value;
int getValue() {
return value;
}
しか知らんのだろうなｗ
0288デフォルトの名無しさん
2011/08/14(日) 11:29:40.73どのオブジェクトに、どの情報を渡すか判断が外に溢れてんのはどう思ってんだい？
そもそも、カプセル化は人間のためじゃなく拡張性のためだぞ。
0289デフォルトの名無しさん
2011/08/14(日) 11:30:26.76> オーバーロード使わんでも結局>>248の書き方になるわけだし、
お前、あのコードがややこしいと思わんのか？
一ついいことを教えてあげよう。
同じ事をするのに、説明が必要になるコードは
悪いコードという原則だ。
動的言語では、説明が不要なコードを書くことができる
>>248のようなごちゃごちゃした書き方をする必要がない。
0290デフォルトの名無しさん
2011/08/14(日) 11:33:27.60> どのオブジェクトに、どの情報を渡すか判断が外に溢れてんのはどう思ってんだい？
漏れてない。
渡す情報は、getterを書いたものだけ。
それ以外の情報は外部に漏れていない。
それがカプセル化。
お前もしかして、private変数全てに
getter書いてるんじゃないかｗ
0291デフォルトの名無しさん
2011/08/14(日) 11:35:26.71ああ、お前、普通にぐぐれば出てくるようなことも解らなかった
あの馬鹿だったのか。
0292デフォルトの名無しさん
2011/08/14(日) 11:37:28.03getterに書いたものとかそういう話じゃない。
getterに公開してるものに、内部で持ってりゃ十分のものがあるって事だよ。
特にどのオブジェクトにどういう形式で渡せとかな。
0293デフォルトの名無しさん
2011/08/14(日) 11:37:40.49setterの中に処理を書くと怒り出すｗ
「setterは与えられた引数をprivate変数に格納する」
以外のことをしてはいけないと思っている人。
たとえば、0以上の値しか入れられないsetterってのもあるんだよ。
void setValue(int i) {
if(i>=0) {
value = i;
} else {
例外送出
}
}
こうのもあり。
0294デフォルトの名無しさん
2011/08/14(日) 11:38:35.94> getterに公開してるものに、内部で持ってりゃ十分のものがあるって事だよ。
内部で持っていれば十分だと判断したのなら、
getter書かなければいいだけ。
お前は何を言っているんだ？
0295デフォルトの名無しさん
2011/08/14(日) 11:40:05.34知らない人は居ないだろう。
0296デフォルトの名無しさん
2011/08/14(日) 11:40:19.860297デフォルトの名無しさん
2011/08/14(日) 11:40:59.39> getterはただのインターフェース。
アンタは聡明。
0298デフォルトの名無しさん
2011/08/14(日) 11:41:17.15そんな程度の低い話はしてないよ。
0299デフォルトの名無しさん
2011/08/14(日) 11:42:48.59誰と勘違いしているんだ？
繰り返すが、ダブルディスパッチは目的じゃない
やりたいことは、オーバーロードでしか無い。
静的な型で呼び出すメソッドを決めるオーバーロードではなく、
動的な型に応じて、呼び出すメソッドを決めるオーバーロードだよ。
この2つは静的か動的かの違いしか無いのだから、
本来どちらも同じように呼び出しできるべきもの。
object.method(value);
どちらであってもこの形式で書くのが一番説明が不要になる。
0300デフォルトの名無しさん
2011/08/14(日) 11:44:50.23getter不要信者は、
ダブルディスパッチの実装でgetterが不要だから、
すべての事象でgetterは不要とか
わけのわからんことを言い出す。
そして、値をgetterを使わずにコールバックで取得するという
>>264のような実装をしてるんだよね。
0301デフォルトの名無しさん
2011/08/14(日) 11:46:43.89正確に言えば、getterの代わりに
ダブルディスパッチを使うことで代用が可能と
言っているよね。
結論は一緒。
0302デフォルトの名無しさん
2011/08/14(日) 11:51:09.98前者の主張が適切な場合は多いが、見境なくダブルディスパッチ使いまくるとか
それこそ拡張性ゼロのクソじゃん
0303デフォルトの名無しさん
2011/08/14(日) 11:52:00.04>>262
0304デフォルトの名無しさん
2011/08/14(日) 11:53:09.75どのオブジェクトにも、すべてのpublicメソッドを公開する。
公開したくないpublicメソッドがあるなら、
メソッドを少なくしたインターフェース型へキャストする。
0305デフォルトの名無しさん
2011/08/14(日) 11:54:00.32そう。別の問題。ダブルディスパッチはメソッド呼び出しまでの話で、
その後getter使って処理を行う〜なんことは普通に行われてる。
なのになぜかgetter不要信者がいる。
0306デフォルトの名無しさん
2011/08/14(日) 11:59:28.53結局のところ最後はgetter使う、つまりgetter必要でFA？
0307デフォルトの名無しさん
2011/08/14(日) 12:00:26.30AはBというオブジェクトにはpublic変数の一部分だけを
見せたいと制限かける場合はどうするの？
あとBというオブジェクトからは使用できるpublicメソッドを
制限したい場合はどうするの？
Aは自分自身が、どのオブジェクトから参照されているかを
知るべきだと思うが。
0308デフォルトの名無しさん
2011/08/14(日) 12:02:19.10全てダブルデイスパッチで解決するとは言ってない。
getterより効率のいい一手段だ。
substringとかgetterじゃないだろって話は何度も出てるでしょ。
0309デフォルトの名無しさん
2011/08/14(日) 12:03:58.34ただし中身を知りたい場合は、別の方法で教えます。
教える情報はどちらも一緒です。
これはgetterを無くす意味は無いと思うｗ
0310デフォルトの名無しさん
2011/08/14(日) 12:05:22.09> substringとかgetterじゃないだろって話は何度も出てるでしょ。
じゃあ、substringを使う場面でよく使われる
length()はgetterなの？ getterじゃない？
0311デフォルトの名無しさん
2011/08/14(日) 12:06:48.040312デフォルトの名無しさん
2011/08/14(日) 12:09:50.03int value1,value2,value3;
a.sendValue(
function (avalue) {value1 = avalue},
function (avalue1,avalue2) {value2 = avalue1;value3=avalue2}
);
0313デフォルトの名無しさん
2011/08/14(日) 12:11:31.12だから何なの?
sendValueを呼んでるのが値を受け取る側である以上、実装が違うだけのgetter
0314デフォルトの名無しさん
2011/08/14(日) 12:13:58.55じゃあprivateメンバーも後で別の形で出てくるんだから
publicのgetterで公開してても一緒だね。
0315デフォルトの名無しさん
2011/08/14(日) 12:14:02.65getterだと効率悪い場合があるという理由だけで禁止するなら、
そもそもOOPなんて効率悪いもん使わず全部Cで書けよ馬鹿www
0316デフォルトの名無しさん
2011/08/14(日) 12:15:54.36別に無名関数の中にがっつり処理書いていいんだぞ。
0317デフォルトの名無しさん
2011/08/14(日) 12:16:29.64コールバック方式は、普通は非同期処理に使うもんだ。
同期処理前提なら、たとえ排他処理処理が必要だったとしても、
Lock→getter/setter→Unlockの方が喜ばれる。
0318デフォルトの名無しさん
2011/08/14(日) 12:23:14.70このスレで一度もそんなコード見なかったけど？
簡単なのは、メソッド内で完結してる場合だけでメソッド跨がったら
引数で渡せば十分ってのばっかり。
0319デフォルトの名無しさん
2011/08/14(日) 12:31:49.45GUI周りがコールバック方式になってるのは、
GUIがイベントドリブンで非同期処理だから、
「仕方が無く」コールバック方式になってるってだけだよ。
別にダブルディスパッチがしたいわけでも、カプセル化がしたいわけでも無い。
単に非同期って理由でそうなってるだけ。
同期的でgetter/setterで書けるようなものを、
わざわざ非同期で使われるコールバックを持ち出して実装するのは、
乱用でしかない。
0320デフォルトの名無しさん
2011/08/14(日) 12:35:57.18自分自身がどのように利用されるかを制限したら、再利用の可能性が下がる。
実装を置換できる抽象クラスと同様に、利用者も置換できるようにするのがいい。
0321デフォルトの名無しさん
2011/08/14(日) 12:37:42.45>>6より>>41の方が簡潔だろ？
お前は「効率が〜」の馬鹿のひとつ覚えで否定してるけどな
そしてOCamlだったら効率すら犠牲にせずgetterで書ける件
0322デフォルトの名無しさん
2011/08/14(日) 12:37:51.04> 全てダブルデイスパッチで解決するとは言ってない。
> getterより効率のいい一手段だ。
ダブルディスパッチを使うのは、実行時の型で処理を
分岐させたいという目的のために使うのであって、
getterの代わりに使うものでも、getterと比較するもんでもねーよ。
0323デフォルトの名無しさん
2011/08/14(日) 12:47:09.17＞Lock→getter/setter→Unlockの方が喜ばれる。
いや、それはちょっとどーかと・・・
0324デフォルトの名無しさん
2011/08/14(日) 12:47:37.28> 別に無名関数の中にがっつり処理書いていいんだぞ。
じゃあ、それでいいから、
元々の例、
int sum = a.getValue() + b.getValue();
をgetter使わずに、無名関数を使って
これよりもシンプルに、書いてくれよ。
当たり前だがaとbの値を使って
最終的な答えはsum変数に入れること。
0325デフォルトの名無しさん
2011/08/14(日) 12:51:29.740326デフォルトの名無しさん
2011/08/14(日) 13:10:23.56intで受けとらにゃならんの？
オブジェクトで受け取りやいいのに。
0327デフォルトの名無しさん
2011/08/14(日) 13:12:54.57> intで受けとらにゃならんの？
はい、それが仕様です。
で、答えは？
0328デフォルトの名無しさん
2011/08/14(日) 13:27:02.640329デフォルトの名無しさん
2011/08/14(日) 13:38:57.99の一種かな
callback があれば getter は要らないもん！（変数は引数渡しで取得出来るから・・・）
みたいな
0330デフォルトの名無しさん
2011/08/14(日) 13:39:25.70結果的に拡張性を下げている
0331デフォルトの名無しさん
2011/08/14(日) 13:46:19.43int sum = a+b;
わざわざgetterで取り出す必要がない。
0332デフォルトの名無しさん
2011/08/14(日) 13:48:01.17じゃあダブルディスパッチいらないってことになるなｗ
0333デフォルトの名無しさん
2011/08/14(日) 14:19:18.04外の話しでしょ。
単にオブジェクトの中で完結する事をわざわざgetter何かで
出仕入れする必要がない。
0334デフォルトの名無しさん
2011/08/14(日) 14:22:16.54オブジェクトの中で完結しないだろ。
なんでクラスAとクラスBが
int型に変更されてるんだ。
それに、getValue()にしか使えないだろ。
クラスAはgetValue1とgetValue2、
クラスBはgetLengthを持ってましたー。
a+bはなんになるでしょーか。
0335デフォルトの名無しさん
2011/08/14(日) 14:23:33.41質問には答えずに逃げたんだっけなｗ
0336デフォルトの名無しさん
2011/08/14(日) 17:16:53.91無駄にコードなんか出すからこんなややこしくなってんだろ
0337デフォルトの名無しさん
2011/08/14(日) 17:25:46.760338デフォルトの名無しさん
2011/08/14(日) 17:30:50.77あいつさえ消えれば平和になる。
世界が。
0339デフォルトの名無しさん
2011/08/14(日) 17:31:58.29コードを出しちゃうと実現不可能な妄想だったり
迂遠なコードになったりすることがバレちゃうもんね
0340デフォルトの名無しさん
2011/08/14(日) 17:33:37.51getter不要っつってもなんも考え無しに自動生成したgetterが不要って話で
ちゃんと考えてるならこの限りではないけどね
でも大抵のコードでとりあえずつけとけ的なもんだから
発言がややこしくなるのでgetter全廃派でいいです的な立場
オブジェクトの関連相手もわからないのにイベント作成してんのはおかしいよ
0341デフォルトの名無しさん
2011/08/14(日) 17:36:19.31>
> getter不要っつってもなんも考え無しに自動生成したgetterが不要って話で
それはgetter不要派ではない。
getter不要派は、どんな場合でもgetter使うなと言っている馬鹿のこと。
その反対は、絶対getterを作る派ではなく、
内部で使うだけのものと、外部に提供するものを見極め
ただしい設計をするもののこと。
0342デフォルトの名無しさん
2011/08/14(日) 17:38:58.60だから一番最初のsetter、getter不要発言をどうにかしたいなら俺の発言を理解してほしいんだけど
別にそうでなくてただ派生種が嫌いってだけならそれだけでいいんだけどｗ
0343デフォルトの名無しさん
2011/08/14(日) 17:42:51.53偽物は黙っててくれないかな。
0344デフォルトの名無しさん
2011/08/14(日) 18:43:22.34intの関連の相手なんて分からない。
Stringの関連の相手なんて分からない。
ただの部品が、自身がどう使われるかなんて知る必要ない。
クラス間は疎結合で有った方が良い。
疎結合なクラス間を埋めるのがコードであり、それがプログラマの仕事。
Observerパターンやコールバックが使われることもある。
が、これらは非同期処理のために使われるのであって、
カプセル化のために使われる訳ではない。
ハンドラに手続きが分断されるのが一番迷惑なわけで、
可能な限りgetter/setterの方が良い。疎結合になるし、読みやすい。
排他処理が必要なら、lock getter/setter unlock なんて手もある。
煩雑に思えるかもしれないが、コールバックよりマシ。
とにかく可能な限りコールバックを少なくすることが良い設計への第一歩。
0345デフォルトの名無しさん
2011/08/14(日) 18:46:51.59習ったんだろｗ バカ量産大学ｗｗｗ
0346デフォルトの名無しさん
2011/08/14(日) 19:01:32.33その際アクセッサ相当のメソッドがあるかどうかは問題にもならない。
0347デフォルトの名無しさん
2011/08/14(日) 22:48:11.39既に受け渡し側の判断が外に漏れ出してるって何度も書いてあるじゃん。
getter派がコード出せっていうからわざわざコードまでだしてさ。
0348デフォルトの名無しさん
2011/08/14(日) 22:57:13.01ACM acm = new ACM();
for( Numeric i : list ) i >> acm;
return acm;
こんなんでいいだろ。
0349デフォルトの名無しさん
2011/08/14(日) 23:07:56.43そもそもメッセージとメソッドの仕組み自体がコールバックなのに。
0350デフォルトの名無しさん
2011/08/14(日) 23:10:24.57じゃあ、素直にgetterが何の問題もないと認めろよｗ
getterがコールバックだというのなら、
getterではなくコールバックを使うべきだという主張は
意味がいないだろｗ
0351デフォルトの名無しさん
2011/08/14(日) 23:13:32.86非同期処理ってわかる?
source.beginDownloadData(function(data) { GUIに反映(data); });
こういうコールバックは大いに意味があるしgetterや同期的なダブルディスパッチとは全く違う
0352デフォルトの名無しさん
2011/08/14(日) 23:14:14.85コールバックを使えとは一言もいってない。お前等がコールバックいってるだけだろ。
勝手にレッテルはんなよ。他の意見は、引数で渡すがベースだろうが。
0353デフォルトの名無しさん
2011/08/14(日) 23:15:10.56> 既に受け渡し側の判断が外に漏れ出してるって何度も書いてあるじゃん。
意味不明
なんの話かわからないし、意味不明だから
それがいけないことだと判断ができん。
0354デフォルトの名無しさん
2011/08/14(日) 23:16:56.37渡す側のオブジェクトの判断基準についてgetterは漏らすかもみ消すかしかできないことに
何も答えが出てないんだけど。
0355デフォルトの名無しさん
2011/08/14(日) 23:17:42.96そもそも制約からして同じ土台じゃないしな。
0356デフォルトの名無しさん
2011/08/14(日) 23:22:18.03> 渡す側のオブジェクトの判断基準についてgetterは漏らすかもみ消すかしかできないことに
やっぱり意味不明だな。
漏らすかもみ消すか？
それはprivateかpublicかってことか？
getterなんてメソッドと一緒なんだから、protectedとか
メソッドで付けられるスコープは何でも付けられるが
お前はそれ以外の何を付けたいのだ？
0357デフォルトの名無しさん
2011/08/14(日) 23:22:21.96はいはい、getterです。OO嫌いのSTL作者が、C言語から引っ張ってきたgetterですよ。
これで満足？そもそも、C++や最近のJavaじゃ、lengthより、イテレーター使えってのが常識じゃん。
Rubyだってイテレーション機能持って登場してるし。
0358デフォルトの名無しさん
2011/08/14(日) 23:24:07.38この二つは用途が違う。
lengthは長さを知りたい時に使う。
イテレータは一文字づつ見ていくときに使う。
長さを知りたい時にイテレータを使って一文字づつ
文字を数えるのか？
遅くなるだけだろｗ
0359デフォルトの名無しさん
2011/08/14(日) 23:24:26.99どのメソッドをオブジェクトが選ぶかは、メソッドを選ぶオブジェクトが知ってればいい。
プログラマーも知っているべきではあるが、そのオブジェクトを使用するクラスやメソッドが
知っているべきではない。
0360デフォルトの名無しさん
2011/08/14(日) 23:25:11.10C++やJavaのイテレータは、値を受ける側が操作するgetter的な方式だぞ?
コールバック派なら違いを理解してRubyのイテレータを信奉しないとw
0361デフォルトの名無しさん
2011/08/14(日) 23:25:36.80長さを知る必要がある場合がまず無いだろ。
ストリーミングデータで長さの取得はできないが、
固定長のデータとストリーミングデータは長さが解らなくても同等に扱える。
0362デフォルトの名無しさん
2011/08/14(日) 23:25:50.70だから意味不明だって。
「どのメソッドをオブジェクトが選ぶ」って何だよ。
「メソッドを選ぶオブジェクト」って何だよ。
ちゃんと具体的に説明しろ。
0363デフォルトの名無しさん
2011/08/14(日) 23:26:58.08> 長さを知る必要がある場合がまず無いだろ。
は？ 100文字以上なら省略して、後ろに…をつける
とかあるだろ。
一秒で思いつたぞｗ
0364デフォルトの名無しさん
2011/08/14(日) 23:27:55.38あれはgetterとして使用できないし、
状態変異も起こす一応参照の部類。
俺や、言語開発者側はプロパティとして見ては居ない。
0365デフォルトの名無しさん
2011/08/14(日) 23:27:55.910366デフォルトの名無しさん
2011/08/14(日) 23:29:21.00入力メソッドで指定すんじゃん。
0367デフォルトの名無しさん
2011/08/14(日) 23:32:52.10HTMLのinputタグでどうやって入力メソッドで制限するんだ？
クライアント側の入力チェックは、簡単に制限解除できるって知らんのか？
0368デフォルトの名無しさん
2011/08/14(日) 23:33:32.99長さ制限はありません。
長すぎたら…で表示するんですよ？
0369デフォルトの名無しさん
2011/08/14(日) 23:35:14.60JavaのOutputStreamだってwrite(byte[] b, int off, int len)ってのを持ってるし、
C++だってiostreamのマニュピレーターstd::setw(これ自体一種のオブジェクト)で指定するようになってる。
0370デフォルトの名無しさん
2011/08/14(日) 23:35:23.87lengthの代わりにイテレータを使えとか
こいつは実践経験ないんだろうなｗ
同じことができるのなら、
複雑になってもいいと思ってらっしゃる。
ソースコードの読みやすさ、
シンプルの書くことに重要さをわかっていない。
KISSってしってる？ チュウじゃないよｗ
0371デフォルトの名無しさん
2011/08/14(日) 23:35:29.94元のコレクションが変更されたらイテレータが無効になるっていうのは
さんざんアンチgetterが主張してきた問題と同じじゃないの?
コールバック式のイテレーションなら少なくともシングルスレッドの範囲では安全だよ
0372デフォルトの名無しさん
2011/08/14(日) 23:38:18.14表示側に任せることじゃん。
大抵、lengthじゃなく反復が指定位置で止まったら"・・・"を付けるだけ。
まぁ君がlengthで判断してんのは知らんけど。
0373デフォルトの名無しさん
2011/08/14(日) 23:39:14.38表示側にもコードはあんだろｗ
0374デフォルトの名無しさん
2011/08/14(日) 23:40:43.99スレッドの話はイベントの人でしょ。こっちに振るなよ。
そもそも、こっちは非同期が重要じゃないって言ってんだし、
そっちで話を広げたこともない。
0375デフォルトの名無しさん
2011/08/14(日) 23:41:43.74>大抵、lengthじゃなく反復が指定位置で止まったら"・・・"を付けるだけ。
0376デフォルトの名無しさん
2011/08/14(日) 23:44:10.00lengthを使うのが全く一緒だと考える。
机上の空論ではそうかもしれないが、
文字列というのは一文字が何バイトかわからない
だから文字列を構成するバイト列を眺めて行かないといけない。
それは時間がかかる。
だから文字の長さを情報をとして別で持っておく。
lengthはその情報を返すだけだから高速になる。
こういう考えは実戦経験を積んでいないと
わからないだろうね。
0377デフォルトの名無しさん
2011/08/14(日) 23:44:35.00・ブロードキャスター君
・コールバック君
・非同期
目の前の話からひたすら目を背けないと困る何かがあるのか？
0378デフォルトの名無しさん
2011/08/14(日) 23:45:53.10getterはgetter。なのに違うもので実装しろと、
用途が違うものの話をし始める。
0379デフォルトの名無しさん
2011/08/14(日) 23:47:06.08ダブルディスパッチ、コールバックで解決できるよ派
ただフィールドの値を取得するだけのgetterは許さないよ派
getter -> 処理 -> setterこんな処理するなら最初から内部で処理しろよ派
lock getter/setter unlockも許しちゃうよ派
無意味にフィールドに全部getterつけるのは許さないよ派
番外
もうディスパッチくんが何を言いたいのかわからなくなってきた派
0380デフォルトの名無しさん
2011/08/14(日) 23:47:18.02そういう問題じゃないだろ。
表示の制限をする以上コピーだし、
元のlengthの長さを出力するわけじゃないから全くlengthが必要ない。
指定の文字で切ってなにかするぐらいだったら、substring呼び出して、
指定の位置で切って"・・・"つけたり修飾したりする。
0381デフォルトの名無しさん
2011/08/14(日) 23:48:56.64じゃなんで変なレッテル貼ってそっちで話を進めようとするんだい？
setter/getterでも同じで問題になってないコールバックとか強調してさ。
0382デフォルトの名無しさん
2011/08/14(日) 23:49:13.24絶対一緒に開発したくないな
0383デフォルトの名無しさん
2011/08/14(日) 23:52:00.54どこぞの嘔吐CADライブラリとか使えないだろうね。
オブジェクトをセットしとけば次々と図形と数値を分解して放り込んでくれる。
更に、補助のオブジェクトを放り込んでやれば、さらにレイヤーやら周辺処理までやってくれる。
そういうライブラリ任せの処理は絶対無理だろう。
0384デフォルトの名無しさん
2011/08/14(日) 23:52:17.98じゃあ、文字数制限はどうするんだよ。
HTMLのINPUTタグにmaxlengthつけたとしても
それは簡単に書き換えられるから
クライアント側おくられてくる文字なんて制限できない。
サーバー側で制限する必要があるからな。
0385デフォルトの名無しさん
2011/08/14(日) 23:56:02.37バリデーターに任せれば？
あと、そもそも、StrutsとかJavaは知らんけど、普通サーバーにおくられてくる文字数は不定だから、
どのみちパースと一緒にチェックしてエラーを出す仕組みがある。
0386デフォルトの名無しさん
2011/08/14(日) 23:56:37.62> 元のlengthの長さを出力するわけじゃないから全くlengthが必要ない。
> 指定の文字で切ってなにかするぐらいだったら、substring呼び出して、
> 指定の位置で切って"・・・"つけたり修飾したりする。
それが必要あるんだよ。
100文字まで普通に表示、
100文字を超えたら後ろに…をつける。
じゃあ、文字列がちょうど100文字だったら？
substringで100文字で切る。
そうだね。でも後ろに・・・をつけてはダメだよ。
ちゃんと元の文字列が100文字を超えるかlength使って確かめないとね！
0387デフォルトの名無しさん
2011/08/14(日) 23:57:41.62> バリデーターに任せれば？
そのバリデータで使ってるだろ・・・
自分が作ってないものは知りません。
それは神様が用意してくれたものです。
とか思ってるのかな？
0388デフォルトの名無しさん
2011/08/15(月) 00:00:57.56残念ながらバイト数にも対応するためlengthは使ってないんだってさ。
0389デフォルトの名無しさん
2011/08/15(月) 00:01:12.15> 長さを知る必要がある場合がまず無いだろ。
> 長さを知る必要がある場合がまず無いだろ。
わろたｗ
すごいな。文字列の長さを知る必要がある場合がないとか。
0390デフォルトの名無しさん
2011/08/15(月) 00:02:01.71lengthはバイト数ではなく
文字数を意味します。
って普通だけど？
実戦経験（ｒｙ
0391デフォルトの名無しさん
2011/08/15(月) 00:09:55.93イテレータ回しながら文字数数えるから要らないんだってさ。
それもコールバック方式でイテレートするらしい。
void callback( iterator *itr ){ 〜〜 }
foreach( list, callback );
C++やJavaだとローカル変数を持ち越せないから
本来ならローカル変数で済むはずのものまでメンバ変数になってグチャグチャ。
こんなんならgetter/setterの方がマシだ。
0392デフォルトの名無しさん
2011/08/15(月) 00:12:40.07なんか作ったら面白そうだな
0393デフォルトの名無しさん
2011/08/15(月) 00:13:27.28コールバック厨は帰れよ。
0394デフォルトの名無しさん
2011/08/15(月) 00:14:33.10文字数カウントさせるたびにイテレータが走る（キャッシュしない）、ってことまでは分かったwww
0395デフォルトの名無しさん
2011/08/15(月) 00:17:16.09キャッシュはするよ。
ただし文字列オブジェクトのキャッシュは使わず
文字列を使う側でキャッシュするんだ（笑）
0396デフォルトの名無しさん
2011/08/15(月) 00:17:53.49どうしても厳密にやりたいなら、substringもコピーするだけ無駄だし、
文字を転写するさいに101文字に達したら"・・・"と出力するUIにすりゃいいじゃねぇか。
WinAPIやらCocoaのUIと同じように。
0397デフォルトの名無しさん
2011/08/15(月) 00:19:05.83iteratorが最後の長さ持ってるだろ。
end() - begin()でもとれんことはないけど、それは重要じゃないし。
0398デフォルトの名無しさん
2011/08/15(月) 00:19:47.55なんの話してんの？
ずれてるよね。
0399デフォルトの名無しさん
2011/08/15(月) 00:22:03.12文字列が変更されてたら再イテレーション、そうじゃなかったら
キャッシュしたデータを使うってのを「文字列を使う側」が判断するの？
0400デフォルトの名無しさん
2011/08/15(月) 00:30:25.58イベントドリブンによる非同期なハンドラの呼び出しによる、
コードの分散によるもの、ってのは殆どの人が納得するところなのに、
それと同じ仕組みを必要も無いのにプログラム全体にまで蔓延させようとする意味が分からない。
getter/setterで済むのなら、そっちのがいいわな。
ObserberパターンだのMVCだのイベントハンドラだのWM_だの、別に好きでやってる訳ではない。
イベントドリブンで非同期だから仕方なくやってるだけ。
必要も無いのにマネようとするのは、それの目的が何なのか、
今の自分にとって必要なのかどうか、の判断が出来ない子供のすること。
0401デフォルトの名無しさん
2011/08/15(月) 00:30:50.95DBはUTF-8ならそのまま入ることはあるけど、
そうじゃない場合があってね。結局、CGIのenvから
バイトストリームで受け取るときバイト数と文字数を調べて、
文字数かバイト数のどっちかが指定してあったら、
オーバーしたほうでエラーを返すってのがあるんだよ。
Maxbytelengthとかね。
0402デフォルトの名無しさん
2011/08/15(月) 00:32:47.43変更もクソも、新しいiterator渡されない限り更新出来んだろ。
大体、ストリームデータと共存できないだろ。まぁ、世の中length固定で
共存できないソフトが多いけどな。
0403デフォルトの名無しさん
2011/08/15(月) 00:34:00.07getterもsetterもコールバック。イベントの話がしたいなら後でしろ。ややこしくなる。
0404デフォルトの名無しさん
2011/08/15(月) 00:35:00.22それで？
DBはUTF-8のまま入るんだよね？
0405デフォルトの名無しさん
2011/08/15(月) 00:35:36.86お前は頭が悪すぎるから引っ込んでろ。
0406デフォルトの名無しさん
2011/08/15(月) 00:37:50.93UTF-8で入らないDBが腐るほどあるからバイト数の仕組みがあるだけで、DB自体はどうでもいいだろ。
0407デフォルトの名無しさん
2011/08/15(月) 00:38:50.160408デフォルトの名無しさん
2011/08/15(月) 00:38:52.12聞いたことないわー。最近のDBで聞いたことないわー
0409デフォルトの名無しさん
2011/08/15(月) 00:43:18.45あんたが勝手にイベントドリブンの話持ち出してんじゃん。
アダプターパターンとか、ダブルディスパッチとかコマンドパターンとか
別にイベントドリブンの為のパターンでもないし。
0410デフォルトの名無しさん
2011/08/15(月) 00:47:54.75イベントドリブンじゃなくて非同期処理な。
アダプターパターン、ダブルディスパッチ、はともかくとしても、コマンドパターンは非同期処理だし。
0411デフォルトの名無しさん
2011/08/15(月) 00:48:19.46バイト単位で文字数制限させられたことは有りますよね。UTF-8対応なんて出てきたのはつい最近の事ですし。
ねぇ >>390 さん
0412デフォルトの名無しさん
2011/08/15(月) 00:52:01.28え？ UTF-8が最近？
10年前ぐらいで止まってるのか？
0413デフォルトの名無しさん
2011/08/15(月) 00:53:06.910414デフォルトの名無しさん
2011/08/15(月) 00:56:08.60少なくとも内部はUTF-8だって。
0415デフォルトの名無しさん
2011/08/15(月) 00:58:20.08>アダプターパターン、ダブルディスパッチ、はともかくとしても
じゃ元々非同期処理の話は関係ないじゃん。
コマンドパターンは、イベントと関係ないものの代表格として今引っ張り出しただけだし。
0416デフォルトの名無しさん
2011/08/15(月) 01:01:18.70Web制作会社ならそうだろうね。
企業相手だと10年以上前のDBデータを
ガワだけ変えながらエンコードも変えずに
維持してんのは大量にある。
某フジ配下のコンテンツ配給会社だってそうだし、
某研究所だってそうだった。
0417デフォルトの名無しさん
2011/08/15(月) 01:07:05.49それで？
お前は何を言いたいんだ？
0418デフォルトの名無しさん
2011/08/15(月) 01:11:07.55やっぱりろくに業務経験のないヤツが多いんだな。
普通他のシステムがエンコーディング決め打ちとかしてるから、
やすやすと移行できるなんてことはまず無いんだけど、やっぱ学生が多いのか？
それとも派遣だらけとか？
0419デフォルトの名無しさん
2011/08/15(月) 01:11:56.03だからなんでエンコーディングの話になってるのさｗ
話しそらしすぎだろ。
getterの話に戻れよ。lengthがなんだって？
0420デフォルトの名無しさん
2011/08/15(月) 01:16:57.20lengthの話は終わったろ。lengthの話ししてたヤツも結局エンコーディングはUTF-8だけだと
思ってる自称実務経験者だったし。
0421デフォルトの名無しさん
2011/08/15(月) 01:17:02.34非同期処理で行われるようなコードの分散はなるべく避けるべき。
可能な限りgetter/setterを用いて、流れを分断せずに記述できる方が好ましい。
そういう主張。
0422デフォルトの名無しさん
2011/08/15(月) 01:18:38.48非同期の処理なんて出てきてないでしょ。出たのはイベントの人と、MVCの時ぐらい。
0423デフォルトの名無しさん
2011/08/15(月) 01:24:56.38lengthの話は終わった？
じゃあ結論はどうなったのさ。
> 長さを知る必要がある場合がまず無いだろ。
この答えはどうなったのさ
0424デフォルトの名無しさん
2011/08/15(月) 01:26:03.34>非同期の処理なんて出てきてないでしょ。
まさにそのとおり。
非同期の処理でもないのに、非同期の処理で行われるようなコードの分散は避けるべき。
非同期でないなら、getter/setterで十分。
余程のことが無い限り、手続きの流れが分断する方が迷惑。
え？ダブルディスパッチ？
実際にはあまり使われないでしょ。
それは、殆どの人が出来ることの割りにコードが複雑になると感じているから。
総合的な判断で、あまり採用されない。
0425デフォルトの名無しさん
2011/08/15(月) 01:26:38.62あと、getter不要、こんなコードを書くとか言っていた馬鹿もいたなｗ
int value1,value2,value3;
a.sendValue(
function (avalue) {value1 = avalue},
function (avalue1,avalue2) {value2 = avalue1;value3=avalue2}
);
0426デフォルトの名無しさん
2011/08/15(月) 01:28:31.24目的に対して手段が全く違っていた馬鹿だったよな。
ダブルディスパッチは静的言語で動的に決まる型で
オーバーロードしたい時に使うテクニック。
それをｗなに？ｗ getterのかわりに使うって？ｗｗｗｗ
腹痛いわｗｗｗｗ病院行こうぜｗｗｗｗ
0427デフォルトの名無しさん
2011/08/15(月) 01:30:27.15シンプルにしておけよ馬鹿野郎。 の略
getterが必要なら、getterを使えよ馬鹿野郎ｗ
そういや、メソッドをオブジェクトが選ぶとかいう
話はどうなったんだ？ｗ
0428デフォルトの名無しさん
2011/08/15(月) 01:33:12.26君の世界はそうだろうしそうでいいんじゃない？
世の中、CADのベンダーライブラリやポスプロツールを作るときの
ライブラリなんかバリバリ出てくるから。だいたいライブラリの中央に
オブジェクトのDBが有るんだけど。そこで扱われる個々のオブジェクト情報を
ダブルディスパッチやアダプターで隠蔽してキャストとか一切メソッドに見えないようにしてる。
0429デフォルトの名無しさん
2011/08/15(月) 01:34:23.97getter不要にはならない。事実どんなものでもgetterは使われてる。
論破完了ｗ
0430デフォルトの名無しさん
2011/08/15(月) 01:36:03.94結局valueで返してるからおかしいんだろ
var object;
a.sendValue(
function (avalue) { object.methodA(avalue);},
function (avalue1,avalue2) {object.methodB(avalue2);object.methodC("キー",avalue2)}
);
return object;
だと別に変でもないし。普通の無名関数の使い方。
0431デフォルトの名無しさん
2011/08/15(月) 01:37:40.69え？ 変だろｗ
0432デフォルトの名無しさん
2011/08/15(月) 01:38:25.00今使ってるものがいらないといってるんだけど。論破して満足ならどうぞ。
おんなじように、
黒電話は事実どんなところでも使われてる。
論破完了。1990年代にそれを言いたければ言えばいい。
0433デフォルトの名無しさん
2011/08/15(月) 01:39:28.20lispも変ですね。C++のalgorithmも変ですね。Rubyのイテレーターも変ですね。
0434デフォルトの名無しさん
2011/08/15(月) 01:39:49.55俺のいた未来では
今使っているものがいらない世界なのだ。
ってこと？
0435デフォルトの名無しさん
2011/08/15(月) 01:40:53.29getterですむところを
シンプルにしないで複雑にしているのが変と言っているのであって
イテレータを否定しているわけじゃないよ。
適材適所って知ってる？
KISSって知ってる？
0436デフォルトの名無しさん
2011/08/15(月) 01:42:19.70国語ができないの？「1990年代に居た時にそういえば良かったろ」とでも言い直してほしいの。
色々考えはあるだろうが、これからも別に要らんといってるだけ。俺の考えが携帯電話になるか
ポケベルになってるかはどうでもいい。
0437デフォルトの名無しさん
2011/08/15(月) 01:45:37.72だからそれをみんなして否定してる。
0438デフォルトの名無しさん
2011/08/15(月) 01:46:27.49アレがKISSに反してると？わざわざ関数の戻り値を使って処理を分岐せずに、
関数に呼び出す処理を選ばせてることが？
0439デフォルトの名無しさん
2011/08/15(月) 01:47:08.83まずそのように説明が必要な時点で
シンプルではないという証拠
0440デフォルトの名無しさん
2011/08/15(月) 01:48:18.230441デフォルトの名無しさん
2011/08/15(月) 01:49:31.78smalltalkもアウトだな。isTrue:とisFalseの引数は処理ブロックだし。
0442デフォルトの名無しさん
2011/08/15(月) 01:50:18.18オブジェクトからgetterで取得した値を引数にして
別の関数を呼び出しますよ。
0443デフォルトの名無しさん
2011/08/15(月) 01:55:40.26関数型言語だから処理を引数でとるのは当然ですよね。
0444デフォルトの名無しさん
2011/08/15(月) 01:56:51.550445デフォルトの名無しさん
2011/08/15(月) 01:57:25.100446デフォルトの名無しさん
2011/08/15(月) 01:58:06.88分岐の場合はそうでも、分岐以外はどうなんだ？
それとも、全部分岐で書くか？
発想が、getterをダブルディスパッチでかけるからと言って
全部ダブルディスパッチで書いて複雑する馬鹿と同じだぞｗ
0447デフォルトの名無しさん
2011/08/15(月) 01:59:06.56全部それでやろうとする。
0448デフォルトの名無しさん
2011/08/15(月) 01:59:34.90お前lisp知らんだろ。
COLSだって知らないっぽいし。
0449デフォルトの名無しさん
2011/08/15(月) 02:01:52.23シンプルを追求するなら、これに習う必要がある。
それだけでは厳しい場合に、色々な技法を駆使する。
だけど、それらを駆使する必要の無い場合は、
ロード→演算→ストア つまり、 getter→演算→setter がシンプルでよい。
getter/setterはコンピューティングの基本であるが故、プログラミングとよく馴染む。
ゆえに不滅である。
0450デフォルトの名無しさん
2011/08/15(月) 02:02:33.01それは反論ではないよ。
0451デフォルトの名無しさん
2011/08/15(月) 02:04:07.74ダブルデイスパッチ自体はオブジェクト間の通信方法。
何度も言うがsubstringやらreadやらは使うし。
0452デフォルトの名無しさん
2011/08/15(月) 02:06:18.98動的な型でオーバーロードをしたい時に使われる通信方法。
通信すべてに適した方法ではない。
適材適所。
0453デフォルトの名無しさん
2011/08/15(月) 02:06:40.06だったら関数が一番真っ当だろ
出力=処理(入力)
0454デフォルトの名無しさん
2011/08/15(月) 02:08:14.950455デフォルトの名無しさん
2011/08/15(月) 02:10:39.14CLOSじゃgetterなんてほとんど使わない。
物好きが使ってるかも知れないけど。
0456デフォルトの名無しさん
2011/08/15(月) 02:12:38.35全部それでやろうとする。
CLOSを知ったら（以下同文
0457デフォルトの名無しさん
2011/08/15(月) 02:13:14.55どんな職業なんだろうねｗ
0458デフォルトの名無しさん
2011/08/15(月) 02:13:21.50はいはい全ての関数はgetterなんですよね。
ちなみにさっきの関数だけど、
出力.処理(入力)でも完結できる話し。
0459デフォルトの名無しさん
2011/08/15(月) 02:15:21.26↓ バカフィルターを通すとこうなるらしい。
全ての関数はgetter
0460デフォルトの名無しさん
2011/08/15(月) 02:15:30.82a.set( a.get() + b.get() + c.get() + d.get() );
これと同じ処理をgetter/setter使わずにどう書く？
0461デフォルトの名無しさん
2011/08/15(月) 02:18:12.030462デフォルトの名無しさん
2011/08/15(月) 02:20:02.84釘を差しておかないとな。
0463デフォルトの名無しさん
2011/08/15(月) 02:23:46.110464デフォルトの名無しさん
2011/08/15(月) 02:24:31.49getter厨はいい加減オブジェクトの通信を外にさらしてる
だけだってことに気づいたら？
隠蔽してる側は隠蔽してるだけだから、
int型とかにわざわざ戻さない限り手間はたいして増えないの。
そしてわざわざintとかに戻さない。
0465デフォルトの名無しさん
2011/08/15(月) 02:25:40.29>>461
0466デフォルトの名無しさん
2011/08/15(月) 02:26:40.17> getter厨はいい加減オブジェクトの通信を外にさらしてる
意味不明。
それの何が悪いのかちゃんと説明したら。
0467デフォルトの名無しさん
2011/08/15(月) 02:27:11.72え？ それ明らかに仕様が違ってるじゃんｗ
aとbとcとdが同じ型と
誰が言いましたか？
0468デフォルトの名無しさん
2011/08/15(月) 02:28:10.05悦に浸っているだけ。
0469デフォルトの名無しさん
2011/08/15(月) 02:28:19.34何度も書いたし、このスレ見直したら？
0470デフォルトの名無しさん
2011/08/15(月) 02:29:07.55だったら早く、
a.set( a.get() + b.get() + c.get() + d.get() );
をgetter/setter以外で書いてよ。手間かからないんでしょ。
0471デフォルトの名無しさん
2011/08/15(月) 02:29:55.91何度も否定されてるし、
いい加減複雑になっているだけって気づいたら？
さて、反論コードはまだですかねぇｗ
0472デフォルトの名無しさん
2011/08/15(月) 02:31:05.38Numericのlistに入れられるように
Numericを継承されます。
そのコードは割愛します。
長いからねｗ
0473デフォルトの名無しさん
2011/08/15(月) 02:33:29.73オブジェクト自体は同じ型じゃない。
わざわざインターフェースを別の型にする理由もない。
だったらgetterの戻り値の型が足し算不能な型でもいいことになる。
そもそも使い方のレイヤーが違うし。
0474デフォルトの名無しさん
2011/08/15(月) 02:35:56.22どこで？分岐に処理を渡す話もしどろもどろだったじゃん。
0475デフォルトの名無しさん
2011/08/15(月) 02:37:32.21getterに実装が有ることやインターフェースが有ることは無視か。
相変わらずだな。
0476デフォルトの名無しさん
2011/08/15(月) 02:40:24.53>>348のループを展開して、a,b,c,dを割り当てりゃ良いだろ。
0477デフォルトの名無しさん
2011/08/15(月) 02:46:08.87具体的にお願い。JavaかC++で。
0478デフォルトの名無しさん
2011/08/15(月) 02:51:00.64足し算ネタは終わった。
あとこれからは、getter方式の式をベースに
すんじゃなくて、入力と結果を指定しろ。
関数で書かれたものに、クラスで近づけろといわれても
意味が無いだろ。
問題は結果と入力だ。
0479デフォルトの名無しさん
2011/08/15(月) 02:52:39.84ループ展開すら出来ないやつがケチつけてんのか。
0480デフォルトの名無しさん
2011/08/15(月) 03:12:12.52> 足し算ネタは終わった。
あ、答えられないから無理やり終わらそうとしてるーｗ
じゃあ再開
0481デフォルトの名無しさん
2011/08/15(月) 03:12:39.81なぜばれたｗ
0482デフォルトの名無しさん
2011/08/15(月) 03:12:55.05バカの一つ覚えでgetterは絶対排除できないとのたまってるくせに、
他人にはバカの一つ覚えとは図々しい・・・。
0483デフォルトの名無しさん
2011/08/15(月) 03:13:49.15>>461で終了。
0484デフォルトの名無しさん
2011/08/15(月) 03:15:09.43すべてを否定することになっているって
気づいているのかな？
戻り値を戻す関数はすべてダブルディスパッチで
実装できるよね。
関数が戻り値を返さなかったら、
それはもはや関数である必要がないだろう。
サブルーチンだ。
0485デフォルトの名無しさん
2011/08/15(月) 03:15:54.24aとbとcとdはどこに言った？
0486デフォルトの名無しさん
2011/08/15(月) 03:17:40.87> バカの一つ覚えでgetterは絶対排除できないとのたまってるくせに、
どこにそんな人がいるの？
getter不要信者 vs 適材適所で使えよ派 だろ。
0487デフォルトの名無しさん
2011/08/15(月) 03:19:01.30これで満足か？
ACM acm;
a >> acm;
b >> acm;
c >> acm;
d >> acm;
return acm;
0488デフォルトの名無しさん
2011/08/15(月) 03:22:10.59>>7 とか他もろもろ。
0489デフォルトの名無しさん
2011/08/15(月) 03:27:32.83それじゃダメだろ。
今回はたまたまa.get()しか無いからいいけど。
a.getValue1()、a.getValue2()とか
複数あったらどうすんだ。
それにそれは>>をオーバーロードしているだけで、
オーバーロードしないコード書いてみ。
0490デフォルトの名無しさん
2011/08/15(月) 03:29:30.98オブジェクトが複数の値を持つことなんてあるのか？
0491デフォルトの名無しさん
2011/08/15(月) 03:30:18.18あるに決まってるだろｗ
0492デフォルトの名無しさん
2011/08/15(月) 03:36:35.28それだけじゃないよね。計算式の方も、足し算だけだとは限らないもんね。
普通、引き算掛け算割り算と色々使うよねぇ。
現実問題、計算機なんだから、そりゃ色々計算するわなぁ。
0493デフォルトの名無しさん
2011/08/15(月) 03:39:11.70オブジェクトはそもそも値なんだから
おかしいだろ。
オブジェクトとオブジェクトを足したら
二つのオブジェクトが合わさったものになる。
その中の一部だけを足すとか設計がおかしいだけ。
aとbがそれぞれ2次元空間だとして、
aとbを足せば、縦は(a+b)、横も(a+b)、面積も(a+b)になる。
オブジェクト同士を足した時の結果は一義に決まるので
その中の一部だけを取り出すとかありえない
0494デフォルトの名無しさん
2011/08/15(月) 03:41:13.53え？
0495デフォルトの名無しさん
2011/08/15(月) 03:41:27.26頭大丈夫か？お前、新しすぎるよ。
0496デフォルトの名無しさん
2011/08/15(月) 03:46:29.48> a >> acm;
> b >> acm;
> c >> acm;
> d >> acm;
> return acm;
abcdが2次元空間だとして
acmには最終的に何が入るんだろうな。
aが1×1(面積1)、bが2×2(4)、cが3×3(9)、dが4×4(16) だとして
acｍに何が入るか答えてよ。
候補としては、10×10（面積100)か、面積1+4+9+16=30のどちらかだろうけどな。
0497デフォルトの名無しさん
2011/08/15(月) 05:54:00.24あまりのレベルの低さに吐気がすんだけど
0498デフォルトの名無しさん
2011/08/15(月) 06:11:55.10コード出させれば、馬鹿さがよく分かるんだから。
さてacmの答えが何になるか
楽しみに待ってようぜｗ
0499デフォルトの名無しさん
2011/08/15(月) 06:20:06.770500デフォルトの名無しさん
2011/08/15(月) 06:21:23.40getter不要論者が苦しんでる。
それで十分だと思うよ。
さて、レスはまだ？
0501デフォルトの名無しさん
2011/08/15(月) 07:04:50.95もう議論に勝つことに夢中で何も見えてないんだな
0502デフォルトの名無しさん
2011/08/15(月) 07:46:18.130503デフォルトの名無しさん
2011/08/15(月) 08:27:12.82「オブジェクトが複数の値を持つことなんてあるのか？（キリッ」
素晴らしい名言www
0504デフォルトの名無しさん
2011/08/15(月) 09:22:55.16勝手に終わらせんなよ
もしかして、iteratorから長さ取ってくる(>>397>>402)のが答えか？
文字列変更するオブジェクトと長さを知りたいオブジェクトが違ったらどうするんだ？
ていうか、それってgetする相手がstringからiteratorに変わっただけだろ馬鹿が
0505デフォルトの名無しさん
2011/08/15(月) 09:40:08.26一端外に晒すから組み合わせやすいんじゃね？
中に分岐を持ってるってんなら、引数の型なりインタフェースなりが限定されるか、
拡張を余儀なくされるかじゃね？
一方、単純な型などを返すインタフェースだと、
インタフェースはそれ以上大きくも多くもならない。
0506デフォルトの名無しさん
2011/08/15(月) 10:02:47.54a.add(b.add(c.add(d.get())))
俺は>>379でいうと「getter -> 処理 -> setterこんな処理するなら最初から内部で処理しろよ派」
0507デフォルトの名無しさん
2011/08/15(月) 10:11:04.89int ret = clamp(Math.sqrt(Math.max(a.getM(), b.getN())), c.getO(), d.getP());
外に出した値を使わずに、中に入れ込んでいくと破綻しそうだが…。
0508デフォルトの名無しさん
2011/08/15(月) 10:18:11.97Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel
0509デフォルトの名無しさん
2011/08/15(月) 10:34:25.99これってある程度具体的なクラスじゃなきゃ適用できないよね
どの程度の粒度を対象に議論するのか決めとかないと話が前に進まないんじゃないかな
0510デフォルトの名無しさん
2011/08/15(月) 10:38:50.96関数はオーバーロードできるけど変数は出来ないから
関数を通して出来るようにしているわけだから
変数の公開変数思えば良い。
変数だけ公開してはいけないなんていうやつは
データの隠蔽と履き違えているとしかいいようがない。
0511デフォルトの名無しさん
2011/08/15(月) 10:48:25.41どういうこと？抽象的な環境でこそ生きてくるものだと思うんだけど
0512デフォルトの名無しさん
2011/08/15(月) 11:00:01.85外に公開したintの用途を全て想定できるならカプセル化なんて要りません
0513デフォルトの名無しさん
2011/08/15(月) 11:28:35.68intを公開しているクラスに対しての新たな用途ができたら、それをintを公開しているクラスにメソッドとして追加するんじゃないの？
そうしないと新たな用途の実装が外部に記述されてしまって、それこそカプセルかできてないと思うんだけど
もしその新たな用途がintを公開しているクラスに対しての物ではないなら、確かにどういう用途かわからないけど
その場合はgetterだけでsetterは必要ないわけだしそこは否定してないよ
対象クラスへの処理を外部で行うなら、対象クラスへ実装しろって話
0514デフォルトの名無しさん
2011/08/15(月) 11:38:16.16外部でできる処理は内部に入れてはいけないというのが
オブジェクト指向の基本だろ。
基本もわかってないような奴が滅茶苦茶なことを書いて
混乱させてるだけとしかいえないな。
0515デフォルトの名無しさん
2011/08/15(月) 12:18:46.94じゃあデータベースアプリは全てデータベースオブジェクトの機能と考えられるから
一つのクラスでDBアクセスもGUIも全部担当するべきだね
0516デフォルトの名無しさん
2011/08/15(月) 12:32:13.320517デフォルトの名無しさん
2011/08/15(月) 12:36:50.95そんな基本聞いたこともないぞwww
>>508読んだ？
0518デフォルトの名無しさん
2011/08/15(月) 12:38:59.69まずそんな考え方しない
おまえはそんな風にクラス分けるのか
0519デフォルトの名無しさん
2011/08/15(月) 12:58:59.070520デフォルトの名無しさん
2011/08/15(月) 13:02:16.49effective c++に書いてあるぞ。
0521デフォルトの名無しさん
2011/08/15(月) 13:05:46.28トンデモ論ワロス
0522デフォルトの名無しさん
2011/08/15(月) 13:06:43.08今まで何度か理解しようとしたが、
俺がアホすぎて理解できたことが無い。
0523デフォルトの名無しさん
2011/08/15(月) 13:12:09.61それに書いてあるの文章そのまま書いてくれ
それか何ページか教えてくれ
0524デフォルトの名無しさん
2011/08/15(月) 13:14:10.78具体的にどこがトンデモかを指摘しろよ
煽るだけなら書き込むな
0525デフォルトの名無しさん
2011/08/15(月) 13:18:44.22俺は彼じゃ無いが、
その文章は、大衆はバカだって言ってる様な物だ。
0526デフォルトの名無しさん
2011/08/15(月) 13:18:49.60可哀想・・・
0527デフォルトの名無しさん
2011/08/15(月) 13:21:08.32トランザクションスクリプトって知ってるか？
ドメインは太らせるばかりが正解じゃないんだぞ。
そして、日本ではトランザクションスクリプトの方が主流。
ドメインモデルは一つのでかいシステムを
十分な時間をかけて分析し設計し
ウォータフローで作っていくには適しているが
アジャイル的な開発には向いていない。
0528デフォルトの名無しさん
2011/08/15(月) 13:21:32.19一つのクラスには一つの責務って話じゃないの？
文脈がよくわからん。
必要最小限の処理とか、外部でできる処理とか、急に言われても・・・
素直に文字通り読んだら、「外部でできる処理」を全部外に出したら
構造体と処理になるかな、と思った。
0529デフォルトの名無しさん
2011/08/15(月) 13:23:49.61少なくともカプセル化はされてるんだから、そうはならないでしょ。
0530デフォルトの名無しさん
2011/08/15(月) 13:30:34.32ドメイン（クラス）が持つべき処理を
外に出してデータだけにしてしまわないように
しようって話であって、
getterをなくそうって話ではない。
しかし、データは長期間保存されるもの
ロジックは変化するもの。と考えれば
ドメインモデルが必ずしも正しいとは言えないんだがね。
オブジェクト指向は適材適所で適用すべきもんだよ。
オブジェクト指向は、ライブラリとフレームワーク部分に適用し
ビジネスロジックはトランザクションスクリプトで書いたほうが
メンテナンス性がよくなる。
0531sage
2011/08/15(月) 13:32:50.54「メソッドとして定義するべきか？」「それを誰が持つべきか？」「外部にも公開するべきか？」といったことは、そのオブジェクトにどのような役割（責務）を持たせるかで決めるものだ。
システム化したい対象をどのように捉えるか（ドメイン分析）と、設計ポリシーが先であって、プログラミングテクニックが主導して決めるものではないよ。
0532デフォルトの名無しさん
2011/08/15(月) 13:37:09.33だからなんなんだw
内容に対してのレス頼むよ
>>526
だから本を参照したいからページを教えてくれと言ってるんだろ
0533デフォルトの名無しさん
2011/08/15(月) 13:37:59.46トランザクションスクリプトは説明しやすいんだが、
GUIアプリだと少し難しい。あまり話題にならないし。
トランザクションスクリプトは、LinuxのGUIアプリでよくあるような
見た目は一見GUIだけど、ボタンを押したときにCUIコマンドが
実行されるような部分のこと。
ドメインモデルだと、各オブジェクトがそれぞれ結合して強調して動く。
トランザクションスクリプトは、その名前のスクリプトからイメージできるように
なんらかのスクリプト（一連の処理）が何かをきっかけで動き出すような感じ。
もしドメインモデルでGUIアプリを作ろうと思えば、すべてをGUIと密接に結合された
オブジェクトとして作ることになる。ボタンの中に処理を書くのではなく
ボタンとオブジェクトのメソッドが直接つながっている感じ。
0534デフォルトの名無しさん
2011/08/15(月) 13:40:11.55ドメインモデルっていうのはプラグインみたいな感じ化？
0535デフォルトの名無しさん
2011/08/15(月) 13:42:37.36話が出てきて嬉しいよw
getter不要とか奴のわからん奴にかまってるのは無駄だからな
で、この話題を振った人(>>508)。なんか書いてね。
理解してるんでしょ？
0536デフォルトの名無しさん
2011/08/15(月) 13:50:22.73具体的にオブジェクト指向的にトランザクションスクリプトのどこが素晴らしいか教えてくれ
>>530
>あと、ドメインモデル貧血症ってのは
>ドメイン（クラス）が持つべき処理を
>外に出してデータだけにしてしまわないように
>しようって話であって、
>
>getterをなくそうって話ではない。
最初から俺はそう主張しているよ>>506
決してgetter不要論者ではないです
>しかし、データは長期間保存されるもの
>ロジックは変化するもの。と考えれば
>ドメインモデルが必ずしも正しいとは言えないんだがね。
>
>オブジェクト指向は適材適所で適用すべきもんだよ。
>オブジェクト指向は、ライブラリとフレームワーク部分に適用し
>ビジネスロジックはトランザクションスクリプトで書いたほうが
>メンテナンス性がよくなる。
やっとまともに意見をくれる人がいて嬉しいです
ドメインモデルよりトランザクションスクリプトの方が拡張性が高いという意見みたいだけど、どういうところでそう思いましたか？
0537デフォルトの名無しさん
2011/08/15(月) 13:51:58.20トランザクションスクリプト・・・手続き型風
ドメインモデル・・・オブジェクト指向風
と考えればいいよ。
ただし、トランザクションスクリプトだからってシステム全体を
手続き型で作るという話ではない。クラスを使わずに使うという話ではない。
トランザクションスクリプト or ドメインモデルは
基本的に、システム全体の一部分、だけど一番重要なビジネスロジックに
適用される話。それ以外はライブラリやフレームワーク（システム専用ではない汎用品）
トランザクションスクリプトでも、オブジェクト指向で作られたライブラリを使うし
フレームワークはオブジェクト指向で作ってあるので、必然的にオブジェクト指向に
そったやり方で処理を埋め込むことになる。
トランザクションスクリプトってのは、その中を（オブジェクト指向ライブラリをつないながらも）
手続き型風に書いていくやり方。データベースのように明らかにデータが分離された状態から
そのデータを加工しながら処理をしていくのに適している。
反対にドメインモデルだと、データベースを使っていたとしてもそれは隠蔽され
完全にロジックと結合しているオブジェクトとなる。
オブジェクト指向信者なら、全部オブジェクトがいいんだろうけど、
データベースがデータだけを分離しているように、またデータは変化しにくい・ロジックは変化しやすい
ことからもわかるようにビジネスロジックにおいては、データとロジックを一体化した
オブジェクト指向＝ドメインモデルが正解だとは言い切れない。
0539デフォルトの名無しさん
2011/08/15(月) 13:58:57.99> ドメインモデルよりトランザクションスクリプトの方が拡張性が高いという意見みたいだけど、
それは適材適所。
俺の中で拡張性といえば、プラグインを追加したり、処理を割りこませる仕組みがあったり
そいういうものを拡張性だと感じる。
ビジネスロジックは、既存の処理とは独立した新たな処理が追加されることはあるが
それを拡張とは思わない。
拡張性を高めるのならオブジェクト指向のほうがいい。そしてそれは
ライブラリやフレームワークに適用されるもの。
だからトランザクションスクリプトは拡張性が高いという意見ではなくて
ビジネスロジックは拡張性は必要ない部分ってだけ。
0540デフォルトの名無しさん
2011/08/15(月) 14:00:17.30本当はもっと厳しい決まりとかあるの？
0541デフォルトの名無しさん
2011/08/15(月) 14:04:01.99ポトペタだけで作れるでしょ？
でもボタンを押したときにコードを書くでしょ？
あの処理をなくして、見えないコンポーネントを作って
ボタンのクリックと見えないコンポーネントをくっつける。
そういうふうにしてGUIを作っているときにコードを書かずに
プロパティ設定だけで、完全にポトペタで作れるようにしたものが
ドメインモデル。
0542デフォルトの名無しさん
2011/08/15(月) 14:11:21.64部品を組み立てるように作るのがドメインモデルで
やることリストを作るのがトランザクションスクリプトだな。
0543デフォルトの名無しさん
2011/08/15(月) 14:18:06.14無いよ。
あれば既存のシステムを読むとき、
もっとわかりやすい世界になっていただろうさ。
それどころかドメインモデルとトランザクションスクリプトの違いを理解してないで開発されている例が多い。
日本ではトランザクションスクリプトが主流だが海外ではドメインモデルのほうが多い。
主流と言っても、意識してそうなっているのではなく、結果としてそういうコードになってるねってだけ。
困ったことにRubyOnRailsとかよくあるフレームワークはドメインモデルを使うことを前提に作られている。
そこにビジネスロジックをトランザクションスクリプトで作るから、コードがゆがんでることが多い。
厳しい決まりがあるどころか、微妙に混ざりながらどっちとも言えないコードで作られている。
そもそもビジネスロジックってのはフレームワークに依存させたくないものなんだから、
フレームワークがビジネスモデルに関わってくるなと言いたい。まあRailsの基本的な考え方が
「俺らが決めたやり方に従えば簡単に作れる」なのだから仕方ないが。
トランザクションスクリプトを使うのならSpringやSeasorのようなDIコンテナを使うといい。
コントローラー（SpringやStruts）とビジネスロジックをつなぐものとしてDIコンテナを使うと
うまくビジネスロジックを分離させられる。DIコンテナはフレームワークと呼ばれているが、
このフレームワーク用に作ったオブジェクトはフレームワークに依存しない。
0544デフォルトの名無しさん
2011/08/15(月) 14:18:49.77>>523じゃないがおれも手元に本用意した。
そろそろページ数教えてくれ
0545デフォルトの名無しさん
2011/08/15(月) 14:21:59.060546デフォルトの名無しさん
2011/08/15(月) 14:28:48.51それなりに間違ってないと思うよｗ
部品と部品をつなげるときに処理をしない。
処理はすべて部品が持っている。
そうするとドメインモデルになる。
これはある意味理想的な形だけど、難しくもある。
作りたいシステム全体を一つのものとして設計しないといけないから。
汎用品と汎用品の間に処理を入れて、汎用品を組み合わせて作るという考え方ではなく、
汎用品がなければ、専用品として仕上げないといけない。すべてが部品となる。
部品と部品の間に処理を入れられれば、多少部品と部品がうまく結合できなくても
どうにかなるが、そういう処理を無くすのであれば、システム全体を見ながら
部品を設計する必要がある。だから大掛かりなものとなってしまい時間もかかる。
0547デフォルトの名無しさん
2011/08/15(月) 14:50:10.07あー、だったら俺は完全にトランザクションスクリプト派だわ。
顧客の細かなニーズに対応したいし、
処理の流れが分かりやすいってのは、メンテ性にも関わってくる。
パーツ作ってるわけではなく、最終目的地点のアプリ作ってるわけだから、
それ以上の拡張性は要らないわけで、ベタで書いても支障ないしな。
0548デフォルトの名無しさん
2011/08/15(月) 14:54:37.11＞十分な時間をかけて分析し設計し
＞ウォータフローで作っていくには適しているが
＞アジャイル的な開発には向いていない。
初耳だわ。誰の意見？少なくともファウラーもエヴァンスも、ウォーターフローを忌み嫌っているはずだがね。
>>533
プロキシを密結合と言うのならそうなんだろうな。
http://martinfowler.com/eaaDev/uiArchs.html
0549デフォルトの名無しさん
2011/08/15(月) 15:35:31.14>しかし、データは長期間保存されるもの
>ロジックは変化するもの。と考えれば
>ドメインモデルが必ずしも正しいとは言えないんだがね。
こういうときこそドメインモデルが生きてくるところだと思う
ドメインモデルの方が難しいというのは同意です。
しかし実装と機能を分けて、それぞれの拡張を別に実現するということを目指すのは必要なことだと思っています
疎結合になりますし、新たな実装を追加しても既存の機能には影響を与えない。
機能の修正は、実装追加とは別に行える。
これこそ拡張性が高いということだと思っています。
Bridgeパターン デザインパターンでキャリアアップ http://www.rarestyle.net/main/patterns/bridge.aspx
9. Bridge パターン | TECHSCORE(テックスコア) http://www.techscore.com/tech/DesignPattern/Bridge.html/
>>547
処理の流れが分かりやすいというのはその通りだと思います。
トランザクションスクリプトでは一連の流れがあるメソッド上に浮かび上がってきますが、ドメインモデルでは大枠で何を行っているかは掴めますが、
流れを知るにはクラスをどんどん潜っていく必要があります。
ドメインモデルはこれをメリットと考えていて利用者側は詳細を知る必要がなく開発ができると捉えます。
そして今更なんですが、
ドメインモデルは>>506
トランザクションモデルは>>460
ということになるんですか？
なんかまた別の話になってるような
0550デフォルトの名無しさん
2011/08/15(月) 16:44:40.03ググったら奇妙な引っ掛かり方した。
そういう言い方がないわけでも無いらしい。
0551デフォルトの名無しさん
2011/08/15(月) 17:25:46.55Martin Fowler's Bliki in Japanese - ドメインロジックとSQL
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
賢いデータは必要なのか (arclamp.jp アークランプ)
http://www.arclamp.jp/blog/archives/000541.html
ドメインモデル VS トランザクションスクリプト
http://hibari.2ch.net/test/read.cgi/php/1241341332/
0552デフォルトの名無しさん
2011/08/15(月) 17:44:48.75スマン…俺がアホだった。自分でも驚いた。
0553デフォルトの名無しさん
2011/08/15(月) 20:09:58.76ACMってアキュムレーターの事だろ。
他の演算するなら他のオブジェクトを使うまで。
オブジェクトによって演算のパターンを決めるだけじゃん。
そういう演算をしたいならそういうオブジェクトを指定すればいいだけ。
0554デフォルトの名無しさん
2011/08/15(月) 20:13:31.490555デフォルトの名無しさん
2011/08/15(月) 20:15:37.62コードを出させてんのはgetter厨じゃん。 >>477 とかさ。
0556デフォルトの名無しさん
2011/08/15(月) 20:20:41.10Value1を拾うオブジェクトを使うか、Value2を拾うオブジェクトを定義するだけ。
ちゃんとValueじゃなくて、countだのなんだの具体的な名前書いてみりゃ、
規則的な計算になることぐらいすぐ解ると思うけど。
今後Valueとか書かずに具体的な名前書けよ。
0557デフォルトの名無しさん
2011/08/15(月) 20:22:13.140558デフォルトの名無しさん
2011/08/15(月) 20:29:39.80classを派生してgetter, setterをつけるんだよえっへん
というバカがたくさんいたのが全ての元凶だと思うんだ
interface abstractなら正解だけど
implementならどうでもいい
そして説明してる奴の九割がimplementのコードを例に出す
そうやってバカが量産されてきたのじゃよ
0559デフォルトの名無しさん
2011/08/15(月) 20:33:08.690560デフォルトの名無しさん
2011/08/15(月) 20:39:32.61なんでアクセサで必死になってんの？
0561デフォルトの名無しさん
2011/08/15(月) 20:42:11.48そもそもアクセッサをなにか特別扱いしてない？
本質は戻り値を返す関数と一緒。
それとも関数そのものを否定する気？
0562デフォルトの名無しさん
2011/08/15(月) 20:52:20.99関数はそもそもリストで返さないか？
0563デフォルトの名無しさん
2011/08/15(月) 20:54:23.50リストで返すわけがないだろう。
0564デフォルトの名無しさん
2011/08/15(月) 20:54:57.02なんの関係があるんだ？
0565デフォルトの名無しさん
2011/08/15(月) 21:02:24.38配列とか構造体的なもんじゃ再帰構造に対応できないから。
オブジェクトなら関数ベースと違ってオブジェクトなりのやり方だろうけど。
0566デフォルトの名無しさん
2011/08/15(月) 21:06:09.45ん？
ひとつ聞いていいか、
お前にとって、リストと配列の違いは何だ？
0567デフォルトの名無しさん
2011/08/15(月) 21:10:28.13リスト ( 1 ( 2 3 ) 4 ( 5 6 7 ) )
配列 [ 1 , 2, 3, 4, 5 ]
0568デフォルトの名無しさん
2011/08/15(月) 21:10:57.15あのおなじみのセル構造。
0569デフォルトの名無しさん
2011/08/15(月) 21:14:05.31メソッドだかオペレーションだかメッセージだか
その辺に読み替えるのが妥当じゃね？
0570デフォルトの名無しさん
2011/08/15(月) 21:31:16.99なんか変なのがいるな。
関数型言語の話をしたいのなら
そっちにいけと。
0571デフォルトの名無しさん
2011/08/15(月) 22:21:08.38>RubyOnRailsとかよくあるフレームワークはドメインモデルを使うことを前提に作られている
ドメインモデルとトランザクションスクリプトの中間に位置するのがActiveRecord（レコード指向）
じゃないの？
データベースのレコードをクラス（インスタンス）として扱うことでオブジェクト指向的な
利点を享受する。
0572デフォルトの名無しさん
2011/08/15(月) 22:42:50.38x = (a + b) * (c + d)
を求めるだけで途中の計算を保存するテンポラリを
人間が用意する必要があるんじゃないの？
0573デフォルトの名無しさん
2011/08/15(月) 22:47:30.29それがよくあるActiveRecordの間違った使い方。
ActiveRecordはドメインモデル。ActiveRecordは自動生成されたものを
そのまま使うのではなく、本来は継承しロジックを追加し
ドメインモデルとして仕上げて使うもの。
ドメインモデルの特徴の一つとして、入力チェックがモデル（ActiveRecord）に
あるということをあげられる。オブジェクト指向的に考えればモデルに
入力チェックがあるのは自然に見える。そしてActiveRecordのやり方に従えば
そこに入力チェックを書くように仕向けられているはず。
これがトランザクションスクリプトの発想だと入力チェックを外でやりたくなるはず。
コントローラ（もしくはコントローラーとビジネスロジックの中間層）で入力チェックをして
そのあとActiveRecordを使って保存したくなるはず。これはActiveRecordのやり方ではない。
本来モデルはテーブルと一対一で結びつける必要はないんだけど、ActiveRecordは一対一に結び付けてる。
これが更に混乱を増す結果になっていると思うな。
一つのアクションで複数のテーブルにデータを格納（＋そのためのチェック）することはよくある話なんだけど、
モデルとテーブルが一対一に結びついてると、意識しないで書くとただの複数のモデルを読み書きする処理
つまりトランザクションスクリプトを書いてしまうんだよ。
本来はそこで、モデル間のリレーションを適切にはって、O/Rマッパーの機能をフルに使って、データベースの存在をなくして
完全なるオブジェクトに仕上げて、一回の保存で複数のテーブルに保存できるようにして行かないといけないんだろうけど
俺には無理だわｗ 現実にはそこでN+1問題とかパフォーマンスとか更に考えるべき問題が出てくるからね。
> データベースのレコードをクラス（インスタンス）として扱うことでオブジェクト指向的な
> 利点を享受する。
これがまさにトランザクションスクリプトで、俺がオブジェクト指向は
フレームワーク(ActiveRecord)とライブラリの部分で使うべしといっていることそのもの
0574573
2011/08/15(月) 22:51:30.87一応自分の考えをまとめるのに参考になった所。
他にもいろいろあるけどなー
0575デフォルトの名無しさん
2011/08/15(月) 23:03:24.96まずa b c dを止めて意味のある名前にしてから聞いてくれない？
目的によっていくらでも捉えようがあるからさ。
0576デフォルトの名無しさん
2011/08/15(月) 23:05:42.09なんで入力チェックをそこ（モデル）でやるんだ？とか
複数のテーブルに格納するときはどうするんだ？
入力チェックはモデルだろ？ 複数のテーブルに格納するとき
複数のテーブルのデータを参照する必要があるチェックはどうするんだ？
その場合のトランザクションはどうするんだｓ？
とか悩んだことがあると思うんだけどどう？
0577571
2011/08/15(月) 23:06:43.83＞フレームワーク(ActiveRecord)とライブラリの部分で使うべしといっていることそのもの
おそらく俺はあんたと同じ価値観を持っていると思う
しかし言葉の定義が違うだろ
＞これがまさにトランザクションスクリプト
いやトランザクションスクリプトではレコードクラスにごく単純なメソッドさえ持たない
あるいはレコードに対応するクラスなんて概念さえない
たとえばTargetDateが営業日かどうか判定するのにIsBusinessDateとかいうメソッドを
作るのがAcriveRecoedの利点だと思うが
0578デフォルトの名無しさん
2011/08/15(月) 23:07:00.87マルチメソッドをgetterの替わりに悪用するのは辛いでしょ。
0579デフォルトの名無しさん
2011/08/15(月) 23:12:53.76結果を何回も使いたけりゃ、さっきの >> を何度も呼び出せばいいだけじゃん。
in >> out; でoutに渡される値はin側のオブジェクトが変更されない限り変わらないんだから。
in >> out1;in >> out2;ってな感じで何度でも渡せる。
0580デフォルトの名無しさん
2011/08/15(月) 23:29:19.07そんで、out1とout2を使って何か計算して、その結果に基づいて、inを更新するのはどうするんだ？
in1 >> out1; in2 >> out2;
out1 >> out3;
out2 >> out3;
out3 >> in1;
とかするわけ？
具体的には、さっき出てきたみたいな、
a=(a+b)*(c+d)のような計算をする場合はどうするんだ？
a>>adder1; b>>adder1;
c>>adder2; d>>adder2;
adder1>>muler;
adder2>>muler;
muler>>a;
とかするわけ？
多くの言語で戻り値を返す関数や式が認められてるのに？
0581デフォルトの名無しさん
2011/08/15(月) 23:36:03.13in1に戻す意味が解からんけど・・・。
out3 == in1なオブジェクトで構わんだろうし。
そんな要件なら。in1 = out3で上書きしとけばいいだろう。
a=(a+b)*(c+d)は内容によるとしか言えんな。
ベクトルとグラデーションで同じ計算があるからと言って、
同じオブジェクト構造になるわけじゃないし。
0582デフォルトの名無しさん
2011/08/15(月) 23:37:45.59a.setValue1( a.getValue1()+a.getValue2() );
の場合はどうするんだ？単純にa>>adderとは書けないぜ？
a>>value1;
a>>value2;
value1>>adder;
value2>>adder;
adder>>value1
value1>>a;
また人手間増えたな。
0583デフォルトの名無しさん
2011/08/15(月) 23:38:36.65もうひとつ言うと、四則演算とかが表に出てくることは殆ど無い。
最初から、aとbとcが一つのオブジェクトに入ってて、dが別のオブジェクトに入ってるってな事になるのが大概だし。
0584デフォルトの名無しさん
2011/08/15(月) 23:40:59.98aによるって。
a.move( x, y );ってのを内部に持ってれば。
1回で済む話しだし。x(つまりgetValue1())が不要なら無視すればいいだけ。
yも同じはなし。
0585デフォルトの名無しさん
2011/08/15(月) 23:46:25.29俺も一つ言わせてもらうが、
引き算はどうするんだ？
a>>suber; b>>suber; だと、引く数、引かれる数の区別が付かん。
>最初から、aとbとcが一つのオブジェクトに入ってて、dが別のオブジェクトに入ってるってな事になるのが大概だし。
そんなことは証明できんだろ。
3つ以上のクラス間で処理が跨ることなんて、多々あるだろ。
第一、
>aとbとcが一つのオブジェクトに入ってて
だったとしても、そのabcにgetterが無かったら同じことだろ。
0586デフォルトの名無しさん
2011/08/15(月) 23:46:27.86なんとも回答できんわ。
int型の配列見せられて、目的も言わずコレを使ってクラスを造ってくれって言われてんのと変わらんし。
配列だけ出されて目的とするものが、ベクターかツリーかグラフかじゃ全然違うからどうしようもない。
0587デフォルトの名無しさん
2011/08/15(月) 23:50:16.73StringBuilderかStringBufferでオブジェクトを作ってても
bufferじゃ、マルチスレッドに対応してるか解からんと言ってんのと変わんない。
あと、suberは引数で渡される事もありうるから、最初から挙動は不明。
suberのオブジェクトを作ったヤツが責任をとる。ACMの時からもだけど、
最初からそういうデザイン。
0588デフォルトの名無しさん
2011/08/15(月) 23:53:45.06意味がわらんのだが。a.move( x, y ) では値を取り出せないし。
仮に、a>>pointだったとして、確かにpointの中にx,yは入ってるだろうが、
今度はpointの中からxだけを取り出す手段がないんだが。
point >> valueX とかするわけ？
それとも、
point >> adderX とかするわけ？
どっちもクラス数が爆発するんだが。
どうせ、CPUは基本型で演算するんだから、
int a.getX()とかint point.getX()とかで良いじゃん。
0589デフォルトの名無しさん
2011/08/15(月) 23:54:58.06いや実際四則演算が出てくるような事はまず無いんだよ。
さっきのmoveとかあったけど、最初から計算するつもりなら、
その値を受け取るインターフェースを持ってる。
point >> block;
scale >> block;
ってな感じにそもそも対象とする値が決まってるからインターフェースも別れる。
あと、突っ込まれる前に言うが、getterが被らないのと同じ理由でインターフェースも被らないし。
0590デフォルトの名無しさん
2011/08/15(月) 23:55:57.02xを取り出すには目的が有るはずだよね。
それは何？
0591デフォルトの名無しさん
2011/08/16(火) 00:01:09.05GUIコンポーネントの中で、x,y自由に移動やら衝突判定に使えばいい。
文字で表示させたいだけなら、文字表示用のレイアウトにmoveを持たせればいい。
一回レイアウト作ったら二度と作る必要はないし。
ま、そうそうxだけを無差別に使うってことはない。
0592デフォルトの名無しさん
2011/08/16(火) 00:03:44.77ちょうどさっきまで書いていたコード（C#)
int 既修単位計 = 判定ルール.科目List.Where(c => c.Is既修).Select(c => c.単位).Sum()
int 履修単位計 = 判定ルール.科目List.Where(c => c.Is履修).Select(c => c.単位).Sum()
int 既修科目計 = 判定ルール.科目List.Where(c => c.Is既修).Count()
int 履修科目計 = 判定ルール.科目List.Where(c => c.Is履修).Count()
if (判定ルール.Is単位 >= 0){
return (判定ルール.必要単位数 <= 既修単位計 + 履修単位計);
} else {
return (判定ルール.必要科目数 <= 既修科目計 + 履修科目計);
}
●仕様
判定ルールオブジェクトには必要単位数か必要科目数が入っている。どちらかが有効（それを判定するのがIs単位）
判定ルール.科目Listには判定に必要な科目リストが入っている。個々の科目オブジェクトは
Is既修、Is履修、単位を持っている
それで必要な条件を満たしているかどうかを判定する
0593デフォルトの名無しさん
2011/08/16(火) 00:08:07.42問題はその、「block」だろ。
計算の種類の数だけblockを作る必要がある。
例えば、xは足したいが、yは足したくない場合など。
ちょっとした計算を行うのに、わけの分からないクラスを大量に作る羽目になる。
普通は、基本的なものの組み合わせでやりたい事を表現できた方が嬉しいだろ。
せっかく基本型と+-*/などの演算子が有るのに。
0594デフォルトの名無しさん
2011/08/16(火) 00:08:11.44あと、余談だけどさ。オブジェクト指向言語なんだから、単位系と、
科目系とでオブジェクトにまとめたら？
0595デフォルトの名無しさん
2011/08/16(火) 00:09:15.62xは足したいがyは足したくない場合って何？
単に、yを0に変えたオブジェクト作ってそっから渡せば済む話じゃないの？
0597デフォルトの名無しさん
2011/08/16(火) 00:12:04.31そのGUIコンポーネントに引き渡す「x.y」をどうやって生成するんだって話なんだが。
getter使わずに。
0598デフォルトの名無しさん
2011/08/16(火) 00:23:45.04Vector vector( file, "キー");//中に readでxとyを取り出してる。
vector >> out でいい。
あと>>592が何したいのか考えてるからちょっと待ってくれる。
ぶっちゃけこのまま風呂行って寝て明日になるかもしれないけど。
0599デフォルトの名無しさん
2011/08/16(火) 00:30:27.78どうやってだよ。
point1 >> block;
point2 >> block;
こんな方式なんだぜ？
だた、意味が伝わってなかったかもしれん。
point3 = { point1.x+point2.x, point1.x };
こんなことがしたい場合はどうするんだって話。
いちいちblockに相当するものを量産するのか？
そもそも、a >> block こんなんで、a内の特定の何かにアクセスできるんかって話も。
お前はgetterと同じで名前はかぶらないって言っていたけど、
aのvalue1と、bのvalue2を足し算したい場合はどうするんだって話もある。
0600599
2011/08/16(火) 00:43:19.11↓
point3 = { point1.x+point2.x, point1.y };
0601デフォルトの名無しさん
2011/08/16(火) 01:18:55.85point3 = { point1.x+point2.x, point1.y };
これ、どこの文法？
0602デフォルトの名無しさん
2011/08/16(火) 03:20:52.13よくよく考えたらルールからしてダメじゃねぇか。Is〜はgetterだから変えさせてもらう。
本来最初から設計してたらそんなもん組み込まないし。
あと判定ルールのIs単位ってなんで数字と比較してるんだ？bool値じゃないのか？
あと科目Listのコンテナは何？
一応マジメに答え作ってるから、ここら辺はしっかりしてもらう。
0603592
2011/08/16(火) 07:43:55.75Is単位はboolです、数値比較は間違いですね。普通にIF分でいいです
科目リストはList＜科目＞です
＞Is〜はgetterだから変えさせてもらう
よく意味がわかりませんが、
Is〜だけでなく「単位」「必要科目数」「必要単位数」もみんなプロパティとして実装しています
必要科目数と必要単位数はただプライベート変数を返しているだけですが
それい以外はなにかしらコードが書いてあります
0604デフォルトの名無しさん
2011/08/16(火) 08:30:44.14getter無しでコード書くって言ってるんだから。
このコードをgetterを使わないで、このgetterを使って書いて
言われてんのと同じなんだけど。
あと、判定ルールだけどis単位が、
真の時、
科目関係の必用科目数って必須なの？
必用単位数と排他関係に有るんじゃないの？
もし型が同じなら、必用単位数と必用科目数の2つに分ける
必用がなく、単に必用数でいいんじゃない？
型が違ってるなら、他の人がやってたように
必用数Int、必用数longとか用意しとけばいいんじゃない。
0605デフォルトの名無しさん
2011/08/16(火) 08:40:56.88「メソッドディスパッチでは実行時の型に応じて
戻り値の型を変える事ができない。だから戻り値を使うのは全部禁止」
こういう主張だろ？
でも前提条件（戻り値の型を変更不可）からして間違ってる上に、
結論（戻り値を全部禁止）もぶっとんでるから、全体として意味不明。
0606592
2011/08/16(火) 08:45:06.64＞必用単位数と排他関係に有るんじゃないの？
論理的にはそうですが、判定ルールオブジェクトはDBに保存されているので
この仕様は変えられません
Is単位をみて必用単位数か必用科目数を返すという新しいプロパティを作るの
もちろんOKですが、結局Is単位の判定は必要になるので今回は作りませんでした
＞このコードをgetterを使わないで、このgetterを使って書いて
そう思います。getterなしでこのコードをかけるとは思わないし、
できたとしても到底使う気にならないと思います
0607デフォルトの名無しさん
2011/08/16(火) 09:45:35.21今までだって質問者の意図無視した>>487みたいなコード連発してたのに、
なんで今回に限ってそんなこと言うのかな？もしかして書けないから？
0608デフォルトの名無しさん
2011/08/16(火) 10:08:38.15これってドメインモデルでもトランザクションスクリプトでもないよね
これでいうところのSQL内にロジック（Logic in SQL） に当たる
良い悪いかは別として、今回の議論の対象とは違うような
Martin Fowler's Bliki in Japanese - ドメインロジックとSQL
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
0609デフォルトの名無しさん
2011/08/16(火) 10:10:57.87俺がドメインモデルで書くならこうする(フィールドに対するコンストラクタ省略)
class 科目{
int 単位;
int get単位(){
return 単位;
}
}
class 人{
List<科目> 既修科目リスト
List<科目> 履修科目リスト
int get既修科目数(){
return 既修科目.size();
}
int get既修単位合計(){
int result = 0
for(科目 既修科目 : 既修科目リスト){
reuslt += 既修科目.get単位();
}
return result;
}
// 履修科目も既修科目と同じメソッドを用意(共通処理部分はメソッドとして切り出してもok)
}
0610609
2011/08/16(火) 10:13:07.05List<人> 学校全員
void 判定(判定ルール){
for(人 : 学校全員){
判定ルール.is判定(人);
}
}
}
// is単位の意味がよくわからなかったので省略
class 判定ルール{
int 必要単位数;
boolean is判定(人){
return (必要単位数 <= 人.get既修単位合計 + 人.履修単位合計);
}
}
main(){
まずすべてをクラスにロード
学校全員.判定(new 判定ルール())
}
0611609
2011/08/16(火) 10:25:08.11のところは専用メソッド用意してもよかったかも
もしくはclass 人に↓のメソッド追加すればgetterは必要なかったかも
boolean is判定(判定ルール){
return 判定ルール.判定(既修単位合計 + 履修単位合計);
}
}
// is単位の意味がよくわからなかったので省略
class 判定ルール{
int 必要単位数;
boolean is判定(int 単位合計){
return (必要単位数 <= 単位合計);
}
}
0612デフォルトの名無しさん
2011/08/16(火) 10:35:46.90こういうツッコミを今するのは申し訳ないが、
class Foo {
Bar bar;
Foo(Bar bar) {this.bar = bar;}
Bar getBar() {return bar;}
}
こういうゲッター単一機能のクラスに、一体何の意味があるというのだろうかｗ
0613デフォルトの名無しさん
2011/08/16(火) 10:41:00.370614デフォルトの名無しさん
2011/08/16(火) 10:47:05.46まさかｗ
Foo extends Barの形でかつ、getBar()などなく、
内部で持ってるBarインスタンスなどに委譲してる、
みたいな形式とってたらプロキシだろうけど。
0615デフォルトの名無しさん
2011/08/16(火) 10:50:43.19その場合のために一段噛ましているの、このこともプロクシという。
0617デフォルトの名無しさん
2011/08/16(火) 11:08:44.25> Fooを継承したクラスがbarを持ってなかったらどうするんだよ。
そのFooを継承したクラスをプロクシとして使う以上、
なんからのインスタンスに委譲しようとするのでは？
インスタンスの初期化や入手をどうするか、なんてプロクシクラスの肝では？
> その場合のために一段噛ましているの、このこともプロクシという。
一段かます？ bar.xxx()とfoo.getBar().xxx()という違いや、
if (bar != null)とif(foo.getBar() != null)の違い？
0618デフォルトの名無しさん
2011/08/16(火) 11:13:25.87これでわかったか。
0619デフォルトの名無しさん
2011/08/16(火) 11:15:59.06FooからえられるBarはただのBarではなくある条件を満たすことが保障されてるBarだ、とかあるでしょ
0620デフォルトの名無しさん
2011/08/16(火) 11:16:48.07確かにこれだけだと科目は機能を持ちませんが、実際は科目名などのフィールドを持つはずです
あと将来的に機能がつく可能性もあります。（科目ごとに別の処理をする場合など）
また単純に構造体のような使い方でもわかりやすいというメリットがあると思います
0621592
2011/08/16(火) 11:17:28.59このコードをドメインモデルにするとしたら典型的な問題があります
判定ルールは複数個あって、それぞれが科目リストを持っています
そして当然学生オブジェクトも科目リストを持っています
つまり
学生.Is履修(判定ルール)
か
判定ルール.Is履修(学生)
かどっちを実装するかが自明ではないのです
これがトランザクションスクリプトなら疑う余地なくプロシージャの中で
書き下すだけです
今回はテーブルモジュールなのでレコードに隠ぺいできるところは隠ぺいして
全体の流れはメソッド化しています
0622デフォルトの名無しさん
2011/08/16(火) 11:24:14.40> あと将来的に機能がつく可能性もあります。（科目ごとに別の処理をする場合など）
一安心。
0623デフォルトの名無しさん
2011/08/16(火) 11:56:19.61判定ルールって分析上ただの処理じゃないの？
学科とかそういうイメージ？
0624デフォルトの名無しさん
2011/08/16(火) 12:06:59.95>このコードをドメインモデルにするとしたら典型的な問題があります
>判定ルールは複数個あって、それぞれが科目リストを持っています
？
持っていませんよ
> 判定ルール.Is履修(学生)
このメソッドも持っていませんよ
0625592
2011/08/16(火) 12:13:55.62そうです。学科とか学年とか資格とかで数百個はルールがあります
>>624
日本語がつたなくて伝わらなかったようです
621の投稿は忘れてください
0626デフォルトの名無しさん
2011/08/16(火) 12:39:52.43別個に取り出せない(x,y)からどうやって後者を生成するのだろう
>>601
別に仮想言語でも良いんでない、特定の言語に限定した話はしてないんだから
0627デフォルトの名無しさん
2011/08/16(火) 12:40:15.19さっきのコードでは全員判定ルールは同一だけど、学年ごとや学科ごとに判定ルールが違うという条件を追加したい場合は、さっきのコードでは対応できないという話？
何を想定しているのかを伝えてくれるとわかりやすいです
0628デフォルトの名無しさん
2011/08/16(火) 13:05:34.74P(x,0) + V(x,y)
0629592
2011/08/16(火) 13:16:21.17>>609でいえば
人.get既修科目数()
は
人.get既修科目数(判定ルール)
にするか
判定ルール. get既修科目数(人)
にする必要があります。
オリジナルの>>592ではc=>c.Is履修
と書いてありましたが、内部詳細としてはすでに科目オブジェクトに
学生の履修データがバインドされていたので引数がありませんでした
>>592のポイントはgetterの話だったので説明しませんでしたが
ドメインモデルの話であればこの部分が論点になるかと思って発言しました
0630592
2011/08/16(火) 13:18:44.87＞学年ごとや学科ごとに判定ルールが違う
というより同じ人でも複数の判定ルールがあるということです
卒業ルールとか進級ルールとか交換留学生になれるルールとか
0631592
2011/08/16(火) 13:25:20.34＞さっきのコードでは対応できないという話？
というわけではなくドメインモデルでやろうとするとどっちのドメインオブジェクトに
メソッドを実装していいか悩むよね？って話です
テーブルモジュールなら横断的な処理はスクリプト的に書くことが前提なので
あまり悩まないです。かといってトランザクションスクリプトだとOOの利点が全く
生かせません。
ということが言いたかっただけで何のオチもないです
0632デフォルトの名無しさん
2011/08/16(火) 17:08:01.02既修科目数を取得するのに判定ルールが必要という状況がよくわかりません
＞オリジナルの>>592ではc=>c.Is履修
＞と書いてありましたが、内部詳細としてはすでに科目オブジェクトに
＞学生の履修データがバインドされていたので引数がありませんでした
学生オブジェクトに履修科目などが保持されているのではなく、科目ごとに履修した学生オブジェクトが保持されているということかな
その場合は、科目すべてを保持しているクラスに、引数として学生を渡して、すべての科目から学生が履修している科目を取得し、その単位数の合計を求める。
(ここからは>>609->>611と同じ)その単位数の合計を判定ルールのis判定メソッドに引数と渡して判定とすればいいと思います。
>>630
詳しい状況はわかりませんが、複数のルールがある場合は、以下のようにするのが良いと思っています
main(){
まずすべてをクラスにロード
学校全員.判定(new 卒業判定ルール())
学校全員.判定(new 進級判定ルール())
学校全員.判定(new 交換留学生判定ルール())
}
>>631
判定メソッドは科目や人に直接持たせるのではなく、判定ルールクラスに持たせることでルールの変更を容易にします。
0633デフォルトの名無しさん
2011/08/16(火) 19:27:58.67仮想言語でも良いんだけど、処理の内容が分からなかっただけだよ。
一応しばらく後で、Cの初期化みたいなものか、と思った。
0634デフォルトの名無しさん
2011/08/16(火) 20:19:35.060635デフォルトの名無しさん
2011/08/16(火) 20:38:57.18この過疎スレも消化しといてね。＜オブラーの人たち
0636デフォルトの名無しさん
2011/08/16(火) 23:31:09.08ホレ作ったぞ。
http://codepad.org/7t7xN7Iy
判定ルールにまでgetterがあるんで、
同じ状態を得られることを前提に再定義させてもらった。
0637デフォルトの名無しさん
2011/08/16(火) 23:40:32.03このコードスレの流れと関係なく気になったんだけどさ、
これぐらい簡潔にしてもいいんじゃないか？
処理的にも無駄が多いぞ。
var 既修 = 判定ルール.科目List.Where(c => c.Is既修);
var 履修 = 判定ルール.科目List.Where(c => c.Is履修);
if (判定ルール.Is単位 ){
int 単位計 = 既修.Select(c => c.単位).Sum() + 履修.Select(c => c.単位).Sum();
return 判定ルール.必要単位数 <= 単位計;
} else {
int 科目計 = 既修.Count() + 履修.Count()
return 判定ルール.必要科目数 <= 科目計;
}
0638デフォルトの名無しさん
2011/08/17(水) 02:25:02.06コテンパンにされたよ。getter不要って言っていた奴が。
0639592
2011/08/17(水) 03:29:52.70>>603で触れたように
科目.既修（＝科目.Is既修)
と
科目.履修（＝科目.Is履修)
は変数ではなく実装のある関数ですよ？
確認ですが、本気でこのコードのほうが>>592よりいいと思っているのでしょうか？
そうでなくて「getterなしでも実装できるよ」って言いたいだけならそれは同意します
0641592
2011/08/17(水) 03:47:41.41ちょっとコード書いただけでいろいろ意見が聞けて楽しいです
実際のコードでは履修を含んで判定するかどうかの引数があるというのと
単に判定するだけでなく実際に何単位（科目）だったかを返す機能も持っている
ので４つの中間変数があった方がわかりやすいのです。パフォーマンスは問題に
ならない程度です
でも上記の理由がなかったとしても
最初に書き下すときは>>592のようになると思います
その後「これって簡潔にできるな」と思ってから最適化をして>>637
みたいになると思うのですが、これって読みにくくなると思っています
＃実際>>637よりは>>592のほうが読みやすいと私は感じます
「簡潔にできるな」ではなく「明確にできるな」とか「わかりやすくできるな」
であれば変更しますが
＃もちろんパフォーマンス問題がある場合は別です
0642デフォルトの名無しさん
2011/08/17(水) 07:37:18.15obj.sendValueTo(continuation) のシンタックスシュガー
0643デフォルトの名無しさん
2011/08/17(水) 08:02:10.38関数だろうが変数だろうが値返すんでしょ。
あと、配列を何度もなめるのは読みやすさ以前の問題。
0644デフォルトの名無しさん
2011/08/17(水) 08:34:53.88この規模だと、一応書けるレベルになるな。
本来であればプログラムはでかいから、
わざわざ判定結果だけ取り出すクラスにしない。
クラスには判定結果に基づいた処理も入る。
そうなると
条件でメソッドが別れているほうが１つのメソッドを数十行の分岐で分断されるより見易い。
あと、検索条件を別クラスにしたけど、
ここはライブラリ次第。
検索用にせず単に転送用の汎用クラスとして作り
検索条件を君の様に
オブジェクトを生成したところで全て指定することもできる。
0645592
2011/08/17(水) 13:40:52.62＞検索条件を君の様に
＞オブジェクトを生成したところで全て指定することもできる
検索条件のラムダ式の中でc.Is履修みたいに書けることがgetterのメリットだと思うのですが
そもそも今の流れではgetterの定義が「引数を取らない関数で、副作用を持たないもの」
だと思うのですが、それを廃止する理由がまったくわかりません
＞この規模だと、一応書けるレベルになるな
これは
＞確認ですが、本気でこのコードのほうが>>592よりいいと思っているのでしょうか
に対して「いやおれも本気でこんな書き方がいいっているわけじゃないよ」
ってことでしょうか？
0646デフォルトの名無しさん
2011/08/17(水) 18:31:04.45アクター厨ってことで分かり易いんだがなぁ
0647デフォルトの名無しさん
2011/08/17(水) 19:22:50.540648デフォルトの名無しさん
2011/08/17(水) 20:06:27.26setterでセットしたものが、そのまま出てくるわけじゃなきゃどうでもいいと
思ってるヤツは多いと思う。
0649デフォルトの名無しさん
2011/08/17(水) 20:55:49.000650デフォルトの名無しさん
2011/08/17(水) 22:05:49.83売るものはスマートフォンアプリ WEBサイト運営
サーバーはクラウド VPS
電話はスマートフォンSkype
オフィスは地方にプレハブ型の格安高性能オフィスを建て(300万〜500万)
レンタル自習室＆シェアオフィスで収入を得ながらそこで開発する
http://tinyurl.com/43xmk7m
http://tinyurl.com/3mopkfy
0651デフォルトの名無しさん
2011/08/17(水) 23:37:43.41そもそもgetter嫌いなんて「多いと思う」とかいうほど居たか？www
変なのが一人で暴れてただけだろ
0652デフォルトの名無しさん
2011/08/18(木) 01:46:20.510653デフォルトの名無しさん
2011/08/18(木) 07:36:32.46勝手にgetter嫌いな話が進んでるし割りといる。
getterというかプロパティ嫌いな人は多いんだろ。
0654デフォルトの名無しさん
2011/08/18(木) 09:25:38.00お互い考える機会になるし、お互い負けそうになったら退散するしｗ
まだ気になることがあるなら突っつけば負けず嫌いは帰ってくる
0655デフォルトの名無しさん
2011/08/18(木) 14:39:55.55これだけで使いたくなる
0656デフォルトの名無しさん
2011/08/18(木) 17:11:13.55お前らボタンとか画面とか作れていいな
ひたすらsocketで内部処理
オブジェクト系とかさっぱり分からん
0657デフォルトの名無しさん
2011/08/18(木) 18:54:37.77逆にOOPじゃないからってボタンとか画面作れない訳じゃないぞ
0658デフォルトの名無しさん
2011/08/18(木) 19:23:35.12能がないって言ってんじゃね？
0659デフォルトの名無しさん
2011/08/18(木) 19:45:59.100660デフォルトの名無しさん
2011/08/18(木) 22:38:57.05http://hibari.2ch.net/test/read.cgi/news4vip/1313638404/
0661デフォルトの名無しさん
2011/08/18(木) 22:42:45.77むしろMVCを気にせずMの部分だけがっつりOOできるじゃないか
0662デフォルトの名無しさん
2011/08/18(木) 23:37:53.33本物のOOPじゃないか。うらやましす。
0663デフォルトの名無しさん
2011/08/19(金) 00:16:01.15状態（データ）を関数で書き換えるだけの手続き型。
0664デフォルトの名無しさん
2011/08/19(金) 01:37:41.37GUI作りたいなぁ。
（それはさておき）オブジェクト指向は分からない。
と、言ってるのではないか。
0665デフォルトの名無しさん
2011/08/20(土) 19:13:23.77オブジェクト系が分からないと書いてある。
オブジェクト系って用語は彼の造語だから、何するものか分からないが、
多分、昨今のオブジェクト指向なGUIフレームワークの事だろう。
GUI面白そうで良いな。
分野外だから、
どんなGUIフレームワークが乱立していて、
それぞれどういった長所と短所を持っていて、
どれが人気で、とか、
さっぱりわかんねぇー。
オブジェクト指向のスレと思って開いたけど、
GUIの話ばかりで会話に参加できねー。つまんね。
ってとこでしょ。
0666デフォルトの名無しさん
2011/08/27(土) 11:47:31.740667デフォルトの名無しさん
2011/08/28(日) 00:10:46.99狂人が来ればまた賑やかになるさ。
OOP自体はもう熱が冷めちゃってるからね。
結局、高級アセンブラのC言語がもっとも自由度と汎用性が高いし、
安全さや開発効率なんかは、専らツールやDSLによる所が大きいし。
汎用言語でOOPする必要が有るのか無いのかは、もうどうでも良い話しだし。
どうせ、マルチスレッドの前では無力だしな。
OOPLって大したこと出来ない割りに、
その言語固有のオブジェクトに対する考え方や流儀があって、
なんつーか、ウザイ一面がある。
上手くウソを突き通そうと無駄な努力をしている感じ。
スケーラビリティーとか意味無いから。
0668デフォルトの名無しさん
2011/08/28(日) 00:26:05.53おい、狂人が戻ってきたようだぞｗ
0669デフォルトの名無しさん
2011/08/28(日) 00:26:27.540670デフォルトの名無しさん
2011/08/28(日) 09:10:05.59ちょうどいい話題があるから食いついてみる
うちの会社は組み込みで大半の人がOOPや現在の先端的なITの開発手法やアーキテクチャを知らないんだけど、一応C言語でOOPしようという取り組みもある
これって意味あることだと思う？
UMLを使えるのとドメインモデルを意識して設計開発できるようになる以外に一切メリットがないような気がする
言語機能的にデザパタなどの手法はほとんど適用できないし、できたとしても本来のメリットがを享受しにくい
タスクという概念がUMLで記述できないのも困る
無理やりOOPを実装するのでコードの記述量が跳ね上がる、そこにバグが生まれる
早くC++での開発が当たり前になって欲しい
できるならJavaで…
0671デフォルトの名無しさん
2011/08/28(日) 09:13:04.250672デフォルトの名無しさん
2011/08/28(日) 09:53:37.25Hoge* hoge = Hoge_new();
Hoge_work(hoge);
みたいな再入可能モジュールをオブジェクト指向だと言い張るだけだろ
0673デフォルトの名無しさん
2011/08/28(日) 10:16:10.280674デフォルトの名無しさん
2011/08/28(日) 17:03:31.50GObjectが何で存在すんのかしらべてみ。
0675デフォルトの名無しさん
2011/08/28(日) 17:24:41.89なんで存在すんのか？
C言語がヘボイからか？
0676デフォルトの名無しさん
2011/08/28(日) 19:45:39.580677デフォルトの名無しさん
2011/08/28(日) 19:48:27.580678デフォルトの名無しさん
2011/08/28(日) 19:55:11.74カタリスレにしようぜ。
0679デフォルトの名無しさん
2011/08/30(火) 08:01:26.31まあ中二病的発想だろうね
三年生ともなれば経済ってもんが大まかにでも分かって来て個々人が自分自身の為に精一杯頑張る事が
最も社会（彼らは地球・世界・市民といった表現が好きなようだが）の為になるって事に気付くもんだけど
0680デフォルトの名無しさん
2011/08/30(火) 22:24:31.31GObject？まーあれだな、中二病的発想だろうね。
0681デフォルトの名無しさん
2011/08/31(水) 18:52:17.32仏敵ぶっ倒せ！【ぶってきぶったおせ！】
創価学会に敵対する人物を、読経により学会員全員で呪い殺す為のスローガン。
学会員には年初にマス目を塗りつぶせるポスターが配られる。
読経の度にマス目を塗りつぶし、1千万遍唱え全部塗りつぶせると、仏敵は死ぬと信じられている。
まさに世界が危険認定済みのカルト集団。
国は創価学会を早く解体させるべき。公明党と分離させるべき。政教一致は憲法20条違反だ。
マスゴミは真実を報道しろ。
0682デフォルトの名無しさん
2011/08/31(水) 20:16:42.94Front - Service - Dao+Entityのトランザクションスクリプト型と、
Front - Facade - Domain(O/R Mapper)のドメイン駆動型が入り混じっています。
設計書は残っているのですが開発時のメンバーは居らず、
なぜこんなことをしたのか意味不明な状況です。
一つのシステムで複数の設計思想を使用する理由として何か考えられるものはあるでしょうか。
0683デフォルトの名無しさん
2011/08/31(水) 21:38:13.83隠蔽される部分には何を混ぜてもよい
そもそも実装を解析することはカプセル化に反する
0684デフォルトの名無しさん
2011/08/31(水) 22:13:22.37みんな馬鹿だから設計を知らない。
それが答え。
0685デフォルトの名無しさん
2011/08/31(水) 22:15:10.28お前は、ソースコードを書くことは
カプセル化に反すると言ってるのか？
まったく関係ないものをつなげるなよ。
0686デフォルトの名無しさん
2011/08/31(水) 22:49:03.54まったく関係の無い事言って煽るなよ。
0687デフォルトの名無しさん
2011/08/31(水) 23:03:45.52ソースコード見てはダメというのがカプセル化の目的？
なにいってるんだ？
0688デフォルトの名無しさん
2011/08/31(水) 23:26:02.920689デフォルトの名無しさん
2011/09/01(木) 07:14:19.49EJBで各々の実体が別のサーバに入ってるとかならまだ話もわかるのですが。
幸いどちらも綺麗な設計しててお互いが干渉している部分もないので、
そういうものだと思って解析することにします。
レスありがとうございました。
0690デフォルトの名無しさん
2011/09/01(木) 08:37:57.460691デフォルトの名無しさん
2011/09/01(木) 09:09:13.16単一の思想では行き詰まる場合があるから複数の思想を用いる
0692デフォルトの名無しさん
2011/09/01(木) 12:06:15.50設計思想を揃えることに合理性がないからな
0693デフォルトの名無しさん
2011/09/01(木) 20:35:30.01>>679
>>680
こんなヤツらがOOをドヤ顔で語ってんだからすげぇ〜わ。
0694デフォルトの名無しさん
2011/09/01(木) 21:26:49.62お前馬鹿じゃね？
既存のコード修正する人が
そのコードを解析しないでどうするよｗ
0695デフォルトの名無しさん
2011/09/01(木) 21:52:48.84OOのカプセル化は、透過性を持たせ拡張性を維持するためのものであって、
人が見ない為じゃないんだけど。
0696デフォルトの名無しさん
2011/09/01(木) 22:44:25.190697デフォルトの名無しさん
2011/09/01(木) 23:01:51.60何の事かと訝しんでたらアウトライン機能でコードを畳んであるだけだったのを
思い出しました。
0698デフォルトの名無しさん
2011/09/01(木) 23:29:36.08実体がどうであれ、同じ手順で期待する結果が得られることを透過性という。
OO以外であれば、ファイルシステムなんかが有名所。
ファイルシステムの実体がExtであれ、NTFSであれ、XFSであれ、仮想ディスクであれ、
SFTPであれ、zipアーカイブであれ、デヴァイスであれ、基本的にopen,read,write,closeだけ使ってれば、
問題なく操作できる。
逆に、ファイルシステム側からopen,read,write,closeを持っているアプリケーションを見た表現を仮想という。
0699デフォルトの名無しさん
2011/09/01(木) 23:32:09.850700デフォルトの名無しさん
2011/09/01(木) 23:36:17.47根拠をどうぞ。
http://en.wikipedia.org/wiki/Transparency_(human-computer_interaction)
In software engineering, it is also considered good practice to develop or use abstraction layers for database
access, so that the same application will work with different databases; here, the abstraction layer allows
other parts of the program to access the database transparently (see Data Access Object, for example).
In object-oriented programming, transparency is facilitated through the use of interfaces that hide
actual implementations done with different underlying classes.
0701デフォルトの名無しさん
2011/09/01(木) 23:37:38.21オブジェクトが透過性を無視した振る舞いをすると最悪クラッシュするけど？
0702デフォルトの名無しさん
2011/09/01(木) 23:45:46.180703デフォルトの名無しさん
2011/09/01(木) 23:48:43.260704デフォルトの名無しさん
2011/09/02(金) 08:10:16.330705デフォルトの名無しさん
2011/09/02(金) 23:29:55.52開発効率がC言語に近づいてくる。
問題はOOPLの範疇の外で起こってるのかもね。
0706デフォルトの名無しさん
2011/09/02(金) 23:47:50.19>transparency is facilitated through the use of interfaces
例えば、実体のメンバーが全部publicでも、interface型にキャストすれば問題無い。
原理的にprivateは不要。
privateがなくなったらC言語に近くなる。
0707デフォルトの名無しさん
2011/09/02(金) 23:50:47.89それはどういう事なんですか？
そもそも、非大規模においてはOOPLとC言語のどちらが開発効率が高いと主張してるんですか？
OOPLの範疇の外ってどういう事ですか？
それはC言語においては範疇の外ではないんですか？
なんですか？設計がそもそも問題だ、とかそういう主張をされたいんですか？
0708デフォルトの名無しさん
2011/09/02(金) 23:56:54.68＞原理的にprivateは不要。
＞privateがなくなったらC言語に近くなる。
意味がよく分からないのですが、privateがなくなったらC言語に近くなるっていうのはどういう事ですか？
カプセル化の恩恵が受けられなくなって、安全性が減って、契約事項が増えるって事だと思うんですが、
それがC言語に近くなるって事なんですか？
0709デフォルトの名無しさん
2011/09/03(土) 00:29:39.71private無くなる→カプセル化はファイル単位、ヘッダで区別。ってことでしょ。
機能モジュール単位内では実装に直接アクセス。
機能モジュール単位外にはインターフェースを渡してカプセル化。
C言語では昔ながらの割と普通のやり方。
0710デフォルトの名無しさん
2011/09/03(土) 00:44:52.63OOPの話してるから、てっきりクラスオブジェクトの話をしてるのかと…。
＞カプセル化はファイル単位、ヘッダで区別。
カプセル化、というか昔ながらの隠蔽って表現が似つかわしいですね。
0711デフォルトの名無しさん
2011/09/03(土) 00:54:12.37＞カプセル化はファイル単位、ヘッダで区別。
とはならない気がするんですが、
オブジェクト様の物を使う場合の話をしているのではなく、
globalほげほげとかの話してますか？
だったらそれは完全に"カプセル化"ではなく"隠蔽"と表現すべき物ですよね。
あとインターフェースってのはexternほげげ、とかの話でしょうか？
0712デフォルトの名無しさん
2011/09/03(土) 01:12:32.49本当に、初心者だったようだ。
> たとえC言語でも構造体の内部の名前空間は別個になってるので、
> ＞カプセル化はファイル単位、ヘッダで区別。
> とはならない気がするんですが、
名前空間とカプセル化は関係ないだろ。
名前空間が別でも、publicになってて直接アクセスしてたら
その部分はカプセル化されてねーよ。
> あとインターフェースってのはexternほげげ、とかの話でしょうか？
昔ながらのWin32的なAPI関数のインターフェースもありうるし、
COM風の関数テーブルでも良いだろうし。
C言語は何でもありだから。
0713デフォルトの名無しさん
2011/09/03(土) 02:01:33.88カプセル化について話す時に>>711の1行目は確かにおかしいですね。
オブジェクト様の物を作る事に頭が支配されすぎてました。
自分で見直しても何言ってんだコイツ、なのでそう思われるのはもっともです。
で、>>709を飲み込めました。
>>706は"privateがなくなったらC言語(でのOOP)に近くなる。 "
って事だったんですね。
0714デフォルトの名無しさん
2011/09/03(土) 05:10:50.76同種のオブジェクトが複数存在することを考えると
構造体のがやはり近い気がするなあ
0715デフォルトの名無しさん
2011/09/03(土) 10:32:03.18クラスの話とインスタンスの話を混ぜてない？
0716デフォルトの名無しさん
2011/09/03(土) 11:08:49.18その通り、混ざってないとこんなヘンテコな話の流れになってないってことを言いたいんだよ
0717デフォルトの名無しさん
2011/09/03(土) 12:01:46.33private_hoge_というメンバにモジュール外から直接アクセスする奴がいるかもしれないとか考えるのは
リフレクションでprivateフィールドにアクセスされることを想定するようなもんだろ
0718デフォルトの名無しさん
2011/09/03(土) 13:23:36.03その辺は、プログラマの統制をコーディング規約で取るか
言語の文法で取るかって話だから、
C言語に限定すれば、一般論で言ってアローでアクセス出来る構造体の
メンバを直接参照しにいくのは当然ある。
リフレクションで見るっていうのと比較するなら、
「ヘッダに構造体のメンバを晒さないように作って」るのに、
外部でその構造体のポインタからオフセットでアクセスするようなもんじゃないの？
結局プロジェクト内でコンセンサス取れてればどんな方法でもいい訳で、
労力の多少はあっても、アクセス制限のやり方なんて別になんでもいいだろ。
0719デフォルトの名無しさん
2011/09/03(土) 20:05:51.55相手が誰なのかって概念が抜け落ちているような。
一応、friend指定とかもあるけどさー。
同じネームスペース内にあるものは、全てfriend扱いでも良い気がする。
0720デフォルトの名無しさん
2011/09/03(土) 20:10:51.66リアルに友達いないお前がfriendとか、笑わせんなよ
0721デフォルトの名無しさん
2011/09/03(土) 21:11:04.170722デフォルトの名無しさん
2011/09/03(土) 22:26:49.75protectedやpublicと似てるけど、全くの別物。protected、publicは通信のために用意されてる区分で、
privateは、あくまでペイロードを格納する領域。禿も言っていたが、
本来publicなどと同じ場所に書かれるべきじゃ無いんだけど、パフォーマンス上の都合で
publicやprotectedと同じ場所に置いてる。privateを外にだすと結局pimpに近いことしなくちゃならないからね。
0723デフォルトの名無しさん
2011/09/03(土) 22:35:18.66interface型やid型だけにするって手もあるけどね。
ただ常にinterface経由でしかアクセスできないようにすると、新しいinterfaceを持ったクラスをつくるたびに
interfaceを書く必要があって、初心者や土方にはとっつきにくい。
0724デフォルトの名無しさん
2011/09/03(土) 22:55:17.88全てfirendでいいわけないじゃん。
そもそもfriendはクラス外インターフェースの指定で、
firiend指定された関数や、クラスはあくまでfirend指定したクラスの一部。
逆に、packageスコープというかinternalスコープはインターフェースの拡張じゃない。
そもそもinternalスコープはprivate領域にはアクセスできない。
あくまでもinternalなinterfaceを実現するための仕組み。
0725デフォルトの名無しさん
2011/09/03(土) 23:04:59.58ttp://d.hatena.ne.jp/xuwei/20110623/1308787607
0726デフォルトの名無しさん
2011/09/03(土) 23:16:26.430727デフォルトの名無しさん
2011/09/04(日) 11:03:28.730728デフォルトの名無しさん
2011/09/04(日) 15:54:00.34ポインタがパフォーマンスに悪いって、Cではあまり気にしないね
昔は、アセンブラに比べてCは遅い遅いと言われていたらしいし
C++になってまた速さを気にしだしたのは先祖返りなのかな
0729デフォルトの名無しさん
2011/09/04(日) 17:49:17.36C++よりも洗練された構文を持つ言語が増えて来て
速度で優位に立たないと存在意義が保てないからだろう
低レベルを触れるというだけならCのFFIを持ってれば良いだけだし
0730デフォルトの名無しさん
2011/09/04(日) 19:04:55.13具体的には、ポインタがというよりヒープの問題だけどね。
OSや環境によりけりだけど、newを使うと一回のメモリ確保に最悪で
1ページ分のメモリー(1024B等)を割り当てたりするから非常に空間効率が悪い。
さらに、ヒープメモリーの空き領域特定にファーストフィット等のアルゴリズムを
走らせるんで1〜3回の演算で済む自動変数とは比べ物にならないほど遅い。
ちなみに、これはC++に限らずJavaやら後発の言語でも同じ話。
独自にメモリー管理はしてるが、メモリープールの拡張や、
メモリープール内の探索同じことが起きる。
0731デフォルトの名無しさん
2011/09/04(日) 19:26:02.430732デフォルトの名無しさん
2011/09/04(日) 19:26:28.27C++知ってるヤツだったら、他の言語でグラフィックスや、演算主体のプログラムを書こうと思わんよ。
速度も一つではあるが、それ以上にtemplateと演算子のオーバーロードが無いのが痛すぎる。
いちいち vector = matrix.mul( vector.mul( 3 ) );とかやっとられん。
0733デフォルトの名無しさん
2011/09/04(日) 19:28:16.95いや普通に使う。そもそも、OOの発端は群体の計算だし。
高速計算ライブラリBlits++は、完全にOOベースだし。
0734デフォルトの名無しさん
2011/09/04(日) 19:28:51.330735デフォルトの名無しさん
2011/09/04(日) 19:35:00.310736デフォルトの名無しさん
2011/09/04(日) 19:36:01.72FORTRANが科学技術演算に使われる理由はベクトル化のしやすさだけでなく、
最初からメモリー領域を確保していてメモリー確保のウェイトがかからないからだ。
Blits++に於いてもExpression Templateによってヒープの確保はループなどでは
殆ど発生しないようになってる。
0737デフォルトの名無しさん
2011/09/04(日) 19:39:09.31だからどうでもいいと言ってるんだけど
0738デフォルトの名無しさん
2011/09/04(日) 19:41:18.200739デフォルトの名無しさん
2011/09/04(日) 19:42:01.77いつまで続くか怪しいけどね。ただ、分岐が絡む演算だとまだまだCPUでの演算だわな。
0740デフォルトの名無しさん
2011/09/04(日) 19:43:07.06じゃレスしなきゃいいだろ。
0741デフォルトの名無しさん
2011/09/04(日) 20:03:39.48言葉足らずですまん。言語やプラットフォームに関わらず、どうせ>>736のように
メモリ確保がボトルネックにならないように作るからそれ自体のコストは問題にならないということ。
それがオブジェクト指向的でないと言われたらそうかもしれないが。
0742デフォルトの名無しさん
2011/09/04(日) 21:17:06.54> そもそも、OOの発端は群体の計算だし。
どっからそんなアホなデマが...
0743デフォルトの名無しさん
2011/09/04(日) 22:00:44.42>気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
>一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が
>自然で取り扱いやすい。その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が
>必要となる。こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
http://ja.wikipedia.org/wiki/Simula
Wikipediaに限らず他でも色々と書いてある。
アラン・ケイと禿が分子の群体シミレーションに発想を得たというのは、
そこそこ知られた話。
0744デフォルトの名無しさん
2011/09/04(日) 22:02:24.060745デフォルトの名無しさん
2011/09/04(日) 22:06:10.43「思った」
で？
0746デフォルトの名無しさん
2011/09/04(日) 22:08:37.41相互作用計算がO(N^2)だったりして圧倒的に重いからそこだけ上からやっちゃえば
他はオブジェクト指向的に扱っても全然問題なし
0747デフォルトの名無しさん
2011/09/04(日) 22:09:57.58怒んなやｗ 反論でもいちゃもんでも何でもないんだから。まさに、思っただけ。
0748デフォルトの名無しさん
2011/09/04(日) 22:13:42.780749デフォルトの名無しさん
2011/09/04(日) 22:16:40.250750デフォルトの名無しさん
2011/09/04(日) 22:20:23.74群体 とやらを調べてから出直してこいよ。
0751デフォルトの名無しさん
2011/09/04(日) 22:24:02.42MDってやつ
0752デフォルトの名無しさん
2011/09/04(日) 22:24:14.33コロニーの事だからどうでもいいけど。
0753デフォルトの名無しさん
2011/09/04(日) 22:25:36.580754デフォルトの名無しさん
2011/09/04(日) 22:36:01.48まあ、どうでもいいか。
0755デフォルトの名無しさん
2011/09/04(日) 22:51:13.760756デフォルトの名無しさん
2011/09/04(日) 22:53:21.38字面があわないと文が読めないコミュ障なのかな。
0757デフォルトの名無しさん
2011/09/04(日) 22:57:07.11人のことを心配する前に、自分の日本語能力心配しろよ。
>> 間違っちゃいなけど、
0758デフォルトの名無しさん
2011/09/04(日) 23:06:39.550759デフォルトの名無しさん
2011/09/04(日) 23:09:57.65意味合いが強い気はする
0760デフォルトの名無しさん
2011/09/04(日) 23:14:22.09http://www.atmarkit.co.jp/aig/04biz/oo.html
>単細胞生物のコロニーのようにソフトウェア・モジュール同士が
>協調動作するというプログラミング・アーキテクチャの着想を得た。
>ケイの回想によると、これを「オブジェクト指向プログラミング」と呼んだのは1967年だという。
分子云々は置いといて、コロニー(群体)そのものの話もあるわけだけど、
それについては、どういい訳するつもり？
0761デフォルトの名無しさん
2011/09/04(日) 23:22:47.70何か言い訳が必要なのかな？
0762デフォルトの名無しさん
2011/09/04(日) 23:28:45.02ふ〜ん。日本語を(ry
0763デフォルトの名無しさん
2011/09/04(日) 23:36:19.75あれ？ なんで最後まで書かないの？
まあ、着想と計算が一緒とはさすがに恥ずかしくていえないか。
0764デフォルトの名無しさん
2011/09/04(日) 23:43:09.51> >>733
> > そもそも、OOの発端は群体の計算だし。
>
> どっからそんなアホなデマが...
これ書いたのあんたでしょ。
自分で「そもそも、OOの発端は群体の計算だし。」に引用符
振っといて何いってんの？
"OOの発端は群体=着想は群体"って事だろ
隠さずに言うけど、ホントに日本語勉強しなおしたら？
文法とかじゃなくて、小学校で求められる読解力の日本語をね。
0765デフォルトの名無しさん
2011/09/04(日) 23:58:00.66どっから出てきたのって書いてるんだけど。
>>750 とか >>754 とか書かれたら、普通わかると思ったんだが、>>756 で逆切
れしてるような頭じゃしょうがないかな。
まあ、「群体シミレーション」なんて堂々と書く人だしね (pgr
0766デフォルトの名無しさん
2011/09/05(月) 00:01:27.85世界ではじめて俺が言った言葉
0767デフォルトの名無しさん
2011/09/05(月) 00:18:42.650768デフォルトの名無しさん
2011/09/05(月) 00:30:54.54ソフトウェアの開発がどういう風に楽になるんだ？
0769デフォルトの名無しさん
2011/09/05(月) 00:37:00.58そもそも、分子の多体問題や群体活動に類する課題にOOが向いてるという話。
0770デフォルトの名無しさん
2011/09/05(月) 00:40:39.64いや、もうオレオレ解説はいらないから。
>>767
さあ？ >>733 にでも聞いてみたらいいんじゃね。
0771デフォルトの名無しさん
2011/09/05(月) 00:43:46.92「群体シミュレーション」がおかしい!?
http://www.google.co.jp/search?sourceid=chrome&ie=UTF-8&q=Colony+simuration#hl=ja&
safe=off&pwst=1&sa=X&ei=JJxjTquPLsPTmAWLi6GfCg&ved=0CBsQvwUoAQ&
q=%E7%BE%A4%E4%BD%93+%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3&spell=1&
bav=on.2,or.r_gc.r_pw.&fp=99f03f2e1f417722&biw=1156&bih=688
ぐぐれば5万件以上でてくるぞ。
0772デフォルトの名無しさん
2011/09/05(月) 00:44:46.52そんな超特殊な問題への適用の成否を議論することで、人類の有用な知識の総量を増やすことに
どう貢献するのか全く理解不能だな。
一つ言うなら、そういう大規模計算にオーバヘッドの大きい抽象化技術を使おうとするのが、
そもそも根本的に誤っている。OOの適用によるメリットをもう一回リストアップしてみろ。
0773デフォルトの名無しさん
2011/09/05(月) 00:47:09.51http://translate.google.co.jp/
オレオレ用語だと言いたいんなら、
ここに群体って打ち込んで英語に翻訳してご覧よ。
0774デフォルトの名無しさん
2011/09/05(月) 00:51:20.71特殊っつうか、もともと話の流れが高速計算分野でも
Blits++とか使うようなOOベースの開発があるって事だったわけで、
別に明日から、OOは科学技術計算のためにしろとか言っているわけじゃないんだよ。
0775デフォルトの名無しさん
2011/09/05(月) 00:54:26.02そんなん言うたら>>743、もといSimulaを全否定じゃね？
0776デフォルトの名無しさん
2011/09/05(月) 00:59:13.86シミレーション につづいて simuration ですか...、ネタですよね？
>ぐぐれば5万件以上でてくるぞ。
ひょっとして、グーグルすらまともに使えないのか？
"群体シミュレーション" ⇒ 65件
"群体シミレーション" ⇒ 0件
0777デフォルトの名無しさん
2011/09/05(月) 01:02:16.05ちょっと性格わるいよ
0778デフォルトの名無しさん
2011/09/05(月) 01:03:35.30ミトコンドリアとかよく俺らといっしょに生きてるよな
0779デフォルトの名無しさん
2011/09/05(月) 01:04:56.98基本的にOOの概念そのものがオーバーヘッドを生むんじゃなく
実行環境次第だから、別に大規模計算にOOが向かないわけでもないぞ。
template使ったり、LLVMで実行時インライン展開したり、
GPUとかベクトル回路を抽象化したりとか色々実装手段は有るわけだし。
0780デフォルトの名無しさん
2011/09/05(月) 01:06:19.55さっきから揚げ足取りしかしてないように見える・・・
0781デフォルトの名無しさん
2011/09/05(月) 01:10:33.24誰も「用語」って書いてないんだけど、変な電波受信してるんか？
群体も Colony も、>>743 のリンク先に出てこないだろ。
気体分子の集まりを群体とか言う奴はちょっとおかしいと思った方がいい。
明らかに違うものだから。
>>777, >>780
いや、まじめな話、"群体シミュレーション" の検索結果見てみりゃわかると思うけど、
世間で群体シミュレーションなんて用語はほとんど使われてないよ。
0782デフォルトの名無しさん
2011/09/05(月) 01:12:34.02で？「群体のシミュレーション」だったりしたら違うわけか。
揚げ足取りはどうでもいいから、本質的に何が問題なのか
具体的に書いてみろよ。
0783デフォルトの名無しさん
2011/09/05(月) 01:14:09.17>>760にコロニーってでてんじゃん。
0784デフォルトの名無しさん
2011/09/05(月) 01:16:08.28群体シミュレーションを用語として使ったわけじゃないけど？
群体のシミュレーションと書いてなかったのが不満なわけ？
0785デフォルトの名無しさん
2011/09/05(月) 01:24:00.13分子等の群の体系をColonyとして表現する人や、
Colonyを使って説明しようとする人はぼちぼちいるんだけど。
ttp://www.ncbi.nlm.nih.gov/pmc/articles/PMC1243806/
ttp://www.waseda.jp/wias/researchers/plofile/prof_k_endo.html
0786デフォルトの名無しさん
2011/09/05(月) 01:31:10.010787デフォルトの名無しさん
2011/09/05(月) 01:34:07.61あいつら得るもののないクソレス伸ばして何が楽しいんだろうな
0788デフォルトの名無しさん
2011/09/05(月) 01:41:05.77初めから、「群体」なんて関係のない言葉使うのがおかしいって書いてあるんだが、
理解できてないってことなの？
>>783
> 「コロニーから着想する」のと「群体の計算」だと相当違うと思うんだけど、
いや、区別できないというなら、別にそれでもいいけど。
>>784
論文の対象によって、そういう説明することもあるけど、そのリンク先にも
「一般的な『群体』とは生物などで定義される細胞の集合」
って書いてあるでしょ？ それが普通の解釈。
0789デフォルトの名無しさん
2011/09/05(月) 01:48:04.78プレステをファミコンと呼んで、ファミコン貸してくれって言われて、
これはPSだから、これはPSだからって言ってるガキと
大して変わらないことにいつになったら気づくのかねぇ。
0790デフォルトの名無しさん
2011/09/05(月) 01:59:49.93同じように >>750 でちゃんと調べろって言われてるのに、コロニーとか言い出す
アホガキはどっちなんだろうね (w
0791デフォルトの名無しさん
2011/09/05(月) 02:14:15.090792デフォルトの名無しさん
2011/09/05(月) 02:33:29.760793デフォルトの名無しさん
2011/09/05(月) 08:39:33.18最適化が揚げ足取りを助長している
0794デフォルトの名無しさん
2011/09/05(月) 08:46:19.08> 初めから、「群体」なんて関係のない言葉使うのがおかしいって書いてあるんだが、
え？>>742にはそんなこと書いてなくね？
お前が無知さらしたあげく発狂してるようにしか見えんが？
0795デフォルトの名無しさん
2011/09/05(月) 09:15:38.65なんかうまいこと言おうとしてるのは伝わるけど、意味不明な文章にしかなってない。
まあ、>>742 に「群体」ってはっきり書いてあっても、「書いてなくね？」って、アホ晒し
ている奴もいるし。
そこでわからなくても、>>750 見ればわかると思ったんだけどね。
0796デフォルトの名無しさん
2011/09/05(月) 09:20:37.94書いてたら>>788にも説得力あったけどね。
実際は「どっからそんなアホなデマが...」だからね。
まあ、お前がアホで無知でもいいじゃん。今までそれで生きて来れたんだろ？
0797デフォルトの名無しさん
2011/09/05(月) 09:35:10.70実行環境や細かい最適化よりもまずアルゴリズム次第だ
例の分子動力学シミュレーションに限るならOOは全くオーバーヘッドにならんぞ
相互作用だけなんとかすればスクリプト言語でも余裕
0798デフォルトの名無しさん
2011/09/05(月) 10:01:46.30おっさん「わしゃ、デジタルなんぞ判らん！」
若造「あんたのその言い方が、デジタルなんだよ！」
0799デフォルトの名無しさん
2011/09/05(月) 10:13:59.49またどの分野で適していないかをリストアップしていくことだな。
それができないなら何の意味もない。
0800デフォルトの名無しさん
2011/09/05(月) 10:21:59.97> simuration
m9(^Д^)ﾌﾟｷﾞｬｰｰｰｯ
0801デフォルトの名無しさん
2011/09/05(月) 10:27:50.53>>750, >>754, >>765 まで書いてあれば普通何が馬鹿にされてるかぐらい
気づきそうなもんだけどね。
まあちょっと頭冷やしたほうがいいんじゃね？
0802デフォルトの名無しさん
2011/09/05(月) 12:58:20.16分子でなかろうが、群体の計算から着想を得たってのは事実だし、
それをデマだって書いた時点であんたの負けだよ。
0803デフォルトの名無しさん
2011/09/05(月) 15:43:39.59だって、「群体の計算」なんてわけわからんこと書いてあったら、デマって書くしかないでしょ？
デマじゃないと言うなら、「群体の計算」って書いてあるソース示せばいいんじゃね？
0804デフォルトの名無しさん
2011/09/05(月) 16:48:22.970805デフォルトの名無しさん
2011/09/05(月) 17:51:23.620806デフォルトの名無しさん
2011/09/05(月) 18:05:04.55なんでスルーできないの？
こういうスルーできない奴も荒らし扱いにするべき
0807デフォルトの名無しさん
2011/09/05(月) 18:21:51.07Scalaスレに迷い込んだのかと思った
0808オマエモナァ〜
2011/09/05(月) 18:35:29.85そうだよね〜、「群体の計算」なんてねよく知りもしないこと偉そうに書いちゃいました、ごめんね
って書けばすむのにね (w
0809デフォルトの名無しさん
2011/09/05(月) 18:55:40.01流石にスクリプトはキツいぞ。
Perl見たいな疑似インタプリタなら別だろうけど。
0810デフォルトの名無しさん
2011/09/05(月) 19:09:23.42無理してスクリプト言語で書く必要ないしな。
つーか、下手なスクリプト言語よりC++の方が使いやすいし。
汎用向けのスクリプト言語ってマジ意味ないと思う。
DSLにしたって、HLSLやSQLレベルまで作りこまないと使い物にならないし。
コンパイラや処理系がバグ持ちだったりするしな。
世界標準で最古からあって、これからも永遠に不滅で、
枯れてて、誰でも知ってて、何処でも動く、
C言語割とマジで最強。
C++も良かったんだけど、0xで死ぬかもな。
0811デフォルトの名無しさん
2011/09/05(月) 19:13:15.910812デフォルトの名無しさん
2011/09/05(月) 19:19:26.02用語じゃなくてただの日本語だろそれ
日本人じゃないの？
0813デフォルトの名無しさん
2011/09/05(月) 19:26:29.300814デフォルトの名無しさん
2011/09/05(月) 19:28:58.40元はなんだっけ？
>>742に対して>>743出したらうんこが噛み付いてきたんだっけ？
でやっぱり>>742は大嘘吐きの糞野郎ってことでこの話もう終わってるんだろ？
新しい話題ねーじゃん
0815デフォルトの名無しさん
2011/09/05(月) 20:07:36.010816デフォルトの名無しさん
2011/09/05(月) 20:42:57.18包含関係ってわかる？
日本人なら、普通にわかってると思ったけど、君には難しかったみたいね。
>>814
> この話もう終わってるんだろ？
終わってる話、蒸し返すほど悔しかったの？
0817デフォルトの名無しさん
2011/09/05(月) 21:17:27.10群体の抗力係数なんてもんが有ることを知った。
0818デフォルトの名無しさん
2011/09/05(月) 21:22:03.960819デフォルトの名無しさん
2011/09/05(月) 21:52:23.790820デフォルトの名無しさん
2011/09/05(月) 22:11:14.92ネット上の掲示板等での議論において、結論はすでに明白なのに、負けているのに負けを認めず、
相手が諦めるまでつまらない反論を次から次に持ち出してずるずると引き延ばし続ける者のこと。
http://dic.nicovideo.jp/a/%E7%84%A1%E6%95%B5%E3%81%8F%E3%82%93
0821デフォルトの名無しさん
2011/09/05(月) 22:20:41.75自己紹介乙。
0822デフォルトの名無しさん
2011/09/05(月) 22:22:19.59http://www.netis.mlit.go.jp/NetisRev/Search/NtDetail5.asp?REG_NO=CB-000025&TabType=&nt=
ここでは、護岸ブロックの集まりの事を群体と読んでるねぇ
英語のコロニーには、集落とか植民地ってのも含まれるし
使われ方としては「一定の範囲に集まると意味を持つ集団、集合」って事なんじゃない
Objectって言葉だって、日本語的に捕らえると相当あいまいな言葉だし
0823デフォルトの名無しさん
2011/09/05(月) 22:39:33.56そもそもいろんなものを「群体」って呼ぶことがあるのは >>784 に書いてあるし、
それについても >>784 のリンク先に書いてあるように、一般的とは言えない。
0824デフォルトの名無しさん
2011/09/05(月) 22:49:27.900825デフォルトの名無しさん
2011/09/05(月) 22:50:28.96そんなに正確な表記が好きなら、>>819の様な無様な間違いはしないほうが良いと思うの
0826デフォルトの名無しさん
2011/09/05(月) 22:51:18.80群体スレでも立ててそっちでやってよ。
ここは群体スレじゃないんだからさ。
んーじゃ、仕方ないから。
マーク&スイープのガベコレって要る？
結局メモリの管理しかしてくれないし。
ファイナライザでデッドロックとかしたら嫌だなぁ。
0827デフォルトの名無しさん
2011/09/05(月) 22:53:40.45GCに何を求めてるんだよｗ
0828デフォルトの名無しさん
2011/09/05(月) 23:00:14.01OOPLじゃなくてもLispみたいにガベコレ実装してる言語あるし、
OOPLでも参照カウント式とか自己管理式とかあるし。
0829デフォルトの名無しさん
2011/09/05(月) 23:06:02.600830デフォルトの名無しさん
2011/09/05(月) 23:14:10.30VB自体バカしか使わないから、バカにされる存在でしかなかったけど。
クラスを継承すると、インターフェースだけ継承された。
もちろん実体継承できたに越したことはないが、実体を持つクラスを
継承する場合も実体継承しないようにできるってのは、他の言語でも欲しい機能だ。
インターフェースが不要になる。
0831デフォルトの名無しさん
2011/09/05(月) 23:19:06.130832デフォルトの名無しさん
2011/09/05(月) 23:20:35.131.Java,.net環境のファイナライザ
2.関数型言語や、Perl等手続きベースの側面で見た場合の後片付け。
1.だと一部のOOPLの話
2.だと自動リソース解放が絡む言語全般の話。
0833デフォルトの名無しさん
2011/09/05(月) 23:23:41.67なぜ？VBの継承概念はCOM由来だったからか？
それとも親クラスに対する期待を子クラスが裏切れるからか？
0834デフォルトの名無しさん
2011/09/05(月) 23:31:20.36インターフェース継承になるようになってたら便利だったろうけどな。
インターフェースとクラスの定義が別れてるなんて結局実装上の都合じゃん。
0835デフォルトの名無しさん
2011/09/05(月) 23:49:51.810836デフォルトの名無しさん
2011/09/05(月) 23:53:37.34あと、親がパッケージスコープなら子もパッケージスコープにすればいいでしょ。
0837デフォルトの名無しさん
2011/09/06(火) 00:12:15.31なぜ「便利」を肯定して「都合」を否定するのかさっぱりわからない
0838デフォルトの名無しさん
2011/09/06(火) 00:20:13.81相手すんなし。時間の無駄の気配がプンプンしやがる。
0839デフォルトの名無しさん
2011/09/06(火) 00:24:22.96例えば大人の都合だらけのEC++はだれも寄り付かず、
便利なフリースタンディングのC++に流れて行ったしね。
0840デフォルトの名無しさん
2011/09/06(火) 00:24:50.71それじゃパッケージスコープの意味がないだろ
パッケージ外からみれば隠蔽されるべき実装の詳細なんだから
0841デフォルトの名無しさん
2011/09/06(火) 00:36:20.81今までだって、継承でパッケージスコープのあるクラスを継承できたわけでしょ。
何が引っかかるの？
0842デフォルトの名無しさん
2011/09/06(火) 00:42:15.77実装継承の意義って、デフォルトの実装が得られる以外あんまり解からん。
純粋仮想クラスばっかり使うのに比べて、実装継承が無いと無理ってな事って
デフォルト実装以外にあるの？まぁ、テンプレートを使う場合は別だろうけどさ。
0843デフォルトの名無しさん
2011/09/06(火) 01:02:41.45サブクラスのパッケージが別の場合、
実装を継承しないとパッケージスコープのメンバが使えなくなるだろ?
0844デフォルトの名無しさん
2011/09/06(火) 01:11:28.72ダックタイピングなら仕様の継承は不要だから
消去法的に実装継承は必要という見方がある
もちろん、消去法は詭弁であって両方とも不要だという意見もある
0845デフォルトの名無しさん
2011/09/06(火) 01:14:09.62使う気があったら実装継承するだろうし。
まぁ、継承してパッケージスコープに介入ってのもどうかとは思うけど。
それなら移譲で受け取ったオブジェクトを経由してパッケージにアクセスするでしょ。
0846デフォルトの名無しさん
2011/09/06(火) 01:18:40.34ダックタイピングであれデフォルト実装の域を出ないよね。
SmalltalkやObjective-Cみたいな、そもそもオブジェクトを生成できないとか
そういうレベルの問題があるケースってないんかねぇ。
0847デフォルトの名無しさん
2011/09/06(火) 01:20:28.94そうじゃなくて、スーパークラスが属するパッケージ内の他のクラスが
スーパークラスのパッケージスコープメンバに依存してるかもしれないだろ
設計の良し悪しはともかく現実にはよくあるでしょ
0849デフォルトの名無しさん
2011/09/06(火) 01:24:40.50なんかそれって危なくね？
子クラスが、別パッケージの親クラスの、internalメンバーにアクセスする訳だろ。
internalなメンバーって、Eclipseのライブラリなんかだとバージョンによって
消えたりするよな。
0850デフォルトの名無しさん
2011/09/06(火) 01:32:00.40なるほどね。
パッケージスコープがある言語においてはそうだね。
0851デフォルトの名無しさん
2011/09/06(火) 05:46:01.21GoFやEffective Javaなんかでは実装継承より集約を薦めているけど
0852デフォルトの名無しさん
2011/09/06(火) 06:54:32.80DefWindowProc相当とか俺かけねーよ。
0853デフォルトの名無しさん
2011/09/06(火) 07:14:06.79描画とか変更するんであれば、描画処理を行うオブジェクトを
差し替えてやるべきだろうし。
毎回描画処理を差し替えたwindowを作るのが面倒なら
ファクトリーの出番でしょ。
やるかどうかは別として、結構委譲ですませられる
とこは多いね。
0854デフォルトの名無しさん
2011/09/06(火) 09:19:48.08マーチンファウラーは実装の継承を、
これはいい差分プログラミングだ、とおおはしゃぎしてたようだが。
0855デフォルトの名無しさん
2011/09/06(火) 16:24:08.31それはそうだけどRADで都合が悪い
アプリケーションレベルの設計まで持ち込んだGUIフレームワークは糞
0856デフォルトの名無しさん
2011/09/06(火) 16:34:40.08そういえばファウラーの継承についての意見を見たことないんだけど書籍やホームページに彼の主張が書いてあるところないかな
とりあえずぐぐってみる
0857デフォルトの名無しさん
2011/09/06(火) 16:40:11.93一般的なモデル部分ではわざわざ実装継承をしろっていう主張はほとんどなさそうだな
委譲と継承:カタコト備忘録 http://app.f.m-cocolog.jp/t/typecast/568631/1012090/51728131
0858デフォルトの名無しさん
2011/09/06(火) 22:29:39.08スレの趣旨とずれるが、RAD、RADとよく聞くが、
VBとVS.net環境以外でRADを本格的に使ったりするかな？
俺の周りだと、なんだかんだしてるうちに、レイアウト崩壊したり、
結局コード上でレイアウト変更するん事になって無意味な場合が多いぞ。
0859デフォルトの名無しさん
2011/09/06(火) 23:04:35.850860デフォルトの名無しさん
2011/09/06(火) 23:37:44.48> (「群体の計算」なんて) おかしいよって意見と延々と一人で戦い続けて何も思わないのかねぇ。
そうだよねぇ、俺もそう思うよ (w
>>825
指摘、ありがと。
IME は、自主規制してるのか知らんけど、変換できないからつい見落としたよ。
って、間違ってたら普通に訂正すればいいだけなのに、コロニーとか (w
0861デフォルトの名無しさん
2011/09/07(水) 09:06:32.11自分の間違いをIMEの所為にするのは良くない
0862デフォルトの名無しさん
2011/09/07(水) 09:19:08.21なんのRADだったか忘れたが、
有償のRADツールで画面編集して保存したら壊れて開けなくなった。
それ以来トラウマ。
0863デフォルトの名無しさん
2011/09/07(水) 18:45:55.15OOはメンバーのユニオンなんてメモリ効率の良い器用な事はできないが、思考がすっきりする事と、楽ちん。
制御組込みでUMLを使うなんて夢にも思ってなかったが．．． ｗ
かつて、モジュール設計とかなんたらで悩んでいたのはいったいなんだったのか？
応答速度？ 何でも有りのワンチップだよ 君 ｗ PCの世界とは違う。
0864デフォルトの名無しさん
2011/09/08(木) 01:39:43.01あんな小規模プログラム、
別にOOを使うまでもない。
あ、組み込みで大規模なら
OO使うのはあたりまえだよ！
0865デフォルトの名無しさん
2011/09/08(木) 01:50:29.420866デフォルトの名無しさん
2011/09/08(木) 06:02:33.770867デフォルトの名無しさん
2011/09/09(金) 23:39:53.700868uy
2011/09/11(日) 16:57:55.49本当にレベルが低いなぁ
進化が遅い
0869デフォルトの名無しさん
2011/09/11(日) 17:00:05.480870デフォルトの名無しさん
2011/09/11(日) 17:45:16.94アスペルガー思考のスレにでも行ってろよ。
0871uy
2011/09/11(日) 21:34:04.900872デフォルトの名無しさん
2011/09/16(金) 21:25:01.79Getter/Setterとは何だったのか
0873デフォルトの名無しさん
2011/09/17(土) 13:25:42.85そんなのオブジェクト指向の本質とはなんの関係もない
0874デフォルトの名無しさん
2011/09/17(土) 13:31:39.360875デフォルトの名無しさん
2011/09/17(土) 13:31:39.50Getter/Setterとはインタフェースの一例。
0876デフォルトの名無しさん
2011/09/17(土) 14:22:12.410877デフォルトの名無しさん
2011/09/17(土) 20:29:30.15どんな設計が良いのでしょうか？
それとも、バッチ系はOOを使用しない方がいいのでしょうか？
0878デフォルトの名無しさん
2011/09/17(土) 21:43:15.430879デフォルトの名無しさん
2011/09/17(土) 21:57:33.49逆に今までOOを何に使ってきたんだろうか…？
0880デフォルトの名無しさん
2011/09/17(土) 22:34:47.32って、プログラム群を処理目的ごとに区切り、この区切り毎に順次実行してゆくバッチ処理のことを指していると思われ。
たしかにOOって意味ない
まぁでも絶対使っちゃ駄目ってレベルでもないわなw
0881デフォルトの名無しさん
2011/09/18(日) 12:42:12.86継承はinheritって機能の訳語で、
言語構文に依存した名前でしょ。
ハンドルの継承とかディスクリプタの継承とかと同じ汎用的な意味で、
"継承"という言葉自体はOOに専属しているわけじゃない。
0882デフォルトの名無しさん
2011/09/18(日) 12:47:28.01こういうのとかグラフ処理とか。
actionMap[new OptionKey("キー1")] = new ActionA();
actionMap[new OptionKey("キー2")] = new ActionB();
actionMap[new OptionKey("キー3")] = new ActionC();
var source = new XMLSource("・・・.xml");
source.process(actionMap);
0884デフォルトの名無しさん
2011/09/18(日) 20:59:47.83信者なら Rubyが使える=Rubyを使わなければならない だから
0885デフォルトの名無しさん
2011/09/18(日) 21:14:16.39よくある手順、既にコマンド化されてるものを順番に流すだけとかファイルを移動するだけなら
シェルスクリプトが一番簡潔だろうし、デリミタだけで分けてあるデータを元に処理するなら
awkがやりやすいだろ。CADデータの変換とかならC++じゃないとまずやってられないし。
0886デフォルトの名無しさん
2011/09/18(日) 21:20:33.98.bat だけがバッチ処理ではないぞ…
0887デフォルトの名無しさん
2011/09/18(日) 21:23:02.75話外れるが、汎用機だとbat処理というとsh系の処理を指すことが多いね。
スクリプト有りきみたいでなんかちがうけど。
0888デフォルトの名無しさん
2011/09/18(日) 21:24:38.30てことはバッチ処理のことをbatと呼んでたのか
…かなり誤解を招きやすい表記だと思うのだが
0889877
2011/09/18(日) 23:26:07.21一般的なOOが使われているのはWin３２・Webアプリなど対話型（リアルタイム処理）です。
対話型では現状の状態を持たせているオブジェクト指向と相性がいいのですが（アクターモデルやメッセージパッシングなど）
バッチ処理では、データを長期間保持する必要はありませんし、オブジェクトを作成が逆に
オーバーヘッドになってしまいます。
レスポンスが一番求められるバッチ処理で、オブジェクト指向の上手な使い道は何でしょうか？
0890デフォルトの名無しさん
2011/09/18(日) 23:28:51.57使う環境にもよるが、大抵処理はインライン展開やスタックフレームの割付に変わる。
0891877
2011/09/19(月) 00:54:14.50その為いまだに、バッチ処理は汎用機で行うのがメインです。
（汎用機とはホストです、WSやServerではありません）
今年起こった、みずほ銀行の障害も夜間バッチが朝までに処理出来なかった為です。
（PCより何千倍早い汎用機でも、何時間も掛かるのです）
このようバッチ処理では、リアルタイム処理より処理速度が数段厳しく求められます。
少しの処理速度の違いでも大量データでは、処理速度の差が大きく現れます。
0892デフォルトの名無しさん
2011/09/19(月) 00:58:59.250893デフォルトの名無しさん
2011/09/19(月) 01:36:11.50オープン系サーバでのバッチ処理も今はあるけどね
0894デフォルトの名無しさん
2011/09/19(月) 05:54:15.00構造から変えないとダメだろうな
オブジェクトの生成で左右されるような作りにしちゃダメ
そのレベルのことを気にするのであればメモリ管理をＯＳにまかせちゃダメ
でかい領域をもって全部自分で管理
0895デフォルトの名無しさん
2011/09/19(月) 07:12:28.86テキストファイルにするだけでもかなり早くなる。
バイナリーならなお早い。
0896デフォルトの名無しさん
2011/09/19(月) 10:50:55.930897デフォルトの名無しさん
2011/09/19(月) 11:37:31.99偉い時間が掛かるんだよ。
目的とする操作単純なら単純な程その無駄がボトルネックになってくる。
0898デフォルトの名無しさん
2011/09/19(月) 11:44:55.32え？まさか
テーブル結合しない場合 と テーブル結合した場合を比較してるの？
それじゃ比較になってないだろｗ
0899デフォルトの名無しさん
2011/09/19(月) 11:49:08.47OOだけで遅くなるとしたら、関数参照だけではないかな?（C++の場合)
いっとくが、オブジェクトをあちこちで生成・廃棄するのがOOじゃないからな！！
後は言語依存のコンパイラの性能、C++はそのオーバーヘッドがとても少ない。
0900デフォルトの名無しさん
2011/09/19(月) 11:49:10.97お前のは小規模システムでの話しかしてないな。
大規模システムでは、マシン一台じゃおいつかないから複数台連携する。
そういうときにバイナリファイルで複数マシン連携とかやってられない。
0901デフォルトの名無しさん
2011/09/19(月) 11:51:54.04OOから単なる手続きに組み直すより効率をあげられるって言ってるの。
0902デフォルトの名無しさん
2011/09/19(月) 11:55:42.72大規模システムなら単純なマスターをDBから外して
共有ファイルにするのは常套手段だと思うけど。
保険屋とかに卸すERPなんかで良くつかわれてんじゃん。
0903デフォルトの名無しさん
2011/09/19(月) 12:04:41.32そんなんじゃ適切なロックもかけられやしない。
SQLサーバーのように、ファイルの読み書きはサーバーに要求を投げるだけ。
あとはサーバーが適切に要求を処理しファイルを読み書きしデータを返す。
サーバーがやるべき処理がSQLというクエリーにまとまっているから
並列動作させやすい。統計データとクエリーの内容から最適な方法でデータ取得を行える。
パフォーマンスなんて必要ない小規模なシステムでは意味が無いだろうが。
大規模なシステムではSQLサーバーなどを使うことで大幅なパフォーマンス向上が行える。
0904デフォルトの名無しさん
2011/09/19(月) 12:13:30.99保守でもなきゃ書き換えないデータでロックとか同期とかバカだろ
ものによってはファイルのタイムスタンプが変わらない限り
メモリーにキャッシュしっぱなしなんだぞ
0905デフォルトの名無しさん
2011/09/19(月) 12:16:15.09あぁ、それはSQLでも同じだよ。
0906デフォルトの名無しさん
2011/09/19(月) 12:22:49.720907デフォルトの名無しさん
2011/09/19(月) 12:27:49.06だからそれは小規模の世界の話だってｗ
0908デフォルトの名無しさん
2011/09/19(月) 12:32:58.690909デフォルトの名無しさん
2011/09/19(月) 12:37:50.93だんだんと規模が広がると設計で某伊藤のコンサルがきたりして
速度あげろとか言われ、しこしこボトルネックの切り離しを行っていく。
0910デフォルトの名無しさん
2011/09/19(月) 12:42:53.04お前が遅いって言ったデータを取ったのが
小規模なだけ。
ERPでは普通はSQLサーバーを使っている。
0911デフォルトの名無しさん
2011/09/19(月) 12:47:19.99少なくともSAPじゃねえよなあ。
0912デフォルトの名無しさん
2011/09/19(月) 12:54:28.71調べておいで。
ERP製品一覧
http://techtarget.itmedia.co.jp/tt/news/1010/04/news03.html
0913デフォルトの名無しさん
2011/09/19(月) 12:56:13.58SAP ERPは、DBMSとして Oracle,SQL Server,DB2,Infomix,SAP DBなどを使用することができます。
0914デフォルトの名無しさん
2011/09/19(月) 12:58:25.10製品名のMicrosoft SQL Serverじゃねえからｗ
0915デフォルトの名無しさん
2011/09/19(月) 13:00:17.39使ったこと無いのにカタログだけで語ってたのかよ
0916デフォルトの名無しさん
2011/09/19(月) 13:02:25.210917デフォルトの名無しさん
2011/09/19(月) 17:05:48.29Javaだから言語的にはOOPだ
実際どうやって書くものか一切知らないが
0918デフォルトの名無しさん
2011/09/19(月) 18:57:14.48だからどうしたんだよ。
最初から単純なマスターを切り離してるっていってんだから
他のデータでDBに依存すんのは当然だろ
現実に単純なマスターをDBからファイル化されてることの
反証でもなんでもない。
日本語でググレるドキュメントは無いから、
ファイルにできる証拠が欲しいなら会社にあるERPの仕様を読んでみろ。
0919デフォルトの名無しさん
2011/09/19(月) 19:53:07.480920デフォルトの名無しさん
2011/09/19(月) 20:33:43.92学生は黙ってろよ。
0921デフォルトの名無しさん
2011/09/19(月) 22:28:23.550922デフォルトの名無しさん
2011/09/20(火) 01:32:29.31規模に応じて使い分けろアホども。
0923デフォルトの名無しさん
2011/09/20(火) 03:26:04.100924デフォルトの名無しさん
2011/09/22(木) 15:56:02.05MapReduceすればいいのでわ
0925デフォルトの名無しさん
2011/09/22(木) 15:58:00.76普通はSQLServerかよ
Oracle EBSならそれはないｗ
0926デフォルトの名無しさん
2011/09/23(金) 18:57:27.010927デフォルトの名無しさん
2011/09/23(金) 20:22:36.760928デフォルトの名無しさん
2011/09/23(金) 21:32:49.03普通DBサーバとか言わね？
SQLサーバって意味わかんないんだけどw
0929デフォルトの名無しさん
2011/09/24(土) 07:35:32.050930デフォルトの名無しさん
2011/09/24(土) 11:47:27.90プログラマ同士だとたまにあるだろ？
プログラミング言語をいくつ使えるか、
みたいな競争が。そこにSQL入れてるやつってどうなのよ。
データベースにクエリを発行するためのもんをそこに入れるかね。
0931デフォルトの名無しさん
2011/09/24(土) 12:39:50.930932デフォルトの名無しさん
2011/09/24(土) 14:02:50.72開発現場でDBサーバーの事SQLサーバー何て言ってたらすげえ危険だよ
MSのSQLサーバーの事を
指してるのに、DBの一般名詞として解釈されたりして
現場が混乱しまくる。
0933デフォルトの名無しさん
2011/09/24(土) 15:32:03.60データベースを管理してるサーバがDBサーバだろ。
通信系だとそうなんだけど、業務系の業界の文化は知らない。
「現場」でひとくくりにされても困る。
0934デフォルトの名無しさん
2011/09/24(土) 15:57:01.524GLも立派な言語だと思うけど、SQLのLも言語だし。
>>933
DBサーバーのなかにSQLサーバーも含まれると思うけど。
SQLサーバーと言ったら、ハードのPC自体を指すから
>>910のSQLサーバーは本来ならRDBとかRDBMSとかを使った方が意味は伝わると思う。
ハード（サーバー機）とソフト（DBMS）の用語が曖昧に使われていると思う。
0935デフォルトの名無しさん
2011/09/24(土) 16:42:11.42postgreもMySQLもDB鯖かつSQL鯖だろ。
Berkley DBならDB鯖であってSQL鯖でないと言える。
0936デフォルトの名無しさん
2011/09/24(土) 18:04:23.52まぁ既知者の間でも分かれているようだけど。
0937デフォルトの名無しさん
2011/09/24(土) 18:15:33.92本来はWindows上で漢字変換などのシステムを動かすための仕組みであって
MS-IMEはそのひとつでしか無いんだが、MS-IMEのことをIMEと呼ぶ人間が後を絶たない
0938デフォルトの名無しさん
2011/09/24(土) 19:56:34.400939デフォルトの名無しさん
2011/09/24(土) 22:27:39.310940デフォルトの名無しさん
2011/09/24(土) 23:45:37.13何が違う？俺には似たようなもんだと思うのだが。
0941デフォルトの名無しさん
2011/09/25(日) 00:06:08.640942デフォルトの名無しさん
2011/09/25(日) 00:10:12.58まあ、でも確かに本筋からはズレてるな、すまぬ
0943デフォルトの名無しさん
2011/09/25(日) 02:13:34.530944デフォルトの名無しさん
2011/09/25(日) 02:21:27.64SQLサーバーをSQLを使ったDBとして書いてるところなんて無いね。
一般名詞 = 個人的範囲外で通じる言葉
なので別にSQLサーバーは一般名詞じゃないな。
だいたいOracle DBの事を一般名詞のつもりでSQL Serverと呼んで
他の人が製品のSQL Serverの設定準備をしてしまうとかトラブルになるだろ。
0945デフォルトの名無しさん
2011/09/25(日) 02:22:48.69一般人は呼んでも、技術者は区別するし。
0946デフォルトの名無しさん
2011/09/25(日) 02:24:56.04SQLを解釈するのはDBであってサーバーの役割じゃないし
SQLとサーバーをひもづける理由なんて殊更ないし
0947デフォルトの名無しさん
2011/09/25(日) 02:31:35.96RDBの事をSQLサーバと呼んでいたわけだから、
IMEの事をMS-IMEと呼んでいた、が正解。
MS-IMEの事をIMEと呼んでいた、は例として可笑しい。
逆だ逆。
0948デフォルトの名無しさん
2011/09/25(日) 09:40:40.50話してるとなんとなく話は通じてるみたいだけど、
微妙なところで認識ずれがありそうで怖い。
0949デフォルトの名無しさん
2011/09/25(日) 12:35:41.64RDBのことSQLサーバじゃなくて、MS-SQLServerのことをSQLサーバじゃなかったのか
0950デフォルトの名無しさん
2011/09/25(日) 14:55:58.500951デフォルトの名無しさん
2011/09/25(日) 15:36:47.080952デフォルトの名無しさん
2011/09/25(日) 15:41:48.39ソフトウェアとしてのものと、
ハードウェアとしてのもののどちらかを指してる。
0953デフォルトの名無しさん
2011/09/25(日) 15:42:52.53soket ならサーバ・クライアントは絶対的意味において固定なのですが？
0954デフォルトの名無しさん
2011/09/25(日) 16:13:52.60SKKを殊更サーバーと呼ぶこともないし意味が解からん
>>952
S/Cは別に相対関係を表してるだけだから、
ハードだろうがソフトだろうが混在しても
問題になる事はないでしょ。
Webサーバーとhttpdをごっちゃにしたって
機能が全然違うからSQL Serverみたいに間違えることはまずない。
0955デフォルトの名無しさん
2011/09/25(日) 20:01:51.55普通はDBMSかRDBに限ればRDBMSだろ
普通DBMSって言ったらRDBMSのことで
KVSっていったらNoSQLデータベースのことだろ
あとはISAMデータベースだけど、DBMSの範疇ではないな。MySQLが特殊なだけで。
0956デフォルトの名無しさん
2011/09/25(日) 20:11:37.44>SQLを解釈するサーバがSQLサーバで、
それはSQLパーサーまたはSQL Nodeだろう
それに対になる言葉ならストレージエンジンだろう。
0957デフォルトの名無しさん
2011/09/25(日) 20:15:43.92SQL(RDB)でもスタンドアローンで使っているシステムもあるので
サーバーだと限定は出来ないと思いますよ。
0958デフォルトの名無しさん
2011/09/25(日) 20:17:34.79スキーマやら、DBそのものの管理やらSQL以外の機能は沢山ある。
0959デフォルトの名無しさん
2011/09/25(日) 20:58:29.30俺は寡聞にして知らないけど。
普通なら「SQLサーバーが一般用語www」で終わるところ、ここまで長引いてんのもそこが追求できないからでしょ。
業界通()笑さんはおらんのかね。
0960デフォルトの名無しさん
2011/09/25(日) 21:09:37.25それを相手してるから無駄にレスが伸びてるだけだろ
0961デフォルトの名無しさん
2011/09/26(月) 00:17:26.790962デフォルトの名無しさん
2011/09/27(火) 22:38:41.89固有名詞だと主張してる時点でおかしいんだよ。
そんな奴に技術者としてのプライドがあるか怪しい。
0963デフォルトの名無しさん
2011/09/27(火) 22:46:17.87もはや一般語でも無いだろ。それは置いといてもSQL Serverって
名前自体が意味合い的におかしいけどな。
0964デフォルトの名無しさん
2011/09/28(水) 18:24:47.15でも、postgreSQLとかもあるし。
0965デフォルトの名無しさん
2011/09/28(水) 19:18:15.39間違えてるよ
0966デフォルトの名無しさん
2011/09/29(木) 17:41:06.250967デフォルトの名無しさん
2011/09/29(木) 23:48:19.150968デフォルトの名無しさん
2011/10/01(土) 21:17:31.93それなりの規模のプロジェクトで、オブジェクト指向じゃない
プロジェクトの方が珍しくない？
たとえば、10万ステップ以上程度のOSSで、
(オブジェクト指向言語ではない)Cで書かれていて、
OOPじゃない物って何かある？
調べてないけど、ほぼすべてOOPの体裁を取ってるんじゃないかと
思うんだけど、どうですかね？
0969デフォルトの名無しさん
2011/10/01(土) 22:13:17.55ただのリエントラントなモジュールをOOPに含めるかどうかによる
0970デフォルトの名無しさん
2011/10/01(土) 22:22:18.700971デフォルトの名無しさん
2011/10/01(土) 22:44:12.30linux kermel
0972デフォルトの名無しさん
2011/10/01(土) 23:00:15.170973デフォルトの名無しさん
2011/10/01(土) 23:05:42.26当たり前だが、OOPが広まる前の巨大システムは総てOOP以外。
今も生き残ってる物は多い、L… とか…言語系もそう。
巨大アセンブラプログラムのシステムも見た。
0974デフォルトの名無しさん
2011/10/01(土) 23:46:13.90その上で動くアプリをオブジェクト指向じゃない書き方で作れば
それは当然オブジェクト指向ではない。
それではだ、フレームワークやライブラリがオブジェクト指向で作られているものを
単に使うだけで、オブジェクト指向とかなんも考えずに作られた
ソフトウェアはオブジェクト指向になるのだろうか。
0975デフォルトの名無しさん
2011/10/02(日) 00:04:09.94ソフトウェアがオブジェクト指向であるかないかの必要要件が有るのだろうか?
最低要件としては、データと処理が合体して、1つのオブジェクトとして振る舞い、
他のオブジェクトとコミュニケーションしてシステムを制御すればいいような気がする。
そう考えた場合、フレームワークがその仕組みを強制すれば、オブジェクト指向の
プログラムになるのではないかと。どの様に作ったかは関係がないのでは?
できあがったソフトウエアの設計資料まで遡らなくてはいけないのだろうか?
0976968
2011/10/02(日) 00:14:27.93Linux kernelがOOPじゃないなんて、信じられない。。
マジですか。ちゃんと読んでみます。
ものすごく古いのならともかく、まだOOPが言われるようになる前の時代の物でも
原始的なOOPの考え方はそれなりの規模のプロジェクトなら自然発生しているのでは？
と、思ったわけなんだけど、そうでもないのですね。
0977デフォルトの名無しさん
2011/10/02(日) 00:18:10.93くだない(Trivial)と
というか、いろんな考え方のごった煮で、時代とともに適当に後付けで都合のいい理論を吸収してきたことが、C++ の発展の仕方をみてもよくわかる。
0979デフォルトの名無しさん
2011/10/02(日) 00:36:03.49>Linux kernelがOOPじゃないなんて、信じられない。。
逆に聞きたいんですがkernelにどのようにOOを適用します？ その場合の利点は？
そもそも、なぜオブジェクトを作成してオブジェクトが
プログラムを制御する仕組みがいいのか分かりますか？
そのあたりが分かると、OOが適しているプログラムかどうかが分かると思いますよ。
0980デフォルトの名無しさん
2011/10/02(日) 00:37:23.120981968
2011/10/02(日) 01:00:10.28> 逆に聞きたいんですがkernelにどのようにOOを適用します？ その場合の利点は？
例えばファイルハンドルなんかはカプセル化やポリモーフィズムを外部に提供している(と俺は思う）から、
十分OOPだと思ってるのです。またLinuxの実装においてもデバイスドライバを登録する時に使う
register_chrdev() 関数なんかにおいても、引数として渡す file_operations 構造体はメソッドへのポインタの
集合だし、十分OOPにおけるクラス的ふるまいだと思うのです。
というわけでOOPLでないCを使いながら外部に対してはオブジェクト指向なインターフェースを供給している
Linux kernel において、それ自身はOOPじゃないって話しだから「マジですか？」になりました。
と言うわけで
> 逆に聞きたいんですがkernelにどのようにOOを適用します？ その場合の利点は？
に対しては、ファイルハンドルやデバイスドライバとか、色々あるじゃん？ と思ってます。
あー、叩かれるのだろうか。。
0982デフォルトの名無しさん
2011/10/02(日) 01:06:09.61そこにカプセル化と差分プログラミングを詰め込んで、
クラスでなんでもやろうとしたのが悲劇の始まり。
クラスが全てみたいになって、勘違いする奴が続出。
元に戻そうとするムーブメントが有って、
その第一歩がマルチメソッド。
実行性能無視してでもこれを実装しようとする人たちが居たりする。
一石投じるってやつ。
0983デフォルトの名無しさん
2011/10/02(日) 01:06:49.35⊂（ ・∀・） ､,Jし // ﾊﾟﾝ
（几と ノ ） て.
／/'|ヽソ 彡 Y⌒Y ｀Д´） <968
／ノ / ｜ ＼ 彡
ヽ/､/ヽ/ ヽ/
0984デフォルトの名無しさん
2011/10/02(日) 01:24:38.78ファイルなんかはread,write,ioctlぐらいしか操作はない。
しかも、read,write,ioctlは非常に単純な情報しか知らない。
言ってしまえばvoid*。void*は値を渡す側と受け取る側は、同じデータを
指すことを期待してる。要するにプログラマ任せ。
プログラマじゃなくオブジェクトの判断に任せられるOOとは矛盾する。
0985デフォルトの名無しさん
2011/10/02(日) 01:31:16.90読解力無さ杉。
0986デフォルトの名無しさん
2011/10/02(日) 01:54:10.360987デフォルトの名無しさん
2011/10/02(日) 02:09:35.64カーネルはCでしか書かないんだって偉い人が言ってた。
0988デフォルトの名無しさん
2011/10/02(日) 02:29:12.462.C++はコンパイラ間の移植性が低い(アーキテクチャごとの移植性は高い)
3.タイミングがシビアなので機械語命令からかけ離れた抽象的な機能を持つ言語は使えない
最適化で命令を飛ばされると致命的な結果を生むことがある
0989デフォルトの名無しさん
2011/10/02(日) 04:05:22.740990デフォルトの名無しさん
2011/10/02(日) 13:49:50.551.http://slashdot.jp/journal/509450/Linus%E6%B0%8F%E3%81%AEC%2B%2B%E3%81%AB%E5%AF%BE
%E3%81%99%E3%82%8B%E6%9C%80%E8%BF%91%E3%81%AE%E5%90%A6%E5%AE%9A%E7%9A%84%E8
%A6%8B%E8%A7%A3
2.https://developer.mozilla.org/ja/Mozilla_Coding_Style_Guide
3. 1と同じ
0991デフォルトの名無しさん
2011/10/02(日) 17:18:41.69外部にAPI/インタフェースを公開していることと、コードがOOで書かれていることは混同しちゃならんよ。
UNIX系のインタフェースを考察するなら、むしろテキストストリームのことを考えた方がいい。
http://d.hatena.ne.jp/asakichy/20100514/1273790514
LinuxがC言語でゴリゴリ書かれているのは、一番パフォーマンスに影響する部分なのだから、
抽象化すらそぎ落としたいと考えるのは当然ちゃ当然。Linusほどのハッカーが開発をしていて、
コードベースが安定しているソフトウェア（というより安定していないと困る）なら、非OOも合理的な選択だ。
あと、LinusはC++を嫌っているのであって、OO言語全般を嫌っているわけじゃないよ。
LKLMで、Linusがその辺の議論をしている過去ログを見たことがあるので、興味があれば探してみるといい。
0992デフォルトの名無しさん
2011/10/02(日) 18:19:35.02>>990 のソースでOOをDisってるよ
0993デフォルトの名無しさん
2011/10/02(日) 18:22:22.80オブジェクトを中心に考えるのは腐ってるってね。
まぁ、言うとおりだわ。ただ元祖OOを批判してるわけじゃなく
最近のクラスありきのOOを批判してんだろうけど。
0994デフォルトの名無しさん
2011/10/02(日) 18:30:02.33ctor,dtor当たり前、とかいうレベルじゃなくて、
スケジューラとかオブジェクト指向っぽいと思うんだけどな。
構造体と関数ポインタを使ったC言語OOPは普通にやられてると思うんだけど。
Linux KernelがC++を使ってないから非OOPとするのであれば、それには異論を唱えたい。
0995デフォルトの名無しさん
2011/10/02(日) 18:40:34.06単に処理とコンテキストが一緒になった何か。
コールバックのために仕方なくそうしているだけであって、
積極的な姿勢ではないんだろう。
0996デフォルトの名無しさん
2011/10/02(日) 18:49:41.07部分的に非OOP言語によるOOP技法が適用されているからといって、
システム全体がOOP/OODであるとされるのは違和感があるなぁ....
0997デフォルトの名無しさん
2011/10/02(日) 18:55:56.01> いいかい、私がそう思うのは、私が低レベルプログラミングだけをしているからかも知れない。
> 先に言った通り、私が仕事しているコードの大部分が、殆のソフトウェアプロジェクトが考え
> すらしていない事柄に非常に注意を払っている。
って本人も言ってるしね。Linuxカーネル開発者の態度としては完全に正しい。
んで、カーネルがOOで書かれていないからといって、OOの存在意義が否定されるわけではない。
OOは「責務」を抽象化して開発単位を分割できるようにするための道具なわけであり、
「慈悲深い独裁者」が開発を独裁的にコントロールできるのでは「ない」場面で有効な方法論。
Linusが、マイクロカーネルに反発してモノリシックカーネルのLinuxを始めたことを考えても、
彼がOOに否定的なのは驚くに値しない。
>>994
少なくとも、Linus本人はそう思ってないだろうな。
0998デフォルトの名無しさん
2011/10/02(日) 18:59:18.89タスクのオブジェクトがスケジューラー以外で使われてる訳じゃないでしょ。
あくまでもタスク制御の為の構造なだけ。
OOみたいに古い型のオブジェクトに、新しく作った型のオブジェクトを注入するとかはしてない。
新しい型を利用する古い型も、古い型に注入する新しい型もお互いの都合をあまり知らない。
それは、オーバーフローや最適化の抑止にまで拘ってるカーネル開発じゃ危険すぎるんだよ。
古い型と重複する部分が多くても、新しい型を熟知している、新しい型を作ったほうがましって事らしい。
0999デフォルトの名無しさん
2011/10/02(日) 19:00:09.30開発言語のほとんどはC言語だろう？
C言語でオブジェクト指向なんて
不可能だし。
1000デフォルトの名無しさん
2011/10/02(日) 19:04:21.781001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。