【OOP】オブジェクト指向総合 part3【OOA/OOD】

1 ：デフォルトの名無しさん：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/

2 ：デフォルトの名無しさん：2011/08/10(水) 22:55:08.10

>>1
ポニーテールうんたらかんたら

3 ：デフォルトの名無しさん：2011/08/10(水) 23:00:02.67

self->乙( >>1 )

4 ：デフォルトの名無しさん：2011/08/11(木) 22:29:49.49

こんなに早く立てたらdat落ちすんじゃないのか？

5 ：デフォルトの名無しさん：2011/08/12(金) 23:45:42.76

分かり易かったので引用しとく

getter否定派(実質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の中で
> 今の自分の状態で最も適切に受け取れるものを選んで受け取ることができる

6 ：デフォルトの名無しさん：2011/08/12(金) 23:56:43.87

getter屋さんはこれをどう書くの？
getterじゃ無理だとは言わないから、
どういうふうに書くのか見せてよ。

Numeric method(Source source)
{
        Numeric dest = new PackdNumeric( 255 ); // 255に数値を丸めるオブジェクト
        source.toValue( dest );
        return dest;
}

7 ：デフォルトの名無しさん：2011/08/12(金) 23:56:43.92

前スレ>>986

> 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())

8 ：デフォルトの名無しさん：2011/08/13(土) 00:00:29.76

>>6
馬鹿だなぁ。getterじゃ難しい例（>>6がそれかどうかは興味無いけど）をいくら挙げても
getterを禁止する理由にはならないんだぜ？
そんな基本的な事すら分かってないアホだから突っ込まれてんだよ

9 ：デフォルトの名無しさん：2011/08/13(土) 00:11:53.01

>>6
例がクソコード過ぎて、そっちのツッコミしかできんｗ

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が何をする関数なのか全く理解できん。

10 ：9：2011/08/13(土) 00:14:36.53

とりあえずだ。

methodとかsourceとかPackedNumericとかtoValueとか

それらの仕事（何をする関数・クラスなのか）を
明確にしてくれ。でないとこんな答えしかできん。

11 ：デフォルトの名無しさん：2011/08/13(土) 00:16:33.68

てか、なんで特定のイベントに対する取得イベントなのにも関わらず
getとかどんなタイミングでも取得していいようなイベント名にするのか理解できない
現実は特定の瞬間しかダメなんしょ？
ダメなのになんでget作っちゃうの？
いい加減な仕事すんなよ

って程度
できるできないの話だったらできるよやりゃいいんじゃん
ただ、それはかなり仕事いい加減だよね？って話

12 ：デフォルトの名無しさん：2011/08/13(土) 00:17:22.87

>>9
インターフェースぐらい守れよ。
Numeric method( Source )
お前のクソコードじゃこれすら守れないんだろ。

13 ：デフォルトの名無しさん：2011/08/13(土) 00:18:52.61

クラス図書いてＭとＶとＣの関連ちゃんと出してみろって
ぜってーgetなんてイベントできねーからｗ

14 ：デフォルトの名無しさん：2011/08/13(土) 00:19:29.69

>>12
だから、その前に、
そのコードの意味がわからん。

インターフェースが間違っていると
俺は言ってるだけだ。

クソコード出して、クソコードだけに通用する
話をされても意味はない。

15 ：デフォルトの名無しさん：2011/08/13(土) 00:20:35.64

>>11
おいｗ

getterはgetという名前じゃないぞ。

getWidthとかgetHeightとか
具体的な名前だ。

16 ：デフォルトの名無しさん：2011/08/13(土) 00:21:40.44

構造体の代わりがほしいだけなのにgetがイベントだなんていっちゃうもんだからこのザマだな
お前等がほしいのは構造体であってクラスのメソッドじゃないだろ

17 ：デフォルトの名無しさん：2011/08/13(土) 00:22:32.16

length()とsetLength()を持つせいで構造体扱いされてる
StringBufferさん可哀想www

18 ：デフォルトの名無しさん：2011/08/13(土) 00:23:27.03

>>6
> getter屋さんはこれをどう書くの？

クソコードのままのそのコードに対して
コメントをするとだな。

そのコードの範囲内に、値を取得（参照）するコードは
一つもないので、getterがでてこないのは当たり前だ。

19 ：デフォルトの名無しさん：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 ); //最終結果をメンバーへ
}

20 ：デフォルトの名無しさん：2011/08/13(土) 00:24:14.59

>>16
君の所の構造体は mutate した変数を自動的に undo manager に登録してくれるの?

21 ：デフォルトの名無しさん：2011/08/13(土) 00:25:44.66

>>18
正論だなｗ

値を取得するコードがないのに
これをgetterを使って書けという方がどうかしてるｗ

22 ：デフォルトの名無しさん：2011/08/13(土) 00:26:39.10

>>19
糞コードじゃん
出力結果をさらに入力に使うような変換にはまったく使えないのに
こんなとこ拡張してもなんの意味もない画像処理のがの字も見えてない真性の糞コード

23 ：デフォルトの名無しさん：2011/08/13(土) 00:28:41.41

仕様を把握してない奴が考える自称汎用コードほど無駄＆オナニー臭がすごいものは他にないな

24 ：デフォルトの名無しさん：2011/08/13(土) 00:31:01.64

前スレであれだけ議論したＭＶＣは結局なんの意味もなかったってこといいの？

25 ：デフォルトの名無しさん：2011/08/13(土) 00:32:40.82

>>9
前スレにでてた、Sourceは、数値か文字列か不定だったろ。
Sourceの状態に従って文字や数値をNumericに取り込ませる処理は何処いったんだよ。

26 ：デフォルトの名無しさん：2011/08/13(土) 00:33:28.70

>>24
MVCはMVCの話だろ。

27 ：デフォルトの名無しさん：2011/08/13(土) 00:33:38.39

obj.getFoo() って select foo from model where object = obj; してる感覚なんだけどな

getter 否定派の人が主張する様な、データストアからデータを取ってくるのにイチイチ
callback を定義しないといけないというのは、あまり直感的じゃないと思うわ

28 ：デフォルトの名無しさん：2011/08/13(土) 00:34:38.68

>>22
は？
fillter.To( device );

29 ：デフォルトの名無しさん：2011/08/13(土) 00:36:25.43

>>25
> 前スレにでてた、Sourceは、数値か文字列か不定だったろ。

前スレにsourceなんて出てきていません。

30 ：デフォルトの名無しさん：2011/08/13(土) 00:37:16.13

>>25
どのスレの話してんの？

31 ：デフォルトの名無しさん：2011/08/13(土) 00:37:17.87

はじめにもどろう
この問題はgetterやsetterをおざなりに用意しちまうことがダメだって話だろ
それとそのコードはなんか関係あるのか？（まったく関係ない気がすんぜ）

オブジェクト間のアクセスを限定することにカプセル化の意味があるってのに
全く無視してgetterやsetter用意しちゃうのはなんかちがくない？って話よ

また、はじめの手順に戻って落ち着いて設計したときにgetterやsetterなんてメソッドできんの？
ってことよな

32 ：デフォルトの名無しさん：2011/08/13(土) 00:39:44.09

>>31
>オブジェクト間のアクセスを限定することにカプセル化の意味があるってのに
>全く無視してgetterやsetter用意しちゃうのはなんかちがくない？って話よ

これと

>また、はじめの手順に戻って落ち着いて設計したときにgetterやsetterなんてメソッドできんの？
>ってことよな

これは大分次元の違う話だと思うから、どっちかにした方が良いと思われ

33 ：デフォルトの名無しさん：2011/08/13(土) 00:39:59.76

>>31
違う。特定の処理をgetter/setterを使わないで
できると言っているだけで、

じゃあその他の処理は？　特定の処理ができたからって
getter/setterがいらないという理由にはならないよね。

って言ってるのに、それを無視してgetter否定し続けている

ってのがここまでの流れ。

34 ：デフォルトの名無しさん：2011/08/13(土) 00:40:58.70

>>33
いや、設計ででた以外のことしちゃだめだろ？
その他って何？

35 ：デフォルトの名無しさん：2011/08/13(土) 00:43:22.18

>>31
あのコードはオブジェクトを使う側は、オブジェクト同士でどう通信してるか隠蔽される。
getter/setterは、隠蔽されてる操作をオブジェクトが使う側が書く。
オブジェクトの判断で値を渡せなくなる。

36 ：デフォルトの名無しさん：2011/08/13(土) 00:45:07.74

>>34
たとえばウインドウをリサイズするときにその中のオブジェクトの
リサイズをgetter/setterなくてもできるという主張をしている。

これは正しいとしてもだ。それはリサイズ時にgetter/setterが
必要ないということにすぎない。

その他の処理、たとえばボタンを押したときに
ウインドウのサイズの半分の大きさに小ウインドウのサイズを広げる
などという処理にはgetter/setterは必要。

このように、特定の処理で不要だからとって、
それをもって、すべての処理で不要と言っている
その理屈がおかしいという話。

37 ：デフォルトの名無しさん：2011/08/13(土) 00:45:55.70

>>33
いる理由が、バカでも解る以外ない。

38 ：デフォルトの名無しさん：2011/08/13(土) 00:46:48.88

void toValue(Numeric), void toValue(int) ... ってcoercion作るのと
Numeric getNumeric(), int getInt() ... ってgetter作るのの違いだな

型システムがnominalな言語なら前者もありだが、動的型やsubstructuralな言語なら後者だろ
俺は安易なcoercion嫌いだけど

39 ：デフォルトの名無しさん：2011/08/13(土) 00:49:57.23

>>36
したらそれ個々のメンバにgetter/setterいれちゃうんじゃなくて
ウィンドウをリサイズするときに必要な情報の取得
（注：取得は取得だが個々の値ではない。あくまでウィンドウをリサイズするという目的の関連の実装である）って関数（イベント）作って
取得できるようにしないといけないんじゃない？

って話だよ
取得は取得
だけどそれはあくまで「ウィンドウをリサイズするために」という目的をもった値の受け渡しでないといけない
って考え方な

40 ：デフォルトの名無しさん：2011/08/13(土) 00:50:56.50

>>37
墓穴ほったなｗ

いる理由はあるが、それをお前は馬鹿と言っているだけだろ。
本当に馬鹿なのはお前だ。

少なくともいる理由があることをお前は認めた。

41 ：38：2011/08/13(土) 00:51:10.61

>>6をgetterで書くとこうか？

Numeric method(Source source)
{
return new PackdNumeric(source.getNumeric(), 255);
}

42 ：デフォルトの名無しさん：2011/08/13(土) 00:52:43.48

>>38
違う。intへの変換が必ず起きることは保証されない。
元がStringで受け取り手がStringならStringのまま。
元がintで受け取り手がintならintのまま。

43 ：デフォルトの名無しさん：2011/08/13(土) 00:57:17.49

>>40
じゃ書いてみろ。toValueで代用できない方法でな。

44 ：デフォルトの名無しさん：2011/08/13(土) 00:58:58.44

>>39
>だけどそれはあくまで「ウィンドウをリサイズするために」という目的をもった値の受け渡しでないといけないって考え方な

それは事前に全て設計が済んでないと無理でしょ

45 ：デフォルトの名無しさん：2011/08/13(土) 00:59:08.96

あるGUIコンポーネントがあってそれは
自立して動いている。

たとえばコンボボックスだと
それ単体で選択したものを変更できる。

そういう場合何かが変更したら、何から何に変更したという
情報を他のオブジェクトに通知すればgetterは不要になる。

理屈ではそのとおりだが、これだとGUIコンポーネントが
持っている情報を変更したら、それごとに○○changeという
イベントが大量に必要になる。

これは現実的ではないので、GUIコンポーネントに何かの
変更が加わったら、change()というイベントを送る
changeの引数には、イベントを発生したオブジェクトsenderが存在する。

void change(Window sender) {
　　ここでsender.getXX()を呼び出してなにが変更したかを調べる。
}

46 ：デフォルトの名無しさん：2011/08/13(土) 01:00:38.60

>>43
> じゃ書いてみろ。toValueで代用できない方法でな。

toValueってsetterじゃんｗ

47 ：デフォルトの名無しさん：2011/08/13(土) 01:01:50.47

>>44
後から必要だって言われたら用意してやればいいじゃん
もちろんクラス図書いてなんのイベントなのかちゃんと決まってからね
こういうヌケ穴をボコボコ用意しちゃうと穴作ったぶんだけバグ増えるからね

48 ：デフォルトの名無しさん：2011/08/13(土) 01:02:01.53

>>41
コギたねぇけど、こういう形か
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;
    }
}

49 ：デフォルトの名無しさん：2011/08/13(土) 01:03:38.75

toValue(setter)をgetterで書けという理屈がよくわからんｗ

50 ：デフォルトの名無しさん：2011/08/13(土) 01:04:42.78

>>47
getter が用意されていれば、model を使う側だけ変えれば良いけど、
listener 方式だと model の側も変えないといけない

試行錯誤しながらプロトタイプを作る場合には不向きだね

51 ：デフォルトの名無しさん：2011/08/13(土) 01:04:52.08

そりゃgetterなんて必要ないもんな。

52 ：デフォルトの名無しさん：2011/08/13(土) 01:05:16.38

>>39
ウィンドウのサイズを半分にしたいとき、
ウィンドウにサイズ変更イベントを投げて、
サイズ変更通知用コールバック呼んでもらって、
そのコールバックの中でウィンドウサイズを半分にする、
ってことだと思うけど、そういう実装にしちゃうと、
今度は、ウィンドウを半分のサイズにするって処理が分断されちゃう。
ウィンドウサイズ変更のコールバックが呼ばれたとき、
それが何の引き金で呼ばれたのか分からない。
ウィンドウサイズ半分ボタンが押されたからなのか、
マウスでウィンドウサイズを変えたからなのか、
はたまた他のスレッドで何かウィンドウサイズを変更するような処理が走ったのか、
分からないから、
ウィンドウサイズ半分ボタンが押される→コールバックでウィンドウサイズ半分って流れが確定しない。
結局、getter/setterとの違いは、
変更元の処理が分断するか、変更先の処理が分断するかの差でしかない。

53 ：デフォルトの名無しさん：2011/08/13(土) 01:07:03.13

>>50
いや、getterでもModelのインターフェースも変えなきゃならんし、Viewの内部も変えなきゃならん。

54 ：デフォルトの名無しさん：2011/08/13(土) 01:07:22.73

>>50
>試行錯誤しながらプロトタイプを作る場合には不向きだね
まあ、前スレでも書いたけどその辺は俺らとマイクロソフトの開発者（ライブラリ開発者という意味で）との違いだね
あくまで俺らは使う側、向こうはライブラリ開発だから当然
こういうのやりたきゃＭＳかＧｏｏｇｌｅにでも入るしかないんじゃない？割とガチで

55 ：デフォルトの名無しさん：2011/08/13(土) 01:07:45.00

>>48
getStringとgetInt()がありでgetNumeric()は禁止ってどういう縛りだよ

56 ：デフォルトの名無しさん：2011/08/13(土) 01:08:56.46

>>48
toValue(Numeric)が許されてgetNumeric()がダメな理由は？

57 ：デフォルトの名無しさん：2011/08/13(土) 01:09:46.12

ベンダーが用意したイベントリスナーに登録する方式だと、用意されている
イベントモデルやネーミングコンベンションを理解しないといけない

それは getter / setter を理解するより遥かに面倒

58 ：デフォルトの名無しさん：2011/08/13(土) 01:09:46.70

>>52
まあ、クラス図とその関連書いてイベント名決めろよｗ
理想の実装に必要なイベントあればいいからよ
そこにずらずら書いてある内容この問題じゃねーべ

59 ：デフォルトの名無しさん：2011/08/13(土) 01:11:04.24

>>53
getter を追加するのは一瞬
イベントを定義してコールバックを登録するより遥かにラクチン

60 ：デフォルトの名無しさん：2011/08/13(土) 01:12:24.74

イベントはイベントであっていいんだよ。

ただ、そのイベント内で、イベントを送ってきた相手の
情報を取得するために、getterがあれば使いやすい。

サイズが変更したときに送ってくるのはサイズ情報だけ。
サイズ変更と同時にその他の情報を知りたい時は
getter使って取得した方が簡潔に書ける。

61 ：デフォルトの名無しさん：2011/08/13(土) 01:12:29.45

>>59
サボってねーでちゃんと関連は一箇所に搾れよ
ＭＳのLockUnlock方式でもいいからよｗ（これも一応行儀はいいほうだと思う）

62 ：デフォルトの名無しさん：2011/08/13(土) 01:12:40.28

>>48
だれもそんな糞コード書いてねーだろばーか

63 ：デフォルトの名無しさん：2011/08/13(土) 01:14:00.79

>>61
効率重視なだけだよ

64 ：デフォルトの名無しさん：2011/08/13(土) 01:16:35.08

書くぞ。
class hoge : public hoge_interface
{
window w;
virtual void on_halfsize( SIZE *s ){};
void halfsize_window()
{
};

65 ：デフォルトの名無しさん：2011/08/13(土) 01:16:40.94

>>63
じゃーそーゆーことなのかもな
あんまりオブジェクト指向意識して開発もしてねーだろ
（ってそれが悪いとは俺はおもっちゃいないけどね）

66 ：デフォルトの名無しさん：2011/08/13(土) 01:17:40.44

>>55
>>56
>違う。intへの変換が必ず起きることは保証されない。
>元がStringで受け取り手がStringならStringのまま。
>元がintで受け取り手がintならintのまま。

67 ：デフォルトの名無しさん：2011/08/13(土) 01:19:05.68

>>66
それ、全然答えになってないけど？
getNumeric()ってインターフェース持てない理由を教えてよ

68 ：デフォルトの名無しさん：2011/08/13(土) 01:19:51.58

>>65
オブジェクト指向的に書いた方が良い所と、そうじゃない所ってあるじゃん
要は使い分け

69 ：デフォルトの名無しさん：2011/08/13(土) 01:19:59.00

>>6より>>41の方が圧倒的にシンプルな件
toValueさん涙目www

70 ：デフォルトの名無しさん：2011/08/13(土) 01:20:56.76

>>67
getNumeric()から帰ってくるNumericは実際何で値を持ってるんだ？

71 ：デフォルトの名無しさん：2011/08/13(土) 01:21:34.01

>>69
あんたが見る先は>>48だけど。

72 ：デフォルトの名無しさん：2011/08/13(土) 01:22:16.52

オブジェクト指向はやはり使えないな

73 ：デフォルトの名無しさん：2011/08/13(土) 01:23:43.01

>>69
現実から目を背けるなよ。

74 ：64 ：2011/08/13(土) 01:23:57.63

途中で送信してしまった・・・
class 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が危なくなる。

75 ：デフォルトの名無しさん：2011/08/13(土) 01:24:19.90

>>70
//sourceが内部で文字列として持っている場合
Numeric getNumeric()
{
return new Numeric("10");
}

//sourceが内部で整数として持っている場合
void getNumeric()
{
return new Numeric(10);
}

76 ：デフォルトの名無しさん：2011/08/13(土) 01:26:03.04

getter 派：「こっちでよろしくやっておくから getter よこせよ」
listener 派：「いやいや、こっちでよろしくやっておくから callback よこせよ」
getter 派：「getter の方がシンプルで良いだろ」
listener 派：「listener の方が内部構造を知らなくていいから良いだろ」
getter 派：「内部の複雑な所に踏み込むつもりはないから getter よこせ！」
listener 派：「何でも楽しようと思うなよ！！」

77 ：デフォルトの名無しさん：2011/08/13(土) 01:26:05.04

一生懸命コード貼ってる奴等は内容自体はだいたいわかるからもうええんやでｗ

78 ：デフォルトの名無しさん：2011/08/13(土) 01:26:38.61

結局、名前に文句つけてるだけだってことがはっきりしたなｗ
本質的にはgetterだったんだよ。

getterってのは、何かを取得する関数全般のこと。
戻り値を返す関数すべてがgetterになりうる。

79 ：デフォルトの名無しさん：2011/08/13(土) 01:28:19.63

>>70
Numericの中身が気になるとか、お前本当はオブジェクト指向分かってねーんじゃね？

80 ：デフォルトの名無しさん：2011/08/13(土) 01:29:31.04

>>75
それじゃあ>>66は守れないわな。Numericが一旦否応なしにStringか、intに変えるわけだから。
そうでなけりゃ、Numericの中で2つの型をもって、受け取り側で、intとStringのどっちか取り出してもらうか。
あれ？構造体渡してんのとかわんね？しかも後者だと2つのコピーが発生してんじゃん。

81 ：デフォルトの名無しさん：2011/08/13(土) 01:30:19.54

>>80
>>79

82 ：デフォルトの名無しさん：2011/08/13(土) 01:30:52.95

オブジェクトの状態を知りたければ
getTypeとか作ればいいよ。

83 ：デフォルトの名無しさん：2011/08/13(土) 01:32:17.32

>>82
そして>>48のカプセル化が破綻したコードに戻る

84 ：デフォルトの名無しさん：2011/08/13(土) 01:34:21.64

>>80
コールバックで num.convertFrom(String) とか num.convertFrom(int) で受け取るのと
new Numeric(String) や new Numeric(int) とで何が違うん？まじで

85 ：デフォルトの名無しさん：2011/08/13(土) 01:34:24.08

>>81
1回間接的に不必要な変換される事はOO以前に無駄以外の何者でもないんだけど。
まだ数値や文字列程度なら大した問題にはならないが、画像とかだとコストがバカにならない。

86 ：デフォルトの名無しさん：2011/08/13(土) 01:35:13.56

>>84
>>66

87 ：デフォルトの名無しさん：2011/08/13(土) 01:35:35.98

>>85
>>84

88 ：デフォルトの名無しさん：2011/08/13(土) 01:38:16.84

>>87
>>86

89 ：デフォルトの名無しさん：2011/08/13(土) 01:38:35.24

>>84
>>87

90 ：デフォルトの名無しさん：2011/08/13(土) 01:38:57.47

>>88
>>86

91 ：デフォルトの名無しさん：2011/08/13(土) 01:39:21.43

>>87
>>90

92 ：デフォルトの名無しさん：2011/08/13(土) 01:39:44.07

>>87
>>85

93 ：デフォルトの名無しさん：2011/08/13(土) 01:40:11.04

>>85
>>89

94 ：デフォルトの名無しさん：2011/08/13(土) 01:40:56.40

>>1-99
>>100

95 ：デフォルトの名無しさん：2011/08/13(土) 01:48:31.14

つまり、コールバックだらけで制御構造がスパゲッティーになった様を表現したいのですね。

96 ：デフォルトの名無しさん：2011/08/13(土) 01:48:32.47

>>84

24bit-24bit
16bit-24bit
24bit-16bit
16bit-16bit

各bit数が画像の色深度を表しているものとして、
このbit間の変換が可能なときNumeric固定方式で
何回複製と変換が必要になるでしょうね。

97 ：デフォルトの名無しさん：2011/08/13(土) 01:58:27.55

NumericをImageに置き換えたとして、

Image 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 コピー

98 ：デフォルトの名無しさん：2011/08/13(土) 02:12:42.93

まぁ画像とかはまだ単純だよな。

レジストリ
iniファイル
XML
JSON

で相互変換し、互換性がある限り属性を残し、
互換性がない部分は切り捨てと補完って仕様に
なってたら劣化しまくる。

99 ：デフォルトの名無しさん：2011/08/13(土) 03:05:07.60

>>96-97
俺だったら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が必要になる。

100 ：デフォルトの名無しさん：2011/08/13(土) 03:12:44.02

new Numeric(String) 、new Numeric(int) みたいなのだと、
未知の形式に対応できないからね。つまりnew Numeric(ABCD)
なんてのは用意されてますか？って話。

conv(Image img) とかいう変換メソッドを作っておいて
Image24も Image16も ImageJPGも、Imageを継承していれば、
元がどんな形式であってもconvに渡せる。

ImageはgetBinaryImageメソッドを持っていて
内部のバイナリイメージにアクセスできる。

あとはconvメソッドは、変換元と変換先形式に対応した変換ロジックを
Factoryを呼び出して取得しそのロジックにImageを渡せばいい。
そのロジックは渡されたImageのバイナリイメージを
getBinaryImageを呼び出して取得し変換する。

101 ：デフォルトの名無しさん：2011/08/13(土) 03:27:52.49

> Image24も Image16も ImageJPGも、Imageを継承していれば、

直接継承関係にない形式も変換したいのなら、
conv(Object img) こんなのでもいいけどね。

あとは実行時型情報を使って、型名を取得し
その型名に対応したConverterをFactoryから取得すればできる。

どちらにしろ、Conveterが画像オブジェクトから
データをgetすることには変わらないけど。

これをgetterを使わないで、実装するにはどうすればいいんだろうね。
スマートに実装できるのかな？

102 ：デフォルトの名無しさん：2011/08/13(土) 04:13:39.22

Image にtoNumeric()持たせちゃえば良いんでない

103 ：デフォルトの名無しさん：2011/08/13(土) 07:04:57.37

厳密に完璧な設計にするならデータのやり取りのほぼ全ては
インターフェースでやり取りするべきだよな
でも現実的に使い捨ててもいいようなものを作るなら
getter, setterなんて作らなくてもいいし
完璧に仕上げるべき部分と適当でいい部分を見極めて設計したほうがいいんじゃないのか
十年後も使ってそうな部分は完璧に設計してインターフェース層と
インプリメント層を分けてテストしまくりで作り上げて
なくなってそうな部分はVBであうあう言いながら適当に作っておけよ
客がバカなら外側だけを立派にして中で手抜きするんだ

104 ：デフォルトの名無しさん：2011/08/13(土) 07:12:29.87

最小限度ではいいと思うが、getter/setter不要だとは思わん
本質的にgetter/setterが向く用途はあるのだから

105 ：デフォルトの名無しさん：2011/08/13(土) 09:24:31.66

そうそう。i=i+1なんてその典型。
JavaやC+なんかの手続き型言語は元々そういうもの。

それに、インターフェースを使った情報取得だと、
情報を取得する側のコールバックメソッドの呼び出し順が、
情報取得の対象のオブジェクトの実装に依存するから、
情報を取得する側のオブジェクトの整合性が破壊される危険がある。
これは丁度、getter/setter方式で情報取得の対象のオブジェクトの
メソッド呼び出し順が不定になって危険ってのと逆の現象。

getter/setter→呼び出し先が危険
コールバック→呼び出し元が危険
なわけだから、状況によって使い分けるのが賢い。

106 ：デフォルトの名無しさん：2011/08/13(土) 10:09:05.52

整合性の話はまた別じゃないか？
スレッド間の排他、同期、っていう話じゃなくて？

そうじゃなくて、単一スレッドでの、
呼び出し順に正解不正解があるのが問題だとしたら、
それはよくある使いにくいだけの糞クラス。

107 ：デフォルトの名無しさん：2011/08/13(土) 10:19:46.70

>>97
そんなのメソッド並べてくれたほうが明らかにわかりいいね

108 ：デフォルトの名無しさん：2011/08/13(土) 10:24:08.36

>>78
名前に文句つけてるだけ？
オブジェクト指向理解してないな
イベントが確定してたらgetterなんて作らないだろ
仕様があいまいなまま作ろうとするからgetterなんてできちゃうんだろ

ってかお前は他の人より大分レベル低そうだからそれでいいやｗ
（どうせ微妙な違いだしｗ）

109 ：デフォルトの名無しさん：2011/08/13(土) 10:28:04.51

>>101
奴らは画素一つ一つをオブジェクトにするらしいよ

110 ：デフォルトの名無しさん：2011/08/13(土) 10:28:13.19

まずスレッドを批判すればいいのに
スレッドは強そうだから、代わりに弱そうなgetter/setterをいじめてるのか
まったく酷い話だ

111 ：デフォルトの名無しさん：2011/08/13(土) 11:22:21.95

>>101
image24.pixels24To(new Pixels24To16Converter(image16));
pixels24To: arg.setPixels24(this.pixelBuffer);
setPixels24: this.image16.setPixels16(convertPixels24To16(arg));
とでもするんじゃないの
余計なコピーが発生する以外にgetterと何が違うのか知らないけど

112 ：デフォルトの名無しさん：2011/08/13(土) 11:37:32.09

必要以上に削ったり、短縮したりする必要はないが、
長すぎる変数名、クラス名、メドッド名、すべて設計の悪さを匂わしてる。

113 ：デフォルトの名無しさん：2011/08/13(土) 12:41:56.35

>>100
> new Numeric(String) 、new Numeric(int) みたいなのだと、
> 未知の形式に対応できないからね。つまりnew Numeric(ABCD)
> なんてのは用意されてますか？って話。

Numeric には new Numeric(ABCD) は無いけど convertFrom(ABCD)はあるの？www
自分に都合の良い妄想見てんじゃねーぞ馬鹿が

でだ、Numeric みたいなクラスは immutable であることも珍しくないが、
その場合はどうするんだ？
>>41は immutable でも動くが>>6は動かねーぞ？

114 ：デフォルトの名無しさん：2011/08/13(土) 12:56:14.31

new Numeric(ABCD) はgetter/setterそのものだよ。

n = new Numeric();
n.setValue(n)

やってることは、これと全く同じだからね。

そして、nから内部の値を取得するもの。
n.getValue() これはもちろんgetterだし、
n.getValueAsString() これも、nを文字列としてgetするからgetter

toValueも結局は、getter/setterを使っているのと一緒。
単に名前にget/setが入っていないだけ。

115 ：デフォルトの名無しさん：2011/08/13(土) 13:14:24.27

toValueじゃ値を渡すタイミングは受け取る側が握ることになるよね
イベントの利点はどこに行ったの?

116 ：デフォルトの名無しさん：2011/08/13(土) 15:02:44.58

>>48のコードが悪い意味で神すぎる件。
今年見たコードの中でもぶっちぎりで最低だ。
こいつまだ息してるの？

117 ：デフォルトの名無しさん：2011/08/13(土) 15:43:54.59

説明が抜けてる。0点

118 ：デフォルトの名無しさん：2011/08/13(土) 15:45:35.05

>>111
通信の実装を表に出すなよ。それじゃgetterと変わらないだろ。

119 ：デフォルトの名無しさん：2011/08/13(土) 15:47:39.42

>>114
setterはgetterの選択しないけど？

120 ：デフォルトの名無しさん：2011/08/13(土) 15:50:37.52

>>99
未知は未知でいいんだよ。
元々渡す方も受け取る方もそれを前提にしていない。
送り側、受け取り側が新しい形式に対応するばあいは、
拡張したインターフェースを作って、それを実装するか、
必要となる他のインターフェースを新たに実装すれば済む。

121 ：デフォルトの名無しさん：2011/08/13(土) 15:51:43.37

>>116
getterさんそこら中にいるから、そんなかのどっかに居るんじゃない。

122 ：デフォルトの名無しさん：2011/08/13(土) 15:52:39.87

>>118
実装（コード）とデータの区別ついてる？

表に出すのはデータであって実装ではない。
しかも表に出しているのは、内部データではなくて
外部用のデータだ。

123 ：デフォルトの名無しさん：2011/08/13(土) 15:55:11.29

>>114
意味が解からん。setterの中でgetter何度も呼ぶだけ無駄じゃん。
元となるオブジェクトの状態情報を取り出すgetterまで呼ぶんだろ>>48と同じじゃん。きたねぇ。

124 ：デフォルトの名無しさん：2011/08/13(土) 16:00:19.40

>>120
> 送り側、受け取り側が新しい形式に対応するばあいは、
> 拡張したインターフェースを作って、それを実装するか、
> 必要となる他のインターフェースを新たに実装すれば済む。

なんかお前の作るクラスは一つのクラスに機能を
たくさん押し込み過ぎになりそうだな。
一つのクラスがたくさんのインターフェースを実装してるんだろ？ｗ

送り側、受け取り側が、どんどん対応形式を増やしていき、
どんなものでも変換できちゃう、
神のようなオブジェクトができあがりそうだｗ

あ、神オブジェクトってのは褒めてないからね。ぐぐってね。

125 ：デフォルトの名無しさん：2011/08/13(土) 16:19:48.18

>>122
値を渡す側が、受け取り側に渡す判断基準は、受け取り側から一切アクセスできない。
値をどう渡すかは、飽くまで実装の問題。データではない。

126 ：デフォルトの名無しさん：2011/08/13(土) 16:22:47.43

×値をどう渡すかは、飽くまで実装の問題。
○値をどう渡すかは、あくまで仕様の問題。

なんもわかってないじゃねーか。

127 ：デフォルトの名無しさん：2011/08/13(土) 16:24:00.93

>>125
ねえ渡す側と受け取る側に一切のコントラクトが無くて何をどうやって渡すの?

128 ：デフォルトの名無しさん：2011/08/13(土) 16:26:20.94

>>124
"1つの事だけを上手くやれ"って話しらないの？Unix哲学とかであるけど。
画像処理するオブジェクトは、画像のプロフェッショナルでいい。
どういう形で値が渡されようと、内部で処理する分には全て画像として取り扱い、
入力変換以外では、一切画像に関係ないことはしない。
入力変換自体も画像オブジェクト自体が知っているべき事で、
他のオブジェクトが知っていてはいけない。それは画像オブジェクトの領域に
踏み込んだことになる。
素直に画像オブジェクトに変換を任せればいいだけ。

129 ：デフォルトの名無しさん：2011/08/13(土) 16:27:44.10

>>127
話が何処とも繋がってないから意味がわからないよ。

130 ：デフォルトの名無しさん：2011/08/13(土) 16:32:54.05

>>127
どこにコンストラクター使っちゃいけないって書いてあんの？>>19とか使いまくりじゃん。

131 ：デフォルトの名無しさん：2011/08/13(土) 16:39:47.60

>>121
アホか>>48書いたのブロードキャスター君だろwww

132 ：デフォルトの名無しさん：2011/08/13(土) 16:41:38.84

前スレの最後のほうにいい意見が出てたが、
小さいインタフェースっていう観点。メイヤーのOOSCの60ページ目。
モジュール間の接続の数（これは「少ないインタフェース」の話題）でなく、
サイズについて、情報量は小さくすべきである、という話。

アクセッサが悪く見えるとき、
getGreenAppleTable, getAvocadoApricotMap, getStrawberryFigTree
, getOrangeSlot, getPersimmonChunk, geTraspberryThread
みたいなデッカイ粒をやりとりしてて、それが臭いのかもしれない。

もしここが、Javaでいうところのプリミティブ型程度のやりとりだったり、
せいぜいそこに、java.lang.*;程度のクラスのオブジェクトやり取りだったりすると、
カプセル化は守られたような気になるのではないか。

ゲッタセッタが悪く見えるとき、
実はインタフェースの大きさこそが問題だったりして。

133 ：デフォルトの名無しさん：2011/08/13(土) 16:44:18.19

>>128
> "1つの事だけを上手くやれ"って話しらないの？

えぇ、だからどんな画像形式にも対応するのは
「一つの事」ではないのですよ。

たくさんの事をやれる、画像のプロフェッショナルなんてのを
作らないようにしようねｗ

134 ：デフォルトの名無しさん：2011/08/13(土) 16:44:27.97

そういやブロードキャスター君がコンストラクタ使うと
変換が余計にかかるみたいな妄言吐いてたけど、あれってどういう意味？
コールバックなら掛からないとでも？

頼まれもしないのに下らないゴミコード貼りまくってんだから、
コールバックだと変換かからないって示すコード貼ってみせてよ。

135 ：デフォルトの名無しさん：2011/08/13(土) 16:47:07.88

>>128
だからその魔法の変換君をどうやって実装するのか知りたいんだけど
俺は画像処理としてのまともな速度とgetterなしを両立するには、データを巨大な値として>>111のように渡すく
らいしか思いつかないんだが、良い方法があるならぜひ教えて欲しい

136 ：デフォルトの名無しさん：2011/08/13(土) 16:48:34.03

>>117
>>41 >>75と比べて>>48が優れてる点って何だ？www

137 ：デフォルトの名無しさん：2011/08/13(土) 16:53:22.41

>>135
脳みそお花畑で何も考えてないだけだと思うぞ。
試しにコード書かせてみたら良い。

138 ：デフォルトの名無しさん：2011/08/13(土) 16:55:32.55

>>135
なんでpixel24Toって形式指定してる事がおかしいて思わないの？
コンストラクターが問題じゃなくて、toValueで隠蔽してたpixel24を表にだしてる事が問題なんだけど。

139 ：デフォルトの名無しさん：2011/08/13(土) 16:57:40.39

>>134
コンストラクターっつうか>>48になる事が問題なんだろ。

140 ：デフォルトの名無しさん：2011/08/13(土) 17:00:12.51

>>139
あれ？馬鹿には>>41は見えないの？

141 ：デフォルトの名無しさん：2011/08/13(土) 17:01:14.03

なんか必死すぎて爆笑

142 ：デフォルトの名無しさん：2011/08/13(土) 17:02:17.40

これ使って頑張って書こうとすると
Numeric getNumeric()
{
return new Numeric("10");
}

object.getNumeric().getInt();
object.getNumeric().getString();
こういう形式になんのか。

143 ：デフォルトの名無しさん：2011/08/13(土) 17:02:21.84

Numericがimmutableの場合はどうするのか、とか
何故コールバックだと変換が余分にかからないのか、とかの
質問に答えた方が良いよブロードキャスター君。

144 ：デフォルトの名無しさん：2011/08/13(土) 17:03:37.61

>>142
最初からintが欲しければobject.getInt()だろ馬鹿

145 ：デフォルトの名無しさん：2011/08/13(土) 17:03:57.90

Numeric ～のやつは
そもそも設計がおかしい。

無理やりgetter排除しようという考えで作るから
設計がねじれるといういい例だ。

146 ：デフォルトの名無しさん：2011/08/13(土) 17:05:00.68

いい加減>>6でやりたいことは>>41で出来てる事を認めた方が……

147 ：デフォルトの名無しさん：2011/08/13(土) 17:06:21.24

>>145
確かに。ちょっと理解できないセンスだよな。
でも面白いからもっとヤレって思ってるw

148 ：デフォルトの名無しさん：2011/08/13(土) 17:06:46.20

>>140
いや、それコンストラクターというよりgetNumericが問題だからな。

149 ：デフォルトの名無しさん：2011/08/13(土) 17:08:08.25

>>146 それだと >>97 の問題が発生するって。

150 ：デフォルトの名無しさん：2011/08/13(土) 17:09:50.02

>>149
なるほど。ではコールバックだと問題が発生しないって
コード使って説明してみて。

151 ：デフォルトの名無しさん：2011/08/13(土) 17:12:04.21

だから画像の変換は、画像オブジェクトと
変換オブジェクトは分離させて、
変換前と変換後の形式をもとにFactoryから
変換オブジェクトを取得して変換させろと。

152 ：デフォルトの名無しさん：2011/08/13(土) 17:14:44.07

ちょっと議論に置いてけぼりなんだけど、
toValueの実装はどうなってるの？
getNumericはあったけどtoValueはまだ出てなかったよね？

153 ：デフォルトの名無しさん：2011/08/13(土) 17:16:55.14

>>150
convertFrom( 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 = //変換処理

154 ：デフォルトの名無しさん：2011/08/13(土) 17:18:25.83

>>152
前スレ>>994より

//object1が、内部で文字列として持っている場合
void toValue(Numeric target)
{
target.convertFrom( "100", 10 );
}

//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
target.convertFrom( 10 );
}

155 ：デフォルトの名無しさん：2011/08/13(土) 17:20:44.95

>>154
てかコールバックつうよりダブルディスパッチだよな。
グダグダ議論するよりダブルディスパッチの記事調べたほうが早い。

156 ：デフォルトの名無しさん：2011/08/13(土) 17:24:33.29

>>153
それってtoValue()の中身？
つまり source.toValue(obj) は source 自体も変える操作ってことでおk？
ぐだぐだ質問してスマン

157 ：デフォルトの名無しさん：2011/08/13(土) 17:27:46.09

>>156
変えない。可能か不可能かといえば可能だけど、変える必要なんて無いし。

158 ：デフォルトの名無しさん：2011/08/13(土) 17:34:00.39

>>154
まぁ、ダブルディスパッチの問題対応できなきゃgetterなら云々言っても仕方ないわな。

159 ：デフォルトの名無しさん：2011/08/13(土) 17:42:47.35

>>133
　実際には画像形式が基準ではないんだけどね。
例えば、PNG、BMPがそれぞれ24bit形式で値を持ってるなら
処理の内容変える必要はない。なのでPNGかBMPかで
メソッドを分ける必要もない。問題は、16bitだのアルファ値がつくだの
直接処理に影響する部分。そこだけ変換するインターフェースを持っていればいい。
もし、PNG、BMPを区別する必要があるんならそっちはそっちでインターフェース用意すればいいだけだし、
今まで24bit、16bitとかしか気にしてなかったオブジェクトが、PNGやBMPのインターフェースを持つ必要もない。
森羅万象変換する必要なんて無い。

160 ：デフォルトの名無しさん：2011/08/13(土) 17:53:11.23

161 ：デフォルトの名無しさん：2011/08/13(土) 17:57:55.15

>>131
ブロードキャストの話は、MVCの実装方法の話なのになんで
まだ引きずってんの？

162 ：デフォルトの名無しさん：2011/08/13(土) 17:58:51.73

>>160
同じにはならねぇよ。
getterのNumericは処理しないだろ。

163 ：デフォルトの名無しさん：2011/08/13(土) 18:00:12.44

あーなるほど
Decoratorパターンは効率悪いってこと？
でも画像ならともかく、Numeric -> PackedNumeric では変換は走らないと思うぞ
野暮な突っ込みだが

164 ：デフォルトの名無しさん：2011/08/13(土) 18:03:37.26

>>163
PackedNumericに値が入った時点で、丸められるし、
Numericの中身が整数型である保証はない。PackedNumericに
値を渡せられる何か。

165 ：デフォルトの名無しさん：2011/08/13(土) 18:05:29.02

あとPackedNumericも中でどんな形で値を持ってるかは不明。有理数かもしれない。

166 ：デフォルトの名無しさん：2011/08/13(土) 18:08:50.43

>>164
まあ、NumericとPackedNumericが内部で数値を表す
データ構造が違う可能性はあるけど、ちょっと苦しいだろ
速度が気になるところだけ>>6のように書いても良いんだし(>>41の方が記述は短い)

普通にImageだけに絞って話した方が良いと思うぞ

167 ：デフォルトの名無しさん：2011/08/13(土) 18:13:30.28

あと既出だけど、Numeric（に限らず任意のクラス）がimmutableな場合は
やっぱりgetterが必要だと思うぞ

168 ：デフォルトの名無しさん：2011/08/13(土) 18:22:32.89

>>166
ImageとかNumericどちらかで話をすると、Numeric固有Image固有で
話を進めてくる輩がいるしなァ。あと、別に数値で持ってないってことは珍しくないんだ。
例えば、
Fillter fillter = new Pack(100);
new FileValue( file1, "キー" ).toValue( fillter );
fillter.toValue( new FileValue( file2, "キー" ) );

だと、FileValueは中身ファイルだけ持ってりゃいいし。

>>167
Immutable自体は最初から諦めてるよ。
そんなもんで関数型言語とは相性の悪いやり方だけど。

169 ：デフォルトの名無しさん：2011/08/13(土) 18:51:43.51

immutableでgetter必須って人は、
substringも、getSubstring()なの？
toStringもgetString()なの？

170 ：デフォルトの名無しさん：2011/08/13(土) 18:57:20.77

>>169
俺はてっきりjava.beanの対象となるアクセサや、
プロパティ機能の事だと思ってたけど、そういう事だったんだな。
なるほど、どおりで食い違うわけだ。

171 ：デフォルトの名無しさん：2011/08/13(土) 19:07:08.01

>>168
immutableは最適化に有利だしバグ防止に役立つし
諦めるには勿体無い気がするが、それはこちらが関数型言語の方が
好きなせいかもな

>>169
話題がGUIの話とか>>6とかで発散してるからなぁ
getXxxって名前がダサイのは同意するし
M→Vをgetterで書かれたら殺意を覚えるのも事実

172 ：デフォルトの名無しさん：2011/08/13(土) 19:10:12.76

>>169
えーと、>>78に答えてあげてください

173 ：デフォルトの名無しさん：2011/08/13(土) 19:11:48.97

>>49 みたいなgetterさんが、setterとgetterで書いても同じだというので
プロパティーで書いてみたら入出力逆で気持ち悪くて仕方ないでござるの巻

source.toValue = dest;

174 ：デフォルトの名無しさん：2011/08/13(土) 19:13:51.00

>>173
綺麗に見せようとするとC++の source >> dest; になるわな。

175 ：デフォルトの名無しさん：2011/08/13(土) 19:19:56.05

>>171
関数型で不可能かというとそうでも無いけどね。
Type toValue(new Type())で引数で入ってきたもんコピーして
返せば良いわけだから。関数型言語なら仮想関数テーブルに当たる
部分を失わせず返す事ができるだろうから行けるっちゃいけるだろう。

176 ：デフォルトの名無しさん：2011/08/13(土) 19:39:42.16

関数がファーストクラスのオブジェクトの言語で
副作用無しならこうだよな

Numeric toValue (factory)
{
return factory(10); // factory は new PackedNumeric(255)をカリー化した関数
}

177 ：デフォルトの名無しさん：2011/08/13(土) 19:46:03.89

そうだね。

178 ：デフォルトの名無しさん：2011/08/13(土) 20:30:59.06

ワロタｗ　なにこれ？　toValueの意味が無いじゃん。

> //object1が、内部で文字列として持っている場合
> void toValue(Numeric target)
> {
> target.convertFrom( "100", 10 );
> }
>
> //object1が内部で整数として持っている場合
> void toValue(Numeric target)
> {
> target.convertFrom( 10 );

やってることは、これだけでしょ？
target.convertFrom( "100", 10 );
target.convertFrom( 10 );

179 ：デフォルトの名無しさん：2011/08/13(土) 20:32:13.84

> target.convertFrom( 10 );

これ、ただのsetterじゃねーの？

Numeric target = new Numeric();
target.setValue(10);

180 ：デフォルトの名無しさん：2011/08/13(土) 20:38:02.83

>>178
ダブルディスパッチについてお勉強しまちょうね。

181 ：デフォルトの名無しさん：2011/08/13(土) 20:40:14.31

ダブルディスパッチの内部でsetterを使ってるだけだろ？

182 ：デフォルトの名無しさん：2011/08/13(土) 20:47:28.53

>>181
お前にとっちゃプロパティー替わりじゃなくても全てセッターなんだろうな。
それともこんなふうに書けることを想像してんだろうか。
target.convertFrom = "1000", 10;
引数が2つに増えたぐらいだったら
target.onvertFrom[10] = "1000";
ぐらいは無理やり書けるか。

183 ：デフォルトの名無しさん：2011/08/13(土) 20:48:56.15

>>180
へ？それダブルディスパッチのつもりだったの？
それじゃ、今までの議論全て台無しじゃん。

ダブルディスパッチの、”ダブル” はどこにあるのかな？
もしこれがタブルディスパッチなら、convertFromの引数にthisがあるはず。

184 ：デフォルトの名無しさん：2011/08/13(土) 20:50:46.22

だめだって、下駄雪駄は処理の如何にかかわらず
戻り値がなければ全てsetter、戻り値があれば全てgetterらしいから。

185 ：デフォルトの名無しさん：2011/08/13(土) 20:52:25.72

>>184
つーか、関数の特殊バージョンが、setter/getterだよ。

オブジェクト内部の状態を変更、もしくは取得する関数で
一番単純にしたものが、setter/getter

186 ：デフォルトの名無しさん：2011/08/13(土) 20:52:57.82

>>183
Wikipediaに書いてある事がオマエの全てか。

toValue ← 一回目
convertFrom ← 二回目

別にthisを渡すことがダブルディスパッチの要件じゃねぇし。

187 ：デフォルトの名無しさん：2011/08/13(土) 20:54:49.88

>>185
getter排除派は、プロパティー構文として機能しているものをgetter/setterと
呼んでるように見えるけど。

188 ：デフォルトの名無しさん：2011/08/13(土) 20:57:46.61

結論として>>39で話終わってるんでしょ？
なんのために実装の話なんてしてるの？
実装の話してる人はレベル低そうなんだけど
設計の話なのになんでいちいち実装出さないと話できないの？

189 ：デフォルトの名無しさん：2011/08/13(土) 21:00:35.00

getter屋はconnect(host, port)もsetConnect(host, port)じゃないといかんらしい。

190 ：デフォルトの名無しさん：2011/08/13(土) 21:01:13.44

>>154がダブルディスパッチの話だとすると、

//object1が、内部で文字列として持っている場合
void toValue(Numeric target)
{
　　target.convertFrom( "100", 10 );
}

//object1が内部で整数として持っている場合
void toValue(Numeric target)
{
　　target.convertFrom( 10 );
}

void toValue(Numeric target) ← このNumericの部分の型は
それぞれ違っていなければならないはず。

191 ：デフォルトの名無しさん：2011/08/13(土) 21:01:29.93

実はsetter vs getterの争いだった件

192 ：デフォルトの名無しさん：2011/08/13(土) 21:03:01.76

>>190
Numericはインターフェースで実装は違う。
this渡すダブルディスパッチでも同じだったろ。

193 ：デフォルトの名無しさん：2011/08/13(土) 21:04:03.85

実装を出さずに話す奴って、実装が出来ない奴だろ。

194 ：デフォルトの名無しさん：2011/08/13(土) 21:06:04.32

じゃあ、今から全部実装すること。
toValueとそれ関連全てを。
一部分出すから誤解を与える。

195 ：デフォルトの名無しさん：2011/08/13(土) 21:11:52.95

>>75はこうすると変換が少なくて済む

//sourceが内部で文字列として持っている場合
Numeric getNumeric()
{
return new StringNumeric("10"); // 内部で文字列で持ってるNumeric
}

//sourceが内部で整数として持っている場合
void getNumeric()
{
return new IntNumeric(10); // 内部で整数で持ってるNumeric
}

196 ：デフォルトの名無しさん：2011/08/13(土) 21:21:47.71

>>195
要するに >>160 になるんだよな。

197 ：デフォルトの名無しさん：2011/08/13(土) 21:22:06.10

>>192
> Numericはインターフェースで実装は違う。
じゃあ実装を書いてね。動かない実装風のものに興味はないから。

198 ：デフォルトの名無しさん：2011/08/13(土) 21:26:38.39

ダブルディスパッチだとしても、
それはディスパッチ（関数呼び出し）部分の話であって
最終的には、

classA {
　public void func(ClassB b) {
　　　ここでbから値を取得して、なにか処理する。
　}
}

こういうことをするんだろ？
結局は、bにあるgetterを使って、bの状態を見ながら処理するわけで、
ダブルディスパッチがあれば、getterがいらないってことにはならないんだが？

199 ：デフォルトの名無しさん：2011/08/13(土) 21:31:35.96

いえてる。
ダブルディスパッチはメソッド決定のメカニズムでしかないから、
その決定されたメソッド内で、
getter/setter使うか、それともコールバック式に引数で情報をもらうかは、
また別問題だよな。

200 ：デフォルトの名無しさん：2011/08/13(土) 22:06:41.98

>>197
めんどくさいヤツだな。お前以外は解ってるよ。

http://ideone.com/mzkq1

>>199
もともとgetterはいらんし使わんでも書ける。さらに加え、
ダブルディスパッチなどでオブジェクト自身に判断させれば済む事を
外に晒してるってのがナイなって事で、ダブルディスパッチが出たの。

あくまで、getterのロスや、カプセル化の破綻を見せるための一例。

201 ：デフォルトの名無しさん：2011/08/13(土) 22:14:58.10

>>200

>>198

202 ：デフォルトの名無しさん：2011/08/13(土) 22:16:05.41

>>201
中身見て書いてんのか？

203 ：デフォルトの名無しさん：2011/08/13(土) 22:16:11.28

getterがいらないのはディスパッチ部分のみ。
ディスパッチは呼び出す関数を選択するとこまでのこと。

その後でどうせgetterを使用する。
ディスパッチでgetterがいらないからという理屈で
世の中からgetterすべてがいらないと結論づけるのは馬鹿。

204 ：デフォルトの名無しさん：2011/08/13(土) 22:16:34.54

>>200のリンク先が釣りにしか見えぬ…。
クラス名、メソッド名ともに、悪い結果しか残してないように見える。
すくなくとも、そうじゃないけないという説得力は伝わってこない。

205 ：デフォルトの名無しさん：2011/08/13(土) 22:19:07.88

>>198
>public void func(ClassB b)
じゃなく
>public void func(Stirng a,Point, b)
てな形で直接ClassBの中身渡せばいいよな。
なんのためにワザワザClassBにgetter用意すんの？

206 ：デフォルトの名無しさん：2011/08/13(土) 22:20:27.62

>>203
現に >>200 のコードじゃ一切必要ないけど。

207 ：デフォルトの名無しさん：2011/08/13(土) 22:21:55.69

>>204
悪い結果って何？
あと補足程度に言うけど、>>200のクラスに今のメソッド以外のメソッドを追加しちゃいけないわけじゃないからな。

208 ：デフォルトの名無しさん：2011/08/13(土) 22:23:18.60

>>203
>その後でどうせgetterを使用する。
それは書き方次第だろう。
必要な情報が引数で渡るようにしておいても良いし。
ただどうせ、追加の情報が欲しくなってgetter使うんだけどな。

あと、getter/setter否定派は、
obj1.get～
obj2.get～
何か計算
obj1.set～
obj2.set～
と言う風に複数のクラス間に処理が跨るときはどうするんだろう。

209 ：デフォルトの名無しさん：2011/08/13(土) 22:24:53.93

>>207
不明瞭な単位でのクラスやメソッドを量産し、
いたずらにプロジェクトを混乱させること。

210 ：デフォルトの名無しさん：2011/08/13(土) 22:25:01.20

>>205
お前はダブルディスパッチについて調べろ。

ダブルディスパッチとは、ClassB bの型情報をもとに呼び出す関数を
振り分けるのだからClassB がなければディスパッチできん。

classA {
　public void func(ClassB b) {
　　　ここで相手がClassBだった場合の処理
　}
　public void func(ClassC c) {
　　　ここで相手がClassCだった場合の処理
　}
}

211 ：デフォルトの名無しさん：2011/08/13(土) 22:26:25.25

>>208
そもそも、そのset/get自体は無いからな。
もともとライブラリにあってもまぁそりゃ構わんけど。

結局>>200の方法なら影響しないでしょ。

212 ：デフォルトの名無しさん：2011/08/13(土) 22:26:37.73

>>206
> 現に >>200 のコードじゃ一切必要ないけど。
それはそもそも、ダブルディスパッチを使う必要がないコードだからだよ。

213 ：デフォルトの名無しさん：2011/08/13(土) 22:27:34.68

>>209
機能単位で別れてんじゃん。それ以外の何者でもない。

214 ：デフォルトの名無しさん：2011/08/13(土) 22:28:56.62

>>210

>>186と>>200見たら？

215 ：デフォルトの名無しさん：2011/08/13(土) 22:30:03.44

>>212
ダブルディスパッチはなんのために使うもんだと思ってんの？
クラスを識別するためとか、辞書に乗ってそうな説明はすんなよ。

216 ：デフォルトの名無しさん：2011/08/13(土) 22:36:13.35

> 辞書に乗ってそうな説明はすんなよ。
じゃあ、どう説明すればいいんだよｗ

そこは辞書にのってるような正しい説明を要求するべきだ。

217 ：デフォルトの名無しさん：2011/08/13(土) 22:37:48.97

getter/setter方式だとカプセル化が破綻するって言うけど、
コールバック方式でも、多段的にコールバックすると、
破綻しちゃうんじゃないの？
何かの設定をするためにコールバックしてもらう。
他の情報も必要になって、その中から更に別のコールバックをしてもらう。
とか。
しかもJavaやC++だと、関数間でローカル変数を持ち越せないから、
処理に必要な一時変数をメンバ変数で受け渡し・・・。
呼び出し先のオブジェクトが多段的なコールバックに　対応している/していない　の問題や、
そもそも呼び出し元のオブジェクトの処理がコールバックで分断されてスパゲッティ－化するとか。
一長一短に思えるけどネェ。
素直に、locker = obj.lock(); getter/setter locker.unlock();でも良いと思うけどなぁ。

218 ：デフォルトの名無しさん：2011/08/13(土) 22:47:04.01

>>210
ほう。それじゃタイプレス言語じゃ
ダブルデイスパッチは不可能つて事になるな。

219 ：デフォルトの名無しさん：2011/08/13(土) 22:48:28.08

>>213
釣りなら釣られたくないし、
本気なら俺が貴方に言うことは何も無い。

220 ：デフォルトの名無しさん：2011/08/13(土) 22:50:09.60

>>216
ダブルデイスパッチはどういう時に使うか経験談で
説明も出来ないのに本にこう書いてあったから
間違いないと偉そうに説明するきかい。

221 ：デフォルトの名無しさん：2011/08/13(土) 22:52:11.49

結局>>41は>>195と組み合わせれば良いのか？

222 ：デフォルトの名無しさん：2011/08/13(土) 22:53:57.90

>>219
君にとっちゃコマンドパターンの
コマンドも釣りなんだろ。
意識の相違だからどうしょうもないな。

223 ：デフォルトの名無しさん：2011/08/13(土) 22:55:15.55

>>218
タイプレス言語ってなに？

変数に型がない言語はあるが、
変数に入っている値に型があるのなら、ダブルディスパッチはできるよ。

ただその場合は、オーバーロードができないから、
関数名を分けるか。
func_b（値がClassBだった場合に呼び出される）
func_c（値がClassCだった場合に呼び出される）

funcという一つの関数で受け取って、
引数を見て、func_b、func_cに振り分けることになるけど。

224 ：デフォルトの名無しさん：2011/08/13(土) 22:56:29.48

>>221
オブジェクト間に無駄なオブジェクトが存在するから、
あれを排除しない限りどうやっても無理。

225 ：デフォルトの名無しさん：2011/08/13(土) 22:57:35.24

>>223
じゃ中身渡せばいいだけの話だよね。

226 ：デフォルトの名無しさん：2011/08/13(土) 22:58:44.64

ダブルディスパッチの理解、おまえら大丈夫か？
分かってるの一人くらいしかいないように見えるが。
一回目に呼ばれたメソッド内で、thisを渡すことにより、
型情報が使えるんで、もいいっかい委譲オブジェクトに対してオーバーロードされたメソッドから、
適切なのを選べるってことだぞ。this渡すことでその型が使えるのがポイントだぞ。

227 ：デフォルトの名無しさん：2011/08/13(土) 22:59:29.91

>>222
すまん。ますますもって意味不明になってきたので打ち切りたい。

228 ：デフォルトの名無しさん：2011/08/13(土) 23:04:57.68

>>225
中身見て、
switch（中身) {
　○ならfunc_○
　△ならfunc_△
　□ならfunc_□
　×ならfunc_×
}
ってコードを書かないといけなくなるけどねｗ

229 ：デフォルトの名無しさん：2011/08/13(土) 23:05:53.73

>>226
だからそれじゃ静的型付け言語じゃないと出来ないだろ。
それからダブルデイスパッチは、マルチディスパッチや
シングルデイスパッチと同じ領域の話だ。

230 ：デフォルトの名無しさん：2011/08/13(土) 23:07:08.69

>>228
>>200のコードのどこにそんな記述があった？

231 ：デフォルトの名無しさん：2011/08/13(土) 23:08:30.96

>>229
出来なくはない。
ただし動的型付け言語だと、オーバーロードができないんで
swtichの嵐になる。

switchの嵐をどうせ書くのなら、
ダブルディスパッチなんてテクニックを使わずに、
呼び出し部分でswitch使って切り替えればすむから
意味が無いって話になるだけ。

232 ：デフォルトの名無しさん：2011/08/13(土) 23:10:05.02

getter派は、ワザワザ人にコード貼らせてそれも読めないバカばっか。
だから、頭使わずとりあえず書けるgetter/setterを書きまくるわけだ。

233 ：デフォルトの名無しさん：2011/08/13(土) 23:13:19.91

>>231
ならねぇよ。
なんでダブルディスパッチなのか解ってないだろ。
object1とobject2でダブルディスパッチする場合、
お前の書いたswitchがobject1の仮想関数テーブルになる。
で、2回めのディスパッチがobject2の仮想関数テーブルになる。
関数のシグニチャがどうのは関係ないんだよ。

234 ：デフォルトの名無しさん：2011/08/13(土) 23:13:37.82

ある人はなるべくシンプルに、一般的な方法で記述し、
またある人はなるべく複雑に、特殊な方法を選んで記述する。

235 ：デフォルトの名無しさん：2011/08/13(土) 23:30:10.81

>>170
俺もそう思ってた
今回の議論でメソッド名なんてどうでもいいだろ
機能の問題
と思ってたんだけど、フィールドを取得するメソッド名の先頭にgetをつける、つけないを議論している人もいたのかw

236 ：デフォルトの名無しさん：2011/08/13(土) 23:31:11.45

>>217
カプセル化される対象は、値を渡す側のオブジェクトの判断結果。
送り側が、受け取り側に渡した時点で、受け取り側には"値として"送り側の
判断結果が渡らない。受け取り側がわざわざフラグだの何だのにその結果を
記録しない限りは、その時点で送り側の情報は消えるんで、いくらコールバックしようが
カプセル化の破綻にはつながらないよ。

237 ：デフォルトの名無しさん：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)と解釈される。

やりたいことは本質的にはこれであり、ダブルディスパッチは
これを型あり言語で実現するために用いられるテクニック。

238 ：デフォルトの名無しさん：2011/08/13(土) 23:38:32.56

もし、これが型無し言語であれば、foo.func(n); という呼び出し方でいい。
頑張ろうとした所でオーバーライドがないのだから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コードによる手動振り分けコードを書かなくてよくしたものである。

239 ：デフォルトの名無しさん：2011/08/13(土) 23:49:59.90

訂正

×頑張ろうとした所でオーバーライドがないのだからswitchは絶対に必要になる。
○頑張ろうとした所でオーバーロードがないのだからswitchは絶対に必要になる。

240 ：デフォルトの名無しさん：2011/08/13(土) 23:55:26.50

>>238
なんでfunc_int,func_longをint型のオブジェクト、long型のオブジェクトが呼び出しちゃいかんのだ。
形式とかどうでもいいから、その結果発生する問題を言ってくれ。

241 ：デフォルトの名無しさん：2011/08/13(土) 23:58:51.59

>>238
よく見たらコイツ間違えてんじゃん。
なんでFooの中でfunc_intとfunc_long呼び出してんだよ。
func(v)の中で呼び出すのは v.func_CategoryBar( this ); だろ

242 ：デフォルトの名無しさん：2011/08/14(日) 00:00:50.12

>>237
偉い説法してるくせに何で"ディスパッチ"なのか理解してないのな。

243 ：デフォルトの名無しさん：2011/08/14(日) 00:08:47.65

動的言語ならこれで済む。

A.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() );

244 ：デフォルトの名無しさん：2011/08/14(日) 00:14:40.92

>>241
これは静的言語によるダブルディスパッチの
実装を書いたんじゃないよ。

ダブルディスパッチでやりたいこと(>>237)が何かと
それを動的言語(>>238)で実装した場合の話。

Javaっぽく見えるだろうけど、別にJavaということではない。

あとひとつ書き忘れた、静的言語によるダブルディスパッチは
実行時の型情報をしようしてないってことに注意。
実行時の型情報を使わないという制約のもとに、
「やりたいこと」を実現するときに使うのがダブルディスパッチ

245 ：デフォルトの名無しさん：2011/08/14(日) 00:18:26.04

>>232
じゃあ貼ってみる。
>>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();
    /* 丸め処理 */
}

246 ：デフォルトの名無しさん：2011/08/14(日) 00:23:01.29

>>243
それ違ってるぞ。

最終的に実行したいのは、bar（Cクラス)で定義されたメソッドだよ。

まずCクラスに、
「引数にAクラスが渡された時の処理」
「引数にBクラスが渡された時の処理」を書く
そこがスタート。

あとはその処理を呼び出す方法を書く。

静的言語で実装したらそれがダブルディスパッチになる。

247 ：デフォルトの名無しさん：2011/08/14(日) 00:25:12.63

>>245
結局わざわざget～書く"必要ない"よな

248 ：デフォルトの名無しさん：2011/08/14(日) 00:32:06.68

>>246
いや、>>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が呼ばれる

249 ：デフォルトの名無しさん：2011/08/14(日) 00:34:06.63

BarなのかHooなのか判断したいのはAとBだもんな。

250 ：デフォルトの名無しさん：2011/08/14(日) 00:36:14.73

>>238
動的型でダブルディスパッチの例
言語は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()を呼び出す

251 ：デフォルトの名無しさん：2011/08/14(日) 00:36:50.86

そもそも、型によるオーバーロードは、静的型付け言語の都合で仕方なく用意されてる物だもんな

252 ：デフォルトの名無しさん：2011/08/14(日) 00:36:57.79

>>246
逆にお前の言う静的ダブルディスパッチとやらを見てみたいわ。
今の話だと、単なるオーバーロードにしか見えんし。

253 ：デフォルトの名無しさん：2011/08/14(日) 00:39:44.96

>>250
だから何で自分を渡す必要があんの？わざわざtoStringとか呼び出したりしてさ。

254 ：デフォルトの名無しさん：2011/08/14(日) 00:44:21.75

>>250
def toValue(self, dest):
dest.hiQualityConvert(self,self.num)

def hiQualityConvert(self, num):
self.num = num

これでいいじゃん。

255 ：デフォルトの名無しさん：2011/08/14(日) 00:50:28.36

>>254
srcとdestは常に同じ型の数値情報を持つのか？

256 ：デフォルトの名無しさん：2011/08/14(日) 00:53:54.05

>>255
それを決めてんのは、def hiQualityConvert(self, num):というシグニチャじゃないのかい。
hiQualityConvertはsrcの時でも、srcがどういうメンバーを持っているか全く決めてないのかい？
toStringも失敗する可能性があるって事だよね。

257 ：デフォルトの名無しさん：2011/08/14(日) 00:59:59.37

>>256
静的型言語の視点で動的型言語を語られてもなぁ……

258 ：デフォルトの名無しさん：2011/08/14(日) 01:03:47.86

動的言語だったらtoString()が実装されなくても成功するの？
ダックタイピング可能だったとしても、何を持たなければいけないかルールを決めとくんじゃないのかい？
object.abs()を呼び出す事が解ってんのにabsを持たせることってルール決めないの？

259 ：デフォルトの名無しさん：2011/08/14(日) 01:19:58.28

>>245
なんで渡す側が、intかStringに変換せにゃならんの？
受け取り側は、>>200の例のようなストリームで、文字列とも
数値とも関係ない形式かもしれないのに。

260 ：デフォルトの名無しさん：2011/08/14(日) 01:26:58.91

>>258
基本的に、そういう保証が必要な場合は静的型付け言語を使う。

ObjC には protocol という Java の Interface みたいな仕組みがあるけど、別に強制じゃないし、
respondsToSelector: みたいなリフレクションの機能もあるけど、必須じゃないし、
テストケースを書きまくるという手もあるけど、実際そうするかどうかは人によるし。

静的言語と同じ仕組みを動的言語に求めるのは筋違い。

261 ：デフォルトの名無しさん：2011/08/14(日) 01:37:18.13

>>252
> 逆にお前の言う静的ダブルディスパッチとやらを見てみたいわ。
> 今の話だと、単なるオーバーロードにしか見えんし。

実際やりたいことは単なるオーバーロードだよ。

だけど、静的言語のオーバーロードってのは
静的に呼び出すメソッドが決まるから、
値が動的に決まる場合には使えない。

それを突破する技術がダブルディスパッチなんだよ。
ダブルディスパッチが目的じゃない。
実行時に動的に決まる値でメソッドを切り替えられればいい。
それができない静的言語の欠点から生まれたのがダブルディスパッチ。

動的に決まる型を知ることができるなら不要な技術だよ。
今はリフレクションによって動的に決まる型から
処理を分けることも当たり前になってしまったけどね。
動的な型で判断することが許されるならダブルディスパッチは不要。

262 ：デフォルトの名無しさん：2011/08/14(日) 04:24:44.92

getter派についたほうが（逆境に逆らう的な意味で）面白そうなので
getterのポテンシャルを追求してみた
言語は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

263 ：デフォルトの名無しさん：2011/08/14(日) 04:31:36.33

getter派じゃない人は何派なの？

getterはオブジェクトの状態を
取り出す方法でしょ。
それを否定する意味が分からないんだけど。

264 ：デフォルトの名無しさん：2011/08/14(日) 04:40:50.33

>>263

int 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;

こんなふうに書く流派があるらしい。

265 ：デフォルトの名無しさん：2011/08/14(日) 04:49:05.47

>>264
何のために？

266 ：デフォルトの名無しさん：2011/08/14(日) 04:51:59.32

>>265
しらん。なんかgetterがなくても実装できるって話が
いつの間にか無くす事が目的になってしまって
getter不要原理主義者になったみたい。

267 ：デフォルトの名無しさん：2011/08/14(日) 08:46:55.04

>>263
>>39

268 ：デフォルトの名無しさん：2011/08/14(日) 08:53:19.08

>>266
横から見てたら、おまいらが面白半分で彼を煽って、
細道に追い込んで言ってしまったようにも見えるよｗ

269 ：デフォルトの名無しさん：2011/08/14(日) 08:56:47.04

やっぱりコード出さないと話ができない奴ってレベル低いな
話してるうちに目的とか頭から全部消えてるじゃん
超馬鹿にしかみえないからそこんとこよろしくな！

270 ：デフォルトの名無しさん：2011/08/14(日) 08:58:38.64

そっか、自分じゃレベル高いと思ってるんだね。
まぁ、そんなこったろうと思ったけど。

271 ：デフォルトの名無しさん：2011/08/14(日) 09:00:11.59

結局、コードだけだして何話してるのかわかんなくなっちゃってるのｗ
馬鹿みたい
だいたいなんでオブジェクト指向の話でコードが必要なんだよ
死ね、早く死んじまえ
自害しろ

272 ：デフォルトの名無しさん：2011/08/14(日) 09:54:19.64

死ねってかいちゃったね。
きみのお家に警察来るよ。

273 ：デフォルトの名無しさん：2011/08/14(日) 10:18:48.59

殺すって書いたのたらともかく
死ねで警察動いた事無いってｗ

274 ：デフォルトの名無しさん：2011/08/14(日) 10:23:31.82

いくら盆休みだからって、スレ伸びすぎだろ。
そこまで話し合うような内容か？

当たり前だけど、状況によって使い分ければ良い話ってだけなのに。
Windowsで言えば、ディバイスコンテキストはsetter/getterだし、
ウィンドウ関数ははコールバック方式だし、既に混在している。

コールバックでロックしてもらって、その中でsetter/getterって設計も有りなわけで。

275 ：デフォルトの名無しさん：2011/08/14(日) 10:42:13.22

ぶっちゃけアホを釣って遊んでるだけ

276 ：デフォルトの名無しさん：2011/08/14(日) 10:45:44.11

本人は本気でgetter不要論唱えてるみたいだけどねｗ

277 ：デフォルトの名無しさん：2011/08/14(日) 10:48:49.26

>>276
俺はやっぱり、お前等が彼を追い詰めたんだと思うよｗ

278 ：デフォルトの名無しさん：2011/08/14(日) 10:53:25.26

追いつめられる方が悪い。自業自得ｗ

279 ：デフォルトの名無しさん：2011/08/14(日) 11:04:46.78

>>260
言語的保証以前にある程度決めるだろ。
チームの取り決めとかじゃなくてさ、個人で組んでる時でもさ。
四則演算のあるメソッドにわざわざシーケンス型オブジェクト突っ込んだりすんの？

280 ：デフォルトの名無しさん：2011/08/14(日) 11:09:24.98

>>261
目的の理解はそう離れてないが、
理解の根本がズレてる。
オーバーロード使わんでも結局>>248の書き方になるわけだし、
リフレクションやら仮想関数テーブル以外の具体的な型情報は
一切必要ない。

281 ：デフォルトの名無しさん：2011/08/14(日) 11:12:08.23

>>264
初めて見るコードだな。
前スレにあったの？

282 ：デフォルトの名無しさん：2011/08/14(日) 11:14:50.09

>>263
getterを使うとカプセル化されてるハズの中身がボロっとそとに出るんだけど、
getter派の人は何が何でもそこから目を背けたいんだってさ。

283 ：デフォルトの名無しさん：2011/08/14(日) 11:18:33.61

あと、getter派の人は
戻り値を返さず引数を取るメソッド = setter
戻り値を返す関数 = getter
なんだってさ。
他の人はプロパティーに当たるものをsetter/getterって呼んでるはずなんだけど。

284 ：デフォルトの名無しさん：2011/08/14(日) 11:23:19.95

getterを単なるprivateな属性へのアクセサと取る人と、
操作の一種と取る人が混ざってて、さらにイベントなる物の解釈が
バラバラで話が発散してるだけだろ。

285 ：デフォルトの名無しさん：2011/08/14(日) 11:24:21.87

>>282
ダブルディスパッチではその問題の解決にはならないけどね
switchをどこに押し付けるかだけの違い

286 ：デフォルトの名無しさん：2011/08/14(日) 11:25:31.49

>>282
お前、カプセル化の意味勘違いしてね？
中身を一切出さないのがカプセル化じゃないよ。

出さなくていいものを出さないのがカプセル化であって、
getterはただのインターフェース。
そしてgetterは中身をそのまま出す必要もない。
中身が文字列であるものを、数値に変換して出すのもgetterでいい。

287 ：デフォルトの名無しさん：2011/08/14(日) 11:27:12.94

getterはprivate変数と一対一に
結びついているものって勘違いしているのかｗ

getterの実装を

private int value;
int getValue() {
　　return value;
}

しか知らんのだろうなｗ

288 ：デフォルトの名無しさん：2011/08/14(日) 11:29:40.73

>>286
どのオブジェクトに、どの情報を渡すか判断が外に溢れてんのはどう思ってんだい？
そもそも、カプセル化は人間のためじゃなく拡張性のためだぞ。

289 ：デフォルトの名無しさん：2011/08/14(日) 11:30:26.76

>>280
> オーバーロード使わんでも結局>>248の書き方になるわけだし、
お前、あのコードがややこしいと思わんのか？

一ついいことを教えてあげよう。
同じ事をするのに、説明が必要になるコードは
悪いコードという原則だ。

動的言語では、説明が不要なコードを書くことができる
>>248のようなごちゃごちゃした書き方をする必要がない。

290 ：デフォルトの名無しさん：2011/08/14(日) 11:33:27.60

>>288
> どのオブジェクトに、どの情報を渡すか判断が外に溢れてんのはどう思ってんだい？

漏れてない。

渡す情報は、getterを書いたものだけ。
それ以外の情報は外部に漏れていない。
それがカプセル化。

お前もしかして、private変数全てに
getter書いてるんじゃないかｗ

291 ：デフォルトの名無しさん：2011/08/14(日) 11:35:26.71

>>289
ああ、お前、普通にぐぐれば出てくるようなことも解らなかった
あの馬鹿だったのか。

292 ：デフォルトの名無しさん：2011/08/14(日) 11:37:28.03

>>290
getterに書いたものとかそういう話じゃない。
getterに公開してるものに、内部で持ってりゃ十分のものがあるって事だよ。
特にどのオブジェクトにどういう形式で渡せとかな。

293 ：デフォルトの名無しさん：2011/08/14(日) 11:37:40.49

高機能なgetter/setterというものを知らない人がいるよね。
setterの中に処理を書くと怒り出すｗ

「setterは与えられた引数をprivate変数に格納する」
以外のことをしてはいけないと思っている人。

たとえば、0以上の値しか入れられないsetterってのもあるんだよ。
void setValue(int i) {
　　if(i>=0) {
　　　　value = i;
　　} else {
　　　　例外送出
　　}
}
こうのもあり。

294 ：デフォルトの名無しさん：2011/08/14(日) 11:38:35.94

>>292
> getterに公開してるものに、内部で持ってりゃ十分のものがあるって事だよ。

内部で持っていれば十分だと判断したのなら、
getter書かなければいいだけ。

お前は何を言っているんだ？

295 ：デフォルトの名無しさん：2011/08/14(日) 11:40:05.34

>>293
知らない人は居ないだろう。

296 ：デフォルトの名無しさん：2011/08/14(日) 11:40:19.86

で結局、値の判断まで塞いで無理やりgetterで実装したのが>>245

297 ：デフォルトの名無しさん：2011/08/14(日) 11:40:59.39

>>286
> getterはただのインターフェース。

アンタは聡明。

298 ：デフォルトの名無しさん：2011/08/14(日) 11:41:17.15

>>293
そんな程度の低い話はしてないよ。

299 ：デフォルトの名無しさん：2011/08/14(日) 11:42:48.59

>>291
誰と勘違いしているんだ？

繰り返すが、ダブルディスパッチは目的じゃない
やりたいことは、オーバーロードでしか無い。

静的な型で呼び出すメソッドを決めるオーバーロードではなく、
動的な型に応じて、呼び出すメソッドを決めるオーバーロードだよ。

この2つは静的か動的かの違いしか無いのだから、
本来どちらも同じように呼び出しできるべきもの。
object.method(value);
どちらであってもこの形式で書くのが一番説明が不要になる。

300 ：デフォルトの名無しさん：2011/08/14(日) 11:44:50.23

>>296
getter不要信者は、

ダブルディスパッチの実装でgetterが不要だから、
すべての事象でgetterは不要とか
わけのわからんことを言い出す。

そして、値をgetterを使わずにコールバックで取得するという
>>264のような実装をしてるんだよね。

301 ：デフォルトの名無しさん：2011/08/14(日) 11:46:43.89

>>300
正確に言えば、getterの代わりに
ダブルディスパッチを使うことで代用が可能と
言っているよね。

結論は一緒。

302 ：デフォルトの名無しさん：2011/08/14(日) 11:51:09.98

値を渡すタイミングを渡す側が制御したいというのと、ダブルディスパッチは全く別の問題だろ?
前者の主張が適切な場合は多いが、見境なくダブルディスパッチ使いまくるとか
それこそ拡張性ゼロのクソじゃん

303 ：デフォルトの名無しさん：2011/08/14(日) 11:52:00.04

>>296
>>262

304 ：デフォルトの名無しさん：2011/08/14(日) 11:53:09.75

>>288
どのオブジェクトにも、すべてのpublicメソッドを公開する。
公開したくないpublicメソッドがあるなら、
メソッドを少なくしたインターフェース型へキャストする。

305 ：デフォルトの名無しさん：2011/08/14(日) 11:54:00.32

>>302
そう。別の問題。ダブルディスパッチはメソッド呼び出しまでの話で、
その後getter使って処理を行う～なんことは普通に行われてる。

なのになぜかgetter不要信者がいる。

306 ：デフォルトの名無しさん：2011/08/14(日) 11:59:28.53

ダブルディスパッチが～イベントが～と足掻いてみたところで、
結局のところ最後はgetter使う、つまりgetter必要でFA？

307 ：デフォルトの名無しさん：2011/08/14(日) 12:00:26.30

たとえば、Aというオブジェクトがあって
AはBというオブジェクトにはpublic変数の一部分だけを
見せたいと制限かける場合はどうするの？

あとBというオブジェクトからは使用できるpublicメソッドを
制限したい場合はどうするの？

Aは自分自身が、どのオブジェクトから参照されているかを
知るべきだと思うが。

308 ：デフォルトの名無しさん：2011/08/14(日) 12:02:19.10

>>302
全てダブルデイスパッチで解決するとは言ってない。
getterより効率のいい一手段だ。
substringとかgetterじゃないだろって話は何度も出てるでしょ。

309 ：デフォルトの名無しさん：2011/08/14(日) 12:03:58.34

中身を知りたくても、getterでは教えません。
ただし中身を知りたい場合は、別の方法で教えます。
教える情報はどちらも一緒です。

これはgetterを無くす意味は無いと思うｗ

310 ：デフォルトの名無しさん：2011/08/14(日) 12:05:22.09

>>308
> substringとかgetterじゃないだろって話は何度も出てるでしょ。

じゃあ、substringを使う場面でよく使われる
length()はgetterなの？ getterじゃない？

311 ：デフォルトの名無しさん：2011/08/14(日) 12:06:48.04

その理由は？

312 ：デフォルトの名無しさん：2011/08/14(日) 12:09:50.03

>>264を元にするなら、こういうコードはアリだ。

int value1,value2,value3;
a.sendValue(
function (avalue) {value1 = avalue},
function (avalue1,avalue2) {value2 = avalue1;value3=avalue2}
);

313 ：デフォルトの名無しさん：2011/08/14(日) 12:11:31.12

>>312
だから何なの?
sendValueを呼んでるのが値を受け取る側である以上、実装が違うだけのgetter

314 ：デフォルトの名無しさん：2011/08/14(日) 12:13:58.55

>>309
じゃあprivateメンバーも後で別の形で出てくるんだから
publicのgetterで公開してても一緒だね。

315 ：デフォルトの名無しさん：2011/08/14(日) 12:14:02.65

getter使った方が簡潔に書ける場合もあるのに、
getterだと効率悪い場合があるという理由だけで禁止するなら、
そもそもOOPなんて効率悪いもん使わず全部Cで書けよ馬鹿www

316 ：デフォルトの名無しさん：2011/08/14(日) 12:15:54.36

>>313
別に無名関数の中にがっつり処理書いていいんだぞ。

317 ：デフォルトの名無しさん：2011/08/14(日) 12:16:29.64

そうそう。
コールバック方式は、普通は非同期処理に使うもんだ。
同期処理前提なら、たとえ排他処理処理が必要だったとしても、
Lock→getter/setter→Unlockの方が喜ばれる。

318 ：デフォルトの名無しさん：2011/08/14(日) 12:23:14.70

>>315
このスレで一度もそんなコード見なかったけど？
簡単なのは、メソッド内で完結してる場合だけでメソッド跨がったら
引数で渡せば十分ってのばっかり。

319 ：デフォルトの名無しさん：2011/08/14(日) 12:31:49.45

そもそもだよ、
GUI周りがコールバック方式になってるのは、
GUIがイベントドリブンで非同期処理だから、
「仕方が無く」コールバック方式になってるってだけだよ。
別にダブルディスパッチがしたいわけでも、カプセル化がしたいわけでも無い。
単に非同期って理由でそうなってるだけ。
同期的でgetter/setterで書けるようなものを、
わざわざ非同期で使われるコールバックを持ち出して実装するのは、
乱用でしかない。

320 ：デフォルトの名無しさん：2011/08/14(日) 12:35:57.18

>>307
自分自身がどのように利用されるかを制限したら、再利用の可能性が下がる。
実装を置換できる抽象クラスと同様に、利用者も置換できるようにするのがいい。

321 ：デフォルトの名無しさん：2011/08/14(日) 12:37:42.45

>>318
>>6より>>41の方が簡潔だろ？
お前は「効率が～」の馬鹿のひとつ覚えで否定してるけどな

そしてOCamlだったら効率すら犠牲にせずgetterで書ける件

322 ：デフォルトの名無しさん：2011/08/14(日) 12:37:51.04

>>308
> 全てダブルデイスパッチで解決するとは言ってない。
> getterより効率のいい一手段だ。

ダブルディスパッチを使うのは、実行時の型で処理を
分岐させたいという目的のために使うのであって、
getterの代わりに使うものでも、getterと比較するもんでもねーよ。

323 ：デフォルトの名無しさん：2011/08/14(日) 12:47:09.17

>>317
＞Lock→getter/setter→Unlockの方が喜ばれる。

いや、それはちょっとどーかと・・・

324 ：デフォルトの名無しさん：2011/08/14(日) 12:47:37.28

>>316
> 別に無名関数の中にがっつり処理書いていいんだぞ。

じゃあ、それでいいから、
元々の例、

int sum = a.getValue() + b.getValue();

をgetter使わずに、無名関数を使って
これよりもシンプルに、書いてくれよ。

当たり前だがaとbの値を使って
最終的な答えはsum変数に入れること。

325 ：デフォルトの名無しさん：2011/08/14(日) 12:51:29.74

お前等がOOPよりさきに徹底すべきはKISSだったようだな。

326 ：デフォルトの名無しさん：2011/08/14(日) 13:10:23.56

>>324
intで受けとらにゃならんの？
オブジェクトで受け取りやいいのに。

327 ：デフォルトの名無しさん：2011/08/14(日) 13:12:54.57

>>326
> intで受けとらにゃならんの？
はい、それが仕様です。

で、答えは？

328 ：デフォルトの名無しさん：2011/08/14(日) 13:27:02.64

要は、OOPと無関係な代入文やswitch文の存在が許せないんだな

329 ：デフォルトの名無しさん：2011/08/14(日) 13:38:57.99

lambda があれば let は要らないもん！（ローカル変数は引数渡しに出来るから・・・）

の一種かな

callback があれば getter は要らないもん！（変数は引数渡しで取得出来るから・・・）

みたいな

330 ：デフォルトの名無しさん：2011/08/14(日) 13:39:25.70

データの表現の隠蔽に固執するあまり、ダブルディスパッチに頼り
結果的に拡張性を下げている

331 ：デフォルトの名無しさん：2011/08/14(日) 13:46:19.43

>>327
int sum = a+b;

わざわざgetterで取り出す必要がない。

332 ：デフォルトの名無しさん：2011/08/14(日) 13:48:01.17

>>331
じゃあダブルディスパッチいらないってことになるなｗ

333 ：デフォルトの名無しさん：2011/08/14(日) 14:19:18.04

>>332
外の話しでしょ。
単にオブジェクトの中で完結する事をわざわざgetter何かで
出仕入れする必要がない。

334 ：デフォルトの名無しさん：2011/08/14(日) 14:22:16.54

>>333
オブジェクトの中で完結しないだろ。
なんでクラスAとクラスBが
int型に変更されてるんだ。

それに、getValue()にしか使えないだろ。
クラスAはgetValue1とgetValue2、
クラスBはgetLengthを持ってましたー。

a+bはなんになるでしょーか。

335 ：デフォルトの名無しさん：2011/08/14(日) 14:23:33.41

そういやlengthといえば、>>310-311の
質問には答えずに逃げたんだっけなｗ

336 ：デフォルトの名無しさん：2011/08/14(日) 17:16:53.91

だから>>39だっての

無駄にコードなんか出すからこんなややこしくなってんだろ

337 ：デフォルトの名無しさん：2011/08/14(日) 17:25:46.76

このスレは、プログラム板の中でC言語なら俺に聞けスレと同じくらい圧倒的な勢いだなｗ

338 ：デフォルトの名無しさん：2011/08/14(日) 17:30:50.77

ややこしくなっているのは、getter不要厨がいるせいだろ。
あいつさえ消えれば平和になる。
世界が。

339 ：デフォルトの名無しさん：2011/08/14(日) 17:31:58.29

>>336
コードを出しちゃうと実現不可能な妄想だったり
迂遠なコードになったりすることがバレちゃうもんね

340 ：デフォルトの名無しさん：2011/08/14(日) 17:33:37.51

俺もgetter不要派だけどコード出してる奴は馬鹿に見える

getter不要っつってもなんも考え無しに自動生成したgetterが不要って話で
ちゃんと考えてるならこの限りではないけどね
でも大抵のコードでとりあえずつけとけ的なもんだから
発言がややこしくなるのでgetter全廃派でいいです的な立場

オブジェクトの関連相手もわからないのにイベント作成してんのはおかしいよ

341 ：デフォルトの名無しさん：2011/08/14(日) 17:36:19.31

> 俺もgetter不要派だけどコード出してる奴は馬鹿に見える
>
> getter不要っつってもなんも考え無しに自動生成したgetterが不要って話で

それはgetter不要派ではない。

getter不要派は、どんな場合でもgetter使うなと言っている馬鹿のこと。
その反対は、絶対getterを作る派ではなく、
内部で使うだけのものと、外部に提供するものを見極め
ただしい設計をするもののこと。

342 ：デフォルトの名無しさん：2011/08/14(日) 17:38:58.60

でもこの一連の流れの一番最初にsetter、getterなんて作ってる奴は馬鹿って言い出したの俺なんだよねｗ
だから一番最初のsetter、getter不要発言をどうにかしたいなら俺の発言を理解してほしいんだけど

別にそうでなくてただ派生種が嫌いってだけならそれだけでいいんだけどｗ

343 ：デフォルトの名無しさん：2011/08/14(日) 17:42:51.53

いや、getter不要って言い出したのは俺なんだけど？
偽物は黙っててくれないかな。

344 ：デフォルトの名無しさん：2011/08/14(日) 18:43:22.34

>オブジェクトの関連相手もわからないのにイベント作成してんのはおかしいよ

intの関連の相手なんて分からない。
Stringの関連の相手なんて分からない。
ただの部品が、自身がどう使われるかなんて知る必要ない。
クラス間は疎結合で有った方が良い。
疎結合なクラス間を埋めるのがコードであり、それがプログラマの仕事。

Observerパターンやコールバックが使われることもある。
が、これらは非同期処理のために使われるのであって、
カプセル化のために使われる訳ではない。
ハンドラに手続きが分断されるのが一番迷惑なわけで、
可能な限りgetter/setterの方が良い。疎結合になるし、読みやすい。
排他処理が必要なら、lock getter/setter unlock なんて手もある。
煩雑に思えるかもしれないが、コールバックよりマシ。
とにかく可能な限りコールバックを少なくすることが良い設計への第一歩。

345 ：デフォルトの名無しさん：2011/08/14(日) 18:46:51.59

どこぞの馬鹿にgetterはカプセル化を破壊するとか
習ったんだろｗ　バカ量産大学ｗｗｗ

346 ：デフォルトの名無しさん：2011/08/14(日) 19:01:32.33

少ないインタフェース、小さいインタフェースであればいいのであって、
その際アクセッサ相当のメソッドがあるかどうかは問題にもならない。

347 ：デフォルトの名無しさん：2011/08/14(日) 22:48:11.39

>>345
既に受け渡し側の判断が外に漏れ出してるって何度も書いてあるじゃん。
getter派がコード出せっていうからわざわざコードまでだしてさ。

348 ：デフォルトの名無しさん：2011/08/14(日) 22:57:13.01

つか合計求めるだけだったら、
ACM acm = new ACM();
for( Numeric i : list ) i >> acm;
return acm;
こんなんでいいだろ。

349 ：デフォルトの名無しさん：2011/08/14(日) 23:07:56.43

コールバックコールバック言ってるやつってアクセサはコールバックじゃないと思ってんのかな？
そもそもメッセージとメソッドの仕組み自体がコールバックなのに。

350 ：デフォルトの名無しさん：2011/08/14(日) 23:10:24.57

>>349
じゃあ、素直にgetterが何の問題もないと認めろよｗ

getterがコールバックだというのなら、
getterではなくコールバックを使うべきだという主張は
意味がいないだろｗ

351 ：デフォルトの名無しさん：2011/08/14(日) 23:13:32.86

>>349
非同期処理ってわかる?
source.beginDownloadData(function(data) { GUIに反映(data); });
こういうコールバックは大いに意味があるしgetterや同期的なダブルディスパッチとは全く違う

352 ：デフォルトの名無しさん：2011/08/14(日) 23:14:14.85

>>350
コールバックを使えとは一言もいってない。お前等がコールバックいってるだけだろ。
勝手にレッテルはんなよ。他の意見は、引数で渡すがベースだろうが。

353 ：デフォルトの名無しさん：2011/08/14(日) 23:15:10.56

>>347
> 既に受け渡し側の判断が外に漏れ出してるって何度も書いてあるじゃん。
意味不明

なんの話かわからないし、意味不明だから
それがいけないことだと判断ができん。

354 ：デフォルトの名無しさん：2011/08/14(日) 23:16:56.37

>>350
渡す側のオブジェクトの判断基準についてgetterは漏らすかもみ消すかしかできないことに
何も答えが出てないんだけど。

355 ：デフォルトの名無しさん：2011/08/14(日) 23:17:42.96

>>334
そもそも制約からして同じ土台じゃないしな。

356 ：デフォルトの名無しさん：2011/08/14(日) 23:22:18.03

>>354
> 渡す側のオブジェクトの判断基準についてgetterは漏らすかもみ消すかしかできないことに

やっぱり意味不明だな。
漏らすかもみ消すか？

それはprivateかpublicかってことか？
getterなんてメソッドと一緒なんだから、protectedとか
メソッドで付けられるスコープは何でも付けられるが
お前はそれ以外の何を付けたいのだ？

357 ：デフォルトの名無しさん：2011/08/14(日) 23:22:21.96

>>310
はいはい、getterです。OO嫌いのSTL作者が、C言語から引っ張ってきたgetterですよ。
これで満足？そもそも、C++や最近のJavaじゃ、lengthより、イテレーター使えってのが常識じゃん。
Rubyだってイテレーション機能持って登場してるし。

358 ：デフォルトの名無しさん：2011/08/14(日) 23:24:07.38

> lengthより、イテレーター

この二つは用途が違う。

lengthは長さを知りたい時に使う。
イテレータは一文字づつ見ていくときに使う。

長さを知りたい時にイテレータを使って一文字づつ
文字を数えるのか？
遅くなるだけだろｗ

359 ：デフォルトの名無しさん：2011/08/14(日) 23:24:26.99

>>356
どのメソッドをオブジェクトが選ぶかは、メソッドを選ぶオブジェクトが知ってればいい。
プログラマーも知っているべきではあるが、そのオブジェクトを使用するクラスやメソッドが
知っているべきではない。

360 ：デフォルトの名無しさん：2011/08/14(日) 23:25:11.10

>>357
C++やJavaのイテレータは、値を受ける側が操作するgetter的な方式だぞ?
コールバック派なら違いを理解してRubyのイテレータを信奉しないとw

361 ：デフォルトの名無しさん：2011/08/14(日) 23:25:36.80

>>358
長さを知る必要がある場合がまず無いだろ。
ストリーミングデータで長さの取得はできないが、
固定長のデータとストリーミングデータは長さが解らなくても同等に扱える。

362 ：デフォルトの名無しさん：2011/08/14(日) 23:25:50.70

>>359
だから意味不明だって。

「どのメソッドをオブジェクトが選ぶ」って何だよ。
「メソッドを選ぶオブジェクト」って何だよ。
ちゃんと具体的に説明しろ。

363 ：デフォルトの名無しさん：2011/08/14(日) 23:26:58.08

>>361
> 長さを知る必要がある場合がまず無いだろ。

は？ 100文字以上なら省略して、後ろに…をつける
とかあるだろ。

一秒で思いつたぞｗ

364 ：デフォルトの名無しさん：2011/08/14(日) 23:27:55.38

>>360
あれはgetterとして使用できないし、
状態変異も起こす一応参照の部類。
俺や、言語開発者側はプロパティとして見ては居ない。

365 ：デフォルトの名無しさん：2011/08/14(日) 23:27:55.91

50文字までしか入力できません。とか

366 ：デフォルトの名無しさん：2011/08/14(日) 23:29:21.00

長さの制限なんて、普通lengthで決めることないだろ。
入力メソッドで指定すんじゃん。

367 ：デフォルトの名無しさん：2011/08/14(日) 23:32:52.10

>>366
HTMLのinputタグでどうやって入力メソッドで制限するんだ？
クライアント側の入力チェックは、簡単に制限解除できるって知らんのか？

368 ：デフォルトの名無しさん：2011/08/14(日) 23:33:32.99

>>366
長さ制限はありません。
長すぎたら…で表示するんですよ？

369 ：デフォルトの名無しさん：2011/08/14(日) 23:35:14.60

書き込み先もそうだよな。大抵の場合書きだす長さを指定するようになってる。
JavaのOutputStreamだってwrite(byte[] b, int off, int len)ってのを持ってるし、
C++だってiostreamのマニュピレーターstd::setw(これ自体一種のオブジェクト)で指定するようになってる。

370 ：デフォルトの名無しさん：2011/08/14(日) 23:35:23.87

getterの代わりにコールバックを使えとか
lengthの代わりにイテレータを使えとか
こいつは実践経験ないんだろうなｗ

同じことができるのなら、
複雑になってもいいと思ってらっしゃる。

ソースコードの読みやすさ、
シンプルの書くことに重要さをわかっていない。

KISSってしってる？チュウじゃないよｗ

371 ：デフォルトの名無しさん：2011/08/14(日) 23:35:29.94

>>364
元のコレクションが変更されたらイテレータが無効になるっていうのは
さんざんアンチgetterが主張してきた問題と同じじゃないの?
コールバック式のイテレーションなら少なくともシングルスレッドの範囲では安全だよ

372 ：デフォルトの名無しさん：2011/08/14(日) 23:38:18.14

>>368
表示側に任せることじゃん。
大抵、lengthじゃなく反復が指定位置で止まったら"・・・"を付けるだけ。
まぁ君がlengthで判断してんのは知らんけど。

373 ：デフォルトの名無しさん：2011/08/14(日) 23:39:14.38

> 表示側に任せることじゃん。

表示側にもコードはあんだろｗ

374 ：デフォルトの名無しさん：2011/08/14(日) 23:40:43.99

>>371
スレッドの話はイベントの人でしょ。こっちに振るなよ。
そもそも、こっちは非同期が重要じゃないって言ってんだし、
そっちで話を広げたこともない。

375 ：デフォルトの名無しさん：2011/08/14(日) 23:41:43.74

>>373
>大抵、lengthじゃなく反復が指定位置で止まったら"・・・"を付けるだけ。

376 ：デフォルトの名無しさん：2011/08/14(日) 23:44:10.00

実戦経験がないと一文字づつ数えるのと
lengthを使うのが全く一緒だと考える。

机上の空論ではそうかもしれないが、
文字列というのは一文字が何バイトかわからない
だから文字列を構成するバイト列を眺めて行かないといけない。
それは時間がかかる。

だから文字の長さを情報をとして別で持っておく。
lengthはその情報を返すだけだから高速になる。

こういう考えは実戦経験を積んでいないと
わからないだろうね。

377 ：デフォルトの名無しさん：2011/08/14(日) 23:44:35.00

なんでgetter厨は勝手に世界を広げるかな。

・ブロードキャスター君
・コールバック君
・非同期

目の前の話からひたすら目を背けないと困る何かがあるのか？

378 ：デフォルトの名無しさん：2011/08/14(日) 23:45:53.10

目の前の話を別の話にして言ってるのはgetter不要信者だろｗ

getterはgetter。なのに違うもので実装しろと、
用途が違うものの話をし始める。

379 ：デフォルトの名無しさん：2011/08/14(日) 23:47:06.08

上からgetterを許さない度合いが強い順に並べてみた

ダブルディスパッチ、コールバックで解決できるよ派
ただフィールドの値を取得するだけのgetterは許さないよ派
getter -> 処理 -> setterこんな処理するなら最初から内部で処理しろよ派
lock getter/setter unlockも許しちゃうよ派
無意味にフィールドに全部getterつけるのは許さないよ派

番外
もうディスパッチくんが何を言いたいのかわからなくなってきた派

380 ：デフォルトの名無しさん：2011/08/14(日) 23:47:18.02

>>376
そういう問題じゃないだろ。
表示の制限をする以上コピーだし、
元のlengthの長さを出力するわけじゃないから全くlengthが必要ない。
指定の文字で切ってなにかするぐらいだったら、substring呼び出して、
指定の位置で切って"・・・"つけたり修飾したりする。

381 ：デフォルトの名無しさん：2011/08/14(日) 23:48:56.64

>>378
じゃなんで変なレッテル貼ってそっちで話を進めようとするんだい？
setter/getterでも同じで問題になってないコールバックとか強調してさ。

382 ：デフォルトの名無しさん：2011/08/14(日) 23:49:13.24

getter不要信者は本当にgetterを一切使用しない(フィールドの値を一切外部から取得しない)でプログラムを書いているのだろうか・・・
絶対一緒に開発したくないな

383 ：デフォルトの名無しさん：2011/08/14(日) 23:52:00.54

>>382
どこぞの嘔吐CADライブラリとか使えないだろうね。
オブジェクトをセットしとけば次々と図形と数値を分解して放り込んでくれる。
更に、補助のオブジェクトを放り込んでやれば、さらにレイヤーやら周辺処理までやってくれる。
そういうライブラリ任せの処理は絶対無理だろう。

384 ：デフォルトの名無しさん：2011/08/14(日) 23:52:17.98

>>380
じゃあ、文字数制限はどうするんだよ。
HTMLのINPUTタグにmaxlengthつけたとしても
それは簡単に書き換えられるから
クライアント側おくられてくる文字なんて制限できない。
サーバー側で制限する必要があるからな。

385 ：デフォルトの名無しさん：2011/08/14(日) 23:56:02.37

>>384
バリデーターに任せれば？
あと、そもそも、StrutsとかJavaは知らんけど、普通サーバーにおくられてくる文字数は不定だから、
どのみちパースと一緒にチェックしてエラーを出す仕組みがある。

386 ：デフォルトの名無しさん：2011/08/14(日) 23:56:37.62

>>380
> 元のlengthの長さを出力するわけじゃないから全くlengthが必要ない。
> 指定の文字で切ってなにかするぐらいだったら、substring呼び出して、
> 指定の位置で切って"・・・"つけたり修飾したりする。

それが必要あるんだよ。

100文字まで普通に表示、
100文字を超えたら後ろに…をつける。

じゃあ、文字列がちょうど100文字だったら？
substringで100文字で切る。
そうだね。でも後ろに・・・をつけてはダメだよ。

ちゃんと元の文字列が100文字を超えるかlength使って確かめないとね！

387 ：デフォルトの名無しさん：2011/08/14(日) 23:57:41.62

>>385
> バリデーターに任せれば？
そのバリデータで使ってるだろ・・・

自分が作ってないものは知りません。
それは神様が用意してくれたものです。
とか思ってるのかな？

388 ：デフォルトの名無しさん：2011/08/15(月) 00:00:57.56

>>387
残念ながらバイト数にも対応するためlengthは使ってないんだってさ。

389 ：デフォルトの名無しさん：2011/08/15(月) 00:01:12.15

> 長さを知る必要がある場合がまず無いだろ。
> 長さを知る必要がある場合がまず無いだろ。
> 長さを知る必要がある場合がまず無いだろ。

わろたｗ

すごいな。文字列の長さを知る必要がある場合がないとか。

390 ：デフォルトの名無しさん：2011/08/15(月) 00:02:01.71

>>388
lengthはバイト数ではなく
文字数を意味します。

って普通だけど？

実戦経験（ｒｙ

391 ：デフォルトの名無しさん：2011/08/15(月) 00:09:55.93

>>389
イテレータ回しながら文字数数えるから要らないんだってさ。
それもコールバック方式でイテレートするらしい。
void callback( iterator *itr ){ ～～ }
foreach( list, callback );

C++やJavaだとローカル変数を持ち越せないから
本来ならローカル変数で済むはずのものまでメンバ変数になってグチャグチャ。
こんなんならgetter/setterの方がマシだ。

392 ：デフォルトの名無しさん：2011/08/15(月) 00:12:40.07

ここまでの議論で出てきたgetter不要論をすべて採用して
なんか作ったら面白そうだな

393 ：デフォルトの名無しさん：2011/08/15(月) 00:13:27.28

>>391
コールバック厨は帰れよ。

394 ：デフォルトの名無しさん：2011/08/15(月) 00:14:33.10

ここのgetter不要派がエディタやワードプロセッサ作ったら
文字数カウントさせるたびにイテレータが走る（キャッシュしない）、ってことまでは分かったwww

395 ：デフォルトの名無しさん：2011/08/15(月) 00:17:16.09

>>394
キャッシュはするよ。

ただし文字列オブジェクトのキャッシュは使わず
文字列を使う側でキャッシュするんだ（笑）

396 ：デフォルトの名無しさん：2011/08/15(月) 00:17:53.49

>>386
どうしても厳密にやりたいなら、substringもコピーするだけ無駄だし、
文字を転写するさいに101文字に達したら"・・・"と出力するUIにすりゃいいじゃねぇか。
WinAPIやらCocoaのUIと同じように。

397 ：デフォルトの名無しさん：2011/08/15(月) 00:19:05.83

>>394
iteratorが最後の長さ持ってるだろ。
end() - begin()でもとれんことはないけど、それは重要じゃないし。

398 ：デフォルトの名無しさん：2011/08/15(月) 00:19:47.55

>>396
なんの話してんの？
ずれてるよね。

399 ：デフォルトの名無しさん：2011/08/15(月) 00:22:03.12

>>397
文字列が変更されてたら再イテレーション、そうじゃなかったら
キャッシュしたデータを使うってのを「文字列を使う側」が判断するの？

400 ：デフォルトの名無しさん：2011/08/15(月) 00:30:25.58

GUIプログラミングの煩雑さは、
イベントドリブンによる非同期なハンドラの呼び出しによる、
コードの分散によるもの、ってのは殆どの人が納得するところなのに、
それと同じ仕組みを必要も無いのにプログラム全体にまで蔓延させようとする意味が分からない。
getter/setterで済むのなら、そっちのがいいわな。
ObserberパターンだのMVCだのイベントハンドラだのWM_だの、別に好きでやってる訳ではない。
イベントドリブンで非同期だから仕方なくやってるだけ。
必要も無いのにマネようとするのは、それの目的が何なのか、
今の自分にとって必要なのかどうか、の判断が出来ない子供のすること。

401 ：デフォルトの名無しさん：2011/08/15(月) 00:30:50.95

>>390
DBはUTF-8ならそのまま入ることはあるけど、
そうじゃない場合があってね。結局、CGIのenvから
バイトストリームで受け取るときバイト数と文字数を調べて、
文字数かバイト数のどっちかが指定してあったら、
オーバーしたほうでエラーを返すってのがあるんだよ。
Maxbytelengthとかね。

402 ：デフォルトの名無しさん：2011/08/15(月) 00:32:47.43

>>399
変更もクソも、新しいiterator渡されない限り更新出来んだろ。
大体、ストリームデータと共存できないだろ。まぁ、世の中length固定で
共存できないソフトが多いけどな。

403 ：デフォルトの名無しさん：2011/08/15(月) 00:34:00.07

>>400
getterもsetterもコールバック。イベントの話がしたいなら後でしろ。ややこしくなる。

404 ：デフォルトの名無しさん：2011/08/15(月) 00:35:00.22

>>401
それで？
DBはUTF-8のまま入るんだよね？

405 ：デフォルトの名無しさん：2011/08/15(月) 00:35:36.86

>>403
お前は頭が悪すぎるから引っ込んでろ。

406 ：デフォルトの名無しさん：2011/08/15(月) 00:37:50.93

>>404
UTF-8で入らないDBが腐るほどあるからバイト数の仕組みがあるだけで、DB自体はどうでもいいだろ。

407 ：デフォルトの名無しさん：2011/08/15(月) 00:38:50.16

入らないってのはDBがって事じゃなく昔からSJIS使ってたからとかそういう問題な。

408 ：デフォルトの名無しさん：2011/08/15(月) 00:38:52.12

> UTF-8で入らないDBが腐るほどあるから
聞いたことないわー。最近のDBで聞いたことないわー

409 ：デフォルトの名無しさん：2011/08/15(月) 00:43:18.45

>>405
あんたが勝手にイベントドリブンの話持ち出してんじゃん。
アダプターパターンとか、ダブルディスパッチとかコマンドパターンとか
別にイベントドリブンの為のパターンでもないし。

410 ：デフォルトの名無しさん：2011/08/15(月) 00:47:54.75

>>409
イベントドリブンじゃなくて非同期処理な。
アダプターパターン、ダブルディスパッチ、はともかくとしても、コマンドパターンは非同期処理だし。

411 ：デフォルトの名無しさん：2011/08/15(月) 00:48:19.46

現場経験があれば有るほど、EUC使ってるからとか、SJISつかってるからとかっていう理由で
バイト単位で文字数制限させられたことは有りますよね。UTF-8対応なんて出てきたのはつい最近の事ですし。
ねぇ >>390 さん

412 ：デフォルトの名無しさん：2011/08/15(月) 00:52:01.28

>>390
え？ UTF-8が最近？
10年前ぐらいで止まってるのか？

413 ：デフォルトの名無しさん：2011/08/15(月) 00:53:06.91

>>412

414 ：デフォルトの名無しさん：2011/08/15(月) 00:56:08.60

今時EUCとかSJISとか、どこの弱小ウェブ制作会社だよｗ
少なくとも内部はUTF-8だって。

415 ：デフォルトの名無しさん：2011/08/15(月) 00:58:20.08

>>410
>アダプターパターン、ダブルディスパッチ、はともかくとしても
じゃ元々非同期処理の話は関係ないじゃん。
コマンドパターンは、イベントと関係ないものの代表格として今引っ張り出しただけだし。

416 ：デフォルトの名無しさん：2011/08/15(月) 01:01:18.70

>>414
Web制作会社ならそうだろうね。
企業相手だと10年以上前のDBデータを
ガワだけ変えながらエンコードも変えずに
維持してんのは大量にある。
某フジ配下のコンテンツ配給会社だってそうだし、
某研究所だってそうだった。

417 ：デフォルトの名無しさん：2011/08/15(月) 01:07:05.49

>>416
それで？
お前は何を言いたいんだ？

418 ：デフォルトの名無しさん：2011/08/15(月) 01:11:07.55

エンコーディングの移行の難しさも知らんヤツが書き込んでんのか。
やっぱりろくに業務経験のないヤツが多いんだな。
普通他のシステムがエンコーディング決め打ちとかしてるから、
やすやすと移行できるなんてことはまず無いんだけど、やっぱ学生が多いのか？
それとも派遣だらけとか？

419 ：デフォルトの名無しさん：2011/08/15(月) 01:11:56.03

>>418
だからなんでエンコーディングの話になってるのさｗ
話しそらしすぎだろ。
getterの話に戻れよ。lengthがなんだって？

420 ：デフォルトの名無しさん：2011/08/15(月) 01:16:57.20

>>419
lengthの話は終わったろ。lengthの話ししてたヤツも結局エンコーディングはUTF-8だけだと
思ってる自称実務経験者だったし。

421 ：デフォルトの名無しさん：2011/08/15(月) 01:17:02.34

>>415
非同期処理で行われるようなコードの分散はなるべく避けるべき。
可能な限りgetter/setterを用いて、流れを分断せずに記述できる方が好ましい。
そういう主張。

422 ：デフォルトの名無しさん：2011/08/15(月) 01:18:38.48

>>421
非同期の処理なんて出てきてないでしょ。出たのはイベントの人と、MVCの時ぐらい。

423 ：デフォルトの名無しさん：2011/08/15(月) 01:24:56.38

>>420
lengthの話は終わった？

じゃあ結論はどうなったのさ。

> 長さを知る必要がある場合がまず無いだろ。

この答えはどうなったのさ

424 ：デフォルトの名無しさん：2011/08/15(月) 01:26:03.34

>>422
>非同期の処理なんて出てきてないでしょ。

まさにそのとおり。
非同期の処理でもないのに、非同期の処理で行われるようなコードの分散は避けるべき。
非同期でないなら、getter/setterで十分。
余程のことが無い限り、手続きの流れが分断する方が迷惑。

え？ダブルディスパッチ？
実際にはあまり使われないでしょ。
それは、殆どの人が出来ることの割りにコードが複雑になると感じているから。
総合的な判断で、あまり採用されない。

425 ：デフォルトの名無しさん：2011/08/15(月) 01:26:38.62

>>422
あと、getter不要、こんなコードを書くとか言っていた馬鹿もいたなｗ

int value1,value2,value3;
a.sendValue(
function (avalue) {value1 = avalue},
function (avalue1,avalue2) {value2 = avalue1;value3=avalue2}
);

426 ：デフォルトの名無しさん：2011/08/15(月) 01:28:31.24

ダブルディスパッチに関しては、
目的に対して手段が全く違っていた馬鹿だったよな。

ダブルディスパッチは静的言語で動的に決まる型で
オーバーロードしたい時に使うテクニック。

それをｗなに？ｗ getterのかわりに使うって？ｗｗｗｗ
腹痛いわｗｗｗｗ病院行こうぜｗｗｗｗ

427 ：デフォルトの名無しさん：2011/08/15(月) 01:30:27.15

KISS

シンプルにしておけよ馬鹿野郎。　の略

getterが必要なら、getterを使えよ馬鹿野郎ｗ

そういや、メソッドをオブジェクトが選ぶとかいう
話はどうなったんだ？ｗ

428 ：デフォルトの名無しさん：2011/08/15(月) 01:33:12.26

>>424
君の世界はそうだろうしそうでいいんじゃない？
世の中、CADのベンダーライブラリやポスプロツールを作るときの
ライブラリなんかバリバリ出てくるから。だいたいライブラリの中央に
オブジェクトのDBが有るんだけど。そこで扱われる個々のオブジェクト情報を
ダブルディスパッチやアダプターで隠蔽してキャストとか一切メソッドに見えないようにしてる。

429 ：デフォルトの名無しさん：2011/08/15(月) 01:34:23.97

というやり方を使っている部分があるってだけで、
getter不要にはならない。事実どんなものでもgetterは使われてる。

論破完了ｗ

430 ：デフォルトの名無しさん：2011/08/15(月) 01:36:03.94

>>425
結局valueで返してるからおかしいんだろ
var object;
a.sendValue(
function (avalue) { object.methodA(avalue);},
function (avalue1,avalue2) {object.methodB(avalue2);object.methodC("キー",avalue2)}
);
return object;

だと別に変でもないし。普通の無名関数の使い方。

431 ：デフォルトの名無しさん：2011/08/15(月) 01:37:40.69

> だと別に変でもないし。

え？変だろｗ

432 ：デフォルトの名無しさん：2011/08/15(月) 01:38:25.00

>>429
今使ってるものがいらないといってるんだけど。論破して満足ならどうぞ。

おんなじように、
黒電話は事実どんなところでも使われてる。
論破完了。1990年代にそれを言いたければ言えばいい。

433 ：デフォルトの名無しさん：2011/08/15(月) 01:39:28.20

>>431
lispも変ですね。C++のalgorithmも変ですね。Rubyのイテレーターも変ですね。

434 ：デフォルトの名無しさん：2011/08/15(月) 01:39:49.55

つまり

俺のいた未来では
今使っているものがいらない世界なのだ。

ってこと？

435 ：デフォルトの名無しさん：2011/08/15(月) 01:40:53.29

>>433
getterですむところを
シンプルにしないで複雑にしているのが変と言っているのであって
イテレータを否定しているわけじゃないよ。

適材適所って知ってる？

KISSって知ってる？

436 ：デフォルトの名無しさん：2011/08/15(月) 01:42:19.70

>>434
国語ができないの？「1990年代に居た時にそういえば良かったろ」とでも言い直してほしいの。
色々考えはあるだろうが、これからも別に要らんといってるだけ。俺の考えが携帯電話になるか
ポケベルになってるかはどうでもいい。

437 ：デフォルトの名無しさん：2011/08/15(月) 01:45:37.72

お前の考えはポケベルだよ。
だからそれをみんなして否定してる。

438 ：デフォルトの名無しさん：2011/08/15(月) 01:46:27.49

>>435
アレがKISSに反してると？わざわざ関数の戻り値を使って処理を分岐せずに、
関数に呼び出す処理を選ばせてることが？

439 ：デフォルトの名無しさん：2011/08/15(月) 01:47:08.83

反してますね。

まずそのように説明が必要な時点で
シンプルではないという証拠

440 ：デフォルトの名無しさん：2011/08/15(月) 01:48:18.23

それはあんたが見慣れてないだけだろ、lispとかどうすんだよ。

441 ：デフォルトの名無しさん：2011/08/15(月) 01:49:31.78

>>439
smalltalkもアウトだな。isTrue:とisFalseの引数は処理ブロックだし。

442 ：デフォルトの名無しさん：2011/08/15(月) 01:50:18.18

lispですか？関数型言語ですから
オブジェクトからgetterで取得した値を引数にして
別の関数を呼び出しますよ。

443 ：デフォルトの名無しさん：2011/08/15(月) 01:55:40.26

lispの分岐は引数に処理のリストを受け取って分岐するんだけど。
関数型言語だから処理を引数でとるのは当然ですよね。

444 ：デフォルトの名無しさん：2011/08/15(月) 01:56:51.55

あ、getterが関数であることをご存じない？

445 ：デフォルトの名無しさん：2011/08/15(月) 01:57:25.10

haskelなんて呼び出す関数切り替えて分岐してるしな。

446 ：デフォルトの名無しさん：2011/08/15(月) 01:58:06.88

>>443
分岐の場合はそうでも、分岐以外はどうなんだ？
それとも、全部分岐で書くか？

発想が、getterをダブルディスパッチでかけるからと言って
全部ダブルディスパッチで書いて複雑する馬鹿と同じだぞｗ

447 ：デフォルトの名無しさん：2011/08/15(月) 01:59:06.56

頭が悪いんで、ひとつのやり方を知ったら
全部それでやろうとする。

448 ：デフォルトの名無しさん：2011/08/15(月) 01:59:34.90

>>444
お前lisp知らんだろ。
COLSだって知らないっぽいし。

449 ：デフォルトの名無しさん：2011/08/15(月) 02:01:52.23

CPUの基本は、ロード→演算→ストア　なので、
シンプルを追求するなら、これに習う必要がある。
それだけでは厳しい場合に、色々な技法を駆使する。
だけど、それらを駆使する必要の無い場合は、
ロード→演算→ストア　つまり、　getter→演算→setter　がシンプルでよい。
getter/setterはコンピューティングの基本であるが故、プログラミングとよく馴染む。
ゆえに不滅である。

450 ：デフォルトの名無しさん：2011/08/15(月) 02:02:33.01

>>448
それは反論ではないよ。

451 ：デフォルトの名無しさん：2011/08/15(月) 02:04:07.74

>>446
ダブルデイスパッチ自体はオブジェクト間の通信方法。
何度も言うがsubstringやらreadやらは使うし。

452 ：デフォルトの名無しさん：2011/08/15(月) 02:06:18.98

> ダブルデイスパッチ自体はオブジェクト間の通信方法。

動的な型でオーバーロードをしたい時に使われる通信方法。
通信すべてに適した方法ではない。

適材適所。

453 ：デフォルトの名無しさん：2011/08/15(月) 02:06:40.06

>>449
だったら関数が一番真っ当だろ
出力=処理(入力)

454 ：デフォルトの名無しさん：2011/08/15(月) 02:08:14.95

getterも関数の一種だけどなｗ

455 ：デフォルトの名無しさん：2011/08/15(月) 02:10:39.14

>>450
CLOSじゃgetterなんてほとんど使わない。
物好きが使ってるかも知れないけど。

456 ：デフォルトの名無しさん：2011/08/15(月) 02:12:38.35

頭が悪いんで、ひとつのやり方を知ったら
全部それでやろうとする。

CLOSを知ったら（以下同文

457 ：デフォルトの名無しさん：2011/08/15(月) 02:13:14.55

頭が固い人って
どんな職業なんだろうねｗ

458 ：デフォルトの名無しさん：2011/08/15(月) 02:13:21.50

>>454
はいはい全ての関数はgetterなんですよね。
ちなみにさっきの関数だけど、
出力.処理(入力)でも完結できる話し。

459 ：デフォルトの名無しさん：2011/08/15(月) 02:15:21.26

getterは関数の一種

↓ バカフィルターを通すとこうなるらしい。

全ての関数はgetter

460 ：デフォルトの名無しさん：2011/08/15(月) 02:15:30.82

これはもうイジメの域なんだけど、そろそろこの話も終わりにしていいと思うので。

a.set( a.get() + b.get() + c.get() + d.get() );

これと同じ処理をgetter/setter使わずにどう書く？

461 ：デフォルトの名無しさん：2011/08/15(月) 02:18:12.03

>>348 のことを今さら書かれてもなぁ。

462 ：デフォルトの名無しさん：2011/08/15(月) 02:20:02.84

どうせ仕様変えてくるぞｗ
釘を差しておかないとな。

463 ：デフォルトの名無しさん：2011/08/15(月) 02:23:46.11

レスまだ？

464 ：デフォルトの名無しさん：2011/08/15(月) 02:24:31.49

>>460
getter厨はいい加減オブジェクトの通信を外にさらしてる
だけだってことに気づいたら？
隠蔽してる側は隠蔽してるだけだから、
int型とかにわざわざ戻さない限り手間はたいして増えないの。
そしてわざわざintとかに戻さない。

465 ：デフォルトの名無しさん：2011/08/15(月) 02:25:40.29

>>463
>>461

466 ：デフォルトの名無しさん：2011/08/15(月) 02:26:40.17

>>464
> getter厨はいい加減オブジェクトの通信を外にさらしてる
意味不明。

それの何が悪いのかちゃんと説明したら。

467 ：デフォルトの名無しさん：2011/08/15(月) 02:27:11.72

>>485
え？それ明らかに仕様が違ってるじゃんｗ

aとbとcとdが同じ型と
誰が言いましたか？

468 ：デフォルトの名無しさん：2011/08/15(月) 02:28:10.05

シンプルなものを複雑に書いて
悦に浸っているだけ。

469 ：デフォルトの名無しさん：2011/08/15(月) 02:28:19.34

>>466
何度も書いたし、このスレ見直したら？

470 ：デフォルトの名無しさん：2011/08/15(月) 02:29:07.55

>>464
だったら早く、
a.set( a.get() + b.get() + c.get() + d.get() );
をgetter/setter以外で書いてよ。手間かからないんでしょ。

471 ：デフォルトの名無しさん：2011/08/15(月) 02:29:55.91

>>469
何度も否定されてるし、
いい加減複雑になっているだけって気づいたら？

さて、反論コードはまだですかねぇｗ

472 ：デフォルトの名無しさん：2011/08/15(月) 02:31:05.38

まず、aとbとcとdを
Numericのlistに入れられるように
Numericを継承されます。

そのコードは割愛します。
長いからねｗ

473 ：デフォルトの名無しさん：2011/08/15(月) 02:33:29.73

>>467
オブジェクト自体は同じ型じゃない。
わざわざインターフェースを別の型にする理由もない。
だったらgetterの戻り値の型が足し算不能な型でもいいことになる。
そもそも使い方のレイヤーが違うし。

474 ：デフォルトの名無しさん：2011/08/15(月) 02:35:56.22

>>471
どこで？分岐に処理を渡す話もしどろもどろだったじゃん。

475 ：デフォルトの名無しさん：2011/08/15(月) 02:37:32.21

>>472
getterに実装が有ることやインターフェースが有ることは無視か。
相変わらずだな。

476 ：デフォルトの名無しさん：2011/08/15(月) 02:40:24.53

>>470
>>348のループを展開して、a,b,c,dを割り当てりゃ良いだろ。

477 ：デフォルトの名無しさん：2011/08/15(月) 02:46:08.87

>>476
具体的にお願い。JavaかC++で。

478 ：デフォルトの名無しさん：2011/08/15(月) 02:51:00.64

>>470
足し算ネタは終わった。
あとこれからは、getter方式の式をベースに
すんじゃなくて、入力と結果を指定しろ。
関数で書かれたものに、クラスで近づけろといわれても
意味が無いだろ。
問題は結果と入力だ。

479 ：デフォルトの名無しさん：2011/08/15(月) 02:52:39.84

>>477
ループ展開すら出来ないやつがケチつけてんのか。

480 ：デフォルトの名無しさん：2011/08/15(月) 03:12:12.52

>>470
> 足し算ネタは終わった。

あ、答えられないから無理やり終わらそうとしてるーｗ

じゃあ再開

481 ：デフォルトの名無しさん：2011/08/15(月) 03:12:39.81

>>480
なぜばれたｗ

482 ：デフォルトの名無しさん：2011/08/15(月) 03:12:55.05

>>447
バカの一つ覚えでgetterは絶対排除できないとのたまってるくせに、
他人にはバカの一つ覚えとは図々しい・・・。

483 ：デフォルトの名無しさん：2011/08/15(月) 03:13:49.15

>>480
>>461で終了。

484 ：デフォルトの名無しさん：2011/08/15(月) 03:15:09.43

getterを否定することは、戻り値を戻す関数
すべてを否定することになっているって
気づいているのかな？

戻り値を戻す関数はすべてダブルディスパッチで
実装できるよね。

関数が戻り値を返さなかったら、
それはもはや関数である必要がないだろう。
サブルーチンだ。

485 ：デフォルトの名無しさん：2011/08/15(月) 03:15:54.24

>>483
aとbとcとdはどこに言った？

486 ：デフォルトの名無しさん：2011/08/15(月) 03:17:40.87

>>482
> バカの一つ覚えでgetterは絶対排除できないとのたまってるくせに、

どこにそんな人がいるの？

getter不要信者 vs 適材適所で使えよ派だろ。

487 ：デフォルトの名無しさん：2011/08/15(月) 03:19:01.30

iostreamに合わせて純粋にC++の形で書くとこうか。
これで満足か？
ACM acm;
a >> acm;
b >> acm;
c >> acm;
d >> acm;
return acm;

488 ：デフォルトの名無しさん：2011/08/15(月) 03:22:10.59

>>486
>>7 とか他もろもろ。

489 ：デフォルトの名無しさん：2011/08/15(月) 03:27:32.83

>>487
それじゃダメだろ。

今回はたまたまa.get()しか無いからいいけど。
a.getValue1()、a.getValue2()とか
複数あったらどうすんだ。

それにそれは>>をオーバーロードしているだけで、
オーバーロードしないコード書いてみ。

490 ：デフォルトの名無しさん：2011/08/15(月) 03:29:30.98

>>489
オブジェクトが複数の値を持つことなんてあるのか？

491 ：デフォルトの名無しさん：2011/08/15(月) 03:30:18.18

>>490
あるに決まってるだろｗ

492 ：デフォルトの名無しさん：2011/08/15(月) 03:36:35.28

>>491
それだけじゃないよね。計算式の方も、足し算だけだとは限らないもんね。
普通、引き算掛け算割り算と色々使うよねぇ。
現実問題、計算機なんだから、そりゃ色々計算するわなぁ。

493 ：デフォルトの名無しさん：2011/08/15(月) 03:39:11.70

>>491
オブジェクトはそもそも値なんだから
おかしいだろ。

オブジェクトとオブジェクトを足したら
二つのオブジェクトが合わさったものになる。
その中の一部だけを足すとか設計がおかしいだけ。

aとbがそれぞれ2次元空間だとして、
aとbを足せば、縦は(a+b)、横も(a+b)、面積も(a+b)になる。
オブジェクト同士を足した時の結果は一義に決まるので
その中の一部だけを取り出すとかありえない

494 ：デフォルトの名無しさん：2011/08/15(月) 03:41:13.53

> 縦は(a+b)、横も(a+b)、面積も(a+b)になる。

え？

495 ：デフォルトの名無しさん：2011/08/15(月) 03:41:27.26

>>493
頭大丈夫か？お前、新しすぎるよ。

496 ：デフォルトの名無しさん：2011/08/15(月) 03:46:29.48

> ACM acm;
> 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のどちらかだろうけどな。

497 ：デフォルトの名無しさん：2011/08/15(月) 05:54:00.24

このコードを出さないと設計の話のできないレベルが低いのはマジで会社で仕事どうやってんだ？
あまりのレベルの低さに吐気がすんだけど

498 ：デフォルトの名無しさん：2011/08/15(月) 06:11:55.10

どうでもいいじゃない。
コード出させれば、馬鹿さがよく分かるんだから。

さてacmの答えが何になるか
楽しみに待ってようぜｗ

499 ：デフォルトの名無しさん：2011/08/15(月) 06:20:06.77

そもそもそんなコードだした目的はなんなの？

500 ：デフォルトの名無しさん：2011/08/15(月) 06:21:23.40

目的は知らんが、それによって
getter不要論者が苦しんでる。
それで十分だと思うよ。

さて、レスはまだ？

501 ：デフォルトの名無しさん：2011/08/15(月) 07:04:50.95

>>500
もう議論に勝つことに夢中で何も見えてないんだな

502 ：デフォルトの名無しさん：2011/08/15(月) 07:46:18.13

どっちもどっちに見える

503 ：デフォルトの名無しさん：2011/08/15(月) 08:27:12.82

>>490
「オブジェクトが複数の値を持つことなんてあるのか？（キリッ」

素晴らしい名言www

504 ：デフォルトの名無しさん：2011/08/15(月) 09:22:55.16

>>420
勝手に終わらせんなよ
もしかして、iteratorから長さ取ってくる(>>397 >>402)のが答えか？
文字列変更するオブジェクトと長さを知りたいオブジェクトが違ったらどうするんだ？
ていうか、それってgetする相手がstringからiteratorに変わっただけだろ馬鹿が

505 ：デフォルトの名無しさん：2011/08/15(月) 09:40:08.26

>>464
一端外に晒すから組み合わせやすいんじゃね？
中に分岐を持ってるってんなら、引数の型なりインタフェースなりが限定されるか、
拡張を余儀なくされるかじゃね？

一方、単純な型などを返すインタフェースだと、
インタフェースはそれ以上大きくも多くもならない。

506 ：デフォルトの名無しさん：2011/08/15(月) 10:02:47.54

>>460
a.add(b.add(c.add(d.get())))
俺は>>379でいうと「getter -> 処理 -> setterこんな処理するなら最初から内部で処理しろよ派」

507 ：デフォルトの名無しさん：2011/08/15(月) 10:11:04.89

int ret = a.getM() / b.getN() * c.getO() % d.getP();
int ret = clamp(Math.sqrt(Math.max(a.getM(), b.getN())), c.getO(), d.getP());

外に出した値を使わずに、中に入れ込んでいくと破綻しそうだが…。

508 ：デフォルトの名無しさん：2011/08/15(月) 10:18:11.97

>>460らへんはここの通りだな

Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

509 ：デフォルトの名無しさん：2011/08/15(月) 10:34:25.99

「getter -> 処理 -> setterこんな処理するなら最初から内部で処理」
これってある程度具体的なクラスじゃなきゃ適用できないよね

どの程度の粒度を対象に議論するのか決めとかないと話が前に進まないんじゃないかな

510 ：デフォルトの名無しさん：2011/08/15(月) 10:38:50.96

getterの意味はプロキシだからな。
関数はオーバーロードできるけど変数は出来ないから
関数を通して出来るようにしているわけだから
変数の公開変数思えば良い。
変数だけ公開してはいけないなんていうやつは
データの隠蔽と履き違えているとしかいいようがない。

511 ：デフォルトの名無しさん：2011/08/15(月) 10:48:25.41

>>509
どういうこと？抽象的な環境でこそ生きてくるものだと思うんだけど

512 ：デフォルトの名無しさん：2011/08/15(月) 11:00:01.85

>>511
外に公開したintの用途を全て想定できるならカプセル化なんて要りません

513 ：デフォルトの名無しさん：2011/08/15(月) 11:28:35.68

>>512
intを公開しているクラスに対しての新たな用途ができたら、それをintを公開しているクラスにメソッドとして追加するんじゃないの？
そうしないと新たな用途の実装が外部に記述されてしまって、それこそカプセルかできてないと思うんだけど

もしその新たな用途がintを公開しているクラスに対しての物ではないなら、確かにどういう用途かわからないけど
その場合はgetterだけでsetterは必要ないわけだしそこは否定してないよ

対象クラスへの処理を外部で行うなら、対象クラスへ実装しろって話

514 ：デフォルトの名無しさん：2011/08/15(月) 11:38:16.16

オブジェクトには必要最小限の処理しか書かず
外部でできる処理は内部に入れてはいけないというのが
オブジェクト指向の基本だろ。
基本もわかってないような奴が滅茶苦茶なことを書いて
混乱させてるだけとしかいえないな。

515 ：デフォルトの名無しさん：2011/08/15(月) 12:18:46.94

>>513
じゃあデータベースアプリは全てデータベースオブジェクトの機能と考えられるから
一つのクラスでDBアクセスもGUIも全部担当するべきだね

516 ：デフォルトの名無しさん：2011/08/15(月) 12:32:13.32

普通ドメインを軸に考えるだろ

517 ：デフォルトの名無しさん：2011/08/15(月) 12:36:50.95

>>514
そんな基本聞いたこともないぞwww
>>508読んだ？

518 ：デフォルトの名無しさん：2011/08/15(月) 12:38:59.69

>>515
まずそんな考え方しない
おまえはそんな風にクラス分けるのか

519 ：デフォルトの名無しさん：2011/08/15(月) 12:58:59.07

領域を軸に考える？

520 ：デフォルトの名無しさん：2011/08/15(月) 13:02:16.49

>>517
effective c++に書いてあるぞ。

521 ：デフォルトの名無しさん：2011/08/15(月) 13:05:46.28

>>508
トンデモ論ワロス

522 ：デフォルトの名無しさん：2011/08/15(月) 13:06:43.08

ドメインとかビジネスロジックとか、
今まで何度か理解しようとしたが、
俺がアホすぎて理解できたことが無い。

523 ：デフォルトの名無しさん：2011/08/15(月) 13:12:09.61

>>520
それに書いてあるの文章そのまま書いてくれ
それか何ページか教えてくれ

524 ：デフォルトの名無しさん：2011/08/15(月) 13:14:10.78

>>521
具体的にどこがトンデモかを指摘しろよ
煽るだけなら書き込むな

525 ：デフォルトの名無しさん：2011/08/15(月) 13:18:44.22

>>524
俺は彼じゃ無いが、
その文章は、大衆はバカだって言ってる様な物だ。

526 ：デフォルトの名無しさん：2011/08/15(月) 13:18:49.60

本が買えなくてネットでしか情報が得られない人なんだろう
可哀想・・・

527 ：デフォルトの名無しさん：2011/08/15(月) 13:21:08.32

>>508
トランザクションスクリプトって知ってるか？

ドメインは太らせるばかりが正解じゃないんだぞ。
そして、日本ではトランザクションスクリプトの方が主流。

ドメインモデルは一つのでかいシステムを
十分な時間をかけて分析し設計し
ウォータフローで作っていくには適しているが
アジャイル的な開発には向いていない。

528 ：デフォルトの名無しさん：2011/08/15(月) 13:21:32.19

>>514
一つのクラスには一つの責務って話じゃないの？
文脈がよくわからん。

必要最小限の処理とか、外部でできる処理とか、急に言われても・・・

素直に文字通り読んだら、「外部でできる処理」を全部外に出したら
構造体と処理になるかな、と思った。

529 ：デフォルトの名無しさん：2011/08/15(月) 13:23:49.61

>>528
少なくともカプセル化はされてるんだから、そうはならないでしょ。

530 ：デフォルトの名無しさん：2011/08/15(月) 13:30:34.32

あと、ドメインモデル貧血症ってのは
ドメイン（クラス）が持つべき処理を
外に出してデータだけにしてしまわないように
しようって話であって、

getterをなくそうって話ではない。

しかし、データは長期間保存されるもの
ロジックは変化するもの。と考えれば
ドメインモデルが必ずしも正しいとは言えないんだがね。

オブジェクト指向は適材適所で適用すべきもんだよ。
オブジェクト指向は、ライブラリとフレームワーク部分に適用し
ビジネスロジックはトランザクションスクリプトで書いたほうが
メンテナンス性がよくなる。

531 ：sage：2011/08/15(月) 13:32:50.54

getterだのsetterだのというが、結局のところメソッドだ。
「メソッドとして定義するべきか？」「それを誰が持つべきか？」「外部にも公開するべきか？」といったことは、そのオブジェクトにどのような役割（責務）を持たせるかで決めるものだ。
システム化したい対象をどのように捉えるか（ドメイン分析）と、設計ポリシーが先であって、プログラミングテクニックが主導して決めるものではないよ。

532 ：デフォルトの名無しさん：2011/08/15(月) 13:37:09.33

>>525
だからなんなんだw
内容に対してのレス頼むよ

>>526
だから本を参照したいからページを教えてくれと言ってるんだろ

533 ：デフォルトの名無しさん：2011/08/15(月) 13:37:59.46

ウェブアプリの世界ではドメインモデルと
トランザクションスクリプトは説明しやすいんだが、
GUIアプリだと少し難しい。あまり話題にならないし。

トランザクションスクリプトは、LinuxのGUIアプリでよくあるような
見た目は一見GUIだけど、ボタンを押したときにCUIコマンドが
実行されるような部分のこと。

ドメインモデルだと、各オブジェクトがそれぞれ結合して強調して動く。
トランザクションスクリプトは、その名前のスクリプトからイメージできるように
なんらかのスクリプト（一連の処理）が何かをきっかけで動き出すような感じ。

もしドメインモデルでGUIアプリを作ろうと思えば、すべてをGUIと密接に結合された
オブジェクトとして作ることになる。ボタンの中に処理を書くのではなく
ボタンとオブジェクトのメソッドが直接つながっている感じ。

534 ：デフォルトの名無しさん：2011/08/15(月) 13:40:11.55

トランザクションスクリプトってデザインパターンのコマンドパターンってやつで
ドメインモデルっていうのはプラグインみたいな感じ化？

535 ：デフォルトの名無しさん：2011/08/15(月) 13:42:37.36

いや、やっとドメインモデルとトランザクションスクリプトの
話が出てきて嬉しいよw
getter不要とか奴のわからん奴にかまってるのは無駄だからな

で、この話題を振った人(>>508)。なんか書いてね。
理解してるんでしょ？

536 ：デフォルトの名無しさん：2011/08/15(月) 13:50:22.73

>>527
具体的にオブジェクト指向的にトランザクションスクリプトのどこが素晴らしいか教えてくれ

>>530
>あと、ドメインモデル貧血症ってのは
>ドメイン（クラス）が持つべき処理を
>外に出してデータだけにしてしまわないように
>しようって話であって、
>
>getterをなくそうって話ではない。
最初から俺はそう主張しているよ>>506
決してgetter不要論者ではないです

>しかし、データは長期間保存されるもの
>ロジックは変化するもの。と考えれば
>ドメインモデルが必ずしも正しいとは言えないんだがね。
>
>オブジェクト指向は適材適所で適用すべきもんだよ。
>オブジェクト指向は、ライブラリとフレームワーク部分に適用し
>ビジネスロジックはトランザクションスクリプトで書いたほうが
>メンテナンス性がよくなる。
やっとまともに意見をくれる人がいて嬉しいです
ドメインモデルよりトランザクションスクリプトの方が拡張性が高いという意見みたいだけど、どういうところでそう思いましたか？

537 ：デフォルトの名無しさん：2011/08/15(月) 13:51:58.20

>>534
トランザクションスクリプト・・・手続き型風
ドメインモデル・・・オブジェクト指向風

と考えればいいよ。

ただし、トランザクションスクリプトだからってシステム全体を
手続き型で作るという話ではない。クラスを使わずに使うという話ではない。

トランザクションスクリプト or ドメインモデルは
基本的に、システム全体の一部分、だけど一番重要なビジネスロジックに
適用される話。それ以外はライブラリやフレームワーク（システム専用ではない汎用品）

トランザクションスクリプトでも、オブジェクト指向で作られたライブラリを使うし
フレームワークはオブジェクト指向で作ってあるので、必然的にオブジェクト指向に
そったやり方で処理を埋め込むことになる。

トランザクションスクリプトってのは、その中を（オブジェクト指向ライブラリをつないながらも）
手続き型風に書いていくやり方。データベースのように明らかにデータが分離された状態から
そのデータを加工しながら処理をしていくのに適している。

反対にドメインモデルだと、データベースを使っていたとしてもそれは隠蔽され
完全にロジックと結合しているオブジェクトとなる。

オブジェクト指向信者なら、全部オブジェクトがいいんだろうけど、
データベースがデータだけを分離しているように、またデータは変化しにくい・ロジックは変化しやすい
ことからもわかるようにビジネスロジックにおいては、データとロジックを一体化した
オブジェクト指向＝ドメインモデルが正解だとは言い切れない。

538 ：508：2011/08/15(月) 13:57:57.62

>>535
>>506が言いたいことです
そこを納得してもらえないようだから>>508を出しました
あと一連のやかましいレスは俺です

539 ：デフォルトの名無しさん：2011/08/15(月) 13:58:57.99

>>536
> ドメインモデルよりトランザクションスクリプトの方が拡張性が高いという意見みたいだけど、

それは適材適所。

俺の中で拡張性といえば、プラグインを追加したり、処理を割りこませる仕組みがあったり
そいういうものを拡張性だと感じる。

ビジネスロジックは、既存の処理とは独立した新たな処理が追加されることはあるが
それを拡張とは思わない。

拡張性を高めるのならオブジェクト指向のほうがいい。そしてそれは
ライブラリやフレームワークに適用されるもの。

だからトランザクションスクリプトは拡張性が高いという意見ではなくて
ビジネスロジックは拡張性は必要ない部分ってだけ。

540 ：デフォルトの名無しさん：2011/08/15(月) 14:00:17.30

へー、それって大雑把な解説だけど
本当はもっと厳しい決まりとかあるの？

541 ：デフォルトの名無しさん：2011/08/15(月) 14:04:01.99

WindowsのGUIアプリで、コード書かずに
ポトペタだけで作れるでしょ？

でもボタンを押したときにコードを書くでしょ？
あの処理をなくして、見えないコンポーネントを作って
ボタンのクリックと見えないコンポーネントをくっつける。

そういうふうにしてGUIを作っているときにコードを書かずに
プロパティ設定だけで、完全にポトペタで作れるようにしたものが
ドメインモデル。

542 ：デフォルトの名無しさん：2011/08/15(月) 14:11:21.64

わかったぞ、
部品を組み立てるように作るのがドメインモデルで
やることリストを作るのがトランザクションスクリプトだな。

543 ：デフォルトの名無しさん：2011/08/15(月) 14:18:06.14

>>540
無いよ。

あれば既存のシステムを読むとき、
もっとわかりやすい世界になっていただろうさ。

それどころかドメインモデルとトランザクションスクリプトの違いを理解してないで開発されている例が多い。
日本ではトランザクションスクリプトが主流だが海外ではドメインモデルのほうが多い。
主流と言っても、意識してそうなっているのではなく、結果としてそういうコードになってるねってだけ。

困ったことにRubyOnRailsとかよくあるフレームワークはドメインモデルを使うことを前提に作られている。
そこにビジネスロジックをトランザクションスクリプトで作るから、コードがゆがんでることが多い。
厳しい決まりがあるどころか、微妙に混ざりながらどっちとも言えないコードで作られている。

そもそもビジネスロジックってのはフレームワークに依存させたくないものなんだから、
フレームワークがビジネスモデルに関わってくるなと言いたい。まあRailsの基本的な考え方が
「俺らが決めたやり方に従えば簡単に作れる」なのだから仕方ないが。

トランザクションスクリプトを使うのならSpringやSeasorのようなDIコンテナを使うといい。
コントローラー（SpringやStruts）とビジネスロジックをつなぐものとしてDIコンテナを使うと
うまくビジネスロジックを分離させられる。DIコンテナはフレームワークと呼ばれているが、
このフレームワーク用に作ったオブジェクトはフレームワークに依存しない。

544 ：デフォルトの名無しさん：2011/08/15(月) 14:18:49.77

>>520
>>523じゃないがおれも手元に本用意した。
そろそろページ数教えてくれ

545 ：デフォルトの名無しさん：2011/08/15(月) 14:21:59.06

Web系の人もいろいろ工夫してやってんだなぁ（対岸の火事）。

546 ：デフォルトの名無しさん：2011/08/15(月) 14:28:48.51

>>542
それなりに間違ってないと思うよｗ

部品と部品をつなげるときに処理をしない。
処理はすべて部品が持っている。
そうするとドメインモデルになる。

これはある意味理想的な形だけど、難しくもある。
作りたいシステム全体を一つのものとして設計しないといけないから。

汎用品と汎用品の間に処理を入れて、汎用品を組み合わせて作るという考え方ではなく、
汎用品がなければ、専用品として仕上げないといけない。すべてが部品となる。

部品と部品の間に処理を入れられれば、多少部品と部品がうまく結合できなくても
どうにかなるが、そういう処理を無くすのであれば、システム全体を見ながら
部品を設計する必要がある。だから大掛かりなものとなってしまい時間もかかる。

547 ：デフォルトの名無しさん：2011/08/15(月) 14:50:10.07

>>546
あー、だったら俺は完全にトランザクションスクリプト派だわ。
顧客の細かなニーズに対応したいし、
処理の流れが分かりやすいってのは、メンテ性にも関わってくる。
パーツ作ってるわけではなく、最終目的地点のアプリ作ってるわけだから、
それ以上の拡張性は要らないわけで、ベタで書いても支障ないしな。

548 ：デフォルトの名無しさん：2011/08/15(月) 14:54:37.11

>>527
＞十分な時間をかけて分析し設計し
＞ウォータフローで作っていくには適しているが
＞アジャイル的な開発には向いていない。
初耳だわ。誰の意見？少なくともファウラーもエヴァンスも、ウォーターフローを忌み嫌っているはずだがね。

>>533
プロキシを密結合と言うのならそうなんだろうな。
http://martinfowler.com/eaaDev/uiArchs.html

549 ：デフォルトの名無しさん：2011/08/15(月) 15:35:31.14

>>539 >>546
>しかし、データは長期間保存されるもの
>ロジックは変化するもの。と考えれば
>ドメインモデルが必ずしも正しいとは言えないんだがね。
こういうときこそドメインモデルが生きてくるところだと思う

ドメインモデルの方が難しいというのは同意です。
しかし実装と機能を分けて、それぞれの拡張を別に実現するということを目指すのは必要なことだと思っています
疎結合になりますし、新たな実装を追加しても既存の機能には影響を与えない。
機能の修正は、実装追加とは別に行える。
これこそ拡張性が高いということだと思っています。
Bridgeパターンデザインパターンでキャリアアップ　http://www.rarestyle.net/main/patterns/bridge.aspx
9. Bridge パターン | TECHSCORE(テックスコア)　http://www.techscore.com/tech/DesignPattern/Bridge.html/

>>547
処理の流れが分かりやすいというのはその通りだと思います。
トランザクションスクリプトでは一連の流れがあるメソッド上に浮かび上がってきますが、ドメインモデルでは大枠で何を行っているかは掴めますが、
流れを知るにはクラスをどんどん潜っていく必要があります。
ドメインモデルはこれをメリットと考えていて利用者側は詳細を知る必要がなく開発ができると捉えます。

そして今更なんですが、
ドメインモデルは>>506
トランザクションモデルは>>460
ということになるんですか？
なんかまた別の話になってるような

550 ：デフォルトの名無しさん：2011/08/15(月) 16:44:40.03

ウォーターフローとかはじめて聞いた・・・
ググったら奇妙な引っ掛かり方した。
そういう言い方がないわけでも無いらしい。

551 ：デフォルトの名無しさん：2011/08/15(月) 17:25:46.55

ドメインモデルとトランザクションスクリプトについてはここらへんがいいね

Martin 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/

552 ：デフォルトの名無しさん：2011/08/15(月) 17:44:48.75

>>550
スマン…俺がアホだった。自分でも驚いた。

553 ：デフォルトの名無しさん：2011/08/15(月) 20:09:58.76

>>496
ACMってアキュムレーターの事だろ。
他の演算するなら他のオブジェクトを使うまで。
オブジェクトによって演算のパターンを決めるだけじゃん。
そういう演算をしたいならそういうオブジェクトを指定すればいいだけ。

554 ：デフォルトの名無しさん：2011/08/15(月) 20:13:31.49

どんどんシンプルとはかけ離れていくなｗ

555 ：デフォルトの名無しさん：2011/08/15(月) 20:15:37.62

>>497
コードを出させてんのはgetter厨じゃん。 >>477 とかさ。

556 ：デフォルトの名無しさん：2011/08/15(月) 20:20:41.10

>>489
Value1を拾うオブジェクトを使うか、Value2を拾うオブジェクトを定義するだけ。
ちゃんとValueじゃなくて、countだのなんだの具体的な名前書いてみりゃ、
規則的な計算になることぐらいすぐ解ると思うけど。
今後Valueとか書かずに具体的な名前書けよ。

557 ：デフォルトの名無しさん：2011/08/15(月) 20:22:13.14

あ、もちろんValue1とValue2両方必要なら両方拾えば済む。

558 ：デフォルトの名無しさん：2011/08/15(月) 20:29:39.80

interfaceとabstractとimplementの区別が付かないくせに
classを派生してgetter, setterをつけるんだよえっへん
というバカがたくさんいたのが全ての元凶だと思うんだ
interface abstractなら正解だけど
implementならどうでもいい
そして説明してる奴の九割がimplementのコードを例に出す
そうやってバカが量産されてきたのじゃよ

559 ：デフォルトの名無しさん：2011/08/15(月) 20:33:08.69

という思い込み

560 ：デフォルトの名無しさん：2011/08/15(月) 20:39:32.61

オブジェクト指向なんだから、オブジェクトに振る舞い任せるのは普通だろ、
なんでアクセサで必死になってんの？

561 ：デフォルトの名無しさん：2011/08/15(月) 20:42:11.48

？アクセッサもオブジェクトの振る舞いの一つだからだよ？

そもそもアクセッサをなにか特別扱いしてない？
本質は戻り値を返す関数と一緒。

それとも関数そのものを否定する気？

562 ：デフォルトの名無しさん：2011/08/15(月) 20:52:20.99

>>561
関数はそもそもリストで返さないか？

563 ：デフォルトの名無しさん：2011/08/15(月) 20:54:23.50

リストで返す必要がないものを
リストで返すわけがないだろう。

564 ：デフォルトの名無しさん：2011/08/15(月) 20:54:57.02

それにリストで返すアクセッサもあるし、
なんの関係があるんだ？

565 ：デフォルトの名無しさん：2011/08/15(月) 21:02:24.38

いや、純粋に関数ならアトムかリストでしょ。
配列とか構造体的なもんじゃ再帰構造に対応できないから。
オブジェクトなら関数ベースと違ってオブジェクトなりのやり方だろうけど。

566 ：デフォルトの名無しさん：2011/08/15(月) 21:06:09.45

>>565
ん？
ひとつ聞いていいか、
お前にとって、リストと配列の違いは何だ？

567 ：デフォルトの名無しさん：2011/08/15(月) 21:10:28.13

>>566
リスト　( 1 ( 2 3 ) 4 ( 5 6 7 ) )
配列　[ 1 , 2, 3, 4, 5 ]

568 ：デフォルトの名無しさん：2011/08/15(月) 21:10:57.15

かー、くだーができるかいなかじゃねｗ
あのおなじみのセル構造。

569 ：デフォルトの名無しさん：2011/08/15(月) 21:14:05.31

別に>>561は関数型言語的な意味で関数っつってるんじゃないっしょ。
メソッドだかオペレーションだかメッセージだか
その辺に読み替えるのが妥当じゃね？

570 ：デフォルトの名無しさん：2011/08/15(月) 21:31:16.99

ここ、オブジェクト指向のスレだろ？

なんか変なのがいるな。

関数型言語の話をしたいのなら
そっちにいけと。

571 ：デフォルトの名無しさん：2011/08/15(月) 22:21:08.38

>543
>RubyOnRailsとかよくあるフレームワークはドメインモデルを使うことを前提に作られている
ドメインモデルとトランザクションスクリプトの中間に位置するのがActiveRecord（レコード指向）
じゃないの？
データベースのレコードをクラス（インスタンス）として扱うことでオブジェクト指向的な
利点を享受する。

572 ：デフォルトの名無しさん：2011/08/15(月) 22:42:50.38

>>556
x = (a + b) * (c + d)
を求めるだけで途中の計算を保存するテンポラリを
人間が用意する必要があるんじゃないの？

573 ：デフォルトの名無しさん：2011/08/15(月) 22:47:30.29

>>571
それがよくあるActiveRecordの間違った使い方。
ActiveRecordはドメインモデル。ActiveRecordは自動生成されたものを
そのまま使うのではなく、本来は継承しロジックを追加し
ドメインモデルとして仕上げて使うもの。

ドメインモデルの特徴の一つとして、入力チェックがモデル（ActiveRecord）に
あるということをあげられる。オブジェクト指向的に考えればモデルに
入力チェックがあるのは自然に見える。そしてActiveRecordのやり方に従えば
そこに入力チェックを書くように仕向けられているはず。

これがトランザクションスクリプトの発想だと入力チェックを外でやりたくなるはず。
コントローラ（もしくはコントローラーとビジネスロジックの中間層）で入力チェックをして
そのあとActiveRecordを使って保存したくなるはず。これはActiveRecordのやり方ではない。

本来モデルはテーブルと一対一で結びつける必要はないんだけど、ActiveRecordは一対一に結び付けてる。
これが更に混乱を増す結果になっていると思うな。
一つのアクションで複数のテーブルにデータを格納（＋そのためのチェック）することはよくある話なんだけど、
モデルとテーブルが一対一に結びついてると、意識しないで書くとただの複数のモデルを読み書きする処理
つまりトランザクションスクリプトを書いてしまうんだよ。

本来はそこで、モデル間のリレーションを適切にはって、O/Rマッパーの機能をフルに使って、データベースの存在をなくして
完全なるオブジェクトに仕上げて、一回の保存で複数のテーブルに保存できるようにして行かないといけないんだろうけど
俺には無理だわｗ現実にはそこでN+1問題とかパフォーマンスとか更に考えるべき問題が出てくるからね。

> データベースのレコードをクラス（インスタンス）として扱うことでオブジェクト指向的な
> 利点を享受する。
これがまさにトランザクションスクリプトで、俺がオブジェクト指向は
フレームワーク(ActiveRecord)とライブラリの部分で使うべしといっていることそのもの

574 ：573：2011/08/15(月) 22:51:30.87

http://thinkit.co.jp/story/2010/10/06/1792?page=0,0

一応自分の考えをまとめるのに参考になった所。

他にもいろいろあるけどなー

575 ：デフォルトの名無しさん：2011/08/15(月) 23:03:24.96

>>572
まずa b c dを止めて意味のある名前にしてから聞いてくれない？
目的によっていくらでも捉えようがあるからさ。

576 ：デフォルトの名無しさん：2011/08/15(月) 23:05:42.09

Railsとかそれに近い考えのフレームワークを使っていると、

なんで入力チェックをそこ（モデル）でやるんだ？とか

複数のテーブルに格納するときはどうするんだ？

入力チェックはモデルだろ？複数のテーブルに格納するとき
複数のテーブルのデータを参照する必要があるチェックはどうするんだ？
その場合のトランザクションはどうするんだｓ？

とか悩んだことがあると思うんだけどどう？

577 ：571：2011/08/15(月) 23:06:43.83

>573
＞フレームワーク(ActiveRecord)とライブラリの部分で使うべしといっていることそのもの
おそらく俺はあんたと同じ価値観を持っていると思う

しかし言葉の定義が違うだろ
＞これがまさにトランザクションスクリプト
いやトランザクションスクリプトではレコードクラスにごく単純なメソッドさえ持たない
あるいはレコードに対応するクラスなんて概念さえない
たとえばTargetDateが営業日かどうか判定するのにIsBusinessDateとかいうメソッドを
作るのがAcriveRecoedの利点だと思うが

578 ：デフォルトの名無しさん：2011/08/15(月) 23:07:00.87

計算結果をテンポラリする必要のある処理では、
マルチメソッドをgetterの替わりに悪用するのは辛いでしょ。

579 ：デフォルトの名無しさん：2011/08/15(月) 23:12:53.76

>>578
結果を何回も使いたけりゃ、さっきの >> を何度も呼び出せばいいだけじゃん。
in >> out; でoutに渡される値はin側のオブジェクトが変更されない限り変わらないんだから。
in >> out1;in >> out2;ってな感じで何度でも渡せる。

580 ：デフォルトの名無しさん：2011/08/15(月) 23:29:19.07

>>579
そんで、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;
とかするわけ？
多くの言語で戻り値を返す関数や式が認められてるのに？

581 ：デフォルトの名無しさん：2011/08/15(月) 23:36:03.13

>>580
in1に戻す意味が解からんけど・・・。
out3　== in1なオブジェクトで構わんだろうし。
そんな要件なら。in1 = out3で上書きしとけばいいだろう。
a=(a+b)*(c+d)は内容によるとしか言えんな。
ベクトルとグラデーションで同じ計算があるからと言って、
同じオブジェクト構造になるわけじゃないし。

582 ：デフォルトの名無しさん：2011/08/15(月) 23:37:45.59

それだけじゃない。
a.setValue1( a.getValue1()+a.getValue2() );
の場合はどうするんだ？単純にa>>adderとは書けないぜ？

a>>value1;
a>>value2;
value1>>adder;
value2>>adder;
adder>>value1
value1>>a;
また人手間増えたな。

583 ：デフォルトの名無しさん：2011/08/15(月) 23:38:36.65

>>580
もうひとつ言うと、四則演算とかが表に出てくることは殆ど無い。
最初から、aとbとcが一つのオブジェクトに入ってて、dが別のオブジェクトに入ってるってな事になるのが大概だし。

584 ：デフォルトの名無しさん：2011/08/15(月) 23:40:59.98

>>582
aによるって。
a.move( x, y );ってのを内部に持ってれば。
1回で済む話しだし。x(つまりgetValue1())が不要なら無視すればいいだけ。
yも同じはなし。

585 ：デフォルトの名無しさん：2011/08/15(月) 23:46:25.29

>>583
俺も一つ言わせてもらうが、
引き算はどうするんだ？
a>>suber; b>>suber;　だと、引く数、引かれる数の区別が付かん。

>最初から、aとbとcが一つのオブジェクトに入ってて、dが別のオブジェクトに入ってるってな事になるのが大概だし。

そんなことは証明できんだろ。
3つ以上のクラス間で処理が跨ることなんて、多々あるだろ。

第一、
>aとbとcが一つのオブジェクトに入ってて
だったとしても、そのabcにgetterが無かったら同じことだろ。

586 ：デフォルトの名無しさん：2011/08/15(月) 23:46:27.86

結局、オブジェクトの意味と、getValueの名前を明確にしてもらわにゃ、
なんとも回答できんわ。
int型の配列見せられて、目的も言わずコレを使ってクラスを造ってくれって言われてんのと変わらんし。
配列だけ出されて目的とするものが、ベクターかツリーかグラフかじゃ全然違うからどうしようもない。

587 ：デフォルトの名無しさん：2011/08/15(月) 23:50:16.73

>>585
StringBuilderかStringBufferでオブジェクトを作ってても
bufferじゃ、マルチスレッドに対応してるか解からんと言ってんのと変わんない。

あと、suberは引数で渡される事もありうるから、最初から挙動は不明。
suberのオブジェクトを作ったヤツが責任をとる。ACMの時からもだけど、
最初からそういうデザイン。

588 ：デフォルトの名無しさん：2011/08/15(月) 23:53:45.06

>>584
意味がわらんのだが。a.move( x, y )　では値を取り出せないし。
仮に、a>>pointだったとして、確かにpointの中にx,yは入ってるだろうが、
今度はpointの中からxだけを取り出す手段がないんだが。
point >> valueX とかするわけ？
それとも、
point >> adderX　とかするわけ？
どっちもクラス数が爆発するんだが。
どうせ、CPUは基本型で演算するんだから、
int a.getX()とかint point.getX()とかで良いじゃん。

589 ：デフォルトの名無しさん：2011/08/15(月) 23:54:58.06

>>585
いや実際四則演算が出てくるような事はまず無いんだよ。
さっきのmoveとかあったけど、最初から計算するつもりなら、
その値を受け取るインターフェースを持ってる。
point >> block;
scale >> block;
ってな感じにそもそも対象とする値が決まってるからインターフェースも別れる。
あと、突っ込まれる前に言うが、getterが被らないのと同じ理由でインターフェースも被らないし。

590 ：デフォルトの名無しさん：2011/08/15(月) 23:55:57.02

>>588
xを取り出すには目的が有るはずだよね。
それは何？

591 ：デフォルトの名無しさん：2011/08/16(火) 00:01:09.05

仮にGUIコンポーネントにx,y引き渡すなら、moveをGUIコンポーネントに持たせて、
GUIコンポーネントの中で、x,y自由に移動やら衝突判定に使えばいい。
文字で表示させたいだけなら、文字表示用のレイアウトにmoveを持たせればいい。
一回レイアウト作ったら二度と作る必要はないし。
ま、そうそうxだけを無差別に使うってことはない。

592 ：デフォルトの名無しさん：2011/08/16(火) 00:03:44.77

>586
ちょうどさっきまで書いていたコード（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履修、単位を持っている
それで必要な条件を満たしているかどうかを判定する

593 ：デフォルトの名無しさん：2011/08/16(火) 00:08:07.42

>>589
問題はその、「block」だろ。
計算の種類の数だけblockを作る必要がある。
例えば、xは足したいが、yは足したくない場合など。
ちょっとした計算を行うのに、わけの分からないクラスを大量に作る羽目になる。

普通は、基本的なものの組み合わせでやりたい事を表現できた方が嬉しいだろ。
せっかく基本型と+-*/などの演算子が有るのに。

594 ：デフォルトの名無しさん：2011/08/16(火) 00:08:11.44

戻り値はbool型でいいのかい？
あと、余談だけどさ。オブジェクト指向言語なんだから、単位系と、
科目系とでオブジェクトにまとめたら？

595 ：デフォルトの名無しさん：2011/08/16(火) 00:09:15.62

>>593
xは足したいがyは足したくない場合って何？
単に、yを0に変えたオブジェクト作ってそっから渡せば済む話じゃないの？

596 ：592：2011/08/16(火) 00:11:02.63

>>594
戻り値はboolでOKです
余談の部分は言っている意味がわかりません

597 ：デフォルトの名無しさん：2011/08/16(火) 00:12:04.31

>>591
そのGUIコンポーネントに引き渡す「x.y」をどうやって生成するんだって話なんだが。
getter使わずに。

598 ：デフォルトの名無しさん：2011/08/16(火) 00:23:45.04

>>597
Vector vector( file, "キー");//中に readでxとyを取り出してる。
vector >> out でいい。

あと>>592が何したいのか考えてるからちょっと待ってくれる。
ぶっちゃけこのまま風呂行って寝て明日になるかもしれないけど。

599 ：デフォルトの名無しさん：2011/08/16(火) 00:30:27.78

>>595
どうやってだよ。
point1 >> block;
point2 >> block;
こんな方式なんだぜ？

だた、意味が伝わってなかったかもしれん。
point3 = { point1.x+point2.x, point1.x };
こんなことがしたい場合はどうするんだって話。
いちいちblockに相当するものを量産するのか？

そもそも、a >> block　こんなんで、a内の特定の何かにアクセスできるんかって話も。
お前はgetterと同じで名前はかぶらないって言っていたけど、
aのvalue1と、bのvalue2を足し算したい場合はどうするんだって話もある。

600 ：599：2011/08/16(火) 00:43:19.11

point3 = { point1.x+point2.x, point1.x };
↓
point3 = { point1.x+point2.x, point1.y };

601 ：デフォルトの名無しさん：2011/08/16(火) 01:18:55.85

横からごめん。
point3 = { point1.x+point2.x, point1.y };
これ、どこの文法？

602 ：デフォルトの名無しさん：2011/08/16(火) 03:20:52.13

>>592
よくよく考えたらルールからしてダメじゃねぇか。Is～はgetterだから変えさせてもらう。
本来最初から設計してたらそんなもん組み込まないし。
あと判定ルールのIs単位ってなんで数字と比較してるんだ？bool値じゃないのか？
あと科目Listのコンテナは何？

一応マジメに答え作ってるから、ここら辺はしっかりしてもらう。

603 ：592：2011/08/16(火) 07:43:55.75

>>602
Is単位はboolです、数値比較は間違いですね。普通にIF分でいいです
科目リストはList＜科目＞です

＞Is～はgetterだから変えさせてもらう
よく意味がわかりませんが、
Is～だけでなく「単位」「必要科目数」「必要単位数」もみんなプロパティとして実装しています
必要科目数と必要単位数はただプライベート変数を返しているだけですが
それい以外はなにかしらコードが書いてあります

604 ：デフォルトの名無しさん：2011/08/16(火) 08:30:44.14

>>603
getter無しでコード書くって言ってるんだから。
このコードをgetterを使わないで、このgetterを使って書いて
言われてんのと同じなんだけど。

あと、判定ルールだけどis単位が、
真の時、
科目関係の必用科目数って必須なの？
必用単位数と排他関係に有るんじゃないの？
もし型が同じなら、必用単位数と必用科目数の2つに分ける
必用がなく、単に必用数でいいんじゃない？
型が違ってるなら、他の人がやってたように
必用数Int、必用数longとか用意しとけばいいんじゃない。

605 ：デフォルトの名無しさん：2011/08/16(火) 08:40:56.88

ダブルディスパッチ君はあれだろ、getterとか関係なくて
「メソッドディスパッチでは実行時の型に応じて
戻り値の型を変える事ができない。だから戻り値を使うのは全部禁止」
こういう主張だろ？

でも前提条件（戻り値の型を変更不可）からして間違ってる上に、
結論（戻り値を全部禁止）もぶっとんでるから、全体として意味不明。

606 ：592：2011/08/16(火) 08:45:06.64

>>604
＞必用単位数と排他関係に有るんじゃないの？
論理的にはそうですが、判定ルールオブジェクトはDBに保存されているので
この仕様は変えられません
Is単位をみて必用単位数か必用科目数を返すという新しいプロパティを作るの
もちろんOKですが、結局Is単位の判定は必要になるので今回は作りませんでした

＞このコードをgetterを使わないで、このgetterを使って書いて
そう思います。getterなしでこのコードをかけるとは思わないし、
できたとしても到底使う気にならないと思います

607 ：デフォルトの名無しさん：2011/08/16(火) 09:45:35.21

>>575
今までだって質問者の意図無視した>>487みたいなコード連発してたのに、
なんで今回に限ってそんなこと言うのかな？もしかして書けないから？

608 ：デフォルトの名無しさん：2011/08/16(火) 10:08:38.15

>>592
これってドメインモデルでもトランザクションスクリプトでもないよね
これでいうところのSQL内にロジック（Logic in SQL）　に当たる
良い悪いかは別として、今回の議論の対象とは違うような

Martin Fowler's Bliki in Japanese - ドメインロジックとSQL
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

609 ：デフォルトの名無しさん：2011/08/16(火) 10:10:57.87

>>592
俺がドメインモデルで書くならこうする(フィールドに対するコンストラクタ省略)

class 科目{
　int 単位;
　int get単位(){
　　return 単位;
　}
}
class 人{
　List<科目>　既修科目リスト
　List<科目>　履修科目リスト
　int get既修科目数(){
　　return 既修科目.size();
}
　int get既修単位合計(){
　　int result = 0
　　　for(科目既修科目 : 既修科目リスト){
　　　　reuslt +=　既修科目.get単位();
　　　}
　　return result;
　}
　// 履修科目も既修科目と同じメソッドを用意(共通処理部分はメソッドとして切り出してもok)
}

610 ：609：2011/08/16(火) 10:13:07.05

class 学校全員{
　List<人>　学校全員
　void 判定(判定ルール){
　　for(人 : 学校全員){
　　　判定ルール.is判定(人);
　　}
　}
}
// is単位の意味がよくわからなかったので省略
class 判定ルール{
　int 必要単位数;
　boolean is判定(人){
　　return (必要単位数 <= 人.get既修単位合計 + 人.履修単位合計);
　}
}

main(){
　まずすべてをクラスにロード
　学校全員.判定(new 判定ルール())
}

611 ：609：2011/08/16(火) 10:25:08.11

人.get既修単位合計 + 人.履修単位合計
のところは専用メソッド用意してもよかったかも

もしくはclass 人に↓のメソッド追加すればgetterは必要なかったかも
boolean is判定(判定ルール){
　return 判定ルール.判定(既修単位合計 + 履修単位合計);
　}
}

// is単位の意味がよくわからなかったので省略
class 判定ルール{
　int 必要単位数;
　boolean is判定(int 単位合計){
　　return (必要単位数 <= 単位合計);
　}
}

612 ：デフォルトの名無しさん：2011/08/16(火) 10:35:46.90

>>609
こういうツッコミを今するのは申し訳ないが、
class Foo {
Bar bar;
Foo(Bar bar) {this.bar = bar;}
Bar getBar() {return bar;}
}
こういうゲッター単一機能のクラスに、一体何の意味があるというのだろうかｗ

613 ：デフォルトの名無しさん：2011/08/16(火) 10:41:00.37

プロキシだろ。

614 ：デフォルトの名無しさん：2011/08/16(火) 10:47:05.46

>>613
まさかｗ
Foo extends Barの形でかつ、getBar()などなく、
内部で持ってるBarインスタンスなどに委譲してる、
みたいな形式とってたらプロキシだろうけど。

615 ：デフォルトの名無しさん：2011/08/16(火) 10:50:43.19

Fooを継承したクラスがbarを持ってなかったらどうするんだよ。
その場合のために一段噛ましているの、このこともプロクシという。

616 ：592：2011/08/16(火) 10:56:26.48

>>608
そうです、ファウラーでいうところのテーブルモジュール（出典：PoEAA)です

617 ：デフォルトの名無しさん：2011/08/16(火) 11:08:44.25

>>615
> Fooを継承したクラスがbarを持ってなかったらどうするんだよ。

そのFooを継承したクラスをプロクシとして使う以上、
なんからのインスタンスに委譲しようとするのでは？
インスタンスの初期化や入手をどうするか、なんてプロクシクラスの肝では？

> その場合のために一段噛ましているの、このこともプロクシという。

一段かます？　bar.xxx()とfoo.getBar().xxx()という違いや、
if (bar != null)とif(foo.getBar() != null)の違い？

618 ：デフォルトの名無しさん：2011/08/16(火) 11:13:25.87

プロクシ＝テンプレートパターン。
これでわかったか。

619 ：デフォルトの名無しさん：2011/08/16(火) 11:15:59.06

>>612
FooからえられるBarはただのBarではなくある条件を満たすことが保障されてるBarだ、とかあるでしょ

620 ：デフォルトの名無しさん：2011/08/16(火) 11:16:48.07

>>612
確かにこれだけだと科目は機能を持ちませんが、実際は科目名などのフィールドを持つはずです
あと将来的に機能がつく可能性もあります。（科目ごとに別の処理をする場合など）
また単純に構造体のような使い方でもわかりやすいというメリットがあると思います

621 ：592：2011/08/16(火) 11:17:28.59

>>609-611
このコードをドメインモデルにするとしたら典型的な問題があります
判定ルールは複数個あって、それぞれが科目リストを持っています
そして当然学生オブジェクトも科目リストを持っています
つまり
　学生.Is履修(判定ルール)
か
　判定ルール.Is履修(学生)
かどっちを実装するかが自明ではないのです

これがトランザクションスクリプトなら疑う余地なくプロシージャの中で
書き下すだけです
今回はテーブルモジュールなのでレコードに隠ぺいできるところは隠ぺいして
全体の流れはメソッド化しています

622 ：デフォルトの名無しさん：2011/08/16(火) 11:24:14.40

>>620
> あと将来的に機能がつく可能性もあります。（科目ごとに別の処理をする場合など）

一安心。

623 ：デフォルトの名無しさん：2011/08/16(火) 11:56:19.61

>>621
判定ルールって分析上ただの処理じゃないの？
学科とかそういうイメージ？

624 ：デフォルトの名無しさん：2011/08/16(火) 12:06:59.95

>>621
>このコードをドメインモデルにするとしたら典型的な問題があります
>判定ルールは複数個あって、それぞれが科目リストを持っています
？
持っていませんよ

>　判定ルール.Is履修(学生)
このメソッドも持っていませんよ

625 ：592：2011/08/16(火) 12:13:55.62

>>623
そうです。学科とか学年とか資格とかで数百個はルールがあります

>>624
日本語がつたなくて伝わらなかったようです
621の投稿は忘れてください

626 ：デフォルトの名無しさん：2011/08/16(火) 12:39:52.43

(x,y)という座標から(-y,-x)や(y,-x)、(-x,-y)を求めたいとかだったら
別個に取り出せない(x,y)からどうやって後者を生成するのだろう

>>601
別に仮想言語でも良いんでない、特定の言語に限定した話はしてないんだから

627 ：デフォルトの名無しさん：2011/08/16(火) 12:40:15.19

>>625
さっきのコードでは全員判定ルールは同一だけど、学年ごとや学科ごとに判定ルールが違うという条件を追加したい場合は、さっきのコードでは対応できないという話？
何を想定しているのかを伝えてくれるとわかりやすいです

628 ：デフォルトの名無しさん：2011/08/16(火) 13:05:34.74

>>599
P(x,0) + V(x,y)

629 ：592：2011/08/16(火) 13:16:21.17

>>627
>>609でいえば
　人.get既修科目数()
は
　人.get既修科目数(判定ルール)
にするか
　判定ルール. get既修科目数(人)
にする必要があります。
オリジナルの>>592ではc=>c.Is履修
と書いてありましたが、内部詳細としてはすでに科目オブジェクトに
学生の履修データがバインドされていたので引数がありませんでした

>>592のポイントはgetterの話だったので説明しませんでしたが
ドメインモデルの話であればこの部分が論点になるかと思って発言しました

630 ：592：2011/08/16(火) 13:18:44.87

追記
＞学年ごとや学科ごとに判定ルールが違う
というより同じ人でも複数の判定ルールがあるということです
卒業ルールとか進級ルールとか交換留学生になれるルールとか

631 ：592：2011/08/16(火) 13:25:20.34

連投ごめん。まだ舌足らずなので追記
＞さっきのコードでは対応できないという話？
というわけではなくドメインモデルでやろうとするとどっちのドメインオブジェクトに
メソッドを実装していいか悩むよね？って話です
テーブルモジュールなら横断的な処理はスクリプト的に書くことが前提なので
あまり悩まないです。かといってトランザクションスクリプトだとOOの利点が全く
生かせません。

ということが言いたかっただけで何のオチもないです

632 ：デフォルトの名無しさん：2011/08/16(火) 17:08:01.02

>>629
既修科目数を取得するのに判定ルールが必要という状況がよくわかりません

＞オリジナルの>>592ではc=>c.Is履修
＞と書いてありましたが、内部詳細としてはすでに科目オブジェクトに
＞学生の履修データがバインドされていたので引数がありませんでした
学生オブジェクトに履修科目などが保持されているのではなく、科目ごとに履修した学生オブジェクトが保持されているということかな
その場合は、科目すべてを保持しているクラスに、引数として学生を渡して、すべての科目から学生が履修している科目を取得し、その単位数の合計を求める。
(ここからは>>609->>611と同じ)その単位数の合計を判定ルールのis判定メソッドに引数と渡して判定とすればいいと思います。

>>630
詳しい状況はわかりませんが、複数のルールがある場合は、以下のようにするのが良いと思っています

main(){
　まずすべてをクラスにロード
　学校全員.判定(new 卒業判定ルール())
　学校全員.判定(new 進級判定ルール())
　学校全員.判定(new 交換留学生判定ルール())
}

>>631
判定メソッドは科目や人に直接持たせるのではなく、判定ルールクラスに持たせることでルールの変更を容易にします。

633 ：デフォルトの名無しさん：2011/08/16(火) 19:27:58.67

>>626
仮想言語でも良いんだけど、処理の内容が分からなかっただけだよ。
一応しばらく後で、Cの初期化みたいなものか、と思った。

634 ：デフォルトの名無しさん：2011/08/16(火) 20:19:35.06

結局getter使うやつはコボラー並みって話はどうなった？

635 ：デフォルトの名無しさん：2011/08/16(火) 20:38:57.18

http://hibari.2ch.net/test/read.cgi/tech/1272806908/1-100

この過疎スレも消化しといてね。＜オブラーの人たち

636 ：デフォルトの名無しさん：2011/08/16(火) 23:31:09.08

>>592
ホレ作ったぞ。
http://codepad.org/7t7xN7Iy
判定ルールにまでgetterがあるんで、
同じ状態を得られることを前提に再定義させてもらった。

637 ：デフォルトの名無しさん：2011/08/16(火) 23:40:32.03

>>592
このコードスレの流れと関係なく気になったんだけどさ、
これぐらい簡潔にしてもいいんじゃないか？
処理的にも無駄が多いぞ。

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 判定ルール.必要科目数 <= 科目計;
}

638 ：デフォルトの名無しさん：2011/08/17(水) 02:25:02.06

>>634
コテンパンにされたよ。getter不要って言っていた奴が。

639 ：592：2011/08/17(水) 03:29:52.70

>>637
>>603で触れたように
科目.既修（＝科目.Is既修)
と
科目.履修（＝科目.Is履修)
は変数ではなく実装のある関数ですよ？

確認ですが、本気でこのコードのほうが>>592よりいいと思っているのでしょうか？
そうでなくて「getterなしでも実装できるよ」って言いたいだけならそれは同意します

640 ：592：2011/08/17(水) 03:31:32.22

アンカ間違えました
上のは>>636への返答です

641 ：592：2011/08/17(水) 03:47:41.41

>>637

ちょっとコード書いただけでいろいろ意見が聞けて楽しいです

実際のコードでは履修を含んで判定するかどうかの引数があるというのと
単に判定するだけでなく実際に何単位（科目）だったかを返す機能も持っている
ので４つの中間変数があった方がわかりやすいのです。パフォーマンスは問題に
ならない程度です

でも上記の理由がなかったとしても
最初に書き下すときは>>592のようになると思います
その後「これって簡潔にできるな」と思ってから最適化をして>>637
みたいになると思うのですが、これって読みにくくなると思っています
＃実際>>637よりは>>592のほうが読みやすいと私は感じます
「簡潔にできるな」ではなく「明確にできるな」とか「わかりやすくできるな」
であれば変更しますが
＃もちろんパフォーマンス問題がある場合は別です

642 ：デフォルトの名無しさん：2011/08/17(水) 07:37:18.15

obj.getValue() は継続（スタックフレーム）へ値を送る次のような構文
obj.sendValueTo(continuation) のシンタックスシュガー

643 ：デフォルトの名無しさん：2011/08/17(水) 08:02:10.38

>>639
関数だろうが変数だろうが値返すんでしょ。
あと、配列を何度もなめるのは読みやすさ以前の問題。

644 ：デフォルトの名無しさん：2011/08/17(水) 08:34:53.88

>>639
この規模だと、一応書けるレベルになるな。
本来であればプログラムはでかいから、
わざわざ判定結果だけ取り出すクラスにしない。
クラスには判定結果に基づいた処理も入る。
そうなると
条件でメソッドが別れているほうが１つのメソッドを数十行の分岐で分断されるより見易い。

あと、検索条件を別クラスにしたけど、
ここはライブラリ次第。
検索用にせず単に転送用の汎用クラスとして作り
検索条件を君の様に
オブジェクトを生成したところで全て指定することもできる。

645 ：592：2011/08/17(水) 13:40:52.62

>>644
＞検索条件を君の様に
＞オブジェクトを生成したところで全て指定することもできる
検索条件のラムダ式の中でc.Is履修みたいに書けることがgetterのメリットだと思うのですが

そもそも今の流れではgetterの定義が「引数を取らない関数で、副作用を持たないもの」
だと思うのですが、それを廃止する理由がまったくわかりません

＞この規模だと、一応書けるレベルになるな
これは
＞確認ですが、本気でこのコードのほうが>>592よりいいと思っているのでしょうか
に対して「いやおれも本気でこんな書き方がいいっているわけじゃないよ」
ってことでしょうか？

646 ：デフォルトの名無しさん：2011/08/17(水) 18:31:04.45

戻り値を一切使わないって話なら
アクター厨ってことで分かり易いんだがなぁ

647 ：デフォルトの名無しさん：2011/08/17(水) 19:22:50.54

え？

648 ：デフォルトの名無しさん：2011/08/17(水) 20:06:27.26

ぶっちゃけやけになってるけど、getter嫌いでも別に、lengthとか、countとか
setterでセットしたものが、そのまま出てくるわけじゃなきゃどうでもいいと
思ってるヤツは多いと思う。

649 ：デフォルトの名無しさん：2011/08/17(水) 20:55:49.00

より邪悪なのはsetterのほうだからな

650 ：デフォルトの名無しさん：2011/08/17(水) 22:05:49.83

これで独立できる

売るものはスマートフォンアプリ　WEBサイト運営
サーバーはクラウド VPS
電話はスマートフォンSkype
オフィスは地方にプレハブ型の格安高性能オフィスを建て(300万～500万)
レンタル自習室＆シェアオフィスで収入を得ながらそこで開発する
http://tinyurl.com/43xmk7m
http://tinyurl.com/3mopkfy

651 ：デフォルトの名無しさん：2011/08/17(水) 23:37:43.41

>>648
そもそもgetter嫌いなんて「多いと思う」とかいうほど居たか？www
変なのが一人で暴れてただけだろ

652 ：デフォルトの名無しさん：2011/08/18(木) 01:46:20.51

数人居た気がした

653 ：デフォルトの名無しさん：2011/08/18(木) 07:36:32.46

おれ昼とか仕事で書き込んでないけど
勝手にgetter嫌いな話が進んでるし割りといる。
getterというかプロパティ嫌いな人は多いんだろ。

654 ：デフォルトの名無しさん：2011/08/18(木) 09:25:38.00

まあ基本的にこのスレの議論の答えは出ないから発散したままでいいんじゃない
お互い考える機会になるし、お互い負けそうになったら退散するしｗ
まだ気になることがあるなら突っつけば負けず嫌いは帰ってくる

655 ：デフォルトの名無しさん：2011/08/18(木) 14:39:55.55

プロパティがあったほうがソースが見やすいわかりやすいと思う
これだけで使いたくなる

656 ：デフォルトの名無しさん：2011/08/18(木) 17:11:13.55

UNIX　C++環境で仕事してるんだが
お前らボタンとか画面とか作れていいな
ひたすらsocketで内部処理
オブジェクト系とかさっぱり分からん

657 ：デフォルトの名無しさん：2011/08/18(木) 18:54:37.77

いや別にOOPだからってボタンとか画面作れる訳じゃないし
逆にOOPじゃないからってボタンとか画面作れない訳じゃないぞ

658 ：デフォルトの名無しさん：2011/08/18(木) 19:23:35.12

暗にOOPなんてボタンとか画面作るくらいしか
能がないって言ってんじゃね？

659 ：デフォルトの名無しさん：2011/08/18(木) 19:45:59.10

しかしだな、C++である以上それを言う立場としては微妙で、きっと素だと思うんだよな

660 ：デフォルトの名無しさん：2011/08/18(木) 22:38:57.05

さてID:Zno7HWwt0を特定するかｗｗｗｗ
http://hibari.2ch.net/test/read.cgi/news4vip/1313638404/

661 ：デフォルトの名無しさん：2011/08/18(木) 22:42:45.77

内部処理だからOOしてないというのは…
むしろMVCを気にせずMの部分だけがっつりOOできるじゃないか

662 ：デフォルトの名無しさん：2011/08/18(木) 23:37:53.33

Socket使ったマルチプロセスプログラミングか。
本物のOOPじゃないか。うらやましす。

663 ：デフォルトの名無しさん：2011/08/19(金) 00:16:01.15

いや、ただの状態変移図だよ。オブジェクトなんて関係ない。
状態（データ）を関数で書き換えるだけの手続き型。

664 ：デフォルトの名無しさん：2011/08/19(金) 01:37:41.37

意味が通るように、善意に解釈すれば>>656は

GUI作りたいなぁ。
（それはさておき）オブジェクト指向は分からない。

と、言ってるのではないか。

665 ：デフォルトの名無しさん：2011/08/20(土) 19:13:23.77

オブジェクト指向が分からないとは書かれてないぞ。
オブジェクト系が分からないと書いてある。
オブジェクト系って用語は彼の造語だから、何するものか分からないが、
多分、昨今のオブジェクト指向なGUIフレームワークの事だろう。

GUI面白そうで良いな。
分野外だから、
どんなGUIフレームワークが乱立していて、
それぞれどういった長所と短所を持っていて、
どれが人気で、とか、
さっぱりわかんねぇー。
オブジェクト指向のスレと思って開いたけど、
GUIの話ばかりで会話に参加できねー。つまんね。

ってとこでしょ。

666 ：デフォルトの名無しさん：2011/08/27(土) 11:47:31.74

突然過疎ったなｗ

667 ：デフォルトの名無しさん：2011/08/28(日) 00:10:46.99

お盆が済んだってのもあるんだろうけど。
狂人が来ればまた賑やかになるさ。
OOP自体はもう熱が冷めちゃってるからね。

結局、高級アセンブラのC言語がもっとも自由度と汎用性が高いし、
安全さや開発効率なんかは、専らツールやDSLによる所が大きいし。
汎用言語でOOPする必要が有るのか無いのかは、もうどうでも良い話しだし。
どうせ、マルチスレッドの前では無力だしな。
OOPLって大したこと出来ない割りに、
その言語固有のオブジェクトに対する考え方や流儀があって、
なんつーか、ウザイ一面がある。
上手くウソを突き通そうと無駄な努力をしている感じ。
スケーラビリティーとか意味無いから。

668 ：デフォルトの名無しさん：2011/08/28(日) 00:26:05.53

おい、狂人が戻ってきたようだぞｗ

669 ：デフォルトの名無しさん：2011/08/28(日) 00:26:27.54

ｸﾏｸﾏ

670 ：デフォルトの名無しさん：2011/08/28(日) 09:10:05.59

>>667
ちょうどいい話題があるから食いついてみる

うちの会社は組み込みで大半の人がOOPや現在の先端的なITの開発手法やアーキテクチャを知らないんだけど、一応C言語でOOPしようという取り組みもある

これって意味あることだと思う？

UMLを使えるのとドメインモデルを意識して設計開発できるようになる以外に一切メリットがないような気がする
言語機能的にデザパタなどの手法はほとんど適用できないし、できたとしても本来のメリットがを享受しにくい
タスクという概念がUMLで記述できないのも困る
無理やりOOPを実装するのでコードの記述量が跳ね上がる、そこにバグが生まれる

早くC++での開発が当たり前になって欲しい
できるならJavaで…

671 ：デフォルトの名無しさん：2011/08/28(日) 09:13:04.25

意味ある

672 ：デフォルトの名無しさん：2011/08/28(日) 09:53:37.25

そんな大したことじゃなくね
Hoge* hoge = Hoge_new();
Hoge_work(hoge);
みたいな再入可能モジュールをオブジェクト指向だと言い張るだけだろ

673 ：デフォルトの名無しさん：2011/08/28(日) 10:16:10.28

だけとつけるだけで強くなれる気がした

674 ：デフォルトの名無しさん：2011/08/28(日) 17:03:31.50

>>670
GObjectが何で存在すんのかしらべてみ。

675 ：デフォルトの名無しさん：2011/08/28(日) 17:24:41.89

> GObjectが何で存在すんのかしらべてみ。

なんで存在すんのか？
C言語がヘボイからか？

676 ：デフォルトの名無しさん：2011/08/28(日) 19:45:39.58

いつまでオブ指語ってんだよ

677 ：デフォルトの名無しさん：2011/08/28(日) 19:48:27.58

スレタイよめよ

678 ：デフォルトの名無しさん：2011/08/28(日) 19:55:11.74

じゃあ、デブ脂について
カタリスレにしようぜ。

679 ：デフォルトの名無しさん：2011/08/30(火) 08:01:26.31

>>674
まあ中二病的発想だろうね
三年生ともなれば経済ってもんが大まかにでも分かって来て個々人が自分自身の為に精一杯頑張る事が
最も社会（彼らは地球・世界・市民といった表現が好きなようだが）の為になるって事に気付くもんだけど

680 ：デフォルトの名無しさん：2011/08/30(火) 22:24:31.31

やべぇやべぇよ。流れを元に戻さなきゃ。

GObject？まーあれだな、中二病的発想だろうね。

681 ：デフォルトの名無しさん：2011/08/31(水) 18:52:17.32

仏敵ぶっ倒せ！【ぶってきぶったおせ！】
創価学会に敵対する人物を、読経により学会員全員で呪い殺す為のスローガン。

学会員には年初にマス目を塗りつぶせるポスターが配られる。
読経の度にマス目を塗りつぶし、1千万遍唱え全部塗りつぶせると、仏敵は死ぬと信じられている。

まさに世界が危険認定済みのカルト集団。

国は創価学会を早く解体させるべき。公明党と分離させるべき。政教一致は憲法20条違反だ。

マスゴミは真実を報道しろ。

682 ：デフォルトの名無しさん：2011/08/31(水) 20:16:42.94

とあるJavaの既存システムを解析しているところなのですが、なぜかサブパッケージ単位で構造が異なっていて、
Front - Service - Dao+Entityのトランザクションスクリプト型と、
Front - Facade - Domain(O/R Mapper)のドメイン駆動型が入り混じっています。

設計書は残っているのですが開発時のメンバーは居らず、
なぜこんなことをしたのか意味不明な状況です。
一つのシステムで複数の設計思想を使用する理由として何か考えられるものはあるでしょうか。

683 ：デフォルトの名無しさん：2011/08/31(水) 21:38:13.83

カプセル化
隠蔽される部分には何を混ぜてもよい
そもそも実装を解析することはカプセル化に反する

684 ：デフォルトの名無しさん：2011/08/31(水) 22:13:22.37

>>682
みんな馬鹿だから設計を知らない。

それが答え。

685 ：デフォルトの名無しさん：2011/08/31(水) 22:15:10.28

>>683
お前は、ソースコードを書くことは
カプセル化に反すると言ってるのか？
まったく関係ないものをつなげるなよ。

686 ：デフォルトの名無しさん：2011/08/31(水) 22:49:03.54

いちゃもんじゃねーかw
まったく関係の無い事言って煽るなよ。

687 ：デフォルトの名無しさん：2011/08/31(水) 23:03:45.52

実装を解析、、、カプセル化に反する？
ソースコード見てはダメというのがカプセル化の目的？

なにいってるんだ？

688 ：デフォルトの名無しさん：2011/08/31(水) 23:26:02.92

か　た　こ　と

689 ：デフォルトの名無しさん：2011/09/01(木) 07:14:19.49

やはり合理的な理由はなさそうですね。
EJBで各々の実体が別のサーバに入ってるとかならまだ話もわかるのですが。

幸いどちらも綺麗な設計しててお互いが干渉している部分もないので、
そういうものだと思って解析することにします。
レスありがとうございました。

690 ：デフォルトの名無しさん：2011/09/01(木) 08:37:57.46

実装を解析するな。カプセル化に反する

691 ：デフォルトの名無しさん：2011/09/01(木) 09:09:13.16

解析していい思想とダメな思想の両方を使え
単一の思想では行き詰まる場合があるから複数の思想を用いる

692 ：デフォルトの名無しさん：2011/09/01(木) 12:06:15.50

お互いに干渉しないように作れるなら
設計思想を揃えることに合理性がないからな

693 ：デフォルトの名無しさん：2011/09/01(木) 20:35:30.01

>>675
>>679
>>680
こんなヤツらがOOをドヤ顔で語ってんだからすげぇ～わ。

694 ：デフォルトの名無しさん：2011/09/01(木) 21:26:49.62

>>691
お前馬鹿じゃね？

既存のコード修正する人が
そのコードを解析しないでどうするよｗ

695 ：デフォルトの名無しさん：2011/09/01(木) 21:52:48.84

>>690
OOのカプセル化は、透過性を持たせ拡張性を維持するためのものであって、
人が見ない為じゃないんだけど。

696 ：デフォルトの名無しさん：2011/09/01(木) 22:44:25.19

透過性？

697 ：デフォルトの名無しさん：2011/09/01(木) 23:01:51.60

派遣先の社員が「カプセル化するな！中身がみえないだろ！」と言ってきたので
何の事かと訝しんでたらアウトライン機能でコードを畳んであるだけだったのを
思い出しました。

698 ：デフォルトの名無しさん：2011/09/01(木) 23:29:36.08

>>696
実体がどうであれ、同じ手順で期待する結果が得られることを透過性という。
OO以外であれば、ファイルシステムなんかが有名所。
ファイルシステムの実体がExtであれ、NTFSであれ、XFSであれ、仮想ディスクであれ、
SFTPであれ、zipアーカイブであれ、デヴァイスであれ、基本的にopen,read,write,closeだけ使ってれば、
問題なく操作できる。

逆に、ファイルシステム側からopen,read,write,closeを持っているアプリケーションを見た表現を仮想という。

699 ：デフォルトの名無しさん：2011/09/01(木) 23:32:09.85

OOで透過性って頭おかしいだろ

700 ：デフォルトの名無しさん：2011/09/01(木) 23:36:17.47

>>699
根拠をどうぞ。

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.

701 ：デフォルトの名無しさん：2011/09/01(木) 23:37:38.21

>>699
オブジェクトが透過性を無視した振る舞いをすると最悪クラッシュするけど？

702 ：デフォルトの名無しさん：2011/09/01(木) 23:45:46.18

状態持ってる透過性ｗ

703 ：デフォルトの名無しさん：2011/09/01(木) 23:48:43.26

↑参照透過性と間違えてるバカ

704 ：デフォルトの名無しさん：2011/09/02(金) 08:10:16.33

さすがにこれは恥ずかしい

705 ：デフォルトの名無しさん：2011/09/02(金) 23:29:55.52

OOPLって、開発規模が大きくなるにつれて、
開発効率がC言語に近づいてくる。
問題はOOPLの範疇の外で起こってるのかもね。

706 ：デフォルトの名無しさん：2011/09/02(金) 23:47:50.19

>実体がどうであれ
>transparency is facilitated through the use of interfaces

例えば、実体のメンバーが全部publicでも、interface型にキャストすれば問題無い。
原理的にprivateは不要。
privateがなくなったらC言語に近くなる。

707 ：デフォルトの名無しさん：2011/09/02(金) 23:50:47.89

>>705
それはどういう事なんですか？
そもそも、非大規模においてはOOPLとC言語のどちらが開発効率が高いと主張してるんですか？
OOPLの範疇の外ってどういう事ですか？
それはC言語においては範疇の外ではないんですか？
なんですか？設計がそもそも問題だ、とかそういう主張をされたいんですか？

708 ：デフォルトの名無しさん：2011/09/02(金) 23:56:54.68

>>706
＞原理的にprivateは不要。
＞privateがなくなったらC言語に近くなる。
意味がよく分からないのですが、privateがなくなったらC言語に近くなるっていうのはどういう事ですか？
カプセル化の恩恵が受けられなくなって、安全性が減って、契約事項が増えるって事だと思うんですが、
それがC言語に近くなるって事なんですか？

709 ：デフォルトの名無しさん：2011/09/03(土) 00:29:39.71

考えりゃ分かるけどなぁ。
private無くなる→カプセル化はファイル単位、ヘッダで区別。ってことでしょ。
機能モジュール単位内では実装に直接アクセス。
機能モジュール単位外にはインターフェースを渡してカプセル化。
C言語では昔ながらの割と普通のやり方。

710 ：デフォルトの名無しさん：2011/09/03(土) 00:44:52.63

>>709
OOPの話してるから、てっきりクラスオブジェクトの話をしてるのかと…。
＞カプセル化はファイル単位、ヘッダで区別。
カプセル化、というか昔ながらの隠蔽って表現が似つかわしいですね。

711 ：デフォルトの名無しさん：2011/09/03(土) 00:54:12.37

たとえC言語でも構造体の内部の名前空間は別個になってるので、
＞カプセル化はファイル単位、ヘッダで区別。
とはならない気がするんですが、
オブジェクト様の物を使う場合の話をしているのではなく、
globalほげほげとかの話してますか？
だったらそれは完全に"カプセル化"ではなく"隠蔽"と表現すべき物ですよね。
あとインターフェースってのはexternほげげ、とかの話でしょうか？

712 ：デフォルトの名無しさん：2011/09/03(土) 01:12:32.49

何言ってんだコイツ。てっきり初心者の振りした煽りかと思っていたら、
本当に、初心者だったようだ。

>　たとえC言語でも構造体の内部の名前空間は別個になってるので、
>　＞カプセル化はファイル単位、ヘッダで区別。
>　とはならない気がするんですが、
名前空間とカプセル化は関係ないだろ。
名前空間が別でも、publicになってて直接アクセスしてたら
その部分はカプセル化されてねーよ。

>　あとインターフェースってのはexternほげげ、とかの話でしょうか？
昔ながらのWin32的なAPI関数のインターフェースもありうるし、
COM風の関数テーブルでも良いだろうし。
C言語は何でもありだから。

713 ：デフォルトの名無しさん：2011/09/03(土) 02:01:33.88

>>712
カプセル化について話す時に>>711の1行目は確かにおかしいですね。
オブジェクト様の物を作る事に頭が支配されすぎてました。
自分で見直しても何言ってんだコイツ、なのでそう思われるのはもっともです。

で、>>709を飲み込めました。
>>706は"privateがなくなったらC言語(でのOOP)に近くなる。 "
って事だったんですね。

714 ：デフォルトの名無しさん：2011/09/03(土) 05:10:50.76

シングルトンなら分割コンパイルでの公開制御だけで代用出来るんだろうが
同種のオブジェクトが複数存在することを考えると
構造体のがやはり近い気がするなあ

715 ：デフォルトの名無しさん：2011/09/03(土) 10:32:03.18

>>714
クラスの話とインスタンスの話を混ぜてない？

716 ：デフォルトの名無しさん：2011/09/03(土) 11:08:49.18

>>715
その通り、混ざってないとこんなヘンテコな話の流れになってないってことを言いたいんだよ

717 ：デフォルトの名無しさん：2011/09/03(土) 12:01:46.33

ヘッダに構造体のメンバを晒さないように作ってもいいが、実際問題として
private_hoge_というメンバにモジュール外から直接アクセスする奴がいるかもしれないとか考えるのは
リフレクションでprivateフィールドにアクセスされることを想定するようなもんだろ

718 ：デフォルトの名無しさん：2011/09/03(土) 13:23:36.03

>>717
その辺は、プログラマの統制をコーディング規約で取るか
言語の文法で取るかって話だから、
C言語に限定すれば、一般論で言ってアローでアクセス出来る構造体の
メンバを直接参照しにいくのは当然ある。

リフレクションで見るっていうのと比較するなら、
「ヘッダに構造体のメンバを晒さないように作って」るのに、
外部でその構造体のポインタからオフセットでアクセスするようなもんじゃないの？

結局プロジェクト内でコンセンサス取れてればどんな方法でもいい訳で、
労力の多少はあっても、アクセス制限のやり方なんて別になんでもいいだろ。

719 ：デフォルトの名無しさん：2011/09/03(土) 20:05:51.55

なんつーか、public/privateって、
相手が誰なのかって概念が抜け落ちているような。
一応、friend指定とかもあるけどさー。
同じネームスペース内にあるものは、全てfriend扱いでも良い気がする。

720 ：デフォルトの名無しさん：2011/09/03(土) 20:10:51.66

>>719
リアルに友達いないお前がfriendとか、笑わせんなよ

721 ：デフォルトの名無しさん：2011/09/03(土) 21:11:04.17

Javaにはパッケージスコープがあるし.NETにはアセンブリスコープがあるぞ

722 ：デフォルトの名無しさん：2011/09/03(土) 22:26:49.75

privateってさ、基本的な話じゃだけど、interfaceじゃ無いんだよね。
protectedやpublicと似てるけど、全くの別物。protected、publicは通信のために用意されてる区分で、
privateは、あくまでペイロードを格納する領域。禿も言っていたが、
本来publicなどと同じ場所に書かれるべきじゃ無いんだけど、パフォーマンス上の都合で
publicやprotectedと同じ場所に置いてる。privateを外にだすと結局pimpに近いことしなくちゃならないからね。

723 ：デフォルトの名無しさん：2011/09/03(土) 22:35:18.66

まぁ、pimpじゃなくても、Objective-Cみたいに、束縛先の変数をクラス型のものにせず、
interface型やid型だけにするって手もあるけどね。
ただ常にinterface経由でしかアクセスできないようにすると、新しいinterfaceを持ったクラスをつくるたびに
interfaceを書く必要があって、初心者や土方にはとっつきにくい。

724 ：デフォルトの名無しさん：2011/09/03(土) 22:55:17.88

>>719
全てfirendでいいわけないじゃん。
そもそもfriendはクラス外インターフェースの指定で、
firiend指定された関数や、クラスはあくまでfirend指定したクラスの一部。
逆に、packageスコープというかinternalスコープはインターフェースの拡張じゃない。
そもそもinternalスコープはprivate領域にはアクセスできない。
あくまでもinternalなinterfaceを実現するための仕組み。

725 ：デフォルトの名無しさん：2011/09/03(土) 23:04:59.58

pimpって何？↓のページにあるpimp my libraryパターンってやつ？
ttp://d.hatena.ne.jp/xuwei/20110623/1308787607

726 ：デフォルトの名無しさん：2011/09/03(土) 23:16:26.43

Pimpi ,Pimpイデオムの事ね。

727 ：デフォルトの名無しさん：2011/09/04(日) 11:03:28.73

scalaはprivate[hoge]とかやるとhogeパッケージのメンバまではアクセスできるとかできるよ

728 ：デフォルトの名無しさん：2011/09/04(日) 15:54:00.34

>>722
ポインタがパフォーマンスに悪いって、Cではあまり気にしないね
昔は、アセンブラに比べてCは遅い遅いと言われていたらしいし
C++になってまた速さを気にしだしたのは先祖返りなのかな

729 ：デフォルトの名無しさん：2011/09/04(日) 17:49:17.36

>>728
C++よりも洗練された構文を持つ言語が増えて来て
速度で優位に立たないと存在意義が保てないからだろう
低レベルを触れるというだけならCのFFIを持ってれば良いだけだし

730 ：デフォルトの名無しさん：2011/09/04(日) 19:04:55.13

>>728
具体的には、ポインタがというよりヒープの問題だけどね。
OSや環境によりけりだけど、newを使うと一回のメモリ確保に最悪で
1ページ分のメモリー(1024B等)を割り当てたりするから非常に空間効率が悪い。
さらに、ヒープメモリーの空き領域特定にファーストフィット等のアルゴリズムを
走らせるんで1～3回の演算で済む自動変数とは比べ物にならないほど遅い。

ちなみに、これはC++に限らずJavaやら後発の言語でも同じ話。
独自にメモリー管理はしてるが、メモリープールの拡張や、
メモリープール内の探索同じことが起きる。

731 ：デフォルトの名無しさん：2011/09/04(日) 19:26:02.43

そもそも速さが求められるような分野で使うものじゃないでしょ

732 ：デフォルトの名無しさん：2011/09/04(日) 19:26:28.27

>>729
C++知ってるヤツだったら、他の言語でグラフィックスや、演算主体のプログラムを書こうと思わんよ。
速度も一つではあるが、それ以上にtemplateと演算子のオーバーロードが無いのが痛すぎる。
いちいち vector = matrix.mul( vector.mul( 3 ) );とかやっとられん。

733 ：デフォルトの名無しさん：2011/09/04(日) 19:28:16.95

>>731
いや普通に使う。そもそも、OOの発端は群体の計算だし。
高速計算ライブラリBlits++は、完全にOOベースだし。

734 ：デフォルトの名無しさん：2011/09/04(日) 19:28:51.33

ガチな数値計算はそれ自体がボトルネックだからメモリ確保とかどうでもいいの

735 ：デフォルトの名無しさん：2011/09/04(日) 19:35:00.31

ばかばっか

736 ：デフォルトの名無しさん：2011/09/04(日) 19:36:01.72

いや計算メインだとメモリー確保は、かなりウェイトは高い。
FORTRANが科学技術演算に使われる理由はベクトル化のしやすさだけでなく、
最初からメモリー領域を確保していてメモリー確保のウェイトがかからないからだ。
Blits++に於いてもExpression Templateによってヒープの確保はループなどでは
殆ど発生しないようになってる。

737 ：デフォルトの名無しさん：2011/09/04(日) 19:39:09.31

>>736
だからどうでもいいと言ってるんだけど

738 ：デフォルトの名無しさん：2011/09/04(日) 19:41:18.20

ばかばっか

739 ：デフォルトの名無しさん：2011/09/04(日) 19:42:01.77

まぁ、最近GPGPUが発展してきてるし、計算をCPU相手の言語がやらなきゃならない情勢が
いつまで続くか怪しいけどね。ただ、分岐が絡む演算だとまだまだCPUでの演算だわな。

740 ：デフォルトの名無しさん：2011/09/04(日) 19:43:07.06

>>737
じゃレスしなきゃいいだろ。

741 ：デフォルトの名無しさん：2011/09/04(日) 20:03:39.48

>>740
言葉足らずですまん。言語やプラットフォームに関わらず、どうせ>>736のように
メモリ確保がボトルネックにならないように作るからそれ自体のコストは問題にならないということ。
それがオブジェクト指向的でないと言われたらそうかもしれないが。

742 ：デフォルトの名無しさん：2011/09/04(日) 21:17:06.54

>>733
> そもそも、OOの発端は群体の計算だし。

どっからそんなアホなデマが...

743 ：デフォルトの名無しさん：2011/09/04(日) 22:00:44.42

>>742
>気体の分子運動を例にとると、システム全体を考えてその中の項として分子を扱うよりも、
>一つの一つの気体分子をモデル化し、それぞれの相互作用の結果をシステムとして捉える方が
>自然で取り扱いやすい。その為には小さなモデル、関連する法則、それらを一度に複数取り扱う能力が
>必要となる。こうして属性を備えたオブジェクト概念と、それに従属するメソッド概念が生まれたのである。
http://ja.wikipedia.org/wiki/Simula

Wikipediaに限らず他でも色々と書いてある。
アラン・ケイと禿が分子の群体シミレーションに発想を得たというのは、
そこそこ知られた話。

744 ：デフォルトの名無しさん：2011/09/04(日) 22:02:24.06

その話出してくると思ったｗ

745 ：デフォルトの名無しさん：2011/09/04(日) 22:06:10.43

>>744
「思った」
で？

746 ：デフォルトの名無しさん：2011/09/04(日) 22:08:37.41

実際できないことはないよ
相互作用計算がO(N^2)だったりして圧倒的に重いからそこだけ上からやっちゃえば
他はオブジェクト指向的に扱っても全然問題なし

747 ：デフォルトの名無しさん：2011/09/04(日) 22:09:57.58

>>745
怒んなやｗ　反論でもいちゃもんでも何でもないんだから。まさに、思っただけ。

748 ：デフォルトの名無しさん：2011/09/04(日) 22:13:42.78

とすると>>742の発言はただのアフォってことになるけど？

749 ：デフォルトの名無しさん：2011/09/04(日) 22:16:40.25

？　ワシャ>>742のことまでは知らんよ。

750 ：デフォルトの名無しさん：2011/09/04(日) 22:20:23.74

>>743
群体とやらを調べてから出直してこいよ。

751 ：デフォルトの名無しさん：2011/09/04(日) 22:24:02.42

多体問題だな
MDってやつ

752 ：デフォルトの名無しさん：2011/09/04(日) 22:24:14.33

生物集合体の群体の事でもいいたいの？
コロニーの事だからどうでもいいけど。

753 ：デフォルトの名無しさん：2011/09/04(日) 22:25:36.58

物理屋は多体問題っていうな

754 ：デフォルトの名無しさん：2011/09/04(日) 22:36:01.48

群体で突っ込まれて、コロニーって...さすがにアホすぎ。
まあ、どうでもいいか。

755 ：デフォルトの名無しさん：2011/09/04(日) 22:51:13.76

震災以降久しぶりにスレタイを見かけて来てみれば、お前らはまだそんな言い争いをしているのか。

756 ：デフォルトの名無しさん：2011/09/04(日) 22:53:21.38

コロニーだろうが、多体だろうが本質的に何も間違っちゃいなけど、
字面があわないと文が読めないコミュ障なのかな。

757 ：デフォルトの名無しさん：2011/09/04(日) 22:57:07.11

>>756
人のことを心配する前に、自分の日本語能力心配しろよ。

>> 間違っちゃいなけど、

758 ：デフォルトの名無しさん：2011/09/04(日) 23:06:39.55

友達居なそうだな。

759 ：デフォルトの名無しさん：2011/09/04(日) 23:09:57.65

多体問題というとどっちかというと>システム全体を考えてその中の項として分子を扱う
意味合いが強い気はする

760 ：デフォルトの名無しさん：2011/09/04(日) 23:14:22.09

>>742
http://www.atmarkit.co.jp/aig/04biz/oo.html
>単細胞生物のコロニーのようにソフトウェア・モジュール同士が
>協調動作するというプログラミング・アーキテクチャの着想を得た。
>ケイの回想によると、これを「オブジェクト指向プログラミング」と呼んだのは1967年だという。

分子云々は置いといて、コロニー(群体)そのものの話もあるわけだけど、
それについては、どういい訳するつもり？

761 ：デフォルトの名無しさん：2011/09/04(日) 23:22:47.70

「コロニーから着想する」のと「群体の計算」だと相当違うと思うんだけど、
何か言い訳が必要なのかな？

762 ：デフォルトの名無しさん：2011/09/04(日) 23:28:45.02

>「コロニーから着想する」のと「コロニーの計算」だと相当違う
ふ～ん。日本語を(ry

763 ：デフォルトの名無しさん：2011/09/04(日) 23:36:19.75

>>762
あれ？なんで最後まで書かないの？
まあ、着想と計算が一緒とはさすがに恥ずかしくていえないか。

764 ：デフォルトの名無しさん：2011/09/04(日) 23:43:09.51

> 742 名前：デフォルトの名無しさん [sage]： 2011/09/04(日) 21:17:06.54
> >>733
> > そもそも、OOの発端は群体の計算だし。
>
> どっからそんなアホなデマが...

これ書いたのあんたでしょ。
自分で「そもそも、OOの発端は群体の計算だし。」に引用符
振っといて何いってんの？
"OOの発端は群体=着想は群体"って事だろ
隠さずに言うけど、ホントに日本語勉強しなおしたら？
文法とかじゃなくて、小学校で求められる読解力の日本語をね。

765 ：デフォルトの名無しさん：2011/09/04(日) 23:58:00.66

なに熱くなってるのか知らんけど、もともと「群体の計算」なんていうアホな話は
どっから出てきたのって書いてるんだけど。

>>750 とか >>754 とか書かれたら、普通わかると思ったんだが、>>756 で逆切
れしてるような頭じゃしょうがないかな。

まあ、「群体シミレーション」なんて堂々と書く人だしね (pgr

766 ：デフォルトの名無しさん：2011/09/05(月) 00:01:27.85

群体の計算の話は俺がオリジナル。
世界ではじめて俺が言った言葉

767 ：デフォルトの名無しさん：2011/09/05(月) 00:18:42.65

コロニーの和訳が群体だろうに

768 ：デフォルトの名無しさん：2011/09/05(月) 00:30:54.54

オブジェクト指向のアイディアが群体から出てきたかそうでないかが分かると、
ソフトウェアの開発がどういう風に楽になるんだ？

769 ：デフォルトの名無しさん：2011/09/05(月) 00:37:00.58

>>768
そもそも、分子の多体問題や群体活動に類する課題にOOが向いてるという話。

770 ：デフォルトの名無しさん：2011/09/05(月) 00:40:39.64

>>767
いや、もうオレオレ解説はいらないから。

>>767
さあ？ >>733 にでも聞いてみたらいいんじゃね。

771 ：デフォルトの名無しさん：2011/09/05(月) 00:43:46.92

>>765
「群体シミュレーション」がおかしい!?
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万件以上でてくるぞ。

772 ：デフォルトの名無しさん：2011/09/05(月) 00:44:46.52

>>769
そんな超特殊な問題への適用の成否を議論することで、人類の有用な知識の総量を増やすことに
どう貢献するのか全く理解不能だな。

一つ言うなら、そういう大規模計算にオーバヘッドの大きい抽象化技術を使おうとするのが、
そもそも根本的に誤っている。OOの適用によるメリットをもう一回リストアップしてみろ。

773 ：デフォルトの名無しさん：2011/09/05(月) 00:47:09.51

>>770
http://translate.google.co.jp/
オレオレ用語だと言いたいんなら、
ここに群体って打ち込んで英語に翻訳してご覧よ。

774 ：デフォルトの名無しさん：2011/09/05(月) 00:51:20.71

>>772
特殊っつうか、もともと話の流れが高速計算分野でも
Blits++とか使うようなOOベースの開発があるって事だったわけで、
別に明日から、OOは科学技術計算のためにしろとか言っているわけじゃないんだよ。

775 ：デフォルトの名無しさん：2011/09/05(月) 00:54:26.02

>>772
そんなん言うたら>>743、もといSimulaを全否定じゃね？

776 ：デフォルトの名無しさん：2011/09/05(月) 00:59:13.86

>>771
シミレーションにつづいて simuration ですか...、ネタですよね？

>ぐぐれば5万件以上でてくるぞ。

ひょっとして、グーグルすらまともに使えないのか？

"群体シミュレーション" ⇒ 65件
"群体シミレーション" ⇒ 0件

777 ：デフォルトの名無しさん：2011/09/05(月) 01:02:16.05

>>776
ちょっと性格わるいよ

778 ：デフォルトの名無しさん：2011/09/05(月) 01:03:35.30

まあ、人間も群生体だからな
ミトコンドリアとかよく俺らといっしょに生きてるよな

779 ：デフォルトの名無しさん：2011/09/05(月) 01:04:56.98

>>772
基本的にOOの概念そのものがオーバーヘッドを生むんじゃなく
実行環境次第だから、別に大規模計算にOOが向かないわけでもないぞ。
template使ったり、LLVMで実行時インライン展開したり、
GPUとかベクトル回路を抽象化したりとか色々実装手段は有るわけだし。

780 ：デフォルトの名無しさん：2011/09/05(月) 01:06:19.55

>>776
さっきから揚げ足取りしかしてないように見える・・・

781 ：デフォルトの名無しさん：2011/09/05(月) 01:10:33.24

>>773
誰も「用語」って書いてないんだけど、変な電波受信してるんか？

群体も Colony も、>>743 のリンク先に出てこないだろ。
気体分子の集まりを群体とか言う奴はちょっとおかしいと思った方がいい。
明らかに違うものだから。

>>777, >>780
いや、まじめな話、"群体シミュレーション" の検索結果見てみりゃわかると思うけど、
世間で群体シミュレーションなんて用語はほとんど使われてないよ。

782 ：デフォルトの名無しさん：2011/09/05(月) 01:12:34.02

>>776
で？「群体のシミュレーション」だったりしたら違うわけか。
揚げ足取りはどうでもいいから、本質的に何が問題なのか
具体的に書いてみろよ。

783 ：デフォルトの名無しさん：2011/09/05(月) 01:14:09.17

>>781
>>760にコロニーってでてんじゃん。

784 ：デフォルトの名無しさん：2011/09/05(月) 01:16:08.28

>>781
群体シミュレーションを用語として使ったわけじゃないけど？
群体のシミュレーションと書いてなかったのが不満なわけ？

785 ：デフォルトの名無しさん：2011/09/05(月) 01:24:00.13

>>781
分子等の群の体系をColonyとして表現する人や、
Colonyを使って説明しようとする人はぼちぼちいるんだけど。
ttp://www.ncbi.nlm.nih.gov/pmc/articles/PMC1243806/
ttp://www.waseda.jp/wias/researchers/plofile/prof_k_endo.html

786 ：デフォルトの名無しさん：2011/09/05(月) 01:31:10.01

このスレいつ来ても揚げ足取りが居るな

787 ：デフォルトの名無しさん：2011/09/05(月) 01:34:07.61

>>786
あいつら得るもののないクソレス伸ばして何が楽しいんだろうな

788 ：デフォルトの名無しさん：2011/09/05(月) 01:41:05.77

>>782, >>784
初めから、「群体」なんて関係のない言葉使うのがおかしいって書いてあるんだが、
理解できてないってことなの？

>>783
> 「コロニーから着想する」のと「群体の計算」だと相当違うと思うんだけど、

いや、区別できないというなら、別にそれでもいいけど。

>>784
論文の対象によって、そういう説明することもあるけど、そのリンク先にも
「一般的な『群体』とは生物などで定義される細胞の集合」
って書いてあるでしょ？それが普通の解釈。

789 ：デフォルトの名無しさん：2011/09/05(月) 01:48:04.78

それを揚げ足と言うんだけどなぁ。
プレステをファミコンと呼んで、ファミコン貸してくれって言われて、
これはPSだから、これはPSだからって言ってるガキと
大して変わらないことにいつになったら気づくのかねぇ。

790 ：デフォルトの名無しさん：2011/09/05(月) 01:59:49.93

普通ファミコン貸してくれって言われたら「プレステのことか？」って聞くだろ。

同じように >>750 でちゃんと調べろって言われてるのに、コロニーとか言い出す
アホガキはどっちなんだろうね (w

791 ：デフォルトの名無しさん：2011/09/05(月) 02:14:15.09

やっぱこいつ友達いないわ

792 ：デフォルトの名無しさん：2011/09/05(月) 02:33:29.76

うん、そういうアホガキの友達はいらないから。

793 ：デフォルトの名無しさん：2011/09/05(月) 08:39:33.18

ヒープメモリー貸してくれって言われて、これは遅いから、これは遅いからって
最適化が揚げ足取りを助長している

794 ：デフォルトの名無しさん：2011/09/05(月) 08:46:19.08

>>788
> 初めから、「群体」なんて関係のない言葉使うのがおかしいって書いてあるんだが、

え？>>742にはそんなこと書いてなくね？

お前が無知さらしたあげく発狂してるようにしか見えんが？

795 ：デフォルトの名無しさん：2011/09/05(月) 09:15:38.65

>>793
なんかうまいこと言おうとしてるのは伝わるけど、意味不明な文章にしかなってない。

まあ、>>742 に「群体」ってはっきり書いてあっても、「書いてなくね？」って、アホ晒し
ている奴もいるし。

そこでわからなくても、>>750 見ればわかると思ったんだけどね。

796 ：デフォルトの名無しさん：2011/09/05(月) 09:20:37.94

そりゃ、>>742で「普通は郡体なんて言葉使わねーよ」的なことを
書いてたら>>788にも説得力あったけどね。
実際は「どっからそんなアホなデマが...」だからね。

まあ、お前がアホで無知でもいいじゃん。今までそれで生きて来れたんだろ？

797 ：デフォルトの名無しさん：2011/09/05(月) 09:35:10.70

>>779
実行環境や細かい最適化よりもまずアルゴリズム次第だ
例の分子動力学シミュレーションに限るならOOは全くオーバーヘッドにならんぞ
相互作用だけなんとかすればスクリプト言語でも余裕

798 ：デフォルトの名無しさん：2011/09/05(月) 10:01:46.30

お前らの話を聞いてると、こういう会話が思い浮かんだ

おっさん「わしゃ、デジタルなんぞ判らん！」
若造「あんたのその言い方が、デジタルなんだよ！」

799 ：デフォルトの名無しさん：2011/09/05(月) 10:13:59.49

このスレの正しい道は、どの分野でOOが適しているか、
またどの分野で適していないかをリストアップしていくことだな。
それができないなら何の意味もない。

800 ：デフォルトの名無しさん：2011/09/05(月) 10:21:59.97

>>771
> simuration

m9(^Д^)ﾌﾟｷﾞｬｰｰｰｯ

801 ：デフォルトの名無しさん：2011/09/05(月) 10:27:50.53

>>796
>>750, >>754, >>765 まで書いてあれば普通何が馬鹿にされてるかぐらい
気づきそうなもんだけどね。

まあちょっと頭冷やしたほうがいいんじゃね？

802 ：デフォルトの名無しさん：2011/09/05(月) 12:58:20.16

>>801
分子でなかろうが、群体の計算から着想を得たってのは事実だし、
それをデマだって書いた時点であんたの負けだよ。

803 ：デフォルトの名無しさん：2011/09/05(月) 15:43:39.59

>>802
だって、「群体の計算」なんてわけわからんこと書いてあったら、デマって書くしかないでしょ？

デマじゃないと言うなら、「群体の計算」って書いてあるソース示せばいいんじゃね？

804 ：デフォルトの名無しさん：2011/09/05(月) 16:48:22.97

別に間違ってるところないんじゃないかなぁ・・・って思う

805 ：デフォルトの名無しさん：2011/09/05(月) 17:51:23.62

群体スレ作ってそっちで一生やってろよ。

806 ：デフォルトの名無しさん：2011/09/05(月) 18:05:04.55

ていうか突っかかるところじゃないのにものすごくこだわってるキチ外をいちいち相手にしちゃうのがダメ
なんでスルーできないの？
こういうスルーできない奴も荒らし扱いにするべき

807 ：デフォルトの名無しさん：2011/09/05(月) 18:21:51.07

>>786
Scalaスレに迷い込んだのかと思った

808 ：オマエモナァ～：2011/09/05(月) 18:35:29.85

>>806
そうだよね～、「群体の計算」なんてねよく知りもしないこと偉そうに書いちゃいました、ごめんね

って書けばすむのにね (w

809 ：デフォルトの名無しさん：2011/09/05(月) 18:55:40.01

>>797
流石にスクリプトはキツいぞ。
Perl見たいな疑似インタプリタなら別だろうけど。

810 ：デフォルトの名無しさん：2011/09/05(月) 19:09:23.42

そういうのは、普通にCかC++で良いよな。
無理してスクリプト言語で書く必要ないしな。
つーか、下手なスクリプト言語よりC++の方が使いやすいし。
汎用向けのスクリプト言語ってマジ意味ないと思う。
DSLにしたって、HLSLやSQLレベルまで作りこまないと使い物にならないし。
コンパイラや処理系がバグ持ちだったりするしな。
世界標準で最古からあって、これからも永遠に不滅で、
枯れてて、誰でも知ってて、何処でも動く、
C言語割とマジで最強。
C++も良かったんだけど、0xで死ぬかもな。

811 ：デフォルトの名無しさん：2011/09/05(月) 19:13:15.91

C言語は最古じゃないぞ…

812 ：デフォルトの名無しさん：2011/09/05(月) 19:19:26.02

>>808
用語じゃなくてただの日本語だろそれ
日本人じゃないの？

813 ：デフォルトの名無しさん：2011/09/05(月) 19:26:29.30

また基地外が帰ってくるからやめてっ!!

814 ：デフォルトの名無しさん：2011/09/05(月) 19:28:58.40

で？
元はなんだっけ？
>>742に対して>>743出したらうんこが噛み付いてきたんだっけ？
でやっぱり>>742は大嘘吐きの糞野郎ってことでこの話もう終わってるんだろ？
新しい話題ねーじゃん

815 ：デフォルトの名無しさん：2011/09/05(月) 20:07:36.01

この間のゲッターセッターの盛り上がりのほうがまだ実があったぞｗ

816 ：デフォルトの名無しさん：2011/09/05(月) 20:42:57.18

>>812
包含関係ってわかる？
日本人なら、普通にわかってると思ったけど、君には難しかったみたいね。

>>814
> この話もう終わってるんだろ？

終わってる話、蒸し返すほど悔しかったの？

817 ：デフォルトの名無しさん：2011/09/05(月) 21:17:27.10

どうでもいいがこのスレのせいで群体の揚力係数とか
群体の抗力係数なんてもんが有ることを知った。

818 ：デフォルトの名無しさん：2011/09/05(月) 21:22:03.96

結局、>>742は、白と黒しかない、デジタル野郎って事だな

819 ：デフォルトの名無しさん：2011/09/05(月) 21:52:23.79

で、君は白しかない「白知」野郎ってことで。

820 ：デフォルトの名無しさん：2011/09/05(月) 22:11:14.92

「無敵くん」とは、
ネット上の掲示板等での議論において、結論はすでに明白なのに、負けているのに負けを認めず、
相手が諦めるまでつまらない反論を次から次に持ち出してずるずると引き延ばし続ける者のこと。

http://dic.nicovideo.jp/a/%E7%84%A1%E6%95%B5%E3%81%8F%E3%82%93

821 ：デフォルトの名無しさん：2011/09/05(月) 22:20:41.75

>>820
自己紹介乙。

822 ：デフォルトの名無しさん：2011/09/05(月) 22:22:19.59

>>819
http://www.netis.mlit.go.jp/NetisRev/Search/NtDetail5.asp?REG_NO=CB-000025&TabType=&nt=
ここでは、護岸ブロックの集まりの事を群体と読んでるねぇ

英語のコロニーには、集落とか植民地ってのも含まれるし
使われ方としては「一定の範囲に集まると意味を持つ集団、集合」って事なんじゃない

Objectって言葉だって、日本語的に捕らえると相当あいまいな言葉だし

823 ：デフォルトの名無しさん：2011/09/05(月) 22:39:33.56

一生懸命ググってきたんだろうけど、それこそ「無敵君」状態になってるよ (w

そもそもいろんなものを「群体」って呼ぶことがあるのは >>784 に書いてあるし、
それについても >>784 のリンク先に書いてあるように、一般的とは言えない。

824 ：デフォルトの名無しさん：2011/09/05(月) 22:49:27.90

四六時中現れるおかしいよって意見と延々と一人で戦い続けて何も思わないのかねぇ。

825 ：デフォルトの名無しさん：2011/09/05(月) 22:50:28.96

>>823
そんなに正確な表記が好きなら、>>819の様な無様な間違いはしないほうが良いと思うの

826 ：デフォルトの名無しさん：2011/09/05(月) 22:51:18.80

すげーどうでも良い。
群体スレでも立ててそっちでやってよ。
ここは群体スレじゃないんだからさ。

んーじゃ、仕方ないから。
マーク&スイープのガベコレって要る？
結局メモリの管理しかしてくれないし。
ファイナライザでデッドロックとかしたら嫌だなぁ。

827 ：デフォルトの名無しさん：2011/09/05(月) 22:53:40.45

>結局メモリの管理しかしてくれないし。

GCに何を求めてるんだよｗ

828 ：デフォルトの名無しさん：2011/09/05(月) 23:00:14.01

別にガベコレはOOと関係なくね？
OOPLじゃなくてもLispみたいにガベコレ実装してる言語あるし、
OOPLでも参照カウント式とか自己管理式とかあるし。

829 ：デフォルトの名無しさん：2011/09/05(月) 23:06:02.60

そうかなぁ。ファイナライザの問題はOO特有だと思う。

830 ：デフォルトの名無しさん：2011/09/05(月) 23:14:10.30

VB6.0のオブジェクト機構って、割と理想的だったな。
VB自体バカしか使わないから、バカにされる存在でしかなかったけど。
クラスを継承すると、インターフェースだけ継承された。
もちろん実体継承できたに越したことはないが、実体を持つクラスを
継承する場合も実体継承しないようにできるってのは、他の言語でも欲しい機能だ。
インターフェースが不要になる。

831 ：デフォルトの名無しさん：2011/09/05(月) 23:19:06.13

>>830は半年ROMっておいたほうがいい。

832 ：デフォルトの名無しさん：2011/09/05(月) 23:20:35.13

ファイナライザというと大きく範囲がブレるでしょ。
1.Java,.net環境のファイナライザ
2.関数型言語や、Perl等手続きベースの側面で見た場合の後片付け。

1.だと一部のOOPLの話
2.だと自動リソース解放が絡む言語全般の話。

833 ：デフォルトの名無しさん：2011/09/05(月) 23:23:41.67

>>831
なぜ？VBの継承概念はCOM由来だったからか？
それとも親クラスに対する期待を子クラスが裏切れるからか？

834 ：デフォルトの名無しさん：2011/09/05(月) 23:31:20.36

実際、クラスをextendsに書いたら実装継承、implementsに書いたら
インターフェース継承になるようになってたら便利だったろうけどな。
インターフェースとクラスの定義が別れてるなんて結局実装上の都合じゃん。

835 ：デフォルトの名無しさん：2011/09/05(月) 23:49:51.81

パッケージスコープなメンバが使えなくなるよ

836 ：デフォルトの名無しさん：2011/09/05(月) 23:53:37.34

それはパッケージスコープのある言語特有の話でしょ。
あと、親がパッケージスコープなら子もパッケージスコープにすればいいでしょ。

837 ：デフォルトの名無しさん：2011/09/06(火) 00:12:15.31

>>834
なぜ「便利」を肯定して「都合」を否定するのかさっぱりわからない

838 ：デフォルトの名無しさん：2011/09/06(火) 00:20:13.81

>>837
相手すんなし。時間の無駄の気配がプンプンしやがる。

839 ：デフォルトの名無しさん：2011/09/06(火) 00:24:22.96

都合より、利便性を取るのは普通じゃね。
例えば大人の都合だらけのEC++はだれも寄り付かず、
便利なフリースタンディングのC++に流れて行ったしね。

840 ：デフォルトの名無しさん：2011/09/06(火) 00:24:50.71

>>836
それじゃパッケージスコープの意味がないだろ
パッケージ外からみれば隠蔽されるべき実装の詳細なんだから

841 ：デフォルトの名無しさん：2011/09/06(火) 00:36:20.81

意味がちょっと解らないなぁ。
今までだって、継承でパッケージスコープのあるクラスを継承できたわけでしょ。
何が引っかかるの？

842 ：デフォルトの名無しさん：2011/09/06(火) 00:42:15.77

微妙に流れに乗ってみる。
実装継承の意義って、デフォルトの実装が得られる以外あんまり解からん。
純粋仮想クラスばっかり使うのに比べて、実装継承が無いと無理ってな事って
デフォルト実装以外にあるの？まぁ、テンプレートを使う場合は別だろうけどさ。

843 ：デフォルトの名無しさん：2011/09/06(火) 01:02:41.45

>>841
サブクラスのパッケージが別の場合、
実装を継承しないとパッケージスコープのメンバが使えなくなるだろ?

844 ：デフォルトの名無しさん：2011/09/06(火) 01:11:28.72

>>842
ダックタイピングなら仕様の継承は不要だから
消去法的に実装継承は必要という見方がある

もちろん、消去法は詭弁であって両方とも不要だという意見もある

845 ：デフォルトの名無しさん：2011/09/06(火) 01:14:09.62

別に使えなくてもいいじゃん。
使う気があったら実装継承するだろうし。
まぁ、継承してパッケージスコープに介入ってのもどうかとは思うけど。
それなら移譲で受け取ったオブジェクトを経由してパッケージにアクセスするでしょ。

846 ：デフォルトの名無しさん：2011/09/06(火) 01:18:40.34

>>844
ダックタイピングであれデフォルト実装の域を出ないよね。

SmalltalkやObjective-Cみたいな、そもそもオブジェクトを生成できないとか
そういうレベルの問題があるケースってないんかねぇ。

847 ：デフォルトの名無しさん：2011/09/06(火) 01:20:28.94

>>846
そうじゃなくて、スーパークラスが属するパッケージ内の他のクラスが
スーパークラスのパッケージスコープメンバに依存してるかもしれないだろ
設計の良し悪しはともかく現実にはよくあるでしょ

848 ：847：2011/09/06(火) 01:21:35.39

すまん>>845の間違い

849 ：デフォルトの名無しさん：2011/09/06(火) 01:24:40.50

>>843
なんかそれって危なくね？
子クラスが、別パッケージの親クラスの、internalメンバーにアクセスする訳だろ。
internalなメンバーって、Eclipseのライブラリなんかだとバージョンによって
消えたりするよな。

850 ：デフォルトの名無しさん：2011/09/06(火) 01:32:00.40

>>847
なるほどね。
パッケージスコープがある言語においてはそうだね。

851 ：デフォルトの名無しさん：2011/09/06(火) 05:46:01.21

そもそも実装の継承って本当に必要なの？
GoFやEffective Javaなんかでは実装継承より集約を薦めているけど

852 ：デフォルトの名無しさん：2011/09/06(火) 06:54:32.80

Windowクラスとか、実装の継承の方がよくね？
DefWindowProc相当とか俺かけねーよ。

853 ：デフォルトの名無しさん：2011/09/06(火) 07:14:06.79

そもそもwindowを継承する必用があるのかってのも疑問だけど。
描画とか変更するんであれば、描画処理を行うオブジェクトを
差し替えてやるべきだろうし。
毎回描画処理を差し替えたwindowを作るのが面倒なら
ファクトリーの出番でしょ。
やるかどうかは別として、結構委譲ですませられる
とこは多いね。

854 ：デフォルトの名無しさん：2011/09/06(火) 09:19:48.08

>>851
マーチンファウラーは実装の継承を、
これはいい差分プログラミングだ、とおおはしゃぎしてたようだが。

855 ：デフォルトの名無しさん：2011/09/06(火) 16:24:08.31

>>853
それはそうだけどRADで都合が悪い
アプリケーションレベルの設計まで持ち込んだGUIフレームワークは糞

856 ：デフォルトの名無しさん：2011/09/06(火) 16:34:40.08

>>854
そういえばファウラーの継承についての意見を見たことないんだけど書籍やホームページに彼の主張が書いてあるところないかな
とりあえずぐぐってみる

857 ：デフォルトの名無しさん：2011/09/06(火) 16:40:11.93

リファクタリングにあるのか
一般的なモデル部分ではわざわざ実装継承をしろっていう主張はほとんどなさそうだな

委譲と継承:カタコト備忘録 http://app.f.m-cocolog.jp/t/typecast/568631/1012090/51728131

858 ：デフォルトの名無しさん：2011/09/06(火) 22:29:39.08

>>855
スレの趣旨とずれるが、RAD、RADとよく聞くが、
VBとVS.net環境以外でRADを本格的に使ったりするかな？
俺の周りだと、なんだかんだしてるうちに、レイアウト崩壊したり、
結局コード上でレイアウト変更するん事になって無意味な場合が多いぞ。

859 ：デフォルトの名無しさん：2011/09/06(火) 23:04:35.85

レイアウトマネージャあればそうそう崩壊しないと思うが…

860 ：デフォルトの名無しさん：2011/09/06(火) 23:37:44.48

>>824
> (「群体の計算」なんて) おかしいよって意見と延々と一人で戦い続けて何も思わないのかねぇ。

そうだよねぇ、俺もそう思うよ (w

>>825
指摘、ありがと。
IME は、自主規制してるのか知らんけど、変換できないからつい見落としたよ。

って、間違ってたら普通に訂正すればいいだけなのに、コロニーとか (w

861 ：デフォルトの名無しさん：2011/09/07(水) 09:06:32.11

>>860
自分の間違いをIMEの所為にするのは良くない

862 ：デフォルトの名無しさん：2011/09/07(水) 09:19:08.21

>>859
なんのRADだったか忘れたが、
有償のRADツールで画面編集して保存したら壊れて開けなくなった。
それ以来トラウマ。

863 ：デフォルトの名無しさん：2011/09/07(水) 18:45:55.15

ワンチップ組込み屋だが、実装の継承は滅多に使わんな。　集約が中心。　Cで深い継承を書くのはしんどい。
OOはメンバーのユニオンなんてメモリ効率の良い器用な事はできないが、思考がすっきりする事と、楽ちん。
制御組込みでUMLを使うなんて夢にも思ってなかったが．．．　ｗ
かつて、モジュール設計とかなんたらで悩んでいたのはいったいなんだったのか？
応答速度？　何でも有りのワンチップだよ　君　ｗ　PCの世界とは違う。

864 ：デフォルトの名無しさん：2011/09/08(木) 01:39:43.01

組み込みはどうでもいいよ。

あんな小規模プログラム、
別にOOを使うまでもない。

あ、組み込みで大規模なら
OO使うのはあたりまえだよ！

865 ：デフォルトの名無しさん：2011/09/08(木) 01:50:29.42

組み込みでオートマトンを組むなら、OOがキャストいらずで楽。

866 ：デフォルトの名無しさん：2011/09/08(木) 06:02:33.77

うちは組み込みで大規模だが、OSに近いところだとif文1つでも減らそうとしてる

867 ：デフォルトの名無しさん：2011/09/09(金) 23:39:53.70

それがたとえ一回しか呼ばれなくても？

868 ：uy：2011/09/11(日) 16:57:55.49

まだOOスレがこんなに勢いもってるとか
本当にレベルが低いなぁ

進化が遅い

869 ：デフォルトの名無しさん：2011/09/11(日) 17:00:05.48

ポケモンゲットだぜ！

870 ：デフォルトの名無しさん：2011/09/11(日) 17:45:16.94

>>868
アスペルガー思考のスレにでも行ってろよ。

871 ：uy：2011/09/11(日) 21:34:04.90

ゴミグラマは死ね　　　死ねゴミグラマ

872 ：デフォルトの名無しさん：2011/09/16(金) 21:25:01.79

継承とは何だったのか
Getter/Setterとは何だったのか

873 ：デフォルトの名無しさん：2011/09/17(土) 13:25:42.85

>>872
そんなのオブジェクト指向の本質とはなんの関係もない

874 ：デフォルトの名無しさん：2011/09/17(土) 13:31:39.36

え？

875 ：デフォルトの名無しさん：2011/09/17(土) 13:31:39.50

継承とはポリモを仕込む仕組み。
Getter/Setterとはインタフェースの一例。

876 ：デフォルトの名無しさん：2011/09/17(土) 14:22:12.41

俺定義ではインターフェイスも継承ですか？

877 ：デフォルトの名無しさん：2011/09/17(土) 20:29:30.15

すみません、バッチ系で上手くOOを使うには
どんな設計が良いのでしょうか？

それとも、バッチ系はOOを使用しない方がいいのでしょうか？

878 ：デフォルトの名無しさん：2011/09/17(土) 21:43:15.43

バッチ系はRubyでok

879 ：デフォルトの名無しさん：2011/09/17(土) 21:57:33.49

言語選びの話じゃないと思うが…まあ、どっちにしても質問が曖昧だわな
逆に今までOOを何に使ってきたんだろうか…？

880 ：デフォルトの名無しさん：2011/09/17(土) 22:34:47.32

ばっち

って、プログラム群を処理目的ごとに区切り、この区切り毎に順次実行してゆくバッチ処理のことを指していると思われ。
たしかにOOって意味ない
まぁでも絶対使っちゃ駄目ってレベルでもないわなw

881 ：デフォルトの名無しさん：2011/09/18(日) 12:42:12.86

>>872
継承はinheritって機能の訳語で、
言語構文に依存した名前でしょ。
ハンドルの継承とかディスクリプタの継承とかと同じ汎用的な意味で、
"継承"という言葉自体はOOに専属しているわけじゃない。

882 ：デフォルトの名無しさん：2011/09/18(日) 12:47:28.01

ばっち処理でOO活かす機会なんていくらでもあるだろ。
こういうのとかグラフ処理とか。

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);

883 ：877：2011/09/18(日) 20:09:36.98

>>878
Rubyだと何がバッチ処理にいいんですか？
教えて下さい。

884 ：デフォルトの名無しさん：2011/09/18(日) 20:59:47.83

どうせIOバウンドだからRubyが使えるんでしょ
信者なら Rubyが使える=Rubyを使わなければならないだから

885 ：デフォルトの名無しさん：2011/09/18(日) 21:14:16.39

batつっても何をやりたいかによるでしょ。
よくある手順、既にコマンド化されてるものを順番に流すだけとかファイルを移動するだけなら
シェルスクリプトが一番簡潔だろうし、デリミタだけで分けてあるデータを元に処理するなら
awkがやりやすいだろ。CADデータの変換とかならC++じゃないとまずやってられないし。

886 ：デフォルトの名無しさん：2011/09/18(日) 21:20:33.98

>>885
.bat だけがバッチ処理ではないぞ…

887 ：デフォルトの名無しさん：2011/09/18(日) 21:23:02.75

解ってるよ。
話外れるが、汎用機だとbat処理というとsh系の処理を指すことが多いね。
スクリプト有りきみたいでなんかちがうけど。

888 ：デフォルトの名無しさん：2011/09/18(日) 21:24:38.30

>>887
てことはバッチ処理のことをbatと呼んでたのか
…かなり誤解を招きやすい表記だと思うのだが

889 ：877：2011/09/18(日) 23:26:07.21

何かバッチ処理を理解されていない人が多いので聞きたい事を詳細に書いてみます。

一般的なOOが使われているのはWin３２・Webアプリなど対話型（リアルタイム処理）です。
対話型では現状の状態を持たせているオブジェクト指向と相性がいいのですが（アクターモデルやメッセージパッシングなど）
バッチ処理では、データを長期間保持する必要はありませんし、オブジェクトを作成が逆に
オーバーヘッドになってしまいます。

レスポンスが一番求められるバッチ処理で、オブジェクト指向の上手な使い道は何でしょうか？

890 ：デフォルトの名無しさん：2011/09/18(日) 23:28:51.57

オブジェクト作成がバッチ程度でボトルネックになるなんてありえんから気にすんな。
使う環境にもよるが、大抵処理はインライン展開やスタックフレームの割付に変わる。

891 ：877：2011/09/19(月) 00:54:14.50

一般的にバッチ処理は非常に強力なマシンパワーを必要とします。
その為いまだに、バッチ処理は汎用機で行うのがメインです。
（汎用機とはホストです、WSやServerではありません）

今年起こった、みずほ銀行の障害も夜間バッチが朝までに処理出来なかった為です。
（PCより何千倍早い汎用機でも、何時間も掛かるのです）

このようバッチ処理では、リアルタイム処理より処理速度が数段厳しく求められます。
少しの処理速度の違いでも大量データでは、処理速度の差が大きく現れます。

892 ：デフォルトの名無しさん：2011/09/19(月) 00:58:59.25

そういうのは、だいたいlistでやることをvector使ってるとかアルゴリズムそのものの問題でな。

893 ：デフォルトの名無しさん：2011/09/19(月) 01:36:11.50

>>891
オープン系サーバでのバッチ処理も今はあるけどね

894 ：デフォルトの名無しさん：2011/09/19(月) 05:54:15.00

>>891
構造から変えないとダメだろうな
オブジェクトの生成で左右されるような作りにしちゃダメ
そのレベルのことを気にするのであればメモリ管理をＯＳにまかせちゃダメ
でかい領域をもって全部自分で管理

895 ：デフォルトの名無しさん：2011/09/19(月) 07:12:28.86

他にも出来るところはSQL式DBを使わないとかね。
テキストファイルにするだけでもかなり早くなる。
バイナリーならなお早い。

896 ：デフォルトの名無しさん：2011/09/19(月) 10:50:55.93

SQL式DBは、バイナリファイルだよ。

897 ：デフォルトの名無しさん：2011/09/19(月) 11:37:31.99

バイナリーだろうがテーブル結合が大規模だしSQLの解析計算に
偉い時間が掛かるんだよ。
目的とする操作単純なら単純な程その無駄がボトルネックになってくる。

898 ：デフォルトの名無しさん：2011/09/19(月) 11:44:55.32

>>897
え？まさか
テーブル結合しない場合とテーブル結合した場合を比較してるの？
それじゃ比較になってないだろｗ

899 ：デフォルトの名無しさん：2011/09/19(月) 11:49:08.47

OOだから遅いとかあまり関係ないと思う、設計の問題でしょ。
OOだけで遅くなるとしたら、関数参照だけではないかな?（C++の場合)
いっとくが、オブジェクトをあちこちで生成・廃棄するのがOOじゃないからな！！
後は言語依存のコンパイラの性能、C++はそのオーバーヘッドがとても少ない。

900 ：デフォルトの名無しさん：2011/09/19(月) 11:49:10.97

>>897
お前のは小規模システムでの話しかしてないな。
大規模システムでは、マシン一台じゃおいつかないから複数台連携する。
そういうときにバイナリファイルで複数マシン連携とかやってられない。

901 ：デフォルトの名無しさん：2011/09/19(月) 11:51:54.04

だからテーブル結合しないようなデータをDBから取り除く方が
OOから単なる手続きに組み直すより効率をあげられるって言ってるの。

902 ：デフォルトの名無しさん：2011/09/19(月) 11:55:42.72

>>900
大規模システムなら単純なマスターをDBから外して
共有ファイルにするのは常套手段だと思うけど。
保険屋とかに卸すERPなんかで良くつかわれてんじゃん。

903 ：デフォルトの名無しさん：2011/09/19(月) 12:04:41.32

共有ファイルとか、時代遅れの技術だな。
そんなんじゃ適切なロックもかけられやしない。

SQLサーバーのように、ファイルの読み書きはサーバーに要求を投げるだけ。
あとはサーバーが適切に要求を処理しファイルを読み書きしデータを返す。

サーバーがやるべき処理がSQLというクエリーにまとまっているから
並列動作させやすい。統計データとクエリーの内容から最適な方法でデータ取得を行える。

パフォーマンスなんて必要ない小規模なシステムでは意味が無いだろうが。
大規模なシステムではSQLサーバーなどを使うことで大幅なパフォーマンス向上が行える。

904 ：デフォルトの名無しさん：2011/09/19(月) 12:13:30.99

>>903
保守でもなきゃ書き換えないデータでロックとか同期とかバカだろ
ものによってはファイルのタイムスタンプが変わらない限り
メモリーにキャッシュしっぱなしなんだぞ

905 ：デフォルトの名無しさん：2011/09/19(月) 12:16:15.09

>>904
あぁ、それはSQLでも同じだよ。

906 ：デフォルトの名無しさん：2011/09/19(月) 12:22:49.72

実際SQLでやると遅いんだからしょうがないわな。

907 ：デフォルトの名無しさん：2011/09/19(月) 12:27:49.06

>>906
だからそれは小規模の世界の話だってｗ

908 ：デフォルトの名無しさん：2011/09/19(月) 12:32:58.69

ERPが小規模かよ笑わせる

909 ：デフォルトの名無しさん：2011/09/19(月) 12:37:50.93

逆に小規模なら全部DBにいれといてもいいんだけどな。
だんだんと規模が広がると設計で某伊藤のコンサルがきたりして
速度あげろとか言われ、しこしこボトルネックの切り離しを行っていく。

910 ：デフォルトの名無しさん：2011/09/19(月) 12:42:53.04

>>908
お前が遅いって言ったデータを取ったのが
小規模なだけ。

ERPでは普通はSQLサーバーを使っている。

911 ：デフォルトの名無しさん：2011/09/19(月) 12:47:19.99

マスター全部DBに入れてて、しかもSQLサーバー限定ってどこのERPだよ。
少なくともSAPじゃねえよなあ。

912 ：デフォルトの名無しさん：2011/09/19(月) 12:54:28.71

>>911
調べておいで。

ERP製品一覧
http://techtarget.itmedia.co.jp/tt/news/1010/04/news03.html

913 ：デフォルトの名無しさん：2011/09/19(月) 12:56:13.58

http://www.softes.co.jp/faq/basis/basis06/index.html
SAP ERPは、DBMSとして　Oracle,SQL Server,DB2,Infomix,SAP DBなどを使用することができます。

914 ：デフォルトの名無しさん：2011/09/19(月) 12:58:25.10

言っとくがSQLサーバーってのは、汎用的な意味で
製品名のMicrosoft SQL Serverじゃねえからｗ

915 ：デフォルトの名無しさん：2011/09/19(月) 13:00:17.39

>>912
使ったこと無いのにカタログだけで語ってたのかよ

916 ：デフォルトの名無しさん：2011/09/19(月) 13:02:25.21

で、調べてきた？

917 ：デフォルトの名無しさん：2011/09/19(月) 17:05:48.29

流行りならHadoopとかあるだろ
Javaだから言語的にはOOPだ
実際どうやって書くものか一切知らないが

918 ：デフォルトの名無しさん：2011/09/19(月) 18:57:14.48

>>913
だからどうしたんだよ。
最初から単純なマスターを切り離してるっていってんだから
他のデータでDBに依存すんのは当然だろ
現実に単純なマスターをDBからファイル化されてることの
反証でもなんでもない。
日本語でググレるドキュメントは無いから、
ファイルにできる証拠が欲しいなら会社にあるERPの仕様を読んでみろ。

919 ：デフォルトの名無しさん：2011/09/19(月) 19:53:07.48

で、調べてきた？

920 ：デフォルトの名無しさん：2011/09/19(月) 20:33:43.92

仕様が解るドキュメント持ってないのか、
学生は黙ってろよ。

921 ：デフォルトの名無しさん：2011/09/19(月) 22:28:23.55

で、調べてきた？

922 ：デフォルトの名無しさん：2011/09/20(火) 01:32:29.31

しょーもない構造体にgetterやイベントなんかつくってられっかよ。

規模に応じて使い分けろアホども。

923 ：デフォルトの名無しさん：2011/09/20(火) 03:26:04.10

>>718にレスしてるのか？構造体って。

924 ：デフォルトの名無しさん：2011/09/22(木) 15:56:02.05

>>891
MapReduceすればいいのでわ

925 ：デフォルトの名無しさん：2011/09/22(木) 15:58:00.76

>>910
普通はSQLServerかよ
Oracle EBSならそれはないｗ

926 ：デフォルトの名無しさん：2011/09/23(金) 18:57:27.01

一般名詞としてのSQLサーバと固有名詞としてのMS-SQLServerをごっちゃにしてる人が居ると聞いて

927 ：デフォルトの名無しさん：2011/09/23(金) 20:22:36.76

まさかと思ったが>>914で告白してるのか。インターネットとIEを混同する位ありえねぇな。

928 ：デフォルトの名無しさん：2011/09/23(金) 21:32:49.03

SQLサーバとか言う？
普通DBサーバとか言わね？

SQLサーバって意味わかんないんだけどw

929 ：デフォルトの名無しさん：2011/09/24(土) 07:35:32.05

きっとSQL文が一杯入ったサーバーだよ。

930 ：デフォルトの名無しさん：2011/09/24(土) 11:47:27.90

どうでもいいけど言わせてくれ。
プログラマ同士だとたまにあるだろ？
プログラミング言語をいくつ使えるか、
みたいな競争が。そこにSQL入れてるやつってどうなのよ。
データベースにクエリを発行するためのもんをそこに入れるかね。

931 ：デフォルトの名無しさん：2011/09/24(土) 12:39:50.93

有用性と難解性を考えれば、入れても良いと思う。

932 ：デフォルトの名無しさん：2011/09/24(土) 14:02:50.72

>>928
開発現場でDBサーバーの事SQLサーバー何て言ってたらすげえ危険だよ
MSのSQLサーバーの事を
指してるのに、DBの一般名詞として解釈されたりして
現場が混乱しまくる。

933 ：デフォルトの名無しさん：2011/09/24(土) 15:32:03.60

SQLを解釈するサーバがSQLサーバで、
データベースを管理してるサーバがDBサーバだろ。
通信系だとそうなんだけど、業務系の業界の文化は知らない。

「現場」でひとくくりにされても困る。

934 ：デフォルトの名無しさん：2011/09/24(土) 15:57:01.52

>>930
4GLも立派な言語だと思うけど、SQLのLも言語だし。

>>933
DBサーバーのなかにSQLサーバーも含まれると思うけど。

SQLサーバーと言ったら、ハードのPC自体を指すから
>>910のSQLサーバーは本来ならRDBとかRDBMSとかを使った方が意味は伝わると思う。

ハード（サーバー機）とソフト（DBMS）の用語が曖昧に使われていると思う。

935 ：デフォルトの名無しさん：2011/09/24(土) 16:42:11.42

そもそもの奴がRDBが全てだと思ってるんだよな。
postgreもMySQLもDB鯖かつSQL鯖だろ。
Berkley DBならDB鯖であってSQL鯖でないと言える。

936 ：デフォルトの名無しさん：2011/09/24(土) 18:04:23.52

SQLサーバーが一般用語なんて知らんかったわ。
まぁ既知者の間でも分かれているようだけど。

937 ：デフォルトの名無しさん：2011/09/24(土) 18:15:33.92

「IME」みたいなもんさね
本来はWindows上で漢字変換などのシステムを動かすための仕組みであって
MS-IMEはそのひとつでしか無いんだが、MS-IMEのことをIMEと呼ぶ人間が後を絶たない

938 ：デフォルトの名無しさん：2011/09/24(土) 19:56:34.40

なんか違う気が。

939 ：デフォルトの名無しさん：2011/09/24(土) 22:27:39.31

この業界ってわかりにくい例え言ってどや顔するのが流行ってるの？

940 ：デフォルトの名無しさん：2011/09/24(土) 23:45:37.13

>>938
何が違う？俺には似たようなもんだと思うのだが。

941 ：デフォルトの名無しさん：2011/09/25(日) 00:06:08.64

いや、もうくだらないからシネ

942 ：デフォルトの名無しさん：2011/09/25(日) 00:10:12.58

死にたくないなー
まあ、でも確かに本筋からはズレてるな、すまぬ

943 ：デフォルトの名無しさん：2011/09/25(日) 02:13:34.53

>>926 = >>933 = >>937 = >>940

944 ：デフォルトの名無しさん：2011/09/25(日) 02:21:27.64

http://www.google.co.jp/search?sourceid=chrome&ie=UTF-8&q=SQL%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC

SQLサーバーをSQLを使ったDBとして書いてるところなんて無いね。
一般名詞 = 個人的範囲外で通じる言葉
なので別にSQLサーバーは一般名詞じゃないな。

だいたいOracle DBの事を一般名詞のつもりでSQL Serverと呼んで
他の人が製品のSQL Serverの設定準備をしてしまうとかトラブルになるだろ。

945 ：デフォルトの名無しさん：2011/09/25(日) 02:22:48.69

>>940
一般人は呼んでも、技術者は区別するし。

946 ：デフォルトの名無しさん：2011/09/25(日) 02:24:56.04

>>935
SQLを解釈するのはDBであってサーバーの役割じゃないし
SQLとサーバーをひもづける理由なんて殊更ないし

947 ：デフォルトの名無しさん：2011/09/25(日) 02:31:35.96

どうしても今回のことをIMEで例えたいのなら、
RDBの事をSQLサーバと呼んでいたわけだから、
IMEの事をMS-IMEと呼んでいた、が正解。
MS-IMEの事をIMEと呼んでいた、は例として可笑しい。
逆だ逆。

948 ：デフォルトの名無しさん：2011/09/25(日) 09:40:40.50

DBとDBMS、DBサーバーをごっちゃにして理解している人も多いよね。
話してるとなんとなく話は通じてるみたいだけど、
微妙なところで認識ずれがありそうで怖い。

949 ：デフォルトの名無しさん：2011/09/25(日) 12:35:41.64

>>947
RDBのことSQLサーバじゃなくて、MS-SQLServerのことをSQLサーバじゃなかったのか

950 ：デフォルトの名無しさん：2011/09/25(日) 14:55:58.50

>>914

951 ：デフォルトの名無しさん：2011/09/25(日) 15:36:47.08

例えばSKKもサーバーであるように、SQLもサーバーといえばサーバーといえなくも。

952 ：デフォルトの名無しさん：2011/09/25(日) 15:41:48.39

サーバ、クライアントってのも文脈によって、
ソフトウェアとしてのものと、
ハードウェアとしてのもののどちらかを指してる。

953 ：デフォルトの名無しさん：2011/09/25(日) 15:42:52.53

>>952
soket ならサーバ・クライアントは絶対的意味において固定なのですが？

954 ：デフォルトの名無しさん：2011/09/25(日) 16:13:52.60

>>951
SKKを殊更サーバーと呼ぶこともないし意味が解からん

>>952
S/Cは別に相対関係を表してるだけだから、
ハードだろうがソフトだろうが混在しても
問題になる事はないでしょ。
Webサーバーとhttpdをごっちゃにしたって
機能が全然違うからSQL Serverみたいに間違えることはまずない。

955 ：デフォルトの名無しさん：2011/09/25(日) 20:01:51.55

SQLサーバーって言い方がまずおかしいだろ
普通はDBMSかRDBに限ればRDBMSだろ
普通DBMSって言ったらRDBMSのことで
KVSっていったらNoSQLデータベースのことだろ
あとはISAMデータベースだけど、DBMSの範疇ではないな。MySQLが特殊なだけで。

956 ：デフォルトの名無しさん：2011/09/25(日) 20:11:37.44

>>933
>SQLを解釈するサーバがSQLサーバで、
それはSQLパーサーまたはSQL Nodeだろう
それに対になる言葉ならストレージエンジンだろう。

957 ：デフォルトの名無しさん：2011/09/25(日) 20:15:43.92

>>951
SQL(RDB)でもスタンドアローンで使っているシステムもあるので
サーバーだと限定は出来ないと思いますよ。

958 ：デフォルトの名無しさん：2011/09/25(日) 20:17:34.79

つうかSQLだけを解釈するDBサーバーなんて無いし。
スキーマやら、DBそのものの管理やらSQL以外の機能は沢山ある。

959 ：デフォルトの名無しさん：2011/09/25(日) 20:58:29.30

通信の世界での用語と言っている以上、そうなんだろうなぁとしか言えないような。
俺は寡聞にして知らないけど。
普通なら「SQLサーバーが一般用語www」で終わるところ、ここまで長引いてんのもそこが追求できないからでしょ。
業界通()笑さんはおらんのかね。

960 ：デフォルトの名無しさん：2011/09/25(日) 21:09:37.25

1人しか主張してない時点でオレオレ用語でしかないし
それを相手してるから無駄にレスが伸びてるだけだろ

961 ：デフォルトの名無しさん：2011/09/26(月) 00:17:26.79

2人主張してないか？俺ともうひとり最初に言った人

962 ：デフォルトの名無しさん：2011/09/27(火) 22:38:41.89

一般用語と取られてもおかしくない曖昧な単語を、
固有名詞だと主張してる時点でおかしいんだよ。

そんな奴に技術者としてのプライドがあるか怪しい。

963 ：デフォルトの名無しさん：2011/09/27(火) 22:46:17.87

SQL Serverと検索しても、MSのアレしかひっから無いんだから
もはや一般語でも無いだろ。それは置いといてもSQL Serverって
名前自体が意味合い的におかしいけどな。

964 ：デフォルトの名無しさん：2011/09/28(水) 18:24:47.15

それは俺も言おうと思ってた。
でも、postgreSQLとかもあるし。

965 ：デフォルトの名無しさん：2011/09/28(水) 19:18:15.39

>>964
間違えてるよ

966 ：デフォルトの名無しさん：2011/09/29(木) 17:41:06.25

久しぶりにスレ見たらSQLサーバスレになってた

967 ：デフォルトの名無しさん：2011/09/29(木) 23:48:19.15

だって、RDBの方が面白いもん。

968 ：デフォルトの名無しさん：2011/10/01(土) 21:17:31.93

SQLサーバーの話題はもうおいといて。。

それなりの規模のプロジェクトで、オブジェクト指向じゃない
プロジェクトの方が珍しくない？

たとえば、10万ステップ以上程度のOSSで、
(オブジェクト指向言語ではない)Cで書かれていて、
OOPじゃない物って何かある？

調べてないけど、ほぼすべてOOPの体裁を取ってるんじゃないかと
思うんだけど、どうですかね？

969 ：デフォルトの名無しさん：2011/10/01(土) 22:13:17.55

OOPの体裁って?
ただのリエントラントなモジュールをOOPに含めるかどうかによる

970 ：デフォルトの名無しさん：2011/10/01(土) 22:22:18.70

リエントラントてｗ

971 ：デフォルトの名無しさん：2011/10/01(土) 22:44:12.30

>>968
linux kermel

972 ：デフォルトの名無しさん：2011/10/01(土) 23:00:15.17

カーネルもコマンドも自動車事故も全部合計すればいいんだよ

973 ：デフォルトの名無しさん：2011/10/01(土) 23:05:42.26

>>968
当たり前だが、OOPが広まる前の巨大システムは総てOOP以外。
今も生き残ってる物は多い、L… とか…言語系もそう。
巨大アセンブラプログラムのシステムも見た。

974 ：デフォルトの名無しさん：2011/10/01(土) 23:46:13.90

仮にOSがオブジェクト指向でできていたとして、
その上で動くアプリをオブジェクト指向じゃない書き方で作れば
それは当然オブジェクト指向ではない。

それではだ、フレームワークやライブラリがオブジェクト指向で作られているものを
単に使うだけで、オブジェクト指向とかなんも考えずに作られた
ソフトウェアはオブジェクト指向になるのだろうか。

975 ：デフォルトの名無しさん：2011/10/02(日) 00:04:09.94

ふと思ったんだが
ソフトウェアがオブジェクト指向であるかないかの必要要件が有るのだろうか?

最低要件としては、データと処理が合体して、1つのオブジェクトとして振る舞い、
　　他のオブジェクトとコミュニケーションしてシステムを制御すればいいような気がする。

そう考えた場合、フレームワークがその仕組みを強制すれば、オブジェクト指向の
プログラムになるのではないかと。どの様に作ったかは関係がないのでは?

できあがったソフトウエアの設計資料まで遡らなくてはいけないのだろうか?

976 ：968：2011/10/02(日) 00:14:27.93

レスどうもです。

Linux kernelがOOPじゃないなんて、信じられない。。
マジですか。ちゃんと読んでみます。

ものすごく古いのならともかく、まだOOPが言われるようになる前の時代の物でも
原始的なOOPの考え方はそれなりの規模のプロジェクトなら自然発生しているのでは？
と、思ったわけなんだけど、そうでもないのですね。

977 ：デフォルトの名無しさん：2011/10/02(日) 00:18:10.93

つかLinux発案者のリーナスがOOをバカにしてる
くだない(Trivial)と

978 ： ◆QZaw55cn4c ：2011/10/02(日) 00:27:59.04

実際、OO はいわれるほど革新的でも革命的でもないわけで。
というか、いろんな考え方のごった煮で、時代とともに適当に後付けで都合のいい理論を吸収してきたことが、C++ の発展の仕方をみてもよくわかる。

979 ：デフォルトの名無しさん：2011/10/02(日) 00:36:03.49

>>976
>Linux kernelがOOPじゃないなんて、信じられない。。
逆に聞きたいんですがkernelにどのようにOOを適用します？　その場合の利点は？

そもそも、なぜオブジェクトを作成してオブジェクトが
プログラムを制御する仕組みがいいのか分かりますか？

そのあたりが分かると、OOが適しているプログラムかどうかが分かると思いますよ。

980 ：デフォルトの名無しさん：2011/10/02(日) 00:37:23.12

まあ、長いことやってるけどその辺の利点を工学的にちゃんと説明できる奴はこの世にいないな

981 ：968：2011/10/02(日) 01:00:10.28

半年romってからと思ったけど、質問きたし叩かれるのもまた勉強になるのではないかと思って書きます。

> 逆に聞きたいんですがkernelにどのようにOOを適用します？　その場合の利点は？
例えばファイルハンドルなんかはカプセル化やポリモーフィズムを外部に提供している(と俺は思う）から、
十分OOPだと思ってるのです。またLinuxの実装においてもデバイスドライバを登録する時に使う
register_chrdev() 関数なんかにおいても、引数として渡す file_operations 構造体はメソッドへのポインタの
集合だし、十分OOPにおけるクラス的ふるまいだと思うのです。
というわけでOOPLでないCを使いながら外部に対してはオブジェクト指向なインターフェースを供給している
Linux kernel において、それ自身はOOPじゃないって話しだから「マジですか？」になりました。

と言うわけで
> 逆に聞きたいんですがkernelにどのようにOOを適用します？　その場合の利点は？
に対しては、ファイルハンドルやデバイスドライバとか、色々あるじゃん？　と思ってます。

あー、叩かれるのだろうか。。

982 ：デフォルトの名無しさん：2011/10/02(日) 01:06:09.61

ぶっちゃけ単なる型スイッチですからねー。
そこにカプセル化と差分プログラミングを詰め込んで、
クラスでなんでもやろうとしたのが悲劇の始まり。
クラスが全てみたいになって、勘違いする奴が続出。
元に戻そうとするムーブメントが有って、
その第一歩がマルチメソッド。
実行性能無視してでもこれを実装しようとする人たちが居たりする。
一石投じるってやつ。

983 ：デフォルトの名無しさん：2011/10/02(日) 01:06:49.35

　　　　∧___∧　　　　/ / / /
　　⊂（　・∀・）　､,Jし //　ﾊﾟﾝ
　　　（几と　ノ　　）　て.
　　／/'|ヽソ彡　Y⌒Y　｀Д´） <968
／ノ / ｜＼彡
ヽ/､/ヽ/ ヽ/ 　　　　

984 ：デフォルトの名無しさん：2011/10/02(日) 01:24:38.78

>>981
ファイルなんかはread,write,ioctlぐらいしか操作はない。
しかも、read,write,ioctlは非常に単純な情報しか知らない。
言ってしまえばvoid*。void*は値を渡す側と受け取る側は、同じデータを
指すことを期待してる。要するにプログラマ任せ。
プログラマじゃなくオブジェクトの判断に任せられるOOとは矛盾する。

985 ：デフォルトの名無しさん：2011/10/02(日) 01:31:16.90

入出力装置が何であっても、同じシステムコールで装置固有の動作をするって話でしょ？
読解力無さ杉。

986 ：デフォルトの名無しさん：2011/10/02(日) 01:54:10.36

そこは関係ないんだって事をあえて書いてあるんだろ

987 ：デフォルトの名無しさん：2011/10/02(日) 02:09:35.64

C++で書いたら、遅いって意見がアホ程出たから、
カーネルはCでしか書かないんだって偉い人が言ってた。

988 ：デフォルトの名無しさん：2011/10/02(日) 02:29:12.46

1.リーナスはC++を汚物よばわりしている
2.C++はコンパイラ間の移植性が低い(アーキテクチャごとの移植性は高い)
3.タイミングがシビアなので機械語命令からかけ離れた抽象的な機能を持つ言語は使えない
　最適化で命令を飛ばされると致命的な結果を生むことがある

989 ：デフォルトの名無しさん：2011/10/02(日) 04:05:22.74

また知ったか

990 ：デフォルトの名無しさん：2011/10/02(日) 13:49:50.55

スラドで悪いが元ネタ
1.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と同じ

991 ：デフォルトの名無しさん：2011/10/02(日) 17:18:41.69

>>981
外部にAPI/インタフェースを公開していることと、コードがOOで書かれていることは混同しちゃならんよ。
UNIX系のインタフェースを考察するなら、むしろテキストストリームのことを考えた方がいい。

http://d.hatena.ne.jp/asakichy/20100514/1273790514

LinuxがC言語でゴリゴリ書かれているのは、一番パフォーマンスに影響する部分なのだから、
抽象化すらそぎ落としたいと考えるのは当然ちゃ当然。Linusほどのハッカーが開発をしていて、
コードベースが安定しているソフトウェア（というより安定していないと困る）なら、非OOも合理的な選択だ。

あと、LinusはC++を嫌っているのであって、OO言語全般を嫌っているわけじゃないよ。
LKLMで、Linusがその辺の議論をしている過去ログを見たことがあるので、興味があれば探してみるといい。

992 ：デフォルトの名無しさん：2011/10/02(日) 18:19:35.02

>>991
>>990 のソースでOOをDisってるよ

993 ：デフォルトの名無しさん：2011/10/02(日) 18:22:22.80

本質はロッキングであってオブジェクトじゃないし、
オブジェクトを中心に考えるのは腐ってるってね。
まぁ、言うとおりだわ。ただ元祖OOを批判してるわけじゃなく
最近のクラスありきのOOを批判してんだろうけど。

994 ：デフォルトの名無しさん：2011/10/02(日) 18:30:02.33

Linux Kernelを非OOPとしていいものなんかなー、という疑問が俺にはあるわ、ちょっと前の話見てると。
ctor,dtor当たり前、とかいうレベルじゃなくて、
スケジューラとかオブジェクト指向っぽいと思うんだけどな。
構造体と関数ポインタを使ったC言語OOPは普通にやられてると思うんだけど。
Linux KernelがC++を使ってないから非OOPとするのであれば、それには異論を唱えたい。

995 ：デフォルトの名無しさん：2011/10/02(日) 18:40:34.06

OOと拡大解釈されるようなものではない、ってことでしょ。
単に処理とコンテキストが一緒になった何か。
コールバックのために仕方なくそうしているだけであって、
積極的な姿勢ではないんだろう。

996 ：デフォルトの名無しさん：2011/10/02(日) 18:49:41.07

>>994
部分的に非OOP言語によるOOP技法が適用されているからといって、
システム全体がOOP/OODであるとされるのは違和感があるなぁ....

997 ：デフォルトの名無しさん：2011/10/02(日) 18:55:56.01

>>992
> いいかい、私がそう思うのは、私が低レベルプログラミングだけをしているからかも知れない。
> 先に言った通り、私が仕事しているコードの大部分が、殆のソフトウェアプロジェクトが考え
> すらしていない事柄に非常に注意を払っている。

って本人も言ってるしね。Linuxカーネル開発者の態度としては完全に正しい。

んで、カーネルがOOで書かれていないからといって、OOの存在意義が否定されるわけではない。
OOは「責務」を抽象化して開発単位を分割できるようにするための道具なわけであり、
「慈悲深い独裁者」が開発を独裁的にコントロールできるのでは「ない」場面で有効な方法論。

Linusが、マイクロカーネルに反発してモノリシックカーネルのLinuxを始めたことを考えても、
彼がOOに否定的なのは驚くに値しない。

>>994
少なくとも、Linus本人はそう思ってないだろうな。

998 ：デフォルトの名無しさん：2011/10/02(日) 18:59:18.89

>>994
タスクのオブジェクトがスケジューラー以外で使われてる訳じゃないでしょ。
あくまでもタスク制御の為の構造なだけ。
OOみたいに古い型のオブジェクトに、新しく作った型のオブジェクトを注入するとかはしてない。

新しい型を利用する古い型も、古い型に注入する新しい型もお互いの都合をあまり知らない。
それは、オーバーフローや最適化の抑止にまで拘ってるカーネル開発じゃ危険すぎるんだよ。
古い型と重複する部分が多くても、新しい型を熟知している、新しい型を作ったほうがましって事らしい。

999 ：デフォルトの名無しさん：2011/10/02(日) 19:00:09.30

ところでLinuxはオブジェクト指向なのか？

開発言語のほとんどはC言語だろう？

C言語でオブジェクト指向なんて
不可能だし。

1000 ：デフォルトの名無しさん：2011/10/02(日) 19:04:21.78

CでならGObjectでできる

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。