OOP

1 ：デフォルトの名無しさん：2010/09/10(金) 19:44:50

OOPをネタに罵ったり罵られたりするスレ

2 ：デフォルトの名無しさん：2010/09/10(金) 21:32:49

Oops!

3 ：デフォルトの名無しさん：2010/09/10(金) 22:12:39

抽象クラスってうまいこと使えたためしがないんだが
みんなほんとに使ってんのか？

4 ：デフォルトの名無しさん：2010/09/10(金) 23:58:55

おお次スレ立ったか。サンクス。このスレ、案外有用だと思う。
終にはOOPに替わる実験言語作るところまで行ければいいな。
何が欲しい？やっぱテンプレート？

あと、前スレのインスタンス君は来なくていいから。

5 ：デフォルトの名無しさん：2010/09/11(土) 00:38:13

>クラスや継承がなかったときはどうしてたんだろう
>
>ほとんど同じだけど、微妙に違う構造体
>みたいなのがいくつかあったら継承便利だと思うんだが。

継承はポリモーフィズムの為に使う物なので
コードを使いまわすためだけに継承するのはかなり良くない

そんなことやってると機能を派生させる毎に継承が分岐して無茶苦茶に絡みあったコードになる

6 ：デフォルトの名無しさん：2010/09/11(土) 00:40:55

継承と所有の使い分け方でだいたい実力がわかる

7 ：デフォルトの名無しさん：2010/09/11(土) 02:25:45

とりあえずOOP言語放棄とか言うくらいなら、当然DCIは知ってるんだよね。

8 ：デフォルトの名無しさん：2010/09/11(土) 07:27:20

Ookina OPpai

9 ：デフォルトの名無しさん：2010/09/11(土) 08:26:53

>>4
>終にはOOPに替わる実験言語作るところまで行ければいいな。
>何が欲しい？やっぱテンプレート？
オブジェクト指向が分からないから早くも現実逃避かｗ
お前の来なくていいから。

10 ：デフォルトの名無しさん：2010/09/11(土) 08:29:34

>>9
誤：お前の来なくていいから。
正：お前も来なくていいから。

11 ：デフォルトの名無しさん：2010/09/11(土) 08:35:15

どちらにしろおかしい
恥ずかしい奴・・

12 ：デフォルトの名無しさん：2010/09/11(土) 08:35:17

>何が欲しい？やっぱテンプレート？
欲しがらないで、自分で作れよ。クソが。

13 ：デフォルトの名無しさん：2010/09/11(土) 08:49:40

無茶言うな、理解出来ないものは作れないぞｗ

14 ：デフォルトの名無しさん：2010/09/11(土) 09:08:26

>>4 みたいなのがいるからスレが荒れる

15 ：デフォルトの名無しさん：2010/09/11(土) 10:31:44

ほんとに罵りあうなよ

16 ：デフォルトの名無しさん：2010/09/11(土) 10:36:57

ネタないときにとりあえず煽っとけば出てくるかもってやつばっかだよね２ちゃんて。

17 ：デフォルトの名無しさん：2010/09/11(土) 11:50:59

このスレは明確な主旨がある訳でもないし
理想のOOPLを語るくらいイイんじゃないか？
流れをブッタぎっての発言でもないしね

18 ：デフォルトの名無しさん：2010/09/11(土) 12:10:45

複合型のインスタンスをスタックに置ける言語ってC++以外何がある？

19 ：デフォルトの名無しさん：2010/09/11(土) 12:39:25

>>5
>継承はポリモーフィズムの為に使う物
違うぞ。継承はポリモーフィズムと差分プログラミングの両方の意味を持ってる
静的型付け言語でポリモしたいだけならインターフェースを使うのが正しい

20 ：デフォルトの名無しさん：2010/09/11(土) 12:43:26

スタックに置けるというか、オブジェクトがリファレンスじゃなくて、
値としてのオブジェクトがあるということ？

リファレンス型を明示的に使わなきゃいけないOCamlなんかは、
オブジェクトが基本みんな値だと思うけど。

21 ：デフォルトの名無しさん：2010/09/11(土) 13:19:44

C#もできたと思う。stacallocだったかな

22 ：デフォルトの名無しさん：2010/09/11(土) 14:43:51

>>18
意味が分からない。

「スタック」てLIFOやFILO構造のエリアを書いているんだよな？
それなら、スタックレジスタが指しているエリアに存在すればいいだけの話。
一般型だろうがクラス型だろうがローカル変数で定義すれば
スタックレジスタが指しているエリアに出来ると思うが。

23 ：デフォルトの名無しさん：2010/09/11(土) 14:57:42

参照型はローカルで宣言してもインスタンスは別のトコに領域が確保されるよ。参照型は文字通り参照してるだけ

24 ：デフォルトの名無しさん：2010/09/11(土) 14:58:22

>>5
>コードを使いまわすためだけに継承するのはかなり良くない
>そんなことやってると機能を派生させる毎に継承が分岐して無茶苦茶に絡みあったコードになる
実体験だとおもうけど、それは君の技術力が低いから。
君と同じ技術力の無い初心者へのアドバイスなら「あり」だと思うが．．．

Visitorパターンぐらいから勉強すれば。

25 ：デフォルトの名無しさん：2010/09/11(土) 15:21:26

>>23
>参照型はローカルで宣言してもインスタンスは別のトコに領域が確保されるよ。参照型は文字通り参照してるだけ
つまり、C++をはじめスタックにインスタンス（実体）は存在しないと。

26 ：デフォルトの名無しさん：2010/09/11(土) 15:29:02

動的に確保された領域はヒープにできるんじゃないかな。基本的には

27 ：デフォルトの名無しさん：2010/09/11(土) 15:32:54

C++は両方あるよ

28 ：デフォルトの名無しさん：2010/09/11(土) 16:06:32

>>27
>C++は両方あるよ
つまり
>>23
>参照型はローカルで宣言してもインスタンスは別のトコに領域が確保されるよ。参照型は文字通り参照してるだけ
は間違っていると。　ちなみにC++では両方はどんなコードで実装されるの？

しかし、スタック上にインスタンスが有るか無いかは何が重要？
前スレから何が言いたいのかまったく分からない。
スタック君を無視しないと、また糞スレになる予感。

29 ：デフォルトの名無しさん：2010/09/11(土) 16:19:10

C++には参照型なんてないだろ？参照という名前のエイリアスっぽい機能はあるけど

30 ：デフォルトの名無しさん：2010/09/11(土) 18:19:58

>>28
ポインタ否定派か？ってレスに意味がわからんって言ってたから
>>22みたいに思ってるの？っていう意味で聞いただけ

31 ：デフォルトの名無しさん：2010/09/11(土) 18:50:24

>>28
また出てきたのか

以下が>>28の前スレでの主張ね
>オブジェクト指向の欠点
>・オブジェクトを使用するとき、インスタンスの存在チェックが必要、インスタンスが存在するものしか使用出来ない。

動的確保したらOOだろうが構造化だろうが存在のチェックは必要なんだよ
これでおしまいなのに何をグダグダ言ってんだ

32 ：デフォルトの名無しさん：2010/09/11(土) 18:55:11

スタック上にインスタンスとか言っている奴は逃げたのか？

33 ：デフォルトの名無しさん：2010/09/11(土) 19:01:08

>>32
多分、上がそいつじゃないの？
都合が悪くなると話題を変えるから。

34 ：デフォルトの名無しさん：2010/09/11(土) 19:05:19

ワザワザ書かなくても、みんな分かっているのにｗ

35 ：デフォルトの名無しさん：2010/09/11(土) 19:12:18

>>31
横からで悪いけど
オブジェクト指向のように基本機能が動的に作成するものと
構造化のように任意で動的にするのでは意味が違うと思うよ。

36 ：デフォルトの名無しさん：2010/09/11(土) 19:55:16

>>35
さらに横から。
基本機能てなんぞ？

C++でnewせずインスタンスを作る場合は、どういう位置づけ？

OOPどうこうってより、その言語の風習次第じゃない？

37 ：デフォルトの名無しさん：2010/09/11(土) 20:45:26

>>19
>>24
publicメンバー変数使ってバグが増えるのは君の技術力が低いから。

とでも言えば自分の言ってる事が分かるのかね。
継承は結合がかなり強い、だから結合を弱めるために極力避けるべき。
これはかなり当たり前の話だ。

だいたい、合成やmixinで実現できることをイチイチ継承する意味がわからん

38 ：デフォルトの名無しさん：2010/09/11(土) 21:00:58

山で狩をして暮らすよりも
平地で田んぼを耕す方が楽なのと同じ
山は遭難の危険あり

39 ：デフォルトの名無しさん：2010/09/11(土) 21:30:41

メモリー管理も理解できないレベルで語ってたのかｗ

40 ：デフォルトの名無しさん：2010/09/11(土) 22:07:51

>>24
ヒント：組み合わせ爆発。Bridgeパターン。

41 ：デフォルトの名無しさん：2010/09/11(土) 22:27:19

優秀な奴らはみんなどこかへ行ってしまったのさ。
本当みんな何処に行っちゃったんだろうな。
案外C言語に出戻ってたりして。

まともにOOPの議論したい奴はこっちへどうぞ。
http://hibari.2ch.net/test/read.cgi/tech/1127547359/
スレのレベルは俺の見た限りここより酷いが。

ネタ、ネタ、ネガがいるよね。まずキックしなきゃスレが動かないもんな。
もう一度、
object.method()ってー並び順についてウダウダする？
なんで第一引数だけ前に出すのか、
将来マルチメソッドに対応した場合の呼び出し文法はどうなるのか。
まさか　(object1, object2).method(); とか嫌だぜ。
そしてその場合、メソッドの定義は何処に書くんだ？
それに、func( object );　ではダメだった理由は何だ？
なぜ伝統に習わず急に変えた？その意味は？

42 ：デフォルトの名無しさん：2010/09/11(土) 22:41:55

しかも第二引数以降は後ろに書くんだぜ？第一引数のみ前に持ってくる。
おれは、
func( obj1, obj2, obj3 );
でも
( obj1, obj2, obj3 )func;
でもどっちでもかまわないが、
obj1.func(　obj2, obj3 );
これは嫌だ。
引数の対象性って言うんですかね（よーわからん）、それが壊れてる気がするんだよ。
つまりそれは、経験的にはどうか知らんが、数学的には間違ってるってことなんじゃないかな。
引数はどれもおなじ重みで等しく対等に扱われなきゃ変だろ？
第一引数だけ特別扱いするという対象性を欠いた発想が、
何するでも思考の妨げになってるというか、なんというか。
そこがおかしいから何やってもしっくり来ないんじゃないか。
そもそもからしてが悪問なんだと思う。

43 ：デフォルトの名無しさん：2010/09/11(土) 22:44:01

その辺の議論はLisperが詳しいと思うよ

44 ：デフォルトの名無しさん：2010/09/11(土) 22:54:06

特別扱いするからオブジェクト指向なんだが

45 ：デフォルトの名無しさん：2010/09/11(土) 23:00:20

関数型言語は魅力的なんだよなー。
単にxとかyとか言ったときに、それらの変数は何でもありで何にも無しの、何の意味も無くて、何の情報量もないんだけど、
ひとたびy=f(x)と定義すれば、xとyはfで関係が定義されて、
まーこれは、xとyがfという法の下に置かれたと考えてもいいのかもしれないし、
fというフィルタと考えてもいいのかもしれないんだけど、
どっちにしろ、xとyが秩序や機能や制約やルールの下に置かれたことになって、
そんで初めてxとyに個性が生まれるという。

これOOPだったら、xの個性を定義してーyの個性を定義してーってなるだろ。
その方向性の戦略ってどうなん。破滅パターンに見えて仕方ない。

46 ：デフォルトの名無しさん：2010/09/11(土) 23:07:40

関数型はモノつくらない人に人気。

47 ：デフォルトの名無しさん：2010/09/11(土) 23:13:31

例えばさ、仮に
y=2*x と定義したとするじゃない。
すると、yはxの2倍なんだよね。
xとyが何者かは知らんが、とにかくyはxの2倍と。
xとyのそのものの定義ははっきりしないんだけど、
だけど、関係が定義されてて、だから機能する。そんでそれが実は個性なんだと思う。
個性って本来そういう相対的なもの。
数字の「1」の定義は、他の数との関係でもって定義するしか無い。
1そのもののプリミティブな定義が無いっていう。

48 ：デフォルトの名無しさん：2010/09/11(土) 23:23:33

虚数なんてどうよ。あのイメージしにくい憎い奴。
でも関係が定義してあるからちゃんと機能する。
数学って面白いよな。関係だけで成り立ってる。
全てのものは相対的。偶数文化の極み。

49 ：デフォルトの名無しさん：2010/09/11(土) 23:30:48

コンピュータも同じだとおもうんよ。
全てのものは結局ビット列にすぎんし、
さらに細かく見ると、電気信号のHiとLowにすぎん。
物を細かく見ていっても、結局何も見えんし、何の意味も無いという。
だけど関係が定義してあるから、単なるビット列も個性を持つし、意味を持つし、機能する。
だから、オブジェクトを指向してもダメなんだと思う。
関係を指向しなきゃ。

50 ：デフォルトの名無しさん：2010/09/11(土) 23:31:50

お前のご高説などどうでもいい。

51 ：デフォルトの名無しさん：2010/09/11(土) 23:42:45

>>46
グサッ…

52 ：デフォルトの名無しさん：2010/09/11(土) 23:45:16

OOPはオブジェクトを志向するんじゃなくて、
オブジェクトとして志向するのであって
関係性もオブジェクトになりうる

53 ：デフォルトの名無しさん：2010/09/12(日) 01:18:25

またオレオレOOか

54 ：デフォルトの名無しさん：2010/09/12(日) 01:19:36

「一次情報源がないこと」
OOP関連の議論が袋小路に入る一番の問題点はこれにつきる。
誰も、納得のいく情報源を提示出来てない
そういう意味で、日本語のwikipediaは酷い

55 ：デフォルトの名無しさん：2010/09/12(日) 01:25:41

資本主義は一つだが、社会主義共産主義は色々ある。
つまりはそういうことだ。はじめからペテンなのさ。

56 ：デフォルトの名無しさん：2010/09/12(日) 01:27:57

修正資本主義は資本主義と社会主義の多重継承

57 ：デフォルトの名無しさん：2010/09/12(日) 03:05:37

勝手になりすますなや

58 ：デフォルトの名無しさん：2010/09/12(日) 03:20:37

>>52
正解。

>>53 >>54
それは最低でもMeyerとGOF本を読んだ上で言ってるのか？

59 ：デフォルトの名無しさん：2010/09/12(日) 03:56:55

もちろん。Meyerのは実質Eiffel解説本じゃん。
あれでOOを語ると、契約による設計もジェネリクスもOOの範疇になるよ？
GoF読んでもプロトタイプベースのことはわからんし
アニマルクラスでOOを語るのと同じ意味での手落ちがあると思うわけ

60 ：デフォルトの名無しさん：2010/09/12(日) 04:31:18

オブジェクトとして指向ったて、
関係性をオブジェクトにしたところで、
その関係性オブジェクトと他のオブジェクトの関係は
やっぱり関数なりで定義しなきゃいけないわけで。

61 ：デフォルトの名無しさん：2010/09/12(日) 05:26:34

もうどこから突っ込んだものか分かんないよぼかぁ

62 ：デフォルトの名無しさん：2010/09/12(日) 09:50:27

一次情報っつったらSmalltalkだろ。なんかみんな無視するけど

63 ：デフォルトの名無しさん：2010/09/12(日) 09:51:40

>>62
じゃあよろしく

64 ：デフォルトの名無しさん：2010/09/12(日) 18:19:38

何を？

65 ：デフォルトの名無しさん：2010/09/12(日) 18:55:10

俺が調べて来ておいたぞ。Alan Kayの言葉
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other
systems in which this is possible, but I'm not aware of them.

66 ：デフォルトの名無しさん：2010/09/12(日) 23:04:55

私が提唱したOOPは電文通信、局所的な記憶と保護、
状態遷移の隠蔽、極端な遅延束縛だけを意味します。
SmalltalkとLISPでそれを可能にしました。
これ以外のまがい物のことは関知しません。

67 ：デフォルトの名無しさん：2010/09/12(日) 23:58:35

超訳きた

68 ：デフォルトの名無しさん：2010/09/13(月) 00:37:33

>>41
> なんで第一引数だけ前に出すのか

逆に考えるんだ。まず、「オブジェクトにメッセージを送る」というコンセプトありきで、
それを既存の言語の枠組みで記述するのに、第一引数を特別扱いする仕組みを
流用するのが手っ取り早かった…ってだけで、そうなっていること自体には、実装のしやすさを
のぞけば、たいした意味はない。

…というのはケイのメッセージングのOOの話で、ストラウストラップの抽象データ型のOOでは
また話が変わってくる。

余談だが、Smalltalk は比較的「オブジェクトメッセージ」という元々の文法に近くなる記法を
使っているように見えるけれど、処理系の解釈自体は、他の言語と同様、arg1.method(arg2,arg3) と変わらない。
たとえば、receiver with: param1 with: param2 という式であれば
receiver.with:with:(param1,param2) と何ら変わらない。（この式でコールされるメソッドの名前は with:with: 。
Smalltalk ではコロンもメソッド名に含まれるので省略したり、分割してしまうと、
別のメソッドの名前になってしまうので注意されたい）。

69 ：デフォルトの名無しさん：2010/09/13(月) 01:43:40

>>41
> そしてその場合、メソッドの定義は何処に書くんだ？
CLOS だと、メソッドは総称関数に属していてクラスには属してないんだよなぁ

70 ：デフォルトの名無しさん：2010/09/13(月) 03:09:41

今日知ったこと
問題
　整数型の派生型として、正の整数型を作ることは正しいか

答え
　正の整数⊂整数は明らかだが、
　メソッドを定義するまで、それが正しいかどうかは判定出来ない

71 ：デフォルトの名無しさん：2010/09/13(月) 12:46:17

>>41
ポリモーフィズムの対象になる引数だけ特別扱いしたいんだったら
func( obj1 => obj2, obj3)って感じにすれば
マルチメソッドは
func( obj1, obj2 => obj3)って感じで自然に拡張できるんじゃね？

72 ：デフォルトの名無しさん：2010/09/13(月) 12:53:33

OOPはチームメンバーの水準が一定以上にならないと
逆効果なんでしょ？

73 ：デフォルトの名無しさん：2010/09/13(月) 13:22:41

>>70
正の整数を使う目的が負値の抑制であれば
「符号反転」や「減算」があるであろう整数型を継承するのは考えものだな。

基本的に、継承するされるの関係は「is-a」でなくてはならないが、
厳密に言うと「is-a」は要素の包含関係だけ整合性が取れれば良いのではなく、
振る舞いについて閉じている必要もある。

74 ：デフォルトの名無しさん：2010/09/13(月) 18:19:50

>>72
OOPのスキルと手続き型のスキルはまた別だけどな
俺みたく、OOPLで組む分にはほとんど悩まないが
純粋に手続き型で組むと高確率で頭抱えてしまう低水準な人間も居る

75 ：デフォルトの名無しさん：2010/09/13(月) 19:32:11

>>69
>>71
結局、obj.method();　って呼び出し文法は意味分からんってことだよね。
別に　func( obj );　で良いよなぁ。
Cで採用されてて、皆に馴染んでて、何の問題も無く、優れた文法だったのに、
何でわざわざ変えたんだろう。
ポリモするにしたって、マルチメソッドするにしたって、
したけりゃそりゃすりゃいいんだろうが、
呼び出し文法は func( obj1, obj2 );　でいいよなぁ。
要はオーバーロードが動的に行われるってノリでいいんだろ？
なんで変えたかなぁ。
Pythonでのメンバメソッドの仮引数のthisに関する議論とかさー。
アホだろ？
はじめから呼び出し文法が func( obj1, obj2 ); だったら
そんなこと議論する必要も疑問視する必要も無かったのによー。

76 ：デフォルトの名無しさん：2010/09/13(月) 19:54:23

func( obj );　がいかに「当たり前」か。
1. 数学の関数の記述の仕方y=f(x)に似てる。
2. 英語の命令形の文法に似てる。
3. C言語などで当たり前に採用されてて馴染みがあった。
4. UnixのbashやWindowsのバッチファイルもこの並び。
5. アセンブリもこの並び。
6. 機械語もこの並び。

普通の人が普通に考えりゃ普通にfunc( obj1 )の並びになるわな。
英語も数学も機械語もアセンブリもシェルスクリプトもC言語も揃いも揃って
皆そうなんだから、それが「普通」ってことだわな。
なんでわざわざobj.method()なんていう変な文法に変えちまったんだ？
パラダイムシフトとか言って、へんな方向にシフトしてズレちまったら意味ねぇ。
奇をてらわなくても普通でいいじゃん、自然で良いじゃん。

77 ：デフォルトの名無しさん：2010/09/13(月) 20:35:19

変えたって考え方がそもそもおかしい
奇をてらった訳でもなんでもない、そもそも関数でも命令でも無いのだから

78 ：デフォルトの名無しさん：2010/09/13(月) 20:47:06

中置演算子もよくないよな。
代入は= x y
加算は+ x y
と書くべき。

79 ：デフォルトの名無しさん：2010/09/13(月) 20:52:27

いやだからそれが・・・、
なんで変な考え方に変えたんだって・・。
そりゃ、変な考え方の世界では、変な行為が普通なんだろうよ。
obj.method();が普通に見えるような考え方は、そりゃ普通か？と。
普通だったらfunc( obj );が普通に見えるはずだろ。
英語も数学も機械語もアセンブリもシェルスクリプトもC言語もその並びなんだから。
だから、obj.method();が普通に見える思考回路や世界観は狂ってるって言う。

80 ：デフォルトの名無しさん：2010/09/13(月) 20:53:15

後置にすればみんな幸せになれる。
f(g(h(x))) は x → h → g → fという順番に読む必要があるが
x h g f という順番に書けば出てくる順番に適用するだけでいい。

「英語の命令形」を参考にして述語を最初に持ってきたのが諸悪の根源。
日本語なら述語が最後だったのに。

81 ：デフォルトの名無しさん：2010/09/13(月) 20:54:49

しかし遅延評価でハマれる

82 ：デフォルトの名無しさん：2010/09/13(月) 20:58:16

obj.XXXの「obj.」ぶぶんは所有を表明しているだけじゃね？
なにかもんだいでもあったか？

83 ：デフォルトの名無しさん：2010/09/13(月) 21:00:05

>>78
あれはオペランドが2つって決まりきってるから出来る芸当だね。
本来なら、+ 1 2 か　1 2 +　が良かっただろうね。
で、一方プログラミングの世界では、引数は二つって決まりきってる訳でもないので、
中置記法は相性悪いし不自然だわな。

84 ：デフォルトの名無しさん：2010/09/13(月) 21:07:06

>>80
俺もそう思う。
後置記法は何気に優れた一面を持ってると。
ただ、最後まで読まないと何をしたいのかが分からないという。
ファンクションの切り替えが最初に来た方がコンピュータ的には優しかったのだろう。
もっと単純なコンピュータだったら後置記法でも良かったかもね。
データが出てきたらスタックにプッシュプッシュプッシュ、関数が出てきたらコールっていう。
電卓作るなら後置記法がスゲー楽だもんな。

85 ：デフォルトの名無しさん：2010/09/13(月) 21:17:37

>>82
なんでオブジェクトが関数を所有してんだよ。そもそもそこがどうなんだ。
その考え方は、OOPでも単一ディスパッチでしか通用しないんだぞ。
何の発展性も無いんだぞ。
おそらく将来多重ディスパッチが普通になったら、
func( obj1, obj2 );　っていうC風の普通の書き方に舞い戻るんだぞ。
そしたらどうだ？obj.method()って書き方の立場はどうなる？
一時的にそういう書き方をしたけど、また元に戻ることが約束されているんだぞ？
思い出したら恥ずかしい若気の至り、中学時代の甘酸っぱい思い出みたくなるんだぞ。
いわゆる中2病みたいな位置づけなんだぞ。

86 ：デフォルトの名無しさん：2010/09/13(月) 21:17:41

1引数を取る後置演算子あたりが定義出来ると良いなと思う
でも、全部後置記法とかはやり過ぎ
マイナス個の引数を持つ関数を定義も出来るけど、
型がないようなもんだし

87 ：デフォルトの名無しさん：2010/09/13(月) 21:22:21

CLOSに
お　ま　か　せ

88 ：デフォルトの名無しさん：2010/09/13(月) 21:23:34

多重ディスパッチはweak typedな言語の特徴だから
強い型システムを持つ言語では積極的に採用されないと思う

89 ：デフォルトの名無しさん：2010/09/13(月) 21:30:54

元々Cの構造体アクセス演算子がstruct.member
もしくはstructptr->memberなんだからそれに添っただけでしょ。
構造体に関数ポインタ入れとけば関数内で
ディスパッチするよりも効率いいし。
OOPと全く関係ない。

90 ：デフォルトの名無しさん：2010/09/13(月) 21:37:47

>>88
それで、C++やJavaやC#は誰も使わなくなるんだよ。
だってどう考えても関数の呼び出しはfunc( obj1 )で統一されていた方が良いもんな。
C++は皆テンプレートとオーバーロード目的で使い始めるだろうな。
てか、既にそうなってるが。
オーバーロードは静的多重ディスパッチ(なんじゃそれ)とも解釈できるわけで。
というか、オーバーロードがあるんなら、それを動的にする形で
ポリモを実現してくれたらよかったのによー。

結局オーバーロードもポリモも引数の型で呼び出す処理を変えたいって目的は同じなんだから、
文法も統一すりゃ良いのに。

>>89
その、構造体が関数を抱え込むって発想が不味かったんじゃないかって。
関数は関数で構造体と独立しているからこそ意味があるんじゃないかって。
だって、構造体と構造体のコミュニケートの際に使うのが関数なんだから、
その関数が単一の構造体に縛られてちゃまずいでしょ。

91 ：デフォルトの名無しさん：2010/09/13(月) 21:51:00

言ってることがめちゃくちゃだ
静的→動的の変更なんて速度的/安全度的に全くメリットがないし
HaskellやMLなどの新しい言語は、そもそもオーバーロードを全く許さない方向に進化してる

92 ：デフォルトの名無しさん：2010/09/13(月) 22:01:56

>91
ポリモ前置氏はただスレの活性化のため、よた話をしているんだと思うよ。

ちなみに、Haskellはオーバーロードがあったはず。

93 ：デフォルトの名無しさん：2010/09/13(月) 22:03:17

だから、手続き型の「関数」（≒サブルーチン）と、
数学の「関数」（≒純粋関数型言語の関数）は、別物だと何度言わせるんだ。

94 ：デフォルトの名無しさん：2010/09/13(月) 22:06:04

LISPやMLの関数は何者ですか？

95 ：デフォルトの名無しさん：2010/09/13(月) 22:09:33

class Hoge a b where
foo :: a -> b
として

instance Hoge X Y where
foo a b = (云々)

って感じで多重ディスパッチが書けたような

96 ：デフォルトの名無しさん：2010/09/13(月) 22:11:05

あ、スペース置き換えんの忘れた

97 ：デフォルトの名無しさん：2010/09/13(月) 22:17:06

>>92
お、分かってるね。俺がいないとここドライブしねーだろ。
実際俺がいない間、全然スレ進んでねーし。
しまいにはヘッダがどうとかプリプロセッサとかダサいとかのどうでも良い話題でスレ汚す始末。

>>93
なぜそうと言い切れるんだ？
手続き型の関数も、数学の関数も、何かと何かの関係を定義するってことには変わりないぞ。
ただ、手続き型の場合は、定義した関係が、呼び出したときのみ有効で、
数学や関数型言語の場合は、定義した関係が永続的に有効、って違いは有るが。
どちらにしても、関数が何かと何かの関係を定義していることには変わりないし、
その、何かと何かの関係を定義してるって部分がプログラムの機能に重要なことも変わりないだろ。
方法が違うだけで、やろうとしていることは同じだ。
そういうもんは同じで良いだろ。
だから、関数呼び出しとメソッド呼び出しの文法は統一したいし、
オーバーロードとポリモも目的が同じようなもんだから、文法を統一しろと。

98 ：デフォルトの名無しさん：2010/09/13(月) 22:40:40

C++0xみてて本当にそう思うんだよね。
似たような目的なのに、文法上違うものが一杯。誰かまとめろよ。
といっても、互換性の問題もあるし、アレはアレで仕方ないんだろう。
そういう意味ではD言語はアホの集まりだな。
一から作ってアレかよ。なんつーか、寄せ集め？
上手い具合に纏め上げてやろうという気は無いのかね。
プログラムって本来そんなに複雑なものか？
なんかおかしくなって来てる気がする。
特にOOPが世に広まってからな。

99 ：デフォルトの名無しさん：2010/09/13(月) 22:44:35

オレオレOOPを批判するその口が、オレオレ関数の定義を得々と語る不思議。
いいから、とりあえず高校数学を一から勉強しなおしてくるんだ。

100 ：デフォルトの名無しさん：2010/09/13(月) 22:47:12

話が平行線?なのは、ポリモ前置き氏ｗがコンピュータ的（または論理的・演繹的）な自然さと
人間にとっての自然さを区別してないからだろう。

>>83で本来なら「+ 1 2」や「1 2 +」が良かったと書いているけど、こんなのは誰も望んでいない。
これだと複雑な式の構造が分かりづらいし、手書き文字の「- 12 3」と「- 1 23」と「-123」の
区別なんて考えるだけで頭が痛くなる。
数学は理屈優先のように思われがちだけど、実際は人間に都合よく定められていることが多い。
＋と×の優先順位が違うのも、括弧を中括弧や大括弧と使い分けるのも全て人間のため。
プログラミング言語も人間のためのものなのだから人間的な自然さで考えないと。

結局、氏からはOOPは不自然という以上の理屈は出てこないけど、その自然さの基準がずれてる
わけだから話が噛み合うはずがない。

101 ：デフォルトの名無しさん：2010/09/13(月) 22:56:49

そんなに今のOOPLに一言あるんだったら自分でなんか作ってみたら？
rubyみたいに流行るかもよ

102 ：デフォルトの名無しさん：2010/09/13(月) 23:01:50

Rubyは、ブレイクするまで10年かかってるけどな。
半生をかけて、自分のコンセプトを貫き通せる根性があるようには見えんが。

103 ：デフォルトの名無しさん：2010/09/13(月) 23:02:07

>>100
コンピュータにとって自然なことと、人間にとって自然なことは、同じだよ。
だって、コンピュータと人間の両方にとって自然なことが、本当の自然だから。
コンピュータは2進数で人間は10進数でーーーなんだけど、
だけど、数という概念で見れば何進数だろうと数は数なんだから、同じもの。
という風に、どっかで折り合いがつくところがあって、それが自然。

プログラミングという行為を自然に表現すると、
「データとデータの関係を関数で定義して機能させること」
となり、これが素直に表現できる自然な言語が求められる。

>>101
楽しそうだね。そういう方向性でスレを活性化させることも考えたんだが、時間が足りねーんだよねぇ。
ニートじゃ有るまいし。
しかし、普通の言語、自然な言語、調和の取れてる言語、ありのままの言語、何一つ悩まなくてもいい言語、
出来たら楽しいだろうな。
あーでもプログラマの仕事が無くなったら困るか。

104 ：デフォルトの名無しさん：2010/09/13(月) 23:06:07

>>103
論理を戦わせている議論で、「自然」とか「当然」とかいう単語で
自分の主張の正当化を図る時点で君は色々ダメ。

105 ：デフォルトの名無しさん：2010/09/13(月) 23:10:13

>>102
まじで、そんなに根性いるの？
10年？ありえねぇ。そこまでの根性あるやつって、絶対普通じゃないし、
普通じゃない奴の作った言語は普通じゃない言語だから、俺の目指す「普通の言語」とは程遠いし。
まず普通の奴は言語作って普及させようなんて思わないもんな。
あーだから言語屋は変な奴ばっかで、変な言語ばっか出回ってるのか。納得。
すげーすっきりした。ずっと何で普通の言語がねぇんだって思ってたんだけど、
そりゃそうなんだよな。「普通の奴は言語なんぞ作って広めたりしない」か。
それで必要に迫られて作ったC言語や、その時代に作られた言語だけがマトモなのか。

106 ：デフォルトの名無しさん：2010/09/13(月) 23:11:24

>>92氏はすげーな。C++スレでマイヤーズの本を参照しろって言うようなもんか
俺は向いてないのかもしれん

107 ：デフォルトの名無しさん：2010/09/13(月) 23:12:16

オレオレOOPLで良いからなんかコード書いてみてよ

108 ：デフォルトの名無しさん：2010/09/13(月) 23:24:31

>>105
なんか色々な物を冒涜して恥じない人なんだね、君って。
C言語だって、色々な学術的・工学的実践の歴史の上に成り立っているわけだよ。

まぁ、「自然」とか「普通」とかって言葉を恥ずかしげもなく連発できる奴に何を言っても無駄か。

109 ：デフォルトの名無しさん：2010/09/13(月) 23:27:57

後置出来ると、便利なんだよ
C++だと複数次元配列を扱うクラスとかが
テンプレートと後置のoperator[]呼び出しで実現できる

mdarray<4> m = new ... //略
m[0][1][2][2]=10;
前置だとこういうことは出来ない

110 ：デフォルトの名無しさん：2010/09/13(月) 23:29:33

すげーどうでもいいｗ

111 ：デフォルトの名無しさん：2010/09/13(月) 23:33:54

C言語の何がマトモなんだ・・・

112 ：デフォルトの名無しさん：2010/09/13(月) 23:39:21

>>111
そう書くなら「マトモ」じゃない所を挙げなさいよ

113 ：デフォルトの名無しさん：2010/09/14(火) 00:09:15

>>112
規格化以前にエラい人が書き散らしたコードを気にしすぎ。
そのせいで似たようなコードなのに、
この場合はこう、
この場合はこう、
統一性がない。

さらに、無理矢理ハードウェアを隠してるから、各所に無理がある。

一番酷いのが処理系依存が多すぎる。
特に未定義。都合悪いとすぐ未定義。
処理系で好きにしてくれ、と丸投げ。
処理系定義ですら酷い。

型変換などのメモリの使い方に関するところも色々微妙。
一例上げるとsignedとunsignedの整数の変換とか。
signedからunsignedの変換は、以下。
新しい型で表現出来ない場合、その最大値または最小値を
足すか引くかを繰り返し、最初に表現可能になった値をとる。

実はこの処理はリトルエンディアンな2の補数表現で、
メモリの後ろを切り飛ばす処理だ。

そのくせunsignedからsignedの変換は処理系定義なんだぜ？

何この非対称変換な規格。

C言語、大好きです。

114 ：デフォルトの名無しさん：2010/09/14(火) 00:28:09

まぁ細かいことはあれど、コンセプトというか、センスのいい言語だと思うよ＞C言語
それに、とにかくコードの見た目が綺麗。
C言語を読んだり書いたりしていると気分がよくなる。

115 ：デフォルトの名無しさん：2010/09/14(火) 00:30:36

俺は>>114とは友達になれないようだ。

116 ：デフォルトの名無しさん：2010/09/14(火) 00:33:06

メソッドを所有できないOOPってなんかあったかな？

117 ：デフォルトの名無しさん：2010/09/14(火) 00:38:56

なんかそれ、OOPを否定してないか？

118 ：デフォルトの名無しさん：2010/09/14(火) 00:39:58

上のレスで何でオブジェクトがメソッドを所有してんだよてきな発言があったようなきがしたからさ。

119 ：デフォルトの名無しさん：2010/09/14(火) 07:04:03

まあ確かにオブジェクトにメソッド持たしても汎用性失うだけだからな

120 ：デフォルトの名無しさん：2010/09/14(火) 18:12:45

今読み返したら、>>114の変換方法間違えてるわ。

121 ：デフォルトの名無しさん：2010/09/14(火) 19:52:29

でも大半のOOPLはオブジェクトがメソッドを所有…というか、そもそもメソッドって言葉自体
能力とかそういう意味だから、オブジェクトが持つものなんだが。
言語によっては…例えばPythonとか文字通り「所有」してるしな。

122 ：デフォルトの名無しさん：2010/09/14(火) 20:13:33

クラス型なら所有しているのはクラスだ、オブジェクトじゃない。

123 ：デフォルトの名無しさん：2010/09/14(火) 20:43:25

>>121
オブジェクトが自分自身の能力を定義してることがおかしいんだよ。
オブジェクトの能力は、周りとの関係や、その関係から得られる機能の中で受身的に決まるものだから。

さて、今日のネタ。「パラダイムシフト」
パラダイムシフトってのは身近での出来事の中にも良く見て取れる。

昔は人間も裸で木の棒持って動物を追い回してた。(ある程度の社会性は有っただろうがな)
でも、今は違う。家があり服が有り、文化文明があり、いわゆる人間らしい生活をしているよな。
だったら、昔と今で、なんらかのパラダイムシフトがあったはずだ。
では、どんなパラダイムシフトがあったのか。
まー単なる動物と人間の違いといっても良いだろうかな。
あるとき人間は気づいたんだよ。
物そのものよりも、物と物の間にある関係のほうが大事だって。
俺は強いぞーーーってな主観的な考え方ではなくて、関係性の生み出す相対性がキモだって気づいたんだ。
そんで、数学やら物理やら社会性やら言語やら工学やらが急速に発達した。
皆の知ってのとおり、数学なんか、その全てが互いの関係だけで成り立ってる相対的な学問で、
人類の生み出した最高のものと言っても良く、その美しさはパンピーを寄せ付けない。
そんで、昔はコンピュータは上流階級の人しか触れなかったから、
コンピュータは高等な数学的概念を下に着々と理論を積み上げられ、
偉い人たちがパラダイムシフト後の洗練された頭でC言語なりの土台を一気にバーと作った訳だ。
ということで、C言語は既にパラダイムシフト後の高等な言語だったわけだ。
しかしコンピュータが庶民化し、そこに頭の悪い人たちがパラダイムシフトーとか言いながら、
既にパラダイムシフト後であった物をさらにパラダイムシフトし・・・
裏の裏は表なわけで、後は分かるよな。何で退化させんだよ。バカか。
C言語がパラダイムシフト後の言語じゃないって言えるか？
昔の偉い人が作ったんだぜ？サルやライオンが作った訳じゃないんだぞ。
それを今一度パラダイムシフト？元に戻るわけ？わけわかめ。

124 ：デフォルトの名無しさん：2010/09/14(火) 20:52:54

大体、よーく考えてみてよ。
物事ってのは積み上げていくもんだろ。
そこへパラダイムシフトーーーとか言ってチャチャいれる必要はあるんか？
物理学ではまだ辛うじてありえるかも知れんが、数学の世界では絶対にありえないだろ。
C言語まで偉い人たちが着々と積み上げてきたものに、
パラダイムシフトーーーとか言って殴りこみして、
そんなペテンが上手くいくとでも？
世の中に構造化言語が出てきたとき、パラダイムシフトとか言ったか？
言わなかっただろ。だってそれは正当な進化だったから。
なんだよ、OOPのパラダイムシフトって。
既に重要なパラダイムシフトは済んだ後だったつーの。
人類の英知を馬鹿にしてるよな、まったく。

125 ：デフォルトの名無しさん：2010/09/14(火) 20:55:11

>>123
Lisp 最高ですよね。

126 ：デフォルトの名無しさん：2010/09/14(火) 20:55:15

その物言い、構造化を否定してた奴等とそっくりだよw

127 ：デフォルトの名無しさん：2010/09/14(火) 21:01:59

パラダイムシフトというのは、パラダイムが A から B へシフトする (した) ことだよね。
>>123
> 偉い人たちがパラダイムシフト後の洗練された頭でC言語なりの土台を一気にバーと作った訳だ。
いったい何から何へシフトしたのよ。

128 ：デフォルトの名無しさん：2010/09/14(火) 21:15:47

触れてやるな、覚えたての言葉を使ってみたくなったんだろう。

129 ：デフォルトの名無しさん：2010/09/14(火) 21:35:10

>>127
コンピュータ自体がパラダイムシフト後(文明文化が十分発達した後)に発明されたものだったから、
初めからパラダイムシフト後の世界観で偉い人たちが理論を構築していた。
チューリングマシンやらLISPやら紙と鉛筆でのパンピー立ち入り禁止の完全なる数学としてな。
初期のコンピュータサイエンスは今よりも数学色が強かったし、
数学が人間だけが持ちえる高等概念であることは違いないし、
そこへきてパラダイムシフトなんぞ必要あったのかねぇ。

130 ：デフォルトの名無しさん：2010/09/14(火) 21:37:00

なんでもLispの再発明的に語る風潮があるが、
lispとMLではλ理論の体系が違うから、パラダイムが変わってる気がする

131 ：デフォルトの名無しさん：2010/09/14(火) 21:45:23

加熱調理は調理法の革命なので、それ以後の新たな調理法の発明は無意味と
主張している人間を見ている気分。

つうか、パラダイムシフトは科学哲学の概念だ。革新とか発明と同じ意味で使うな。

132 ：デフォルトの名無しさん：2010/09/14(火) 21:48:11

つうか、本当に論理的思考能力が欠落してるな、彼は。
なんでプログラマなんかやれてるんだろ。

133 ：デフォルトの名無しさん：2010/09/14(火) 21:48:44

レコード、CD、 iPod と音楽を聞くためのメディアも変わってきている。
これもパラダイムシフトだと思うけど、音を録ることが可能になった蓄音機よりも小さなパラダイムシフト。

>>129 がいうパラダイムシフトと同等なものは、生命の誕生？恐竜の絶滅？
確かに構造化とか OOP はそのレベルのパラダイムシフトではないよね。

134 ：デフォルトの名無しさん：2010/09/14(火) 21:55:22

いやだから、パラダイムシフトっていう言葉だけ取り上げて揚げ足取るなよ。
問題は、OOPのパラダイムシフトが何だったかだ。
それは、人類が発展していく過程で捨て去ってきた物への回帰だったろ。
物中心の考え方を止めて、関係中心に考えることで人類は発展してきたのに。
数学がまさにそれで、実際に文明を支えてるだろ。

135 ：デフォルトの名無しさん：2010/09/14(火) 22:07:41

典型的な詭弁だな。

136 ：デフォルトの名無しさん：2010/09/14(火) 22:38:55

なんだかんだ言った所で世に出た言語使うしか無いんだから
オレオレ言語とかいくら考えても仕事するときにチラついて邪魔なだけだ

137 ：デフォルトの名無しさん：2010/09/14(火) 22:59:19

オレオレ言語で納品すればオレオレ言語にパラダイムシフトが起こる

138 ：デフォルトの名無しさん：2010/09/14(火) 23:01:52

func( obj );
より
obj.method();
のが数倍優れてるだろ、
インテリセンス効くし。

139 ：デフォルトの名無しさん：2010/09/14(火) 23:02:45

ポリモさん、出番です

140 ：デフォルトの名無しさん：2010/09/15(水) 00:01:06

ポリモ前置氏だけど、
釣りじゃね？数倍も優れてちゃ敵わんw

141 ：デフォルトの名無しさん：2010/09/15(水) 00:04:42

obj.method();
method(obj);
タイプ量が

obj.method1().method2();
method2(method1(obj));
見やすさが

142 ：デフォルトの名無しさん：2010/09/15(水) 00:06:12

どう考えてもインテリセンスの効く今のOOPの方が開発効率良いし

143 ：デフォルトの名無しさん：2010/09/15(水) 00:10:43

obj.method()はインプレースでobjを変更するように見える
method(obj)はobjを変えないように見える
コレが等価扱いされるとなんかモヤッとする

144 ：デフォルトの名無しさん：2010/09/15(水) 00:12:21

ポリモ前置氏だけど、なんもモヤっとしねぇ。
俺やべぇ。

145 ：デフォルトの名無しさん：2010/09/15(水) 00:13:24

　　5
　　＿＿＿　　530,000
　 | 　　　|＼　.__
　 | 　　　|　|　| ||
　 | 　　　|　|　| ||
　 | 　　　|　|　| ||　　　グラフで比較するとそれほど差はない
　 | 　　　|　|　| ||　　　むしろ関数の方が効率的に感じられる
　 | 　　　|　|　| ||
　 | 　　　|　|　| ||
　 | 　　　|　|　| ||
　 | 　　　|　|　| ||
　 | 　　　|　|　|_|| OOP
　 | 　　　|　|／/
　 | 　　　|　|　/
　 | 　　　|　| /
　 | 　　　|　|/
　 | 　　　| ./
　 |＿＿＿|/FP
／　　　　 /

146 ：デフォルトの名無しさん：2010/09/15(水) 00:15:24

え？FPと勝負すんの？そりゃ分が悪いって。せめてC言語にしときなよ。

147 ：デフォルトの名無しさん：2010/09/15(水) 01:26:49

>>142
釣り？

148 ：デフォルトの名無しさん：2010/09/15(水) 07:05:37

１番
obj = obj.method1(a).method2(b).method3(c).method4(d);
２番
obj = method4(method3(method2(method1(obj,a),b),c),d);
３番
obj = method1(obj,a);
obj = method2(obj,b);
obj = method3(obj,c);
obj = method4(obj,d);
４番
method1(obj,a);
method2(obj,b);
method3(obj,c);
method4(obj,d);

それぞれの違いが判るかな？

149 ：デフォルトの名無しさん：2010/09/15(水) 07:59:25

>>147
特に最近は、IDEとの相性は重要な要素になってきたと思うな。

150 ：デフォルトの名無しさん：2010/09/15(水) 11:43:37

method2(method1(obj)); ってさ、Cで自分の
データ構造を加工させる関数呼んでるのとかわらなくね？

151 ：デフォルトの名無しさん：2010/09/15(水) 12:42:58

>>142 >>147 >>149
動的言語だとOOPでもIDEでまともに補完効かないよ。OOPだからいいってことではない。

例えば、Rubyだと実行時に動的にメソッドが定義されるのと、定義されてるメソッドがない場合の処理もあるので、
個別に対応したり静的な解析をかなり頑張ったり、補完速度がもっさり度MAX級ですよ。
それ以上に大クラス主義なので補完候補が数百でたり、かなりしんどい。

その後にC#とかJavaの補完使うと感動するレベルw

OOPというか言語によるって話しだが。

152 ：デフォルトの名無しさん：2010/09/15(水) 13:08:03

>>123
オブジェクトが自分自身の能力を定義してることがおかしいんだよ。
オブジェクトの能力は、周りとの関係や、その関係から得られる機能の中で受身的に決まるものだから。

さて、今日のネタ。「パラダイムシフト」
パラダイムシフトってのは身近での出来事の中にも良く見て取れる。

昔は人間も裸で木の棒持って動物を追い回してた。(ある程度の社会性は有っただろうがな)
でも、今は違う。家があり服が有り、文化文明があり、いわゆる人間らしい生活をしているよな。
だったら、昔と今で、なんらかのパラダイムシフトがあったはずだ。
では、どんなパラダイムシフトがあったのか。
まー単なる動物と人間の違いといっても良いだろうかな。
あるとき人間は気づいたんだよ。
物そのものよりも、物と物の間にある関係のほうが大事だって。
俺は強いぞーーーってな主観的な考え方ではなくて、関係性の生み出す相対性がキモだって気づいたんだ。
そんで、数学やら物理やら社会性やら言語やら工学やらが急速に発達した。
皆の知ってのとおり、数学なんか、その全てが互いの関係だけで成り立ってる相対的な学問で、
人類の生み出した最高のものと言っても良く、その美しさはパンピーを寄せ付けない。
そんで、昔はコンピュータは上流階級の人しか触れなかったから、
コンピュータは高等な数学的概念を下に着々と理論を積み上げられ、
偉い人たちがパラダイムシフト後の洗練された頭でLispなりの土台を一気にバーと作った訳だ。
ということで、Lispは既にパラダイムシフト後の高等な言語だったわけだ。
しかしコンピュータが庶民化し、そこに頭の悪い人たちがパラダイムシフトーとか言いながら、
既にパラダイムシフト後であった物をさらにパラダイムシフトし・・・
裏の裏は表なわけで、後は分かるよな。何で退化させんだよ。バカか。
Lispがパラダイムシフト後の言語じゃないって言えるか？
昔の偉い人が作ったんだぜ？サルやライオンが作った訳じゃないんだぞ。
それを今一度パラダイムシフト？元に戻るわけ？わけわかめ。

153 ：デフォルトの名無しさん：2010/09/15(水) 13:11:46

切れてナイーだけ読んだ

154 ：デフォルトの名無しさん：2010/09/15(水) 13:12:23

>>141
io言語最強！！

obj method1 method2

タイプ量も見やすさも

155 ：デフォルトの名無しさん：2010/09/15(水) 13:26:56

(ノ∀｀)アチャー
だからもういーお
とか言われるんだお

156 ：デフォルトの名無しさん：2010/09/15(水) 14:22:50

>>143
>obj.method()はインプレースでobjを変更するように見える
>method(obj)はobjを変えないように見える

いや、全くそう見えない…というか、どっちも変更するかどうかは処理内容次第だろ
強いて変更する場合だけで言えば
method(obj)はobjとは別の存在がobjを変更するイメージ
obj.method()はobj自身がobjを変更するイメージがあるかな

157 ：デフォルトの名無しさん：2010/09/15(水) 14:31:20

そもそもなんでメソッド呼び出しが変更することが前提なんだよｗ

158 ：デフォルトの名無しさん：2010/09/15(水) 15:14:47

>>157
変更されないことが保障されているのか？

159 ：デフォルトの名無しさん：2010/09/15(水) 15:59:06

関数に引数として渡すにしても、メソッド呼び出すにしても
どっちでも保証されてないって話をしてたと思ったんだが

160 ：デフォルトの名無しさん：2010/09/15(水) 17:02:45

そのようによめない

161 ：デフォルトの名無しさん：2010/09/15(水) 19:19:23

いつもの人だけど、今日のご高説のお題は何にしようか。
「メッセージ」これにしよう。このお題は複雑に入り組んでてとても面白い。
複雑で面白いんだが、話が発散しそうだから、ここではアランケイ流のメッセージについて考えてみよう。

まず初めに絶対に読んでおかないといけないのはこれ。
http://d.hatena.ne.jp/sumim/20040525/p1

>誤った傾向として、よく、「すべてがオブジェクト」であることのみが強調されがちですが、
>この文脈における「オブジェクト指向」で重要なのはむしろ“メッセージング”のほうです。
>クラスはおろか、オブジェクトですら飾りに過ぎません。偉い人にもそれがわかっとらん人がけっこう多いのです。ｗ

つまりアランケイ流のOOPは、オブジェクトがメッセージングの媒体の中にプカプカ浮かんでいて、互いに相互作用しあってるようなもの。
で、この思想で重要なのはオブジェクトではなく、むしろ媒体であるメッセージングの方だと言ってる。(なのにOOPを唱えると言う謎)
じゃあその彼の言う大事な「メッセージング」の正体って何だろう。
アランケイみたいに捻くれた考え方をしていない俺らは、素直にこう考える。
メッセージングはとどのつまりオブジェクトとオブジェクトの関係を定義しているのだから、
それは既存の概念でいうところの関数だね、と。あっという間に紐解ける。
実は彼のOOPの思想は関数型言語に近く、実際彼自身もこんな名言を残している。
■LISPについて→「これまでに設計された最も偉大なプログラミング言語」

162 ：デフォルトの名無しさん：2010/09/15(水) 19:21:32

OOPの訳の分からなさの正体は、アランケイが自分の思想を相手に正しく伝えるための手段を知らなかったために起こった悲劇なのさ。
彼は深層心理では関数型言語的なものを欲していたのに、何故かOOPとか言い出した。
自分の思想がメッセージング(関係/関数)が重要なものと分かりつつ、なぜかOOPという名前を付けた。(せめてメッセージング指向とかで良かっただろうがよ)
既に関数と言う良く知られた概念があったにもかかわらず、何故かメッセージングという独自の言葉を再発明した。
何故か物事を裏側から見て、分けの分からないことを永遠とのた打ち回った。

事の発端は本当に些細なことだったんだろうよ。
仮に彼が自分の思想を表現するのにオブジェクト指向と表現せずにメッセージング指向と表現していれば、
事態は全然変わってきていただろうね。恐ろしいね。

163 ：デフォルトの名無しさん：2010/09/15(水) 19:25:46

それでも結局のところ、ストラウストラップをとどめることはできなかったんじゃない？
たらればだけどさ。

164 ：デフォルトの名無しさん：2010/09/15(水) 19:29:33

これからの言語はIDEとの相性はかなり重要な要素だと思うけどな。
実行時エラー＜コンパイルエラー＜コンパイル前エラー　だし
タイプ数もコード補間が効きやすい構文とかの方が圧倒的に有利になる。
今後はオブジェクト同士の依存関係もコーディングしてる側からどんどん視覚化されていくIDEになると思う

165 ：デフォルトの名無しさん：2010/09/15(水) 19:34:09

>>163
そうだろうけど、OOPに関する論争が、もう一回りだけシンプルになってただろうと思うのよ。
アランケイのあれはどう考えてもどっちかというと関数型言語よりの思想だろ？
そんな相反するもんまでひっくるめてOOPの範疇にしちまったら、もう議論なんて成り立たないだろう。
オブジェクト以外のも、メッセージング、関係、それが大事だといいつつ、「オブジェクト指向」。
もう分けわからんだろ。アランケイはわびろ。

166 ：デフォルトの名無しさん：2010/09/15(水) 19:39:28

訂正：
オブジェクト以外のもの、メッセージング、関係、それが大事だといいつつ、「オブジェクト指向」。
もう分けわからんだろ。アランケイはわびろ。

167 ：デフォルトの名無しさん：2010/09/15(水) 19:41:52

まあプログラミングなんて半分以上が依存関係の整理だしな

168 ：デフォルトの名無しさん：2010/09/15(水) 19:57:28

メッセージはオブジェクト間の関連なんか表してないだろ
むしろメッセージングの欠点はオブジェクト間が疎結合になりすぎる事。まったく逆だろ

169 ：デフォルトの名無しさん：2010/09/15(水) 20:04:00

メッセージはオブジェクト間の関係なんぞ表してない。そりゃそうだろう。
だがよく読め。「メッセージング」だ。メッセージをやり取りしあうこと。
オブジェクト同士がメッセージをやり取りしあう。メッセージングする。その結果どうなる？
オブジェクト同士の関係が定義される。
そして、その行為こそが大事だというのなら、それは関係指向とでも言うべきだっただろう。

170 ：デフォルトの名無しさん：2010/09/15(水) 20:05:40

疎結合だとなんか問題あんの

171 ：デフォルトの名無しさん：2010/09/15(水) 20:43:46

御託はいいから可動する処理系の実装もってこい、話はそれからだ。

172 ：デフォルトの名無しさん：2010/09/15(水) 21:12:31

>>169
それを関係と言うのなら、多重ディスパッチで定義される関係と大分趣きが違うと思う
多重ディスパッチは型同士の関係が静的に定義されるけど
メッセージングは型とか関係なくインスタンスが持ってるメソッドが呼び出されるからかなり動的なその場限りの関係になるでしょ

>>170
結合度が低くなり過ぎると処理が分散して似たような記述を何度も書かなくちゃいけないじゃん
だから継承やmixinなんかを使って適度に依存関係を作ってやる必要があるわけで

173 ：デフォルトの名無しさん：2010/09/15(水) 21:24:17

多重ディスパッチだって、コールしない限りはその関係は無効だから、その場限りなのには変わりない。
それが逐次実行、手続き型の特徴だ。あー頭痛い。

174 ：デフォルトの名無しさん：2010/09/15(水) 21:36:07

>>172
結合度が低くなりすぎて云々というところがいまいちわからん
オブジェクトの結合度が低いほうが「適度な依存関係」というのを作りやすいんじゃないの？

175 ：デフォルトの名無しさん：2010/09/15(水) 21:46:41

そこが、今日の先生の技だよ

176 ：デフォルトの名無しさん：2010/09/15(水) 23:53:38

>>173
お前の言う関係って具体的に何よ

>>174
ごめん結合度が低い、という言葉はあんまり適切じゃなかった。継承とかを例に出したのは完全に間違いだった。
もっと正しく言うと「オブジェクトの独立性が高すぎる」になるんだろうか。複数のクラスのインスタンスが関連し合う処理を書くときは
メッセージングより多重ディスパッチのほうが楽でしょ

177 ：デフォルトの名無しさん：2010/09/15(水) 23:57:11

差分プログラミングは基本的に良くない

178 ：デフォルトの名無しさん：2010/09/16(木) 00:29:11

>>177
禿同。

179 ：デフォルトの名無しさん：2010/09/16(木) 01:17:21

オープンソース全般で行われていることですね！

180 ：デフォルトの名無しさん：2010/09/16(木) 01:32:51

オープンソースは基本的に良くない

181 ：デフォルトの名無しさん：2010/09/16(木) 01:34:57

このセンスｗ

182 ：デフォルトの名無しさん：2010/09/16(木) 02:11:19

最近はソースはオープンでも、クローズドな展開が目立つな
昔からだけどな

183 ：デフォルトの名無しさん：2010/09/16(木) 10:56:52

オープン過ぎるとコモンズの悲劇が起こる
クローズド過ぎるとアンチコモンズの悲劇が起きる
要はバランスの問題

184 ：デフォルトの名無しさん：2010/09/16(木) 20:43:42

ちょっと質問させてくれ
ウィキペディアによると

>多重ディスパッチを採用する言語では、全ての引数がメソッド選択という観点では平等に扱われる。
>第一引数、第二引数、第三引数とマッチングを行うが、どれか特定の引数がその関数やメソッドを「所有」しているわけではない。

らしいんだけど、この場合関数やらメソッドやらはどこにあるの？

185 ：デフォルトの名無しさん：2010/09/16(木) 20:44:46

グローバルとか（Javaのパッケージのような）名前空間とか

186 ：デフォルトの名無しさん：2010/09/16(木) 20:50:01

>>185
グローバルとかに置いて煩雑にならないのかな
というか多重ディスパッチだけ抜き出すとあんまりOOっぽくないね

187 ：デフォルトの名無しさん：2010/09/16(木) 21:32:16

名前空間ありゃ問題ないだろ

188 ：デフォルトの名無しさん：2010/09/16(木) 22:00:30

>>184
CLOS 系だと総称関数に属しますね. いわゆる OO 言語とは全然、別物
まぁ、あっちは関数の扱いが全然異なってるから...

189 ：デフォルトの名無しさん：2010/09/16(木) 22:14:40

マルチメソッドを実装したら、いわゆるOO言語でなくなる・・・
OOPって一体なんだったのだろう。

190 ：デフォルトの名無しさん：2010/09/16(木) 22:22:28

OOA/OODの結果を効率よく実装するためのツール。

191 ：デフォルトの名無しさん：2010/09/16(木) 22:25:45

・差分プログラミング
・多態
・カプセル化
クラスで何でもやろうとしたところが問題だったのだろう。

差分プログラミングは今となってはあまり重要ではない。
多態はなくてもいいけど、やるならマルチメソッドな方向でいいだろう。
カプセル化は今のクラスの仕組みでも良いかな。

ということで、継承が諸悪の根源ってことで良いだろう。

192 ：デフォルトの名無しさん：2010/09/16(木) 22:28:50

その中だとむしろカプセル化が要らん
多態は使ってて良さが見えやすいから、
ダックタイピングやらパターンマッチやらテンプレートやらでいろんなアイディアが考え出されてる

カプセル化はなくても死なん

193 ：デフォルトの名無しさん：2010/09/16(木) 22:38:28

OO脳としか。

無くても死なんカプセル化ぐらいにしか使えんのがOOPだと言うのに。

194 ：デフォルトの名無しさん：2010/09/16(木) 22:38:31

>>189
おそらくハゲの人には, いいアイデアに思えたのでは???
各種 lisp 系も, 最初は (object <- message ...) みたいな
表記をしてたみたいですけど, まじめに考えると
「だめなんちゃう， (object <- message ...) は???」
に, なったみたいですね
まぁ,
変数は型を持たないけど, オブジェクトは型を持ちまくってる言語の
特性が，特性が!!!
てなところでしょうか?

195 ：デフォルトの名無しさん：2010/09/16(木) 22:42:39

日本語でおk

196 ：デフォルトの名無しさん：2010/09/16(木) 22:44:54

> (せめてメッセージング指向とかで良かっただろうがよ)
これは同意ｗ

今OOPとして広まっている多くの言語で、OOPはメッセージ指向ではないし、
そうなっているのでメッセージ指向の言語をOOPというのにも違和感あるし

197 ：デフォルトの名無しさん：2010/09/16(木) 22:45:13

lisp 系の, 歴史流れ書いてるだけなんで
> 日本語でおk
とか，きかれても…

198 ：デフォルトの名無しさん：2010/09/16(木) 22:45:21

>>190を無視して処理系の詳細を語ることに拘泥するのがこのスレの限界。

199 ：デフォルトの名無しさん：2010/09/16(木) 22:48:52

>>197
変な改行したり、感嘆符や句読点がおかしいのは気にならないのか？

200 ：デフォルトの名無しさん：2010/09/16(木) 22:50:27

句点をコンマで書く人なら気にならないのでは？

201 ：デフォルトの名無しさん：2010/09/16(木) 22:50:57

>>199
まぁ, そう言われりゃそうだなw

202 ：デフォルトの名無しさん：2010/09/16(木) 22:56:26

というか、ケイ君の言ってるOOPを、彼の思想をもとに真面目に実装したら、

void messaging_hoge( A *a, B *b )
　　//ケイ君の言う「メッセージング」の正体は、実は私です。
　　//数学の世界では関数と呼ばれています。
　　//オブジェクト間の相互作用を担当します。
　　//当然マルチメソッドに対応しています。
　　//ケイ君いわく、一番重要な存在らしいです。光栄です。
{
　　a->set_value( b->get_value() );
　　　　//型内の整合性はアクセサで完全に保障されてるんだからね。
　　　　//だから安心して思う存分コミュニケーションしちゃっていいんだからね。
　　　　//継承？多態？そんなの知らないわよ。メッセージングでなんとかしてよね！
}

となると思うんだが。
なぜ彼はSmalltalkなんぞに肩入れしたのだろうな。
良い事言ってるのに、やってることがwww一番たちわるいな。
上記っぽい言語作ってりゃ、今頃ケイ君の評価もうなぎ上り、
皆も美味しい美味しい言いながら食べてくれてただろうに。

203 ：デフォルトの名無しさん：2010/09/16(木) 23:02:08

>>202
> 　　//数学の世界では関数と呼ばれています。

ソース。

204 ：デフォルトの名無しさん：2010/09/16(木) 23:11:52

>>202
そんなところに納めたら構文拡張できないじゃないか
あの言語は, 通常の言語の if 文ですら message だぞ

205 ：デフォルトの名無しさん：2010/09/16(木) 23:12:49

おれはカプセル化のためにOOPL使ってる

206 ：デフォルトの名無しさん：2010/09/16(木) 23:14:30

>>205
お前は正しい、と俺だけが保障してやる。

207 ：デフォルトの名無しさん：2010/09/16(木) 23:23:39

結局、どう依存関係を整理できるのか、ってのが大事なわけで
継承なんかはポリモが絶対必要な場面以外では使うべきじゃないんだよな。

208 ：デフォルトの名無しさん：2010/09/16(木) 23:30:00

んだ。ある記法が適切かどうかは、それによってどれだけ複雑さを縮減できるかによる。
文法で云々するのは多くの場合ナンセンス。

209 ：デフォルトの名無しさん：2010/09/16(木) 23:44:03

構造化言語は文法で可読性やら安全性やら飛躍的に高めたろ

210 ：デフォルトの名無しさん：2010/09/16(木) 23:47:27

>>209
特定の文法を強制することで、可読性や安全性が高まったことに価値があるのであって、
if { ... } else { ... }という記法そのものに意味があるわけじゃない。

211 ：デフォルトの名無しさん：2010/09/16(木) 23:49:12

お前がなに言ってるか分からない

212 ：デフォルトの名無しさん：2010/09/16(木) 23:49:38

継承に関しても同じだろ
継承の記法に意味があるわけじゃない

213 ：デフォルトの名無しさん：2010/09/16(木) 23:55:07

>>210
そうか?
try {...} catch { ...} じゃないけど interrupy-disabled {...} みたいな
構文が自由に定義できるとバグが減ると思わないか?
まぁ, c++ あたりは scoped... みたいな物を導入して逃げることは可能だが

214 ：デフォルトの名無しさん：2010/09/16(木) 23:55:47

また馬鹿がきた

215 ：デフォルトの名無しさん：2010/09/17(金) 00:03:02

>>213
その記法が、可読性を改善する効用があるなら有用だろうね。
ただし、それが有用か否かは、そのコードが置かれているコンテクストに依存するだろう。

216 ：デフォルトの名無しさん：2010/09/17(金) 00:13:03

あーまた論点がズレてきつつあるな。俺がいないと本当にだめだなぁ。
OOPのそれは文法云々関係なく、もっと根本でやらかしてる。
それは、データと制御は元来別物なのにも関わらず、単一のデータに制御を括り付けてしまったこと。
データの切れ目と制御の切れ目が一致するとは限らないだろ？
なのにデータの切れ目にあわせて制御をぶった切ったら、制御構造はめちゃくちゃハチャメチャになるだろ？

そもそも、制御はデータよりも偉い。
何故かというと、データに意味を持たせるのが制御だから。
どうやって制御がデータに意味を持たせるかというと、
他のデータとそのデータの相対的な関係を定義することで、意味を持たせる。
数学の「1」はメソッドを持たない。あるのは他の数との相対的な関係を定めた定理だけ。
1は2の半分だし、2は1の倍。1や2の実態なぞ無いのだよ、有るのは他者との相対的な関係の定義だけ→関数型言語にいらっしゃーい。
コンピュータの世界も割りと同じで、
整数値はただのビット列にすぎないんだけど、他との演算や、printfなんかの文字列への変換なんかを通して、
初めてただのビット列が整数の意味を持って、そして機能する。
自分自身で自分自身の意味を定義しても仕方ない。そんな行為はまるで青少年の主張と同レベル。
うつ病患者の自分探しの旅と変わりない。

217 ：デフォルトの名無しさん：2010/09/17(金) 00:14:51

おまえはコテハンつけろ

218 ：デフォルトの名無しさん：2010/09/17(金) 00:18:41

>>216
おまえは何を言っている?
*いわゆる OO 言語* にしか当てはまってないじゃん?

219 ：デフォルトの名無しさん：2010/09/17(金) 00:20:18

メッセージ信者は今更定義論争すんなよ

220 ：デフォルトの名無しさん：2010/09/17(金) 00:21:49

カプセル化がOOPの本質じゃないならおれはOOPいらね

221 ：デフォルトの名無しさん：2010/09/17(金) 00:30:51

依存関係が整理できたら可読性は自然に上がる。

逆に、可読性が上がったからといって依存関係が整理されてるとは限らない。

222 ：デフォルトの名無しさん：2010/09/17(金) 00:31:54

>>218
ケイ君流のメッセージング主体のオブジェクト指向の思想は、
関数型言語や手続き型言語の専売特許なんだからな。
関数型や手続き型は、初めっから、
関係、関数、制御、手続き、メッセージング、コミュニケーション、相対性、機能、
そういったものが物事の主体で設計のキモだと言っていたのに
(関数型、手続き型という名前からして明らかだろ？)、
そこへ、ケイ君が適当な再発明で殴りこんできたんだからな。OOPという変な名前でな。

223 ：デフォルトの名無しさん：2010/09/17(金) 00:38:49

数百行の単位で可読性が高いだけの構文を
プログラム全体が整理されていると勘違いしてはいけない。

224 ：デフォルトの名無しさん：2010/09/17(金) 00:39:56

中身ないレスばっか

225 ：デフォルトの名無しさん：2010/09/17(金) 00:51:01

>>224
仲間入りおめ

226 ：デフォルトの名無しさん：2010/09/17(金) 01:26:39

>>213
それやりすぎると、RubyとRailsは別言語みたいに比喩されるおそれあるんだが

227 ：デフォルトの名無しさん：2010/09/17(金) 02:17:20

>>194
従来の文法と親和性の高いやり方を選んだだけじゃね
C++だって既にあった文法と親和性の高い方法を選んだだけなんだし

228 ：デフォルトの名無しさん：2010/09/17(金) 02:18:07

>>226
個人的には実際に別言語と言いたい

229 ：デフォルトの名無しさん：2010/09/17(金) 04:11:20

>>222
すまんがケイ以前に、そうだな、具体的には例えばSmalltalk-72が考案された1972年以前に、
メッセージングがLISPの専売特許であると主張した論文があれば出してみてくれまいか？（もちろん反語的にだが）

230 ：デフォルトの名無しさん：2010/09/17(金) 06:37:12

微妙に異なる構造体とそれの操作関数が膨大になって、管理に困った、どうする？
→ オブジェクト指向
だと思ってるので、構造体の操作に関係ないところはオブジェクト指向的な設計は必ずしも必要ない。

>>216
> データの切れ目と制御の切れ目が一致するとは限らないだろ？
そうゆうとこは無理に OO しなくていいと思う。

231 ：デフォルトの名無しさん：2010/09/17(金) 07:01:21

>>220
プロトタイプベースもOOPと言われてるあたり本質では無いんだろうな

232 ：デフォルトの名無しさん：2010/09/17(金) 08:21:41

”オブジェクトがー”って書いてあれば大抵オブジェクト指向
オブジェクトは未定義であっても

233 ：デフォルトの名無しさん：2010/09/17(金) 10:07:04

>>231
そういうふうに共通項を括りだしてOOの本質を語ろうとすると確実に填るよ。
ついでに言うと、実装面での共通機構のくくり出しによる分類もしかり。

「カプセル化のOO」、「メッセージングのOO」、「プロトタイプベースのOO」とそれをサポートするOOPは
それぞれメジャーでよく知られているし、互いに強い影響を与え合ってはいるけれど（特に実装面で）、
出自や特色は異なる別物だから、概念や運用法はそれぞれの違いを意識して学んだほうがいい。

だから、この場合、220がたまたまカプセル化（この場合抽象データ型を意味するのであれば―だけど。
情報隠蔽であればケイも重視している）が本質ではないOO、つまり実行時動的性を重視するOOである
後二者が嫌いってだけのレベルの話。

234 ：デフォルトの名無しさん：2010/09/17(金) 11:41:48

プロトタイプベースは基本的に良くない

235 ：デフォルトの名無しさん：2010/09/17(金) 11:43:34

OOPのキモはやっぱ多態だと思うけどな～
インターフェース、抽象クラス、ダックタイピング、多重ディスパッチ…OOPLにはだいたいどれか入ってると思う
多態の要素が無いOOPLってあるの？

236 ：デフォルトの名無しさん：2010/09/17(金) 12:02:37

OOPLじゃなくても多胎ぐらいできるぞ
裏を返せばどういうことか判るよな

237 ：デフォルトの名無しさん：2010/09/17(金) 12:18:10

該当メソッド名があればコールできるようなＯＯＰＬのことかい？
あれは果たして多態とよぶのであろうか・・・。

238 ：デフォルトの名無しさん：2010/09/17(金) 12:35:18

言語に何があるかでなく
何が言語にあって欲しいかいらないか語ってくれ

239 ：デフォルトの名無しさん：2010/09/17(金) 16:58:18

>>237
それダックタイピングではなくて？

240 ：デフォルトの名無しさん：2010/09/17(金) 21:57:40

いよいよ混沌としてきたな。
でもそれがOOPの本質。
ケイ君の頭のバグが具現化したものが元祖OOP。
バグがバグを呼んで二次三次四次災害と永遠にループ。
自然治癒できないから、いっそ切り取ろう。。
OOPのことは忘れよう。皆で一斉に。

241 ：デフォルトの名無しさん：2010/09/17(金) 22:03:39

お前ら本当はオブジェクト指向で、プログラム作ったことないだろう。
作ってるつもりでも、それが本当にオブジェクト指向だと断言出来るか？
口だけの技術者が作ったプログラムを見せて、オブジェクト指向じゃないのに
偉そうにオブジェクト指向はこう作るんだとか言っている奴が多いからなｗ

242 ：デフォルトの名無しさん：2010/09/17(金) 22:06:23

お
作
口
偉

いまいち。

243 ：デフォルトの名無しさん：2010/09/17(金) 23:17:44

OOPっていったら多態だけど、
その仕組みに付随して色々便利機能がついてるから、どれが本質かわかんなくなりガチなんだよな

244 ：デフォルトの名無しさん：2010/09/17(金) 23:30:20

なんでお前ら、そこまで処理系の機能でOO語ることに執着するん？

245 ：デフォルトの名無しさん：2010/09/17(金) 23:55:34

じゃあこの世に存在しない、理想の OOP について、どうぞ。

246 ：デフォルトの名無しさん：2010/09/18(土) 00:05:33

分析・設計の観点を無視してOOPを語っても無意味だろ。
俺は「OO」と言ってるのに、「OOP」に変換されてる辺りが象徴的。

247 ：デフォルトの名無しさん：2010/09/18(土) 00:08:32

OOPで出来る事を無視して設計語ってもしょうがないだろ

248 ：デフォルトの名無しさん：2010/09/18(土) 00:22:00

チューリング完全な言語なら、どんなプログラムだって「出来る」。

分析・設計を、どれだけ素直にコードに落とし「やすい」かが重要なんだろ。
目的を無視して道具を弄んだって袋小路に陥るに決まってる。

249 ：デフォルトの名無しさん：2010/09/18(土) 00:22:37

OOAとかOODとかは派生物だから、OOと言えば普通はOOP

250 ：デフォルトの名無しさん：2010/09/18(土) 00:24:59

>>249
30年前ならその言い分は正しかったかもしれないがな。

251 ：デフォルトの名無しさん：2010/09/18(土) 00:25:50

分析や設計もコードでやれよ。
classと空のメソッド作ればいいだけじゃん。

252 ：デフォルトの名無しさん：2010/09/18(土) 00:27:41

>>246
ごめん、 oriented て形容詞だから、その後に何もないのが気になって。

253 ：デフォルトの名無しさん：2010/09/18(土) 00:28:00

>>251
そこでTDD等の開発手法の話を持ち出すならいいと思うよ。

254 ：デフォルトの名無しさん：2010/09/18(土) 00:30:08

テストはもっと見えてからじゃないと用意できない

255 ：デフォルトの名無しさん：2010/09/18(土) 08:26:26

論議も良いが、実益の話が出来ない時点で議論が不毛と感じる。
しかも継承を否定する意見も多い、継承はオブジェクト指向なかで
実利を一番説明しやすい部分なのに。

256 ：デフォルトの名無しさん：2010/09/18(土) 09:54:31

継承は、安易に使用すると弊害の方が大きいからな。

257 ：デフォルトの名無しさん：2010/09/18(土) 09:59:29

実利強調するなら説明してから言えよ

258 ：デフォルトの名無しさん：2010/09/18(土) 10:29:59

>>254
ユースケースで仕様を固めておけば、実装始める前にテストケースの骨格(メソッド名が決まってないので、やりたいことをコメントで記述)ぐらいはつくれるんじゃないかな

259 ：デフォルトの名無しさん：2010/09/18(土) 11:15:37

やっぱりOOP使うならUMLは理解できるようにしたほうがいいのかな

260 ：デフォルトの名無しさん：2010/09/18(土) 11:20:49

UMLこそ罠じゃね？
あんな静的な図が何の役にたつのだろうか。

261 ：デフォルトの名無しさん：2010/09/18(土) 11:43:27

理解できることに越したことはない。
UML理解≠OO理解だが。

262 ：デフォルトの名無しさん：2010/09/18(土) 11:55:42

>>256
弊害が出るなら継承を適用しなければ良いと思うが。
ところで、弊害とは？設計不良による継承の弊害じゃなくて？
設計から来る継承の弊害じゃないなら、継承自身の弊害を具体的に聞きたい。

>>257
継承の長所は既存ソースに手を加えないこと。
構造化時代の問題として、「実績のあるプログラムを
いかに既存部分に影響なく機能追加・削除出来るか」があった。
その答えの一つが継承だ。

263 ：デフォルトの名無しさん：2010/09/18(土) 12:58:06

そして地層のように継承されて誰もメンテしないカオスの塊になるわけだ
「そのソースは俺の担当じゃない」「管理してた人は10年前に辞めました」

264 ：デフォルトの名無しさん：2010/09/18(土) 12:59:53

protected 変数があって、派生クラスでそれを使う以上、
クラス階層の成長は、それに足をひっぱられるわな。

265 ：デフォルトの名無しさん：2010/09/18(土) 13:11:37

「正しく使えば」が前提ならgotoもグローバル変数も人畜無害になっちゃうよ

266 ：デフォルトの名無しさん：2010/09/18(土) 14:06:09

>>262
っ【リスコフ置換原則】

267 ：デフォルトの名無しさん：2010/09/18(土) 14:37:20

>>263
ソースは見なくていい、機能させ分かっていれば。
標準ライブラリのクラスを継承する時に中身を見ないと継承できないか？

>>264
それは内部の変数の設定でも行儀良くGetter・Setterを使えば済むこと。

>>265
別に継承を「正しく使えば」とは書いていない、どんな使い方でも
既存部分に影響を与えない利点はある。

268 ：デフォルトの名無しさん：2010/09/18(土) 14:42:53

>>267
少なくとも、近年では差分プログラミングを目的とした継承(IS-A)より、
インタフェースを介したオブジェクト間での委譲(HAS-A)がより良いとされているよ。

269 ：デフォルトの名無しさん：2010/09/18(土) 15:07:47

>ソースは見なくていい、機能させ分かっていれば。

バグ修正するときどうすんだよ

270 ：デフォルトの名無しさん：2010/09/18(土) 15:18:07

継承だと中身を見るまではしなくて良いが、ある程度はクラス全体を理解しておきたい
has-aなら利用側と全く変わらない理解度でおkだし、誤った継承もしにくいよ

271 ：デフォルトの名無しさん：2010/09/18(土) 15:19:06

テストがないの汚物(レガシーコード)は消毒(リファクタリング)ﾀﾞｧ~!!

まあ、間違った挙動に依存しているコードがあるかもしれないから、
おいそれとなおさねーよがMSの流儀ですね。

272 ：デフォルトの名無しさん：2010/09/18(土) 15:42:43

増築こそ長生きの秘訣
ただし被せたらうまくいかない
つまり継承は×

273 ：デフォルトの名無しさん：2010/09/18(土) 16:02:39

>>268
俺の知識では、それは多態の話だとおもうが。
それに、インタフェースはクラス全体で見ると差分プログラムと言えなくもないが
メソッドレベルだと、新規プログラミングで差分プログラミングじゃない。

>>269
既存ソースがなくてもバグは取れる。
そもそも前提条件が違う、業務運用を長年行なって品質の確かな
既存クラスに影響を与えず、機能追加・削除出来るから継承を使う。

>>270,271
同意。

274 ：デフォルトの名無しさん：2010/09/18(土) 16:49:55

なんか次は、

メソッド全体で見ると差分プログラムと言えなくもないが
行レベルだと、新規プログラミングで差分プログラミングじゃない。

とか言いそうな勢いだな。

275 ：デフォルトの名無しさん：2010/09/18(土) 16:57:21

エヘ

276 ：デフォルトの名無しさん：2010/09/18(土) 17:24:24

>>273
>既存ソースがなくてもバグは取れる。

具体的にはどうすんの？
オーバーライドしてメソッド書き直すの？

277 ：デフォルトの名無しさん：2010/09/18(土) 17:27:22

違うバグが増えそうだなｗｗｗ

278 ：デフォルトの名無しさん：2010/09/18(土) 18:53:59

今時差分プログラミングとか言ってる奴なんて相手にしないほうが良い。こっちまで巻き込まれるよ。遠ざけて置くのが吉かと。
継承でインターフェイス整えるのが便利って言うならまだ分かるんだよ。
ただ、「マルチメソッドはどうするの？」って切り返させてもらうが。
でもまだ分かるよ、気持ちはな。
差分プログラミング目的の継承は論外だよ。

ありえるのは、実は本人はインターフェイス周りに利点を感じているのにもかかわらず、
上手く思いを表現できずに、出てくる言葉が差分プログラミングどうのこうのになってるっていう、
いわゆるケイ君状態。こっちにエスパーしろってか？付き合いきれねぇ。
語学力というより、数学力が無いのだろう。

279 ：デフォルトの名無しさん：2010/09/18(土) 18:56:44

>>278
すまん、マルチメソッドってそんなのかいな？

280 ：デフォルトの名無しさん：2010/09/18(土) 18:58:04

> 差分プログラミング目的の継承は論外だよ。

そりゃそうなんだが、オープンクローズド原則って、
変更するときゃ継承しなよ、ってことだろ？　あれはどうなん？
oosc本によると、差分プログラミングで(ﾟДﾟ)ｳﾏｰと書いてるようにすら見えるが。

281 ：デフォルトの名無しさん：2010/09/18(土) 19:02:11

>>280
インターフェース(抽象クラス)使うなら、
変更するクラスは一から作り直すことになる。

282 ：デフォルトの名無しさん：2010/09/18(土) 19:34:26

差分プログラミングはまあいいとしても
バグを修正するために継承はないわ

283 ：デフォルトの名無しさん：2010/09/18(土) 20:28:22

ソースが無かったらけいしょうするしかないだろ

284 ：デフォルトの名無しさん：2010/09/18(土) 20:31:10

委譲しろよ

285 ：デフォルトの名無しさん：2010/09/18(土) 21:16:08

>>280
Wikipediaの開放閉鎖原則のページによれば、オリジナルはそういう意味だったが、
最近はインタフェースを利用汁という解釈に変化した、って書いてあるね。

286 ：デフォルトの名無しさん：2010/09/18(土) 21:28:12

ほらすごいね。
OOPだった連中ですら、今はもうインターフェース使えって言ってる。
インターフェース中心に考える・・・つまりオブジェクト指向ではなくインターフェース指向だと。
もうOOPは完全に消えてなくなったんだね。ﾅﾑﾅﾑ

287 ：デフォルトの名無しさん：2010/09/18(土) 21:41:28

実装継承が悪いわけじゃないけど、控えるべきだね
boost::operatorsとか、Haskellの型クラスのデフォルトメソッドみたいな
「多態性」を考慮しない実装継承なら有効

逆に言えば「多態性」を使うなら継承は使いにくいと思う
インターフェース継承+委譲とか、ダックタイピングとか使ったほうがマシ

288 ：デフォルトの名無しさん：2010/09/18(土) 21:42:06

OOPなんてもうバズワードに近い状態だと思ってる。

289 ：デフォルトの名無しさん：2010/09/18(土) 21:48:28

>>286
でもさ、OOPを、インタフェース志向に置き換えるのは、
すごくいいアイデアだと思う。モジュール性をよりプッシュ。

290 ：デフォルトの名無しさん：2010/09/18(土) 21:53:56

まー端的に言ってしまえば、物中心の考え方は土人の思考だ。
そのほうが考えやすいって奴は、昔風の人ってこったろう。
それはそれで別にかまわないんだけど、今は21世紀だし、そんな思考回路じゃそのうち干されちゃうよ。
数学習ったんだろ？コミュニケーションが大事だって散々言われてるんだろ？
物事の関係を抽出して上手くまとめて機能させる、それが創造性だろ？
神は細部に宿るって言うだろ？目では見ること出来ない「関係」に神は宿ってるんだよ。
少なくとも「物」には神は宿らないよ、八百万の神じゃあるまいし、古臭い。
発展途上国の人たちはバイクのことをホンダと言い、トラクターのことをクボタと言うらしいが、
まだまだ機能で考える文化が無いんだろうね。これからに期待しよう。
でもお前らは運よく日本で生まれて中学校まで義務教育で、大体の奴は高校へ行き、今なら大学行くのも当たり前で、
高等な教育を受けれるラッキーな環境で育ったんだから、もうちょっと頑張れるよな。
OOPなんぞの古い考え方にハマって折角のチャンスを無碍にするなよー。田代並みに残念な奴らだ。

291 ：デフォルトの名無しさん：2010/09/18(土) 22:27:53

またまともなアプリケーション作れなさそうなやつが来た

292 ：デフォルトの名無しさん：2010/09/18(土) 22:33:42

>>290
長い上に分かりづらい。
お前の言う関係って何？
コラボレート？
手続き？
何と何の関係なの？
客の要望からいきなり抽出出来るもんなの？

293 ：デフォルトの名無しさん：2010/09/18(土) 22:59:46

分からないなら無理しなくても良いんだよ。
正しく理解せず無駄に頑張って「関係も物として～」とかやり始めてたら、
いよいよ収拾がつかないwww手の施しようの無い狂人に成り果てる。

294 ：デフォルトの名無しさん：2010/09/18(土) 23:02:55

>>287
実装継承しないで元のソースにアクセス出来るなら現実的にはコピペコードを作ることになるけど、継承とどっちがマシなのか？

295 ：デフォルトの名無しさん：2010/09/18(土) 23:40:03

>>293
なんだ。
神だの何だの言ってるから何事かと思ったら、
単なる宗教家か。
無説明に恐怖心を煽って判断力を奪おうとする辺り、
とても新興宗教的。

296 ：デフォルトの名無しさん：2010/09/18(土) 23:41:32

>>286
オブジェクト指向設計の実装方法がインターフェース指向だってだけなんですが。

297 ：デフォルトの名無しさん：2010/09/18(土) 23:43:39

>>295
自分の理解できない概念をFUDしてるだけだしな。
全員が自分と同レベルになれば、何も勉強しなくていいしおまんまも食えるっていうチンケな心算。

298 ：デフォルトの名無しさん：2010/09/19(日) 00:13:17

自己紹介が好きな人が多くて困る。
誰しも自分の持ってる物差しでしか把握出来ないし語れないのだから無理も無いが。
俺はOOPは意味が無いと言う。
彼は俺がOOPを理解できないと言う。
俺は意味の有る/無しを論点にする。
彼は理解できる/出来ないを論点にする。
そのままその人の価値基準の表れなのだろう。

299 ：デフォルトの名無しさん：2010/09/19(日) 00:13:37

なんで世の中の言語にはstatic変数なるものがあるんですか？
かなり邪悪な存在だと思うんだけど。

300 ：デフォルトの名無しさん：2010/09/19(日) 00:16:07

そんなものはない。

301 ：デフォルトの名無しさん：2010/09/19(日) 00:16:49

なんでそうおもうの

302 ：デフォルトの名無しさん：2010/09/19(日) 00:17:58

どうせ邪悪な使い方しか知らないだけだろｗ

303 ：デフォルトの名無しさん：2010/09/19(日) 00:18:45

>>296
初めから「インターフェース指向設計」でいいだろ。いちいち回りくどい。

304 ：デフォルトの名無しさん：2010/09/19(日) 00:20:14

アジャイルってなんですの？

305 ：デフォルトの名無しさん：2010/09/19(日) 00:20:43

構造化プログラミングのサブルーチンの概念も破壊するよね。static変数。

306 ：デフォルトの名無しさん：2010/09/19(日) 00:31:57

>>305
オブジェクト指向のスレなんだから
関数内static変数とか、ファイルネームスペースのstatic変数とかではないだろ

307 ：デフォルトの名無しさん：2010/09/19(日) 00:34:10

え？

308 ：デフォルトの名無しさん：2010/09/19(日) 00:45:53

そして、どうでもいい話をし始める、と。
アンチすら居なくなってOOP完全消滅か。

309 ：デフォルトの名無しさん：2010/09/19(日) 00:48:33

え？

310 ：デフォルトの名無しさん：2010/09/19(日) 01:25:14

世の中の主流言語の大半がオブジェクト指向的な文法を取り入れてるこのご時世に消滅を予言とな？

311 ：デフォルトの名無しさん：2010/09/19(日) 01:27:14

え？

312 ：デフォルトの名無しさん：2010/09/19(日) 01:48:49

え？

313 ：デフォルトの名無しさん：2010/09/19(日) 09:57:33

>>276
>具体的にはどうすんの？
上でも書いたが、信頼性のあるクラスに影響を与えない為に
継承を使って差分プログラミングを行なう。
クラスのバグ修正は別の話。

>>279
>すまん、マルチメソッドってそんなのかいな？
俺もマルチメソッドってそんなものじゃないと思う。
マルチメソッドは継承や多態性とは関係ない。

>>280
>> 差分プログラミング目的の継承は論外だよ。
>そりゃそうなんだが
具体的に聞きたい、何故論外なんだ？

こちらも具体的な例を挙げるから、それについて書いてくれ。

例：あるメソッドの引数が和暦の誕生日だった。
ある日元号が新しくなる事になり、機能追加が必要になった。
俺はそのクラスを継承し、既存元号（明治～平成）はスーパークラスのメソッドを実行し
新しい元号のロジックのみをサブクラスに実装した。

>>282
同意。

>>284
委譲も使うべきだが、それが差分プログラミングが駄目だという理由にはならない。

314 ：デフォルトの名無しさん：2010/09/19(日) 11:19:54

>>294
個人的にはまだコピペコードのがマシじゃないかと思う。
というかコピペコードでもあんま問題にならんくらい
クラスはコンパクトにしとけと思う。

315 ：デフォルトの名無しさん：2010/09/19(日) 12:46:34

>>313
なんかその例の設計自体がおかしい感じがするけど
普通に和暦を引数に取ってるメソッドそのものを修正したほうがいいと思うんだが

サブクラスに修正内容を実装しちゃったら、既存のスーパークラス使ってるロジックを
サブクラスに置き換えて修正する必要が出てくる気がするんだけど、それは許容するの？

316 ：デフォルトの名無しさん：2010/09/19(日) 12:47:24

差分プログラミングほど想定外の仕様変更に弱い物無いだろ
一旦今の仕組みじゃ無理とわかったら、目的のスーパークラスまでガッツリ穴掘って
カスタマイズポイントつくらないといけない。

そりゃ設計がヘボなんだと言われたら、あるいはそうかもしれんが
どんな仕様変更にも耐えうる何でもスーパークラスなんてもっと地雷だからな。

継承なんか極力使わずにできるだけ合成で済ませればそんな問題は起こらない。

317 ：デフォルトの名無しさん：2010/09/19(日) 15:42:19

>>315
>なんかその例の設計自体がおかしい感じがするけど
>普通に和暦を引数に取ってるメソッドそのものを修正したほうがいいと思うんだが
具体的に書いてくれ。

>サブクラスに修正内容を実装しちゃったら、既存のスーパークラス使ってるロジックを
>サブクラスに置き換えて修正する必要が出てくる気がするんだけど、それは許容するの？
俺の中での常識では、自分が作ったクラス変数から直にオブジェクトを作成する
ハードコーディングは絶対に駄目だと思っている。
だから修正する必要はないように始めから作っている。

318 ：デフォルトの名無しさん：2010/09/19(日) 16:17:03

315とは別人だが、それは明らかにクソ設計
継承での差分ってのは、動的な多態をする際にメリットがあるわけだけれども
その追加のやり方だと
(～明治まで計算出来る)
(～大正まで計算出来る)
(～昭和まで計算出来る)
みたいなクラス階層が出来るが、これで多態すんの？
最新版以外は何の役にも立たないじゃん
is-a関係とか、全く気にしてないでしょ

>自分が作ったクラス変数から直にオブジェクトを作成する
>ハードコーディングは絶対に駄目だと思っている。
暗号すぎる

319 ：デフォルトの名無しさん：2010/09/19(日) 17:30:43

まじ暗号だな。
まさに言葉の定義の曖昧なOOPらしい会話だ。
同じ概念なのに独自の言葉を再発明。
違った目的なのに、同じ文法。ポリモ、差分P、カプセル化、全部クラスの仕組みでやってねー。
頭悪くなるんだと思うよ、やってる連中も、そいつらに関わった奴も。
朱に交われば赤くなるって言うんだっけか。

320 ：デフォルトの名無しさん：2010/09/19(日) 18:18:26

>>319
テンプレートも忘れないでください

321 ：デフォルトの名無しさん：2010/09/19(日) 18:18:55

静的ポリモと動的ポリモを正しく使いわけよう

322 ：デフォルトの名無しさん：2010/09/19(日) 19:20:35

>>318,319
暗号ってｗ　前に彼女がソースを見たとき、暗号っぽいねと言ってたのを思い出したわｗ
知識の無い奴が見ると暗号なんだろうな >>317がどの言語を使っているかわからんが
メタクラスやクラス参照型、あとポインターもSingletonっぽく書けば出来るだろう
お前ら、インスタンス生成をハードコードで書いているのか？
これスレが噛み合わないのはレベルの違いだな

323 ：デフォルトの名無しさん：2010/09/19(日) 19:28:09

そうだね、この住人はレベルが違い過ぎるね

324 ：デフォルトの名無しさん：2010/09/19(日) 19:36:12

>>322
文の切れ目が判らん、パーザがエラー起こすんだ
引用された文に括弧付けて貰うと助かる

325 ：デフォルトの名無しさん：2010/09/19(日) 20:34:35

OOPなんだから学術的な話かとおもったら

思いっきり実装でソースがドロドロしてる話だったなり

326 ：デフォルトの名無しさん：2010/09/19(日) 21:00:18

>>317の下の段を頑張って解釈してみると、クラス変数っていうのは一般的に言うクラス間で共有出来る静的な変数じゃなくて
クラスインスタンスとかクラス名の事を指していて、ハードコーディングというのはクラス名を直接書いてnewする事を指している
そしてなるべく具体的なクラス名を記述せずに実装するのが前提なので、コードの修正無しに差し替え可能だと言ってる……のかな

なんかのフレームワークが前提になってる？

327 ：デフォルトの名無しさん：2010/09/19(日) 21:10:43

学術と実装は関係ないと。

328 ：デフォルトの名無しさん：2010/09/19(日) 21:58:28

学術的な話ができればここまで混沌とした会話をせずに済むんだがな。。

とりあえず、継承の欠点その1は、機能拡張の軸が二つ以上あるようなクラスの
継承を始めると、子クラスの数が爆発を起こすこと。
このような場合は、軸ごとにクラスを分けて委譲することで解決できる。

329 ：デフォルトの名無しさん：2010/09/19(日) 22:09:11

現場の言葉で話せないと。
無力だな。

330 ：デフォルトの名無しさん：2010/09/19(日) 22:40:03

現場がOOPを語りだしたらﾊﾞｼﾊﾞｼつぶします
何でもいいから手を動かせよ

331 ：デフォルトの名無しさん：2010/09/19(日) 22:54:26

>>318
多態性の話じゃない、それに
>最新版以外は何の役にも立たないじゃん
>is-a関係とか、全く気にしてないでしょ
「引数が和暦の誕生日」だから最新以外も使われる。
ちゃんと読んで書いてくれ。

>>319
>まじ暗号だな。
そんなに分かり難い表現だったのか？

>>326
その通りの意味で、メタクラスを使っている。
クラスを抽象化するのは基本だと思っていたが違うみだいだ。

しかし、クラス名をハードコーディングしたら
差分プログラミングは出来ないだろうに？

>>328
>とりあえず、継承の欠点その1は、機能拡張の軸が二つ以上あるようなクラスの
>継承を始めると、子クラスの数が爆発を起こすこと。
それはある。しかし俺が話しているのは多態性の話じゃなく差分プログラミング。

>このような場合は、軸ごとにクラスを分けて委譲することで解決できる。
多分BridgeパターンやDecoratorパターンみたいな解決方法をいっていると思うが？
その場合の委譲は、継承と組み合わせ場合が多いと思うが。

332 ：デフォルトの名無しさん：2010/09/19(日) 23:16:04

>>328
さぁ、学術的回答が聞かれるかなｗ

333 ：デフォルトの名無しさん：2010/09/19(日) 23:18:48

>>331
横から。

>>最新版以外は何の役にも立たないじゃん
>「引数が和暦の誕生日」だから最新以外も使われる。

明治、大正、昭和、平成が扱えるクラスががある時、
設計上、明治、大正、昭和が扱えるクラスは要るのか？
っつー話じゃね？

実装上は、内部のみで使ってるか知らんが。

334 ：デフォルトの名無しさん：2010/09/19(日) 23:22:50

差分プログラミングは糞

335 ：デフォルトの名無しさん：2010/09/19(日) 23:34:30

出た、学術的回答ｗ

336 ：デフォルトの名無しさん：2010/09/19(日) 23:35:28

リファクタリングできないとあんまり意味ないよな

337 ：デフォルトの名無しさん：2010/09/19(日) 23:41:02

>>333
それも違うんじゃないか？

338 ：デフォルトの名無しさん：2010/09/19(日) 23:48:17

差分プログラミングって何が良いの？

339 ：デフォルトの名無しさん：2010/09/20(月) 00:10:07

何を使ったって過去に書かれた文書から内容を読み解くのに時間が掛かる
ソースの作りかたにこだわるよりはラノベでも読んでおけよ

340 ：デフォルトの名無しさん：2010/09/20(月) 00:55:16

差分プログラミングが全ての場合においてよくないわけではないが、多くの場合、
リスコフ置換原則に反するようなやり方になりがちなのが問題、ということじゃないかと。

過去の自分と今の自分、そして未来の自分は、大抵において、相互に矛盾する考えを
持ってプログラミングしている可能性が低くないしね。別人だと言ってもいい。

341 ：デフォルトの名無しさん：2010/09/20(月) 09:58:44

>>333
なるほど、しかし回答は同じだけど。
差分プログラミングはスーパークラスの仕様が分かっていれば設計は知らなくていい。
それに、多態性じゃなく差分プログラミングなんだから
>(～明治まで計算出来る)
>(～大正まで計算出来る)
>(～昭和まで計算出来る)
じゃなく(～昭和”まで”計算出来る)　は　(昭和”の”計算出来る)　見たいに積み重なっていくと思うけど。
確かにその設計は >それは明らかにクソ設計
かもしれない、そんな発想もなかった。３３３はよく理解出来たね？

>>336
駄目だ意味が分からない、ワンフレーズだと理解出来ないもんだ。

>>338
俺的に一番は、デグレード”予防”だと思う。

>>340
>リスコフ置換原則に反するようなやり方になりがちなのが問題、ということじゃないかと。
俺の考えでは逆。
既存を残して積み上げていくから「リスコフの置換原則」を守りやすい。

342 ：デフォルトの名無しさん：2010/09/20(月) 11:52:23

つーか差分プログラミングって修正で済むようなものでも何でもオーバーライドで解決するようなポリシーを指してるっけ？
単純に似たような物を作る時に既存部分を流用する手法程度に思ってたんだけど

343 ：デフォルトの名無しさん：2010/09/20(月) 12:15:52

>>341
>３３３はよく理解出来たね？
むしろ341が理解できない。
積み重ねる、のニュアンスが致命的にズレてるのかも。
元号の判定は誰がすんの？

もう日本語よりJAVAか何かで話した方が早い気がしてきた。

344 ：デフォルトの名無しさん：2010/09/20(月) 12:45:16

>>341
俺が言いたいのは、「既存を残して積み上げていく」手段として継承を使うと、
以前の要求に基づいたクラスと、現在の要求に基づいたクラスという、
二つの異なる考え方に基づいたコードが地層として積み重なるということが
起きるのは良くないのではないか、ってこと。

うまく作ればいいのかもしれないが、外部からそのオブジェクトの機能を見た時の
一貫性が失われる結果になる可能性は高い。

345 ：デフォルトの名無しさん：2010/09/20(月) 12:54:06

>>344がいいこと書いた！

346 ：デフォルトの名無しさん：2010/09/20(月) 13:31:16

正しく使えば
うまく作れば

347 ：デフォルトの名無しさん：2010/09/20(月) 14:55:19

なぁ、いつもの人だけど、そろそろ俺の出番じゃね？
なんか放っておくと、どんどん実装よりの小手先な話に話題が拡散していくな。
スレの話題が、数多ある地獄からヌーと伸びてきた手に引きづられ、自分たちのフィールドに持ってかれる。
それぞれ違った常識の中に生きてるから、話がまるでかみ合わない。こんな展開、OOPらしいっちゃらしいが。
が、しかし、2chのように色々な人が居る場所でそれやる意味あるか？
学術的どうのこうの言ってた人も居たけど、そういうことだろ。

・オブジェクトとは何か。
・メッセージングとはどういった行為か。
その辺から一つ一つ真面目に定義していけば、OOPの全貌が見えてくるし、
プログラミング、ソフトウェア工学、設計、そういったものの本質も見えてくるだろう。
その結果、OOPイラネってなるかもしれないし、使いどころだってなるかもしれないし、
必要悪だってなるかもしんないけど、それは各自の判断だろうに。

348 ：デフォルトの名無しさん：2010/09/20(月) 14:58:21

> ・オブジェクトとは何か。
> ・メッセージングとはどういった行為か。
> その辺から一つ一つ真面目に定義していけば、OOPの全貌が見えてくるし、

ないない。どういう設計的前提を置くかを明確にせずに、それだけ語っても宗教論争にしかならん。

349 ：デフォルトの名無しさん：2010/09/20(月) 15:01:23

じゃあ設計的前提とやらを語ってくれ

350 ：デフォルトの名無しさん：2010/09/20(月) 15:12:09

いつもの人だけど、俺も設計的前提とやらが聞きたい。
顧客要求は分かるよ、でも設計的前提wって何よ。
相手を自分の都合のいいフィールドに引きづり込むための制約か何かかw

設計的前提、設計的前提、設計的前提・・・
設計って「行為」なのに、「的」つけてわざわざ物みたいな扱いにしてるのが
OOP脳っぽいっちゃぽいな。
そういう些細な言葉のチョイスにその人と成りは表れてしまう。恐ろしいね。
まさに神は細部に宿る。

351 ：デフォルトの名無しさん：2010/09/20(月) 15:29:20

・オブジェクト=データと処理（メソッド）を持つもの。変数に束縛できる
・メッセージ=オブジェクトからメソッドを呼び出す行為

最低限のOOっていうか、OO言語の共通点ってこれくらいしかない

352 ：デフォルトの名無しさん：2010/09/20(月) 16:12:32

いや、それで十分だろう。
かりに、そう定義したとして、

>オブジェクト=データと処理（メソッド）を持つもの。
データと処理をひとまとめにする意味は？

>メッセージ=オブジェクトからメソッドを呼び出す行為
メソッド呼び出して、結局のところ、何がしたいの？
その行為の意味は何？

俺らのしたがってることは一体何？

と、話題を発展することが出来る。

353 ：デフォルトの名無しさん：2010/09/20(月) 16:54:59

>>342
>単純に似たような物を作る時に既存部分を流用する手法程度に思ってたんだけど
汎化だろ？俺もそう思っていた、たぶん341とのズレは新規か既存プログラムのどっちを
対象にしているかの違いじゃないのか？

354 ：デフォルトの名無しさん：2010/09/20(月) 17:48:36

ここは偽学者と偽プログラマーしかいないな

355 ：デフォルトの名無しさん：2010/09/20(月) 19:15:32

>>343
話がズレている。差分プログラミングの話なのに
なぜ継承元の構造をそこまで意識しないといけない？
あと　>元号の判定は誰がすんの？
オブジェクト指向だから、オブジェクト自身が判断する。

>>344
>以前の要求に基づいたクラスと、現在の要求に基づいたクラスという、
>二つの異なる考え方に基づいたコードが地層として積み重なるということが
>起きるのは良くないのではないか、ってこと。
意味が理解出来ない、「以前の要求に基づいたクラス」と「現在の要求に基づいたクラス」は
インスタンスが違うだから、「異なる考え方」でも問題はないと思うが？
もちろん、クラスは抽象化してインスタンス作成もクラスに任せるから呼び出し側に
意識させないようにするけおど。

>>347
>なぁ、いつもの人だけど、そろそろ俺の出番じゃね？
まかせる。

356 ：デフォルトの名無しさん：2010/09/20(月) 19:53:35

GUIを表現するクラスに機能を追加するときによく継承を使うようになってる作りのライブラリは結構みかけるんですが
機能の拡張に継承は駄目でなるべくコンポジションを使うべきとか聞いた記憶があります
何故駄目なんでしょうか？

例:
標準のイベントハンドラを拡張したハンドラ、それ用の補助メソッドや振舞設定用インタフェースを実装するダイアログボックスExtendedDialogを作るときに
標準のダイアログボックスクラスDialogを継承することで、標準の実装を利用し実装した
尚Dialogは継承されることを前提とした作りにはなっているとする

それとも「なるべく」なだけで、こういう場合なら大きな問題はないのでしょうか？

357 ：デフォルトの名無しさん：2010/09/20(月) 20:19:11

今GUIは結構古い時代に設計された物や、それを間接的に使用していることが多いので
オブジェクト指向と言ったら継承っしょみたいなノリで継承が多用されてる

しかし、一口に継承と言っても
実装の継承: コードの使い回しを目的にした継承
概念の継承: 多態性を利用する目的の継承（インターフェース継承）
の二つの継承があり、この二つが混同されることによって厄介な問題が起きる。

ちなみに、C++はprivate継承といって、実装だけの継承も出来るのだけど、
boost::operatorsみたいな特殊なパターンを除いては、コンポジションが推奨されてるみたい。

358 ：デフォルトの名無しさん：2010/09/20(月) 20:43:48

>>355
ズレてるってか多分俺が理解できてない。

>なぜ継承元の構造をそこまで意識しないといけない？
今のところ、凄くやっつけ仕事を言ってるに見えてるから。
システム全体として引き継ぎ易い構造になるの？

359 ：デフォルトの名無しさん：2010/09/20(月) 21:30:24

>>356
言語や開発環境でいろいろなケースがあると思うけど、俺が考えつくのは
ライブラリや開発環境が比較的代わりやすい場合は
コンポジションの方が影響を受け難い。
コンポジションは別クラスに実装するから、相手のフィールドやメソッドを直接操作出来ない。
これは欠点でもあるし、影響を受け難い利点にもなる。
継承の場合、スーパークラスが修正されると影響が出るから安定したクラスを親にしないと。
言語はjavaとか？　

>>358
>今のところ、凄くやっつけ仕事を言ってるに見えてるから。
差分プログラミングの例だから、そこまで考えていない。
和暦を入力パラメータにもつメソッドに
新元号が追加される単純な話だから。

360 ：デフォルトの名無しさん：2010/09/20(月) 21:50:40

>>355
契約プログラミング的な考え方を非常に大雑把に言えば、
「あるインタフェースを持つオブジェクトがユーザに対して見せる機能は、
常に一貫していなければならない」と言えると思う。

差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
むしろ相反する場合の方が多いのではないか、というのが俺の意見。

もちろん、両者が一致する範囲内での話なら特に問題はないと思う。

361 ：デフォルトの名無しさん：2010/09/20(月) 21:58:50

>>360はいつも良いこと書くな！

362 ：デフォルトの名無しさん：2010/09/20(月) 22:46:19

>>360
なるほど、そう言うことが言いたかったのか。

>差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
>という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
>むしろ相反する場合の方が多いのではないか、というのが俺の意見。
俺の意見は、差分プログラミングは基本包含になるから継承しても事前/事後条件は守られる。
俺の浅いEiffelの知識でも大丈夫だったと思うが。

ただ機能削除や別機能なら言う通りだと思う。

363 ：デフォルトの名無しさん：2010/09/20(月) 23:05:34

いつもの人だけど、な？暗号だろ？読む気するか？
肝心の、「オブジェクトがメソッドを持つべきかどうか」に関しては何も考えない、というか、それが当たり前と思ってるのな。
OOPのグダグダは全部そこから始まってるといっても過言ではないのに。
そこ無視して小手先のフォローに走る。OOPらしいっちゃらしいが。

364 ：デフォルトの名無しさん：2010/09/20(月) 23:33:15

少なくともC++とかの継承で多態と差分Pを同時にやるとだいたい破綻するから
やるなら多態だけにして、あとはできるだけ合成しろって事でしょ。

365 ：デフォルトの名無しさん：2010/09/20(月) 23:37:10

>>363
少しはこのスレの住人を説得してみろよ

366 ：デフォルトの名無しさん：2010/09/21(火) 00:39:54

>>363
OOPだとモジュール構成の最小単位がオブジェクトで、
オブジェクト同士が協調しる手段としてメソッドがあるんたから、
オブジェクトはメソッドを持ってて当たり前だと思うけど。

「OOPはよろしくない」って話？

367 ：デフォルトの名無しさん：2010/09/21(火) 00:46:01

>>366
多重ディスパッチのことを言ってるんじゃね

>>363
個人的には「オブジェクトがメソッドを持つべきか」は正直どうでもいいなあ
それが多重ディスパッチとかのことなのであればの話だが…
最低限多態さえ出来れば手段は何でもいいと思うよ
カプセル化や継承も、あったら便利だな程度の認識だわ俺は

368 ：デフォルトの名無しさん：2010/09/21(火) 19:39:54

>>363
そんな話し書店に行けばいくらでも読める。
俺は実践から学んだ人の考えを知りたい。
お前は図書館でもいってろ。

369 ：デフォルトの名無しさん：2010/09/21(火) 19:58:41

そうだね、本を読めば分かることを２ちゃんで勉強するバカはいないよｗ
やっぱり不特定多数の人が集まるところでは、経験から来る話を一番に聞きたいね。

370 ：デフォルトの名無しさん：2010/09/21(火) 20:29:29

しかし、本当にOOを経験している人間がこのスレに何人いるか？

371 ：デフォルトの名無しさん：2010/09/21(火) 20:42:46

ttp://togetter.com/li/25507
最近調べ物をしててこれを知ったんだけど
publicやprivateなどの可視性は事前条件とは無関係なんだろうか？
C++ではvirtualなメンバ関数はprivate推奨のNVIイディオムとかあるし

それとは別にis-a関係はLSPにとって十分でないことを知り
調べるほどに、継承を使える自信が無くなって行く

372 ：デフォルトの名無しさん：2010/09/21(火) 21:09:31

NVIイディオムってなんぞ？

373 ：デフォルトの名無しさん：2010/09/21(火) 21:19:00

Non-virtual interface

それはさておき、クラスのprivateな状態をメソッドの事前条件にするのは良くない。
呼び出し側がチェック不能だから。

374 ：371：2010/09/21(火) 21:31:29

自己レス。
>publicやprivateなどの可視性
この認識はそもそも誤りだった。
publicやprivateはアクセス権(accessibility)のコントロールであり、
可視性(visibility)とは別の概念

>>373
というわけで、その主張は俺の勘違いと同じ誤りを含む
検証可能なソースとしては
C++の仕様書をvisibilityで検索すると1箇所(+索引)しかヒットせず
そこにはaccessibilityとvisibilityは違うと書いてある

となると、アクセス権と事前条件の話は独立、と考えるのが正しいのかな
上の記事はどちらかというと疑って読んでたんだけど
上のtwitterの人はまじプロいな
なんたるPitfall

375 ：デフォルトの名無しさん：2010/09/21(火) 21:56:34

単に、派生クラスのインスタンスを基本クラスのそれと思って好きなように扱っても、
そのプログラムは常に正しい動きをするって事なんじゃないのかな

そんなにややこしいかねLSPって

376 ：デフォルトの名無しさん：2010/09/22(水) 03:52:21

SettingDialogクラスをDialogクラスからprivate継承すれば、
SettingDialog sd = new SettingDialog();
sd.bModal = false; //エラー
Dialog tmp = sd; //エラー
tmp.width = 0;
とできる。

しかしDialogクラスのコンストラクタでdialogManagerか何か、クラスの外にDialogクラスのポインタ/参照
として渡されている可能性を考えると完璧とはいえない。

377 ：356：2010/09/22(水) 04:14:15

Qtライブラリ(言語はC++)の設計を真似した例だと
(*)AbstractDialogクラスを実装したDialogクラスがあって
こいつの実装を利用して(一部の振舞いは変更して)MyDialogクラス作りたい

MyDialogもAbstractDialogインタフェースを実装すればこのインタフェースを想定する他のクラスと組み合わせることができる
じゃあとりあえずpublic継承してメソッドオーバーライド使うのが目的の達成は一番楽だよね
Qtもこういうプログラミングを想定しているようだし

これをMyDialogクラスがDialogクラスのインスタンスをprivateメンバに持つような形の包含にしちゃうと
一々MyDialogクラスの定義でAbstractDialogインタフェースのメソッドの定義を、
振舞いがDialogクラスのそれと全く同じでも書かなくちゃならない

void fuga() { m_dialog.fuga(); }
とかね

MyDialogクラスをAbstractDialogクラスのインタフェースを使って参照等で扱う、または直接扱う場合なら問題なさそうだけど
MyDialogクラスをDialogクラスの参照経由で扱うとかならちょっと嫌な臭いがする気がする
これが>>357のいう混同なのかな？

378 ：デフォルトの名無しさん：2010/09/22(水) 05:31:34

インターフェイスならそんな抽象クラスみたいな名前じゃなくてIDialogとかにしてくれ。

379 ：デフォルトの名無しさん：2010/09/22(水) 07:21:52

その場合は、インタフェースの継承（AbstractDialog）と、
実装の継承系統を分けた方良いんでない

DialogImplみたいな別クラスをAbstractDialogに所有させる。
違う挙動が欲しければImplの方をいじる。

380 ：デフォルトの名無しさん：2010/09/24(金) 21:39:31

継承が一応の結果が出たから次は
・カプセル化

まず構造化と比べオブジェクト指向はどう違うか？

381 ：デフォルトの名無しさん：2010/09/24(金) 22:59:25

あるスコープから見える範囲についての決まりを強制する機能が処理系にある。

お　　し　　ま　　い

382 ：デフォルトの名無しさん：2010/09/24(金) 23:10:28

>あるスコープから見える範囲についての決まりを強制する機能が処理系にある。
馬鹿？　お前自身が終わっているぞｗ

383 ：デフォルトの名無しさん：2010/09/24(金) 23:49:24

自説を論証しない馬鹿に馬鹿と言われてもなぁ。

384 ：デフォルトの名無しさん：2010/09/25(土) 00:05:41

カプセル化ねえ…構造体との最大の違いは
要素へのアクセスを「確実に」共通化できる、ってとこじゃないだろうか
構造体だと、どこか1つでも直接アクセスしたら共通化が外れちゃうからね

その恩恵は多人数開発だけじゃない、個人での開発でもある
例えば、あるフィールドをpublicでの直接アクセスから
private+アクセサメソッドに切り替えたくなった時とかね

フィールド代入をメソッド扱いにできる言語なら、利用側はそのままで
宣言／定義の書き換えだけで済むし
そうでない言語でも、フィールドをprivateにしたことで
利用側でアクセサメソッドを通してない部分はコンパイル時に炙り出される

385 ：356：2010/09/25(土) 00:11:52

見えない化
見せない化
意識させない化

386 ：デフォルトの名無しさん：2010/09/25(土) 00:13:26

継承や多態性と違ってカプセル化（PrivateやらProtectedやら）は本質的なもんじゃないから
議論する必要ないだろ

お　し　ま　い

387 ：デフォルトの名無しさん：2010/09/25(土) 00:23:32

カプセル化が一番の肝だろ

388 ：デフォルトの名無しさん：2010/09/25(土) 00:30:24

そうだ、カプセル化が一番理解されてないといっても過言でない

389 ：デフォルトの名無しさん：2010/09/25(土) 00:44:09

(ﾟДﾟ)

390 ：デフォルトの名無しさん：2010/09/25(土) 00:47:15

カプセル化がない（もしくは希薄な）OOP言語は無視ですか

391 ：デフォルトの名無しさん：2010/09/25(土) 00:51:12

でも一番重要視されてしかるべきなのはカプセル化だと思うぞ。
継承なんて言ってしまえばただの便利機能だし。

カプセル化は便利とは真逆の、アクセスを制限してしまう不便機能だが
そんなものがなぜプログラムに必要で重宝されるのか、もうちょっと真剣に理解したほうが良い。

392 ：デフォルトの名無しさん：2010/09/25(土) 00:51:21

>>386,390はアクセス修飾だけがカプセル化と思ってるんじゃまいか？

393 ：デフォルトの名無しさん：2010/09/25(土) 01:01:59

カプセル化もバズワード臭いんだよなぁ
単にグループ化を指してる人と
オブジェクトのインターフェースを作る事を重要視してる人と
データを隠蔽する事を重要視している人が居るから

394 ：デフォルトの名無しさん：2010/09/25(土) 01:06:10

全部だ全部、
全部大事なんだよ。

プログラムの宿敵はスパゲッティだ。
全部それを避けるための手法だ。

395 ：デフォルトの名無しさん：2010/09/25(土) 01:21:00

多態が無くなっても
せいぜい要所に型switch入れるぐらいの変更で済むが
カプセル化が無くなると大変酷いことになる。

396 ：デフォルトの名無しさん：2010/09/25(土) 01:50:48

カプセル化が無くなっても
せいぜいクラスを構造体に替えたりアクセサを関数に変えるくらいの変更で済むが
多態が無くなると大変酷いことになる。

397 ：デフォルトの名無しさん：2010/09/25(土) 02:07:46

つまりどちらも不要ということですね

398 ：デフォルトの名無しさん：2010/09/25(土) 02:13:00

俺は最重要は多態と思う、これが無いとコードを根本から直さないといけない。
要所に型switchで代用できるレベルならいいけど、そうとも限らないからな。

次点でカプセル化だな、使い方が解りやすい割に幅広く、便利機能って言葉がぴったり。
無くてもなんとかなるっちゃなるんだが、あって欲しい機能ではある。

継承はたまーに欲しいんだが、普段は多態の一手段でしかないのがなあ。
他の手段で代用できるのなら要らないことも多い。
でも、大きめのライブラリを作る場合にはちょっと欲しいかな。

399 ：デフォルトの名無しさん：2010/09/25(土) 03:55:49

また実装レベルの話に後退したでござる。

400 ：デフォルトの名無しさん：2010/09/25(土) 04:17:04

論文の一本でも引っ張ってこいよ

401 ：デフォルトの名無しさん：2010/09/25(土) 08:09:37

実装の話をしないプログラミング

402 ：デフォルトの名無しさん：2010/09/25(土) 08:24:58

もともとオブジェクトは一種の変数で構造化で言うグローバル変数。
使う側も使われる側も相手を意識しないオブジェクトではグローバルに定義されている。
しかしグローバル変数の弊害が、オブジェクト指向ではあまり聞かれない。
構造化のスコープとオブジェクト指向のカプセル化は考え方の違いがある。

403 ：デフォルトの名無しさん：2010/09/25(土) 08:30:03

グローバルスコープとクラススコープは別物

404 ：デフォルトの名無しさん：2010/09/25(土) 09:27:37

>グローバルスコープとクラススコープは別物
クラスとオブジェクトの区別もつかない奴がいるとは

405 ：デフォルトの名無しさん：2010/09/25(土) 09:35:18

Rubyではクラスもオブジェクトだぞ

406 ：デフォルトの名無しさん：2010/09/25(土) 10:16:56

カプセル化を単なる便利機能とか言ってる時点で何かを履き違えている。
設計の本質は依存関係の整理であって、継承関係の構築じゃない。

407 ：デフォルトの名無しさん：2010/09/25(土) 10:25:33

いるよな、全てのクラスを単一の継承ツリーに収めようとする奴。
あれはOOPやりはじめの熱病みたいなもんかな。

408 ：デフォルトの名無しさん：2010/09/25(土) 11:41:18

>>381
何を「処理系」と言っているのか理解出来ないが
オブジェクト指向はデータに処理が付く、その基本観点が抜けている。
>>384
言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。
>>386
仮に「本質的なもんじゃない」としよう（本当にそうなのかもしれないが）
だが、オブジェクト指向では必要なものだ。なぜ必要なのか議論してもいいと思うが。
>>390
カプセル化の定義を聞きたい。
>>393
なるほど、カプセル化の結果から考える人はそうなるな。
ここではカプセル化の本質から考えるのがいいと思う。
>>394
勘違いしている「スパゲッティ」は制御文の話だ。データの話ではない。
>>395,396
>カプセル化が無くなると大変酷いことになる。
>多態が無くなると大変酷いことになる。
具体的に？　
マシン語や構造化の時代でもカプセル化・多態性が無くても
それなりの手法はあって「大変酷い」事にはなっていなかったが。
>>406
>設計の本質は依存関係の整理であって、継承関係の構築じゃない。
具体的に？　俺はオブジェクト指向設計の本質は再利用だと思うが。

409 ：デフォルトの名無しさん：2010/09/25(土) 12:18:55

>>408
今のWindowsアプリをマシン語で書けって言われて大変酷い事にならない奴がいたら天才
プログラムの規模が昔のままで良いんなら別にOOPもなくて良い

そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない

410 ：デフォルトの名無しさん：2010/09/25(土) 12:26:05

>>408
>言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
>なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。

OOPの機能とカプセル化の相性が良かったからでしょ。
カプセル化ってのはデータと処理を一括りにすることなワケで
データと処理を分割している非OOPLでそれをやるのは、新たな要素を追加しなきゃならんが
そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。

411 ：デフォルトの名無しさん：2010/09/25(土) 14:13:06

>>409
論点がずれている。どう「大変酷い」になるか聞いている。
アセンブラでも構造化でも大規模開発はあって、綺麗なソースも存在した。
君が言う通り「天才」なのかもしれんが．．．

>そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない
オブジェクト指向で再利用を否定できるのは、まだまだオブジェクト指向の理解が足りないから。

>>410
>カプセル化ってのはデータと処理を一括りにすることなワケ
カプセル化をそう考えるのか、俺はカプセル化＝情報隠蔽と考えるから
「データと処理を一括りにする」はカプセル化とは考えていない。
つまり、publicのみにフィールド・メソッドが書かれている場合
カプセル化は適応されていないと考える。

>そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。
一括りにするだけなら、publicやprivateなど要らない。
オブジェクト指向はpublicやprivateなどの新しい概念を導入している。

412 ：デフォルトの名無しさん：2010/09/25(土) 14:34:50

>>411
どう大変酷くなるか、なんて考えなくてもわかるもんでは？
誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
そのあたりを何のツールも使わずに完璧に整理できるならOOPLなど要らないと言ってる。
そしてそれができる奴は天才だし、どんな言語でどんな開発規模でもうまくやってのけるだろう。

OOPにおける再利用は依存関係をうまく整理した上で得られた副次的な物に過ぎない。
逆に言えば、依存関係がうまく整理できたならOOPなど関係なく再利用性の高いコードになる。

「オブジェクト志向」がいったい何を志向しているのかといったら
それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。

413 ：デフォルトの名無しさん：2010/09/25(土) 14:45:54

ここまでオレオレOOP
そしてこれからもオレオレOOP

414 ：デフォルトの名無しさん：2010/09/25(土) 16:14:09

>>411
情報隠蔽は「データと処理を一括りにすること」で生まれる二次的な効果じゃね？
データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
情報の隠蔽もなされるワケで。

415 ：デフォルトの名無しさん：2010/09/25(土) 16:42:21

http://scholar.google.co.jp/scholar?q=object-oriented+programming&hl=ja&lr=
acm のが一番古いっぽいんだが今大学いない一般人なのでむりです

416 ：デフォルトの名無しさん：2010/09/25(土) 17:49:15

> 情報隠蔽は「データと処理を一括りにする
CLOS あたりはクラスはメソッドを抱えていないが…

417 ：デフォルトの名無しさん：2010/09/25(土) 18:56:54

いつもの人だけど、
CLOSの話にもっていきたい人がいるみたいだけど、
多分それ、正解。でもバカどもは食いつかないだろうな。
OOPのObjみたく、自分で情報を遮断して殻に閉じこもってるから。

だから、議論は成り立たないから、天下り的に一言で未来を予言してみせるしかない。
モノに執着した考え方は破滅を招く。
オブジェクト指向？ﾉﾝﾉﾝ
関係指向、関数指向、機能指向、メッセージング指向。
他との関係から導かれる個性こそが、それの性質そのもの。
単体では個性は確立し得ない。
マルチメソッドの無いOOPは全部甘い罠だ。つれてかれるぞ。

418 ：デフォルトの名無しさん：2010/09/25(土) 19:01:18

ﾉﾝﾉﾝ

419 ：デフォルトの名無しさん：2010/09/25(土) 19:12:28

いつもの人はメッセージング指向になったら、コーディングがどう変わるのかまで踏み込んで話してくれよ
いっつも雰囲気でぼんやりした話しかしないからかなり信用できない

420 ：デフォルトの名無しさん：2010/09/25(土) 19:15:39

マルチパラダイムなんだから動けばいいんじゃねーですかね

421 ：デフォルトの名無しさん：2010/09/25(土) 21:31:41

だからC++は一部機能を任意に制限できる仕様にしろって
多重継承とかほとんどいらないし

422 ：デフォルトの名無しさん：2010/09/25(土) 21:43:23

ライブラリの中で多重継承が使われてたらどうすんだよ

423 ：デフォルトの名無しさん：2010/09/25(土) 22:20:36

ラップすればよくね？

424 ：デフォルトの名無しさん：2010/09/25(土) 23:23:39

class ITree{
public : void Parent(ITree* pITree_ ) = 0;
public : void Add(ITree* pITree_ ) = 0;
public : void Remove( ITree* pITree_ ) = 0;
};

class Tree : public ITree {
public : void Parent(ITree* pITree_ ){...}
public : void Add(ITree* pITree_ ){...}
public : void Remove( ITree* pITree_ ){...}
};

class XXTree : public ITree {
private : Tree tree;
public : void Parent(ITree* pITree_ ){ tree.Parent( pITree_ ); }
public : void Add(ITree* pITree_ ){ tree.Add( pITree_ ); }
public : void Remove( ITree* pITree_ ){ tree.Remove( pITree_ ); }

private : XX xx;
public : xx GetXX(){...}
public : void SetXX( XX xx_ ){ xx = xx_; }
}

425 ：デフォルトの名無しさん：2010/09/25(土) 23:24:32

>>416
クラスとメソッドって形ではないけど
データ型によって実際の処理が変わるのだから、データと処理はセットになってると言えないか？

426 ：デフォルトの名無しさん：2010/09/25(土) 23:24:32

●データ構造はツリー型(コンポジット)
●ツリーの操作はITreeで定義
●Treeにて上記インターフェースを実装
●深い継承はしたくない

XXTreeという具体的なデータを持つノードを作成したい。

この場合上記のようにXXTreeを作成すればよいか、
またはTreeを継承して作成したほうが良いのか。

冒頭のXXTreeのつくりの場合、ITreeはTreeとXXTreeで、
別々ではあるが2回継承されている。

包含されるTreeはインターフェースを継承すべきか。

使用目的が明示的になるの継承したほうが良いのか。
パフォーマンスのために継承はしないほうが良いのか。

具体的なデータを持つノードはXX以外にも多数あり、
またそれらはXMLのように互いを子要素として持つこともありえる。

皆様のご意見をいただきたく思います。

427 ：デフォルトの名無しさん：2010/09/25(土) 23:27:14

このスレ、OOPのスレなのに、なんで保守の話はしないんだろう？

428 ：デフォルトの名無しさん：2010/09/25(土) 23:34:39

話題を振ればいい

429 ：デフォルトの名無しさん：2010/09/25(土) 23:47:00

>>426
ツリー構造を管理するデータと、それ以外のデータが、同じ場所にあるのは、
のちの混乱の元にならないだろうか？
ちゃんと分けた方がいいかと。

430 ：424：2010/09/26(日) 00:06:18

>>429
レスありがとうございます。
いまいちそこまで考えが至りません。

もしよろしければもう少し具体的にお願いできますでしょうか・・・。

431 ：429：2010/09/26(日) 00:21:59

俺が同じアプリを作るなら、
1.ユーザーに提供するデータだけを保持するクラス。
2.1のクラスのインスタンスを集めて、ツリー構造にするクラス。
に、分けるかな。

1はシンプルにして、多様性をだしやすく、
2には色々めんどい事を任せる。

こうしておけば、1は簡単に拡張が出来るし、
後でハッシュ構造に変えたくなった時は、2を取り替えるだけで済む。

432 ：デフォルトの名無しさん：2010/09/26(日) 00:36:35

上の人とは別人だけど。
Tree単体で使うこともあるの？
そうでないならITreeの役割をTreeに移してしまえばいいと思う

また、XXTreeがTreeの子でない、というのは直感的でない
名前だけみたら、TreeがXXTreeの派生クラスだと勘違いする

ITreeはインタフェースなんだから、XXTreeはTree/ITreeを両方継承しても問題無いけど
上の例だと、そもそもTree/XXTree独自のメソッドがないから
クラス階層をわける意義が感じられない

それからvirtualは付けなくて良いんだっけ
最初Javaか何かかと思ったけどC++だよね？

433 ：デフォルトの名無しさん：2010/09/26(日) 00:44:41

下手な設計するよりはS式で持っといた方がいい
とりあえずLISPで検証できる

434 ：デフォルトの名無しさん：2010/09/26(日) 00:54:48

要素がVariantであるN木で持つのと同じじゃん

435 ：デフォルトの名無しさん：2010/09/26(日) 01:02:50

データ構造なんて配列とおなじじゃん？

436 ：デフォルトの名無しさん：2010/09/26(日) 01:03:04

考えるべき順番が全く違うんだよ
データ構造を定義する前にまず何をすんの？から始めないと
それが決まらんうちはXMLでもS式でもVariantでもDBでも使っとけばいいよ

437 ：デフォルトの名無しさん：2010/09/26(日) 01:06:22

そんなこといってたら、まず、プログラミングする必要があるのか？とかに発展してく。
最初から設定された問題の中で話をすればいいのに。

438 ：デフォルトの名無しさん：2010/09/26(日) 01:15:55

>>436
>>426はもうやりたい事は決まってるでしょ。
ツリー構造を使う必要があったり、データの多様性を出そうとしたりしてるし。

439 ：デフォルトの名無しさん：2010/09/26(日) 01:35:31

だからそれ作って何すんの
構造を眺めるだけですか

440 ：デフォルトの名無しさん：2010/09/26(日) 01:40:08

そうです

441 ：デフォルトの名無しさん：2010/09/26(日) 02:27:27

見る化

442 ：デフォルトの名無しさん：2010/09/26(日) 09:03:05

>>412
なるほど、カプセル化を「物事の整理の仕方」と考えているのか。
何件か質問させてもらう。
>誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
「誰がどのメモリ領域いじってるのか」と「誰がどのメソッド（Setter）いじってるのか」での違いは？
構造化でもサブルーチン・ローカル変数など制限できるがオブジェクト指向と何が違う？

>「オブジェクト志向」がいったい何を志向しているのかといったら
>それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。
「オブジェクト志向」=「物事の整理の仕方」=「プセル化」と考えているようだが
それは概念か、それとも方法諭か　実装もかみしているのか？

>>414
>データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
>情報の隠蔽もなされるワケで。
その「特定の処理を通させる」は何の目的の為に行なうのか？、具体的に書いてくれ。
俺の考えでは「フィールドの情報隠蔽の為に、”特定の処理を通させ”るカプセル化を適用している」のよう考える。
「データと処理を一括りにすること」は手段だと考えるが、目的と考えているのか？そのメリットは？
まっ、メリットを書いてもらうとそれが目的だとなるが。

443 ：デフォルトの名無しさん：2010/09/26(日) 09:42:25

>>442
このメソッドを呼ぶときは事前にあっちのメソッドが呼ばれてないといけないとか
誰それがこういう状態を構築してなきゃ、このメソッドは成功しないとか
引数にはこれを生成して渡さなきゃいけないとか
この変数はこいつもいじってるから勝手に触っちゃダメとか

そういう膨大な依存関係が出来上がるだろう
これは開発規模が大きくなれば指数関数的に複雑になっていく。
ドキュメントちゃんと書けば済むじゃんと言われればそうだが
こういう依存関係に依存したバグが一旦出てしまったら捜索は厄介になりがちだ。

もちろん天才なら構造化だけの整理手法でもかなり対応できるとおもう。
でも、コードをオブジェクト単位でまとめると、さらに関係が整理しやすくなる、と。

444 ：デフォルトの名無しさん：2010/09/26(日) 10:45:05

おまえらカプセル化って言葉じゃ
ぼやけたイメージしか出てこないみたいだから
MVCのMの範囲とかで考えた方がいいよ
何のためにそんなことするのか

445 ：デフォルトの名無しさん：2010/09/26(日) 13:00:12

>>444
そんな事したらもっとぼやけるっていう。
てかカプセル化って、モジュール化をもっと使いやすくしたものなんだけどな。

446 ：デフォルトの名無しさん：2010/09/26(日) 13:01:59

単に、>>442も視点が違うだけでそんなに外したことを言ってない気もするが、
俺はどちらかというと、「依存関係の整理を支援するために、OOP言語の機能がある」
という>>443の説明の方が説得的だな。>>436とは違う意味だが、何をするのかが
決まらなければ、最適な言語機能を論ずることもできない。

もちろん、これは歴史的にどうだったかとか、アラン・ケイの意見がどうかというのとは
別の話な。

447 ：デフォルトの名無しさん：2010/09/26(日) 13:13:56

まともに色々と文献にあたった人でも「やっぱ正確な定義なんてどうでもいいや」ってなる厄介なtermらしいな>カプセル化
だからこそこのネタで盛り上ることができるわけだが

448 ：デフォルトの名無しさん：2010/09/26(日) 13:27:57

そりゃ、「何に対して」情報を隠蔽するのかが明らかでなければ定義なんてできないわな。

449 ：デフォルトの名無しさん：2010/09/26(日) 13:29:15

>>447
正確な定義はなくても、目的はモジュール化なのは確実だから、まだマシだよね。

450 ：デフォルトの名無しさん：2010/09/26(日) 13:29:48

wikiとかでわかる範囲で調べた
データにメソッドをくっつけたもの派？(Booch,Thomas M. Connolly, Wm. Paul Rogers)
Encapsulation is not information hiding
ttp://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html?page=9

アクセス権派？(John C. Mitchell,Pierce, Benjamin)

メリット
どっかいじっても他の場所に影響がないか小さい領域にとどまる
よくわからない依存関係を、インタフェースなどに明示し、実装から分離

他にもAbstract Data TypeやModuleにも同様の考え方がある。
どのタイプも、数学的には存在型というコンセプトがベース

451 ：デフォルトの名無しさん：2010/09/26(日) 13:31:39

そもそもカプセル化って原典は何なんだ

452 ：デフォルトの名無しさん：2010/09/26(日) 13:35:32

450だけど、wikipediaにはBoochの定義が一番よく使われてるようなことが書いてたよ
でもこれはコンピュータサイエンスでの定義でOOPには限らないもののよう
the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior;
encapsulation serves to separate the contractual interface of an abstraction and its implementation.

453 ：デフォルトの名無しさん：2010/09/26(日) 13:39:01

補足だけど、ブーチはUMLの人で、ヤコブソン、ランボーとともに3アミーゴとしてOOの世界では有名な人ね

454 ：デフォルトの名無しさん：2010/09/26(日) 13:52:01

確かに、欧米では既に常識となってる考え方が、日本だと全然普及してないってことはままあるからなぁ。

455 ：デフォルトの名無しさん：2010/09/26(日) 14:09:04

俺的には、カプセル化は内部データの外部への直接アクセスを禁止して
代わりにメソッドを用意し、内部的不整合な設定を起こさないようにするという理解。

例えば
・0～2までが設定可能なときにそれ以外の値が渡されたときに回避または例外発生
・２つの内部状態が連動して変化する関係の場合にメソッドが整合性を保って処理する
みたいに

特に２番目がないと使う側が考えることが増える。
アクセス制限もコードを読む上で無視できる目印になる。

456 ：デフォルトの名無しさん：2010/09/26(日) 14:12:03

カプセル化って、オブジェクトの内部状態が有効でない瞬間を他者に見せないしくみの事じゃねーの

457 ：デフォルトの名無しさん：2010/09/26(日) 14:13:17

オブジェクトに内部状態が有効でない瞬間があるの？
何のためのコンストラクタ？

458 ：デフォルトの名無しさん：2010/09/26(日) 14:15:25

メソッドの実行中

459 ：デフォルトの名無しさん：2010/09/26(日) 14:17:29

それただに分かりにくい言い換えな気がｗ

460 ：デフォルトの名無しさん：2010/09/26(日) 14:20:52

カプセル化されてなかったら、
「このメソッド実行してから、あのメソッドを開始するまでの瞬間、オブジェクトの動作が未定義になる」
ことがあるとおもうんだよね。

でも、カプセル化されてたら、おそらくprivateであろう「この」メソッドと「あの」メソッドの隙間は外からは全く見えなくなる

461 ：デフォルトの名無しさん：2010/09/26(日) 14:23:23

つまり
「内部的不整合な設定を起こさない」＝「内部状態が有効でない瞬間を他者に見せない」
じゃねーの？

462 ：デフォルトの名無しさん：2010/09/26(日) 14:29:27

それがつまり、「インタフェースによって、オブジェクトの機能を明示的に宣言する」ってことなんじゃないのかな。

463 ：デフォルトの名無しさん：2010/09/26(日) 14:44:38

>>460
そういう目的ならロジックとデータが一緒である必要は無いよね
例えば名前空間にアクセス権限付けてprivateな関数と変数を作れば事足りるよね

464 ：デフォルトの名無しさん：2010/09/26(日) 14:45:57

>>463
それクラスとどう違うの

465 ：デフォルトの名無しさん：2010/09/26(日) 14:46:55

>>464
インスタンスに出来ない所

466 ：デフォルトの名無しさん：2010/09/26(日) 14:47:56

>>463
それもカプセル化なんじゃないか？
違いはstaticか否かっぽいし。名前空間でロジックとデータが一緒なんじゃないの？

467 ：デフォルトの名無しさん：2010/09/26(日) 14:53:07

必ずしもクラスだからってロジックとデータが一緒が推奨されてるわけでもない
非メンバ化が可能なメソッドはできるだけそうする、ってのは割と一般的だと思うよ

468 ：デフォルトの名無しさん：2010/09/26(日) 14:53:58

それはまた別な話じゃないか？

469 ：デフォルトの名無しさん：2010/09/26(日) 14:57:10

ロジックとデータが一緒なのは、データ独立ではその有効性を維持するのに十分でないからだ

470 ：デフォルトの名無しさん：2010/09/26(日) 14:57:55

ロジックつまりは論理だな
操作的意味論を元にメソッドを考えると事前条件から事後条件への推論だ
データはその過程で用いられる仮定として捉えればデータもロジックになるなならないな

471 ：デフォルトの名無しさん：2010/09/26(日) 14:59:13

次はロジックとデータの定義だな頑張って

472 ：デフォルトの名無しさん：2010/09/26(日) 15:06:01

ロジックとデータが一緒じゃなきゃ、不正な操作を許してしまう事になると思うのだが

473 ：デフォルトの名無しさん：2010/09/26(日) 15:10:17

ロジックという言葉がアレっぽいからメソッドに言い換える

>>466
でもそれをオブジェクト指向と呼べるのだろうか
データとメソッドが一体になったもの(=オブジェクト)を変数に束縛出来なくてもオブジェクト指向言語と言えるのだろうか

俺が言いたい事は隠蔽はオブジェクトという考え方を導入しなくても出来るから
オブジェクト指向自体のメリットでは無いのでは無いか、と言う事な

474 ：デフォルトの名無しさん：2010/09/26(日) 15:13:16

>>473
いやカプセル化の議論だったからそういっただけ。
それにインスタンスがひとつしかなくてもオブジェクト指向と呼べないとはいえないと思う。
便利がどうかは別として。

475 ：デフォルトの名無しさん：2010/09/26(日) 15:15:30

メソッドとフィールドが一緒だからインスタンスが必要になるんだ。

476 ：デフォルトの名無しさん：2010/09/26(日) 15:16:16

データを状態と言い換えても同じ議論ができるか否か

477 ：デフォルトの名無しさん：2010/09/26(日) 15:17:45

面倒くさいとこいちいち丸投げすんなようざいから。

478 ：デフォルトの名無しさん：2010/09/26(日) 16:44:39

状態が複数あるっつうことはそれぞれの状態において違う仮定があるというわけだから
単純にその仮定をorで結合、つまり場合分けすりゃいいだけ
議論としてはまったく同じになる
ただそのデータの存在のみから導き出せる仮定が弱くなるから
そのデータのもつ責任をデータを扱う奴ら(*)が肩代わりしなくちゃならないので(*)が扱う事前事後条件が複雑になる

479 ：デフォルトの名無しさん：2010/09/26(日) 17:23:23

>>443
>このメソッドを呼ぶときは事前にあっちのメソッドが呼ばれてないといけないとか
>誰それがこういう状態を構築してなきゃ、このメソッドは成功しないとか
>引数にはこれを生成して渡さなきゃいけないとか
>この変数はこいつもいじってるから勝手に触っちゃダメとか
それだと、俺がいっている情報隠蔽に近いと思う。

>そういう膨大な依存関係が出来上がるだろう
>これは開発規模が大きくなれば指数関数的に複雑になっていく。
データの親子関係・依存関係を継承・コンポジションなどで整理するがこれはカプセル化とは別。
だから、「物事の整理の仕方」の一部は「カプセル化」がだが、「物事の整理の仕方」＝「カプセル化」ではない。

>>449
「モジュール化=カプセル化」は同意。ただ、じゃモジュール化って？　と聞かれたらまた意見が分かれると思う。

>>455
同意。

>>456
同意、RDBのトランザクションイメージだと思う。

>>463
>そういう目的ならロジックとデータが一緒である必要は無いよね
例えば、RDBとクライアントの関係のように？
目的は同じでも色々やり方があると思う。その一種がカプセル化なだけ。

480 ：デフォルトの名無しさん：2010/09/26(日) 18:06:59

>>479
443と449へのレスで「＝」がダブルスタンダードになってないか？

481 ：デフォルトの名無しさん：2010/09/26(日) 18:21:53

>>479
コンポジションはカプセル化の本領発揮ってとこでしょ。
継承は多態目的だからまた別。

そして確かに継承も整理の仕方の一つではあるが、
「依存関係を弱める」カプセル化とは真逆の、「依存関係を非常に強める」手法。
うまく使わないと整理どころか逆に厄介なバグを産みかねない恐ろしいもの。

入門書では継承を単なる便利な物としてしか教えないから
やたらめったら継承して「OOPってなんかおかしくね？」という結論になりがち。

482 ：デフォルトの名無しさん：2010/09/26(日) 18:32:41

C++で一番イヤなのは、クラス定義にプライベートなメンバ変数も書くとこ。
インタフェースの定義じゃなくて、クラスの定義なんだから、とか、
クラスのサイズを決定するために必要なんだとか、もうそういうのいいから。

もしあれが、インタフェースの定義だけをヘッダに書いて、
メンバ変数の定義を、cpp側に書く書式があれば、さぞよかったのに。

483 ：デフォルトの名無しさん：2010/09/26(日) 18:35:13

pimplパターンってのがあるよ。コンパイル時間も減るよ。

484 ：デフォルトの名無しさん：2010/09/26(日) 18:36:28

pimpl

485 ：デフォルトの名無しさん：2010/09/26(日) 18:44:47

>>483-484
( ；∀；)ｲｲﾊﾅｼﾀﾞﾅｰ
これはスカッとする。
ぼんやりと、ポインタ一つだけ持ってやりくりすれば…とは思ってたけど、
実際にやってた奴がいるのか…そりゃいるわな…。

486 ：デフォルトの名無しさん：2010/09/27(月) 01:12:21

pimplpomplpumpop

487 ：デフォルトの名無しさん：2010/09/27(月) 11:42:28

なんか、パンプル・ピンプル～って魔法少女ものなかったか？

488 ：デフォルトの名無しさん：2010/09/27(月) 19:28:37

クリィミーマミ

489 ：デフォルトの名無しさん：2010/09/27(月) 19:30:09

C++の奴はどっか別のところでやってくれないか？
お前らがいるとレベルが下がる。
他の言語では普通に出来ることをグダグダと。

490 ：デフォルトの名無しさん：2010/09/27(月) 19:36:07

>>489一人でレベル下げてんじゃねえよｗ

491 ：デフォルトの名無しさん：2010/09/27(月) 19:41:59

私もcppの人の話は、ちょっと．．．と思うことが多い。「pimplパターン」とか。

492 ：デフォルトの名無しさん：2010/09/27(月) 19:44:22

>>490
たまには面白いけど、やっぱりｃｐｐは×でしょう

493 ：デフォルトの名無しさん：2010/09/27(月) 19:54:19

おいおいC++厨が居なくなったら住人は１０分の１になるぞ。

レベルは１０倍高くなるがｗ

494 ：デフォルトの名無しさん：2010/09/27(月) 20:11:40

おいおい一人でレベル１０もさげてんじゃねえよｗ

495 ：デフォルトの名無しさん：2010/09/27(月) 22:28:43

C++の話が嫌なら、それ以外の話題振ればいいのに。
まあ、大した話は出ない気がするけど。

496 ：デフォルトの名無しさん：2010/09/27(月) 22:40:50

C++ちゃんと触ってない奴はオブ脳とかになりやすい

497 ：デフォルトの名無しさん：2010/09/27(月) 22:50:57

>>496がどういうのをオブ脳と言っているのかよく分からんけど、
C++はオブジェクト指向言語だよな？

498 ：デフォルトの名無しさん：2010/09/27(月) 23:10:35

C++は手続き型言語
ただオブジェクト志向（っぽいもの）が導入されただけ

499 ：デフォルトの名無しさん：2010/09/27(月) 23:15:35

>>498
世界的に、手続き+オブジェクト指向+ジェネリック、
のマルチパラダイム言語だといわれているのに、その主張は無理があるだろ...

500 ：デフォルトの名無しさん：2010/09/27(月) 23:17:37

オブ脳なんて言葉あったなｗ

501 ：デフォルトの名無しさん：2010/09/27(月) 23:49:05

ローレベルでoopやるならC++一択

502 ：デフォルトの名無しさん：2010/09/28(火) 05:08:19

>>491
pimpl ｗｗｗ

pimplは究極的にはコンパイル速度を早めるためだろ、あれはw

C++がダメっていったら、デザパタが一時期流行ったJavaもやばいだろ
LLだったら本にするまでもない分量ですむことをだらだらと本にして出す言語はどうなのかと

503 ：デフォルトの名無しさん：2010/09/28(火) 06:34:08

デザパタはJavaというより、静的OOPLだから本になるという感じ

504 ：デフォルトの名無しさん：2010/09/28(火) 07:54:27

LLのBASICばかにすんあ

505 ：デフォルトの名無しさん：2010/09/28(火) 11:18:14

BASICは行番号を廃止して、構造体を導入してあげればずいぶん組みやすくなすのにね。

506 ：デフォルトの名無しさん：2010/09/28(火) 11:32:52

構造化しないからこそのBASICでしょうよｗ

構造化しないとどんなことになるかを学ぶ。

507 ：506：2010/09/28(火) 11:34:06

あ、なんか駄洒落を言ったような、
構造体と構造化を混同したようなレスになっちゃったけど、
行番号にgotoするのがBASICのジャスティ巣。

508 ：デフォルトの名無しさん：2010/09/28(火) 13:30:44

昔はまともに使えるスクリーンエディタが無かったから行番号なんだろうな

509 ：デフォルトの名無しさん：2010/09/28(火) 13:42:47

おれはてっきりアセンブラのラベルを模倣したくて行番号いれたのかとおもったよ。
原始のＢＡＳＩＣって関数もなかったでしょ。

510 ：デフォルトの名無しさん：2010/09/28(火) 13:45:03

行番号はテレタイプで編集するのに便利だからだと思う。

FORTRANとかアセンブラの言語仕様はパンチカード寄りなんじゃないかと。

511 ：デフォルトの名無しさん：2010/09/28(火) 13:45:27

もちろん関数などない。
GOTOだけがトモダチさ。

512 ：デフォルトの名無しさん：2010/09/28(火) 14:05:10

>>505
VisualBasic、、、

513 ：デフォルトの名無しさん：2010/09/28(火) 14:11:21

いやいや、C言語にコンバート可能なXBASICを忘れては(ry

514 ：デフォルトの名無しさん：2010/09/28(火) 15:21:06

BASIC→Cトランスレーターは作りやすそうだが、
VB→CだとCOM操作とかで複雑度具合がまた違ってくるな

515 ：デフォルトの名無しさん：2010/09/28(火) 15:22:59

BAStoCの出番だな

516 ：デフォルトの名無しさん：2010/09/28(火) 20:23:41

N88BASICにはGOSUBコマンドがあった記憶が。
もちろん引数なんてものはないが。

517 ：デフォルトの名無しさん：2010/09/28(火) 21:35:09

ごく初期のTinyBASICとかでない限りGOSUBはあると思う。
RETURNが使えるGOTO以上のものではないし。

DEFFNはもうちょっと関数ぽいよね。

518 ：デフォルトの名無しさん：2010/09/28(火) 22:32:43

そういえばGosub引数って無かったなぁ。引数って大きな発明だなw

519 ：デフォルトの名無しさん：2010/09/28(火) 23:14:02

>>518
FORTRAN の SUBROUTINE には引数あるのにな…

520 ：デフォルトの名無しさん：2010/09/29(水) 00:19:45

でもコンピュータって計算するものだから、処理中心に設計しないとおかしいよね。
それが全てだよね。
オブジェクトを設計？何それ。
足りない頭で無理にややこしく考えても何の意味も無いと言う。まさに下手の考え休むに似たりだな。
それでも自分には多少の知性があるのだろうと勘違いしてしまう困ったチャンが多くて困るな。
周りを良く見て、そのまま素直に認知して、しかるべき仕事をする。
それ以上は求められてないのにね。
コンピュータって何？まずそっからやり直したほうがいいね。
小手先積み上げてもクソの山にしかならんのよ。

521 ：デフォルトの名無しさん：2010/09/29(水) 00:32:06

僕らの扱うコンピュータは、まぁCPUとか有って、計算が出来る訳だ。
そんで、それで何か計算して意味あることをしたい。これは基本理念だよね。
だから計算のバッチ処理の手続きをプログラミングする訳だ。プログラミングの本質だよね。
だけど、僕らの扱うコンピュータはとても賢くてメモリ領域なんか持っちゃったりしてて、
一時変数をそこに置いておけたりする。
だから、処理手順を記述することの他に、メモリ領域をどう分割するかって話も出てくる。
でも、処理手順を記述することと、メモリ領域をどう分割するかってのは本質的に別次元の話だから、
一緒くたにクラスやオブジェで全部やっちゃえってしたときに、どっかに無理が出てくる罠。
だってさ、自分が何か作業をするとき、
工具や材料を何処においておくかという話と、
どういう手順で作業をするかという話は、
別もんだろ。

522 ：デフォルトの名無しさん：2010/09/29(水) 01:00:52

Unixでは、$program < in > out こんなこと良くやったりするが、
プログラムは入力と出力の関係を定義している、と言えるだろ？
入力と出力の関係をprogramで定義している、と。わりとマトモな考え方だわな。
だけどここでOOPっぽくして、inputにget_outputってメソッドつける発想はマトモに思えない罠。
標準入力にメソッドがくっついてる訳もないのに、なんか変だ罠。
多機能ビューアが有って、
$viewer < image としたときに、imageの種類でviewerの展開アルゴリズムがスイッチしてってのは分かるんだけど、
だからって、imageファイルそのものに展開アルゴリズムを内包させちゃえってことにはならないよな。
だからMacバイナリはアホで、Macもアホなんだよ。
Unixの#!もアホなんだけどね。

523 ：デフォルトの名無しさん：2010/09/29(水) 01:08:13

>>521-522
PowerShellディスってんのかお前は

524 ：デフォルトの名無しさん：2010/09/29(水) 01:12:36

でもimageファイルには大体ヘッダがついてて、「自分は～の種類です」ってそこまでは表明してるんだよね。
これはいわばクラスを表明している訳だ。
しかし、種類は表明するけど、展開アルゴリズム自体は持っておらず、
それがどう扱われるかはプログラムにゆだねられている訳だ。
その辺が落としどころって事。

OOPの言葉で言えば、型やクラスは表明するけど、メソッドは持ってないってこったな。
そこがちょうどいい落しどころなんだ。
だから、型でスイッチすりゃいいし、それが嫌ならマルチメソッドを導入するこったな。

525 ：デフォルトの名無しさん：2010/09/29(水) 01:13:43

>>523
あれはもうどうしようもないよね。誰得言語。

526 ：デフォルトの名無しさん：2010/09/29(水) 01:24:55

それでもカプセル化はしたいって人は多いだろうから、
カプセル化はカプセル化で別の構文を用意することになるだろうね。

OOPのカプセル化と違って、もっとざっくりした物がいいね。
例えば、privateなフィールドには、自ネームスペース内からだけアクセス可能とか。
十分だと思うが。
もとより、それで整合性壊すようなら、プログラマ失格だろう。

527 ：デフォルトの名無しさん：2010/09/29(水) 01:34:24

Javaはよくできてると思う。GC必須でさえなければ・・・

528 ：デフォルトの名無しさん：2010/09/29(水) 03:07:49

コンピューターは処理中心と言う人が居るがそれは違うぞ。
その人はおそらく、「演算」「記憶」「入出力」を、ひっくるめて処理と言っていると思うが、
これらは全て「データ」が無ければ無意味なものだ。
演算はデータに対して行うものだし、
記憶はデータを扱うものだし、
入出力はデータをやり取りするものだ。
つまりコンピューターはデータ中心の物なんだ。

529 ：デフォルトの名無しさん：2010/09/29(水) 03:21:30

チューリングマシン知らないんだろう

530 ：デフォルトの名無しさん：2010/09/29(水) 03:23:49

んで、オブジェクト指向というものは、
データを中心にプログラムを考えていくもの。
なんでオブジェクト指向を使うということは、下手でも何でもなく、
コンピューターの仕組みにあったやり方をする訳で、
むしろ基本をちゃんと押さえた良い方法なんだ。
(正しく使えていればたが...)

531 ：528：2010/09/29(水) 03:27:50

>>529
ん？俺に言ってる？　まさかな...

532 ：デフォルトの名無しさん：2010/09/29(水) 03:53:38

それはもう言ってる事がてんででたらめだよ。
まるで、
数学は、計算は数に対して行うから、数が中心
と言ってるようなものだ。
でも、虚数はどうなる？虚数は意味をもってるけど、どうしてあんなありえもしない数が意味を持ちえる？
それは虚数に、i^2=-1という関係が定義してあって、それで破綻なく機能してるから意味をもてるんだ。
・機能してるから意味を持てる→functionは意味を与える
・機能は関係の定義で成り立つ
これが大事。

例えば、整数値のビット列はデータだけど、でも、演算が出来ないなら何の意味もないし、
数値と言っていいのかすら分からん、ただのビット列にすぎない。
CPUの中でビット列を整数値と見立てた場合の演算が定義されて、それが体を満たして、
他のビット列との相対的な位置関係が定義されて、初めて僕らの知ってる整数値の意味になる。

処理があって、コンピューティングがあって、初めてデータは他のデータと関係が持てて、
それで機能して、何か意味らしきものをもてるんだよ。

もう哲学の世界に行っちゃうけど、
社会や会社や他者との関係があって、初めて人間は意味を持てるっての。
この関係中心の考え方は、今の本流だよ。アメリカなんて機能主義そのものだろ。
機能が自分たちに個性を与える。機能は他者との関係で相対的に生まれるから、
関係を改善していくことで、自分の個性を変えて行くことが出来るっていう。
生まれながらの個性は、重視されない(ことになっている)っていう。

コンピュータで関係を扱ってるものと言ったら、function、処理、手続き、計算、演算、だよ。
ましてデータ中心なんて時代遅れもいいとこ。
物中心の考え方だと上手くいかなくなってきているのは、肌身で感じてるはずだが。

533 ：デフォルトの名無しさん：2010/09/29(水) 04:00:33

もう、
>>528=530
は完全にOOP脳だよ。
データ中心に考えるとか、思考停止もいいとこ。
データに意味なんて無いんだよ。それ意味を与えるのは機能であり、他データとの関係だ。
他データとの相対的関係で意味を持つんだ。データ自身に絶対的な意味があったりはしない。
自分でコンピュータ、計算機と言っておいて、それがデータ中心の物とか・・・正気かよ。
コンピュートの意味分かってるのかよ。コンピュートするためには相手が要るんだぞ。
1+1は、「+」が間に割って入ってるだろ、だから、「+」が中心なんだ。

534 ：デフォルトの名無しさん：2010/09/29(水) 04:19:48

そして、こういった考え方はUnixの根底に流れているものだよ。
データはデータでしかなく、それをどう扱うかまでは決めないっていう。
だからパイプで流したり、データをエディタで編集したり、と、わりと柔軟に対応できる。
そのやり方が優れていたからUnixは成功したんだよ。
ただの画像データに展開用のコードまで内包されてたら嫌だろJK。
どう扱うかはこっちで決めさせろ。んでそれ決めてデータに新たな意味を与え、機能させる。
発展性、創造性。

535 ：デフォルトの名無しさん：2010/09/29(水) 04:35:20

そういやデータ型定義で型制約与えずに、その定義されたデータ型を扱う関数で型制約与えるべき
っていうイディオムがあるな

536 ：デフォルトの名無しさん：2010/09/29(水) 04:44:06

まー、画像というデータをただ開くだけでも、アプリケーションによって多態するわな

537 ：デフォルトの名無しさん：2010/09/29(水) 05:27:05

>>522
自己解凍アーカイブを全否定しておられる？

538 ：デフォルトの名無しさん：2010/09/29(水) 05:38:12

なんかデータ自体には意味が無いとか言ってるけど・・・。

そもそも機能はデータを操作するものだよね？（違うって言われたらお手上げ）
んで、新しいデータを作る。

ここでもし、その作ったデータに意味が無かったら、そんなデータいらないよね？
そんなことになったら、なんでそんなことしたんだよってなる。

じゃあなんでそんなことをするのか？

それはそのデータは意味があるものだからだ。
意味があるからこそ、そのデータを作るしそういう機能も必要になる。
データありきなんだ。
データが意味を持っているからこそ、機能には存在意義がある。

もし>>533が言うようにデータに意味が無かったら、機能なんていらない。
何故ならそれに目的は無いからだ。（あるって言われたらお手上げ）

539 ：デフォルトの名無しさん：2010/09/29(水) 06:09:23

機能によってデータが作られるという考え方もある(例:ADT)
外延と内包とでも言おうか

540 ：デフォルトの名無しさん：2010/09/29(水) 06:15:04

>>539
それ>>538の前提ですよ？

541 ：530：2010/09/29(水) 06:21:50

それにしても、いろいろ考えているうちに考えが変わっちゃったなあ。
で、新しい考えがこれ。

オブジェクト指向とは。
データと機能が合わさって生み出す目的を中心に考えること。

よく考えたらデータだけじゃ意味をなさない。
そのデータの使い道が無いといけない。その使い道を生み出すのは関係と言う名の機能だろう。

だからと言って機能だけでも意味をなさない。
機能だけでは対象が存在しない。そんなものを誰が必要とするのか？

ようするに両方とも必要なんだと。
どっちかが掛けても意味をなさないんだ。
だったらそれをまとめて管理しちゃえばいいじゃない。

542 ：デフォルトの名無しさん：2010/09/29(水) 06:23:51

データのもつ意味とか何か、データとは何か、機能とは何か、存在とは何か
OOPから学ぶ哲学のこころという本でも出す気かお前らは

543 ：530：2010/09/29(水) 06:32:43

>>542
サーセンｗｗｗ

でも、この議論をしたことで、オブジェクト指向を上手く説明できるかもしれない。

544 ：嘘だけど：2010/09/29(水) 06:35:23

データと機能両方を区別なく考える手法としてはデザインパターンで学ぶオブジェクト指向のこころで提唱されている「責任」という概念かな
機能の分割じゃなくて責任の分割
データや機能が何を保証して何を保証しないのか、
それらの保証する所をうまく組み合わせたり、新しく作っていったりして
最終的に仕様が満たされることが保証できるものができればそこでプログラムは完成することになる
仕様という論理をどう導いていくのか、これは証明を補題や場合分けを使って構造化するのと似ている
これを公理的意味論で解釈したのがかの有名なdesign by contract
この考え方だと論理がベースにあるんで、扱う言語が関数型であろうが論理型であろうが一般のOOPLであろうが関係ない

545 ：530：2010/09/29(水) 07:12:32

オブジェクト指向をカーレースで説明してみる。

まず、カーレースには何が必要だろうか。
とりあえず車は必要だろう。
車を走らせるサーキットも必要になるだろう。
観客も居た方がいいかもしれない。

レースなんだから相応のルールが必要だろう。
それを守らせる審判も必要だ。
結果の記録する係も居ると便利だろう。

以上の物を用意すればとりあえずレースは出来る。
実際これで１レース行われる。
そしてレースが終わった後解散した。

（続く）

546 ：530：2010/09/29(水) 07:13:32

後日、またレースをしたくなった。
前回と同じものをまた用意する。
主催者は、レーサー達が前回の経験があるので、よりいいレースが出来るだろうと期待した。
そして準備をする。
しかし、準備をするスタッフが変わっていた。
そのスタッフは前回のレースのことを知らない。

そして、出来あがったものは形は似ていても、細かいところは違っていた。
サーキットの形は違うし、観客席の位置は違うし、審判だって変わっている。
実際これでレーサーたちや観客は混乱した。
目的は前回と同じはずなのに、上手くいかないのだ。

結局１回目のレースとあまり変わらない物になってしまった。
いや、むしろ前回より悪化しているかもしれない。

主催者は考えた。
どうすれば、細かいところも同じにできるだろうか。
結論は設計図を作ることだった。
設計図があればたとえスタッフが違っていても、まったく同じものが作れるだろうと。

（続く）

547 ：530：2010/09/29(水) 07:14:51

そして、またレースを開催した。
またスタッフが変わっている。
しかし、今回は細かいところも変わっていない。
実際大した混乱も無く、レースは大成功を収めたのだった。
設計図を用意した効果が出たのだ。

これはプログラムの世界でも同じことができる。
クラスを使えばいいのだ。
クラスという設計図があれば、人が変わっても現場が混乱することは無い。
まったく同じものを作る限りは・・・

・・・ってこれ長いよ！　書くの飽きたし。（続きの構想はある）

548 ：530：2010/09/29(水) 07:20:44

しかもなんか変な感じになってるという・・・
俺が書きたかったのはこんなんじゃねえ！

549 ：デフォルトの名無しさん：2010/09/29(水) 08:13:36

>>544
役割を果たす責務と、機能を表明するものとしてのインタフェースだな。

550 ：デフォルトの名無しさん：2010/09/29(水) 08:27:49

GCない言語を作るのは簡単。
動的になにも確保できないだけ。

551 ：デフォルトの名無しさん：2010/09/29(水) 09:14:41

確率的メモリ

552 ：デフォルトの名無しさん：2010/09/29(水) 09:48:05

OOPの肝は権限の委譲だってばっちゃが言ってた

553 ：デフォルトの名無しさん：2010/09/29(水) 21:36:07

>>533
お前の考えならコンピュータは要らない、電卓があれば十分だ。

554 ：デフォルトの名無しさん：2010/09/29(水) 22:56:45

またなんか長文書いている人とか居るけど、まったく意味わからんし、どうよこれ。
説明能力の無い奴が設計できるかっつーはなし。

データだけでは意味が無いってのは分かってもらえたようでよかった。
機能が無きゃデータに意味を持たすことは出来ないんだよね。
それ分かっただけでも凄い前進だよ。
そんで、データと機能は両輪のようなものって言う言葉も聴けた。
それはその通り。昔っからそうで、社会と人民は両輪で、どちらが欠けてもダメ。
そこのバランス感覚が「判断力」という奴で、どこに行ってもその人の評価の対象となる箇所。大事だよ。

んでまぁちょっと変なのは、
データだけじゃ意味無いからデータに機能を持たせれば意味も持てるねっていう、
それがOOPの基本的な考え方なんだけど、それが変なんじゃないかって言う、そこの議論をしてたんだよね。
データに機能をもたせるったって、そのデータ単体で自分の機能を決めることは果たして出来るのかって。
青年が一人で自分の機能はこれこれですって叫んで、それが社会で通用するのかって。

データの意味は、他のデータとの相対的な位置関係で決まってくるものだから、
そのデータ単体にメソッド持たせても意味無いだろう。
例えば、1は2の半分だし、2は1の倍と定義されているから、機能するし、道具として使える。数学はそれで成り立ってる。
1や2が本質的に何者かなんてのはどうでも良く、ただ、お互いの相対的な関係だけ定義されてればそれで良い訳だ。
だから、1にメソッド持たせるのは気持ち悪いし、マルチメソッドが良いんじゃないかって。
マルチメソッドの無いOOPは罠だろうと。

555 ：デフォルトの名無しさん：2010/09/29(水) 23:07:15

データと機能がプログラムの両輪ってのはもちろんそうなんだけど、
ただ、その位置関係がさ。
機能はデータとデータの間に割って入ってデータとデータの関係を定義するものだから、
データ自体に機能を持たせるのは発展性がないだろうという。
分かりやすい例では、プログラムは入力と出力の関係を定義してるっていう。
Unixでは、$program < in > out とか書くけど、これは、
inとoutの間にprogramが割って入って互いの関係を定義している訳だ。
この割って入るものが、inかoutのどちらかにくくり付いているのは嫌だろ。
だって、inとoutにどういった関係を持たせるかはこちらで指示したいから。
inやoutに求めるのは、せいぜい型情報を提供することぐらい。

556 ：デフォルトの名無しさん：2010/09/29(水) 23:19:24

またなんか長文書いている人とか居るけど、まったく意味わからんし、どうよこれ。

557 ：デフォルトの名無しさん：2010/09/29(水) 23:24:03

3行超えるひとはトリつけろ

558 ：デフォルトの名無しさん：2010/09/29(水) 23:28:39

いつもの人だけど、文体に特徴を持たせるように気をつけてるよっていう。

559 ：デフォルトの名無しさん：2010/09/30(木) 00:25:58

知ってるか、
情報というのはそれ単体でエネルギーとして扱えるんだ、
1bitの情報が何カロリーか計算できてしまう。

つまり情報ってのは存在そのものなんだ。わかるか？

560 ：デフォルトの名無しさん：2010/09/30(木) 00:29:34

じゃあ32GBは何カロリー？

561 ：デフォルトの名無しさん：2010/09/30(木) 00:32:54

いつもの人は毎回毎回おんなじ事を違う言い方してるだけで、全然説得力がない。

ずっと「これ、気持ち悪くね！？」って言ってるだけっていう

562 ：デフォルトの名無しさん：2010/09/30(木) 01:15:05

例の人的に高階関数ってどういう解釈になるんだろう。

563 ：デフォルトの名無しさん：2010/09/30(木) 01:22:01

少し前に「カプセル化と継承のどっちがOOPの本質か」みたいな話があったが、

データと処理の細部を隠蔽して、オブジェクトの責務を公開インタフェースとして見せるためにカプセル化が重要で、
一方で、同じ責務を持つと同時に、異なる細部を持つオブジェクトを許容するための仕組みが継承、

という考え方はどうかな。

564 ： ◆o0jv9vCVwU ：2010/09/30(木) 13:41:01

>>563
いいと思う。

最近何となく思ったんだけど、
オブジェクト指向はもしかしたら、ジェネリックプログラミングがやりたかったのかもしれない。

カプセル化でデータを扱う機構の、インターフェースを合わせ、
継承で複数のデータ型を同じ枠組みにまとめ、
ポリモーフィズムで複数のデータ型を適切に扱い、
それでも不十分なら動的束縛（Ｃ＋＋には無いけど）で対処する。

なんとなくジェネリックぽくね？

565 ：デフォルトの名無しさん：2010/09/30(木) 15:54:28

>>マルチメソッド
http://www.google.co.jp/search?q=%E3%83%9E%E3%83%AB%E3%83%81%E3%83%A1%E3%82%BD%E3%83%83%E3%83%89
ないな
いかれてる

566 ：デフォルトの名無しさん：2010/09/30(木) 15:55:30

Ｃでもジェネリックできるが

567 ：デフォルトの名無しさん：2010/09/30(木) 17:32:49

>>654
センスないよ君

568 ：デフォルトの名無しさん：2010/09/30(木) 17:33:34

>>564
センスないよ君

569 ：デフォルトの名無しさん：2010/09/30(木) 17:50:27

みんな～、>>568はセンスあること書き込んでくれるってさｗｗｗ

570 ：デフォルトの名無しさん：2010/09/30(木) 18:04:40

俺も彼はセンス無いと思うよ。
センスってのは感性だろ？言うならば物差しや整頓棚。
ごちゃごちゃに散らかってる様を指してセンス無いと称される。

571 ：デフォルトの名無しさん：2010/09/30(木) 18:49:45

単なる話題振りにも攻撃するとか必死だな。

572 ：デフォルトの名無しさん：2010/09/30(木) 18:59:38

Update()と文字数がそろったほうが美しい

573 ：デフォルトの名無しさん：2010/09/30(木) 20:25:20

>>564
なるほど、そういう考えも出来るな。
ジェネリックプログラミングとオブジェクト指向は相性もいい。

しかし、FORTRAN/COBOLから始まった高級言語の目的は
いかにプログラミングを抽象していくかだから
別にオブジェクト指向に限ってないと思う。
構造化言語にもジェネリックプログラミングが導入されていたし。

目指す方向はどの方法でも根本は同じだからね。

574 ：デフォルトの名無しさん：2010/09/30(木) 20:46:35

LISPディスってんの？

575 ：デフォルトの名無しさん：2010/10/01(金) 18:06:07

リスってます

576 ：デフォルトの名無しさん：2010/10/01(金) 20:16:47

(CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAR '((((((((((((((((((((((((((((((((((((
おまえは今まで使った括弧の枚数を覚えているのか？)))))))))))))))))))))))))))))))))))))

577 ：デフォルトの名無しさん：2010/10/01(金) 21:15:25

まあLisp使いは実際、あんまり括弧のこと考えてないよね

578 ：デフォルトの名無しさん：2010/10/02(土) 00:49:17

>>577
そんなことない！
見える括弧と見えない括弧があってだなぁ…………
# let 直後とかの各個は良く見えるもん

579 ：デフォルトの名無しさん：2010/10/04(月) 16:43:48

OOPまったく関係ないけどさ
PHPやらcgiとかサーバーサイドの言語で無限にファイルを作成するプログラム組んだらどうなるの？

580 ：デフォルトの名無しさん：2010/10/04(月) 16:55:01

まったく関係ないからもう書き込むなよ。

581 ：デフォルトの名無しさん：2010/10/06(水) 18:19:54

C/C++ のテンプレートプログラミングもジェネリックぽいよね

582 ：デフォルトの名無しさん：2010/10/06(水) 18:41:49

ジェネリックがテンプレートもどきなんじゃね

583 ：デフォルトの名無しさん：2010/10/06(水) 19:57:50

テンプレートの最も多い用途に特化したのがジェネリックじゃね

584 ：デフォルトの名無しさん：2010/10/06(水) 23:08:21

ジェネリックというとソースコードを自動生成するのか
ソースコードで生成したプログラムでデータを自動生成するのか
どっちのこと？

585 ：デフォルトの名無しさん：2010/10/06(水) 23:39:40

前者はジェネレイティブプログラミング
後者はよくわからないが、ジェネリックとは違うと思う

586 ：デフォルトの名無しさん：2010/10/07(木) 01:27:00

>>581-585
頭の悪い会話
みなくていい

587 ：デフォルトの名無しさん：2010/10/08(金) 13:50:08

HTMLコードをCでジェネレートした
画像一覧を表示するページで６００枚ほど表示させる<a href=... ></a>
とforでまわしてジェネレートして表示しようとしたら
ＩＥが固まった
１ページで表示するには何枚くらいが妥当？

588 ：デフォルトの名無しさん：2010/10/08(金) 18:47:52

おまえのパソがへぼいだけです

589 ：デフォルトの名無しさん：2010/10/08(金) 20:29:49

>>587
>>588 のいうように、WebブラウザとPCのスペック次第だと思うけど

その例でいうWebブラウザ用のUIの話ならば、
WEB+DB PRESSの連載の「モダンWebインタフェース構築術」がそういう話題扱ってる。

AJAX(JavaScript)で画面に見える範囲だけ画像を表示みたいなのはVol.57 でやってるね
WEB+DB PRESS Vol.57
http://www.amazon.co.jp/dp/4774142727/

ただ、上の記事はバックエンドあるWebサービスの話だから、
「HTMLコードをCでジェネレートした」とはけっこう遠い。
(とはいえ、Cで画像のメタデータをjsonとかxmlで吐いておいて、
JavaScritpで動的に少し見える範囲だけ表示というようなモダンなつくりは応用可能だとは思う)

590 ：デフォルトの名無しさん：2010/10/09(土) 23:20:57

オブジェクトをカプセル化カプセル化・・・って依存関係をガンガン切っていくと
確かに個々のオブジェクトの仕事はシンプルになって保守しやすくなるんだけど
何かちょっと新しい仕様を入れようと思うと、、、

このオブジェクトにアレを追加して、
あっちのオブジェクトからあのデータもらって、
そのデータをこっちのオブジェクトに渡して、そっから更にこっちに渡して
ここで処理をやって、そしたら結果をこいつに渡して・・・

ってすごい勢いでいろんな処理の流れがタライ回しのように飛び交ってしまう。
依存関係を切れば切るほどメッセージングの量が膨大に増えていく。
これって良くなってるのか？ってたまに思ってしまうんだけどそんな経験みんなないかな

OOPってカプセル化された個々の処理はシンプルになるけど、
全体の処理の流れが凄く分かりにくくなる欠点があると思う

591 ：デフォルトの名無しさん：2010/10/10(日) 00:19:06

バランス感覚の問題

592 ：デフォルトの名無しさん：2010/10/10(日) 00:37:32

カプセル化を控えると再利用が効きにくくなりコードのコピペが増えるので
一概にそうも言えない

593 ：デフォルトの名無しさん：2010/10/10(日) 01:28:12

全体の流れはデバッガにでも流せば何となく判るからいいや

594 ：デフォルトの名無しさん：2010/10/10(日) 02:29:41

>>590
そのためのテスト(テストファーストとか振る舞いとかの方の)だし、リファクタリングしろって流れじゃないのかな

595 ：デフォルトの名無しさん：2010/10/10(日) 02:30:52

あ、OOPのカプセル化とは直接関係がないなスマソｗ

とにかく直すの前提じゃないかといいたかった

596 ：デフォルトの名無しさん：2010/10/10(日) 02:56:14

コピペを減らしたいならマクロがある
コピペを減らしたいからってカプセル化するのは馬鹿

597 ：デフォルトの名無しさん：2010/10/10(日) 03:34:29

え？

598 ：デフォルトの名無しさん：2010/10/10(日) 11:45:19

モデルの段階のミスはコードのリファクタリング以前に検知して直したいな
コード書く前、いやクラス設計とか考える前ぐらいにさ
なんかいい方法ないのかな

599 ：デフォルトの名無しさん：2010/10/10(日) 13:41:46

>>598
ハード屋業界には結構そのためのツールあるのにな…
ソフトでもj十分使えるんだが, あの手のモデリングシミュレーションツール

ソフト屋がアホで使えてないだけ???

600 ：デフォルトの名無しさん：2010/10/10(日) 14:19:22

設計のミスと片付ければ簡単だが、
それ自体は特に問題があるようには見えず、シコシコ実装すれば最終的に綺麗に出来上がるわけだ。

この機能が必要だから、あのオブジェクトをメンバに入れて、
この機能とこの機能を連携させたいから、ここであのオブジェクトのメソッドを読んで・・・

ってやってくわけだが、どうにもやりたい事に対してコーディング量が増えすぎてる気がしてならない。
とはいえ、仕様の規模が大きくこれ以上の粒度でのカプセル化は考えにくい。
コーディング量は増えてる代わりに、膨大な仕様にもかかわらず混乱なく実装できてると言ってしまえばそうなんだが・・・

601 ：デフォルトの名無しさん：2010/10/10(日) 14:59:47

なんか、好き勝手の縦横無尽にコーディングして
あとから依存関係を視覚化してくれるような物が無いかなぁ。

602 ：デフォルトの名無しさん：2010/10/10(日) 15:09:53

>>600
> 膨大な仕様にもかかわらず混乱なく実装できてる

ある程度以上の規模になると、それが一番重要なことだと思うけどなー。
依存関係がごちゃごちゃになって破綻したコードの変更ほど悲惨なものはない。

603 ：デフォルトの名無しさん：2010/10/10(日) 15:17:05

やりたいことは、

A　→　B

でもコーディングは、

A　→　Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB

だったりする。
しかもそれぞれのオブジェクトに担当者がいる。

ひとりでやれば５分で終わることが、（カプセル化されてなければ１分で終わることが）
まず担当者に機能追加の相談をしにいく事から始まる。
これはしょうがないのだろうか。

604 ：デフォルトの名無しさん：2010/10/10(日) 15:35:45

それだけ見るとすごく駄目な設計に見えるんだけど……

605 ：デフォルトの名無しさん：2010/10/10(日) 15:39:26

ある程度離れたオブジェクトにアクセスする必要があるってだけの例えだよ。
アクセサ辿るのメンドイからシングルトンにしましたってのも違うしなあ

606 ：デフォルトの名無しさん：2010/10/10(日) 15:44:48

これってカプセル化されてなかったら簡単というよりグローバルにしたら簡単っていう話じゃないか？

607 ：デフォルトの名無しさん：2010/10/10(日) 15:47:16

それは全然カプセル化されてない
なんでそんな各クラスの詳細を知らなければならない？

Aが
Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB
を返すアクセス出来るインタフェースを用意すべきで
Cは
Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB
Dは
Dの基本クラスのE　→　Eの持ってるB
についても同じ。基本クラスの部分は用意しなくていいけど。

608 ：デフォルトの名無しさん：2010/10/10(日) 15:47:21

カプセル化しないってのはグローバルって事だろう

609 ：デフォルトの名無しさん：2010/10/10(日) 15:58:51

>>607
そうそう、いざそれを実装するのが超面倒というわけ。
仕様が複雑だとこれだけじゃ機能がちょっと足りなかったねって事がよくあるし
実際そんなにしっかり仕様が決まっていることもなく、アプリの上の方では頻繁にありうる。

本当は他のクラスの詳細なんて知りたくないんだけど、
いったん「あれ、あの状態っていったいどこから取得するんだ？？」ってなったら
結構な勢いでいろんなクラスに穴を開ける作業が発生する。

610 ：デフォルトの名無しさん：2010/10/10(日) 16:03:27

>>608
全然違う。それだと、グローバル変数に束縛したらどんなオブジェクトもカプセル化出来ていない事になる

611 ：デフォルトの名無しさん：2010/10/10(日) 16:04:53

いくらグローバル変数でも、そのprivateメンバにはアクセス不能なんだからカプセル化はできてるのでは

612 ：デフォルトの名無しさん：2010/10/10(日) 18:31:28

>>611
カプセル化は目的ではなくて手段。
グローバルなオブジェクト自体がいつ、どこからアクセスされるのか分からない状態に陥るわけで、
それによって変更に弱くなるし、厄介なバグの遠因になる。

613 ：デフォルトの名無しさん：2010/10/10(日) 18:38:11

>>609
当初考えていた設計が不適切だった、ということ自体は、当然起きうる。
そこでリファクタリングしてインタフェースを切り直し、より適切な設計に近づけて行く。

あるいは、「ある担当者が一つのクラスのクラスを担当する」という体制自体の問題かもしれない。
その現場を知らないから断言はできないけど。

614 ：デフォルトの名無しさん：2010/10/10(日) 18:41:42

>>612
そんなことはみんなわかってるよ。
だがカプセル化したらメッセージのタライ回しが増え、
ある程度実装に時間がかかるようになる傾向があるのも事実だろう。

それなんとかする方法ないの？ってのはOOPの命題じゃね。

615 ：デフォルトの名無しさん：2010/10/10(日) 18:51:22

>>614
あるオブジェクトから、遠く離れたオブジェクトの状態が欲しいということが頻繁に起きるなら、
それはそのオブジェクト間に本質的な関連性があるか、あるいはインタフェースの切り方が不適切か、
のどちらかじゃないのかな。

616 ：デフォルトの名無しさん：2010/10/10(日) 18:56:06

>>613
担当の分け方が不味いのは確実にそうなんだが
余裕のあるプログラマから必要になった仕事を割り振っていかないと回らない現実もあるんだよな。
本当は全員がどのコードでも弄れるってのが良いのかもしれないが規模が大きくなると大変だ

クラス間のメッセージングを実装するのに、まず担当プログラマ同士で口頭メッセージングなんて笑い話だが
実際そのようになってしまっているのでなんとかしたい。

617 ：デフォルトの名無しさん：2010/10/10(日) 19:02:39

>>616
確かに、ある機能単位ごとに担当者を割り振る、というのがそこまで不適切かと言われると、現実的にはそうかもね。
クラス単位じゃなくて、もっと大きな機能単位（モジュール?）ごとに割り当てればいいのかなぁ。
アジャイルとかだと、そのへんどうしてるんだろう。

618 ：デフォルトの名無しさん：2010/10/10(日) 19:04:32

>>603の例はAのスコープから参照出来るようにクラスメソッドとか作ればある程度解決するんじゃないか

619 ：デフォルトの名無しさん：2010/10/11(月) 00:44:06

>>603
> A　→　Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB

これをやるというsewageというアクセサを作って(委譲でもなんでもいい)、必ずsewage経由で使う、
sewageのテストはもちろん書いておいて勝手に担当者がどこかの構造構造が変えてもわかるように

・・・したいけど、まず「Eの持ってるB」「Dの基本クラスのE」「Cを管理してるD」「Aの持ってるC」を得るのに
それぞれの担当者に掛け合う必要あるという話でいいのかな

620 ：デフォルトの名無しさん：2010/10/11(月) 03:22:44

現状の現実をベースに考えると設計を崩さざるを得ない。
極度に納期主義、実績主義で、リファクタリングなんか
ほとんどさせて貰えず、腐った増改築が繰り返されるだけだ。

まぁうちの会社だけかも知れないけど。
参考までに言うと家電組込系。

621 ：デフォルトの名無しさん：2010/10/11(月) 09:45:36

>>614
>カプセル化したらメッセージのタライ回しが増え、
>ある程度実装に時間がかかるようになる傾向があるのも事実だろう。
そもそもメッセージのタライ回しがオブジェクト指向の基本。

>それなんとかする方法ないの？ってのはOOPの命題じゃね。
これも違う、コンピュータの処理速度が上がったからオブジェクト指向が受け入れられた。
いまは「ソフトウェアの生産性＞処理速度」の時代。（処理速度が上がってMS-DOSからWindowsになったのと同じ）

そもそもオブジェクト指向はソフトウェアの再利用を促進して生産性を上げる手法。
その為に事前に再利用の準備が必要になり、コーディング量は増える傾向にある。

例えば家電で例えると、家電を作ったが電源を取る為にコンセント用プラグを装着しないといけない。
また、部屋の方もコンセントを準備しないといけない。
これらは、本来電化製品を使うには必要ないものだ（昔は電球のソケットから電気を取っていた）
しかしコンセントが無いと非常に汎用性が無くなる。
コンセントやプラグは再利用の為のコストで、これと似たようなことをオブジェクト指向でも求められる。

622 ：デフォルトの名無しさん：2010/10/11(月) 13:06:06

そのタライ回しの部分がC時代から進歩してないから、何とかしろって言ってるんだろ。

623 ：デフォルトの名無しさん：2010/10/11(月) 13:10:16

だいたい、自分で「タライ回しがOOPの本質」とか言っといて、
その本質部分のタライ回しの、つまりは制御構造は昔から全然進化してないってどういうことよ。
だから、その部分が今後の課題って意見は凄く真っ当だろ。と、いつもの人は思った。

624 ：デフォルトの名無しさん：2010/10/11(月) 13:12:15

例え話が出てくると、途端に分かりづらくなる。
電気プラグは関係ない。
電球ソケットは十分汎用的だった。
ソケット数が足りなかっただけだ。

625 ：デフォルトの名無しさん：2010/10/11(月) 13:16:21

OOPLに於いて、制御構造は微妙に変化したと思うよ。多態に変わった部分があるからね。
まあ以前から関数ポインタとかで出来たかも知れんが、あまり日常的ではなかった。

626 ：デフォルトの名無しさん：2010/10/11(月) 13:20:40

その多態による変化が進化か退化か判断つかないところがあるから困ってるんだろ。
ようは、オブジェクト単で制御構造をぶつ切りにするから、そのクッションとして多態が必要になったんだけど、
制御構造的にはそれってどうなんよと。
ただ、よりいっそうオブジェクト寄りの思想になったことだけは確かなんだけど、
それもどうなんよと。物主体ってのはなんかアホっぽいし、なんかちょっと変な方向へ向かってるような悪寒。

627 ：デフォルトの名無しさん：2010/10/11(月) 13:25:33

で、当たり前、オブジェクト同士のコミュニケートで皆困ってる罠。
電気回路だったら、ICに足がいっぱいあって、それつなぎ合わせると、後はある意味勝手にコミュニケートするんだけど、
ソフトは逐次実行で流れ作業だからなぁ。
本来物理現象で勝手に行われることを、逐次で自前でやってる訳で、
現実世界と同じ理屈はなかなか当てはまらないと思う。
その辺数学はうまく切り抜けてるけど、ただ、数学は概念でしかなくて、そこから落とし込まないと製品を作れ無いと言う。
困ったね。

628 ：デフォルトの名無しさん：2010/10/11(月) 13:30:21

まぁ100年後には全部FPGAになるかもしれんし、こんな議論も全部意味なくなるかもな。
ただ、100年後にはここにいる誰も生きていないがな。

629 ：デフォルトの名無しさん：2010/10/11(月) 13:32:50

>>625
> まあ以前から関数ポインタとかで出来たかも知れんが
へたな OO 設計より,
十分ドキュメント化された,, 有効な hook を提供してくれるソフトの方が
運用的には役立つな.

630 ：デフォルトの名無しさん：2010/10/11(月) 13:38:18

Gtkとかな。わかります。
もしアレがオブジェクト指向だったら嫌だよな。ボタンクラスを継承してくださいとか、うへーー。

631 ：デフォルトの名無しさん：2010/10/11(月) 13:40:44

新しい技術に対応できなくなったリストラ候補のスレ

632 ：デフォルトの名無しさん：2010/10/11(月) 13:48:52

>>631
で、全継承クラス眺めてるひまがあんたにあるんかい?
つか >>629 の言ってるのはある意味真実じゃね？
現場に会わせて特化させようにも山ほど書類が…
てな、現実は無しにしてほしいいわ

633 ：デフォルトの名無しさん：2010/10/11(月) 14:02:41

どっちかっつーとそれは、書類のほうの設計をそろそろ見直さなきゃならんのでは
OOPに適した書類管理方法を提唱しなければならんな

634 ：デフォルトの名無しさん：2010/10/11(月) 14:40:30

もうある
なんというリストラ候補
こんな時間に・・・ガチだなこれは

635 ：デフォルトの名無しさん：2010/10/11(月) 14:43:52

ある課題をソフトウェアで解決する場合、いろいろな方法で行なっても難易度自体は変らない。
（その方法の中でベストなものが前提だが）

一般的に、その方法は三つある。
・難易度をアルゴリズムで解決する方法。（FORTRAN,C言語など）
・難易度をデータ構造で解決する方法。　（ＣＯＢＯＬ,Ｐａｓｃａｌ言語など）
・難易度を構造で解決する方法。　　　　　（オブジェクト指向言語など）
　（構造化言語からオブジェクト指向言語に拡張した言語を見ればわかるが
　　アルゴリズムに関する拡張はなく、構造に関する拡張のみ）

だからオブジェクト指向でメッセージが多くなるのは当然
それを回避したいなら別の方法で行なうしかない。

636 ：デフォルトの名無しさん：2010/10/11(月) 14:43:55

javadocとmvn testじゃだめなの？

637 ：デフォルトの名無しさん：2010/10/11(月) 14:46:54

>>630
最近はそこらへんはさ、継承でも出来るけど
デリゲートつかってくださいってかんじじゃねえか？

まあ要するにフックなわけだ。

638 ：デフォルトの名無しさん：2010/10/11(月) 14:55:52

うん、でもデリゲートはOOPの範疇じゃないと思うんだ。

639 ：デフォルトの名無しさん：2010/10/11(月) 14:56:31

あるインタフェースを持つオブジェクトを利用する側が、
利用される側の内部のメッセージのたらい回しのされ方を気にしなきゃいけない状況が頻繁に発生するなら、
それは設計の段階でインタフェースの切り方を間違っていた可能性が高いわけだから、修正する必要がある。
従って、配線のやり直しは必要なコスト。

と、まぁ原理的にはこうなる。
上で出てたみたいに、そんなことできる開発体制じゃないんだよ、という意見はあるにせよ。

ただ、これはそもそも依存関係の整理という利得を得るためにやってるわけだし、
そことのトレードオフをどう考えるか、という話になるのかな。

640 ：デフォルトの名無しさん：2010/10/11(月) 14:58:59

>>638
最近のOOPの実践では委譲(delegate)の方が重要視されてると思うが？

641 ：デフォルトの名無しさん：2010/10/11(月) 15:03:18

その、利用される側、とか、利用する側、とか、って発想おかしくない？
1+2で、1が利用する側、2が利用される側ってことになるか？
しいて言えば、+が1と2を利用しているとは言えるかも。
+はプログラミング言語で言えば関数なんだから、
関数が引数を利用する、で良いんじゃないの？
オブジェクトがオブジェクトを利用するってｵｶｼｲ

642 ：デフォルトの名無しさん：2010/10/11(月) 15:05:14

>>640
それがOOPが崩壊してきたって事でもあると思ってる。
C++の連中もテンプレートばっか注力しているようでなによりです。

643 ：デフォルトの名無しさん：2010/10/11(月) 15:09:36

>>641
利用側と被利用側に切り分けることで、各オブジェクトの責務を明らかにでき、
結果として依存関係の整理に役立つ。
四則演算の例は単純すぎるし、演算子のどちらの項も同じ型なわけで、例として適切でもない。

644 ：デフォルトの名無しさん：2010/10/11(月) 15:11:33

違う型だったらいいの？1+2.0とか。

645 ：デフォルトの名無しさん：2010/10/11(月) 15:12:04

>>642
古い継承ベースのOOPが、な。
mix-inみたいな柔軟な仕組みが使えるなら、また少し話が変わるかもだが。

646 ：デフォルトの名無しさん：2010/10/11(月) 15:16:10

>>645
俺のイメージでは、保守派の左翼からリベラリストになったって感じ。
たしかにマシになってきてはいるんだけど、やっぱ根本がずれてるって。
ズレてても機能さえすりゃいいんで、まー周りからは放置されるんだけどな。

647 ：デフォルトの名無しさん：2010/10/11(月) 15:16:44

>>644
単純な二項演算を利用側と被利用側に切り分けて責務を与える、とか、
言語のモデルを統一して見通しを良くする以上のご利益なんかないじゃん。
不適切な例を持ち出しても、それは反例にはならない。

648 ：デフォルトの名無しさん：2010/10/11(月) 15:18:40

やべぇ言ってる意味がわかんねぇ。こえぇ。
責務とか言ってるのお前なのに、俺が言ったことみたいになってるし。

649 ：デフォルトの名無しさん：2010/10/11(月) 15:20:52

>>646
自由主義者の俺からマジレスすると、共産主義と自由主義は全然別物だぞ。
日本で「リベラル」といってるアレは、ロールズに代表される自由主義とは何の関係もない。

650 ：デフォルトの名無しさん：2010/10/11(月) 15:25:13

その前に、左翼と共産主義が同じとも限らなくない？
左翼の実装例が共産主義ってだけだろ？
今俺は、左翼がリベラル実装に発展したっていってるだけで。
民主党的イメージ。共産党とは別。
民主党も機能している限りは構わないって周りから放置されてるじゃん。
事業仕分けとか、ああいうものも必要だろうって。

651 ：デフォルトの名無しさん：2010/10/11(月) 15:25:32

じゃあタバコとライターと喫煙者で例だしてみてよぅ

652 ：デフォルトの名無しさん：2010/10/11(月) 15:27:49

だから俺はOOPの立ち居地は民主党とかぶるなぁっと思ってる。必要悪。
だけど、用済みになったらﾎﾟｲｯだからな、怖い怖い。
とはいっても社会人生活は40年しかないんだから、その間だけ持てば十分だろうとも。
だから皆OOPとかやってるんだろうね。自分の代だけ持てばいいやって。
でも2chでそれやるのは詰まらんね。

653 ：デフォルトの名無しさん：2010/10/11(月) 15:29:15

いっぷく ( &タバコ, &ライター, &喫煙者 );

654 ：デフォルトの名無しさん：2010/10/11(月) 15:31:29

喫煙者.一服　タバコ　ライター
っていうように書きたひ

655 ：デフォルトの名無しさん：2010/10/11(月) 15:32:52

いっぷくの処理内容がタバコに依存しているかも知れんぞ。
ライターは火打石かも知れんぞ。

656 ：デフォルトの名無しさん：2010/10/11(月) 15:40:32

>>648
横からだけど、俺もＯＯを勉強したてのころは
お前みたいに訳の分からん事をいっていたよ、懐かしいな。
頑張れよ。

657 ：デフォルトの名無しさん：2010/10/11(月) 16:04:04

でも実際
喫煙者.一服　タバコ　ライター
ってどうなんだろうね。
タバコ無しじゃタバコすえないし、タバコ吸うことはタバコのメイン機能なんだから、
タバコ.一服　喫煙者　ライター
が正解のように思える。
だけど、一服の形は人それぞれで、もしかしたらタバコをすわない場合もあるかもしれない。
だから、やっぱり一服は喫煙者に紐付けしたほうが良いかもしれない。
ほらもう解らないよね。
でも言うんだろ？それはどういった状況を前提にしているかによる、と。
だけどそれは裏を返せばコードを使いまわせないってことでもあって、墓穴掘ってるんだよね。

658 ：デフォルトの名無しさん：2010/10/11(月) 16:05:23

>>655
現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな

659 ：デフォルトの名無しさん：2010/10/11(月) 16:09:41

>>603
なんて駄目な設計なんだ・・・　どうしてこんな設計に・・・

まず、
＞Aの持ってるC　→　Cを管理してるD
これはCを、AとDが二重に管理しているという解釈でいいよな？
なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
Cを管理するA(D)
もしくは、DはAを管理するようにする。
Cを管理するA　←　Aを管理するD

つぎ、
＞Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB
そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
基本クラスのEを気にする必要は無い。
BとCを管理するA(D)
もしくは、　
Cを管理するA　←　AとBを管理するD

超すっきり。
そもそも、上にAとBを管理するクラスがあるのに、
＞A　→　B　
なんて直接アクセスするような、行き当たりばったりなコーティングをするからいけないんだ。
これはAがやる仕事じゃないだろ。なんで上に管理させてるんだよ。

660 ：デフォルトの名無しさん：2010/10/11(月) 16:10:30

>>658
でも、
いっぷく ( &タバコ, &ライター, &喫煙者 );
で示されるタバコとライターと喫煙者の関係は、現実でも成り立つのだ。
あっても、引数の順番に野次が飛ぶぐらい。

661 ：デフォルトの名無しさん：2010/10/11(月) 16:32:54

>>657
＞タバコ.一服　喫煙者　ライター
タバコ自体が一服の機能を持つとか、タバコが喫煙者を使うとか、
そんな馬鹿なこと言ってんじゃねーよ。

662 ：デフォルトの名無しさん：2010/10/11(月) 16:37:53

>>661
現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな

663 ：デフォルトの名無しさん：2010/10/11(月) 16:47:20

>>630
＞ボタンクラスを継承してくださいとか
こういうことをするメリットはちゃんとあるぞ。

たとえば、ボタンクラスを使うフォームクラスがあるとする。
フォーム．ボタン配置（ボタン）
これは普通に使う分には問題ないよね？

じゃあ、このフォームクラスに渡すボタンクラスの機能を変えたいとする。
もし、ただ単純に新しいボタンクラスを作っただけだと、
フォームクラスにそれは渡せないよね？
それがどういうものかフォームクラスには分らないから当然なんだが。

でも、フォームクラスがそれをどういうものか分れば話は別だ。
それを実現する機能が、継承なんだ。

新しいボタンクラスに、元のボタンクラスを継承させると、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが出来る。

フォームクラスは元のボタンクラスの機能とインターフェースの仕様は知っているので、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが備わっていれば、
フォームクラスはまるで元のボタンクラスを使うように、新しいボタンクラスも使えるようになるんだ。

664 ：デフォルトの名無しさん：2010/10/11(月) 16:49:23

>>662
疑問が出てくるから何？
それは全く関係ないプログラムの機能の話とは、全く繋がらないぞ。
関連性がまるでない。それを見てどうしろと言うんだ。

665 ：デフォルトの名無しさん：2010/10/11(月) 17:31:36

実空間の物体の用法や使用例を基にオブジェクト指向的分析を行うのが難しい理由ってなに？
人それぞれ抽象度や理解力が違うからなの？

666 ：デフォルトの名無しさん：2010/10/11(月) 17:36:52

>>665
実空間の物体の用法や使用例が、
自分の作るプログラムの用法や使用例に合っていないと、
分析しても変な結果になる。

そこに原因があるんじゃないかと。

667 ：デフォルトの名無しさん：2010/10/11(月) 17:39:34

みんな共有できる思いは「動きゃいいんだよーぅ」だな

668 ：デフォルトの名無しさん：2010/10/11(月) 17:41:43

>>665
鳥クラスを作ってflyインタフェースをつけてもペンギンやダチョウは飛べない
そういう現実の分類と実際とのギャップは色々ある
長方形を継承して正方形を作るのが失敗だという古典的な例とか調べてみれば

669 ：デフォルトの名無しさん：2010/10/11(月) 17:43:21

>>667
そうだなｗ

ただ、その何とか動いているものに、
何かしらの手を加える必要に迫られることは、絶対にあるから大変。

670 ：デフォルトの名無しさん：2010/10/11(月) 17:58:07

>>666
その通り。
だから、型やオブジェクトにメソッドじゃーなんじゃーって機能を持たせても意味ない。
そのオブジェクトがどう使われるかは、使う人次第。
画像ファイルに展開用コードが内包されていないのと同じ。
ヘッダでフォーマットさえわかればよい。
どう扱うかはプログラムが決める。

671 ：デフォルトの名無しさん：2010/10/11(月) 18:03:51

>>670
自販機の中のジュースを、外の人間が自由に取り扱ってもいいなら、それでもいいけどな。

672 ：デフォルトの名無しさん：2010/10/11(月) 18:32:30

>>670
あと、データそのものと、データの入れ物を一緒にすんなよ？

673 ：デフォルトの名無しさん：2010/10/11(月) 19:22:03

何言ってるんだろう。翻訳求む。
相当都合の悪いこと言っちゃったかな。

674 ：デフォルトの名無しさん：2010/10/11(月) 19:34:41

タバコとライターは喫煙者にとってhas aじゃないの？
別途買うなり借りるなりでセットして、一服は引数無し。
属性コーヒーが非nullなら、一緒に飲んだって構うまいよ。

675 ：デフォルトの名無しさん：2010/10/11(月) 19:39:30

大丈夫
俺もわからん

676 ：デフォルトの名無しさん：2010/10/11(月) 19:40:48

ソースコードを日本語に無理やり改訳するツールでも使ってるんじゃね？

677 ：デフォルトの名無しさん：2010/10/11(月) 20:35:56

>>659
Cは何かの操作を提供するインターフェース的オブジェクトで
操作の実態はDがまとめて実行しているかもしれない

Bはいくつかアルゴリズムを持ったデータベース的オブジェクトで、
E(D)はこのアルゴリズムを参照してCで受け付けた操作を実行しているかもしれない
そしてDはEによって回される処理の実装かもしれない

今、Aの内部状態によってBのアルゴリズムを切り替える必要が出てきたとする。

ここまで行くとDが処理の基幹を担う重要なオブジェクトであることはうっすらみえてくるはず。
Dが直接AやBを管理して結合を強めることに危険を感じ無いか？
ましてやAとDが同一なんて有り得ない。

678 ：デフォルトの名無しさん：2010/10/11(月) 21:06:01

>>670
そして色んなコードが自分の都合のいいようにデータを操作しまくって収集がつかなくなるんですね、わかります。

679 ：デフォルトの名無しさん：2010/10/11(月) 21:30:10

>>673
画像データはデータそのもの。
型やオブジェクトはデータの入れ物。
ちゃんと言った方がよかったな。

680 ：デフォルトの名無しさん：2010/10/11(月) 22:07:25

>Cは何かの操作を提供
これで一度納得したのに、
>E(D)はCで受け付けた操作を実行
で、Cがなんなのかよくわからなくなった。
Cが実行する操作を決めてるの？

>DはEによって回される処理の実装
これなら、DがEを継承する必要なくね？
EがDを呼び出すだけでいい。

>Dが直接AとBを管理して結合を強めるのに危険を感じないか？
感じない。
そもそも、Dと、AやBの間に何かかませても、結合は弱くならない。面倒なだけ。

それより、AやDが、Cを別々に管理や操作する方が危険を感じる。
感じない奴はプログラマやめろ。

>AとDが同一なんてあり得ない
そこはよくわからなかったから、二通り考えたけど、もう一方はどう思う？

681 ：デフォルトの名無しさん：2010/10/11(月) 22:15:36

だめだこりゃ

682 ：デフォルトの名無しさん：2010/10/11(月) 22:25:17

それぞれの理解度が違うんじゃあ
平行線ですよね

683 ：デフォルトの名無しさん：2010/10/11(月) 22:29:59

そう思うならさっさと叩きのめせばいいのに。

684 ：デフォルトの名無しさん：2010/10/11(月) 22:32:55

そもそも継承するってことは多態が必要ということなので
Dと似た振る舞い（この場合ばBのアルゴリズム利用の何らかの実装）をする
Eを継承したオブジェクトが他に存在すると考えるのが妥当

もっと言うとDやEを継承した他オブジェクトを保持したり扱ったりするクラスも他に存在するんだろう

685 ：デフォルトの名無しさん：2010/10/11(月) 22:35:42

そもそもAからBにアクセスしたい！と思ったときに
可能であれば他に一切変更を加えずに自動的にボッコシ穴あけてアクセスできるような仕組みが
（ようするにそれによって依存関係が崩壊しない保証ができるような機構が）
存在すればOOPももう一歩価値が高まるのに、って話では

686 ：デフォルトの名無しさん：2010/10/11(月) 22:53:32

>>684
>継承するってことは、多態が必要
なにそれ初耳。どこの情報？

>Dと似た振る舞い
何が？
Eがということなら、なに当たり前(ry

>DやEを継承したクラスが他に存在
Dが継承されてるなら、慎重にやる必要があるな。
でも、Eが他のクラスに継承されてたとしても、Dには何の関係も無いだろう。

ところでこれは>>680に対する反論なのか？

687 ：デフォルトの名無しさん：2010/10/11(月) 22:56:10

>>685
そんな行き当たりばったりなコーティング、オブジェクト指向じゃなくても有害だわwww

688 ：デフォルトの名無しさん：2010/10/11(月) 23:09:27

>>686
つ読解力

689 ：デフォルトの名無しさん：2010/10/11(月) 23:11:10

>>687
依存関係が崩壊しない保証があればどれだけ行き当たりばったりでもそれは問題にならない
OOは依存関係を整理するためにあるんだから

690 ：デフォルトの名無しさん：2010/10/11(月) 23:17:44

>>688
>>684から他に何を読み取れと。
説明も何もないぞ。

691 ：デフォルトの名無しさん：2010/10/11(月) 23:21:26

>>689
いままでの話を無視すんな><
そもそも、依存関係が崩壊しない保証を確認してコーティングするのは、行き当たりばったりじゃなくね？

692 ：デフォルトの名無しさん：2010/10/11(月) 23:31:59

Java/C++でひとりでコーディングしてるとすごくしっくりくる書き方がある。
これをチーム開発にしたとたんわけわからんイベントが多数発生する。
この原因を理解して言葉にしたいんだが。

693 ：デフォルトの名無しさん：2010/10/11(月) 23:50:41

>>692
つジョエルテスト
最近知ったやつだけど、チームの問題を探る役に立つかも？

694 ：デフォルトの名無しさん：2010/10/11(月) 23:58:35

ぐぐってみたけどそういうことじゃないみたい。

695 ：デフォルトの名無しさん：2010/10/12(火) 00:29:14

>>691
だからそういう保証が簡単に取れる仕組みがあれば良いねって話でしょ

696 ：デフォルトの名無しさん：2010/10/12(火) 00:35:12

多態以外で継承使う奴は差分プログラミングとOOPの区別が付いてないから厄介
チームに居ると割と複雑なバグだしよる

697 ：デフォルトの名無しさん：2010/10/12(火) 00:41:22

>>696
横からで悪いが、お前はオブジェクト指向が分かっていない。
いい加減、自分だけレベルが低いことに気付け。

698 ：デフォルトの名無しさん：2010/10/12(火) 00:43:36

あれ？OOPじゃなくてOOなの？

699 ：デフォルトの名無しさん：2010/10/12(火) 00:44:58

>>695
いや、そんな話しはしてなかった。
>>603の例の設計は駄目だねって、俺が始めた話し。

700 ：デフォルトの名無しさん：2010/10/12(火) 01:15:33

>>699
別に提案自体はそんなに悪筋じゃないし、そういう言い方せんでも良いのでは。

701 ：デフォルトの名無しさん：2010/10/12(火) 06:39:29

>>697
分かってないのはお前だ。
どうせOOの一番の特徴は再利用性とでも思っているのだろう。

702 ：デフォルトの名無しさん：2010/10/12(火) 11:00:35

>>696
>差分プログラミングとOOPの区別が付いてないから厄介
差分プログラミングとOOPが別物だと言う人間は始めて見たな。
これはどんな根拠なんだ？　誰か教えてくれ。

703 ：デフォルトの名無しさん：2010/10/12(火) 11:14:58

>>702
馬鹿な人間が考えることは、普通の人間には解らん。
まっ天才が考えることも普通の人間には解らんが。

704 ：デフォルトの名無しさん：2010/10/12(火) 12:06:09

>>702
差分プログラミングはあくまでOOPが広めた一要素でしかないのであって
OOP＝差分プログラミングでは無いんだが
何故かやたらと差分プログラミングのための継承を乱発する奴が居る

という意味だと思う

705 ：デフォルトの名無しさん：2010/10/12(火) 19:13:53

差分プログラミングの「差分」が、バリエーションを増やすことではなく単なる機能拡張を意味しているなら、
最近の考え方では誤りを含んでいる可能性が高いとされる。

706 ：705：2010/10/12(火) 19:15:54

継承で機能を増やそうとする前に、もう一個クラスを切って委譲することで解決できないか
考えてみた方が良いと思う。

707 ：デフォルトの名無しさん：2010/10/12(火) 19:32:54

馬鹿な人間が考えることは、普通の人間には解らん。

708 ：デフォルトの名無しさん：2010/10/12(火) 21:50:07

>A　→　Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB

設計は問題あるかもしれないけど
これって別に悪いことじゃないよね？

OOPというかカプセル化は上記のようにするのが目的だと思うんだが

709 ：デフォルトの名無しさん：2010/10/12(火) 22:20:31

>>704
その意味だと”区別”とは言わない。

710 ：デフォルトの名無しさん：2010/10/12(火) 22:29:33

OOPとしての話なら
同じ基本クラスAを継承したクラスBとクラスCがあったとして
クラスAが使われている部分を全部クラスBやクラスCに置き換えても正常に動作しなければならない

つまり多態を必要としていなければ継承は使うべきでない

711 ：デフォルトの名無しさん：2010/10/12(火) 23:29:43

>>708
クラス図を書いて見たけど、全然悪くないと思う。

例えばMVCのビジネスロジックDクラスがCクラスを管理して
そのCクラスをViewでコンポジションするなど普通に行なう。
Dクラスがスーパークラスを持っていてもおかしくないし
そのクラスが別のクラスを持つことも普通にある。

駄目だと言っている人間は本当に実践でOOPを使えているのか？

712 ：デフォルトの名無しさん：2010/10/12(火) 23:38:10

>>711
俺が何を駄目と言ったかちゃんと見た？
まあ、その文の様子だと見てないんだろうけど。

713 ：デフォルトの名無しさん：2010/10/12(火) 23:48:19

お前だれだよ

714 ：デフォルトの名無しさん：2010/10/12(火) 23:49:48

>>713
>>659です。

715 ：デフォルトの名無しさん：2010/10/12(火) 23:54:55

>>710
お前C++房だろう。OOPを勉強して出直せ
他の言語を知っている人間ならそんなバカなこと書かないぞ。

716 ：デフォルトの名無しさん：2010/10/12(火) 23:57:32

他人だがなぜそう思ったかさっぱり分からん

717 ：デフォルトの名無しさん：2010/10/13(水) 00:00:13

ポリモーフィズムって定義曖昧じゃね？

718 ：デフォルトの名無しさん：2010/10/13(水) 00:03:15

>>715
それ、単なるLSPじゃねーの

719 ：デフォルトの名無しさん：2010/10/13(水) 00:07:05

>>715 >>710 じゃないが, OO の定義をしてくれw
まじで OOP って声高にさわぐ奴って何なのよ?

理屈、説明しても分からない
要求仕様を渡しても自分の都合のいいように改変してくる
数式渡しても全然別のものを作ってくる

まともな頭もってる奴って OO って叫ばないぞ

720 ：デフォルトの名無しさん：2010/10/13(水) 00:11:12

>>714
659を読んだから実践でOOPが使えない人だと思ったけど。

721 ：デフォルトの名無しさん：2010/10/13(水) 00:12:41

>>719
OOは知らんが、OOPは言語によって形態が違うな。
共通してるのはカプセル化ぐらいだ。

722 ：デフォルトの名無しさん：2010/10/13(水) 00:18:02

>>720
本当かよww
一応言っとくけど、俺は>>711の、全く悪く無い、ってところ以外は同意してるぞ。
>>659もそれが前提になってるし。

723 ：デフォルトの名無しさん：2010/10/13(水) 00:18:54

継承なんて極力つかうべきじゃないよ

724 ：デフォルトの名無しさん：2010/10/13(水) 00:21:33

継承って可読性下げるよね。
メリットがないときは使わないほうがいいでしょう。

725 ：デフォルトの名無しさん：2010/10/13(水) 00:23:38

まあ、よく分からない物は使わない、は賢い判断だわな。
継承やらテンプレートやら。

726 ：デフォルトの名無しさん：2010/10/13(水) 00:41:19

>>721
そんなこと言ってるんじゃないんだな, これが…
たとえばの話なんだが,
MPEG シリーズってのは、規格書の書式含めて、ある意味 OO の産物なわけだ
これをふまえて, この規格書のここからここまでを何とかしたいとか言うわけ
で、連中、プログラム書いてくるんだが、
規格書に書いてあることに堂々と違反する
規格書中の数式を理解できないんだろうけど, アルゴリズムがおかしい
わかりやすく数式書き直してあげても数式通り動かない
でも, 「うちは OO してますから，大丈夫なはずです！！！」と声高に言う
つか、 OO ってやってるふりしてりゃ許してもらえる隠れみのになってるだろw

727 ：デフォルトの名無しさん：2010/10/13(水) 00:46:02

>>726
それOO以前の問題じゃねwww
プログラマに必要な技能が備わって無いwww

728 ：デフォルトの名無しさん：2010/10/13(水) 00:46:18

哲学者ウィトゲンシュタインは
「思考の限界は言語の限界」だと言っている。
まっ思考には非言語的要素もあるから、これが全て正しい訳じゃないが
しかし、ほとんどの思考は言語で考え、言語で表現する。

だからC++房は駄目なんだよ。C++言語の限界が思考の限界になっている。
C++に無い部分が理解出来ない。

729 ：デフォルトの名無しさん：2010/10/13(水) 00:52:17

>>727
そだよ！じゃなくって、
「OO してますって言えば世間が許してくれる」
と思う、その感性ってどぉよ？？？

730 ：デフォルトの名無しさん：2010/10/13(水) 00:55:06

>>729
そいつらはきっと、世間から無視されるだけだからほっとけ。

731 ：デフォルトの名無しさん：2010/10/13(水) 00:59:22

>>729
相手に仕様が伝わらないのは、お前の日本語が”変”だからじゃないのか。

732 ：デフォルトの名無しさん：2010/10/13(水) 01:02:22

>>731
>>726は、説明書が読めないやつが居る、って言ってるんだよ。

733 ：デフォルトの名無しさん：2010/10/13(水) 01:02:36

>>730
なんで日本語しゃべらんとあかんの？
数式読めないみたいだから、数式を高校生でも読める数式に書き換えただけなのに

734 ：733：2010/10/13(水) 01:12:17

すまん, アンカー間違えた >>731 だったわ

735 ：デフォルトの名無しさん：2010/10/13(水) 01:17:05

>>722
>なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。

>そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
>基本クラスのEを気にする必要は無い。
Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。

736 ：デフォルトの名無しさん：2010/10/13(水) 01:23:43

>>732
>説明書が読めないやつが居る、って言ってるんだよ。
説明書ｗ　お前が読めていない。

737 ：デフォルトの名無しさん：2010/10/13(水) 01:24:02

チューリング完全すら知らないやつがいる

738 ：デフォルトの名無しさん：2010/10/13(水) 01:25:24

>>733
>なんで日本語しゃべらんとあかんの？
何語で喋っているの？

739 ：デフォルトの名無しさん：2010/10/13(水) 01:35:27

>>735
＞そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
データの整合性ちゃんととれるのか？
そもそもそれはプログラム的に自然なのか？

＞Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
コンポジションを知らなかったので、wikipediaで調べた。
＞コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。
＞つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
Privateフィールド関係なくね？　というのは置いといても、
全く関係ないこと言ってないかこれ。

740 ：デフォルトの名無しさん：2010/10/13(水) 01:36:17

>>736
比喩も認めない頭の固い人か。

741 ：733：2010/10/13(水) 01:46:42

>>738
英語でもドイツ語でも… ってのは、さておき、本質は数式部分だから……
つか、おまえ、数式読めない可愛そうな人か？

742 ：デフォルトの名無しさん：2010/10/13(水) 02:17:35

>>739
>百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
603が正しく理解出来ていないのか？　管理しているのはDなんだから
Dが所有物CをAが参照(委譲)しているよ考えるだろう。
何をもって干渉やデータの整合性と言っているのか分からないが
オブジェクト指向はオブジェクト内で完結するように作るものだ。

>Privateフィールド関係なくね？　というのは置いといても、
>全く関係ないこと言ってないかこれ。
まぁコンポジションでも集約でもどちらでもいいんだが
Eが管理クラスだから生成・破棄を制御するのが普通だと思ってコンポジションにした。
俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。

>基本クラスのEを気にする必要は無い。
だからこれは間違い。

743 ：デフォルトの名無しさん：2010/10/13(水) 02:27:34

>>741
喋れるのは中国語か韓国語だと思ったよ。
>そだよ！じゃなくって、
そだよｗ

まぁこれ以外にもおかしな日本語いっぱい使っているし大丈夫かｗ

744 ：デフォルトの名無しさん：2010/10/13(水) 02:30:24

>>740
なぜそこで比喩を使う？　言い訳が苦しいなｗ

745 ：デフォルトの名無しさん：2010/10/13(水) 11:35:24

MVCに関しての質問です。

wikipediaのMVC項目、「MVCのシナリオ」で、下記の疑問をもちました。

・Vにイベントハンドらを関連付ける人はこのモデルの上位に当たるオブジェクトが担当する？
・Cはオブザーバー的な役割を持っている？
・VはMを参照として持っている？なのでVが直接Mからデータを参照するのだろうか？
・Cは入力のオブザーバー的な役割のようだが、出力は担当しないのだろうか？

記事の下部にありますシナリオですが、
私としては以下のように読み取りました。

1. ユーザがviewに入力を行う
2. viewからの入力により、Vに登録したcontrollerのイベントハンドラやコールバック等がよばれる。
3. controllerが必要に応じたmodelのメソッドを呼び、ステータスを更新する。
4. 3の結果を表示する為にviewがmodelから必要なデータを取得し出力する。

また、概念図では相互残照を行っているように見受けられます・・・。

746 ：デフォルトの名無しさん：2010/10/13(水) 11:56:59

疑問の詳細には答えないけど、wikipediaのMVCの項目は適当だから参考にしないほうがいいと思う
特にシナリオの部分は酷い、出典が書いてないオレオレ脚注とか付いてるレベルだよ
要出典タグつけたの俺だし

>また、概念図では相互残照を行っているように見受けられます・・・。
あの図はUMLではないし、Observerパターンがわかってれば別に変でもない

747 ：デフォルトの名無しさん：2010/10/13(水) 12:44:45

>>742
＞管理しているのはDなんだから
＞Dが所有物CをAが参照(委譲)しているよ考えるだろう。
ふーん。>>742はそう見ているのか。
まあ、実はどっちでもいいんだけどｗ

＞何をもって干渉やデータの整合性と言っているのか分からないが
え？　・・・え？
干渉はまだしも、データの整合性が分らないとな・・・？　お前それ本気で言ってる？　
どんなプログラムでも、二つ以上の別々の場所から参照されてるデータは、
データの整合性の問題が付きまとうものなんだがなあ・・・

＞俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
＞Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
ああ、そうか。　それだと直接管理することは出来ないな。
確かに、Eは気にする必要がある。
と言っても、protectedやpublicなメンバから管理することは出来るが。

で、これだとまた別の問題として、継承する意味はあるのか？と言うのはある。
委譲以上のメリットを見いだすなら、
protectedなメンバからそれなりに自由な管理が出来る、と言うのがメリットになるか。
直接管理するのと同じくらいの自由度でね。

・・・あとは、>>742の用語の理解度は大丈夫か？　と言うのは、まあ置いとこう。

748 ：デフォルトの名無しさん：2010/10/13(水) 13:23:39

>>746
レス、ありがとうございました。
あの記事は当てになりませんが・・・。

出直してまいります。

749 ：デフォルトの名無しさん：2010/10/13(水) 15:06:51

>>747
結局603を間違いじゃないと認めたな。
しかし、>>659は酷いな、お前Privateフィールドも分からないとは
オブジェクト指向でプログラム作ったことないだろう。

750 ：デフォルトの名無しさん：2010/10/13(水) 15:30:06

>>749
いや、半分だけだぞ？
つーか、お前プログラム実装したこと無いだろ？

751 ：デフォルトの名無しさん：2010/10/13(水) 19:35:55

protectedメンバとかpublicメンバとか言い出す時点で程度が知れるわけだが

752 ：デフォルトの名無しさん：2010/10/13(水) 20:40:52

議論の元になってる>>603はムよりマ向けの話題だな

設計は別に悪くないけど設計者(と開発体制)が悪い。

753 ：デフォルトの名無しさん：2010/10/13(水) 21:17:50

いつもの人だが、凄いスレが伸びてるな。バカが来たのかと思ったらやっぱり。
AとかBとかCとかDとか頭沸いてるんじゃね。マトモな会話しやがれ。

原文は、やりたいことが素直に書けないから嫌だ、そういってるだけだろ。
やりたいことってのはつまりは手続きで、まぁアルゴリズムや制御構造や関数の類だな。
それが素直にかけない・・・まぁ当たり前だわな。
だってOOPは制御構造をオブジェクト単位でぶつ切りにしてパッパラパーにしちゃうからな。
だから、その指摘自体は何も間違っちゃいないんだぜ？
よくそんなことでこんな長文合戦が続くもんだな。

754 ：デフォルトの名無しさん：2010/10/13(水) 21:24:27

まぁだからアレだな。何でもかんでも、なんせ全部のことをクラスという道具でやろうとするから、
こんなことになってるんだな。OOPもそうなんだけど、クラス云々言ったときに何目的ベースの話なのかが見え無いと言う。
ポリモとカプセル化と差分プロの話がごっちゃになって展開される。だから意味解らん。

もうね、構文わけときゃいいと思うよ。
カプセル化はカプセル化専用の構文なり機構なり作ってそれで固めると。
その固めたオブジェクトをどうコミュニケーションさせるかは、
また別の構文なり機構なりですると。

Unixだと、プログラムはプログラムで閉じてて、
それをシェルを使ってどう組み合わせるかはまた別の話だったりして。
だから解りやすいんだよ、設計するのも、こう言うところで会話するのも。
何使ってるかで目的が明確だから。

755 ：デフォルトの名無しさん：2010/10/13(水) 21:29:51

相変わらず例の彼は何が言いたいのかさっぱりだ。

756 ：デフォルトの名無しさん：2010/10/13(水) 21:29:59

だけど俺思うのね。
プログラムってのは、その名の通り、手続きのことだろ。
俺らそれ書きたいだけなのに、現状データやオブジェクトに振り回されているという。
この逆転劇はどこかで終わるんだろうけど、楽しみだね。

757 ：デフォルトの名無しさん：2010/10/13(水) 21:39:33

いつもの人だけど、俺も昔OOPに凝ってたころは割りとクドクド説明する派の人だったんだけど、
だんだんOOPに疑問を抱くようになってきて、そんで、やっぱ物中心の思考ってのは無いなーとか、
そんで、他との関係が物の性質を決めるんだって気づいてからは、
だんだん行間を飛ばすようになってきて、あーやっぱ「間」って大事なんだなぁって。
行と行の間には行間があって、それが行と行との関係で、そこに本当に言いたいことがあったりして。
だから段落って重要だよね。どういう構成になってるかで言いたい事が大体分かると言う。
日本語も面白くて、漢字をひらがなで繋いでいるのな。言うなら漢字がデータでひらがなが関数って。
こうやって人は成長して大人になっていくんだなぁって。仕事ってほとんど後片付けだしね。

758 ：デフォルトの名無しさん：2010/10/13(水) 21:41:07

日本語でおk

759 ：デフォルトの名無しさん：2010/10/13(水) 21:44:05

でもそう思わない？
漢字って一字一字が意味を持っていて、まるでOOPで言うところのオブジェクトみたい。
一方、ひらがなは一字一字には意味は無く、「いってきます」って流れて意味が出る。
まるで手続きみたいだ。

760 ：デフォルトの名無しさん：2010/10/13(水) 21:45:42

しかし、いつものことだけど、俺いいこと言うよなぁ。

761 ：デフォルトの名無しさん：2010/10/13(水) 21:55:46

OOPが駄目だってんなら対案をちゃんと出してほしいね
抽象的なことばかり言ってないでさ

762 ：デフォルトの名無しさん：2010/10/13(水) 22:24:14

マルチメソッドが良いんじゃないかって。
現状、大概のOOPが単一オブジェやクラスにメソッドがくくりついているから、
オブジェクトがメソッド(機能)を所有しているとかって変な感覚が沸いてくる。それが泥沼の原因なんだと思う。
だから、オブジェクトからメソッドを切り離してさ。
func( obj1, obj2 );
こんな感じで普通にかければ気持ちいいだろうと。
データにはただのデータでいてもらってさ。機能なんか持たずにね。
データやらオブジェクトやらをどう使うかは、型の作成者じゃなくて、利用者が決めるというね、Unixの思想ね。
ただ、カプセル化は必要だろうから、それ用の何らかの機構は必要だと思うけど。
なんかアクセス権とか適当につけて頑張ってって感じ。

763 ：デフォルトの名無しさん：2010/10/13(水) 22:30:27

>>757
わかったから行間を開けて段落を作れ馬鹿

764 ：デフォルトの名無しさん：2010/10/13(水) 22:32:40

オブジェクトは自分の型が何であるかは他に示すが、それ以上のことには関与しない。
関数は引数のオブジェクトの型情報を使ってどう処理するかをマルチメソッドする。
これは、whatとhowの分離で、とても有用。
昔からバカはwhatとhowの区別が解らないもんだと決まってて、whatで聞いてるのにhowで返してきたりする。
だから、whatとhowを分離することは、マトモになることへの第一歩かなぁと。
画像ファイルを見れば解るけど、ヘッダに「フォーマットが何か」が書いてあるだけで、「どう使うか」までは書いてないんだよね。
だから、展開用コードが内包されていたりはしないし、用途も使う人次第。
オナニーには使わないでくださいでは困るんだよ。そんなことは指定しないで欲しいんだよね。

765 ：デフォルトの名無しさん：2010/10/13(水) 22:37:05

で、オブジェクトの型情報なんだけど、何処においておくかって問題がある。
例えば、C++のvtableみたく、データの先頭にヘッダみたいに型情報をおいて置くのも一つの方法なんだけど、
それだとオフセットがずれるし、個人的にキモイ。データは単にデータであって欲しいんだよね。
だから、オブジェクトの型が何であるかは、ポインタや参照が覚えていれば良いと思う。
だから、32bit環境ではポインタや参照のサイズが実アドレスと型値で64bitになるね。
ちょうどC++のshared_ptrがそんな感じの実装になってて、ありかなぁと。

766 ：デフォルトの名無しさん：2010/10/13(水) 22:39:52

補足すると、ポインタや参照に代入が行われたタイミングで、型値も書き換わるのな。
struct pointer{ void *address, int type };
こんな感じかね。その辺は適当に。

767 ：デフォルトの名無しさん：2010/10/13(水) 22:42:19

あ、ごめん。
「,」→「;」
やっちった。これはかっこ悪いぞ俺。頑張れ。

768 ：デフォルトの名無しさん：2010/10/13(水) 22:48:35

>データにはただのデータ
クラスの粒度の違うだけな気がするな

単純にデータとして扱えるのは最初の方だけで
最終的にはOOPと同じような形になるんじゃないかな

769 ：デフォルトの名無しさん：2010/10/13(水) 22:49:45

で、今悩んでるのが、分割コンパイルしたときの型値の扱いについてなんだよね。
それから、型値のマルチメソッドへの最適化。
ポインターの宣言都度都度で変換テーブルを用意せにゃならん。
それも、他ポインターからの代入を洗いざらい全部調べて、組み合わせ爆発的にな。
コンパイル時にはユニークな型値を割り振っておいて、そっから最適化で詰めていくってのがやりやすそうなんだが、
動的にモジュールを読み込んだときはどうなるんだって。そこまで考えると盛り上がるなー。

770 ：デフォルトの名無しさん：2010/10/13(水) 22:55:31

>>768
そうはさせないような仕組みも考え中。
オブジェクトがこんがらがるのは、オブジェクト中に他のオブジェクトの参照を持ってたりするからで、
だから、そういうことはさせないようにしようと。
なんか、そういった依存関係は別の構文で何とかならんかと。
例えば、
relation( "なんかの関係", obj1, obj2 );
とすると、"なんかの関係"とobj1とobj2との間で関係が定義されて、
後で引っ張り出せるような何か。
データ構造にも抜本的にメスを入れたい

771 ：デフォルトの名無しさん：2010/10/13(水) 22:59:58

プロトタイプベースってことでいいのか

772 ：デフォルトの名無しさん：2010/10/13(水) 23:03:17

>>770
>"なんかの関係"とobj1とobj2
これもデリゲートで片がつくのでは？
デリゲートじゃだめな理由を聞きたいね

773 ：デフォルトの名無しさん：2010/10/13(水) 23:07:40

違うけど、近いものにはなるかもね。
それは、今ここで説明した理由ではなくて、
型と関数を同列に扱いたいと言う要望からだけど。
型は型だけど、関数はインスタンスだからね。
同列に扱うには、型とインスタンスの区別をなくす必要があって、
文法をどう纏め上げるか、どういう解釈、トリックにするか、悩み中。
ただ、C言語のノリが一つのヒントになると思ってる。
int i;
int func(){}
変数と関数は全然別物だけど、ただ、どちらも、
identifierを評価すると、前に書いてある型へ落とし込まれて評価されることには
変わりないんだよね。そこつかってなんかできんかと。

774 ：デフォルトの名無しさん：2010/10/13(水) 23:11:59

>>772
デリゲートは何処に保存しとくんだっていう。
でも実際迷ってんのよ。関係を別途保存しますってもうそれDBだし、それするなら、構造体とか・・。
関係を定義したんだから、関数に纏められんかとか。う～ん。
文法としては統一したいんだけど、用途としてはばらして置きたいという。

775 ：デフォルトの名無しさん：2010/10/13(水) 23:21:25

>>773
なんか関数型言語じみてきたな

>>774
>デリゲートは何処に保存しとくんだっていう。
>relation( "なんかの関係", obj1, obj2 );
このrelationを呼び出すとこで管理しとけばいいんじゃない

776 ：デフォルトの名無しさん：2010/10/13(水) 23:47:54

>>775
そそ、関数型言語風。だけど手続き型で、バリバリメモリやインスタンス意識した何か。
そういう中途半端な按配の妙な、しかし、妙にフィットして使いやすいC言語みたいな、そういう。

関係に関してなんだけど、関係を言語環境でサポートしたいんだよね。インデックスとかも割り振って高速に列挙できるような。
そういうの書くのもう面倒でしょ。逆参照がどうとか、一対多だとか。RDBに任せるったって、インピーダンスミスマッチするし。
リストとか配列とか、もう面倒だし、本質じゃないしなぁ。関係の一言で片付けたい。

C言語、あれ面白いんだよ。知ってのとおり、C言語って論理型が無いんだよね。
そのくせ、C言語の企画書みると、標準関数の～は～のとき真を返します、とかしれっと書いてあんのな。
でも文法上は論理型も真偽値も無いと言う。
プログラマも会話や企画書で真とか偽とか普通に使うのに、
でも文法上はそんなもんねーっつー。

俺もそういうのが作りたいなぁって。
型も関数もインスタンスも文法上区別はないし、組み合わせ爆発がないから文法もシンプルだし、
なんだけど、使ってる奴は、型とか関数とかインスタンスとか区別してるし、会話にも出てくるしっていう。
まさにミラクル。

777 ：デフォルトの名無しさん：2010/10/13(水) 23:52:37

論理的な文章が書けない奴が、どんな処理系を書くのか楽しみでならない。

778 ：デフォルトの名無しさん：2010/10/13(水) 23:52:45

そろそろ多態性の話にしないか。
まず多態性の対象はメソッドにいして（オブジェクトを後で）
実装方法はインターフェース・継承ぐらいから話そう。

最初はインターフェース・継承それぞれの利点・欠点ぐらいから。
俺的にはインターフェースしか使わないと言う奴はバカだと思う。
インターフェースは使うのは
結びつき弱いクラス同士のIFを揃える時ぐらいしか使わないのが正しい。

779 ：デフォルトの名無しさん：2010/10/13(水) 23:56:02

>>777
だから頃合見計らって次スレ立てよろしくな。キリ番だし。

780 ：デフォルトの名無しさん：2010/10/14(木) 00:01:45

>>778
日本語でおｋ

781 ：デフォルトの名無しさん：2010/10/14(木) 00:30:04

なんで論文の一本も挙げずに話そうとするわけ？ばかなの？しぬの？

782 ：デフォルトの名無しさん：2010/10/14(木) 00:37:38

読解不能だし、
～はバカだって言っといてその根拠は挙げないし、
～は正しいって言っといて、その根拠も挙げないし。
ばかなのしぬの。
でももう書き込まなくて良いからね。

783 ：デフォルトの名無しさん：2010/10/14(木) 00:41:01

いいからちんこはCLOSやれよ

784 ：デフォルトの名無しさん：2010/10/14(木) 01:04:56

>>776
何となくjavaしかやったことないとみた。

785 ：デフォルトの名無しさん：2010/10/14(木) 01:26:06

>>778
確かに、根拠もなくポリモはIFとか言っている奴はいるが
俺は無視している。

786 ：デフォルトの名無しさん：2010/10/14(木) 01:52:41

根拠もない程度の関係しかないならIFじゃね？
根拠のある関係があるなら継承が適切かも知れんけど。

787 ：デフォルトの名無しさん：2010/10/14(木) 19:58:29

>>776
レスを一通り読み直して見たけどうまくいかないと思うな

>データにはただのデータでいてもらってさ。機能なんか持たずにね。
>プセル化は必要だろうから、それ用の何らかの機構は必要
>relation( "なんかの関係", obj1, obj2 );

"なんかの関係"には関数が入るんだろうけど
カプセル化(情報隠蔽)してたら外からいじれない部分が出てきて破綻しそう
全部パブリックにしてるか単一の値しか持たないなら別だけど

788 ：デフォルトの名無しさん：2010/10/14(木) 21:17:35

>>787
カプセル化はするけど、アクセサを設けないとは言ってないぞ。
上手くいくかはわからないけど、失敗してもそれはそれで。
個人的にはC言語＋マルチメソッド＋テンプレート＋型推論程度で十分なんだが、
そういう言語って何故か無いんだよね。
使い勝手良いと思うんだがなぁ。
何で誰も作らんのだろう。当たり前すぎて面白くないんかね。
そういうまともな仕事よりは、皆やっぱ遊びたいんかね。
まー自分で言語作って普及させようと精力的に頑張るなんて、捻じ曲がったキチガイにしか出来ない行動力だし、
そういうところからまともな物はなかなか出てこないわなぁ。
必要に迫られて仕方なく作ったC言語とか、暇な先生がお遊びで作ったpythonとか、
コンピュータ関係無いところが元ネタのLISPとか、
そういうのだけが人気だもんなぁ。まぁpythonがあんままともとは思わんが。

789 ：デフォルトの名無しさん：2010/10/14(木) 21:24:50

こういうのがユーザ企業の担当者だったらデスマ確定だな。
要件を仕様化できず、その場の思いつきで「う～ん、思ってたのと違うんだなぁ」を
連発してプロジェクトを地獄に叩き落す。

790 ：デフォルトの名無しさん：2010/10/14(木) 21:32:08

自分の仕事の確保には役に立つんじゃね？
つまらーん　どうでもいい仕事をひきのばーし　某内閣みたいに

791 ：デフォルトの名無しさん：2010/10/14(木) 21:36:23

788には毎度感心する

792 ：デフォルトの名無しさん：2010/10/14(木) 21:41:13

よくこれだけ意味の通らない文章を書けるよな。

793 ：デフォルトの名無しさん：2010/10/14(木) 21:43:33

>>788
>カプセル化はするけど、アクセサを設けないとは言ってない
プライベートまでアクセスできてしまったら情報隠蔽にならないのでは？

794 ：デフォルトの名無しさん：2010/10/14(木) 22:02:18

整合性さえ取れれば問題なくね？

795 ：デフォルトの名無しさん：2010/10/14(木) 22:24:43

>>794
どうやって整合性を保つのかが不明

長くなってきたからもうまとめてしまうがいいかね

大事なのは関係(メッセージ)だという主張自体は
べつにおかしいことじゃないし、OOPに取り込んでいける(もしくは既にある)。

しかし「新しい言語、新しいパラダイム」を使うべきということなら

スレ違いです

796 ：デフォルトの名無しさん：2010/10/14(木) 22:40:30

いやだから、その構造体内での整合性が取れてればそれで良いんじゃないの？
直接アクセスさせずに、関数通してアクセスされればいいんでしょ。
別に普通ジャン。

797 ：デフォルトの名無しさん：2010/10/14(木) 22:43:55

あーあと、
メッセージが関係なんじゃなくて、メッセージングな。
その辺はアランケイ氏もメッセージングって言ってて、メッセージじゃないんだよね。
ほら、行動しなきゃ始まらないっていうじゃん。
だけど、アランケイ氏みたく、言ってることと行動がバラバラだったら意味無いんだがな。
あの人は不思議な人だなぁ。

798 ：デフォルトの名無しさん：2010/10/14(木) 22:49:45

だって、OOPで大事なのはメッセージング、媒体となるメッセージングこそが主題だって良い事言っといて、
そんで、オブジェクト指向って名前付けるんだぜ？メッセージング指向ってはっきり言えばいいのに。
しかも、LISPはもっとも偉大な言語だって言っといて、そのくせなぜかRuby贔屓。
京都大学に拾われてるのも意味解らん。
たしかに京都くさい思考回路の人だから、居心地いいだろうが。
なにか惜しい人って印象はあるね。ある意味バランス感覚は良いのかも知れんが。

799 ：デフォルトの名無しさん：2010/10/14(木) 22:51:50

ただ、メッセージング指向って名前付けてたら、
あ、それただのC言語じゃんってなって、
何の話題にもならずに埋没していたかも知れんが。
今となってはその方がよかったかもな。

800 ：733：2010/10/14(木) 23:44:17

>>798
メッセージングが大事なのはケイの oo だけだ（まぁ，言い過ぎだけど)
その他の oo 隠すことの方が大事だっただけだ(最近ちゃってるけど)

# 別の話だけど, 京都生まれの京都育ちなもんで,
# *京都くさい思考回路*ってのはすこし説明してほしいw

801 ：デフォルトの名無しさん：2010/10/14(木) 23:57:06

やっと彼の言動に感じる違和感が分かった。
プログラミング言語を論じる言葉が文芸評論的なんだな。
技術屋の言葉じゃない。

802 ：デフォルトの名無しさん：2010/10/15(金) 09:37:55

オブジェクトとオブジェクトの関係を考えるのがオブジェクト指向。

手続きと手続きの関係を考えるのが手続き指向。(フローチャート)
データとデータならデータ指向。(DFD)

オブジェクト同士の関係を考えるにあたって、
メッセージングとクラス図のどちらを重視するかで
大きく派閥が分かれるが、名前には大きな問題ない。

うん、今テキトーに考えた。

803 ：デフォルトの名無しさん：2010/10/15(金) 18:30:27

オブジェクト指向で作っていたが WIN32API のウィンドウプロシージャの switch( wParam ) case WM_...
case WM_.. case WM_... のスイッチの嵐と変わらなくなってる

804 ：デフォルトの名無しさん：2010/10/15(金) 18:53:42

そういう場面でこそ多態だろ

805 ：デフォルトの名無しさん：2010/10/15(金) 19:31:40

>>804
うん、たしかにそうなんだが、多態を使いまくるとデバックがつらくてね
結局のところ、処理ナンバーを一極集中管理することになった
というか、頭が追いつかない　orz

806 ：デフォルトの名無しさん：2010/10/15(金) 19:44:56

>>805
多態つかわねえでどうすんだよ。
こういう問題こそだろ。

デバッグが大変とかどんな組み方してんだよ。

807 ：デフォルトの名無しさん：2010/10/15(金) 20:52:29

>>801
ほら俺思想家だからw
ちなみ俺はでプログラマではないよ。全然違う仕事してる。

>>806
多態つかうと制御構造が見えづらくなるから、あえて使わず処理ナンバーで一括管理してるって言ってる奴に、
多態使えってそりゃ解決策になってねぇだろ。
ややこしい構造を嫌って、平べったくリスト構造で一括管理ってのは有りなんだよ。
箇条書きは技術者の良きお友達。

808 ：デフォルトの名無しさん：2010/10/15(金) 21:19:08

京都生まれの京都育ちの麻布卒
あ、東「京都」か

809 ：デフォルトの名無しさん：2010/10/15(金) 21:26:48

箇条書きよりはマインドマップの方がわかりやすいってマインドマップの本に書いてあった

810 ：デフォルトの名無しさん：2010/10/15(金) 21:31:37

>>808
まさかの同窓。。
とりあえず、あまり母校の名に泥を塗るような言動は止してくれ、頼むから。

811 ：デフォルトの名無しさん：2010/10/16(土) 04:29:02

>>807
> 処理ナンバーで一括管理してる
管理できなくなってるから困ってるんじゃねーの？

812 ：デフォルトの名無しさん：2010/10/16(土) 18:33:13

俺はそうとは読まなかったが。

とにかく、箇条書きは構造がシンプルだから、後々の応用が利いて良いんだよ。
その証拠にRDBも成功してるじゃん。Oracleとか自社の検定まで作って、ウハウハ。箇条書きすげぇって。
オブジェクト指向型のDBも有るけど、全然人気出なかったし。そんなもんだよ。

俺ら、もう良く知ってるわけよ。
テキストファイルで書いといてgrepしても良し、CSVで書いてエクセルで読み込んでも良し、
エクセルだったら、オートフィルタや関数やVBAも使えるし、あー便利便利。
ただ、かっこ悪い気がするっていう。

でも本当はかっこいいんだよ、箇条書き。
LinuxBoot時の山のようなinitには感動すら覚える。

813 ：デフォルトの名無しさん：2010/10/16(土) 19:59:52

>>812
そのための多態とファクトリーパターンだろ、死ねよ。

814 ：デフォルトの名無しさん：2010/10/16(土) 23:08:36

× 箇条書きは構造がシンプルだから、後々の応用が利いて良い
○ 箇条書きは構造がシンプルだから、バカでも理解できて良い

いや、わりと重要なことだけどな。世の中のみんなが天才ではないし。

815 ：デフォルトの名無しさん：2010/10/16(土) 23:16:09

OOP的な階層構造って、わかってる人が設計した物をわかってる人が読まない限りはスパゲッティにみえちゃうもんだからな

816 ：デフォルトの名無しさん：2010/10/16(土) 23:25:30

プログラマ以外でも書ける部分を箇条書きにしとけばいいって話しだろ
プログラマはOOP覚えろよ

817 ：デフォルトの名無しさん：2010/10/16(土) 23:54:57

なんか裸の王様っぽくなってきました

818 ：デフォルトの名無しさん：2010/10/16(土) 23:59:45

多態つかわないのに継承したり、
get/setだらけで実質ほとんどpublicフィールドになってたり
やたらややこしい事前条件を暗黙的に要求してきたり
何やってくれるのか全く想像できないメソッド名つけたり
やたらたくさんの機能を備えたクラスつくったり

そんなんするからOOPの可読性が悪いんじゃないかと勘違いする奴がでる

819 ：デフォルトの名無しさん：2010/10/17(日) 00:14:58

言語が許してるのが悪い

820 ：デフォルトの名無しさん：2010/10/17(日) 00:19:33

どう考えても使う奴の問題

821 ：デフォルトの名無しさん：2010/10/17(日) 00:25:22

>>817
まーわざと箇条書きとOOPを比較して、OOP派の人に無理に箇条書きを否定させる流れに持っていったからな。
そこは、「OOPも良いけど、箇条書きもいいね」って言えれば良かったのに、
それが出来ないのがOOP脳と言うかなんと言うか。。
2流なんだよ。俺が1流ってわけでもないがな。

822 ：デフォルトの名無しさん：2010/10/17(日) 00:27:14

あんまりそう言い出せる空気でもないだろここ

823 ：デフォルトの名無しさん：2010/10/17(日) 00:36:55

そもそも箇条書きで済むところと多態で済む所が同じとは限らん

824 ：デフォルトの名無しさん：2010/10/17(日) 00:49:33

そうなんだけど、そこはあえて比較させて、箇条書きを叩かせる方向へ持っていったのよ。
俺の悪知恵。

だけど、箇条書きって大概が箇条書きの箇条書きで2次元だから、
マトリックスになって、組み合わせが使えて、大概のことは出来るぞ。
A　○　×
B　○　○
C　×　○
こんな感じでさ。
プログラムで言ったら配列に相当して、
その強力さとシンプルさと道具としての奥深さは、皆理解しているところだろ？
これ否定するとか、天に向かって唾吐くようなものだわな。
あえて吐かさせといて言うのもなんだが。

825 ：デフォルトの名無しさん：2010/10/17(日) 00:52:51

あーごめん2次元って表現はおかしい罠。

826 ：デフォルトの名無しさん：2010/10/17(日) 00:57:47

箇条書きのスレ作って、そっちでやれ。

827 ：デフォルトの名無しさん：2010/10/17(日) 00:59:40

箇条書きって言うからイモいけどcsv, tsvとかいうとそうでもない
まぁcsvがいいか多態がいいかは状況によるよ

828 ：デフォルトの名無しさん：2010/10/17(日) 03:14:29

>>827
CSVやTSVじゃ構造化したデータを表現できねーだろ。
DBのテーブルならそんなんでもいいがな。

829 ：デフォルトの名無しさん：2010/10/17(日) 11:14:59

>>816
箇条書きで手に負えるような単純なもん作ってるうちはそれでいいが、
現代のプログラムはそれじゃおっつかない。だからOOPが必要、ってこったな。

例の彼はプログラマではないみたいだし、OOPが必要になるほど複雑度の高い
プログラムを書いたことがないんだろうな。
ワンライナー書いて「俺って天才ハッカーｗｗｗ」とか勘違いしてるタイプと想像。

あまり誰も言わんが、ワンライナーを賞賛する文化って、教育上有害だと思うんだよな。
ああいうのは、非実用的で実戦で使うのは有害な（だからこそ面白い）お遊びなんだ、
っていうのをもっと喧伝した方がいいと思う。

830 ：デフォルトの名無しさん：2010/10/17(日) 12:05:27

>>829
もちろん使い方次第だけど、ワンライナーが有害だとは思わないな。
書き捨てのスクリプト以外でワンライナー使うのは駄目。

831 ：デフォルトの名無しさん：2010/10/17(日) 12:46:47

是々非々じゃないレスはまず煽り

832 ：デフォルトの名無しさん：2010/10/17(日) 12:55:40

人によって理解力が違うんだから、ソースコードの意味を表すメタ情報が必要だと思うの
コードと仕様書から自動的にドキュメントを生成するのってない？
仕様はもちろんZ言語です

833 ：デフォルトの名無しさん：2010/10/17(日) 14:29:12

>>832
ScalaのSpecsみたいのとかはどうだ。テストケース＝仕様書。

834 ：デフォルトの名無しさん：2010/10/17(日) 14:54:43

おお、specsいいね

835 ：デフォルトの名無しさん：2010/10/17(日) 15:01:11

多態の良さは型switchを無くせることと、既存コードに手を加えずに拡張できる事であって
箇条書き云々とは全く関係ないと思うんだが

836 ：デフォルトの名無しさん：2010/10/17(日) 15:09:27

switchがなくせることがいいこと？

837 ：デフォルトの名無しさん：2010/10/17(日) 16:30:56

switchが不要になるのは結果として、だな。

838 ：デフォルトの名無しさん：2010/10/17(日) 16:43:46

処理対象が増えたら、全ての型switchに処理を追加してかなきゃいけない
継承すればそれが無くなる

839 ：デフォルトの名無しさん：2010/10/17(日) 22:48:20

>>838
継承じゃなくて多態だろ？

840 ：デフォルトの名無しさん：2010/10/17(日) 22:56:08

多態は形容であって、switchの分岐を増やすことでswitchで扱える型と処理の多様性を関係付ける行為は継承なんでは
おっぱお

841 ：デフォルトの名無しさん：2010/10/17(日) 23:22:59

継承は、親オブジェクトから性質を受け継ぐことを述べているに過ぎないだろ。
switchを消せるのは、同じインタフェースに対して別々のオブジェクトを作れることの恩恵に過ぎない。

842 ：デフォルトの名無しさん：2010/10/17(日) 23:23:25

いつもの人だけど、俺より日本語がヤバイってもうダメ。

843 ：デフォルトの名無しさん：2010/10/17(日) 23:58:30

一番いい日本語を頼む

844 ：デフォルトの名無しさん：2010/10/18(月) 00:06:15

そんな日本語で大丈夫か？

845 ：デフォルトの名無しさん：2010/10/18(月) 19:15:18

大丈夫だ、問題ない

846 ：デフォルトの名無しさん：2010/10/19(火) 18:30:09

>>843-845
こんなとこでやるなよw
気がつくまで時間かかるわ

847 ：デフォルトの名無しさん：2010/10/21(木) 12:39:10

ある日
俺「バカオヤジが片付けむちゃくちゃだから新しい棚買おうよ」
母「そうね、明日買いにいきましょう」
明日
俺「オヤジ　車貸してくれ」
父「おぅ、あそこの電気がつかんが・・・ちょっと電気の球とってこい」
俺「・・・」
父「ここの球がなぁ、前からつかん」
俺「・・・（無言で立ち去り部屋で布団に入りヌクヌクする）」
遠くから
父「あいたたたたた・・・ピー（糖尿病の血糖値を測る測定器の音）」
３０分後
母「お父さんが低糖になるからごはんあげてやって」
俺「・・・（メシをつぐ）」
父「（メシをうけとって）おい、電気買ってこいよ（ムシャクチャ）」
母「・・・」
俺「・・・」
俺「いつ棚買いに行く？（いつになったらこいつ死んでくれるだろう・・・）」

848 ：デフォルトの名無しさん：2010/10/21(木) 23:03:56

俺には難しすぎて意味がわからないが、
車持ってないお前が糞でFA？

849 ：デフォルトの名無しさん：2010/10/22(金) 16:17:45

兄が糞でＦＡのようだ

850 ：デフォルトの名無しさん：2010/10/25(月) 05:22:38

ツンデレですね！
デレ期はまだですか！

851 ：デフォルトの名無しさん：2010/10/25(月) 06:06:15

いいえ今日は月曜日です

852 ：デフォルトの名無しさん：2010/10/25(月) 06:13:31

俺を娘に変えると、とたんに・・・

853 ：デフォルトの名無しさん：2010/10/26(火) 11:16:16

ヤンキーデレのほうのヤンデレが連想された
ふしぎ！

854 ：デフォルトの名無しさん：2010/10/26(火) 23:22:25

でも良く考えたら、お前ら永遠の命って欲しいか？
死ぬことも出来ないってのもなかなか大変そうだ。
OOPや取り巻きのプログラマたちもそう思ったのだろう。
儚さ、刹那主義。滅びの美学。
縦割り構造。利権主義。お役所仕事。たらい回し。
とても日本的で良いじゃないか。

C言語は良すぎてダメだね。永遠に残るし。

855 ：デフォルトの名無しさん：2010/10/27(水) 13:56:02

すまん、永遠の命欲しい

856 ：デフォルトの名無しさん：2010/10/27(水) 15:37:26

コンストラクタでどこまで処理をするのが望ましいでしょうか？
クラスの機能を最低限満たせばよいですかね

857 ：デフォルトの名無しさん：2010/10/27(水) 16:39:31

そのクラスを使用できる状態に出来る最低限の初期化かねえ。
細かい設定はほかに持つのがすきかな。

でもコンストラクタで全て終わらせるのもそれはそれですきだけどな。

どういうのがいいのかねえ。

858 ：デフォルトの名無しさん：2010/10/27(水) 18:12:59

クラスの一通りの機能が使える状態にするところまで、かな。
生成したら基本的には、もう使える状態であるべきだと思う。

細かい設定もコンストラクタの引数でやるのが理想ではあるなあ。
作ったらもうほとんど弄る必要がなくて、役割上、本当に途中変更が必要な属性以外は
読み取りしかできないような感じにして、どうしても変更したいならオブジェクト作り直し。

…とはいえ、そういうワケにもいかんって場合もやっぱある。
その線引きは難しいところ。

でも最低限「生成しただけじゃ使い物にならない」ってのは避けたいかな。
出来れば生成しただけで一応使えるように、そうでなくても
生成→有効化、の2手順（有効にする前にやっておくべきことがあるクラスの場合）で一応使えるようにしておきたい。

859 ：デフォルトの名無しさん：2010/10/27(水) 18:20:24

何処で見たか忘れたけど、コンストラクタ内ではいろいろ処理を行わないことみないなやつ。
生成コストがどうのとか例外がどうのとかそんなないようだったきがするんだけど・・・。

こういう考えだと生成と各種変数の初期化くらい？
その後用途別の初期化メソッドを呼ぶのかね。

860 ：デフォルトの名無しさん：2010/10/27(水) 19:29:16

ファクトリ関数にすればいいんじゃね？

861 ：デフォルトの名無しさん：2010/10/27(水) 20:09:30

staticなメソッドで、目的別の生成用メソッドを持つってかんじ？
コンストラクタはprivateで隠蔽なのかな？

862 ：デフォルトの名無しさん：2010/10/27(水) 20:21:25

856です
ありがとうございました。

863 ：デフォルトの名無しさん：2010/10/27(水) 20:44:06

>>862バーローｗｗｗ

864 ：デフォルトの名無しさん：2010/10/27(水) 22:36:22

>>861
一部の言語では複数名称のコンストラクタを持てるから(Delphiとかそうだった希ガス)
そういう言語では単に各種用途のコンストラクタを用意する、になるのかな？

865 ：デフォルトの名無しさん：2010/10/28(木) 00:42:20

ほらもう、コンストラクタで何処までするか、こんなことに悩まなきゃならんなんて、時間の無駄だよなぁ。
コンストラクタって名前がダメなんだろうな、なにか特別な感じがして。
こんなのただの初期化用関数なんだから、深く考えるなよ。
init( &hoge );　だったら誰も悩まないのにな。
インスタンス確保したら勝手に初期化されてる、ってのは一見便利そうに感じるんだけど、
実際には引数を渡さなきゃならなかったり、完全に全自動ってわけにはいかないんだよな。
なんつーか、中途半端。別に初期化用関数方式でも構わないっちゃ構わない現状。
そのくせ言語レベルで組み込まれている仕組みだから、なにか活用しなきゃいけない気がして困る。
その点デストラクタは有用だな。とはいっても、GC無い言語だと意味半減だけど。
まーGCある言語だと、デストラクタ自体の意味が別の意味で半減して、これまたなんとも。
個人的にはコンストラクタもデストラクタも無いほうが良いと思っていて、
無くても問題ないように言語使用を練り直す方向が正しいと思ってる。
オブジェクト自身がコンストラクタやデストラクタを持ってるってのはガンだと思うから、
どこか別のところへ持ってくなり、なんらか別のトリックを用意するなり。

866 ：デフォルトの名無しさん：2010/10/28(木) 00:54:39

そんで、C++だと、暗黙の型変換までコンストラクタで賄うだろ。
初期化の仕組みで変換もするって、もうおかしいだろ。
そんで困って、コンストラクタでの暗黙の型変換を禁止するへんな予約語が追加されたんだっけか。
言語レベルで変な仕組み導入しまくって後で困ってるっていうね。
標準のIOストリームもそうだけどさ。色々やって、結局printf万歳だもんな。
バカの考え休むに似たりってか。あーC言語は平和だなぁ。

867 ：デフォルトの名無しさん：2010/10/28(木) 00:59:27

つーかコンストラクタってそんなに活用されてないよね。
大体はファクトリーパターンとか使うんだろ？
もうなんなんだろうね。
そもそも初期化ってのはそれなりに複合的な処理なんだよ。あっちゃこっちゃが相互作用で影響してくる。
そんな処理が単一のオブジェクトのしたにぶら下がってること事態おかしいっちゃおかしい。
だから、結局大したことできないっつーね。

868 ：デフォルトの名無しさん：2010/10/28(木) 01:26:55

どこまでって明らかにオブジェクトの初期化までだろ

869 ：デフォルトの名無しさん：2010/10/28(木) 03:03:59

あれの自作言語ではnew AddExpr(new IntExpr(4), new MulExpr(new IntExpr(4), new IntExpr(12)))
相当のことやると漏れるようにできてんのか。なる。

870 ：デフォルトの名無しさん：2010/10/28(木) 08:31:10

>>865
init( &hoge ); だと init() の管理は誰がやるんだ。

871 ：デフォルトの名無しさん：2010/10/28(木) 11:24:06

>>865
GCある言語だとデストラクタの扱いは微妙なんじゃなかったか
最近はusingやwithみたいに特定のスコープを抜けたときに処理するという仕様が多かったような

872 ：デフォルトの名無しさん：2010/10/28(木) 11:38:53

C#で「デストラクタ」と呼んでるものはファイナライザ
明示的ないしスコープから抜けた時に明に呼ばれるものがデストラクタで
参照が無くなってる場合に暗に呼ばれるものがファイナライザ

873 ：デフォルトの名無しさん：2010/10/28(木) 12:01:32

そうなるとDisposeは単なる事後処理メソッドの規約みたいなものでいいかいな？

874 ：デフォルトの名無しさん：2010/10/28(木) 13:15:01

「オブジェクト自身がコンストラクタを持っている」という時点でなんか勘違いしてるだろ

875 ：デフォルトの名無しさん：2010/10/28(木) 13:22:57

確かに。読む気しなかったがコンストラクタ持ってるのはクラスだよな。
プロトタイプベースでもオブジェクト自身はコンストラクタでは…ないよな？

876 ：デフォルトの名無しさん：2010/10/28(木) 13:24:23

オブジェクトが持ってるのは半分程度だな。

thisが使えない初期化リストは…オブジェクトのものと言い難いかもしれない。
いや、初期化リストはコンストラクタと呼ばないのかもしれない。
俺は俺が何をいってるのか、わからないのかもしれない。

877 ：デフォルトの名無しさん：2010/10/30(土) 18:31:12

いよいよ「OOPには2012年までのカレンダーしかない」が現実味を帯びてきたな。
って、今日はオカルトキャラで行こうかと思ったけど、無理だったいつもの人。

オブジェクト指向・・・オブジェクト・・・・オブジェクトって何？
二通り思い浮かぶ。
1．オブジェクト=モノ
だけど、物って言っちゃうと、アホっぽいというか。物指向って即物的というか。
それを素晴らしいアイデアのように言われても。なぁ。
2．オブジェクト=対象
対象って言うからには、何かの対象なわけで、じゃあ、オブジェクトは何の対象なの？って言われれば、
オブジェクトは処理の対象なわけで。
英語の文法を考えてもわかるけど、述語もなしに、対象だけポツンっと出てくることって無い訳で。
あくまで、処理側から目線で、自分の処理の対象はアレですって意味合いだから。
だから、オブジェクトがメソッド持ってて、自分のメンバメソッドの処理の対象は自分だから、
自分は自分のメソッドの対象で、すなわち自分は対象＝オブジェクトですってのは
何かふに落ちない。
自分は自分自身の持つ機能の対象だから、自分は対象です。ほらなんか変だ。

どっかでおかしいんだよね、OOP。
そのおかしさをずっと引きづってる。ウソが雪だるま式。掛け違えたボタン。

878 ：デフォルトの名無しさん：2010/10/30(土) 18:42:32

だからなんで論文一本も挙げずに自論をグダグダ言っちゃうわけ？
色々足りてないんでねーのもぅ

879 ：デフォルトの名無しさん：2010/10/30(土) 18:58:14

ドSだから。

880 ：デフォルトの名無しさん：2010/10/30(土) 20:04:58

といいますと、ＯＯＰに関する論文がござるようでぜひともそのＵＲＬを貼っていただけたらと思う次第でございます

881 ：デフォルトの名無しさん：2010/10/30(土) 22:56:19

>>877
オブジェクトひとつで完結するわけじゃないんだから
処理を呼び出される対象でいいじゃん

882 ：デフォルトの名無しさん：2010/10/31(日) 02:26:15

>>881
だったらそれは、C言語だよ。

883 ：デフォルトの名無しさん：2010/10/31(日) 09:37:34

対象を最初に書くからオブジェクト指向、って言い方も聞いたことあるな

884 ：デフォルトの名無しさん：2010/10/31(日) 12:18:44

アホっぽくて良いね

885 ：デフォルトの名無しさん：2010/10/31(日) 12:28:47

過去からの経験の蓄積を元にした、現在のオブジェクト指向の実践が既にあるのに、
いまさら「オブジェクト」っていう言葉の定義を云々して何がしたいんだ？

886 ：デフォルトの名無しさん：2010/10/31(日) 12:43:03

いまさら、という言葉をチョイスする時点で。

887 ：デフォルトの名無しさん：2010/10/31(日) 12:57:10

OOPの進化(bugfix)は未だ衰えずということだ

888 ：デフォルトの名無しさん：2010/10/31(日) 13:14:52

このさい何がオブジェクトかなんてどうでも良くって
ちゃんとカプセル化したら依存関係が整理できて再利用しやすくなるという事実のみが大事

889 ：デフォルトの名無しさん：2010/10/31(日) 13:28:31

>>888
同意。とにかく、整理は全てのプログラマの恩恵となる。
KISSの次はOOP。

890 ：デフォルトの名無しさん：2010/10/31(日) 13:31:18

じゃあカプセル化って何？ってなる
依存関係が整理できて再利用しやすくする事そのものがカプセル化ですか？

891 ：デフォルトの名無しさん：2010/10/31(日) 13:35:31

カプセル化は内部状態を公開しないこと
依存関係の切り離しそれそのもの

892 ：デフォルトの名無しさん：2010/10/31(日) 14:45:12

内部状態を公開しないことと、
依存関係の切り離しは何の関係も無いだろ。
たしかに内部状態と外は切り離されるが、その代わりメソッドが依存するだろ。

893 ：デフォルトの名無しさん：2010/10/31(日) 14:50:32

それから、カプセル化とOOPは関係ないと思うんだよね。
だって、C言語でも普通にするでしょ、カプセル化。
ハンドルとかで対象物を抽象化するわけな。
だけど、対象物を抽象化したからって、オブジェクト指向ってわけでは無いよな。

894 ：デフォルトの名無しさん：2010/10/31(日) 14:52:52

その理屈で行くと多態もOOPと関係ないな
Cや関数型言語でも多態できるしな

895 ：デフォルトの名無しさん：2010/10/31(日) 14:53:40

OOPってやっぱオブジェクトやクラスがメソッド抱えててってイメージがある。
だけど、マルチメソッドになると、メソッドはグローバル空間に行っちゃう。
だからより一層OOPって何なのって話になる。本当は無いんじゃないか？そんなもの初めから。

896 ：デフォルトの名無しさん：2010/10/31(日) 14:56:26

>>894
実際関係ないと思うよ。
だってマルチメソッドだと、クラスやオブジェクトがメソッド抱えてるって感じじゃないし。
要は動的オーバーロードだし。

897 ：デフォルトの名無しさん：2010/10/31(日) 15:00:40

だからオブジェクトが何かなんてこのさいどうでも良いと教えてやったのになんでまたそこに戻るんだ。
そんな曖昧な物いくら考えても有益なことなんて一つも出ないぞ。

898 ：デフォルトの名無しさん：2010/10/31(日) 15:02:04

いや、OOPがまるで実体の無いペテンだってことが解るじゃん。

899 ：デフォルトの名無しさん：2010/10/31(日) 15:02:41

>>892
内部状態は全て自分のメソッドからのみ変更される。
これで依存関係が切れてなかったらそれは単なる設計ミス
内部状態が内部状態になってない。

900 ：デフォルトの名無しさん：2010/10/31(日) 15:06:23

だから、そのメソッドが外部と依存するだろ。
依存関係が切り離されてるんじゃなくて、
実装とインターフェースが切り離されてるだけだ。

901 ：デフォルトの名無しさん：2010/10/31(日) 15:08:18

そして、実装とインターフェースが切り離されていることと、再利用性は何の関係も無い。

902 ：デフォルトの名無しさん：2010/10/31(日) 15:12:48

自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。

外部状態がどうなってるかを気にせず、
「この内部状態の時にこのメソッドが呼ばれたらこの内部状態に変わる」
という一貫した普遍性を維持するためのカプセル化だし
これを依存関係が切れてると言う。

903 ：デフォルトの名無しさん：2010/10/31(日) 15:19:05

何言ってるんだ？
自分のメソッドと、自分以外の他オブジェクトは、
たとえカプセル化しても、メソッドを通じて依存しあってることには変わりない。

>自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。
逆逆。
実装とインターフェースを分離することで、自分のメソッド(というかインターフェース)と内部状態(というか実装)を
依存「しない」ようにするのがOOPだろJK。

>これを依存関係が切れてると言う。(ｷﾘｯ
聞いたこともない。OOPを支持する人って、やっぱこのレベルなんだな。

904 ：デフォルトの名無しさん：2010/10/31(日) 15:22:42

>>903
依存しあってる？
使う側は使われる側の挙動に依存してるかもしれんが
使われる側は使う側の事情なんて何も気にせず、与えられた機能を実行するだけだぞ。

ライブラリの挙動がアプリの実装に依存するわけ無いだろ馬鹿か

905 ：デフォルトの名無しさん：2010/10/31(日) 15:22:57

カプセル化して内部の整合性を取ることを、依存関係が切れてるって表現するの、
本当に聞いたことがない。悪いが。

906 ：デフォルトの名無しさん：2010/10/31(日) 15:24:48

まあ確かに依存しあってるって表現はまずかったな。依存しているが正解。

907 ：デフォルトの名無しさん：2010/10/31(日) 15:32:12

つまり、内部状態をもつということはそれ以外の外部の状態は気にしなくてよくなるわけだ。
気にしなくてよくなるから、そのクラスの実装に関して依存関係はない。
で、その内部状態はカプセル化によって実現している。

908 ：デフォルトの名無しさん：2010/10/31(日) 15:41:19

内部状態を持つ(というか、内部状態をプライベートにして外から見えなくする)ことは、
外から内部の実装を気にしなくても良くなる、というだけで、
内部から外の状態を気にしなくても良いと言うことにはならない。

なんか全て反対言うよな。頭おかしい。

909 ：デフォルトの名無しさん：2010/10/31(日) 15:44:43

内部から外の状態をどうやって気にするんだ。
誰が自分を使うかもわからんのに。

910 ：デフォルトの名無しさん：2010/10/31(日) 15:46:24

シングルトンやグローバル変数にアクセスすることはありうる。
良くないコードだが、ありうる。有りうるんだよ。

911 ：デフォルトの名無しさん：2010/10/31(日) 15:47:37

そんな特殊ケースの話されましても

912 ：デフォルトの名無しさん：2010/10/31(日) 15:49:49

だいたい、カプセル化って、外から中を見えなくするものって、普通そう考える。
中から外を見えなくするって発想は、その発想がありえん。考え方や物事の組み立て方がおかしいとしか。
そんな思考回路搭載してて設計なんぞできるんかねぇ。

913 ：デフォルトの名無しさん：2010/10/31(日) 15:49:57

あるクラスA内部で外のある状態Bを気にするっつう状況があるなら
その状態Bに対して責務を持つクラスCが存在するという仮定においてAからCへの依存関係が存在するので･･･
どういうことになるんだろう？

914 ：デフォルトの名無しさん：2010/10/31(日) 15:54:41

あー責務君の相手はしてはならないんだった。リアルな人だからな。

915 ：デフォルトの名無しさん：2010/10/31(日) 15:55:45

外から中が見えないってのは、単にアクセシビリティの話であって
それはビジビリティとは微妙に違うからな。

916 ：デフォルトの名無しさん：2010/10/31(日) 15:59:47

微妙にってどう違うのか

917 ：デフォルトの名無しさん：2010/10/31(日) 16:02:59

だけど、どうであれ、カプセル化って中を見えなくするものだから。

918 ：デフォルトの名無しさん：2010/10/31(日) 16:29:29

別に、外から内部の実装を気にしなくてもよくなる、というのを否定してるわけじゃない。
いくらカプセル化しても、外から間接的に内部状態見てるというのは変わらんけどね。
なんらかの挙動を期待してるわけだから、あたりまえだけど。

カプセル化について本質的に不可視にできるのは、中から外だけ。
もちろん、それを破る実装はいくらでもできるし
破る必要が出てくる場合もあるのもわかるよ。

でも、外の状態を一切気にせず
粛々と自分の内部状態に依存した振る舞いだけをするクラス作ったほうが
実装がシンプルになって再利用もしやすくなるよ。

つまり外部状態に依存しないんだから、どんな外部状態でも使えるってことだ。
何かの機能を切り分けたいと思ったときの粒度を考える参考にしてくれ。

919 ：デフォルトの名無しさん：2010/10/31(日) 16:33:55

う～んそうだね、
class A
{
private:
　　int private_member;
public:
　　void method( B *b ){ b->member=1; }
};
これだと、クラスAは、カプセル化されてはいるけど、クラスBの実装に依存している。
だから、カプセル化したからって、外部のことを気にしなくて良いかと言うと、そうでもない。
あくまで外から中のことを気にしなくて良くなるだけ。

920 ：デフォルトの名無しさん：2010/10/31(日) 16:36:49

>カプセル化について本質的に不可視にできるのは、中から外だけ。
だからそれはカプセル化とは言わん。

921 ：デフォルトの名無しさん：2010/10/31(日) 16:37:41

外から中の事を気にしないといけないコードなんて書こうとおもえばいくらでもかけるので
わざわざ依存関係が問題になりそうなコード持ち出してあーだこーだ言われても別に

922 ：デフォルトの名無しさん：2010/10/31(日) 16:38:43

カプセル化：外から中を気にしなくていい。
自己完結化：外のクラスを知らない、使われ方にいかなる想定をも置かない、外に左右されない、便利。

923 ：デフォルトの名無しさん：2010/10/31(日) 16:42:07

だから、カプセル化の意味を間違ってるんだって。
http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
勉強しなおせ。
あくまで、インターフェースと実装の分離のことをカプセル化って言うんだ。
外に対して隠蔽することをカプセル化って言うんだ。
外の状態がどうとかって話じゃないから。

924 ：デフォルトの名無しさん：2010/10/31(日) 16:49:57

まあ別に言葉の定義にこだわってるわけじゃないから、それはどうでもいいんだけどね。
そんなんで設計できるのと言われたら、そっちの方が便利だよって話で。

925 ：デフォルトの名無しさん：2010/10/31(日) 16:57:44

自己完結ってことは共通で使う関数や定数すら使わないのか

926 ：デフォルトの名無しさん：2010/10/31(日) 17:00:55

使わないように切り分けると良いよ。
ラムダ欲しくなるね。

927 ：デフォルトの名無しさん：2010/10/31(日) 20:41:21

>>925
自己完結なのは自分以外のステータスを意識しないで使える物じゃねえか？
状態を維持しない関数はもはや定数に等しいわけだからね。

928 ：デフォルトの名無しさん：2010/10/31(日) 20:53:47

まぁ、もし他のオブジェクトに対する依存関係が必要になるなら、
何らかの作法に従って、そのことを明示するようにすればいい。

典型的な委譲だが、

public class MyServiceImpl implements MyService {
　public MyServiceImpl(A a, B b, C c) { }
　...
}

その実装が依存する他のオブジェクトはコンストラクタで受け取るようにする、
と決めれば、その実装が、他のどんな実装に依存しているか分かりやすくなる。
もちろん、A, B, Cはインタフェースね。

翻って、グローバル変数やシングルトンが良くない理由でもある。
依存関係の存在を不可視にするからね。

929 ：デフォルトの名無しさん：2010/10/31(日) 21:43:17

なるほど

930 ：デフォルトの名無しさん：2010/11/01(月) 12:45:51

>>895
「クラスベースOOPL」がOOPなんじゃないからね。
OOP自体にはクラスは関係ないし、OOPLでなくてもOOPは出来る。
OOPLと非OOPLには、それを実装するのに都合が良いかの違いがあるだけ。

クラスは、OOPを実現するために都合の良い機能の1つで
そう言った「OOPを実現するのに都合の良い機能」を
多く言語仕様に取り入れたのがOOPL。

マルチメソッドだとメソッドはグローバル空間に行っちゃうんだけど
多態や継承というOOPの機能を実現する上ではさして問題はないよ。
そのオブジェクトに対応した定義がなきゃ拒否されるだけ。
カプセル化には多少影響有るかもしんないけどね。

931 ：デフォルトの名無しさん：2010/11/01(月) 18:39:26

ドメイン駆動設計の立場からの解説
http://d.hatena.ne.jp/digitalsoul/20101027/1288180208

932 ：733：2010/11/02(火) 06:17:45

>>931 数式書けない奴の言い訳にしか見えん

933 ：デフォルトの名無しさん：2010/11/03(水) 01:01:38

これ本当にひどいな。回りくどい上に解りにくくて、結局何も言ってないっていう。
アホだね。無視無視。こういうペテンが増えたのもOOPの負の一面だよな。
OOP自体が曖昧だから、何言ってもかまわいやしないってか。
近寄らないこったな。時間の無駄。

934 ：デフォルトの名無しさん：2010/11/03(水) 07:58:14

おまえが馬鹿でいるだけなら他人には迷惑かからんからな

935 ：デフォルトの名無しさん：2010/11/03(水) 08:43:20

しかしながら人は生きているだけで周りに迷惑を掛けているのです

936 ：デフォルトの名無しさん：2010/11/03(水) 09:43:11

>>931
良し悪しはおいといて
OOPと関係なさそうだね、これ

937 ：デフォルトの名無しさん：2010/11/03(水) 13:21:46

「P」とは関係ないかもな。

938 ：デフォルトの名無しさん：2010/11/03(水) 13:38:38

OO とも全然関係ないね, 脳みその作りを疑うわw

939 ：デフォルトの名無しさん：2010/11/03(水) 14:54:12

>>938
ドメイン知識を実装に落とす方法としてオブジェクト指向は有効だ、なぜなら、
って丁寧に書いてあるじゃん。

940 ：デフォルトの名無しさん：2010/11/03(水) 15:20:51

windowsAPIみたいなグローバル関数の呼び出しってどうしてますか？

941 ：デフォルトの名無しさん：2010/11/03(水) 15:30:35

直接使わずにクラスにラップする
ほら大抵セットで呼び出すようになってるし

942 ：936：2010/11/03(水) 18:06:26

スレを読み返して気づいたんだが
>>931が読んでほしかったのは
「オブジェクトとは？」の部分だったんだな

適当なことを言ってしまって申し訳ない

943 ：デフォルトの名無しさん：2010/11/03(水) 19:41:34

グローバル嫌って数学関数までクラスメソッドにするのはどうかと思う
静的メソッド使うんならともかく

944 ：デフォルトの名無しさん：2010/11/03(水) 19:42:08

動けばいい

945 ：デフォルトの名無しさん：2010/11/03(水) 20:12:26

例えばウインドウクラスを作った場合、
コンストラクタでパラメータ受け取ってCreateWindow呼び出してハンドルを保持する？
でウインドウクラスを操作するクラスはウインドウハンドルを貰えばいいのかクラスごと貰えば良いのか、、、

946 ：デフォルトの名無しさん：2010/11/03(水) 20:22:50

最終的にはWHND経由しないといけないから、なんか困るよなあれ。
抽象的に、自前クラスでラップして…でもやっぱWHNDむき出しにしたほうがラク。

947 ：デフォルトの名無しさん：2010/11/03(水) 20:38:19

ウィンドウクラスだって。アホ草。

948 ：デフォルトの名無しさん：2010/11/03(水) 21:19:18

>>943
OOPLの多くは数学関数を専門に扱うわけではないから
・Mathと示すことで数学関数であることが明確になる
・他でその識別名をまだ使うことができるようになる

949 ：デフォルトの名無しさん：2010/11/03(水) 21:27:57

>>947
例えばっつってんだろうが

950 ：デフォルトの名無しさん：2010/11/03(水) 22:34:02

例えってのは抽象的な表現を具体的な事例にすることで理解を助けるものであって、理解を与えるものじゃない

951 ：デフォルトの名無しさん：2010/11/06(土) 14:21:01

具体的な事例をあげられないなら、
それは使い物にならないということでしょう。

952 ：デフォルトの名無しさん：2010/11/06(土) 18:33:00

抽象的な表現ができないなら、
それは応用できないということなんではないでしょうか

953 ：デフォルトの名無しさん：2010/11/06(土) 19:34:23

やっぱり二つで一つなんだな

954 ：デフォルトの名無しさん：2010/11/06(土) 20:02:38

A is applicable to B.
A is abstract.

英語のことはよくわからんが、abstractって言うとかっこいいのか？

955 ：デフォルトの名無しさん：2010/11/06(土) 21:28:43

どうでもいいじゃん。
それより、950は次スレが必要かどうか考えるほうが先だな。
何故かいつも立ててくれてる人は、誰だか知らないけど、乙なんだけど、
OOPへの善意なのか悪意なのかはわからんよな。

956 ：デフォルトの名無しさん：2010/11/07(日) 00:03:13

文士様のOOPへの憤りがマックスに達した時にスレは降臨なさいます。

957 ：デフォルトの名無しさん：2010/11/07(日) 17:31:04

ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか

958 ：デフォルトの名無しさん：2010/11/07(日) 17:40:48

場合による

959 ：デフォルトの名無しさん：2010/11/07(日) 17:51:05

>>958
判断基準は？

960 ：デフォルトの名無しさん：2010/11/07(日) 18:00:26

>>959
基準というのは、その時その時の状況が基準になり、それから判断される。
だから、状況を出してもらわない事には、基準としての判断が不可。

961 ：デフォルトの名無しさん：2010/11/07(日) 23:46:58

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
クラスフィールドやクラスメソッドを使うのか？

962 ：デフォルトの名無しさん：2010/11/08(月) 15:06:55

>>961
そうです

963 ：デフォルトの名無しさん：2010/11/08(月) 18:07:26

ほらまたこんなことで悩まなきゃいけないのがOOP。
仕事の押し付け合い。
利権の奪い合い。
どこの縦割行政だよ。

人間は生活のためにそういうのがあるのは分かるけど、
コンピュータにそれいるか？ってな。

コンピュータはやっぱアメリカ主導だし、
アメリカは何でも横のつながりが強い機能主義だよ。

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
どこで処理するかって？
処理は関数でするもんだ。
処理がクラス間をまたいでるんだろ？
だったら外でしろよ。それが完結かつ明快。

964 ：デフォルトの名無しさん：2010/11/08(月) 18:23:31

まず、俺らが扱う所謂コンピュータって呼ばれてるものの構造を良く考えてみよう。
電卓と何が違う？
1.膨大なメモリがある。
　ゆえにメモリを管理する必要がある→構造体、malloc等。
2.制御をプログラミングできる。
　ゆえに制御構造を構築する必要がある→if文、for文、関数等。
そんで、この1と2は本質的に別物の、別次元の問題だということ。
だから別々に取り扱う必要がある。
一緒くたに扱おうとする、例えば、データと制御を紐付けるなど、
し始めると、どこかで矛盾が出てきて、上手くいかなくなってくる。
最初は良くても、どっかでしんどくなる。
「行ける」と思っても、実は「行けない」道だったんだよOOPは。
データ構造はwhatの意味合いが強いし、
制御構造はhowの意味合いが強い。
whatで質問してhowで返答したら、即バカのレッテルを貼られる。
whatとhowを分けて考えられるかどうかは、バカと常人を分ける有名な垣根。

965 ：デフォルトの名無しさん：2010/11/08(月) 18:36:48

それでも、ポリモやカプセル化は強く要望される。それは解る。
だけど、でも、別にクラスやオブジェクトに頼った仕組みでそれを実現しなきゃならないって事はないんだろ？
カプセル化は最重要項目でもあるんだから、それ専用の構文を用意したって構わないだろうし、
ポリモだって動的オーバーロード(マルチメソッド)でも構わない。
問題は、そういう手軽な言語が無いこと。あってもメジャーじゃないこと。
マイクロソフトとかそいういう影響力があるところが頑張ってくれれば良いんだが、
C++広めて、こんどはJavaパクってC#作ってるような所だから、期待するだけ無駄か。
生産性の高いものを提供するより、一件良さそうに見えて、実は罠だらけなものを
押し付けたほうが、ベンダー的にはユーザを囲い込めてウマーだしな。本も売れるし。
てか、マイクロソフトってそういう罠をよく仕込むよね。おー怖い怖い。
Sunは多分天然。D言語の奴らは沸いてるし、Lispの人たちは折れてくれない。
Cの人たちは満足して思考停止状態、さぁどうする。

966 ：デフォルトの名無しさん：2010/11/08(月) 19:24:35

さぁどうするとか書いちゃったけど、忘れてた。Oracleだよ、Oracle。
あっこがDBシームレスな手続き型言語作れば良い。
DBは好きだが、SQLは今となっては拡張拡張でワケワカランことになりつつあるし、
その辺含めて、DBシームレスなC言語風手続き型言語をさ。
インピーダンスミスマッチの問題も解決するし、
トランザクショナルメモリで、マルチスレッドの同期やデッドロックの問題を根こそぎ解決できる可能性すらある。
かなり手堅い仕事するし、必要なものが何か良く解ってる会社だから、期待してるんだがなー。
もしかして俺が知らないだけで、もうあるんだろうか。
業界人じゃないから最近のことは良くわからん。

967 ：デフォルトの名無しさん：2010/11/08(月) 19:48:56

どこのコピペ？
単体で動かすのは簡単でも保守と利用が難しくなるスパゲティコードは最近はやらないよ
linuxがモノリシックカーネルを捨て去った様にね

968 ：デフォルトの名無しさん：2010/11/08(月) 19:58:45

よく分からないって自覚があるのに批判できるとか凄いな。

969 ：デフォルトの名無しさん：2010/11/08(月) 20:56:06

保守や再利用どころか碌にコード書いた経験がない人だから、
まあわからんのも無理は無い。

970 ：デフォルトの名無しさん：2010/11/08(月) 22:18:22

いつもの人はもうあきらめて、データ(とアクセサ)だけ持ってるクラスと
メソッドだけ持ってるクラスでも作ってそれで我慢しろよ

971 ：デフォルトの名無しさん：2010/11/08(月) 23:31:14

>>962
なぜオブジェクトで操作しないのかがわからないけど

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
その処理で変更されるフィールドがある方でいいのでは。
２以上のクラス・フィールドが変更される場合はマスターデータに近い方で処理するとか。
基本、自分自身のフィールドは自分で変更した方がいいと思う。
まっフラグや状態などトランザクション系のフィールドは別で処理して戻り値を設定してもいいと思うけど。

データを基準に判断したら。

972 ：デフォルトの名無しさん：2010/11/09(火) 06:40:56

>1.膨大なメモリがある。
>　ゆえにメモリを管理する必要がある→構造体、malloc等。

で、もうダメだなこの人って思った。構造体は趣旨に則ってて良いんだが
膨大なメモリがあるなら、なおさらメモリ管理は極限まで抽象化しないとダメで
mallocなんてもってのほかだろ…w

973 ：デフォルトの名無しさん：2010/11/09(火) 11:05:04

管理って具体的になんだ？
メモリの一部の空間に名前を付けてアクセスしやすくすることも管理なのか？

974 ：デフォルトの名無しさん：2010/11/09(火) 22:39:15

>>964 アホだよなおまえ、アホだと言ってくれ、頼むから…

975 ：デフォルトの名無しさん：2010/11/09(火) 23:04:27

まーちょっと説明が回りくどすぎたかな。
もっと平たく言うと、
mallocや構造体などは、メモリを操作するための仕組み。
if文や関数などは、プログラムカウンタを操作するための仕組み。
それぞれ別々のディバイスを対象としている。
メモリとプログラムカウンタは、独立して存在しているので、
「mallocや構造体など」と「if文や関数など」も、
独立した概念で存在する必要がある。
だって、もともと独立したディバイスを操作するためのものだから。
車で言えば、もしハンドルとアクセルがくっついていたら困るだろう。
それぞれ別々に操作したいはず。それと同じこと。

976 ：デフォルトの名無しさん：2010/11/09(火) 23:08:54

逆に言えば、
mallocと構造体を統合したり、
if文と関数を統合したり、
は、問題ない。
元々同じディバイスを操作するものなんだから、
それら同士であれば、統合できるのなら統合しても良い訳だ。
簡単簡単。わかってしまえば簡単な話だな。
しかし、知らないと罠にはまる。

977 ：デフォルトの名無しさん：2010/11/09(火) 23:18:42

となると、丁度いいところで分けようと思うと、
自然とマルチメソッドということになる。
構造体はメモリ操作を担当。
関数はプログラムカウンタ操作を担当するってんだから、
関数呼び出し側に、引数の構造体のwhatに基づく分岐を統合して、
マルチメソッドとするのが自然。
単一ディスパッチのOOPでは、
構造体やオブジェクトにポリモと称する分岐の機構を持たせたから可笑しくなった。
あくまで関数側に持たせるべき。

978 ：デフォルトの名無しさん：2010/11/09(火) 23:21:45

>>970
メソッドだけ持ってるクラスの名前は、「please」にしたら洒落てて面白いと思うんだ。
please method obj1 obj2

979 ：デフォルトの名無しさん：2010/11/10(水) 00:27:58

>>975-977
最近のグリッド指向とかクラウドとかディスってんの？
屋上に行こうか

980 ：デフォルトの名無しさん：2010/11/10(水) 00:36:55

>>979
無知ってほんとに恐ろしいよな…。

981 ：デフォルトの名無しさん：2010/11/10(水) 00:52:18

>>976
ふむ、
Expr*expr = new AddExpr(new IntExpr(3), new DoubleExpr(5.4));
double ans = expr->calc();
delete expr;
の実装は
sturct Expr*expr = Expr_Add_malloc_and_init(Expr_Int_malloc_and_init(3), Expr_Double_malloc_and_init(5.4));
double ans = ((double(*)(struct Expr*))expr->vtbl[EXPR_CALC])(expr);
((void(*)(struct Expr*))expr->vtbl[EXPR_DTOR])(expr);
ではなく、
struct Expr*expr = Expr_Add_malloc_and_init(Expr_Int_malloc_and_init(3), Expr_Double_malloc_and_init(5.4));
double ans = Expr_Calc[expr->id](expr);
Expr_Dtor[expr->id](expr);
であるべきと？

『C++の設計と進化』の爪の垢でも煎じて飲めとしか。

982 ：デフォルトの名無しさん：2010/11/10(水) 00:53:39

基本は変わらんと言うに。
量子コンピュータが実用化したら撤退してやるよ。

983 ：デフォルトの名無しさん：2010/11/10(水) 00:59:20

C++は失敗しただろ。まだ言ってんのかよ。
もうみんなテンプレートに夢中で、クラスとかどうでも良くなってる。
C++的OOPに忠実なIOストリームは使いにくく、逆にvectorやlist、shared_ptrは超便利。
MFCも使いづらかった。C++上ではもう決着は付いたもんだともうが。
OOPを応援したいのなら、もっと勝算のある他の言語挙げれば？あるかは知らんが。

984 ：デフォルトの名無しさん：2010/11/10(水) 01:22:14

結局彼が嫌いだったのは仮想関数テーブルであり、
彼にとってOOPとは仮想関数テーブルを使うことである。つうことか。
頭のおかしい人かと思っていたが、彼はOOPを一般に広まっている意味ではない意味で使っていると
気づいて（コミュ障は措く）別に障害がある人ではないとわかったよ。

985 ：デフォルトの名無しさん：2010/11/10(水) 01:23:28

だいたいさー、構造体にvtable持たせるって事自体アホなんだよ。
そんなことしたらオフセットがずれて使いづらいだろーが。Cとの親和性も悪くなる。
それに、Windows.hなどで定義されてる生の構造体に動的な機構を持たせることも出来ん。
何たる中途半端。
vtableは参照が持ってりゃいんだよ。
参照が自分がさしてる型を動的に把握できりゃ、それで十分だろ。
ポリモは参照越しにするんだからよ。

生構造体　-　動的型の参照orポインタ　-　マルチメソッド機構　-　生関数

こういう配置が望ましい。
そうすれば、構造体や関数は余計な機構の付いてない、C言語のそれだから、
扱いやすいし、解りやすいし、使いまわしもしやすい。
構造体先頭のvtableとか邪魔なだけなんだよ。

986 ：デフォルトの名無しさん：2010/11/10(水) 06:05:55

>>984
抽象化ができないんだろうな。
サービスごとにインタフェースを切って…みたいな話がなぜ重要か、とか一生理解できなそう。

実際には、彼がよく持ち出すmalloc一つ取っても、物理メモリの管理を抽象化してくれる、
OSが提供するサービスなんだが。ローカルマシン上で動くプログラムを書いている限りは、
「主語」がOSだから、サービスの提供元として明示的に指定する必要がないってだけで。

RDB屋とかがよく言うデータ指向設計みたいな話も、RDBMSというフレームワークが、
データに対して、ユーザがプログラムしたロジックを強制してくれるから成り立つわけだ。
つまり、データとロジックをまとめて、サービスとして外部に露出しているという意味では
OOPと変わらん。

987 ：デフォルトの名無しさん：2010/11/10(水) 06:31:25

結局のところ、
1. データとロジックをまとめてインタフェースを定義し、サービスとして外部に公開する
2. 他のプログラマは、インタフェース経由でサービスを利用しながら処理を書き、さらにサービスを作る
という概念に沿っていないプログラミングモデルなんて存在しない。
オブジェクト指向も、結局はこういう概念を実現する方法の一つに過ぎない。

かつての、ローカルマシン上で動くプログラムが前提だった時期は、
「誰に」サービスの実行を依頼するかは自明であり、考える必要のないことだった。
なぜなら、「プログラムから見える計算機資源＝世界」だったから。
正確にはそれは「ウソ」なんだが、OSや言語が隠蔽することで、あたかもそうであるか
のように扱えるようにしてくれていた。

しかし、これからマルチコアやクラウド環境のように分散処理が当たり前になっていくと、
「どの計算機資源を使って処理をするか」という話が入ってくるのは不可避になる。
ま、多くの場合、そういったことはフレームワークで隠蔽して、プログラマが意識しなくて
良いように設計されるだろうけど。

とはいえ、1CPUで「プログラムから見える計算機資源＝世界」を所与の前提とした議論は、
ますます現実と乖離していくだろうね。

988 ：デフォルトの名無しさん：2010/11/10(水) 18:03:06

>>984
彼がOOPだと思ってるのは「クラスベースOOPL」だけみたいだからね。
マルチメソッドを使ったOOPLの実装もあるし、
クラスを使わないOOPLの実装もあるし、
そもそもOOPってパラダイム自体はOOPLでなくても実現できるのに。

989 ：デフォルトの名無しさん：2010/11/10(水) 20:22:26

いつもの人だけど、結論は読んだ人自らが決めるといい。

990 ：デフォルトの名無しさん：2010/11/10(水) 20:37:36

そして、1CPUとかまるで関係が無いと言うね。
1CPUだとOOPはダメだが、分散処理ならOOPは上手くいく、
そんな展開には発展しえないのに、まるで関係ないこといって、議論のすり替え。

そしてOOPの拡大解釈。あれもOOPこれもOOPすべてOOPだからOOPは正しい。
アホ草。いつまで屁理屈いってんだか。
まー屁理屈を屁理屈だと理解できないあたりがさすがのOOP脳だがな。
本当左翼と似てるんだよなー。誰しもが通る道なのかもしらんが。

だから誰も近づかないんだよな。もうそっとしておくしか。手遅れなんだろう。
こう言うのが多いからあの業界は嫌だったんだ。まー一定数何処にでも居るがな。
困った困った。

991 ：デフォルトの名無しさん：2010/11/10(水) 20:49:00

誰も近づかないっていうか皆使ってます

992 ：デフォルトの名無しさん：2010/11/10(水) 20:51:45

あまりLISPをディスるのはよくない

993 ：デフォルトの名無しさん：2010/11/10(水) 21:42:28

OOPの拡大解釈も何も、勝手に狭めてるのは誰だよ。
OOPについての書籍だって、始めのうちはC言語とかから出てたんだぜ？

994 ：デフォルトの名無しさん：2010/11/10(水) 22:15:42

C言語の構造体に関数ポインタ突っ込むんだろ？それがまさにアホなやり方だってんだよ。
拡張性のためにそうせざるを得ないこともあるが、仕方なくすることだ。例えば、Windowsの窓関数とかな。
コンパイル後のOSの挙動をアプリから変更できるように、もうね、仕方なくしてる。
フルコンパイルするの前提なら、本来必要の無い手法。
本来ある種のテクニックとして取り上げて、積極的に利用していくようなものではない。

995 ：デフォルトの名無しさん：2010/11/10(水) 22:30:11

「OOPLにあらずんばOOPにあらず」ですか？

996 ：デフォルトの名無しさん：2010/11/10(水) 22:37:59

switchディスってんのか

997 ：デフォルトの名無しさん：2010/11/10(水) 22:42:09

ここだけ中国語の部屋

998 ：デフォルトの名無しさん：2010/11/10(水) 22:42:20

オブジェクト指向という発想がNGって立場。
名前がNG。
オブジェクト指向って明確な定義もないし、実体も無いあやふやなもの。
でも、オブジェクト指向っていうからにはオブジェクトをフューチャーするんだろう。
だけど、オブジェクト、(物とか対象ってことなんだろうけど、)
そんなものに着眼してどうすんのと。
オブジェクト指向な考え方や、そういう考え方を好む人がNG。
そういう思考回路で作られた変てこ言語もまたNGだがね。

999 ：デフォルトの名無しさん：2010/11/10(水) 22:48:59

「最後に書いたやつが勝利」モードに入りましたか。

1000 ：デフォルトの名無しさん：2010/11/10(水) 22:49:24

よしわかった！
もういいよ！

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。