1001コメント377KB

OOP

レス数が1000を超えています。これ以上書き込みはできません。

0001デフォルトの名無しさん

2010/09/10(金) 19:44:50

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

0002デフォルトの名無しさん

2010/09/10(金) 21:32:49

Oops!

0003デフォルトの名無しさん

2010/09/10(金) 22:12:39

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

0004デフォルトの名無しさん

2010/09/10(金) 23:58:55

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

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

0005デフォルトの名無しさん

2010/09/11(土) 00:38:13

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

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

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

0006デフォルトの名無しさん

2010/09/11(土) 00:40:55

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

0007デフォルトの名無しさん

2010/09/11(土) 02:25:45

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

0008デフォルトの名無しさん

2010/09/11(土) 07:27:20

Ookina OPpai

0009デフォルトの名無しさん

2010/09/11(土) 08:26:53

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

0010デフォルトの名無しさん

2010/09/11(土) 08:29:34

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

0011デフォルトの名無しさん

2010/09/11(土) 08:35:15

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

0012デフォルトの名無しさん

2010/09/11(土) 08:35:17

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

0013デフォルトの名無しさん

2010/09/11(土) 08:49:40

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

0014デフォルトの名無しさん

2010/09/11(土) 09:08:26

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

0015デフォルトの名無しさん

2010/09/11(土) 10:31:44

ほんとに罵りあうなよ

0016デフォルトの名無しさん

2010/09/11(土) 10:36:57

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

0017デフォルトの名無しさん

2010/09/11(土) 11:50:59

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

0018デフォルトの名無しさん

2010/09/11(土) 12:10:45

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

0019デフォルトの名無しさん

2010/09/11(土) 12:39:25

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

0020デフォルトの名無しさん

2010/09/11(土) 12:43:26

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

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

0021デフォルトの名無しさん

2010/09/11(土) 13:19:44

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

0022デフォルトの名無しさん

2010/09/11(土) 14:43:51

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

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

0023デフォルトの名無しさん

2010/09/11(土) 14:57:42

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

0024デフォルトの名無しさん

2010/09/11(土) 14:58:22

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

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

0025デフォルトの名無しさん

2010/09/11(土) 15:21:26

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

0026デフォルトの名無しさん

2010/09/11(土) 15:29:02

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

0027デフォルトの名無しさん

2010/09/11(土) 15:32:54

C++は両方あるよ

0028デフォルトの名無しさん

2010/09/11(土) 16:06:32

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

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

0029デフォルトの名無しさん

2010/09/11(土) 16:19:10

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

0030デフォルトの名無しさん

2010/09/11(土) 18:19:58

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

0031デフォルトの名無しさん

2010/09/11(土) 18:50:24

>>28
また出てきたのか

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

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

0032デフォルトの名無しさん

2010/09/11(土) 18:55:11

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

0033デフォルトの名無しさん

2010/09/11(土) 19:01:08

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

0034デフォルトの名無しさん

2010/09/11(土) 19:05:19

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

0035デフォルトの名無しさん

2010/09/11(土) 19:12:18

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

0036デフォルトの名無しさん

2010/09/11(土) 19:55:16

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

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

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

0037デフォルトの名無しさん

2010/09/11(土) 20:45:26

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

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

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

0038デフォルトの名無しさん

2010/09/11(土) 21:00:58

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

0039デフォルトの名無しさん

2010/09/11(土) 21:30:41

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

0040デフォルトの名無しさん

2010/09/11(土) 22:07:51

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

0041デフォルトの名無しさん

2010/09/11(土) 22:27:19

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

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

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

0042デフォルトの名無しさん

2010/09/11(土) 22:41:55

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

0043デフォルトの名無しさん

2010/09/11(土) 22:44:01

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

0044デフォルトの名無しさん

2010/09/11(土) 22:54:06

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

0045デフォルトの名無しさん

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の個性を定義してーってなるだろ。
その方向性の戦略ってどうなん。破滅パターンに見えて仕方ない。

0046デフォルトの名無しさん

2010/09/11(土) 23:07:40

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

0047デフォルトの名無しさん

2010/09/11(土) 23:13:31

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

0048デフォルトの名無しさん

2010/09/11(土) 23:23:33

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

0049デフォルトの名無しさん

2010/09/11(土) 23:30:48

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

0050デフォルトの名無しさん

2010/09/11(土) 23:31:50

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

0051デフォルトの名無しさん

2010/09/11(土) 23:42:45

>>46
グサッ…

0052デフォルトの名無しさん

2010/09/11(土) 23:45:16

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

0053デフォルトの名無しさん

2010/09/12(日) 01:18:25

またオレオレOOか

0054デフォルトの名無しさん

2010/09/12(日) 01:19:36

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

0055デフォルトの名無しさん

2010/09/12(日) 01:25:41

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

0056デフォルトの名無しさん

2010/09/12(日) 01:27:57

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

0057デフォルトの名無しさん

2010/09/12(日) 03:05:37

勝手になりすますなや

0058デフォルトの名無しさん

2010/09/12(日) 03:20:37

>>52
正解。

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

0059デフォルトの名無しさん

2010/09/12(日) 03:56:55

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

0060デフォルトの名無しさん

2010/09/12(日) 04:31:18

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

0061デフォルトの名無しさん

2010/09/12(日) 05:26:34

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

0062デフォルトの名無しさん

2010/09/12(日) 09:50:27

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

0063デフォルトの名無しさん

2010/09/12(日) 09:51:40

>>62
じゃあよろしく

0064デフォルトの名無しさん

2010/09/12(日) 18:19:38

何を？

0065デフォルトの名無しさん

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.

0066デフォルトの名無しさん

2010/09/12(日) 23:04:55

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

0067デフォルトの名無しさん

2010/09/12(日) 23:58:35

超訳きた

0068デフォルトの名無しさん

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 ではコロンもメソッド名に含まれるので省略したり、分割してしまうと、
別のメソッドの名前になってしまうので注意されたい）。

0069デフォルトの名無しさん

2010/09/13(月) 01:43:40

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

0070デフォルトの名無しさん

2010/09/13(月) 03:09:41

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

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

0071デフォルトの名無しさん

2010/09/13(月) 12:46:17

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

0072デフォルトの名無しさん

2010/09/13(月) 12:53:33

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

0073デフォルトの名無しさん

2010/09/13(月) 13:22:41

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

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

0074デフォルトの名無しさん

2010/09/13(月) 18:19:50

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

0075デフォルトの名無しさん

2010/09/13(月) 19:32:11

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

0076デフォルトの名無しさん

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()なんていう変な文法に変えちまったんだ？
パラダイムシフトとか言って、へんな方向にシフトしてズレちまったら意味ねぇ。
奇をてらわなくても普通でいいじゃん、自然で良いじゃん。

0077デフォルトの名無しさん

2010/09/13(月) 20:35:19

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

0078デフォルトの名無しさん

2010/09/13(月) 20:47:06

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

0079デフォルトの名無しさん

2010/09/13(月) 20:52:27

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

0080デフォルトの名無しさん

2010/09/13(月) 20:53:15

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

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

0081デフォルトの名無しさん

2010/09/13(月) 20:54:49

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

0082デフォルトの名無しさん

2010/09/13(月) 20:58:16

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

0083デフォルトの名無しさん

2010/09/13(月) 21:00:05

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

0084デフォルトの名無しさん

2010/09/13(月) 21:07:06

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

0085デフォルトの名無しさん

2010/09/13(月) 21:17:37

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

0086デフォルトの名無しさん

2010/09/13(月) 21:17:41

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

0087デフォルトの名無しさん

2010/09/13(月) 21:22:21

CLOSに
お　ま　か　せ

0088デフォルトの名無しさん

2010/09/13(月) 21:23:34

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

0089デフォルトの名無しさん

2010/09/13(月) 21:30:54

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

0090デフォルトの名無しさん

2010/09/13(月) 21:37:47

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

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

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

0091デフォルトの名無しさん

2010/09/13(月) 21:51:00

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

0092デフォルトの名無しさん

2010/09/13(月) 22:01:56

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

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

0093デフォルトの名無しさん

2010/09/13(月) 22:03:17

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

0094デフォルトの名無しさん

2010/09/13(月) 22:06:04

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

0095デフォルトの名無しさん

2010/09/13(月) 22:09:33

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

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

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

0096デフォルトの名無しさん

2010/09/13(月) 22:11:05

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

0097デフォルトの名無しさん

2010/09/13(月) 22:17:06

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

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

0098デフォルトの名無しさん

2010/09/13(月) 22:40:40

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

0099デフォルトの名無しさん

2010/09/13(月) 22:44:35

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

0100デフォルトの名無しさん

2010/09/13(月) 22:47:12

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

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

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

0101デフォルトの名無しさん

2010/09/13(月) 22:56:49

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

0102デフォルトの名無しさん

2010/09/13(月) 23:01:50

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

0103デフォルトの名無しさん

2010/09/13(月) 23:02:07

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

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

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

0104デフォルトの名無しさん

2010/09/13(月) 23:06:07

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

0105デフォルトの名無しさん

2010/09/13(月) 23:10:13

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

0106デフォルトの名無しさん

2010/09/13(月) 23:11:24

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

0107デフォルトの名無しさん

2010/09/13(月) 23:12:16

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

0108デフォルトの名無しさん

2010/09/13(月) 23:24:31

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

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

0109デフォルトの名無しさん

2010/09/13(月) 23:27:57

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

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

0110デフォルトの名無しさん

2010/09/13(月) 23:29:33

すげーどうでもいいｗ

0111デフォルトの名無しさん

2010/09/13(月) 23:33:54

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

0112デフォルトの名無しさん

2010/09/13(月) 23:39:21

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

0113デフォルトの名無しさん

2010/09/14(火) 00:09:15

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

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

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

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

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

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

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

C言語、大好きです。

0114デフォルトの名無しさん

2010/09/14(火) 00:28:09

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

0115デフォルトの名無しさん

2010/09/14(火) 00:30:36

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

0116デフォルトの名無しさん

2010/09/14(火) 00:33:06

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

0117デフォルトの名無しさん

2010/09/14(火) 00:38:56

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

0118デフォルトの名無しさん

2010/09/14(火) 00:39:58

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

0119デフォルトの名無しさん

2010/09/14(火) 07:04:03

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

0120デフォルトの名無しさん

2010/09/14(火) 18:12:45

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

0121デフォルトの名無しさん

2010/09/14(火) 19:52:29

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

0122デフォルトの名無しさん

2010/09/14(火) 20:13:33

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

0123デフォルトの名無しさん

2010/09/14(火) 20:43:25

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

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

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

0124デフォルトの名無しさん

2010/09/14(火) 20:52:54

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

0125デフォルトの名無しさん

2010/09/14(火) 20:55:11

>>123
Lisp 最高ですよね。

0126デフォルトの名無しさん

2010/09/14(火) 20:55:15

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

0127デフォルトの名無しさん

2010/09/14(火) 21:01:59

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

0128デフォルトの名無しさん

2010/09/14(火) 21:15:47

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

0129デフォルトの名無しさん

2010/09/14(火) 21:35:10

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

0130デフォルトの名無しさん

2010/09/14(火) 21:37:00

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

0131デフォルトの名無しさん

2010/09/14(火) 21:45:23

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

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

0132デフォルトの名無しさん

2010/09/14(火) 21:48:11

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

0133デフォルトの名無しさん

2010/09/14(火) 21:48:44

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

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

0134デフォルトの名無しさん

2010/09/14(火) 21:55:22

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

0135デフォルトの名無しさん

2010/09/14(火) 22:07:41

典型的な詭弁だな。

0136デフォルトの名無しさん

2010/09/14(火) 22:38:55

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

0137デフォルトの名無しさん

2010/09/14(火) 22:59:19

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

0138デフォルトの名無しさん

2010/09/14(火) 23:01:52

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

0139デフォルトの名無しさん

2010/09/14(火) 23:02:45

ポリモさん、出番です

0140デフォルトの名無しさん

2010/09/15(水) 00:01:06

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

0141デフォルトの名無しさん

2010/09/15(水) 00:04:42

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

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

0142デフォルトの名無しさん

2010/09/15(水) 00:06:12

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

0143デフォルトの名無しさん

2010/09/15(水) 00:10:43

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

0144デフォルトの名無しさん

2010/09/15(水) 00:12:21

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

0145デフォルトの名無しさん

2010/09/15(水) 00:13:24

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

0146デフォルトの名無しさん

2010/09/15(水) 00:15:24

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

0147デフォルトの名無しさん

2010/09/15(水) 01:26:49

>>142
釣り？

0148デフォルトの名無しさん

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

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

0149デフォルトの名無しさん

2010/09/15(水) 07:59:25

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

0150デフォルトの名無しさん

2010/09/15(水) 11:43:37

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

0151デフォルトの名無しさん

2010/09/15(水) 12:42:58

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

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

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

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

0152デフォルトの名無しさん

2010/09/15(水) 13:08:03

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

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

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

0153デフォルトの名無しさん

2010/09/15(水) 13:11:46

切れてナイーだけ読んだ

0154デフォルトの名無しさん

2010/09/15(水) 13:12:23

>>141
io言語最強！！

obj method1 method2

タイプ量も見やすさも

0155デフォルトの名無しさん

2010/09/15(水) 13:26:56

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

0156デフォルトの名無しさん

2010/09/15(水) 14:22:50

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

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

0157デフォルトの名無しさん

2010/09/15(水) 14:31:20

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

0158デフォルトの名無しさん

2010/09/15(水) 15:14:47

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

0159デフォルトの名無しさん

2010/09/15(水) 15:59:06

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

0160デフォルトの名無しさん

2010/09/15(水) 17:02:45

そのようによめない

0161デフォルトの名無しさん

2010/09/15(水) 19:19:23

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

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

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

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

0162デフォルトの名無しさん

2010/09/15(水) 19:21:32

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

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

0163デフォルトの名無しさん

2010/09/15(水) 19:25:46

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

0164デフォルトの名無しさん

2010/09/15(水) 19:29:33

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

0165デフォルトの名無しさん

2010/09/15(水) 19:34:09

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

0166デフォルトの名無しさん

2010/09/15(水) 19:39:28

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

0167デフォルトの名無しさん

2010/09/15(水) 19:41:52

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

0168デフォルトの名無しさん

2010/09/15(水) 19:57:28

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

0169デフォルトの名無しさん

2010/09/15(水) 20:04:00

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

0170デフォルトの名無しさん

2010/09/15(水) 20:05:40

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

0171デフォルトの名無しさん

2010/09/15(水) 20:43:46

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

0172デフォルトの名無しさん

2010/09/15(水) 21:12:31

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

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

0173デフォルトの名無しさん

2010/09/15(水) 21:24:17

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

0174デフォルトの名無しさん

2010/09/15(水) 21:36:07

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

0175デフォルトの名無しさん

2010/09/15(水) 21:46:41

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

0176デフォルトの名無しさん

2010/09/15(水) 23:53:38

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

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

0177デフォルトの名無しさん

2010/09/15(水) 23:57:11

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

0178デフォルトの名無しさん

2010/09/16(木) 00:29:11

>>177
禿同。

0179デフォルトの名無しさん

2010/09/16(木) 01:17:21

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

0180デフォルトの名無しさん

2010/09/16(木) 01:32:51

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

0181デフォルトの名無しさん

2010/09/16(木) 01:34:57

このセンスｗ

0182デフォルトの名無しさん

2010/09/16(木) 02:11:19

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

0183デフォルトの名無しさん

2010/09/16(木) 10:56:52

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

0184デフォルトの名無しさん

2010/09/16(木) 20:43:42

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

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

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

0185デフォルトの名無しさん

2010/09/16(木) 20:44:46

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

0186デフォルトの名無しさん

2010/09/16(木) 20:50:01

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

0187デフォルトの名無しさん

2010/09/16(木) 21:32:16

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

0188デフォルトの名無しさん

2010/09/16(木) 22:00:30

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

0189デフォルトの名無しさん

2010/09/16(木) 22:14:40

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

0190デフォルトの名無しさん

2010/09/16(木) 22:22:28

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

0191デフォルトの名無しさん

2010/09/16(木) 22:25:45

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

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

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

0192デフォルトの名無しさん

2010/09/16(木) 22:28:50

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

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

0193デフォルトの名無しさん

2010/09/16(木) 22:38:28

OO脳としか。

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

0194デフォルトの名無しさん

2010/09/16(木) 22:38:31

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

0195デフォルトの名無しさん

2010/09/16(木) 22:42:39

日本語でおk

0196デフォルトの名無しさん

2010/09/16(木) 22:44:54

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

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

0197デフォルトの名無しさん

2010/09/16(木) 22:45:13

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

0198デフォルトの名無しさん

2010/09/16(木) 22:45:21

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

0199デフォルトの名無しさん

2010/09/16(木) 22:48:52

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

0200デフォルトの名無しさん

2010/09/16(木) 22:50:27

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

0201デフォルトの名無しさん

2010/09/16(木) 22:50:57

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

0202デフォルトの名無しさん

2010/09/16(木) 22:56:26

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

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

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

0203デフォルトの名無しさん

2010/09/16(木) 23:02:08

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

ソース。

0204デフォルトの名無しさん

2010/09/16(木) 23:11:52

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

0205デフォルトの名無しさん

2010/09/16(木) 23:12:49

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

0206デフォルトの名無しさん

2010/09/16(木) 23:14:30

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

0207デフォルトの名無しさん

2010/09/16(木) 23:23:39

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

0208デフォルトの名無しさん

2010/09/16(木) 23:30:00

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

0209デフォルトの名無しさん

2010/09/16(木) 23:44:03

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

0210デフォルトの名無しさん

2010/09/16(木) 23:47:27

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

0211デフォルトの名無しさん

2010/09/16(木) 23:49:12

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

0212デフォルトの名無しさん

2010/09/16(木) 23:49:38

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

0213デフォルトの名無しさん

2010/09/16(木) 23:55:07

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

0214デフォルトの名無しさん

2010/09/16(木) 23:55:47

また馬鹿がきた

0215デフォルトの名無しさん

2010/09/17(金) 00:03:02

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

0216デフォルトの名無しさん

2010/09/17(金) 00:13:03

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

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

0217デフォルトの名無しさん

2010/09/17(金) 00:14:51

おまえはコテハンつけろ

0218デフォルトの名無しさん

2010/09/17(金) 00:18:41

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

0219デフォルトの名無しさん

2010/09/17(金) 00:20:18

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

0220デフォルトの名無しさん

2010/09/17(金) 00:21:49

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

0221デフォルトの名無しさん

2010/09/17(金) 00:30:51

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

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

0222デフォルトの名無しさん

2010/09/17(金) 00:31:54

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

0223デフォルトの名無しさん

2010/09/17(金) 00:38:49

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

0224デフォルトの名無しさん

2010/09/17(金) 00:39:56

中身ないレスばっか

0225デフォルトの名無しさん

2010/09/17(金) 00:51:01

>>224
仲間入りおめ

0226デフォルトの名無しさん

2010/09/17(金) 01:26:39

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

0227デフォルトの名無しさん

2010/09/17(金) 02:17:20

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

0228デフォルトの名無しさん

2010/09/17(金) 02:18:07

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

0229デフォルトの名無しさん

2010/09/17(金) 04:11:20

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

0230デフォルトの名無しさん

2010/09/17(金) 06:37:12

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

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

0231デフォルトの名無しさん

2010/09/17(金) 07:01:21

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

0232デフォルトの名無しさん

2010/09/17(金) 08:21:41

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

0233デフォルトの名無しさん

2010/09/17(金) 10:07:04

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

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

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

0234デフォルトの名無しさん

2010/09/17(金) 11:41:48

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

0235デフォルトの名無しさん

2010/09/17(金) 11:43:34

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

0236デフォルトの名無しさん

2010/09/17(金) 12:02:37

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

0237デフォルトの名無しさん

2010/09/17(金) 12:18:10

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

0238デフォルトの名無しさん

2010/09/17(金) 12:35:18

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

0239デフォルトの名無しさん

2010/09/17(金) 16:58:18

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

0240デフォルトの名無しさん

2010/09/17(金) 21:57:40

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

0241デフォルトの名無しさん

2010/09/17(金) 22:03:39

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

0242デフォルトの名無しさん

2010/09/17(金) 22:06:23

お
作
口
偉

いまいち。

0243デフォルトの名無しさん

2010/09/17(金) 23:17:44

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

0244デフォルトの名無しさん

2010/09/17(金) 23:30:20

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

0245デフォルトの名無しさん

2010/09/17(金) 23:55:34

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

0246デフォルトの名無しさん

2010/09/18(土) 00:05:33

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

0247デフォルトの名無しさん

2010/09/18(土) 00:08:32

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

0248デフォルトの名無しさん

2010/09/18(土) 00:22:00

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

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

0249デフォルトの名無しさん

2010/09/18(土) 00:22:37

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

0250デフォルトの名無しさん

2010/09/18(土) 00:24:59

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

0251デフォルトの名無しさん

2010/09/18(土) 00:25:50

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

0252デフォルトの名無しさん

2010/09/18(土) 00:27:41

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

0253デフォルトの名無しさん

2010/09/18(土) 00:28:00

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

0254デフォルトの名無しさん

2010/09/18(土) 00:30:08

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

0255デフォルトの名無しさん

2010/09/18(土) 08:26:26

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

0256デフォルトの名無しさん

2010/09/18(土) 09:54:31

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

0257デフォルトの名無しさん

2010/09/18(土) 09:59:29

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

0258デフォルトの名無しさん

2010/09/18(土) 10:29:59

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

0259デフォルトの名無しさん

2010/09/18(土) 11:15:37

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

0260デフォルトの名無しさん

2010/09/18(土) 11:20:49

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

0261デフォルトの名無しさん

2010/09/18(土) 11:43:27

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

0262デフォルトの名無しさん

2010/09/18(土) 11:55:42

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

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

0263デフォルトの名無しさん

2010/09/18(土) 12:58:06

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

0264デフォルトの名無しさん

2010/09/18(土) 12:59:53

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

0265デフォルトの名無しさん

2010/09/18(土) 13:11:37

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

0266デフォルトの名無しさん

2010/09/18(土) 14:06:09

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

0267デフォルトの名無しさん

2010/09/18(土) 14:37:20

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

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

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

0268デフォルトの名無しさん

2010/09/18(土) 14:42:53

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

0269デフォルトの名無しさん

2010/09/18(土) 15:07:47

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

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

0270デフォルトの名無しさん

2010/09/18(土) 15:18:07

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

0271デフォルトの名無しさん

2010/09/18(土) 15:19:06

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

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

0272デフォルトの名無しさん

2010/09/18(土) 15:42:43

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

0273デフォルトの名無しさん

2010/09/18(土) 16:02:39

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

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

>>270,271
同意。

0274デフォルトの名無しさん

2010/09/18(土) 16:49:55

なんか次は、

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

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

0275デフォルトの名無しさん

2010/09/18(土) 16:57:21

エヘ

0276デフォルトの名無しさん

2010/09/18(土) 17:24:24

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

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

0277デフォルトの名無しさん

2010/09/18(土) 17:27:22

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

0278デフォルトの名無しさん

2010/09/18(土) 18:53:59

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

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

0279デフォルトの名無しさん

2010/09/18(土) 18:56:44

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

0280デフォルトの名無しさん

2010/09/18(土) 18:58:04

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

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

0281デフォルトの名無しさん

2010/09/18(土) 19:02:11

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

0282デフォルトの名無しさん

2010/09/18(土) 19:34:26

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

0283デフォルトの名無しさん

2010/09/18(土) 20:28:22

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

0284デフォルトの名無しさん

2010/09/18(土) 20:31:10

委譲しろよ

0285デフォルトの名無しさん

2010/09/18(土) 21:16:08

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

0286デフォルトの名無しさん

2010/09/18(土) 21:28:12

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

0287デフォルトの名無しさん

2010/09/18(土) 21:41:28

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

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

0288デフォルトの名無しさん

2010/09/18(土) 21:42:06

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

0289デフォルトの名無しさん

2010/09/18(土) 21:48:28

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

0290デフォルトの名無しさん

2010/09/18(土) 21:53:56

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

0291デフォルトの名無しさん

2010/09/18(土) 22:27:53

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

0292デフォルトの名無しさん

2010/09/18(土) 22:33:42

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

0293デフォルトの名無しさん

2010/09/18(土) 22:59:46

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

0294デフォルトの名無しさん

2010/09/18(土) 23:02:55

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

0295デフォルトの名無しさん

2010/09/18(土) 23:40:03

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

0296デフォルトの名無しさん

2010/09/18(土) 23:41:32

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

0297デフォルトの名無しさん

2010/09/18(土) 23:43:39

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

0298デフォルトの名無しさん

2010/09/19(日) 00:13:17

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

0299デフォルトの名無しさん

2010/09/19(日) 00:13:37

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

0300デフォルトの名無しさん

2010/09/19(日) 00:16:07

そんなものはない。

0301デフォルトの名無しさん

2010/09/19(日) 00:16:49

なんでそうおもうの

0302デフォルトの名無しさん

2010/09/19(日) 00:17:58

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

0303デフォルトの名無しさん

2010/09/19(日) 00:18:45

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

0304デフォルトの名無しさん

2010/09/19(日) 00:20:14

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

0305デフォルトの名無しさん

2010/09/19(日) 00:20:43

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

0306デフォルトの名無しさん

2010/09/19(日) 00:31:57

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

0307デフォルトの名無しさん

2010/09/19(日) 00:34:10

え？

0308デフォルトの名無しさん

2010/09/19(日) 00:45:53

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

0309デフォルトの名無しさん

2010/09/19(日) 00:48:33

え？

0310デフォルトの名無しさん

2010/09/19(日) 01:25:14

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

0311デフォルトの名無しさん

2010/09/19(日) 01:27:14

え？

0312デフォルトの名無しさん

2010/09/19(日) 01:48:49

え？

0313デフォルトの名無しさん

2010/09/19(日) 09:57:33

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

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

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

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

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

>>282
同意。

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

0314デフォルトの名無しさん

2010/09/19(日) 11:19:54

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

0315デフォルトの名無しさん

2010/09/19(日) 12:46:34

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

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

0316デフォルトの名無しさん

2010/09/19(日) 12:47:24

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

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

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

0317デフォルトの名無しさん

2010/09/19(日) 15:42:19

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

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

0318デフォルトの名無しさん

2010/09/19(日) 16:17:03

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

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

0319デフォルトの名無しさん

2010/09/19(日) 17:30:43

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

0320デフォルトの名無しさん

2010/09/19(日) 18:18:26

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

0321デフォルトの名無しさん

2010/09/19(日) 18:18:55

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

0322デフォルトの名無しさん

2010/09/19(日) 19:20:35

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

0323デフォルトの名無しさん

2010/09/19(日) 19:28:09

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

0324デフォルトの名無しさん

2010/09/19(日) 19:36:12

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

0325デフォルトの名無しさん

2010/09/19(日) 20:34:35

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

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

0326デフォルトの名無しさん

2010/09/19(日) 21:00:18

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

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

0327デフォルトの名無しさん

2010/09/19(日) 21:10:43

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

0328デフォルトの名無しさん

2010/09/19(日) 21:58:28

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

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

0329デフォルトの名無しさん

2010/09/19(日) 22:09:11

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

0330デフォルトの名無しさん

2010/09/19(日) 22:40:03

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

0331デフォルトの名無しさん

2010/09/19(日) 22:54:26

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

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

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

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

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

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

0332デフォルトの名無しさん

2010/09/19(日) 23:16:04

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

0333デフォルトの名無しさん

2010/09/19(日) 23:18:48

>>331
横から。

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

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

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

0334デフォルトの名無しさん

2010/09/19(日) 23:22:50

差分プログラミングは糞

0335デフォルトの名無しさん

2010/09/19(日) 23:34:30

出た、学術的回答ｗ

0336デフォルトの名無しさん

2010/09/19(日) 23:35:28

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

0337デフォルトの名無しさん

2010/09/19(日) 23:41:02

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

0338デフォルトの名無しさん

2010/09/19(日) 23:48:17

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

0339デフォルトの名無しさん

2010/09/20(月) 00:10:07

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

0340デフォルトの名無しさん

2010/09/20(月) 00:55:16

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

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

0341デフォルトの名無しさん

2010/09/20(月) 09:58:44

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

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

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

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

0342デフォルトの名無しさん

2010/09/20(月) 11:52:23

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

0343デフォルトの名無しさん

2010/09/20(月) 12:15:52

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

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

0344デフォルトの名無しさん

2010/09/20(月) 12:45:16

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

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

0345デフォルトの名無しさん

2010/09/20(月) 12:54:06

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

0346デフォルトの名無しさん

2010/09/20(月) 13:31:16

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

0347デフォルトの名無しさん

2010/09/20(月) 14:55:19

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

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

0348デフォルトの名無しさん

2010/09/20(月) 14:58:21

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

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

0349デフォルトの名無しさん

2010/09/20(月) 15:01:23

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

0350デフォルトの名無しさん

2010/09/20(月) 15:12:09

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

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

0351デフォルトの名無しさん

2010/09/20(月) 15:29:20

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

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

0352デフォルトの名無しさん

2010/09/20(月) 16:12:32

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

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

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

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

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

0353デフォルトの名無しさん

2010/09/20(月) 16:54:59

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

0354デフォルトの名無しさん

2010/09/20(月) 17:48:36

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

0355デフォルトの名無しさん

2010/09/20(月) 19:15:32

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

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

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

0356デフォルトの名無しさん

2010/09/20(月) 19:53:35

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

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

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

0357デフォルトの名無しさん

2010/09/20(月) 20:19:11

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

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

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

0358デフォルトの名無しさん

2010/09/20(月) 20:43:48

>>355
ズレてるってか多分俺が理解できてない。

>なぜ継承元の構造をそこまで意識しないといけない？
今のところ、凄くやっつけ仕事を言ってるに見えてるから。
システム全体として引き継ぎ易い構造になるの？

0359デフォルトの名無しさん

2010/09/20(月) 21:30:24

>>356
言語や開発環境でいろいろなケースがあると思うけど、俺が考えつくのは
ライブラリや開発環境が比較的代わりやすい場合は
コンポジションの方が影響を受け難い。
コンポジションは別クラスに実装するから、相手のフィールドやメソッドを直接操作出来ない。
これは欠点でもあるし、影響を受け難い利点にもなる。
継承の場合、スーパークラスが修正されると影響が出るから安定したクラスを親にしないと。
言語はjavaとか？　

>>358
>今のところ、凄くやっつけ仕事を言ってるに見えてるから。
差分プログラミングの例だから、そこまで考えていない。
和暦を入力パラメータにもつメソッドに
新元号が追加される単純な話だから。

0360デフォルトの名無しさん

2010/09/20(月) 21:50:40

>>355
契約プログラミング的な考え方を非常に大雑把に言えば、
「あるインタフェースを持つオブジェクトがユーザに対して見せる機能は、
常に一貫していなければならない」と言えると思う。

差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
むしろ相反する場合の方が多いのではないか、というのが俺の意見。

もちろん、両者が一致する範囲内での話なら特に問題はないと思う。

0361デフォルトの名無しさん

2010/09/20(月) 21:58:50

>>360はいつも良いこと書くな！

0362デフォルトの名無しさん

2010/09/20(月) 22:46:19

>>360
なるほど、そう言うことが言いたかったのか。

>差分プログラミングを、「要求の変化に対し、過去のコードを拡張することで対応する」
>という考え方だとするなら、それは契約プログラミングとは必ずしも一致しないし、
>むしろ相反する場合の方が多いのではないか、というのが俺の意見。
俺の意見は、差分プログラミングは基本包含になるから継承しても事前/事後条件は守られる。
俺の浅いEiffelの知識でも大丈夫だったと思うが。

ただ機能削除や別機能なら言う通りだと思う。

0363デフォルトの名無しさん

2010/09/20(月) 23:05:34

いつもの人だけど、な？暗号だろ？読む気するか？
肝心の、「オブジェクトがメソッドを持つべきかどうか」に関しては何も考えない、というか、それが当たり前と思ってるのな。
OOPのグダグダは全部そこから始まってるといっても過言ではないのに。
そこ無視して小手先のフォローに走る。OOPらしいっちゃらしいが。

0364デフォルトの名無しさん

2010/09/20(月) 23:33:15

少なくともC++とかの継承で多態と差分Pを同時にやるとだいたい破綻するから
やるなら多態だけにして、あとはできるだけ合成しろって事でしょ。

0365デフォルトの名無しさん

2010/09/20(月) 23:37:10

>>363
少しはこのスレの住人を説得してみろよ

0366デフォルトの名無しさん

2010/09/21(火) 00:39:54

>>363
OOPだとモジュール構成の最小単位がオブジェクトで、
オブジェクト同士が協調しる手段としてメソッドがあるんたから、
オブジェクトはメソッドを持ってて当たり前だと思うけど。

「OOPはよろしくない」って話？

0367デフォルトの名無しさん

2010/09/21(火) 00:46:01

>>366
多重ディスパッチのことを言ってるんじゃね

>>363
個人的には「オブジェクトがメソッドを持つべきか」は正直どうでもいいなあ
それが多重ディスパッチとかのことなのであればの話だが…
最低限多態さえ出来れば手段は何でもいいと思うよ
カプセル化や継承も、あったら便利だな程度の認識だわ俺は

0368デフォルトの名無しさん

2010/09/21(火) 19:39:54

>>363
そんな話し書店に行けばいくらでも読める。
俺は実践から学んだ人の考えを知りたい。
お前は図書館でもいってろ。

0369デフォルトの名無しさん

2010/09/21(火) 19:58:41

そうだね、本を読めば分かることを２ちゃんで勉強するバカはいないよｗ
やっぱり不特定多数の人が集まるところでは、経験から来る話を一番に聞きたいね。

0370デフォルトの名無しさん

2010/09/21(火) 20:29:29

しかし、本当にOOを経験している人間がこのスレに何人いるか？

0371デフォルトの名無しさん

2010/09/21(火) 20:42:46

ttp://togetter.com/li/25507
最近調べ物をしててこれを知ったんだけど
publicやprivateなどの可視性は事前条件とは無関係なんだろうか？
C++ではvirtualなメンバ関数はprivate推奨のNVIイディオムとかあるし

それとは別にis-a関係はLSPにとって十分でないことを知り
調べるほどに、継承を使える自信が無くなって行く

0372デフォルトの名無しさん

2010/09/21(火) 21:09:31

NVIイディオムってなんぞ？

0373デフォルトの名無しさん

2010/09/21(火) 21:19:00

Non-virtual interface

それはさておき、クラスのprivateな状態をメソッドの事前条件にするのは良くない。
呼び出し側がチェック不能だから。

0374371

2010/09/21(火) 21:31:29

自己レス。
>publicやprivateなどの可視性
この認識はそもそも誤りだった。
publicやprivateはアクセス権(accessibility)のコントロールであり、
可視性(visibility)とは別の概念

>>373
というわけで、その主張は俺の勘違いと同じ誤りを含む
検証可能なソースとしては
C++の仕様書をvisibilityで検索すると1箇所(+索引)しかヒットせず
そこにはaccessibilityとvisibilityは違うと書いてある

となると、アクセス権と事前条件の話は独立、と考えるのが正しいのかな
上の記事はどちらかというと疑って読んでたんだけど
上のtwitterの人はまじプロいな
なんたるPitfall

0375デフォルトの名無しさん

2010/09/21(火) 21:56:34

単に、派生クラスのインスタンスを基本クラスのそれと思って好きなように扱っても、
そのプログラムは常に正しい動きをするって事なんじゃないのかな

そんなにややこしいかねLSPって

0376デフォルトの名無しさん

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クラスのポインタ/参照
として渡されている可能性を考えると完璧とはいえない。

0377356

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のいう混同なのかな？

0378デフォルトの名無しさん

2010/09/22(水) 05:31:34

インターフェイスならそんな抽象クラスみたいな名前じゃなくてIDialogとかにしてくれ。

0379デフォルトの名無しさん

2010/09/22(水) 07:21:52

その場合は、インタフェースの継承（AbstractDialog）と、
実装の継承系統を分けた方良いんでない

DialogImplみたいな別クラスをAbstractDialogに所有させる。
違う挙動が欲しければImplの方をいじる。

0380デフォルトの名無しさん

2010/09/24(金) 21:39:31

継承が一応の結果が出たから次は
・カプセル化

まず構造化と比べオブジェクト指向はどう違うか？

0381デフォルトの名無しさん

2010/09/24(金) 22:59:25

あるスコープから見える範囲についての決まりを強制する機能が処理系にある。

お　　し　　ま　　い

0382デフォルトの名無しさん

2010/09/24(金) 23:10:28

>あるスコープから見える範囲についての決まりを強制する機能が処理系にある。
馬鹿？　お前自身が終わっているぞｗ

0383デフォルトの名無しさん

2010/09/24(金) 23:49:24

自説を論証しない馬鹿に馬鹿と言われてもなぁ。

0384デフォルトの名無しさん

2010/09/25(土) 00:05:41

カプセル化ねえ…構造体との最大の違いは
要素へのアクセスを「確実に」共通化できる、ってとこじゃないだろうか
構造体だと、どこか1つでも直接アクセスしたら共通化が外れちゃうからね

その恩恵は多人数開発だけじゃない、個人での開発でもある
例えば、あるフィールドをpublicでの直接アクセスから
private+アクセサメソッドに切り替えたくなった時とかね

フィールド代入をメソッド扱いにできる言語なら、利用側はそのままで
宣言／定義の書き換えだけで済むし
そうでない言語でも、フィールドをprivateにしたことで
利用側でアクセサメソッドを通してない部分はコンパイル時に炙り出される

0385356

2010/09/25(土) 00:11:52

見えない化
見せない化
意識させない化

0386デフォルトの名無しさん

2010/09/25(土) 00:13:26

継承や多態性と違ってカプセル化（PrivateやらProtectedやら）は本質的なもんじゃないから
議論する必要ないだろ

お　し　ま　い

0387デフォルトの名無しさん

2010/09/25(土) 00:23:32

カプセル化が一番の肝だろ

0388デフォルトの名無しさん

2010/09/25(土) 00:30:24

そうだ、カプセル化が一番理解されてないといっても過言でない

0389デフォルトの名無しさん

2010/09/25(土) 00:44:09

(ﾟДﾟ)

0390デフォルトの名無しさん

2010/09/25(土) 00:47:15

カプセル化がない（もしくは希薄な）OOP言語は無視ですか

0391デフォルトの名無しさん

2010/09/25(土) 00:51:12

でも一番重要視されてしかるべきなのはカプセル化だと思うぞ。
継承なんて言ってしまえばただの便利機能だし。

カプセル化は便利とは真逆の、アクセスを制限してしまう不便機能だが
そんなものがなぜプログラムに必要で重宝されるのか、もうちょっと真剣に理解したほうが良い。

0392デフォルトの名無しさん

2010/09/25(土) 00:51:21

>>386,390はアクセス修飾だけがカプセル化と思ってるんじゃまいか？

0393デフォルトの名無しさん

2010/09/25(土) 01:01:59

カプセル化もバズワード臭いんだよなぁ
単にグループ化を指してる人と
オブジェクトのインターフェースを作る事を重要視してる人と
データを隠蔽する事を重要視している人が居るから

0394デフォルトの名無しさん

2010/09/25(土) 01:06:10

全部だ全部、
全部大事なんだよ。

プログラムの宿敵はスパゲッティだ。
全部それを避けるための手法だ。

0395デフォルトの名無しさん

2010/09/25(土) 01:21:00

多態が無くなっても
せいぜい要所に型switch入れるぐらいの変更で済むが
カプセル化が無くなると大変酷いことになる。

0396デフォルトの名無しさん

2010/09/25(土) 01:50:48

カプセル化が無くなっても
せいぜいクラスを構造体に替えたりアクセサを関数に変えるくらいの変更で済むが
多態が無くなると大変酷いことになる。

0397デフォルトの名無しさん

2010/09/25(土) 02:07:46

つまりどちらも不要ということですね

0398デフォルトの名無しさん

2010/09/25(土) 02:13:00

俺は最重要は多態と思う、これが無いとコードを根本から直さないといけない。
要所に型switchで代用できるレベルならいいけど、そうとも限らないからな。

次点でカプセル化だな、使い方が解りやすい割に幅広く、便利機能って言葉がぴったり。
無くてもなんとかなるっちゃなるんだが、あって欲しい機能ではある。

継承はたまーに欲しいんだが、普段は多態の一手段でしかないのがなあ。
他の手段で代用できるのなら要らないことも多い。
でも、大きめのライブラリを作る場合にはちょっと欲しいかな。

0399デフォルトの名無しさん

2010/09/25(土) 03:55:49

また実装レベルの話に後退したでござる。

0400デフォルトの名無しさん

2010/09/25(土) 04:17:04

論文の一本でも引っ張ってこいよ

0401デフォルトの名無しさん

2010/09/25(土) 08:09:37

実装の話をしないプログラミング

0402デフォルトの名無しさん

2010/09/25(土) 08:24:58

もともとオブジェクトは一種の変数で構造化で言うグローバル変数。
使う側も使われる側も相手を意識しないオブジェクトではグローバルに定義されている。
しかしグローバル変数の弊害が、オブジェクト指向ではあまり聞かれない。
構造化のスコープとオブジェクト指向のカプセル化は考え方の違いがある。

0403デフォルトの名無しさん

2010/09/25(土) 08:30:03

グローバルスコープとクラススコープは別物

0404デフォルトの名無しさん

2010/09/25(土) 09:27:37

>グローバルスコープとクラススコープは別物
クラスとオブジェクトの区別もつかない奴がいるとは

0405デフォルトの名無しさん

2010/09/25(土) 09:35:18

Rubyではクラスもオブジェクトだぞ

0406デフォルトの名無しさん

2010/09/25(土) 10:16:56

カプセル化を単なる便利機能とか言ってる時点で何かを履き違えている。
設計の本質は依存関係の整理であって、継承関係の構築じゃない。

0407デフォルトの名無しさん

2010/09/25(土) 10:25:33

いるよな、全てのクラスを単一の継承ツリーに収めようとする奴。
あれはOOPやりはじめの熱病みたいなもんかな。

0408デフォルトの名無しさん

2010/09/25(土) 11:41:18

>>381
何を「処理系」と言っているのか理解出来ないが
オブジェクト指向はデータに処理が付く、その基本観点が抜けている。
>>384
言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。
>>386
仮に「本質的なもんじゃない」としよう（本当にそうなのかもしれないが）
だが、オブジェクト指向では必要なものだ。なぜ必要なのか議論してもいいと思うが。
>>390
カプセル化の定義を聞きたい。
>>393
なるほど、カプセル化の結果から考える人はそうなるな。
ここではカプセル化の本質から考えるのがいいと思う。
>>394
勘違いしている「スパゲッティ」は制御文の話だ。データの話ではない。
>>395,396
>カプセル化が無くなると大変酷いことになる。
>多態が無くなると大変酷いことになる。
具体的に？　
マシン語や構造化の時代でもカプセル化・多態性が無くても
それなりの手法はあって「大変酷い」事にはなっていなかったが。
>>406
>設計の本質は依存関係の整理であって、継承関係の構築じゃない。
具体的に？　俺はオブジェクト指向設計の本質は再利用だと思うが。

0409デフォルトの名無しさん

2010/09/25(土) 12:18:55

>>408
今のWindowsアプリをマシン語で書けって言われて大変酷い事にならない奴がいたら天才
プログラムの規模が昔のままで良いんなら別にOOPもなくて良い

そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない

0410デフォルトの名無しさん

2010/09/25(土) 12:26:05

>>408
>言っていることは分かるが、じゃなぜ構造化にそのような機能を追加しなかったのか？(追加した言語もあるが)
>なぜオブジェクト指向はカプセル化が必要だったのか？そちらも知りたい。

OOPの機能とカプセル化の相性が良かったからでしょ。
カプセル化ってのはデータと処理を一括りにすることなワケで
データと処理を分割している非OOPLでそれをやるのは、新たな要素を追加しなきゃならんが
そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。

0411デフォルトの名無しさん

2010/09/25(土) 14:13:06

>>409
論点がずれている。どう「大変酷い」になるか聞いている。
アセンブラでも構造化でも大規模開発はあって、綺麗なソースも存在した。
君が言う通り「天才」なのかもしれんが．．．

>そして「再利用」はただの差分プログラミングであってOOPとあんま関係ない
オブジェクト指向で再利用を否定できるのは、まだまだオブジェクト指向の理解が足りないから。

>>410
>カプセル化ってのはデータと処理を一括りにすることなワケ
カプセル化をそう考えるのか、俺はカプセル化＝情報隠蔽と考えるから
「データと処理を一括りにする」はカプセル化とは考えていない。
つまり、publicのみにフィールド・メソッドが書かれている場合
カプセル化は適応されていないと考える。

>そもそもデータと処理を一括りにしているOOPLでは何も考えずとも実現できた。
一括りにするだけなら、publicやprivateなど要らない。
オブジェクト指向はpublicやprivateなどの新しい概念を導入している。

0412デフォルトの名無しさん

2010/09/25(土) 14:34:50

>>411
どう大変酷くなるか、なんて考えなくてもわかるもんでは？
誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
そのあたりを何のツールも使わずに完璧に整理できるならOOPLなど要らないと言ってる。
そしてそれができる奴は天才だし、どんな言語でどんな開発規模でもうまくやってのけるだろう。

OOPにおける再利用は依存関係をうまく整理した上で得られた副次的な物に過ぎない。
逆に言えば、依存関係がうまく整理できたならOOPなど関係なく再利用性の高いコードになる。

「オブジェクト志向」がいったい何を志向しているのかといったら
それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。

0413デフォルトの名無しさん

2010/09/25(土) 14:45:54

ここまでオレオレOOP
そしてこれからもオレオレOOP

0414デフォルトの名無しさん

2010/09/25(土) 16:14:09

>>411
情報隠蔽は「データと処理を一括りにすること」で生まれる二次的な効果じゃね？
データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
情報の隠蔽もなされるワケで。

0415デフォルトの名無しさん

2010/09/25(土) 16:42:21

http://scholar.google.co.jp/scholar?q=object-oriented+programming&;hl=ja&lr=
acm のが一番古いっぽいんだが今大学いない一般人なのでむりです

0416デフォルトの名無しさん

2010/09/25(土) 17:49:15

> 情報隠蔽は「データと処理を一括りにする
CLOS あたりはクラスはメソッドを抱えていないが…

0417デフォルトの名無しさん

2010/09/25(土) 18:56:54

いつもの人だけど、
CLOSの話にもっていきたい人がいるみたいだけど、
多分それ、正解。でもバカどもは食いつかないだろうな。
OOPのObjみたく、自分で情報を遮断して殻に閉じこもってるから。

だから、議論は成り立たないから、天下り的に一言で未来を予言してみせるしかない。
モノに執着した考え方は破滅を招く。
オブジェクト指向？ﾉﾝﾉﾝ
関係指向、関数指向、機能指向、メッセージング指向。
他との関係から導かれる個性こそが、それの性質そのもの。
単体では個性は確立し得ない。
マルチメソッドの無いOOPは全部甘い罠だ。つれてかれるぞ。

0418デフォルトの名無しさん

2010/09/25(土) 19:01:18

ﾉﾝﾉﾝ

0419デフォルトの名無しさん

2010/09/25(土) 19:12:28

いつもの人はメッセージング指向になったら、コーディングがどう変わるのかまで踏み込んで話してくれよ
いっつも雰囲気でぼんやりした話しかしないからかなり信用できない

0420デフォルトの名無しさん

2010/09/25(土) 19:15:39

マルチパラダイムなんだから動けばいいんじゃねーですかね

0421デフォルトの名無しさん

2010/09/25(土) 21:31:41

だからC++は一部機能を任意に制限できる仕様にしろって
多重継承とかほとんどいらないし

0422デフォルトの名無しさん

2010/09/25(土) 21:43:23

ライブラリの中で多重継承が使われてたらどうすんだよ

0423デフォルトの名無しさん

2010/09/25(土) 22:20:36

ラップすればよくね？

0424デフォルトの名無しさん

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_; }
}

0425デフォルトの名無しさん

2010/09/25(土) 23:24:32

>>416
クラスとメソッドって形ではないけど
データ型によって実際の処理が変わるのだから、データと処理はセットになってると言えないか？

0426デフォルトの名無しさん

2010/09/25(土) 23:24:32

●データ構造はツリー型(コンポジット)
●ツリーの操作はITreeで定義
●Treeにて上記インターフェースを実装
●深い継承はしたくない

XXTreeという具体的なデータを持つノードを作成したい。

この場合上記のようにXXTreeを作成すればよいか、
またはTreeを継承して作成したほうが良いのか。

冒頭のXXTreeのつくりの場合、ITreeはTreeとXXTreeで、
別々ではあるが2回継承されている。

包含されるTreeはインターフェースを継承すべきか。

使用目的が明示的になるの継承したほうが良いのか。
パフォーマンスのために継承はしないほうが良いのか。

具体的なデータを持つノードはXX以外にも多数あり、
またそれらはXMLのように互いを子要素として持つこともありえる。

皆様のご意見をいただきたく思います。

0427デフォルトの名無しさん

2010/09/25(土) 23:27:14

このスレ、OOPのスレなのに、なんで保守の話はしないんだろう？

0428デフォルトの名無しさん

2010/09/25(土) 23:34:39

話題を振ればいい

0429デフォルトの名無しさん

2010/09/25(土) 23:47:00

>>426
ツリー構造を管理するデータと、それ以外のデータが、同じ場所にあるのは、
のちの混乱の元にならないだろうか？
ちゃんと分けた方がいいかと。

0430424

2010/09/26(日) 00:06:18

>>429
レスありがとうございます。
いまいちそこまで考えが至りません。

もしよろしければもう少し具体的にお願いできますでしょうか・・・。

0431429

2010/09/26(日) 00:21:59

俺が同じアプリを作るなら、
1.ユーザーに提供するデータだけを保持するクラス。
2.1のクラスのインスタンスを集めて、ツリー構造にするクラス。
に、分けるかな。

1はシンプルにして、多様性をだしやすく、
2には色々めんどい事を任せる。

こうしておけば、1は簡単に拡張が出来るし、
後でハッシュ構造に変えたくなった時は、2を取り替えるだけで済む。

0432デフォルトの名無しさん

2010/09/26(日) 00:36:35

上の人とは別人だけど。
Tree単体で使うこともあるの？
そうでないならITreeの役割をTreeに移してしまえばいいと思う

また、XXTreeがTreeの子でない、というのは直感的でない
名前だけみたら、TreeがXXTreeの派生クラスだと勘違いする

ITreeはインタフェースなんだから、XXTreeはTree/ITreeを両方継承しても問題無いけど
上の例だと、そもそもTree/XXTree独自のメソッドがないから
クラス階層をわける意義が感じられない

それからvirtualは付けなくて良いんだっけ
最初Javaか何かかと思ったけどC++だよね？

0433デフォルトの名無しさん

2010/09/26(日) 00:44:41

下手な設計するよりはS式で持っといた方がいい
とりあえずLISPで検証できる

0434デフォルトの名無しさん

2010/09/26(日) 00:54:48

要素がVariantであるN木で持つのと同じじゃん

0435デフォルトの名無しさん

2010/09/26(日) 01:02:50

データ構造なんて配列とおなじじゃん？

0436デフォルトの名無しさん

2010/09/26(日) 01:03:04

考えるべき順番が全く違うんだよ
データ構造を定義する前にまず何をすんの？から始めないと
それが決まらんうちはXMLでもS式でもVariantでもDBでも使っとけばいいよ

0437デフォルトの名無しさん

2010/09/26(日) 01:06:22

そんなこといってたら、まず、プログラミングする必要があるのか？とかに発展してく。
最初から設定された問題の中で話をすればいいのに。

0438デフォルトの名無しさん

2010/09/26(日) 01:15:55

>>436
>>426はもうやりたい事は決まってるでしょ。
ツリー構造を使う必要があったり、データの多様性を出そうとしたりしてるし。

0439デフォルトの名無しさん

2010/09/26(日) 01:35:31

だからそれ作って何すんの
構造を眺めるだけですか

0440デフォルトの名無しさん

2010/09/26(日) 01:40:08

そうです

0441デフォルトの名無しさん

2010/09/26(日) 02:27:27

見る化

0442デフォルトの名無しさん

2010/09/26(日) 09:03:05

>>412
なるほど、カプセル化を「物事の整理の仕方」と考えているのか。
何件か質問させてもらう。
>誰がどのメモリ領域いじってるのか、この機能がどの機能に依存しているのか、
「誰がどのメモリ領域いじってるのか」と「誰がどのメソッド（Setter）いじってるのか」での違いは？
構造化でもサブルーチン・ローカル変数など制限できるがオブジェクト指向と何が違う？

>「オブジェクト志向」がいったい何を志向しているのかといったら
>それは「物事の整理の仕方」に他ならないだろう。つまりカプセル化だ。
「オブジェクト志向」=「物事の整理の仕方」=「プセル化」と考えているようだが
それは概念か、それとも方法諭か　実装もかみしているのか？

>>414
>データを扱うために、必ず特定の処理を通させる（つまりデータと処理がセットになる）ことで
>情報の隠蔽もなされるワケで。
その「特定の処理を通させる」は何の目的の為に行なうのか？、具体的に書いてくれ。
俺の考えでは「フィールドの情報隠蔽の為に、”特定の処理を通させ”るカプセル化を適用している」のよう考える。
「データと処理を一括りにすること」は手段だと考えるが、目的と考えているのか？そのメリットは？
まっ、メリットを書いてもらうとそれが目的だとなるが。

0443デフォルトの名無しさん

2010/09/26(日) 09:42:25

>>442
このメソッドを呼ぶときは事前にあっちのメソッドが呼ばれてないといけないとか
誰それがこういう状態を構築してなきゃ、このメソッドは成功しないとか
引数にはこれを生成して渡さなきゃいけないとか
この変数はこいつもいじってるから勝手に触っちゃダメとか

そういう膨大な依存関係が出来上がるだろう
これは開発規模が大きくなれば指数関数的に複雑になっていく。
ドキュメントちゃんと書けば済むじゃんと言われればそうだが
こういう依存関係に依存したバグが一旦出てしまったら捜索は厄介になりがちだ。

もちろん天才なら構造化だけの整理手法でもかなり対応できるとおもう。
でも、コードをオブジェクト単位でまとめると、さらに関係が整理しやすくなる、と。

0444デフォルトの名無しさん

2010/09/26(日) 10:45:05

おまえらカプセル化って言葉じゃ
ぼやけたイメージしか出てこないみたいだから
MVCのMの範囲とかで考えた方がいいよ
何のためにそんなことするのか

0445デフォルトの名無しさん

2010/09/26(日) 13:00:12

>>444
そんな事したらもっとぼやけるっていう。
てかカプセル化って、モジュール化をもっと使いやすくしたものなんだけどな。

0446デフォルトの名無しさん

2010/09/26(日) 13:01:59

単に、>>442も視点が違うだけでそんなに外したことを言ってない気もするが、
俺はどちらかというと、「依存関係の整理を支援するために、OOP言語の機能がある」
という>>443の説明の方が説得的だな。>>436とは違う意味だが、何をするのかが
決まらなければ、最適な言語機能を論ずることもできない。

もちろん、これは歴史的にどうだったかとか、アラン・ケイの意見がどうかというのとは
別の話な。

0447デフォルトの名無しさん

2010/09/26(日) 13:13:56

まともに色々と文献にあたった人でも「やっぱ正確な定義なんてどうでもいいや」ってなる厄介なtermらしいな>カプセル化
だからこそこのネタで盛り上ることができるわけだが

0448デフォルトの名無しさん

2010/09/26(日) 13:27:57

そりゃ、「何に対して」情報を隠蔽するのかが明らかでなければ定義なんてできないわな。

0449デフォルトの名無しさん

2010/09/26(日) 13:29:15

>>447
正確な定義はなくても、目的はモジュール化なのは確実だから、まだマシだよね。

0450デフォルトの名無しさん

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にも同様の考え方がある。
どのタイプも、数学的には存在型というコンセプトがベース

0451デフォルトの名無しさん

2010/09/26(日) 13:31:39

そもそもカプセル化って原典は何なんだ

0452デフォルトの名無しさん

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.

0453デフォルトの名無しさん

2010/09/26(日) 13:39:01

補足だけど、ブーチはUMLの人で、ヤコブソン、ランボーとともに3アミーゴとしてOOの世界では有名な人ね

0454デフォルトの名無しさん

2010/09/26(日) 13:52:01

確かに、欧米では既に常識となってる考え方が、日本だと全然普及してないってことはままあるからなぁ。

0455デフォルトの名無しさん

2010/09/26(日) 14:09:04

俺的には、カプセル化は内部データの外部への直接アクセスを禁止して
代わりにメソッドを用意し、内部的不整合な設定を起こさないようにするという理解。

例えば
・0～2までが設定可能なときにそれ以外の値が渡されたときに回避または例外発生
・２つの内部状態が連動して変化する関係の場合にメソッドが整合性を保って処理する
みたいに

特に２番目がないと使う側が考えることが増える。
アクセス制限もコードを読む上で無視できる目印になる。

0456デフォルトの名無しさん

2010/09/26(日) 14:12:03

カプセル化って、オブジェクトの内部状態が有効でない瞬間を他者に見せないしくみの事じゃねーの

0457デフォルトの名無しさん

2010/09/26(日) 14:13:17

オブジェクトに内部状態が有効でない瞬間があるの？
何のためのコンストラクタ？

0458デフォルトの名無しさん

2010/09/26(日) 14:15:25

メソッドの実行中

0459デフォルトの名無しさん

2010/09/26(日) 14:17:29

それただに分かりにくい言い換えな気がｗ

0460デフォルトの名無しさん

2010/09/26(日) 14:20:52

カプセル化されてなかったら、
「このメソッド実行してから、あのメソッドを開始するまでの瞬間、オブジェクトの動作が未定義になる」
ことがあるとおもうんだよね。

でも、カプセル化されてたら、おそらくprivateであろう「この」メソッドと「あの」メソッドの隙間は外からは全く見えなくなる

0461デフォルトの名無しさん

2010/09/26(日) 14:23:23

つまり
「内部的不整合な設定を起こさない」＝「内部状態が有効でない瞬間を他者に見せない」
じゃねーの？

0462デフォルトの名無しさん

2010/09/26(日) 14:29:27

それがつまり、「インタフェースによって、オブジェクトの機能を明示的に宣言する」ってことなんじゃないのかな。

0463デフォルトの名無しさん

2010/09/26(日) 14:44:38

>>460
そういう目的ならロジックとデータが一緒である必要は無いよね
例えば名前空間にアクセス権限付けてprivateな関数と変数を作れば事足りるよね

0464デフォルトの名無しさん

2010/09/26(日) 14:45:57

>>463
それクラスとどう違うの

0465デフォルトの名無しさん

2010/09/26(日) 14:46:55

>>464
インスタンスに出来ない所

0466デフォルトの名無しさん

2010/09/26(日) 14:47:56

>>463
それもカプセル化なんじゃないか？
違いはstaticか否かっぽいし。名前空間でロジックとデータが一緒なんじゃないの？

0467デフォルトの名無しさん

2010/09/26(日) 14:53:07

必ずしもクラスだからってロジックとデータが一緒が推奨されてるわけでもない
非メンバ化が可能なメソッドはできるだけそうする、ってのは割と一般的だと思うよ

0468デフォルトの名無しさん

2010/09/26(日) 14:53:58

それはまた別な話じゃないか？

0469デフォルトの名無しさん

2010/09/26(日) 14:57:10

ロジックとデータが一緒なのは、データ独立ではその有効性を維持するのに十分でないからだ

0470デフォルトの名無しさん

2010/09/26(日) 14:57:55

ロジックつまりは論理だな
操作的意味論を元にメソッドを考えると事前条件から事後条件への推論だ
データはその過程で用いられる仮定として捉えればデータもロジックになるなならないな

0471デフォルトの名無しさん

2010/09/26(日) 14:59:13

次はロジックとデータの定義だな頑張って

0472デフォルトの名無しさん

2010/09/26(日) 15:06:01

ロジックとデータが一緒じゃなきゃ、不正な操作を許してしまう事になると思うのだが

0473デフォルトの名無しさん

2010/09/26(日) 15:10:17

ロジックという言葉がアレっぽいからメソッドに言い換える

>>466
でもそれをオブジェクト指向と呼べるのだろうか
データとメソッドが一体になったもの(=オブジェクト)を変数に束縛出来なくてもオブジェクト指向言語と言えるのだろうか

俺が言いたい事は隠蔽はオブジェクトという考え方を導入しなくても出来るから
オブジェクト指向自体のメリットでは無いのでは無いか、と言う事な

0474デフォルトの名無しさん

2010/09/26(日) 15:13:16

>>473
いやカプセル化の議論だったからそういっただけ。
それにインスタンスがひとつしかなくてもオブジェクト指向と呼べないとはいえないと思う。
便利がどうかは別として。

0475デフォルトの名無しさん

2010/09/26(日) 15:15:30

メソッドとフィールドが一緒だからインスタンスが必要になるんだ。

0476デフォルトの名無しさん

2010/09/26(日) 15:16:16

データを状態と言い換えても同じ議論ができるか否か

0477デフォルトの名無しさん

2010/09/26(日) 15:17:45

面倒くさいとこいちいち丸投げすんなようざいから。

0478デフォルトの名無しさん

2010/09/26(日) 16:44:39

状態が複数あるっつうことはそれぞれの状態において違う仮定があるというわけだから
単純にその仮定をorで結合、つまり場合分けすりゃいいだけ
議論としてはまったく同じになる
ただそのデータの存在のみから導き出せる仮定が弱くなるから
そのデータのもつ責任をデータを扱う奴ら(*)が肩代わりしなくちゃならないので(*)が扱う事前事後条件が複雑になる

0479デフォルトの名無しさん

2010/09/26(日) 17:23:23

>>443
>このメソッドを呼ぶときは事前にあっちのメソッドが呼ばれてないといけないとか
>誰それがこういう状態を構築してなきゃ、このメソッドは成功しないとか
>引数にはこれを生成して渡さなきゃいけないとか
>この変数はこいつもいじってるから勝手に触っちゃダメとか
それだと、俺がいっている情報隠蔽に近いと思う。

>そういう膨大な依存関係が出来上がるだろう
>これは開発規模が大きくなれば指数関数的に複雑になっていく。
データの親子関係・依存関係を継承・コンポジションなどで整理するがこれはカプセル化とは別。
だから、「物事の整理の仕方」の一部は「カプセル化」がだが、「物事の整理の仕方」＝「カプセル化」ではない。

>>449
「モジュール化=カプセル化」は同意。ただ、じゃモジュール化って？　と聞かれたらまた意見が分かれると思う。

>>455
同意。

>>456
同意、RDBのトランザクションイメージだと思う。

>>463
>そういう目的ならロジックとデータが一緒である必要は無いよね
例えば、RDBとクライアントの関係のように？
目的は同じでも色々やり方があると思う。その一種がカプセル化なだけ。

0480デフォルトの名無しさん

2010/09/26(日) 18:06:59

>>479
443と449へのレスで「＝」がダブルスタンダードになってないか？

0481デフォルトの名無しさん

2010/09/26(日) 18:21:53

>>479
コンポジションはカプセル化の本領発揮ってとこでしょ。
継承は多態目的だからまた別。

そして確かに継承も整理の仕方の一つではあるが、
「依存関係を弱める」カプセル化とは真逆の、「依存関係を非常に強める」手法。
うまく使わないと整理どころか逆に厄介なバグを産みかねない恐ろしいもの。

入門書では継承を単なる便利な物としてしか教えないから
やたらめったら継承して「OOPってなんかおかしくね？」という結論になりがち。

0482デフォルトの名無しさん

2010/09/26(日) 18:32:41

C++で一番イヤなのは、クラス定義にプライベートなメンバ変数も書くとこ。
インタフェースの定義じゃなくて、クラスの定義なんだから、とか、
クラスのサイズを決定するために必要なんだとか、もうそういうのいいから。

もしあれが、インタフェースの定義だけをヘッダに書いて、
メンバ変数の定義を、cpp側に書く書式があれば、さぞよかったのに。

0483デフォルトの名無しさん

2010/09/26(日) 18:35:13

pimplパターンってのがあるよ。コンパイル時間も減るよ。

0484デフォルトの名無しさん

2010/09/26(日) 18:36:28

pimpl

0485デフォルトの名無しさん

2010/09/26(日) 18:44:47

>>483-484
( ；∀；)ｲｲﾊﾅｼﾀﾞﾅｰ
これはスカッとする。
ぼんやりと、ポインタ一つだけ持ってやりくりすれば…とは思ってたけど、
実際にやってた奴がいるのか…そりゃいるわな…。

0486デフォルトの名無しさん

2010/09/27(月) 01:12:21

pimplpomplpumpop

0487デフォルトの名無しさん

2010/09/27(月) 11:42:28

なんか、パンプル・ピンプル～って魔法少女ものなかったか？

0488デフォルトの名無しさん

2010/09/27(月) 19:28:37

クリィミーマミ

0489デフォルトの名無しさん

2010/09/27(月) 19:30:09

C++の奴はどっか別のところでやってくれないか？
お前らがいるとレベルが下がる。
他の言語では普通に出来ることをグダグダと。

0490デフォルトの名無しさん

2010/09/27(月) 19:36:07

>>489一人でレベル下げてんじゃねえよｗ

0491デフォルトの名無しさん

2010/09/27(月) 19:41:59

私もcppの人の話は、ちょっと．．．と思うことが多い。「pimplパターン」とか。

0492デフォルトの名無しさん

2010/09/27(月) 19:44:22

>>490
たまには面白いけど、やっぱりｃｐｐは×でしょう

0493デフォルトの名無しさん

2010/09/27(月) 19:54:19

おいおいC++厨が居なくなったら住人は１０分の１になるぞ。

レベルは１０倍高くなるがｗ

0494デフォルトの名無しさん

2010/09/27(月) 20:11:40

おいおい一人でレベル１０もさげてんじゃねえよｗ

0495デフォルトの名無しさん

2010/09/27(月) 22:28:43

C++の話が嫌なら、それ以外の話題振ればいいのに。
まあ、大した話は出ない気がするけど。

0496デフォルトの名無しさん

2010/09/27(月) 22:40:50

C++ちゃんと触ってない奴はオブ脳とかになりやすい

0497デフォルトの名無しさん

2010/09/27(月) 22:50:57

>>496がどういうのをオブ脳と言っているのかよく分からんけど、
C++はオブジェクト指向言語だよな？

0498デフォルトの名無しさん

2010/09/27(月) 23:10:35

C++は手続き型言語
ただオブジェクト志向（っぽいもの）が導入されただけ

0499デフォルトの名無しさん

2010/09/27(月) 23:15:35

>>498
世界的に、手続き+オブジェクト指向+ジェネリック、
のマルチパラダイム言語だといわれているのに、その主張は無理があるだろ...

0500デフォルトの名無しさん

2010/09/27(月) 23:17:37

オブ脳なんて言葉あったなｗ

0501デフォルトの名無しさん

2010/09/27(月) 23:49:05

ローレベルでoopやるならC++一択

0502デフォルトの名無しさん

2010/09/28(火) 05:08:19

>>491
pimpl ｗｗｗ

pimplは究極的にはコンパイル速度を早めるためだろ、あれはw

C++がダメっていったら、デザパタが一時期流行ったJavaもやばいだろ
LLだったら本にするまでもない分量ですむことをだらだらと本にして出す言語はどうなのかと

0503デフォルトの名無しさん

2010/09/28(火) 06:34:08

デザパタはJavaというより、静的OOPLだから本になるという感じ

0504デフォルトの名無しさん

2010/09/28(火) 07:54:27

LLのBASICばかにすんあ

0505デフォルトの名無しさん

2010/09/28(火) 11:18:14

BASICは行番号を廃止して、構造体を導入してあげればずいぶん組みやすくなすのにね。

0506デフォルトの名無しさん

2010/09/28(火) 11:32:52

構造化しないからこそのBASICでしょうよｗ

構造化しないとどんなことになるかを学ぶ。

0507506

2010/09/28(火) 11:34:06

あ、なんか駄洒落を言ったような、
構造体と構造化を混同したようなレスになっちゃったけど、
行番号にgotoするのがBASICのジャスティ巣。

0508デフォルトの名無しさん

2010/09/28(火) 13:30:44

昔はまともに使えるスクリーンエディタが無かったから行番号なんだろうな

0509デフォルトの名無しさん

2010/09/28(火) 13:42:47

おれはてっきりアセンブラのラベルを模倣したくて行番号いれたのかとおもったよ。
原始のＢＡＳＩＣって関数もなかったでしょ。

0510デフォルトの名無しさん

2010/09/28(火) 13:45:03

行番号はテレタイプで編集するのに便利だからだと思う。

FORTRANとかアセンブラの言語仕様はパンチカード寄りなんじゃないかと。

0511デフォルトの名無しさん

2010/09/28(火) 13:45:27

もちろん関数などない。
GOTOだけがトモダチさ。

0512デフォルトの名無しさん

2010/09/28(火) 14:05:10

>>505
VisualBasic、、、

0513デフォルトの名無しさん

2010/09/28(火) 14:11:21

いやいや、C言語にコンバート可能なXBASICを忘れては(ry

0514デフォルトの名無しさん

2010/09/28(火) 15:21:06

BASIC→Cトランスレーターは作りやすそうだが、
VB→CだとCOM操作とかで複雑度具合がまた違ってくるな

0515デフォルトの名無しさん

2010/09/28(火) 15:22:59

BAStoCの出番だな

0516デフォルトの名無しさん

2010/09/28(火) 20:23:41

N88BASICにはGOSUBコマンドがあった記憶が。
もちろん引数なんてものはないが。

0517デフォルトの名無しさん

2010/09/28(火) 21:35:09

ごく初期のTinyBASICとかでない限りGOSUBはあると思う。
RETURNが使えるGOTO以上のものではないし。

DEFFNはもうちょっと関数ぽいよね。

0518デフォルトの名無しさん

2010/09/28(火) 22:32:43

そういえばGosub引数って無かったなぁ。引数って大きな発明だなw

0519デフォルトの名無しさん

2010/09/28(火) 23:14:02

>>518
FORTRAN の SUBROUTINE には引数あるのにな…

0520デフォルトの名無しさん

2010/09/29(水) 00:19:45

でもコンピュータって計算するものだから、処理中心に設計しないとおかしいよね。
それが全てだよね。
オブジェクトを設計？何それ。
足りない頭で無理にややこしく考えても何の意味も無いと言う。まさに下手の考え休むに似たりだな。
それでも自分には多少の知性があるのだろうと勘違いしてしまう困ったチャンが多くて困るな。
周りを良く見て、そのまま素直に認知して、しかるべき仕事をする。
それ以上は求められてないのにね。
コンピュータって何？まずそっからやり直したほうがいいね。
小手先積み上げてもクソの山にしかならんのよ。

0521デフォルトの名無しさん

2010/09/29(水) 00:32:06

僕らの扱うコンピュータは、まぁCPUとか有って、計算が出来る訳だ。
そんで、それで何か計算して意味あることをしたい。これは基本理念だよね。
だから計算のバッチ処理の手続きをプログラミングする訳だ。プログラミングの本質だよね。
だけど、僕らの扱うコンピュータはとても賢くてメモリ領域なんか持っちゃったりしてて、
一時変数をそこに置いておけたりする。
だから、処理手順を記述することの他に、メモリ領域をどう分割するかって話も出てくる。
でも、処理手順を記述することと、メモリ領域をどう分割するかってのは本質的に別次元の話だから、
一緒くたにクラスやオブジェで全部やっちゃえってしたときに、どっかに無理が出てくる罠。
だってさ、自分が何か作業をするとき、
工具や材料を何処においておくかという話と、
どういう手順で作業をするかという話は、
別もんだろ。

0522デフォルトの名無しさん

2010/09/29(水) 01:00:52

Unixでは、$program < in > out こんなこと良くやったりするが、
プログラムは入力と出力の関係を定義している、と言えるだろ？
入力と出力の関係をprogramで定義している、と。わりとマトモな考え方だわな。
だけどここでOOPっぽくして、inputにget_outputってメソッドつける発想はマトモに思えない罠。
標準入力にメソッドがくっついてる訳もないのに、なんか変だ罠。
多機能ビューアが有って、
$viewer < image としたときに、imageの種類でviewerの展開アルゴリズムがスイッチしてってのは分かるんだけど、
だからって、imageファイルそのものに展開アルゴリズムを内包させちゃえってことにはならないよな。
だからMacバイナリはアホで、Macもアホなんだよ。
Unixの#!もアホなんだけどね。

0523デフォルトの名無しさん

2010/09/29(水) 01:08:13

>>521-522
PowerShellディスってんのかお前は

0524デフォルトの名無しさん

2010/09/29(水) 01:12:36

でもimageファイルには大体ヘッダがついてて、「自分は～の種類です」ってそこまでは表明してるんだよね。
これはいわばクラスを表明している訳だ。
しかし、種類は表明するけど、展開アルゴリズム自体は持っておらず、
それがどう扱われるかはプログラムにゆだねられている訳だ。
その辺が落としどころって事。

OOPの言葉で言えば、型やクラスは表明するけど、メソッドは持ってないってこったな。
そこがちょうどいい落しどころなんだ。
だから、型でスイッチすりゃいいし、それが嫌ならマルチメソッドを導入するこったな。

0525デフォルトの名無しさん

2010/09/29(水) 01:13:43

>>523
あれはもうどうしようもないよね。誰得言語。

0526デフォルトの名無しさん

2010/09/29(水) 01:24:55

それでもカプセル化はしたいって人は多いだろうから、
カプセル化はカプセル化で別の構文を用意することになるだろうね。

OOPのカプセル化と違って、もっとざっくりした物がいいね。
例えば、privateなフィールドには、自ネームスペース内からだけアクセス可能とか。
十分だと思うが。
もとより、それで整合性壊すようなら、プログラマ失格だろう。

0527デフォルトの名無しさん

2010/09/29(水) 01:34:24

Javaはよくできてると思う。GC必須でさえなければ・・・

0528デフォルトの名無しさん

2010/09/29(水) 03:07:49

コンピューターは処理中心と言う人が居るがそれは違うぞ。
その人はおそらく、「演算」「記憶」「入出力」を、ひっくるめて処理と言っていると思うが、
これらは全て「データ」が無ければ無意味なものだ。
演算はデータに対して行うものだし、
記憶はデータを扱うものだし、
入出力はデータをやり取りするものだ。
つまりコンピューターはデータ中心の物なんだ。

0529デフォルトの名無しさん

2010/09/29(水) 03:21:30

チューリングマシン知らないんだろう

0530デフォルトの名無しさん

2010/09/29(水) 03:23:49

んで、オブジェクト指向というものは、
データを中心にプログラムを考えていくもの。
なんでオブジェクト指向を使うということは、下手でも何でもなく、
コンピューターの仕組みにあったやり方をする訳で、
むしろ基本をちゃんと押さえた良い方法なんだ。
(正しく使えていればたが...)

0531528

2010/09/29(水) 03:27:50

>>529
ん？俺に言ってる？　まさかな...

0532デフォルトの名無しさん

2010/09/29(水) 03:53:38

それはもう言ってる事がてんででたらめだよ。
まるで、
数学は、計算は数に対して行うから、数が中心
と言ってるようなものだ。
でも、虚数はどうなる？虚数は意味をもってるけど、どうしてあんなありえもしない数が意味を持ちえる？
それは虚数に、i^2=-1という関係が定義してあって、それで破綻なく機能してるから意味をもてるんだ。
・機能してるから意味を持てる→functionは意味を与える
・機能は関係の定義で成り立つ
これが大事。

例えば、整数値のビット列はデータだけど、でも、演算が出来ないなら何の意味もないし、
数値と言っていいのかすら分からん、ただのビット列にすぎない。
CPUの中でビット列を整数値と見立てた場合の演算が定義されて、それが体を満たして、
他のビット列との相対的な位置関係が定義されて、初めて僕らの知ってる整数値の意味になる。

処理があって、コンピューティングがあって、初めてデータは他のデータと関係が持てて、
それで機能して、何か意味らしきものをもてるんだよ。

もう哲学の世界に行っちゃうけど、
社会や会社や他者との関係があって、初めて人間は意味を持てるっての。
この関係中心の考え方は、今の本流だよ。アメリカなんて機能主義そのものだろ。
機能が自分たちに個性を与える。機能は他者との関係で相対的に生まれるから、
関係を改善していくことで、自分の個性を変えて行くことが出来るっていう。
生まれながらの個性は、重視されない(ことになっている)っていう。

コンピュータで関係を扱ってるものと言ったら、function、処理、手続き、計算、演算、だよ。
ましてデータ中心なんて時代遅れもいいとこ。
物中心の考え方だと上手くいかなくなってきているのは、肌身で感じてるはずだが。

0533デフォルトの名無しさん

2010/09/29(水) 04:00:33

もう、
>>528=530
は完全にOOP脳だよ。
データ中心に考えるとか、思考停止もいいとこ。
データに意味なんて無いんだよ。それ意味を与えるのは機能であり、他データとの関係だ。
他データとの相対的関係で意味を持つんだ。データ自身に絶対的な意味があったりはしない。
自分でコンピュータ、計算機と言っておいて、それがデータ中心の物とか・・・正気かよ。
コンピュートの意味分かってるのかよ。コンピュートするためには相手が要るんだぞ。
1+1は、「+」が間に割って入ってるだろ、だから、「+」が中心なんだ。

0534デフォルトの名無しさん

2010/09/29(水) 04:19:48

そして、こういった考え方はUnixの根底に流れているものだよ。
データはデータでしかなく、それをどう扱うかまでは決めないっていう。
だからパイプで流したり、データをエディタで編集したり、と、わりと柔軟に対応できる。
そのやり方が優れていたからUnixは成功したんだよ。
ただの画像データに展開用のコードまで内包されてたら嫌だろJK。
どう扱うかはこっちで決めさせろ。んでそれ決めてデータに新たな意味を与え、機能させる。
発展性、創造性。

0535デフォルトの名無しさん

2010/09/29(水) 04:35:20

そういやデータ型定義で型制約与えずに、その定義されたデータ型を扱う関数で型制約与えるべき
っていうイディオムがあるな

0536デフォルトの名無しさん

2010/09/29(水) 04:44:06

まー、画像というデータをただ開くだけでも、アプリケーションによって多態するわな

0537デフォルトの名無しさん

2010/09/29(水) 05:27:05

>>522
自己解凍アーカイブを全否定しておられる？

0538デフォルトの名無しさん

2010/09/29(水) 05:38:12

なんかデータ自体には意味が無いとか言ってるけど・・・。

そもそも機能はデータを操作するものだよね？（違うって言われたらお手上げ）
んで、新しいデータを作る。

ここでもし、その作ったデータに意味が無かったら、そんなデータいらないよね？
そんなことになったら、なんでそんなことしたんだよってなる。

じゃあなんでそんなことをするのか？

それはそのデータは意味があるものだからだ。
意味があるからこそ、そのデータを作るしそういう機能も必要になる。
データありきなんだ。
データが意味を持っているからこそ、機能には存在意義がある。

もし>>533が言うようにデータに意味が無かったら、機能なんていらない。
何故ならそれに目的は無いからだ。（あるって言われたらお手上げ）

0539デフォルトの名無しさん

2010/09/29(水) 06:09:23

機能によってデータが作られるという考え方もある(例:ADT)
外延と内包とでも言おうか

0540デフォルトの名無しさん

2010/09/29(水) 06:15:04

>>539
それ>>538の前提ですよ？

0541530

2010/09/29(水) 06:21:50

それにしても、いろいろ考えているうちに考えが変わっちゃったなあ。
で、新しい考えがこれ。

オブジェクト指向とは。
データと機能が合わさって生み出す目的を中心に考えること。

よく考えたらデータだけじゃ意味をなさない。
そのデータの使い道が無いといけない。その使い道を生み出すのは関係と言う名の機能だろう。

だからと言って機能だけでも意味をなさない。
機能だけでは対象が存在しない。そんなものを誰が必要とするのか？

ようするに両方とも必要なんだと。
どっちかが掛けても意味をなさないんだ。
だったらそれをまとめて管理しちゃえばいいじゃない。

0542デフォルトの名無しさん

2010/09/29(水) 06:23:51

データのもつ意味とか何か、データとは何か、機能とは何か、存在とは何か
OOPから学ぶ哲学のこころという本でも出す気かお前らは

0543530

2010/09/29(水) 06:32:43

>>542
サーセンｗｗｗ

でも、この議論をしたことで、オブジェクト指向を上手く説明できるかもしれない。

0544嘘だけど

2010/09/29(水) 06:35:23

データと機能両方を区別なく考える手法としてはデザインパターンで学ぶオブジェクト指向のこころで提唱されている「責任」という概念かな
機能の分割じゃなくて責任の分割
データや機能が何を保証して何を保証しないのか、
それらの保証する所をうまく組み合わせたり、新しく作っていったりして
最終的に仕様が満たされることが保証できるものができればそこでプログラムは完成することになる
仕様という論理をどう導いていくのか、これは証明を補題や場合分けを使って構造化するのと似ている
これを公理的意味論で解釈したのがかの有名なdesign by contract
この考え方だと論理がベースにあるんで、扱う言語が関数型であろうが論理型であろうが一般のOOPLであろうが関係ない

0545530

2010/09/29(水) 07:12:32

オブジェクト指向をカーレースで説明してみる。

まず、カーレースには何が必要だろうか。
とりあえず車は必要だろう。
車を走らせるサーキットも必要になるだろう。
観客も居た方がいいかもしれない。

レースなんだから相応のルールが必要だろう。
それを守らせる審判も必要だ。
結果の記録する係も居ると便利だろう。

以上の物を用意すればとりあえずレースは出来る。
実際これで１レース行われる。
そしてレースが終わった後解散した。

（続く）

0546530

2010/09/29(水) 07:13:32

後日、またレースをしたくなった。
前回と同じものをまた用意する。
主催者は、レーサー達が前回の経験があるので、よりいいレースが出来るだろうと期待した。
そして準備をする。
しかし、準備をするスタッフが変わっていた。
そのスタッフは前回のレースのことを知らない。

そして、出来あがったものは形は似ていても、細かいところは違っていた。
サーキットの形は違うし、観客席の位置は違うし、審判だって変わっている。
実際これでレーサーたちや観客は混乱した。
目的は前回と同じはずなのに、上手くいかないのだ。

結局１回目のレースとあまり変わらない物になってしまった。
いや、むしろ前回より悪化しているかもしれない。

主催者は考えた。
どうすれば、細かいところも同じにできるだろうか。
結論は設計図を作ることだった。
設計図があればたとえスタッフが違っていても、まったく同じものが作れるだろうと。

（続く）

0547530

2010/09/29(水) 07:14:51

そして、またレースを開催した。
またスタッフが変わっている。
しかし、今回は細かいところも変わっていない。
実際大した混乱も無く、レースは大成功を収めたのだった。
設計図を用意した効果が出たのだ。

これはプログラムの世界でも同じことができる。
クラスを使えばいいのだ。
クラスという設計図があれば、人が変わっても現場が混乱することは無い。
まったく同じものを作る限りは・・・

・・・ってこれ長いよ！　書くの飽きたし。（続きの構想はある）

0548530

2010/09/29(水) 07:20:44

しかもなんか変な感じになってるという・・・
俺が書きたかったのはこんなんじゃねえ！

0549デフォルトの名無しさん

2010/09/29(水) 08:13:36

>>544
役割を果たす責務と、機能を表明するものとしてのインタフェースだな。

0550デフォルトの名無しさん

2010/09/29(水) 08:27:49

GCない言語を作るのは簡単。
動的になにも確保できないだけ。

0551デフォルトの名無しさん

2010/09/29(水) 09:14:41

確率的メモリ

0552デフォルトの名無しさん

2010/09/29(水) 09:48:05

OOPの肝は権限の委譲だってばっちゃが言ってた

0553デフォルトの名無しさん

2010/09/29(水) 21:36:07

>>533
お前の考えならコンピュータは要らない、電卓があれば十分だ。

0554デフォルトの名無しさん

2010/09/29(水) 22:56:45

またなんか長文書いている人とか居るけど、まったく意味わからんし、どうよこれ。
説明能力の無い奴が設計できるかっつーはなし。

データだけでは意味が無いってのは分かってもらえたようでよかった。
機能が無きゃデータに意味を持たすことは出来ないんだよね。
それ分かっただけでも凄い前進だよ。
そんで、データと機能は両輪のようなものって言う言葉も聴けた。
それはその通り。昔っからそうで、社会と人民は両輪で、どちらが欠けてもダメ。
そこのバランス感覚が「判断力」という奴で、どこに行ってもその人の評価の対象となる箇所。大事だよ。

んでまぁちょっと変なのは、
データだけじゃ意味無いからデータに機能を持たせれば意味も持てるねっていう、
それがOOPの基本的な考え方なんだけど、それが変なんじゃないかって言う、そこの議論をしてたんだよね。
データに機能をもたせるったって、そのデータ単体で自分の機能を決めることは果たして出来るのかって。
青年が一人で自分の機能はこれこれですって叫んで、それが社会で通用するのかって。

データの意味は、他のデータとの相対的な位置関係で決まってくるものだから、
そのデータ単体にメソッド持たせても意味無いだろう。
例えば、1は2の半分だし、2は1の倍と定義されているから、機能するし、道具として使える。数学はそれで成り立ってる。
1や2が本質的に何者かなんてのはどうでも良く、ただ、お互いの相対的な関係だけ定義されてればそれで良い訳だ。
だから、1にメソッド持たせるのは気持ち悪いし、マルチメソッドが良いんじゃないかって。
マルチメソッドの無いOOPは罠だろうと。

0555デフォルトの名無しさん

2010/09/29(水) 23:07:15

データと機能がプログラムの両輪ってのはもちろんそうなんだけど、
ただ、その位置関係がさ。
機能はデータとデータの間に割って入ってデータとデータの関係を定義するものだから、
データ自体に機能を持たせるのは発展性がないだろうという。
分かりやすい例では、プログラムは入力と出力の関係を定義してるっていう。
Unixでは、$program < in > out とか書くけど、これは、
inとoutの間にprogramが割って入って互いの関係を定義している訳だ。
この割って入るものが、inかoutのどちらかにくくり付いているのは嫌だろ。
だって、inとoutにどういった関係を持たせるかはこちらで指示したいから。
inやoutに求めるのは、せいぜい型情報を提供することぐらい。

0556デフォルトの名無しさん

2010/09/29(水) 23:19:24

またなんか長文書いている人とか居るけど、まったく意味わからんし、どうよこれ。

0557デフォルトの名無しさん

2010/09/29(水) 23:24:03

3行超えるひとはトリつけろ

0558デフォルトの名無しさん

2010/09/29(水) 23:28:39

いつもの人だけど、文体に特徴を持たせるように気をつけてるよっていう。

0559デフォルトの名無しさん

2010/09/30(木) 00:25:58

知ってるか、
情報というのはそれ単体でエネルギーとして扱えるんだ、
1bitの情報が何カロリーか計算できてしまう。

つまり情報ってのは存在そのものなんだ。わかるか？

0560デフォルトの名無しさん

2010/09/30(木) 00:29:34

じゃあ32GBは何カロリー？

0561デフォルトの名無しさん

2010/09/30(木) 00:32:54

いつもの人は毎回毎回おんなじ事を違う言い方してるだけで、全然説得力がない。

ずっと「これ、気持ち悪くね！？」って言ってるだけっていう

0562デフォルトの名無しさん

2010/09/30(木) 01:15:05

例の人的に高階関数ってどういう解釈になるんだろう。

0563デフォルトの名無しさん

2010/09/30(木) 01:22:01

少し前に「カプセル化と継承のどっちがOOPの本質か」みたいな話があったが、

データと処理の細部を隠蔽して、オブジェクトの責務を公開インタフェースとして見せるためにカプセル化が重要で、
一方で、同じ責務を持つと同時に、異なる細部を持つオブジェクトを許容するための仕組みが継承、

という考え方はどうかな。

0564 ◆o0jv9vCVwU

2010/09/30(木) 13:41:01

>>563
いいと思う。

最近何となく思ったんだけど、
オブジェクト指向はもしかしたら、ジェネリックプログラミングがやりたかったのかもしれない。

カプセル化でデータを扱う機構の、インターフェースを合わせ、
継承で複数のデータ型を同じ枠組みにまとめ、
ポリモーフィズムで複数のデータ型を適切に扱い、
それでも不十分なら動的束縛（Ｃ＋＋には無いけど）で対処する。

なんとなくジェネリックぽくね？

0565デフォルトの名無しさん

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
ないな
いかれてる

0566デフォルトの名無しさん

2010/09/30(木) 15:55:30

Ｃでもジェネリックできるが

0567デフォルトの名無しさん

2010/09/30(木) 17:32:49

>>654
センスないよ君

0568デフォルトの名無しさん

2010/09/30(木) 17:33:34

>>564
センスないよ君

0569デフォルトの名無しさん

2010/09/30(木) 17:50:27

みんな～、>>568はセンスあること書き込んでくれるってさｗｗｗ

0570デフォルトの名無しさん

2010/09/30(木) 18:04:40

俺も彼はセンス無いと思うよ。
センスってのは感性だろ？言うならば物差しや整頓棚。
ごちゃごちゃに散らかってる様を指してセンス無いと称される。

0571デフォルトの名無しさん

2010/09/30(木) 18:49:45

単なる話題振りにも攻撃するとか必死だな。

0572デフォルトの名無しさん

2010/09/30(木) 18:59:38

Update()と文字数がそろったほうが美しい

0573デフォルトの名無しさん

2010/09/30(木) 20:25:20

>>564
なるほど、そういう考えも出来るな。
ジェネリックプログラミングとオブジェクト指向は相性もいい。

しかし、FORTRAN/COBOLから始まった高級言語の目的は
いかにプログラミングを抽象していくかだから
別にオブジェクト指向に限ってないと思う。
構造化言語にもジェネリックプログラミングが導入されていたし。

目指す方向はどの方法でも根本は同じだからね。

0574デフォルトの名無しさん

2010/09/30(木) 20:46:35

LISPディスってんの？

0575デフォルトの名無しさん

2010/10/01(金) 18:06:07

リスってます

0576デフォルトの名無しさん

2010/10/01(金) 20:16:47

(CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAR '((((((((((((((((((((((((((((((((((((
おまえは今まで使った括弧の枚数を覚えているのか？)))))))))))))))))))))))))))))))))))))

0577デフォルトの名無しさん

2010/10/01(金) 21:15:25

まあLisp使いは実際、あんまり括弧のこと考えてないよね

0578デフォルトの名無しさん

2010/10/02(土) 00:49:17

>>577
そんなことない！
見える括弧と見えない括弧があってだなぁ…………
# let 直後とかの各個は良く見えるもん

0579デフォルトの名無しさん

2010/10/04(月) 16:43:48

OOPまったく関係ないけどさ
PHPやらcgiとかサーバーサイドの言語で無限にファイルを作成するプログラム組んだらどうなるの？

0580デフォルトの名無しさん

2010/10/04(月) 16:55:01

まったく関係ないからもう書き込むなよ。

0581デフォルトの名無しさん

2010/10/06(水) 18:19:54

C/C++ のテンプレートプログラミングもジェネリックぽいよね

0582デフォルトの名無しさん

2010/10/06(水) 18:41:49

ジェネリックがテンプレートもどきなんじゃね

0583デフォルトの名無しさん

2010/10/06(水) 19:57:50

テンプレートの最も多い用途に特化したのがジェネリックじゃね

0584デフォルトの名無しさん

2010/10/06(水) 23:08:21

ジェネリックというとソースコードを自動生成するのか
ソースコードで生成したプログラムでデータを自動生成するのか
どっちのこと？

0585デフォルトの名無しさん

2010/10/06(水) 23:39:40

前者はジェネレイティブプログラミング
後者はよくわからないが、ジェネリックとは違うと思う

0586デフォルトの名無しさん

2010/10/07(木) 01:27:00

>>581-585
頭の悪い会話
みなくていい

0587デフォルトの名無しさん

2010/10/08(金) 13:50:08

HTMLコードをCでジェネレートした
画像一覧を表示するページで６００枚ほど表示させる<a href=... ></a>
とforでまわしてジェネレートして表示しようとしたら
ＩＥが固まった
１ページで表示するには何枚くらいが妥当？

0588デフォルトの名無しさん

2010/10/08(金) 18:47:52

おまえのパソがへぼいだけです

0589デフォルトの名無しさん

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で動的に少し見える範囲だけ表示というようなモダンなつくりは応用可能だとは思う)

0590デフォルトの名無しさん

2010/10/09(土) 23:20:57

オブジェクトをカプセル化カプセル化・・・って依存関係をガンガン切っていくと
確かに個々のオブジェクトの仕事はシンプルになって保守しやすくなるんだけど
何かちょっと新しい仕様を入れようと思うと、、、

このオブジェクトにアレを追加して、
あっちのオブジェクトからあのデータもらって、
そのデータをこっちのオブジェクトに渡して、そっから更にこっちに渡して
ここで処理をやって、そしたら結果をこいつに渡して・・・

ってすごい勢いでいろんな処理の流れがタライ回しのように飛び交ってしまう。
依存関係を切れば切るほどメッセージングの量が膨大に増えていく。
これって良くなってるのか？ってたまに思ってしまうんだけどそんな経験みんなないかな

OOPってカプセル化された個々の処理はシンプルになるけど、
全体の処理の流れが凄く分かりにくくなる欠点があると思う

0591デフォルトの名無しさん

2010/10/10(日) 00:19:06

バランス感覚の問題

0592デフォルトの名無しさん

2010/10/10(日) 00:37:32

カプセル化を控えると再利用が効きにくくなりコードのコピペが増えるので
一概にそうも言えない

0593デフォルトの名無しさん

2010/10/10(日) 01:28:12

全体の流れはデバッガにでも流せば何となく判るからいいや

0594デフォルトの名無しさん

2010/10/10(日) 02:29:41

>>590
そのためのテスト(テストファーストとか振る舞いとかの方の)だし、リファクタリングしろって流れじゃないのかな

0595デフォルトの名無しさん

2010/10/10(日) 02:30:52

あ、OOPのカプセル化とは直接関係がないなスマソｗ

とにかく直すの前提じゃないかといいたかった

0596デフォルトの名無しさん

2010/10/10(日) 02:56:14

コピペを減らしたいならマクロがある
コピペを減らしたいからってカプセル化するのは馬鹿

0597デフォルトの名無しさん

2010/10/10(日) 03:34:29

え？

0598デフォルトの名無しさん

2010/10/10(日) 11:45:19

モデルの段階のミスはコードのリファクタリング以前に検知して直したいな
コード書く前、いやクラス設計とか考える前ぐらいにさ
なんかいい方法ないのかな

0599デフォルトの名無しさん

2010/10/10(日) 13:41:46

>>598
ハード屋業界には結構そのためのツールあるのにな…
ソフトでもj十分使えるんだが, あの手のモデリングシミュレーションツール

ソフト屋がアホで使えてないだけ???

0600デフォルトの名無しさん

2010/10/10(日) 14:19:22

設計のミスと片付ければ簡単だが、
それ自体は特に問題があるようには見えず、シコシコ実装すれば最終的に綺麗に出来上がるわけだ。

この機能が必要だから、あのオブジェクトをメンバに入れて、
この機能とこの機能を連携させたいから、ここであのオブジェクトのメソッドを読んで・・・

ってやってくわけだが、どうにもやりたい事に対してコーディング量が増えすぎてる気がしてならない。
とはいえ、仕様の規模が大きくこれ以上の粒度でのカプセル化は考えにくい。
コーディング量は増えてる代わりに、膨大な仕様にもかかわらず混乱なく実装できてると言ってしまえばそうなんだが・・・

0601デフォルトの名無しさん

2010/10/10(日) 14:59:47

なんか、好き勝手の縦横無尽にコーディングして
あとから依存関係を視覚化してくれるような物が無いかなぁ。

0602デフォルトの名無しさん

2010/10/10(日) 15:09:53

>>600
> 膨大な仕様にもかかわらず混乱なく実装できてる

ある程度以上の規模になると、それが一番重要なことだと思うけどなー。
依存関係がごちゃごちゃになって破綻したコードの変更ほど悲惨なものはない。

0603デフォルトの名無しさん

2010/10/10(日) 15:17:05

やりたいことは、

A　→　B

でもコーディングは、

A　→　Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB

だったりする。
しかもそれぞれのオブジェクトに担当者がいる。

ひとりでやれば５分で終わることが、（カプセル化されてなければ１分で終わることが）
まず担当者に機能追加の相談をしにいく事から始まる。
これはしょうがないのだろうか。

0604デフォルトの名無しさん

2010/10/10(日) 15:35:45

それだけ見るとすごく駄目な設計に見えるんだけど……

0605デフォルトの名無しさん

2010/10/10(日) 15:39:26

ある程度離れたオブジェクトにアクセスする必要があるってだけの例えだよ。
アクセサ辿るのメンドイからシングルトンにしましたってのも違うしなあ

0606デフォルトの名無しさん

2010/10/10(日) 15:44:48

これってカプセル化されてなかったら簡単というよりグローバルにしたら簡単っていう話じゃないか？

0607デフォルトの名無しさん

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
についても同じ。基本クラスの部分は用意しなくていいけど。

0608デフォルトの名無しさん

2010/10/10(日) 15:47:21

カプセル化しないってのはグローバルって事だろう

0609デフォルトの名無しさん

2010/10/10(日) 15:58:51

>>607
そうそう、いざそれを実装するのが超面倒というわけ。
仕様が複雑だとこれだけじゃ機能がちょっと足りなかったねって事がよくあるし
実際そんなにしっかり仕様が決まっていることもなく、アプリの上の方では頻繁にありうる。

本当は他のクラスの詳細なんて知りたくないんだけど、
いったん「あれ、あの状態っていったいどこから取得するんだ？？」ってなったら
結構な勢いでいろんなクラスに穴を開ける作業が発生する。

0610デフォルトの名無しさん

2010/10/10(日) 16:03:27

>>608
全然違う。それだと、グローバル変数に束縛したらどんなオブジェクトもカプセル化出来ていない事になる

0611デフォルトの名無しさん

2010/10/10(日) 16:04:53

いくらグローバル変数でも、そのprivateメンバにはアクセス不能なんだからカプセル化はできてるのでは

0612デフォルトの名無しさん

2010/10/10(日) 18:31:28

>>611
カプセル化は目的ではなくて手段。
グローバルなオブジェクト自体がいつ、どこからアクセスされるのか分からない状態に陥るわけで、
それによって変更に弱くなるし、厄介なバグの遠因になる。

0613デフォルトの名無しさん

2010/10/10(日) 18:38:11

>>609
当初考えていた設計が不適切だった、ということ自体は、当然起きうる。
そこでリファクタリングしてインタフェースを切り直し、より適切な設計に近づけて行く。

あるいは、「ある担当者が一つのクラスのクラスを担当する」という体制自体の問題かもしれない。
その現場を知らないから断言はできないけど。

0614デフォルトの名無しさん

2010/10/10(日) 18:41:42

>>612
そんなことはみんなわかってるよ。
だがカプセル化したらメッセージのタライ回しが増え、
ある程度実装に時間がかかるようになる傾向があるのも事実だろう。

それなんとかする方法ないの？ってのはOOPの命題じゃね。

0615デフォルトの名無しさん

2010/10/10(日) 18:51:22

>>614
あるオブジェクトから、遠く離れたオブジェクトの状態が欲しいということが頻繁に起きるなら、
それはそのオブジェクト間に本質的な関連性があるか、あるいはインタフェースの切り方が不適切か、
のどちらかじゃないのかな。

0616デフォルトの名無しさん

2010/10/10(日) 18:56:06

>>613
担当の分け方が不味いのは確実にそうなんだが
余裕のあるプログラマから必要になった仕事を割り振っていかないと回らない現実もあるんだよな。
本当は全員がどのコードでも弄れるってのが良いのかもしれないが規模が大きくなると大変だ

クラス間のメッセージングを実装するのに、まず担当プログラマ同士で口頭メッセージングなんて笑い話だが
実際そのようになってしまっているのでなんとかしたい。

0617デフォルトの名無しさん

2010/10/10(日) 19:02:39

>>616
確かに、ある機能単位ごとに担当者を割り振る、というのがそこまで不適切かと言われると、現実的にはそうかもね。
クラス単位じゃなくて、もっと大きな機能単位（モジュール?）ごとに割り当てればいいのかなぁ。
アジャイルとかだと、そのへんどうしてるんだろう。

0618デフォルトの名無しさん

2010/10/10(日) 19:04:32

>>603の例はAのスコープから参照出来るようにクラスメソッドとか作ればある程度解決するんじゃないか

0619デフォルトの名無しさん

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」を得るのに
それぞれの担当者に掛け合う必要あるという話でいいのかな

0620デフォルトの名無しさん

2010/10/11(月) 03:22:44

現状の現実をベースに考えると設計を崩さざるを得ない。
極度に納期主義、実績主義で、リファクタリングなんか
ほとんどさせて貰えず、腐った増改築が繰り返されるだけだ。

まぁうちの会社だけかも知れないけど。
参考までに言うと家電組込系。

0621デフォルトの名無しさん

2010/10/11(月) 09:45:36

>>614
>カプセル化したらメッセージのタライ回しが増え、
>ある程度実装に時間がかかるようになる傾向があるのも事実だろう。
そもそもメッセージのタライ回しがオブジェクト指向の基本。

>それなんとかする方法ないの？ってのはOOPの命題じゃね。
これも違う、コンピュータの処理速度が上がったからオブジェクト指向が受け入れられた。
いまは「ソフトウェアの生産性＞処理速度」の時代。（処理速度が上がってMS-DOSからWindowsになったのと同じ）

そもそもオブジェクト指向はソフトウェアの再利用を促進して生産性を上げる手法。
その為に事前に再利用の準備が必要になり、コーディング量は増える傾向にある。

例えば家電で例えると、家電を作ったが電源を取る為にコンセント用プラグを装着しないといけない。
また、部屋の方もコンセントを準備しないといけない。
これらは、本来電化製品を使うには必要ないものだ（昔は電球のソケットから電気を取っていた）
しかしコンセントが無いと非常に汎用性が無くなる。
コンセントやプラグは再利用の為のコストで、これと似たようなことをオブジェクト指向でも求められる。

0622デフォルトの名無しさん

2010/10/11(月) 13:06:06

そのタライ回しの部分がC時代から進歩してないから、何とかしろって言ってるんだろ。

0623デフォルトの名無しさん

2010/10/11(月) 13:10:16

だいたい、自分で「タライ回しがOOPの本質」とか言っといて、
その本質部分のタライ回しの、つまりは制御構造は昔から全然進化してないってどういうことよ。
だから、その部分が今後の課題って意見は凄く真っ当だろ。と、いつもの人は思った。

0624デフォルトの名無しさん

2010/10/11(月) 13:12:15

例え話が出てくると、途端に分かりづらくなる。
電気プラグは関係ない。
電球ソケットは十分汎用的だった。
ソケット数が足りなかっただけだ。

0625デフォルトの名無しさん

2010/10/11(月) 13:16:21

OOPLに於いて、制御構造は微妙に変化したと思うよ。多態に変わった部分があるからね。
まあ以前から関数ポインタとかで出来たかも知れんが、あまり日常的ではなかった。

0626デフォルトの名無しさん

2010/10/11(月) 13:20:40

その多態による変化が進化か退化か判断つかないところがあるから困ってるんだろ。
ようは、オブジェクト単で制御構造をぶつ切りにするから、そのクッションとして多態が必要になったんだけど、
制御構造的にはそれってどうなんよと。
ただ、よりいっそうオブジェクト寄りの思想になったことだけは確かなんだけど、
それもどうなんよと。物主体ってのはなんかアホっぽいし、なんかちょっと変な方向へ向かってるような悪寒。

0627デフォルトの名無しさん

2010/10/11(月) 13:25:33

で、当たり前、オブジェクト同士のコミュニケートで皆困ってる罠。
電気回路だったら、ICに足がいっぱいあって、それつなぎ合わせると、後はある意味勝手にコミュニケートするんだけど、
ソフトは逐次実行で流れ作業だからなぁ。
本来物理現象で勝手に行われることを、逐次で自前でやってる訳で、
現実世界と同じ理屈はなかなか当てはまらないと思う。
その辺数学はうまく切り抜けてるけど、ただ、数学は概念でしかなくて、そこから落とし込まないと製品を作れ無いと言う。
困ったね。

0628デフォルトの名無しさん

2010/10/11(月) 13:30:21

まぁ100年後には全部FPGAになるかもしれんし、こんな議論も全部意味なくなるかもな。
ただ、100年後にはここにいる誰も生きていないがな。

0629デフォルトの名無しさん

2010/10/11(月) 13:32:50

>>625
> まあ以前から関数ポインタとかで出来たかも知れんが
へたな OO 設計より,
十分ドキュメント化された,, 有効な hook を提供してくれるソフトの方が
運用的には役立つな.

0630デフォルトの名無しさん

2010/10/11(月) 13:38:18

Gtkとかな。わかります。
もしアレがオブジェクト指向だったら嫌だよな。ボタンクラスを継承してくださいとか、うへーー。

0631デフォルトの名無しさん

2010/10/11(月) 13:40:44

新しい技術に対応できなくなったリストラ候補のスレ

0632デフォルトの名無しさん

2010/10/11(月) 13:48:52

>>631
で、全継承クラス眺めてるひまがあんたにあるんかい?
つか >>629 の言ってるのはある意味真実じゃね？
現場に会わせて特化させようにも山ほど書類が…
てな、現実は無しにしてほしいいわ

0633デフォルトの名無しさん

2010/10/11(月) 14:02:41

どっちかっつーとそれは、書類のほうの設計をそろそろ見直さなきゃならんのでは
OOPに適した書類管理方法を提唱しなければならんな

0634デフォルトの名無しさん

2010/10/11(月) 14:40:30

もうある
なんというリストラ候補
こんな時間に・・・ガチだなこれは

0635デフォルトの名無しさん

2010/10/11(月) 14:43:52

ある課題をソフトウェアで解決する場合、いろいろな方法で行なっても難易度自体は変らない。
（その方法の中でベストなものが前提だが）

一般的に、その方法は三つある。
・難易度をアルゴリズムで解決する方法。（FORTRAN,C言語など）
・難易度をデータ構造で解決する方法。　（ＣＯＢＯＬ,Ｐａｓｃａｌ言語など）
・難易度を構造で解決する方法。　　　　　（オブジェクト指向言語など）
　（構造化言語からオブジェクト指向言語に拡張した言語を見ればわかるが
　　アルゴリズムに関する拡張はなく、構造に関する拡張のみ）

だからオブジェクト指向でメッセージが多くなるのは当然
それを回避したいなら別の方法で行なうしかない。

0636デフォルトの名無しさん

2010/10/11(月) 14:43:55

javadocとmvn testじゃだめなの？

0637デフォルトの名無しさん

2010/10/11(月) 14:46:54

>>630
最近はそこらへんはさ、継承でも出来るけど
デリゲートつかってくださいってかんじじゃねえか？

まあ要するにフックなわけだ。

0638デフォルトの名無しさん

2010/10/11(月) 14:55:52

うん、でもデリゲートはOOPの範疇じゃないと思うんだ。

0639デフォルトの名無しさん

2010/10/11(月) 14:56:31

あるインタフェースを持つオブジェクトを利用する側が、
利用される側の内部のメッセージのたらい回しのされ方を気にしなきゃいけない状況が頻繁に発生するなら、
それは設計の段階でインタフェースの切り方を間違っていた可能性が高いわけだから、修正する必要がある。
従って、配線のやり直しは必要なコスト。

と、まぁ原理的にはこうなる。
上で出てたみたいに、そんなことできる開発体制じゃないんだよ、という意見はあるにせよ。

ただ、これはそもそも依存関係の整理という利得を得るためにやってるわけだし、
そことのトレードオフをどう考えるか、という話になるのかな。

0640デフォルトの名無しさん

2010/10/11(月) 14:58:59

>>638
最近のOOPの実践では委譲(delegate)の方が重要視されてると思うが？

0641デフォルトの名無しさん

2010/10/11(月) 15:03:18

その、利用される側、とか、利用する側、とか、って発想おかしくない？
1+2で、1が利用する側、2が利用される側ってことになるか？
しいて言えば、+が1と2を利用しているとは言えるかも。
+はプログラミング言語で言えば関数なんだから、
関数が引数を利用する、で良いんじゃないの？
オブジェクトがオブジェクトを利用するってｵｶｼｲ

0642デフォルトの名無しさん

2010/10/11(月) 15:05:14

>>640
それがOOPが崩壊してきたって事でもあると思ってる。
C++の連中もテンプレートばっか注力しているようでなによりです。

0643デフォルトの名無しさん

2010/10/11(月) 15:09:36

>>641
利用側と被利用側に切り分けることで、各オブジェクトの責務を明らかにでき、
結果として依存関係の整理に役立つ。
四則演算の例は単純すぎるし、演算子のどちらの項も同じ型なわけで、例として適切でもない。

0644デフォルトの名無しさん

2010/10/11(月) 15:11:33

違う型だったらいいの？1+2.0とか。

0645デフォルトの名無しさん

2010/10/11(月) 15:12:04

>>642
古い継承ベースのOOPが、な。
mix-inみたいな柔軟な仕組みが使えるなら、また少し話が変わるかもだが。

0646デフォルトの名無しさん

2010/10/11(月) 15:16:10

>>645
俺のイメージでは、保守派の左翼からリベラリストになったって感じ。
たしかにマシになってきてはいるんだけど、やっぱ根本がずれてるって。
ズレてても機能さえすりゃいいんで、まー周りからは放置されるんだけどな。

0647デフォルトの名無しさん

2010/10/11(月) 15:16:44

>>644
単純な二項演算を利用側と被利用側に切り分けて責務を与える、とか、
言語のモデルを統一して見通しを良くする以上のご利益なんかないじゃん。
不適切な例を持ち出しても、それは反例にはならない。

0648デフォルトの名無しさん

2010/10/11(月) 15:18:40

やべぇ言ってる意味がわかんねぇ。こえぇ。
責務とか言ってるのお前なのに、俺が言ったことみたいになってるし。

0649デフォルトの名無しさん

2010/10/11(月) 15:20:52

>>646
自由主義者の俺からマジレスすると、共産主義と自由主義は全然別物だぞ。
日本で「リベラル」といってるアレは、ロールズに代表される自由主義とは何の関係もない。

0650デフォルトの名無しさん

2010/10/11(月) 15:25:13

その前に、左翼と共産主義が同じとも限らなくない？
左翼の実装例が共産主義ってだけだろ？
今俺は、左翼がリベラル実装に発展したっていってるだけで。
民主党的イメージ。共産党とは別。
民主党も機能している限りは構わないって周りから放置されてるじゃん。
事業仕分けとか、ああいうものも必要だろうって。

0651デフォルトの名無しさん

2010/10/11(月) 15:25:32

じゃあタバコとライターと喫煙者で例だしてみてよぅ

0652デフォルトの名無しさん

2010/10/11(月) 15:27:49

だから俺はOOPの立ち居地は民主党とかぶるなぁっと思ってる。必要悪。
だけど、用済みになったらﾎﾟｲｯだからな、怖い怖い。
とはいっても社会人生活は40年しかないんだから、その間だけ持てば十分だろうとも。
だから皆OOPとかやってるんだろうね。自分の代だけ持てばいいやって。
でも2chでそれやるのは詰まらんね。

0653デフォルトの名無しさん

2010/10/11(月) 15:29:15

いっぷく ( &タバコ, &ライター, &喫煙者 );

0654デフォルトの名無しさん

2010/10/11(月) 15:31:29

喫煙者.一服　タバコ　ライター
っていうように書きたひ

0655デフォルトの名無しさん

2010/10/11(月) 15:32:52

いっぷくの処理内容がタバコに依存しているかも知れんぞ。
ライターは火打石かも知れんぞ。

0656デフォルトの名無しさん

2010/10/11(月) 15:40:32

>>648
横からだけど、俺もＯＯを勉強したてのころは
お前みたいに訳の分からん事をいっていたよ、懐かしいな。
頑張れよ。

0657デフォルトの名無しさん

2010/10/11(月) 16:04:04

でも実際
喫煙者.一服　タバコ　ライター
ってどうなんだろうね。
タバコ無しじゃタバコすえないし、タバコ吸うことはタバコのメイン機能なんだから、
タバコ.一服　喫煙者　ライター
が正解のように思える。
だけど、一服の形は人それぞれで、もしかしたらタバコをすわない場合もあるかもしれない。
だから、やっぱり一服は喫煙者に紐付けしたほうが良いかもしれない。
ほらもう解らないよね。
でも言うんだろ？それはどういった状況を前提にしているかによる、と。
だけどそれは裏を返せばコードを使いまわせないってことでもあって、墓穴掘ってるんだよね。

0658デフォルトの名無しさん

2010/10/11(月) 16:05:23

>>655
現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな

0659デフォルトの名無しさん

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がやる仕事じゃないだろ。なんで上に管理させてるんだよ。

0660デフォルトの名無しさん

2010/10/11(月) 16:10:30

>>658
でも、
いっぷく ( &タバコ, &ライター, &喫煙者 );
で示されるタバコとライターと喫煙者の関係は、現実でも成り立つのだ。
あっても、引数の順番に野次が飛ぶぐらい。

0661デフォルトの名無しさん

2010/10/11(月) 16:32:54

>>657
＞タバコ.一服　喫煙者　ライター
タバコ自体が一服の機能を持つとか、タバコが喫煙者を使うとか、
そんな馬鹿なこと言ってんじゃねーよ。

0662デフォルトの名無しさん

2010/10/11(月) 16:37:53

>>661
現実に例えて説明するとそういう疑問が出てくるから駄目なんだよな

0663デフォルトの名無しさん

2010/10/11(月) 16:47:20

>>630
＞ボタンクラスを継承してくださいとか
こういうことをするメリットはちゃんとあるぞ。

たとえば、ボタンクラスを使うフォームクラスがあるとする。
フォーム．ボタン配置（ボタン）
これは普通に使う分には問題ないよね？

じゃあ、このフォームクラスに渡すボタンクラスの機能を変えたいとする。
もし、ただ単純に新しいボタンクラスを作っただけだと、
フォームクラスにそれは渡せないよね？
それがどういうものかフォームクラスには分らないから当然なんだが。

でも、フォームクラスがそれをどういうものか分れば話は別だ。
それを実現する機能が、継承なんだ。

新しいボタンクラスに、元のボタンクラスを継承させると、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが出来る。

フォームクラスは元のボタンクラスの機能とインターフェースの仕様は知っているので、
新しいボタンクラスに、元のボタンクラスの機能とインターフェースが備わっていれば、
フォームクラスはまるで元のボタンクラスを使うように、新しいボタンクラスも使えるようになるんだ。

0664デフォルトの名無しさん

2010/10/11(月) 16:49:23

>>662
疑問が出てくるから何？
それは全く関係ないプログラムの機能の話とは、全く繋がらないぞ。
関連性がまるでない。それを見てどうしろと言うんだ。

0665デフォルトの名無しさん

2010/10/11(月) 17:31:36

実空間の物体の用法や使用例を基にオブジェクト指向的分析を行うのが難しい理由ってなに？
人それぞれ抽象度や理解力が違うからなの？

0666デフォルトの名無しさん

2010/10/11(月) 17:36:52

>>665
実空間の物体の用法や使用例が、
自分の作るプログラムの用法や使用例に合っていないと、
分析しても変な結果になる。

そこに原因があるんじゃないかと。

0667デフォルトの名無しさん

2010/10/11(月) 17:39:34

みんな共有できる思いは「動きゃいいんだよーぅ」だな

0668デフォルトの名無しさん

2010/10/11(月) 17:41:43

>>665
鳥クラスを作ってflyインタフェースをつけてもペンギンやダチョウは飛べない
そういう現実の分類と実際とのギャップは色々ある
長方形を継承して正方形を作るのが失敗だという古典的な例とか調べてみれば

0669デフォルトの名無しさん

2010/10/11(月) 17:43:21

>>667
そうだなｗ

ただ、その何とか動いているものに、
何かしらの手を加える必要に迫られることは、絶対にあるから大変。

0670デフォルトの名無しさん

2010/10/11(月) 17:58:07

>>666
その通り。
だから、型やオブジェクトにメソッドじゃーなんじゃーって機能を持たせても意味ない。
そのオブジェクトがどう使われるかは、使う人次第。
画像ファイルに展開用コードが内包されていないのと同じ。
ヘッダでフォーマットさえわかればよい。
どう扱うかはプログラムが決める。

0671デフォルトの名無しさん

2010/10/11(月) 18:03:51

>>670
自販機の中のジュースを、外の人間が自由に取り扱ってもいいなら、それでもいいけどな。

0672デフォルトの名無しさん

2010/10/11(月) 18:32:30

>>670
あと、データそのものと、データの入れ物を一緒にすんなよ？

0673デフォルトの名無しさん

2010/10/11(月) 19:22:03

何言ってるんだろう。翻訳求む。
相当都合の悪いこと言っちゃったかな。

0674デフォルトの名無しさん

2010/10/11(月) 19:34:41

タバコとライターは喫煙者にとってhas aじゃないの？
別途買うなり借りるなりでセットして、一服は引数無し。
属性コーヒーが非nullなら、一緒に飲んだって構うまいよ。

0675デフォルトの名無しさん

2010/10/11(月) 19:39:30

大丈夫
俺もわからん

0676デフォルトの名無しさん

2010/10/11(月) 19:40:48

ソースコードを日本語に無理やり改訳するツールでも使ってるんじゃね？

0677デフォルトの名無しさん

2010/10/11(月) 20:35:56

>>659
Cは何かの操作を提供するインターフェース的オブジェクトで
操作の実態はDがまとめて実行しているかもしれない

Bはいくつかアルゴリズムを持ったデータベース的オブジェクトで、
E(D)はこのアルゴリズムを参照してCで受け付けた操作を実行しているかもしれない
そしてDはEによって回される処理の実装かもしれない

今、Aの内部状態によってBのアルゴリズムを切り替える必要が出てきたとする。

ここまで行くとDが処理の基幹を担う重要なオブジェクトであることはうっすらみえてくるはず。
Dが直接AやBを管理して結合を強めることに危険を感じ無いか？
ましてやAとDが同一なんて有り得ない。

0678デフォルトの名無しさん

2010/10/11(月) 21:06:01

>>670
そして色んなコードが自分の都合のいいようにデータを操作しまくって収集がつかなくなるんですね、わかります。

0679デフォルトの名無しさん

2010/10/11(月) 21:30:10

>>673
画像データはデータそのもの。
型やオブジェクトはデータの入れ物。
ちゃんと言った方がよかったな。

0680デフォルトの名無しさん

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が同一なんてあり得ない
そこはよくわからなかったから、二通り考えたけど、もう一方はどう思う？

0681デフォルトの名無しさん

2010/10/11(月) 22:15:36

だめだこりゃ

0682デフォルトの名無しさん

2010/10/11(月) 22:25:17

それぞれの理解度が違うんじゃあ
平行線ですよね

0683デフォルトの名無しさん

2010/10/11(月) 22:29:59

そう思うならさっさと叩きのめせばいいのに。

0684デフォルトの名無しさん

2010/10/11(月) 22:32:55

そもそも継承するってことは多態が必要ということなので
Dと似た振る舞い（この場合ばBのアルゴリズム利用の何らかの実装）をする
Eを継承したオブジェクトが他に存在すると考えるのが妥当

もっと言うとDやEを継承した他オブジェクトを保持したり扱ったりするクラスも他に存在するんだろう

0685デフォルトの名無しさん

2010/10/11(月) 22:35:42

そもそもAからBにアクセスしたい！と思ったときに
可能であれば他に一切変更を加えずに自動的にボッコシ穴あけてアクセスできるような仕組みが
（ようするにそれによって依存関係が崩壊しない保証ができるような機構が）
存在すればOOPももう一歩価値が高まるのに、って話では

0686デフォルトの名無しさん

2010/10/11(月) 22:53:32

>>684
>継承するってことは、多態が必要
なにそれ初耳。どこの情報？

>Dと似た振る舞い
何が？
Eがということなら、なに当たり前(ry

>DやEを継承したクラスが他に存在
Dが継承されてるなら、慎重にやる必要があるな。
でも、Eが他のクラスに継承されてたとしても、Dには何の関係も無いだろう。

ところでこれは>>680に対する反論なのか？

0687デフォルトの名無しさん

2010/10/11(月) 22:56:10

>>685
そんな行き当たりばったりなコーティング、オブジェクト指向じゃなくても有害だわwww

0688デフォルトの名無しさん

2010/10/11(月) 23:09:27

>>686
つ読解力

0689デフォルトの名無しさん

2010/10/11(月) 23:11:10

>>687
依存関係が崩壊しない保証があればどれだけ行き当たりばったりでもそれは問題にならない
OOは依存関係を整理するためにあるんだから

0690デフォルトの名無しさん

2010/10/11(月) 23:17:44

>>688
>>684から他に何を読み取れと。
説明も何もないぞ。

0691デフォルトの名無しさん

2010/10/11(月) 23:21:26

>>689
いままでの話を無視すんな><
そもそも、依存関係が崩壊しない保証を確認してコーティングするのは、行き当たりばったりじゃなくね？

0692デフォルトの名無しさん

2010/10/11(月) 23:31:59

Java/C++でひとりでコーディングしてるとすごくしっくりくる書き方がある。
これをチーム開発にしたとたんわけわからんイベントが多数発生する。
この原因を理解して言葉にしたいんだが。

0693デフォルトの名無しさん

2010/10/11(月) 23:50:41

>>692
つジョエルテスト
最近知ったやつだけど、チームの問題を探る役に立つかも？

0694デフォルトの名無しさん

2010/10/11(月) 23:58:35

ぐぐってみたけどそういうことじゃないみたい。

0695デフォルトの名無しさん

2010/10/12(火) 00:29:14

>>691
だからそういう保証が簡単に取れる仕組みがあれば良いねって話でしょ

0696デフォルトの名無しさん

2010/10/12(火) 00:35:12

多態以外で継承使う奴は差分プログラミングとOOPの区別が付いてないから厄介
チームに居ると割と複雑なバグだしよる

0697デフォルトの名無しさん

2010/10/12(火) 00:41:22

>>696
横からで悪いが、お前はオブジェクト指向が分かっていない。
いい加減、自分だけレベルが低いことに気付け。

0698デフォルトの名無しさん

2010/10/12(火) 00:43:36

あれ？OOPじゃなくてOOなの？

0699デフォルトの名無しさん

2010/10/12(火) 00:44:58

>>695
いや、そんな話しはしてなかった。
>>603の例の設計は駄目だねって、俺が始めた話し。

0700デフォルトの名無しさん

2010/10/12(火) 01:15:33

>>699
別に提案自体はそんなに悪筋じゃないし、そういう言い方せんでも良いのでは。

0701デフォルトの名無しさん

2010/10/12(火) 06:39:29

>>697
分かってないのはお前だ。
どうせOOの一番の特徴は再利用性とでも思っているのだろう。

0702デフォルトの名無しさん

2010/10/12(火) 11:00:35

>>696
>差分プログラミングとOOPの区別が付いてないから厄介
差分プログラミングとOOPが別物だと言う人間は始めて見たな。
これはどんな根拠なんだ？　誰か教えてくれ。

0703デフォルトの名無しさん

2010/10/12(火) 11:14:58

>>702
馬鹿な人間が考えることは、普通の人間には解らん。
まっ天才が考えることも普通の人間には解らんが。

0704デフォルトの名無しさん

2010/10/12(火) 12:06:09

>>702
差分プログラミングはあくまでOOPが広めた一要素でしかないのであって
OOP＝差分プログラミングでは無いんだが
何故かやたらと差分プログラミングのための継承を乱発する奴が居る

という意味だと思う

0705デフォルトの名無しさん

2010/10/12(火) 19:13:53

差分プログラミングの「差分」が、バリエーションを増やすことではなく単なる機能拡張を意味しているなら、
最近の考え方では誤りを含んでいる可能性が高いとされる。

0706705

2010/10/12(火) 19:15:54

継承で機能を増やそうとする前に、もう一個クラスを切って委譲することで解決できないか
考えてみた方が良いと思う。

0707デフォルトの名無しさん

2010/10/12(火) 19:32:54

馬鹿な人間が考えることは、普通の人間には解らん。

0708デフォルトの名無しさん

2010/10/12(火) 21:50:07

>A　→　Aの持ってるC　→　Cを管理してるD　→　Dの基本クラスのE　→　Eの持ってるB

設計は問題あるかもしれないけど
これって別に悪いことじゃないよね？

OOPというかカプセル化は上記のようにするのが目的だと思うんだが

0709デフォルトの名無しさん

2010/10/12(火) 22:20:31

>>704
その意味だと”区別”とは言わない。

0710デフォルトの名無しさん

2010/10/12(火) 22:29:33

OOPとしての話なら
同じ基本クラスAを継承したクラスBとクラスCがあったとして
クラスAが使われている部分を全部クラスBやクラスCに置き換えても正常に動作しなければならない

つまり多態を必要としていなければ継承は使うべきでない

0711デフォルトの名無しさん

2010/10/12(火) 23:29:43

>>708
クラス図を書いて見たけど、全然悪くないと思う。

例えばMVCのビジネスロジックDクラスがCクラスを管理して
そのCクラスをViewでコンポジションするなど普通に行なう。
Dクラスがスーパークラスを持っていてもおかしくないし
そのクラスが別のクラスを持つことも普通にある。

駄目だと言っている人間は本当に実践でOOPを使えているのか？

0712デフォルトの名無しさん

2010/10/12(火) 23:38:10

>>711
俺が何を駄目と言ったかちゃんと見た？
まあ、その文の様子だと見てないんだろうけど。

0713デフォルトの名無しさん

2010/10/12(火) 23:48:19

お前だれだよ

0714デフォルトの名無しさん

2010/10/12(火) 23:49:48

>>713
>>659です。

0715デフォルトの名無しさん

2010/10/12(火) 23:54:55

>>710
お前C++房だろう。OOPを勉強して出直せ
他の言語を知っている人間ならそんなバカなこと書かないぞ。

0716デフォルトの名無しさん

2010/10/12(火) 23:57:32

他人だがなぜそう思ったかさっぱり分からん

0717デフォルトの名無しさん

2010/10/13(水) 00:00:13

ポリモーフィズムって定義曖昧じゃね？

0718デフォルトの名無しさん

2010/10/13(水) 00:03:15

>>715
それ、単なるLSPじゃねーの

0719デフォルトの名無しさん

2010/10/13(水) 00:07:05

>>715 >>710 じゃないが, OO の定義をしてくれw
まじで OOP って声高にさわぐ奴って何なのよ?

理屈、説明しても分からない
要求仕様を渡しても自分の都合のいいように改変してくる
数式渡しても全然別のものを作ってくる

まともな頭もってる奴って OO って叫ばないぞ

0720デフォルトの名無しさん

2010/10/13(水) 00:11:12

>>714
659を読んだから実践でOOPが使えない人だと思ったけど。

0721デフォルトの名無しさん

2010/10/13(水) 00:12:41

>>719
OOは知らんが、OOPは言語によって形態が違うな。
共通してるのはカプセル化ぐらいだ。

0722デフォルトの名無しさん

2010/10/13(水) 00:18:02

>>720
本当かよww
一応言っとくけど、俺は>>711の、全く悪く無い、ってところ以外は同意してるぞ。
>>659もそれが前提になってるし。

0723デフォルトの名無しさん

2010/10/13(水) 00:18:54

継承なんて極力つかうべきじゃないよ

0724デフォルトの名無しさん

2010/10/13(水) 00:21:33

継承って可読性下げるよね。
メリットがないときは使わないほうがいいでしょう。

0725デフォルトの名無しさん

2010/10/13(水) 00:23:38

まあ、よく分からない物は使わない、は賢い判断だわな。
継承やらテンプレートやら。

0726デフォルトの名無しさん

2010/10/13(水) 00:41:19

>>721
そんなこと言ってるんじゃないんだな, これが…
たとえばの話なんだが,
MPEG シリーズってのは、規格書の書式含めて、ある意味 OO の産物なわけだ
これをふまえて, この規格書のここからここまでを何とかしたいとか言うわけ
で、連中、プログラム書いてくるんだが、
規格書に書いてあることに堂々と違反する
規格書中の数式を理解できないんだろうけど, アルゴリズムがおかしい
わかりやすく数式書き直してあげても数式通り動かない
でも, 「うちは OO してますから，大丈夫なはずです！！！」と声高に言う
つか、 OO ってやってるふりしてりゃ許してもらえる隠れみのになってるだろw

0727デフォルトの名無しさん

2010/10/13(水) 00:46:02

>>726
それOO以前の問題じゃねwww
プログラマに必要な技能が備わって無いwww

0728デフォルトの名無しさん

2010/10/13(水) 00:46:18

哲学者ウィトゲンシュタインは
「思考の限界は言語の限界」だと言っている。
まっ思考には非言語的要素もあるから、これが全て正しい訳じゃないが
しかし、ほとんどの思考は言語で考え、言語で表現する。

だからC++房は駄目なんだよ。C++言語の限界が思考の限界になっている。
C++に無い部分が理解出来ない。

0729デフォルトの名無しさん

2010/10/13(水) 00:52:17

>>727
そだよ！じゃなくって、
「OO してますって言えば世間が許してくれる」
と思う、その感性ってどぉよ？？？

0730デフォルトの名無しさん

2010/10/13(水) 00:55:06

>>729
そいつらはきっと、世間から無視されるだけだからほっとけ。

0731デフォルトの名無しさん

2010/10/13(水) 00:59:22

>>729
相手に仕様が伝わらないのは、お前の日本語が”変”だからじゃないのか。

0732デフォルトの名無しさん

2010/10/13(水) 01:02:22

>>731
>>726は、説明書が読めないやつが居る、って言ってるんだよ。

0733デフォルトの名無しさん

2010/10/13(水) 01:02:36

>>730
なんで日本語しゃべらんとあかんの？
数式読めないみたいだから、数式を高校生でも読める数式に書き換えただけなのに

0734733

2010/10/13(水) 01:12:17

すまん, アンカー間違えた >>731 だったわ

0735デフォルトの名無しさん

2010/10/13(水) 01:17:05

>>722
>なんで二重に管理する必要があるんだ、どうせ機能は同じようなものなんだからまとめてしまえ。
そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。

>そもそもDはEを継承しているんだから、Bも直接管理できるはずだろう。（出来ないならそれは継承するべきではない）
>基本クラスのEを気にする必要は無い。
Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。

0736デフォルトの名無しさん

2010/10/13(水) 01:23:43

>>732
>説明書が読めないやつが居る、って言ってるんだよ。
説明書ｗ　お前が読めていない。

0737デフォルトの名無しさん

2010/10/13(水) 01:24:02

チューリング完全すら知らないやつがいる

0738デフォルトの名無しさん

2010/10/13(水) 01:25:24

>>733
>なんで日本語しゃべらんとあかんの？
何語で喋っているの？

0739デフォルトの名無しさん

2010/10/13(水) 01:35:27

>>735
＞そもそも２重管理じゃない。他で管理しているインスタンスを集約しているケースなどいくらでもある。
百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
データの整合性ちゃんととれるのか？
そもそもそれはプログラム的に自然なのか？

＞Privateフィールドでのコンポジションを認めないのか？これも普通に存在するケースだ。
コンポジションを知らなかったので、wikipediaで調べた。
＞コンポジションは、両クラス間に強いライフサイクルの依存がある場合に使用する。
＞つまり、コンポジション関係にあるクラスの集約しているオブジェクトが削除されると、必ず集約されている側のオブジェクトはすべて削除される。
Privateフィールド関係なくね？　というのは置いといても、
全く関係ないこと言ってないかこれ。

0740デフォルトの名無しさん

2010/10/13(水) 01:36:17

>>736
比喩も認めない頭の固い人か。

0741733

2010/10/13(水) 01:46:42

>>738
英語でもドイツ語でも… ってのは、さておき、本質は数式部分だから……
つか、おまえ、数式読めない可愛そうな人か？

0742デフォルトの名無しさん

2010/10/13(水) 02:17:35

>>739
>百歩譲って二重管理じゃないとしても、Aの所有物にDが干渉していいのか？
603が正しく理解出来ていないのか？　管理しているのはDなんだから
Dが所有物CをAが参照(委譲)しているよ考えるだろう。
何をもって干渉やデータの整合性と言っているのか分からないが
オブジェクト指向はオブジェクト内で完結するように作るものだ。

>Privateフィールド関係なくね？　というのは置いといても、
>全く関係ないこと言ってないかこれ。
まぁコンポジションでも集約でもどちらでもいいんだが
Eが管理クラスだから生成・破棄を制御するのが普通だと思ってコンポジションにした。
俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。

>基本クラスのEを気にする必要は無い。
だからこれは間違い。

0743デフォルトの名無しさん

2010/10/13(水) 02:27:34

>>741
喋れるのは中国語か韓国語だと思ったよ。
>そだよ！じゃなくって、
そだよｗ

まぁこれ以外にもおかしな日本語いっぱい使っているし大丈夫かｗ

0744デフォルトの名無しさん

2010/10/13(水) 02:30:24

>>740
なぜそこで比喩を使う？　言い訳が苦しいなｗ

0745デフォルトの名無しさん

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から必要なデータを取得し出力する。

また、概念図では相互残照を行っているように見受けられます・・・。

0746デフォルトの名無しさん

2010/10/13(水) 11:56:59

疑問の詳細には答えないけど、wikipediaのMVCの項目は適当だから参考にしないほうがいいと思う
特にシナリオの部分は酷い、出典が書いてないオレオレ脚注とか付いてるレベルだよ
要出典タグつけたの俺だし

>また、概念図では相互残照を行っているように見受けられます・・・。
あの図はUMLではないし、Observerパターンがわかってれば別に変でもない

0747デフォルトの名無しさん

2010/10/13(水) 12:44:45

>>742
＞管理しているのはDなんだから
＞Dが所有物CをAが参照(委譲)しているよ考えるだろう。
ふーん。>>742はそう見ているのか。
まあ、実はどっちでもいいんだけどｗ

＞何をもって干渉やデータの整合性と言っているのか分からないが
え？　・・・え？
干渉はまだしも、データの整合性が分らないとな・・・？　お前それ本気で言ってる？　
どんなプログラムでも、二つ以上の別々の場所から参照されてるデータは、
データの整合性の問題が付きまとうものなんだがなあ・・・

＞俺が言いたいのは、PrivateフィールドならEを継承したDから直接Bを参照するのは不可能だと言うことだ。
＞Privateフィールドを子クラスが参照出来ないぐらい理解出来るだろう。
ああ、そうか。　それだと直接管理することは出来ないな。
確かに、Eは気にする必要がある。
と言っても、protectedやpublicなメンバから管理することは出来るが。

で、これだとまた別の問題として、継承する意味はあるのか？と言うのはある。
委譲以上のメリットを見いだすなら、
protectedなメンバからそれなりに自由な管理が出来る、と言うのがメリットになるか。
直接管理するのと同じくらいの自由度でね。

・・・あとは、>>742の用語の理解度は大丈夫か？　と言うのは、まあ置いとこう。

0748デフォルトの名無しさん

2010/10/13(水) 13:23:39

>>746
レス、ありがとうございました。
あの記事は当てになりませんが・・・。

出直してまいります。

0749デフォルトの名無しさん

2010/10/13(水) 15:06:51

>>747
結局603を間違いじゃないと認めたな。
しかし、>>659は酷いな、お前Privateフィールドも分からないとは
オブジェクト指向でプログラム作ったことないだろう。

0750デフォルトの名無しさん

2010/10/13(水) 15:30:06

>>749
いや、半分だけだぞ？
つーか、お前プログラム実装したこと無いだろ？

0751デフォルトの名無しさん

2010/10/13(水) 19:35:55

protectedメンバとかpublicメンバとか言い出す時点で程度が知れるわけだが

0752デフォルトの名無しさん

2010/10/13(水) 20:40:52

議論の元になってる>>603はムよりマ向けの話題だな

設計は別に悪くないけど設計者(と開発体制)が悪い。

0753デフォルトの名無しさん

2010/10/13(水) 21:17:50

いつもの人だが、凄いスレが伸びてるな。バカが来たのかと思ったらやっぱり。
AとかBとかCとかDとか頭沸いてるんじゃね。マトモな会話しやがれ。

原文は、やりたいことが素直に書けないから嫌だ、そういってるだけだろ。
やりたいことってのはつまりは手続きで、まぁアルゴリズムや制御構造や関数の類だな。
それが素直にかけない・・・まぁ当たり前だわな。
だってOOPは制御構造をオブジェクト単位でぶつ切りにしてパッパラパーにしちゃうからな。
だから、その指摘自体は何も間違っちゃいないんだぜ？
よくそんなことでこんな長文合戦が続くもんだな。

0754デフォルトの名無しさん

2010/10/13(水) 21:24:27

まぁだからアレだな。何でもかんでも、なんせ全部のことをクラスという道具でやろうとするから、
こんなことになってるんだな。OOPもそうなんだけど、クラス云々言ったときに何目的ベースの話なのかが見え無いと言う。
ポリモとカプセル化と差分プロの話がごっちゃになって展開される。だから意味解らん。

もうね、構文わけときゃいいと思うよ。
カプセル化はカプセル化専用の構文なり機構なり作ってそれで固めると。
その固めたオブジェクトをどうコミュニケーションさせるかは、
また別の構文なり機構なりですると。

Unixだと、プログラムはプログラムで閉じてて、
それをシェルを使ってどう組み合わせるかはまた別の話だったりして。
だから解りやすいんだよ、設計するのも、こう言うところで会話するのも。
何使ってるかで目的が明確だから。

0755デフォルトの名無しさん

2010/10/13(水) 21:29:51

相変わらず例の彼は何が言いたいのかさっぱりだ。

0756デフォルトの名無しさん

2010/10/13(水) 21:29:59

だけど俺思うのね。
プログラムってのは、その名の通り、手続きのことだろ。
俺らそれ書きたいだけなのに、現状データやオブジェクトに振り回されているという。
この逆転劇はどこかで終わるんだろうけど、楽しみだね。

0757デフォルトの名無しさん

2010/10/13(水) 21:39:33

いつもの人だけど、俺も昔OOPに凝ってたころは割りとクドクド説明する派の人だったんだけど、
だんだんOOPに疑問を抱くようになってきて、そんで、やっぱ物中心の思考ってのは無いなーとか、
そんで、他との関係が物の性質を決めるんだって気づいてからは、
だんだん行間を飛ばすようになってきて、あーやっぱ「間」って大事なんだなぁって。
行と行の間には行間があって、それが行と行との関係で、そこに本当に言いたいことがあったりして。
だから段落って重要だよね。どういう構成になってるかで言いたい事が大体分かると言う。
日本語も面白くて、漢字をひらがなで繋いでいるのな。言うなら漢字がデータでひらがなが関数って。
こうやって人は成長して大人になっていくんだなぁって。仕事ってほとんど後片付けだしね。

0758デフォルトの名無しさん

2010/10/13(水) 21:41:07

日本語でおk

0759デフォルトの名無しさん

2010/10/13(水) 21:44:05

でもそう思わない？
漢字って一字一字が意味を持っていて、まるでOOPで言うところのオブジェクトみたい。
一方、ひらがなは一字一字には意味は無く、「いってきます」って流れて意味が出る。
まるで手続きみたいだ。

0760デフォルトの名無しさん

2010/10/13(水) 21:45:42

しかし、いつものことだけど、俺いいこと言うよなぁ。

0761デフォルトの名無しさん

2010/10/13(水) 21:55:46

OOPが駄目だってんなら対案をちゃんと出してほしいね
抽象的なことばかり言ってないでさ

0762デフォルトの名無しさん

2010/10/13(水) 22:24:14

マルチメソッドが良いんじゃないかって。
現状、大概のOOPが単一オブジェやクラスにメソッドがくくりついているから、
オブジェクトがメソッド(機能)を所有しているとかって変な感覚が沸いてくる。それが泥沼の原因なんだと思う。
だから、オブジェクトからメソッドを切り離してさ。
func( obj1, obj2 );
こんな感じで普通にかければ気持ちいいだろうと。
データにはただのデータでいてもらってさ。機能なんか持たずにね。
データやらオブジェクトやらをどう使うかは、型の作成者じゃなくて、利用者が決めるというね、Unixの思想ね。
ただ、カプセル化は必要だろうから、それ用の何らかの機構は必要だと思うけど。
なんかアクセス権とか適当につけて頑張ってって感じ。

0763デフォルトの名無しさん

2010/10/13(水) 22:30:27

>>757
わかったから行間を開けて段落を作れ馬鹿

0764デフォルトの名無しさん

2010/10/13(水) 22:32:40

オブジェクトは自分の型が何であるかは他に示すが、それ以上のことには関与しない。
関数は引数のオブジェクトの型情報を使ってどう処理するかをマルチメソッドする。
これは、whatとhowの分離で、とても有用。
昔からバカはwhatとhowの区別が解らないもんだと決まってて、whatで聞いてるのにhowで返してきたりする。
だから、whatとhowを分離することは、マトモになることへの第一歩かなぁと。
画像ファイルを見れば解るけど、ヘッダに「フォーマットが何か」が書いてあるだけで、「どう使うか」までは書いてないんだよね。
だから、展開用コードが内包されていたりはしないし、用途も使う人次第。
オナニーには使わないでくださいでは困るんだよ。そんなことは指定しないで欲しいんだよね。

0765デフォルトの名無しさん

2010/10/13(水) 22:37:05

で、オブジェクトの型情報なんだけど、何処においておくかって問題がある。
例えば、C++のvtableみたく、データの先頭にヘッダみたいに型情報をおいて置くのも一つの方法なんだけど、
それだとオフセットがずれるし、個人的にキモイ。データは単にデータであって欲しいんだよね。
だから、オブジェクトの型が何であるかは、ポインタや参照が覚えていれば良いと思う。
だから、32bit環境ではポインタや参照のサイズが実アドレスと型値で64bitになるね。
ちょうどC++のshared_ptrがそんな感じの実装になってて、ありかなぁと。

0766デフォルトの名無しさん

2010/10/13(水) 22:39:52

補足すると、ポインタや参照に代入が行われたタイミングで、型値も書き換わるのな。
struct pointer{ void *address, int type };
こんな感じかね。その辺は適当に。

0767デフォルトの名無しさん

2010/10/13(水) 22:42:19

あ、ごめん。
「,」→「;」
やっちった。これはかっこ悪いぞ俺。頑張れ。

0768デフォルトの名無しさん

2010/10/13(水) 22:48:35

>データにはただのデータ
クラスの粒度の違うだけな気がするな

単純にデータとして扱えるのは最初の方だけで
最終的にはOOPと同じような形になるんじゃないかな

0769デフォルトの名無しさん

2010/10/13(水) 22:49:45

で、今悩んでるのが、分割コンパイルしたときの型値の扱いについてなんだよね。
それから、型値のマルチメソッドへの最適化。
ポインターの宣言都度都度で変換テーブルを用意せにゃならん。
それも、他ポインターからの代入を洗いざらい全部調べて、組み合わせ爆発的にな。
コンパイル時にはユニークな型値を割り振っておいて、そっから最適化で詰めていくってのがやりやすそうなんだが、
動的にモジュールを読み込んだときはどうなるんだって。そこまで考えると盛り上がるなー。

0770デフォルトの名無しさん

2010/10/13(水) 22:55:31

>>768
そうはさせないような仕組みも考え中。
オブジェクトがこんがらがるのは、オブジェクト中に他のオブジェクトの参照を持ってたりするからで、
だから、そういうことはさせないようにしようと。
なんか、そういった依存関係は別の構文で何とかならんかと。
例えば、
relation( "なんかの関係", obj1, obj2 );
とすると、"なんかの関係"とobj1とobj2との間で関係が定義されて、
後で引っ張り出せるような何か。
データ構造にも抜本的にメスを入れたい

0771デフォルトの名無しさん

2010/10/13(水) 22:59:58

プロトタイプベースってことでいいのか

0772デフォルトの名無しさん

2010/10/13(水) 23:03:17

>>770
>"なんかの関係"とobj1とobj2
これもデリゲートで片がつくのでは？
デリゲートじゃだめな理由を聞きたいね

0773デフォルトの名無しさん

2010/10/13(水) 23:07:40

違うけど、近いものにはなるかもね。
それは、今ここで説明した理由ではなくて、
型と関数を同列に扱いたいと言う要望からだけど。
型は型だけど、関数はインスタンスだからね。
同列に扱うには、型とインスタンスの区別をなくす必要があって、
文法をどう纏め上げるか、どういう解釈、トリックにするか、悩み中。
ただ、C言語のノリが一つのヒントになると思ってる。
int i;
int func(){}
変数と関数は全然別物だけど、ただ、どちらも、
identifierを評価すると、前に書いてある型へ落とし込まれて評価されることには
変わりないんだよね。そこつかってなんかできんかと。

0774デフォルトの名無しさん

2010/10/13(水) 23:11:59

>>772
デリゲートは何処に保存しとくんだっていう。
でも実際迷ってんのよ。関係を別途保存しますってもうそれDBだし、それするなら、構造体とか・・。
関係を定義したんだから、関数に纏められんかとか。う～ん。
文法としては統一したいんだけど、用途としてはばらして置きたいという。

0775デフォルトの名無しさん

2010/10/13(水) 23:21:25

>>773
なんか関数型言語じみてきたな

>>774
>デリゲートは何処に保存しとくんだっていう。
>relation( "なんかの関係", obj1, obj2 );
このrelationを呼び出すとこで管理しとけばいいんじゃない

0776デフォルトの名無しさん

2010/10/13(水) 23:47:54

>>775
そそ、関数型言語風。だけど手続き型で、バリバリメモリやインスタンス意識した何か。
そういう中途半端な按配の妙な、しかし、妙にフィットして使いやすいC言語みたいな、そういう。

関係に関してなんだけど、関係を言語環境でサポートしたいんだよね。インデックスとかも割り振って高速に列挙できるような。
そういうの書くのもう面倒でしょ。逆参照がどうとか、一対多だとか。RDBに任せるったって、インピーダンスミスマッチするし。
リストとか配列とか、もう面倒だし、本質じゃないしなぁ。関係の一言で片付けたい。

C言語、あれ面白いんだよ。知ってのとおり、C言語って論理型が無いんだよね。
そのくせ、C言語の企画書みると、標準関数の～は～のとき真を返します、とかしれっと書いてあんのな。
でも文法上は論理型も真偽値も無いと言う。
プログラマも会話や企画書で真とか偽とか普通に使うのに、
でも文法上はそんなもんねーっつー。

俺もそういうのが作りたいなぁって。
型も関数もインスタンスも文法上区別はないし、組み合わせ爆発がないから文法もシンプルだし、
なんだけど、使ってる奴は、型とか関数とかインスタンスとか区別してるし、会話にも出てくるしっていう。
まさにミラクル。

0777デフォルトの名無しさん

2010/10/13(水) 23:52:37

論理的な文章が書けない奴が、どんな処理系を書くのか楽しみでならない。

0778デフォルトの名無しさん

2010/10/13(水) 23:52:45

そろそろ多態性の話にしないか。
まず多態性の対象はメソッドにいして（オブジェクトを後で）
実装方法はインターフェース・継承ぐらいから話そう。

最初はインターフェース・継承それぞれの利点・欠点ぐらいから。
俺的にはインターフェースしか使わないと言う奴はバカだと思う。
インターフェースは使うのは
結びつき弱いクラス同士のIFを揃える時ぐらいしか使わないのが正しい。

0779デフォルトの名無しさん

2010/10/13(水) 23:56:02

>>777
だから頃合見計らって次スレ立てよろしくな。キリ番だし。

0780デフォルトの名無しさん

2010/10/14(木) 00:01:45

>>778
日本語でおｋ

0781デフォルトの名無しさん

2010/10/14(木) 00:30:04

なんで論文の一本も挙げずに話そうとするわけ？ばかなの？しぬの？

0782デフォルトの名無しさん

2010/10/14(木) 00:37:38

読解不能だし、
～はバカだって言っといてその根拠は挙げないし、
～は正しいって言っといて、その根拠も挙げないし。
ばかなのしぬの。
でももう書き込まなくて良いからね。

0783デフォルトの名無しさん

2010/10/14(木) 00:41:01

いいからちんこはCLOSやれよ

0784デフォルトの名無しさん

2010/10/14(木) 01:04:56

>>776
何となくjavaしかやったことないとみた。

0785デフォルトの名無しさん

2010/10/14(木) 01:26:06

>>778
確かに、根拠もなくポリモはIFとか言っている奴はいるが
俺は無視している。

0786デフォルトの名無しさん

2010/10/14(木) 01:52:41

根拠もない程度の関係しかないならIFじゃね？
根拠のある関係があるなら継承が適切かも知れんけど。

0787デフォルトの名無しさん

2010/10/14(木) 19:58:29

>>776
レスを一通り読み直して見たけどうまくいかないと思うな

>データにはただのデータでいてもらってさ。機能なんか持たずにね。
>プセル化は必要だろうから、それ用の何らかの機構は必要
>relation( "なんかの関係", obj1, obj2 );

"なんかの関係"には関数が入るんだろうけど
カプセル化(情報隠蔽)してたら外からいじれない部分が出てきて破綻しそう
全部パブリックにしてるか単一の値しか持たないなら別だけど

0788デフォルトの名無しさん

2010/10/14(木) 21:17:35

>>787
カプセル化はするけど、アクセサを設けないとは言ってないぞ。
上手くいくかはわからないけど、失敗してもそれはそれで。
個人的にはC言語＋マルチメソッド＋テンプレート＋型推論程度で十分なんだが、
そういう言語って何故か無いんだよね。
使い勝手良いと思うんだがなぁ。
何で誰も作らんのだろう。当たり前すぎて面白くないんかね。
そういうまともな仕事よりは、皆やっぱ遊びたいんかね。
まー自分で言語作って普及させようと精力的に頑張るなんて、捻じ曲がったキチガイにしか出来ない行動力だし、
そういうところからまともな物はなかなか出てこないわなぁ。
必要に迫られて仕方なく作ったC言語とか、暇な先生がお遊びで作ったpythonとか、
コンピュータ関係無いところが元ネタのLISPとか、
そういうのだけが人気だもんなぁ。まぁpythonがあんままともとは思わんが。

0789デフォルトの名無しさん

2010/10/14(木) 21:24:50

こういうのがユーザ企業の担当者だったらデスマ確定だな。
要件を仕様化できず、その場の思いつきで「う～ん、思ってたのと違うんだなぁ」を
連発してプロジェクトを地獄に叩き落す。

0790デフォルトの名無しさん

2010/10/14(木) 21:32:08

自分の仕事の確保には役に立つんじゃね？
つまらーん　どうでもいい仕事をひきのばーし　某内閣みたいに

0791デフォルトの名無しさん

2010/10/14(木) 21:36:23

788には毎度感心する

0792デフォルトの名無しさん

2010/10/14(木) 21:41:13

よくこれだけ意味の通らない文章を書けるよな。

0793デフォルトの名無しさん

2010/10/14(木) 21:43:33

>>788
>カプセル化はするけど、アクセサを設けないとは言ってない
プライベートまでアクセスできてしまったら情報隠蔽にならないのでは？

0794デフォルトの名無しさん

2010/10/14(木) 22:02:18

整合性さえ取れれば問題なくね？

0795デフォルトの名無しさん

2010/10/14(木) 22:24:43

>>794
どうやって整合性を保つのかが不明

長くなってきたからもうまとめてしまうがいいかね

大事なのは関係(メッセージ)だという主張自体は
べつにおかしいことじゃないし、OOPに取り込んでいける(もしくは既にある)。

しかし「新しい言語、新しいパラダイム」を使うべきということなら

スレ違いです

0796デフォルトの名無しさん

2010/10/14(木) 22:40:30

いやだから、その構造体内での整合性が取れてればそれで良いんじゃないの？
直接アクセスさせずに、関数通してアクセスされればいいんでしょ。
別に普通ジャン。

0797デフォルトの名無しさん

2010/10/14(木) 22:43:55

あーあと、
メッセージが関係なんじゃなくて、メッセージングな。
その辺はアランケイ氏もメッセージングって言ってて、メッセージじゃないんだよね。
ほら、行動しなきゃ始まらないっていうじゃん。
だけど、アランケイ氏みたく、言ってることと行動がバラバラだったら意味無いんだがな。
あの人は不思議な人だなぁ。

0798デフォルトの名無しさん

2010/10/14(木) 22:49:45

だって、OOPで大事なのはメッセージング、媒体となるメッセージングこそが主題だって良い事言っといて、
そんで、オブジェクト指向って名前付けるんだぜ？メッセージング指向ってはっきり言えばいいのに。
しかも、LISPはもっとも偉大な言語だって言っといて、そのくせなぜかRuby贔屓。
京都大学に拾われてるのも意味解らん。
たしかに京都くさい思考回路の人だから、居心地いいだろうが。
なにか惜しい人って印象はあるね。ある意味バランス感覚は良いのかも知れんが。

0799デフォルトの名無しさん

2010/10/14(木) 22:51:50

ただ、メッセージング指向って名前付けてたら、
あ、それただのC言語じゃんってなって、
何の話題にもならずに埋没していたかも知れんが。
今となってはその方がよかったかもな。

0800733

2010/10/14(木) 23:44:17

>>798
メッセージングが大事なのはケイの oo だけだ（まぁ，言い過ぎだけど)
その他の oo 隠すことの方が大事だっただけだ(最近ちゃってるけど)

# 別の話だけど, 京都生まれの京都育ちなもんで,
# *京都くさい思考回路*ってのはすこし説明してほしいw

0801デフォルトの名無しさん

2010/10/14(木) 23:57:06

やっと彼の言動に感じる違和感が分かった。
プログラミング言語を論じる言葉が文芸評論的なんだな。
技術屋の言葉じゃない。

0802デフォルトの名無しさん

2010/10/15(金) 09:37:55

オブジェクトとオブジェクトの関係を考えるのがオブジェクト指向。

手続きと手続きの関係を考えるのが手続き指向。(フローチャート)
データとデータならデータ指向。(DFD)

オブジェクト同士の関係を考えるにあたって、
メッセージングとクラス図のどちらを重視するかで
大きく派閥が分かれるが、名前には大きな問題ない。

うん、今テキトーに考えた。

0803デフォルトの名無しさん

2010/10/15(金) 18:30:27

オブジェクト指向で作っていたが WIN32API のウィンドウプロシージャの switch( wParam ) case WM_...
case WM_.. case WM_... のスイッチの嵐と変わらなくなってる

0804デフォルトの名無しさん

2010/10/15(金) 18:53:42

そういう場面でこそ多態だろ

0805デフォルトの名無しさん

2010/10/15(金) 19:31:40

>>804
うん、たしかにそうなんだが、多態を使いまくるとデバックがつらくてね
結局のところ、処理ナンバーを一極集中管理することになった
というか、頭が追いつかない　orz

0806デフォルトの名無しさん

2010/10/15(金) 19:44:56

>>805
多態つかわねえでどうすんだよ。
こういう問題こそだろ。

デバッグが大変とかどんな組み方してんだよ。

0807デフォルトの名無しさん

2010/10/15(金) 20:52:29

>>801
ほら俺思想家だからw
ちなみ俺はでプログラマではないよ。全然違う仕事してる。

>>806
多態つかうと制御構造が見えづらくなるから、あえて使わず処理ナンバーで一括管理してるって言ってる奴に、
多態使えってそりゃ解決策になってねぇだろ。
ややこしい構造を嫌って、平べったくリスト構造で一括管理ってのは有りなんだよ。
箇条書きは技術者の良きお友達。

0808デフォルトの名無しさん

2010/10/15(金) 21:19:08

京都生まれの京都育ちの麻布卒
あ、東「京都」か

0809デフォルトの名無しさん

2010/10/15(金) 21:26:48

箇条書きよりはマインドマップの方がわかりやすいってマインドマップの本に書いてあった

0810デフォルトの名無しさん

2010/10/15(金) 21:31:37

>>808
まさかの同窓。。
とりあえず、あまり母校の名に泥を塗るような言動は止してくれ、頼むから。

0811デフォルトの名無しさん

2010/10/16(土) 04:29:02

>>807
> 処理ナンバーで一括管理してる
管理できなくなってるから困ってるんじゃねーの？

0812デフォルトの名無しさん

2010/10/16(土) 18:33:13

俺はそうとは読まなかったが。

とにかく、箇条書きは構造がシンプルだから、後々の応用が利いて良いんだよ。
その証拠にRDBも成功してるじゃん。Oracleとか自社の検定まで作って、ウハウハ。箇条書きすげぇって。
オブジェクト指向型のDBも有るけど、全然人気出なかったし。そんなもんだよ。

俺ら、もう良く知ってるわけよ。
テキストファイルで書いといてgrepしても良し、CSVで書いてエクセルで読み込んでも良し、
エクセルだったら、オートフィルタや関数やVBAも使えるし、あー便利便利。
ただ、かっこ悪い気がするっていう。

でも本当はかっこいいんだよ、箇条書き。
LinuxBoot時の山のようなinitには感動すら覚える。

0813デフォルトの名無しさん

2010/10/16(土) 19:59:52

>>812
そのための多態とファクトリーパターンだろ、死ねよ。

0814デフォルトの名無しさん

2010/10/16(土) 23:08:36

× 箇条書きは構造がシンプルだから、後々の応用が利いて良い
○ 箇条書きは構造がシンプルだから、バカでも理解できて良い

いや、わりと重要なことだけどな。世の中のみんなが天才ではないし。

0815デフォルトの名無しさん

2010/10/16(土) 23:16:09

OOP的な階層構造って、わかってる人が設計した物をわかってる人が読まない限りはスパゲッティにみえちゃうもんだからな

0816デフォルトの名無しさん

2010/10/16(土) 23:25:30

プログラマ以外でも書ける部分を箇条書きにしとけばいいって話しだろ
プログラマはOOP覚えろよ

0817デフォルトの名無しさん

2010/10/16(土) 23:54:57

なんか裸の王様っぽくなってきました

0818デフォルトの名無しさん

2010/10/16(土) 23:59:45

多態つかわないのに継承したり、
get/setだらけで実質ほとんどpublicフィールドになってたり
やたらややこしい事前条件を暗黙的に要求してきたり
何やってくれるのか全く想像できないメソッド名つけたり
やたらたくさんの機能を備えたクラスつくったり

そんなんするからOOPの可読性が悪いんじゃないかと勘違いする奴がでる

0819デフォルトの名無しさん

2010/10/17(日) 00:14:58

言語が許してるのが悪い

0820デフォルトの名無しさん

2010/10/17(日) 00:19:33

どう考えても使う奴の問題

0821デフォルトの名無しさん

2010/10/17(日) 00:25:22

>>817
まーわざと箇条書きとOOPを比較して、OOP派の人に無理に箇条書きを否定させる流れに持っていったからな。
そこは、「OOPも良いけど、箇条書きもいいね」って言えれば良かったのに、
それが出来ないのがOOP脳と言うかなんと言うか。。
2流なんだよ。俺が1流ってわけでもないがな。

0822デフォルトの名無しさん

2010/10/17(日) 00:27:14

あんまりそう言い出せる空気でもないだろここ

0823デフォルトの名無しさん

2010/10/17(日) 00:36:55

そもそも箇条書きで済むところと多態で済む所が同じとは限らん

0824デフォルトの名無しさん

2010/10/17(日) 00:49:33

そうなんだけど、そこはあえて比較させて、箇条書きを叩かせる方向へ持っていったのよ。
俺の悪知恵。

だけど、箇条書きって大概が箇条書きの箇条書きで2次元だから、
マトリックスになって、組み合わせが使えて、大概のことは出来るぞ。
A　○　×
B　○　○
C　×　○
こんな感じでさ。
プログラムで言ったら配列に相当して、
その強力さとシンプルさと道具としての奥深さは、皆理解しているところだろ？
これ否定するとか、天に向かって唾吐くようなものだわな。
あえて吐かさせといて言うのもなんだが。

0825デフォルトの名無しさん

2010/10/17(日) 00:52:51

あーごめん2次元って表現はおかしい罠。

0826デフォルトの名無しさん

2010/10/17(日) 00:57:47

箇条書きのスレ作って、そっちでやれ。

0827デフォルトの名無しさん

2010/10/17(日) 00:59:40

箇条書きって言うからイモいけどcsv, tsvとかいうとそうでもない
まぁcsvがいいか多態がいいかは状況によるよ

0828デフォルトの名無しさん

2010/10/17(日) 03:14:29

>>827
CSVやTSVじゃ構造化したデータを表現できねーだろ。
DBのテーブルならそんなんでもいいがな。

0829デフォルトの名無しさん

2010/10/17(日) 11:14:59

>>816
箇条書きで手に負えるような単純なもん作ってるうちはそれでいいが、
現代のプログラムはそれじゃおっつかない。だからOOPが必要、ってこったな。

例の彼はプログラマではないみたいだし、OOPが必要になるほど複雑度の高い
プログラムを書いたことがないんだろうな。
ワンライナー書いて「俺って天才ハッカーｗｗｗ」とか勘違いしてるタイプと想像。

あまり誰も言わんが、ワンライナーを賞賛する文化って、教育上有害だと思うんだよな。
ああいうのは、非実用的で実戦で使うのは有害な（だからこそ面白い）お遊びなんだ、
っていうのをもっと喧伝した方がいいと思う。

0830デフォルトの名無しさん

2010/10/17(日) 12:05:27

>>829
もちろん使い方次第だけど、ワンライナーが有害だとは思わないな。
書き捨てのスクリプト以外でワンライナー使うのは駄目。

0831デフォルトの名無しさん

2010/10/17(日) 12:46:47

是々非々じゃないレスはまず煽り

0832デフォルトの名無しさん

2010/10/17(日) 12:55:40

人によって理解力が違うんだから、ソースコードの意味を表すメタ情報が必要だと思うの
コードと仕様書から自動的にドキュメントを生成するのってない？
仕様はもちろんZ言語です

0833デフォルトの名無しさん

2010/10/17(日) 14:29:12

>>832
ScalaのSpecsみたいのとかはどうだ。テストケース＝仕様書。

0834デフォルトの名無しさん

2010/10/17(日) 14:54:43

おお、specsいいね

0835デフォルトの名無しさん

2010/10/17(日) 15:01:11

多態の良さは型switchを無くせることと、既存コードに手を加えずに拡張できる事であって
箇条書き云々とは全く関係ないと思うんだが

0836デフォルトの名無しさん

2010/10/17(日) 15:09:27

switchがなくせることがいいこと？

0837デフォルトの名無しさん

2010/10/17(日) 16:30:56

switchが不要になるのは結果として、だな。

0838デフォルトの名無しさん

2010/10/17(日) 16:43:46

処理対象が増えたら、全ての型switchに処理を追加してかなきゃいけない
継承すればそれが無くなる

0839デフォルトの名無しさん

2010/10/17(日) 22:48:20

>>838
継承じゃなくて多態だろ？

0840デフォルトの名無しさん

2010/10/17(日) 22:56:08

多態は形容であって、switchの分岐を増やすことでswitchで扱える型と処理の多様性を関係付ける行為は継承なんでは
おっぱお

0841デフォルトの名無しさん

2010/10/17(日) 23:22:59

継承は、親オブジェクトから性質を受け継ぐことを述べているに過ぎないだろ。
switchを消せるのは、同じインタフェースに対して別々のオブジェクトを作れることの恩恵に過ぎない。

0842デフォルトの名無しさん

2010/10/17(日) 23:23:25

いつもの人だけど、俺より日本語がヤバイってもうダメ。

0843デフォルトの名無しさん

2010/10/17(日) 23:58:30

一番いい日本語を頼む

0844デフォルトの名無しさん

2010/10/18(月) 00:06:15

そんな日本語で大丈夫か？

0845デフォルトの名無しさん

2010/10/18(月) 19:15:18

大丈夫だ、問題ない

0846デフォルトの名無しさん

2010/10/19(火) 18:30:09

>>843-845
こんなとこでやるなよw
気がつくまで時間かかるわ

0847デフォルトの名無しさん

2010/10/21(木) 12:39:10

ある日
俺「バカオヤジが片付けむちゃくちゃだから新しい棚買おうよ」
母「そうね、明日買いにいきましょう」
明日
俺「オヤジ　車貸してくれ」
父「おぅ、あそこの電気がつかんが・・・ちょっと電気の球とってこい」
俺「・・・」
父「ここの球がなぁ、前からつかん」
俺「・・・（無言で立ち去り部屋で布団に入りヌクヌクする）」
遠くから
父「あいたたたたた・・・ピー（糖尿病の血糖値を測る測定器の音）」
３０分後
母「お父さんが低糖になるからごはんあげてやって」
俺「・・・（メシをつぐ）」
父「（メシをうけとって）おい、電気買ってこいよ（ムシャクチャ）」
母「・・・」
俺「・・・」
俺「いつ棚買いに行く？（いつになったらこいつ死んでくれるだろう・・・）」

0848デフォルトの名無しさん

2010/10/21(木) 23:03:56

俺には難しすぎて意味がわからないが、
車持ってないお前が糞でFA？

0849デフォルトの名無しさん

2010/10/22(金) 16:17:45

兄が糞でＦＡのようだ

0850デフォルトの名無しさん

2010/10/25(月) 05:22:38

ツンデレですね！
デレ期はまだですか！

0851デフォルトの名無しさん

2010/10/25(月) 06:06:15

いいえ今日は月曜日です

0852デフォルトの名無しさん

2010/10/25(月) 06:13:31

俺を娘に変えると、とたんに・・・

0853デフォルトの名無しさん

2010/10/26(火) 11:16:16

ヤンキーデレのほうのヤンデレが連想された
ふしぎ！

0854デフォルトの名無しさん

2010/10/26(火) 23:22:25

でも良く考えたら、お前ら永遠の命って欲しいか？
死ぬことも出来ないってのもなかなか大変そうだ。
OOPや取り巻きのプログラマたちもそう思ったのだろう。
儚さ、刹那主義。滅びの美学。
縦割り構造。利権主義。お役所仕事。たらい回し。
とても日本的で良いじゃないか。

C言語は良すぎてダメだね。永遠に残るし。

0855デフォルトの名無しさん

2010/10/27(水) 13:56:02

すまん、永遠の命欲しい

0856デフォルトの名無しさん

2010/10/27(水) 15:37:26

コンストラクタでどこまで処理をするのが望ましいでしょうか？
クラスの機能を最低限満たせばよいですかね

0857デフォルトの名無しさん

2010/10/27(水) 16:39:31

そのクラスを使用できる状態に出来る最低限の初期化かねえ。
細かい設定はほかに持つのがすきかな。

でもコンストラクタで全て終わらせるのもそれはそれですきだけどな。

どういうのがいいのかねえ。

0858デフォルトの名無しさん

2010/10/27(水) 18:12:59

クラスの一通りの機能が使える状態にするところまで、かな。
生成したら基本的には、もう使える状態であるべきだと思う。

細かい設定もコンストラクタの引数でやるのが理想ではあるなあ。
作ったらもうほとんど弄る必要がなくて、役割上、本当に途中変更が必要な属性以外は
読み取りしかできないような感じにして、どうしても変更したいならオブジェクト作り直し。

…とはいえ、そういうワケにもいかんって場合もやっぱある。
その線引きは難しいところ。

でも最低限「生成しただけじゃ使い物にならない」ってのは避けたいかな。
出来れば生成しただけで一応使えるように、そうでなくても
生成→有効化、の2手順（有効にする前にやっておくべきことがあるクラスの場合）で一応使えるようにしておきたい。

0859デフォルトの名無しさん

2010/10/27(水) 18:20:24

何処で見たか忘れたけど、コンストラクタ内ではいろいろ処理を行わないことみないなやつ。
生成コストがどうのとか例外がどうのとかそんなないようだったきがするんだけど・・・。

こういう考えだと生成と各種変数の初期化くらい？
その後用途別の初期化メソッドを呼ぶのかね。

0860デフォルトの名無しさん

2010/10/27(水) 19:29:16

ファクトリ関数にすればいいんじゃね？

0861デフォルトの名無しさん

2010/10/27(水) 20:09:30

staticなメソッドで、目的別の生成用メソッドを持つってかんじ？
コンストラクタはprivateで隠蔽なのかな？

0862デフォルトの名無しさん

2010/10/27(水) 20:21:25

856です
ありがとうございました。

0863デフォルトの名無しさん

2010/10/27(水) 20:44:06

>>862バーローｗｗｗ

0864デフォルトの名無しさん

2010/10/27(水) 22:36:22

>>861
一部の言語では複数名称のコンストラクタを持てるから(Delphiとかそうだった希ガス)
そういう言語では単に各種用途のコンストラクタを用意する、になるのかな？

0865デフォルトの名無しさん

2010/10/28(木) 00:42:20

ほらもう、コンストラクタで何処までするか、こんなことに悩まなきゃならんなんて、時間の無駄だよなぁ。
コンストラクタって名前がダメなんだろうな、なにか特別な感じがして。
こんなのただの初期化用関数なんだから、深く考えるなよ。
init( &hoge );　だったら誰も悩まないのにな。
インスタンス確保したら勝手に初期化されてる、ってのは一見便利そうに感じるんだけど、
実際には引数を渡さなきゃならなかったり、完全に全自動ってわけにはいかないんだよな。
なんつーか、中途半端。別に初期化用関数方式でも構わないっちゃ構わない現状。
そのくせ言語レベルで組み込まれている仕組みだから、なにか活用しなきゃいけない気がして困る。
その点デストラクタは有用だな。とはいっても、GC無い言語だと意味半減だけど。
まーGCある言語だと、デストラクタ自体の意味が別の意味で半減して、これまたなんとも。
個人的にはコンストラクタもデストラクタも無いほうが良いと思っていて、
無くても問題ないように言語使用を練り直す方向が正しいと思ってる。
オブジェクト自身がコンストラクタやデストラクタを持ってるってのはガンだと思うから、
どこか別のところへ持ってくなり、なんらか別のトリックを用意するなり。

0866デフォルトの名無しさん

2010/10/28(木) 00:54:39

そんで、C++だと、暗黙の型変換までコンストラクタで賄うだろ。
初期化の仕組みで変換もするって、もうおかしいだろ。
そんで困って、コンストラクタでの暗黙の型変換を禁止するへんな予約語が追加されたんだっけか。
言語レベルで変な仕組み導入しまくって後で困ってるっていうね。
標準のIOストリームもそうだけどさ。色々やって、結局printf万歳だもんな。
バカの考え休むに似たりってか。あーC言語は平和だなぁ。

0867デフォルトの名無しさん

2010/10/28(木) 00:59:27

つーかコンストラクタってそんなに活用されてないよね。
大体はファクトリーパターンとか使うんだろ？
もうなんなんだろうね。
そもそも初期化ってのはそれなりに複合的な処理なんだよ。あっちゃこっちゃが相互作用で影響してくる。
そんな処理が単一のオブジェクトのしたにぶら下がってること事態おかしいっちゃおかしい。
だから、結局大したことできないっつーね。

0868デフォルトの名無しさん

2010/10/28(木) 01:26:55

どこまでって明らかにオブジェクトの初期化までだろ

0869デフォルトの名無しさん

2010/10/28(木) 03:03:59

あれの自作言語ではnew AddExpr(new IntExpr(4), new MulExpr(new IntExpr(4), new IntExpr(12)))
相当のことやると漏れるようにできてんのか。なる。

0870デフォルトの名無しさん

2010/10/28(木) 08:31:10

>>865
init( &hoge ); だと init() の管理は誰がやるんだ。

0871デフォルトの名無しさん

2010/10/28(木) 11:24:06

>>865
GCある言語だとデストラクタの扱いは微妙なんじゃなかったか
最近はusingやwithみたいに特定のスコープを抜けたときに処理するという仕様が多かったような

0872デフォルトの名無しさん

2010/10/28(木) 11:38:53

C#で「デストラクタ」と呼んでるものはファイナライザ
明示的ないしスコープから抜けた時に明に呼ばれるものがデストラクタで
参照が無くなってる場合に暗に呼ばれるものがファイナライザ

0873デフォルトの名無しさん

2010/10/28(木) 12:01:32

そうなるとDisposeは単なる事後処理メソッドの規約みたいなものでいいかいな？

0874デフォルトの名無しさん

2010/10/28(木) 13:15:01

「オブジェクト自身がコンストラクタを持っている」という時点でなんか勘違いしてるだろ

0875デフォルトの名無しさん

2010/10/28(木) 13:22:57

確かに。読む気しなかったがコンストラクタ持ってるのはクラスだよな。
プロトタイプベースでもオブジェクト自身はコンストラクタでは…ないよな？

0876デフォルトの名無しさん

2010/10/28(木) 13:24:23

オブジェクトが持ってるのは半分程度だな。

thisが使えない初期化リストは…オブジェクトのものと言い難いかもしれない。
いや、初期化リストはコンストラクタと呼ばないのかもしれない。
俺は俺が何をいってるのか、わからないのかもしれない。

0877デフォルトの名無しさん

2010/10/30(土) 18:31:12

いよいよ「OOPには2012年までのカレンダーしかない」が現実味を帯びてきたな。
って、今日はオカルトキャラで行こうかと思ったけど、無理だったいつもの人。

オブジェクト指向・・・オブジェクト・・・・オブジェクトって何？
二通り思い浮かぶ。
1．オブジェクト=モノ
だけど、物って言っちゃうと、アホっぽいというか。物指向って即物的というか。
それを素晴らしいアイデアのように言われても。なぁ。
2．オブジェクト=対象
対象って言うからには、何かの対象なわけで、じゃあ、オブジェクトは何の対象なの？って言われれば、
オブジェクトは処理の対象なわけで。
英語の文法を考えてもわかるけど、述語もなしに、対象だけポツンっと出てくることって無い訳で。
あくまで、処理側から目線で、自分の処理の対象はアレですって意味合いだから。
だから、オブジェクトがメソッド持ってて、自分のメンバメソッドの処理の対象は自分だから、
自分は自分のメソッドの対象で、すなわち自分は対象＝オブジェクトですってのは
何かふに落ちない。
自分は自分自身の持つ機能の対象だから、自分は対象です。ほらなんか変だ。

どっかでおかしいんだよね、OOP。
そのおかしさをずっと引きづってる。ウソが雪だるま式。掛け違えたボタン。

0878デフォルトの名無しさん

2010/10/30(土) 18:42:32

だからなんで論文一本も挙げずに自論をグダグダ言っちゃうわけ？
色々足りてないんでねーのもぅ

0879デフォルトの名無しさん

2010/10/30(土) 18:58:14

ドSだから。

0880デフォルトの名無しさん

2010/10/30(土) 20:04:58

といいますと、ＯＯＰに関する論文がござるようでぜひともそのＵＲＬを貼っていただけたらと思う次第でございます

0881デフォルトの名無しさん

2010/10/30(土) 22:56:19

>>877
オブジェクトひとつで完結するわけじゃないんだから
処理を呼び出される対象でいいじゃん

0882デフォルトの名無しさん

2010/10/31(日) 02:26:15

>>881
だったらそれは、C言語だよ。

0883デフォルトの名無しさん

2010/10/31(日) 09:37:34

対象を最初に書くからオブジェクト指向、って言い方も聞いたことあるな

0884デフォルトの名無しさん

2010/10/31(日) 12:18:44

アホっぽくて良いね

0885デフォルトの名無しさん

2010/10/31(日) 12:28:47

過去からの経験の蓄積を元にした、現在のオブジェクト指向の実践が既にあるのに、
いまさら「オブジェクト」っていう言葉の定義を云々して何がしたいんだ？

0886デフォルトの名無しさん

2010/10/31(日) 12:43:03

いまさら、という言葉をチョイスする時点で。

0887デフォルトの名無しさん

2010/10/31(日) 12:57:10

OOPの進化(bugfix)は未だ衰えずということだ

0888デフォルトの名無しさん

2010/10/31(日) 13:14:52

このさい何がオブジェクトかなんてどうでも良くって
ちゃんとカプセル化したら依存関係が整理できて再利用しやすくなるという事実のみが大事

0889デフォルトの名無しさん

2010/10/31(日) 13:28:31

>>888
同意。とにかく、整理は全てのプログラマの恩恵となる。
KISSの次はOOP。

0890デフォルトの名無しさん

2010/10/31(日) 13:31:18

じゃあカプセル化って何？ってなる
依存関係が整理できて再利用しやすくする事そのものがカプセル化ですか？

0891デフォルトの名無しさん

2010/10/31(日) 13:35:31

カプセル化は内部状態を公開しないこと
依存関係の切り離しそれそのもの

0892デフォルトの名無しさん

2010/10/31(日) 14:45:12

内部状態を公開しないことと、
依存関係の切り離しは何の関係も無いだろ。
たしかに内部状態と外は切り離されるが、その代わりメソッドが依存するだろ。

0893デフォルトの名無しさん

2010/10/31(日) 14:50:32

それから、カプセル化とOOPは関係ないと思うんだよね。
だって、C言語でも普通にするでしょ、カプセル化。
ハンドルとかで対象物を抽象化するわけな。
だけど、対象物を抽象化したからって、オブジェクト指向ってわけでは無いよな。

0894デフォルトの名無しさん

2010/10/31(日) 14:52:52

その理屈で行くと多態もOOPと関係ないな
Cや関数型言語でも多態できるしな

0895デフォルトの名無しさん

2010/10/31(日) 14:53:40

OOPってやっぱオブジェクトやクラスがメソッド抱えててってイメージがある。
だけど、マルチメソッドになると、メソッドはグローバル空間に行っちゃう。
だからより一層OOPって何なのって話になる。本当は無いんじゃないか？そんなもの初めから。

0896デフォルトの名無しさん

2010/10/31(日) 14:56:26

>>894
実際関係ないと思うよ。
だってマルチメソッドだと、クラスやオブジェクトがメソッド抱えてるって感じじゃないし。
要は動的オーバーロードだし。

0897デフォルトの名無しさん

2010/10/31(日) 15:00:40

だからオブジェクトが何かなんてこのさいどうでも良いと教えてやったのになんでまたそこに戻るんだ。
そんな曖昧な物いくら考えても有益なことなんて一つも出ないぞ。

0898デフォルトの名無しさん

2010/10/31(日) 15:02:04

いや、OOPがまるで実体の無いペテンだってことが解るじゃん。

0899デフォルトの名無しさん

2010/10/31(日) 15:02:41

>>892
内部状態は全て自分のメソッドからのみ変更される。
これで依存関係が切れてなかったらそれは単なる設計ミス
内部状態が内部状態になってない。

0900デフォルトの名無しさん

2010/10/31(日) 15:06:23

だから、そのメソッドが外部と依存するだろ。
依存関係が切り離されてるんじゃなくて、
実装とインターフェースが切り離されてるだけだ。

0901デフォルトの名無しさん

2010/10/31(日) 15:08:18

そして、実装とインターフェースが切り離されていることと、再利用性は何の関係も無い。

0902デフォルトの名無しさん

2010/10/31(日) 15:12:48

自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。

外部状態がどうなってるかを気にせず、
「この内部状態の時にこのメソッドが呼ばれたらこの内部状態に変わる」
という一貫した普遍性を維持するためのカプセル化だし
これを依存関係が切れてると言う。

0903デフォルトの名無しさん

2010/10/31(日) 15:19:05

何言ってるんだ？
自分のメソッドと、自分以外の他オブジェクトは、
たとえカプセル化しても、メソッドを通じて依存しあってることには変わりない。

>自分の内部状態が自分のメソッドに依存しているのは当たり前だろ。
逆逆。
実装とインターフェースを分離することで、自分のメソッド(というかインターフェース)と内部状態(というか実装)を
依存「しない」ようにするのがOOPだろJK。

>これを依存関係が切れてると言う。(ｷﾘｯ
聞いたこともない。OOPを支持する人って、やっぱこのレベルなんだな。

0904デフォルトの名無しさん

2010/10/31(日) 15:22:42

>>903
依存しあってる？
使う側は使われる側の挙動に依存してるかもしれんが
使われる側は使う側の事情なんて何も気にせず、与えられた機能を実行するだけだぞ。

ライブラリの挙動がアプリの実装に依存するわけ無いだろ馬鹿か

0905デフォルトの名無しさん

2010/10/31(日) 15:22:57

カプセル化して内部の整合性を取ることを、依存関係が切れてるって表現するの、
本当に聞いたことがない。悪いが。

0906デフォルトの名無しさん

2010/10/31(日) 15:24:48

まあ確かに依存しあってるって表現はまずかったな。依存しているが正解。

0907デフォルトの名無しさん

2010/10/31(日) 15:32:12

つまり、内部状態をもつということはそれ以外の外部の状態は気にしなくてよくなるわけだ。
気にしなくてよくなるから、そのクラスの実装に関して依存関係はない。
で、その内部状態はカプセル化によって実現している。

0908デフォルトの名無しさん

2010/10/31(日) 15:41:19

内部状態を持つ(というか、内部状態をプライベートにして外から見えなくする)ことは、
外から内部の実装を気にしなくても良くなる、というだけで、
内部から外の状態を気にしなくても良いと言うことにはならない。

なんか全て反対言うよな。頭おかしい。

0909デフォルトの名無しさん

2010/10/31(日) 15:44:43

内部から外の状態をどうやって気にするんだ。
誰が自分を使うかもわからんのに。

0910デフォルトの名無しさん

2010/10/31(日) 15:46:24

シングルトンやグローバル変数にアクセスすることはありうる。
良くないコードだが、ありうる。有りうるんだよ。

0911デフォルトの名無しさん

2010/10/31(日) 15:47:37

そんな特殊ケースの話されましても

0912デフォルトの名無しさん

2010/10/31(日) 15:49:49

だいたい、カプセル化って、外から中を見えなくするものって、普通そう考える。
中から外を見えなくするって発想は、その発想がありえん。考え方や物事の組み立て方がおかしいとしか。
そんな思考回路搭載してて設計なんぞできるんかねぇ。

0913デフォルトの名無しさん

2010/10/31(日) 15:49:57

あるクラスA内部で外のある状態Bを気にするっつう状況があるなら
その状態Bに対して責務を持つクラスCが存在するという仮定においてAからCへの依存関係が存在するので･･･
どういうことになるんだろう？

0914デフォルトの名無しさん

2010/10/31(日) 15:54:41

あー責務君の相手はしてはならないんだった。リアルな人だからな。

0915デフォルトの名無しさん

2010/10/31(日) 15:55:45

外から中が見えないってのは、単にアクセシビリティの話であって
それはビジビリティとは微妙に違うからな。

0916デフォルトの名無しさん

2010/10/31(日) 15:59:47

微妙にってどう違うのか

0917デフォルトの名無しさん

2010/10/31(日) 16:02:59

だけど、どうであれ、カプセル化って中を見えなくするものだから。

0918デフォルトの名無しさん

2010/10/31(日) 16:29:29

別に、外から内部の実装を気にしなくてもよくなる、というのを否定してるわけじゃない。
いくらカプセル化しても、外から間接的に内部状態見てるというのは変わらんけどね。
なんらかの挙動を期待してるわけだから、あたりまえだけど。

カプセル化について本質的に不可視にできるのは、中から外だけ。
もちろん、それを破る実装はいくらでもできるし
破る必要が出てくる場合もあるのもわかるよ。

でも、外の状態を一切気にせず
粛々と自分の内部状態に依存した振る舞いだけをするクラス作ったほうが
実装がシンプルになって再利用もしやすくなるよ。

つまり外部状態に依存しないんだから、どんな外部状態でも使えるってことだ。
何かの機能を切り分けたいと思ったときの粒度を考える参考にしてくれ。

0919デフォルトの名無しさん

2010/10/31(日) 16:33:55

う～んそうだね、
class A
{
private:
　　int private_member;
public:
　　void method( B *b ){ b->member=1; }
};
これだと、クラスAは、カプセル化されてはいるけど、クラスBの実装に依存している。
だから、カプセル化したからって、外部のことを気にしなくて良いかと言うと、そうでもない。
あくまで外から中のことを気にしなくて良くなるだけ。

0920デフォルトの名無しさん

2010/10/31(日) 16:36:49

>カプセル化について本質的に不可視にできるのは、中から外だけ。
だからそれはカプセル化とは言わん。

0921デフォルトの名無しさん

2010/10/31(日) 16:37:41

外から中の事を気にしないといけないコードなんて書こうとおもえばいくらでもかけるので
わざわざ依存関係が問題になりそうなコード持ち出してあーだこーだ言われても別に

0922デフォルトの名無しさん

2010/10/31(日) 16:38:43

カプセル化：外から中を気にしなくていい。
自己完結化：外のクラスを知らない、使われ方にいかなる想定をも置かない、外に左右されない、便利。

0923デフォルトの名無しさん

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
勉強しなおせ。
あくまで、インターフェースと実装の分離のことをカプセル化って言うんだ。
外に対して隠蔽することをカプセル化って言うんだ。
外の状態がどうとかって話じゃないから。

0924デフォルトの名無しさん

2010/10/31(日) 16:49:57

まあ別に言葉の定義にこだわってるわけじゃないから、それはどうでもいいんだけどね。
そんなんで設計できるのと言われたら、そっちの方が便利だよって話で。

0925デフォルトの名無しさん

2010/10/31(日) 16:57:44

自己完結ってことは共通で使う関数や定数すら使わないのか

0926デフォルトの名無しさん

2010/10/31(日) 17:00:55

使わないように切り分けると良いよ。
ラムダ欲しくなるね。

0927デフォルトの名無しさん

2010/10/31(日) 20:41:21

>>925
自己完結なのは自分以外のステータスを意識しないで使える物じゃねえか？
状態を維持しない関数はもはや定数に等しいわけだからね。

0928デフォルトの名無しさん

2010/10/31(日) 20:53:47

まぁ、もし他のオブジェクトに対する依存関係が必要になるなら、
何らかの作法に従って、そのことを明示するようにすればいい。

典型的な委譲だが、

public class MyServiceImpl implements MyService {
　public MyServiceImpl(A a, B b, C c) { }
　...
}

その実装が依存する他のオブジェクトはコンストラクタで受け取るようにする、
と決めれば、その実装が、他のどんな実装に依存しているか分かりやすくなる。
もちろん、A, B, Cはインタフェースね。

翻って、グローバル変数やシングルトンが良くない理由でもある。
依存関係の存在を不可視にするからね。

0929デフォルトの名無しさん

2010/10/31(日) 21:43:17

なるほど

0930デフォルトの名無しさん

2010/11/01(月) 12:45:51

>>895
「クラスベースOOPL」がOOPなんじゃないからね。
OOP自体にはクラスは関係ないし、OOPLでなくてもOOPは出来る。
OOPLと非OOPLには、それを実装するのに都合が良いかの違いがあるだけ。

クラスは、OOPを実現するために都合の良い機能の1つで
そう言った「OOPを実現するのに都合の良い機能」を
多く言語仕様に取り入れたのがOOPL。

マルチメソッドだとメソッドはグローバル空間に行っちゃうんだけど
多態や継承というOOPの機能を実現する上ではさして問題はないよ。
そのオブジェクトに対応した定義がなきゃ拒否されるだけ。
カプセル化には多少影響有るかもしんないけどね。

0931デフォルトの名無しさん

2010/11/01(月) 18:39:26

ドメイン駆動設計の立場からの解説
http://d.hatena.ne.jp/digitalsoul/20101027/1288180208

0932733

2010/11/02(火) 06:17:45

>>931 数式書けない奴の言い訳にしか見えん

0933デフォルトの名無しさん

2010/11/03(水) 01:01:38

これ本当にひどいな。回りくどい上に解りにくくて、結局何も言ってないっていう。
アホだね。無視無視。こういうペテンが増えたのもOOPの負の一面だよな。
OOP自体が曖昧だから、何言ってもかまわいやしないってか。
近寄らないこったな。時間の無駄。

0934デフォルトの名無しさん

2010/11/03(水) 07:58:14

おまえが馬鹿でいるだけなら他人には迷惑かからんからな

0935デフォルトの名無しさん

2010/11/03(水) 08:43:20

しかしながら人は生きているだけで周りに迷惑を掛けているのです

0936デフォルトの名無しさん

2010/11/03(水) 09:43:11

>>931
良し悪しはおいといて
OOPと関係なさそうだね、これ

0937デフォルトの名無しさん

2010/11/03(水) 13:21:46

「P」とは関係ないかもな。

0938デフォルトの名無しさん

2010/11/03(水) 13:38:38

OO とも全然関係ないね, 脳みその作りを疑うわw

0939デフォルトの名無しさん

2010/11/03(水) 14:54:12

>>938
ドメイン知識を実装に落とす方法としてオブジェクト指向は有効だ、なぜなら、
って丁寧に書いてあるじゃん。

0940デフォルトの名無しさん

2010/11/03(水) 15:20:51

windowsAPIみたいなグローバル関数の呼び出しってどうしてますか？

0941デフォルトの名無しさん

2010/11/03(水) 15:30:35

直接使わずにクラスにラップする
ほら大抵セットで呼び出すようになってるし

0942936

2010/11/03(水) 18:06:26

スレを読み返して気づいたんだが
>>931が読んでほしかったのは
「オブジェクトとは？」の部分だったんだな

適当なことを言ってしまって申し訳ない

0943デフォルトの名無しさん

2010/11/03(水) 19:41:34

グローバル嫌って数学関数までクラスメソッドにするのはどうかと思う
静的メソッド使うんならともかく

0944デフォルトの名無しさん

2010/11/03(水) 19:42:08

動けばいい

0945デフォルトの名無しさん

2010/11/03(水) 20:12:26

例えばウインドウクラスを作った場合、
コンストラクタでパラメータ受け取ってCreateWindow呼び出してハンドルを保持する？
でウインドウクラスを操作するクラスはウインドウハンドルを貰えばいいのかクラスごと貰えば良いのか、、、

0946デフォルトの名無しさん

2010/11/03(水) 20:22:50

最終的にはWHND経由しないといけないから、なんか困るよなあれ。
抽象的に、自前クラスでラップして…でもやっぱWHNDむき出しにしたほうがラク。

0947デフォルトの名無しさん

2010/11/03(水) 20:38:19

ウィンドウクラスだって。アホ草。

0948デフォルトの名無しさん

2010/11/03(水) 21:19:18

>>943
OOPLの多くは数学関数を専門に扱うわけではないから
・Mathと示すことで数学関数であることが明確になる
・他でその識別名をまだ使うことができるようになる

0949デフォルトの名無しさん

2010/11/03(水) 21:27:57

>>947
例えばっつってんだろうが

0950デフォルトの名無しさん

2010/11/03(水) 22:34:02

例えってのは抽象的な表現を具体的な事例にすることで理解を助けるものであって、理解を与えるものじゃない

0951デフォルトの名無しさん

2010/11/06(土) 14:21:01

具体的な事例をあげられないなら、
それは使い物にならないということでしょう。

0952デフォルトの名無しさん

2010/11/06(土) 18:33:00

抽象的な表現ができないなら、
それは応用できないということなんではないでしょうか

0953デフォルトの名無しさん

2010/11/06(土) 19:34:23

やっぱり二つで一つなんだな

0954デフォルトの名無しさん

2010/11/06(土) 20:02:38

A is applicable to B.
A is abstract.

英語のことはよくわからんが、abstractって言うとかっこいいのか？

0955デフォルトの名無しさん

2010/11/06(土) 21:28:43

どうでもいいじゃん。
それより、950は次スレが必要かどうか考えるほうが先だな。
何故かいつも立ててくれてる人は、誰だか知らないけど、乙なんだけど、
OOPへの善意なのか悪意なのかはわからんよな。

0956デフォルトの名無しさん

2010/11/07(日) 00:03:13

文士様のOOPへの憤りがマックスに達した時にスレは降臨なさいます。

0957デフォルトの名無しさん

2010/11/07(日) 17:31:04

ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか

0958デフォルトの名無しさん

2010/11/07(日) 17:40:48

場合による

0959デフォルトの名無しさん

2010/11/07(日) 17:51:05

>>958
判断基準は？

0960デフォルトの名無しさん

2010/11/07(日) 18:00:26

>>959
基準というのは、その時その時の状況が基準になり、それから判断される。
だから、状況を出してもらわない事には、基準としての判断が不可。

0961デフォルトの名無しさん

2010/11/07(日) 23:46:58

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
クラスフィールドやクラスメソッドを使うのか？

0962デフォルトの名無しさん

2010/11/08(月) 15:06:55

>>961
そうです

0963デフォルトの名無しさん

2010/11/08(月) 18:07:26

ほらまたこんなことで悩まなきゃいけないのがOOP。
仕事の押し付け合い。
利権の奪い合い。
どこの縦割行政だよ。

人間は生活のためにそういうのがあるのは分かるけど、
コンピュータにそれいるか？ってな。

コンピュータはやっぱアメリカ主導だし、
アメリカは何でも横のつながりが強い機能主義だよ。

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
どこで処理するかって？
処理は関数でするもんだ。
処理がクラス間をまたいでるんだろ？
だったら外でしろよ。それが完結かつ明快。

0964デフォルトの名無しさん

2010/11/08(月) 18:23:31

まず、俺らが扱う所謂コンピュータって呼ばれてるものの構造を良く考えてみよう。
電卓と何が違う？
1.膨大なメモリがある。
　ゆえにメモリを管理する必要がある→構造体、malloc等。
2.制御をプログラミングできる。
　ゆえに制御構造を構築する必要がある→if文、for文、関数等。
そんで、この1と2は本質的に別物の、別次元の問題だということ。
だから別々に取り扱う必要がある。
一緒くたに扱おうとする、例えば、データと制御を紐付けるなど、
し始めると、どこかで矛盾が出てきて、上手くいかなくなってくる。
最初は良くても、どっかでしんどくなる。
「行ける」と思っても、実は「行けない」道だったんだよOOPは。
データ構造はwhatの意味合いが強いし、
制御構造はhowの意味合いが強い。
whatで質問してhowで返答したら、即バカのレッテルを貼られる。
whatとhowを分けて考えられるかどうかは、バカと常人を分ける有名な垣根。

0965デフォルトの名無しさん

2010/11/08(月) 18:36:48

それでも、ポリモやカプセル化は強く要望される。それは解る。
だけど、でも、別にクラスやオブジェクトに頼った仕組みでそれを実現しなきゃならないって事はないんだろ？
カプセル化は最重要項目でもあるんだから、それ専用の構文を用意したって構わないだろうし、
ポリモだって動的オーバーロード(マルチメソッド)でも構わない。
問題は、そういう手軽な言語が無いこと。あってもメジャーじゃないこと。
マイクロソフトとかそいういう影響力があるところが頑張ってくれれば良いんだが、
C++広めて、こんどはJavaパクってC#作ってるような所だから、期待するだけ無駄か。
生産性の高いものを提供するより、一件良さそうに見えて、実は罠だらけなものを
押し付けたほうが、ベンダー的にはユーザを囲い込めてウマーだしな。本も売れるし。
てか、マイクロソフトってそういう罠をよく仕込むよね。おー怖い怖い。
Sunは多分天然。D言語の奴らは沸いてるし、Lispの人たちは折れてくれない。
Cの人たちは満足して思考停止状態、さぁどうする。

0966デフォルトの名無しさん

2010/11/08(月) 19:24:35

さぁどうするとか書いちゃったけど、忘れてた。Oracleだよ、Oracle。
あっこがDBシームレスな手続き型言語作れば良い。
DBは好きだが、SQLは今となっては拡張拡張でワケワカランことになりつつあるし、
その辺含めて、DBシームレスなC言語風手続き型言語をさ。
インピーダンスミスマッチの問題も解決するし、
トランザクショナルメモリで、マルチスレッドの同期やデッドロックの問題を根こそぎ解決できる可能性すらある。
かなり手堅い仕事するし、必要なものが何か良く解ってる会社だから、期待してるんだがなー。
もしかして俺が知らないだけで、もうあるんだろうか。
業界人じゃないから最近のことは良くわからん。

0967デフォルトの名無しさん

2010/11/08(月) 19:48:56

どこのコピペ？
単体で動かすのは簡単でも保守と利用が難しくなるスパゲティコードは最近はやらないよ
linuxがモノリシックカーネルを捨て去った様にね

0968デフォルトの名無しさん

2010/11/08(月) 19:58:45

よく分からないって自覚があるのに批判できるとか凄いな。

0969デフォルトの名無しさん

2010/11/08(月) 20:56:06

保守や再利用どころか碌にコード書いた経験がない人だから、
まあわからんのも無理は無い。

0970デフォルトの名無しさん

2010/11/08(月) 22:18:22

いつもの人はもうあきらめて、データ(とアクセサ)だけ持ってるクラスと
メソッドだけ持ってるクラスでも作ってそれで我慢しろよ

0971デフォルトの名無しさん

2010/11/08(月) 23:31:14

>>962
なぜオブジェクトで操作しないのかがわからないけど

>ある処理を行う場合、クラスから値を貰うのか、クラスに処理をしてもらうのか、どちらが良いでしょうか
その処理で変更されるフィールドがある方でいいのでは。
２以上のクラス・フィールドが変更される場合はマスターデータに近い方で処理するとか。
基本、自分自身のフィールドは自分で変更した方がいいと思う。
まっフラグや状態などトランザクション系のフィールドは別で処理して戻り値を設定してもいいと思うけど。

データを基準に判断したら。

0972デフォルトの名無しさん

2010/11/09(火) 06:40:56

>1.膨大なメモリがある。
>　ゆえにメモリを管理する必要がある→構造体、malloc等。

で、もうダメだなこの人って思った。構造体は趣旨に則ってて良いんだが
膨大なメモリがあるなら、なおさらメモリ管理は極限まで抽象化しないとダメで
mallocなんてもってのほかだろ…w

0973デフォルトの名無しさん

2010/11/09(火) 11:05:04

管理って具体的になんだ？
メモリの一部の空間に名前を付けてアクセスしやすくすることも管理なのか？

0974デフォルトの名無しさん

2010/11/09(火) 22:39:15

>>964 アホだよなおまえ、アホだと言ってくれ、頼むから…

0975デフォルトの名無しさん

2010/11/09(火) 23:04:27

まーちょっと説明が回りくどすぎたかな。
もっと平たく言うと、
mallocや構造体などは、メモリを操作するための仕組み。
if文や関数などは、プログラムカウンタを操作するための仕組み。
それぞれ別々のディバイスを対象としている。
メモリとプログラムカウンタは、独立して存在しているので、
「mallocや構造体など」と「if文や関数など」も、
独立した概念で存在する必要がある。
だって、もともと独立したディバイスを操作するためのものだから。
車で言えば、もしハンドルとアクセルがくっついていたら困るだろう。
それぞれ別々に操作したいはず。それと同じこと。

0976デフォルトの名無しさん

2010/11/09(火) 23:08:54

逆に言えば、
mallocと構造体を統合したり、
if文と関数を統合したり、
は、問題ない。
元々同じディバイスを操作するものなんだから、
それら同士であれば、統合できるのなら統合しても良い訳だ。
簡単簡単。わかってしまえば簡単な話だな。
しかし、知らないと罠にはまる。

0977デフォルトの名無しさん

2010/11/09(火) 23:18:42

となると、丁度いいところで分けようと思うと、
自然とマルチメソッドということになる。
構造体はメモリ操作を担当。
関数はプログラムカウンタ操作を担当するってんだから、
関数呼び出し側に、引数の構造体のwhatに基づく分岐を統合して、
マルチメソッドとするのが自然。
単一ディスパッチのOOPでは、
構造体やオブジェクトにポリモと称する分岐の機構を持たせたから可笑しくなった。
あくまで関数側に持たせるべき。

0978デフォルトの名無しさん

2010/11/09(火) 23:21:45

>>970
メソッドだけ持ってるクラスの名前は、「please」にしたら洒落てて面白いと思うんだ。
please method obj1 obj2

0979デフォルトの名無しさん

2010/11/10(水) 00:27:58

>>975-977
最近のグリッド指向とかクラウドとかディスってんの？
屋上に行こうか

0980デフォルトの名無しさん

2010/11/10(水) 00:36:55

>>979
無知ってほんとに恐ろしいよな…。

0981デフォルトの名無しさん

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++の設計と進化』の爪の垢でも煎じて飲めとしか。

0982デフォルトの名無しさん

2010/11/10(水) 00:53:39

基本は変わらんと言うに。
量子コンピュータが実用化したら撤退してやるよ。

0983デフォルトの名無しさん

2010/11/10(水) 00:59:20

C++は失敗しただろ。まだ言ってんのかよ。
もうみんなテンプレートに夢中で、クラスとかどうでも良くなってる。
C++的OOPに忠実なIOストリームは使いにくく、逆にvectorやlist、shared_ptrは超便利。
MFCも使いづらかった。C++上ではもう決着は付いたもんだともうが。
OOPを応援したいのなら、もっと勝算のある他の言語挙げれば？あるかは知らんが。

0984デフォルトの名無しさん

2010/11/10(水) 01:22:14

結局彼が嫌いだったのは仮想関数テーブルであり、
彼にとってOOPとは仮想関数テーブルを使うことである。つうことか。
頭のおかしい人かと思っていたが、彼はOOPを一般に広まっている意味ではない意味で使っていると
気づいて（コミュ障は措く）別に障害がある人ではないとわかったよ。

0985デフォルトの名無しさん

2010/11/10(水) 01:23:28

だいたいさー、構造体にvtable持たせるって事自体アホなんだよ。
そんなことしたらオフセットがずれて使いづらいだろーが。Cとの親和性も悪くなる。
それに、Windows.hなどで定義されてる生の構造体に動的な機構を持たせることも出来ん。
何たる中途半端。
vtableは参照が持ってりゃいんだよ。
参照が自分がさしてる型を動的に把握できりゃ、それで十分だろ。
ポリモは参照越しにするんだからよ。

生構造体　-　動的型の参照orポインタ　-　マルチメソッド機構　-　生関数

こういう配置が望ましい。
そうすれば、構造体や関数は余計な機構の付いてない、C言語のそれだから、
扱いやすいし、解りやすいし、使いまわしもしやすい。
構造体先頭のvtableとか邪魔なだけなんだよ。

0986デフォルトの名無しさん

2010/11/10(水) 06:05:55

>>984
抽象化ができないんだろうな。
サービスごとにインタフェースを切って…みたいな話がなぜ重要か、とか一生理解できなそう。

実際には、彼がよく持ち出すmalloc一つ取っても、物理メモリの管理を抽象化してくれる、
OSが提供するサービスなんだが。ローカルマシン上で動くプログラムを書いている限りは、
「主語」がOSだから、サービスの提供元として明示的に指定する必要がないってだけで。

RDB屋とかがよく言うデータ指向設計みたいな話も、RDBMSというフレームワークが、
データに対して、ユーザがプログラムしたロジックを強制してくれるから成り立つわけだ。
つまり、データとロジックをまとめて、サービスとして外部に露出しているという意味では
OOPと変わらん。

0987デフォルトの名無しさん

2010/11/10(水) 06:31:25

結局のところ、
1. データとロジックをまとめてインタフェースを定義し、サービスとして外部に公開する
2. 他のプログラマは、インタフェース経由でサービスを利用しながら処理を書き、さらにサービスを作る
という概念に沿っていないプログラミングモデルなんて存在しない。
オブジェクト指向も、結局はこういう概念を実現する方法の一つに過ぎない。

かつての、ローカルマシン上で動くプログラムが前提だった時期は、
「誰に」サービスの実行を依頼するかは自明であり、考える必要のないことだった。
なぜなら、「プログラムから見える計算機資源＝世界」だったから。
正確にはそれは「ウソ」なんだが、OSや言語が隠蔽することで、あたかもそうであるか
のように扱えるようにしてくれていた。

しかし、これからマルチコアやクラウド環境のように分散処理が当たり前になっていくと、
「どの計算機資源を使って処理をするか」という話が入ってくるのは不可避になる。
ま、多くの場合、そういったことはフレームワークで隠蔽して、プログラマが意識しなくて
良いように設計されるだろうけど。

とはいえ、1CPUで「プログラムから見える計算機資源＝世界」を所与の前提とした議論は、
ますます現実と乖離していくだろうね。

0988デフォルトの名無しさん

2010/11/10(水) 18:03:06

>>984
彼がOOPだと思ってるのは「クラスベースOOPL」だけみたいだからね。
マルチメソッドを使ったOOPLの実装もあるし、
クラスを使わないOOPLの実装もあるし、
そもそもOOPってパラダイム自体はOOPLでなくても実現できるのに。

0989デフォルトの名無しさん

2010/11/10(水) 20:22:26

いつもの人だけど、結論は読んだ人自らが決めるといい。

0990デフォルトの名無しさん

2010/11/10(水) 20:37:36

そして、1CPUとかまるで関係が無いと言うね。
1CPUだとOOPはダメだが、分散処理ならOOPは上手くいく、
そんな展開には発展しえないのに、まるで関係ないこといって、議論のすり替え。

そしてOOPの拡大解釈。あれもOOPこれもOOPすべてOOPだからOOPは正しい。
アホ草。いつまで屁理屈いってんだか。
まー屁理屈を屁理屈だと理解できないあたりがさすがのOOP脳だがな。
本当左翼と似てるんだよなー。誰しもが通る道なのかもしらんが。

だから誰も近づかないんだよな。もうそっとしておくしか。手遅れなんだろう。
こう言うのが多いからあの業界は嫌だったんだ。まー一定数何処にでも居るがな。
困った困った。

0991デフォルトの名無しさん

2010/11/10(水) 20:49:00

誰も近づかないっていうか皆使ってます

0992デフォルトの名無しさん

2010/11/10(水) 20:51:45

あまりLISPをディスるのはよくない

0993デフォルトの名無しさん

2010/11/10(水) 21:42:28

OOPの拡大解釈も何も、勝手に狭めてるのは誰だよ。
OOPについての書籍だって、始めのうちはC言語とかから出てたんだぜ？

0994デフォルトの名無しさん

2010/11/10(水) 22:15:42

C言語の構造体に関数ポインタ突っ込むんだろ？それがまさにアホなやり方だってんだよ。
拡張性のためにそうせざるを得ないこともあるが、仕方なくすることだ。例えば、Windowsの窓関数とかな。
コンパイル後のOSの挙動をアプリから変更できるように、もうね、仕方なくしてる。
フルコンパイルするの前提なら、本来必要の無い手法。
本来ある種のテクニックとして取り上げて、積極的に利用していくようなものではない。

0995デフォルトの名無しさん

2010/11/10(水) 22:30:11

「OOPLにあらずんばOOPにあらず」ですか？

0996デフォルトの名無しさん

2010/11/10(水) 22:37:59

switchディスってんのか

0997デフォルトの名無しさん

2010/11/10(水) 22:42:09

ここだけ中国語の部屋

0998デフォルトの名無しさん

2010/11/10(水) 22:42:20

オブジェクト指向という発想がNGって立場。
名前がNG。
オブジェクト指向って明確な定義もないし、実体も無いあやふやなもの。
でも、オブジェクト指向っていうからにはオブジェクトをフューチャーするんだろう。
だけど、オブジェクト、(物とか対象ってことなんだろうけど、)
そんなものに着眼してどうすんのと。
オブジェクト指向な考え方や、そういう考え方を好む人がNG。
そういう思考回路で作られた変てこ言語もまたNGだがね。

0999デフォルトの名無しさん

2010/11/10(水) 22:48:59

「最後に書いたやつが勝利」モードに入りましたか。

1000デフォルトの名無しさん

2010/11/10(水) 22:49:24

よしわかった！
もういいよ！

1001１００１

Over 1000Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

レス数が1000を超えています。これ以上書き込みはできません。