オブジェクト指向システムの設計 170

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 657 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:16:03.53 ID:PAgdOZpu.net] > Cはメモリリークがないと言っちゃうところとかからも。 動的にメモリ割り当てた経験がないんだろうなｗ 組み込み業界に新卒で入ってそのやり方しか知らんとかかな。 658 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:35:56.66 ID:nosfsWv3.net] >>628 コンテキストに状態を保持する、または状態を利用する場合以外はクラスメソッドでいいだろ 659 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:38:45.17 ID:PAgdOZpu.net] >>590 > Javaはオブジェクトを基本にしているからこそ、わざわざモックオブジェクトを定義してやって > 食わせてやらないと、簡単に構文エラーをはくだろ コンパイル言語で構文エラー？ 660 名前：デフォルトの名無しさん [2016/06/05(日) 19:41:52.40 ID:zc7alBMy.net] コンパイル時に構文エラーは出るんじゃね？ 661 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:45:31.80 ID:PAgdOZpu.net] C言語でも、ネットワーク通信が含まれた関数をテストしたいときに ネットワークを使わないでできるようにしたいならモック関数が必要になるし、 別にネットワーク通信してもいいっていうのなら、Javaでも モックオブジェクト使わずに、本物のオブジェクトを 使えばいいはずだけど？ なんか、なんのためにやるのか？を理解してない気がするね。 662 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:56:32.50 ID:fuiY39en.net] >>643 Cでグローバル変数（が増える）が嫌な理由は、 1.大域的にその変数にアクセスできることが嫌であること 2.グローバル変数のおかげでモジュールの分割が滞ること javaでクラス定義（が増える）のが嫌な理由は、 1.大域的にクラスをコンストラクトできるということが嫌であるということ 　事実、そのクラスに無関係なコンテクストでもコンストラクトできる 　そんなことはしないとキミは言うかも知れないが、それならCのグローバル変数だって大差ないね、俺もそんなことはしない 　これは事実上のパッケージ内でのグローバルオブジェクトだ 　そしてそうであるがために、必要以上に脳みそを使わざるを得ない 　このオブジェクトは、あのオブジェクトと関係がある、そしてそのオブジェクトとは関係がないってね 2.クラス定義のおかげで、パッケージ分割が滞ること クラスが増えるということはクラスの依存性そのものが増えるということだ、 もしクラスAがBにクラスBがCにクラスCがDに依存している場合、 そのパッケージはクラスA,B,C,Dを内包するものになるだろう。 そのう� 663 名前：ｿBはFやGに依存するようになり　DはV　W　X　Y　Zに依存するようになるだろう。 そうしてパッケージはモノリシックなものになっていくし、 事実オブジェクト指向ライブラリは俺の知る限り関数型のライブラリよりも一つ一つの粒度が大きい。 そしてそのライブラリの使い方を調べることほど面倒なことはない パッケージ分割されていないからこそ、オブジェクトの関係性や依存関係を整理することが苦痛で、複雑性が増す なぜこんなことになるのかというとオブジェクトがデータ・タイプとメソッド定義を混在させているからに他ならない もしオブジェクトがメソッドをもたないのであれば、オブジェクト同士の依存性やヒエラルキーは発生しない 俺も正直なぜデータタイプとメソッドを混在させておきながらSRPやDRYが達成できるのか理解できないのだよ [] [ここ壊れてます] 664 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:00:28.93 ID:PAgdOZpu.net] >>590 > これがもしFightという関数になったとき > Dog.Fight(Cat); > Cat.Fight(Dog); > Fight(Dog,Cat); > これでいいたいことはうっすらわかりましたかね？ 何も言いたいことがわかんねぇｗｗｗ 例えば、「戦士.戦う(スライム)」 だったら普通に武器で攻撃するだろうけど 「戦士.戦う（メタルスライム）」 だったら、聖水を使うかもしれない。 「魔法使い.戦う(フレイム)」なら弱点のヒャド系魔法使うかもしれないし、 「フレイム.戦う(魔法使い)」なら火炎の息を吐くかも知れないし。 自分が今どんな攻撃ができるかは、自分しか知らないだろ。 「戦う（魔法使い, フレイム)」 とか言われたって、 戦う関数は何すればいいか分かんねーよｗ 665 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:02:00.75 ID:nosfsWv3.net] C言語メインでやってたエンジニアが(たぶん)Javaでコード書けって言われて使ったライブラリがたまたま微妙なAPI設計で鬼の首取ったみたいに言われても、、、 オブジェクト指向って書いてある時にさしてるものがJavaのとあるライブラリだったり、Javaの言語仕様 (privateとか)だったり 666 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:05:43.86 ID:PAgdOZpu.net] >>650 > Cでグローバル変数（が増える）が嫌な理由は、 > 1.大域的にその変数にアクセスできることが嫌であること それ間違ってるから。アクセスと言っちゃうと読み書きの両方になってしまう。 グローバル変数がだめな理由は、大域的にその変数に「書き込み」ができるから。 読み込みだけならグローバルで構わん。っていうかOSから得られる様々な情報、 例えばプロセスIDとか空きメモリ量とかファイルとかC言語でも大域情報だらけだからなｗ ということで、Javaのクラス定義がグローバルにいくら増えようが、 クラス定義は読み込みなので、問題ないんだよ。 もちろん「どこからでもクラス変数が書き換えられる」のであれば それは（書込み可能な）グローバル変数と言っていいけど。 667 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:06:48.68 ID:eiIG0jy5.net] >>650 「javaでクラス定義の（が増える）が嫌な理由」って必要があるなら増えても問題ないから避ける必要はない。 あと、クラスを参照できる範囲は制御できるから他から使われたくないなら公開しなければいいだけ。 668 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:13:12.23 ID:fuiY39en.net] 俺は十分説明したと思う オブジェクト指向はCよりも遥かに複雑な依存関係を作り出せるし テストはしにくいし、よって論理エラーを補足しにくく、結合テストで悲鳴を上げる事になり、 メソッドとデータ・タイプが分離されていないおかげで、クラス構造の設計（という名のお絵かき）は大変になるわ、 デザインパターンとかいう言語仕様の欠陥の見本市に付き合わされるわ ToStringすらオーバーライドしないと使いものにならないし オブジェクトを主語としたおかげで汎用性はないし、 クラス・メソッド(関数)は用意されているもののおまけ程度で、関数型には程遠い使い勝手で 単純なことをするには必要以上に複雑で、複雑なことをするにはなおいっそう複雑で その主張がわかってくれればいいよ 結局Cが抱えていた問題を解決したといって、確かにその問題は解決できたのかもしれないが、 Cよりも規模の大きい、厄介な問題を引き連れていることに気が付かないようではな >>651 Fighter.Fight(Slime)� 669 名前：@→たたかう Fighter.Fight(metalSlime)　→聖水 まずこんな動作させたら、このメソッドを使うユーザープログラマが混乱するよね 百歩譲ってそれでいいとしよう、聖水を使うのは、ライブラリプログラマの配慮であり慈悲であると 問題はこれはオブジェクト指向の問題ではないってことだ この動作をオブジェクト指向で実現するなら、 FighterクラスのFightメソッドの中にif文をずらずらと並べて if(slime) {"slash"}else if (metalSlime) {"use holywalter"});とするしかない。 でもってmagicianクラスのFightメソッドには if(slime) {"Fire"} else if (Flame) {"Blizzard"} ... なぜならばオブジェクト指向言語はマルチメソッドという概念をサポートしていないからだ キミの指摘はオブジェクト指向がダメな部分を改めてあげつらっているに過ぎない ちなみに俺ならまずは2次元配列を使ってそれを実装することを考えるけどな [] [ここ壊れてます] 670 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:14:28.99 ID:D6e8xYJD.net] >>631 言いたいことは分かるが、現実的に多態は有用だ。 もちろんオブジェクト構文を用いずに無理矢理多態することは出来るが、 専用文法があるのならそれを用いた方が見やすいのは事実だ。 問題は「クラス作成」「継承」さえすればいいと思っている馬鹿が多いことだと思う。 これは関数型にも同様に言えて、こちらは「状態を持たない」「副作用がない」になる。 >>636 言いたいことは分かる。 > グローバル変数を無くすという意味合いではレキシカルスコープをサポートしていれば十分なのに 特にこれなんて本当にそう思うし、クラス階層がまともに作れないC++は仕様に欠陥があると思う。 ただ正直、レキシカルスコープはGC言語には似合うがスタック言語には似合わない。 だからC++のラムダはアレな仕様に「見た目は」なっている。 実際には確かに妥当な仕様なのだが、綺麗に便利に書こうって感じじゃない。 まあこれは脱線だが。 >>640 > Cよりも後発であるにも関わらず、より問題やシンタックスを複雑にしていて > それもコード上で解決する問題から、設計上に関わる問題へと進化させている ここについては俺の見解は少し異なる。 俺はタイプ量は気にしない。 型にしてもシンタックスにしても、それはコンパイル時点で静的にバグを落とすためだ。 静的に落とせるバグは全て静的に落とすべきだ。動的にテストで落とすよりも断然生産性が高い。 とはいえ、いちいちシンタックスがウザイのも事実だが、これは税金だと思っている。 671 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:20:00.92 ID:PAgdOZpu.net] > まずこんな動作させたら、このメソッドを使うユーザープログラマが混乱するよね え？なんで？ｗｗｗｗ 相手に最適な攻撃をするのは、当たり前の話だけど もちろん、相手（引数）の情報を知らないならば 有効そうな攻撃をするしか無いけどね。 同じ戦うでも、知性によってどういう攻撃をするかは変わる。 672 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:22:15.49 ID:PAgdOZpu.net] >>655 > この動作をオブジェクト指向で実現するなら、 > FighterクラスのFightメソッドの中にif文をずらずらと並べて > if(slime) {"slash"}else if (metalSlime) {"use holywalter"});とするしかない。 あれ？ でも、Fight（Fighter, Slime）とかだったら、 Fightメソッドにif文をずらずら並べないといけないだけだよね？ｗ 673 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:24:05.47 ID:DztPIEJ0.net] >>655 >マルチメソッド メソッドだけの静的なクラスも作れるからそこで多重定義したらいい 674 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:26:32.30 ID:PAgdOZpu.net] >>655 > なぜならばオブジェクト指向言語はマルチメソッドという概念をサポートしていないからだ ほとんどの手続き型もマルチメソッドという概念をサポートしていませんが？ https://ja.wikipedia.org/wiki/%E5%A4%9A%E9%87%8D%E3%83%87%E3%82%A3%E3%82%B9%E3%83%91%E3%83%83%E3%83%81#Common_Lisp > 汎用のマルチメソッド機能をサポートするプログラミング言語は次のとおりである。 > Common Lisp (Common Lisp Object System) > Dylan > Nice > Slate > Cecil > Perl6 > > 何らかの拡張でマルチメソッドをサポートする言語として、次のものがある。 > Scheme (TinyCLOS) > Python (gnosis.magic.multimethods) > Perl (Class:Multimethods) > Java (MultiJava) > Ruby (The Multiple Dispatch Library, Multimethod Package) この中で手続き型なのはどれだろう？ｗ 675 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:30:40.15 ID:fuiY39en.net] >>657 Fighter.OptimalAct()ってことね で、その知性をオブジェクト指向で表現するにはどうするのかってことだが、 例えばFighter.monsterknowlegde というプライベート変数で それぞれのモンスターに対する知識ハッシュテーブルを定義してやればキミのやりたいことは出来る。 さらに言えばmagicianにも同じ変数が必要だから これはBattleClassというクラスから継承するのがおおよそ正しいオブジェクト指向だと考えられる そしてそれがオブジェクト指向的に正しい解であると同時に、俺がやらない方法でも有る >>658 真面目にやればそうだろうね、マルチメソッドも結局はif文みたいなもんだし というよりディスパッチ自体が実質if文だからね まあ俺は、2次元の関数配列を書いて処理しますけどね オブジェクト指向に従うと、Fighterに対して一次元のハッシュテーブル、というふうにしないといけない さらには継承を使わないといけない もっとも、Fighterがwizのように何人も生成できて、キャラクター生成の度に、monsterknowledgeを初期化して生成する っていうのはいかにもオブジェクトらしいけどな まあ、結局2次元の配列で処理できるんですが 676 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:33:28.30 ID:PAgdOZpu.net] >>661 > オブジェクト指向に従うと、Fighterに対して一次元のハッシュテーブル、というふうにしないといけない > さらには継承を使わないといけない ↑ 言い方を変えるだけでこんなにネガティブな印象に！ ↓正しい言い方はこれ オブジェクト指向に従うと、Fighterに対して一次元のハッシュテーブルで十分である。 そして継承を使えばいいだけである。 677 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:37:34.37 ID:PAgdOZpu.net] 結局のところC言語で手動でオレオレマルチメソッドを実装するって話なら オブジェクト指向言語でも、手動でオレオレマルチメソッドを実装すればいいし、 言語仕様に組み込まれた、本物のマルチメソッドが使いたいならば C言語では不可能で、本物のマルチメソッドが組み込まれた言語 （もちろんオブジェクト指向言語にもそれは存在する）を使えばいいだけ。 ID:fuiY39en の話を読めばわかるが、結局こいつは Javaだけが唯一のオブジェクト指向言語だと勘違いしているのだ。 678 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:38:16.94 ID:MVcwnGuc.net] オブジェクト指向を批判しようとしてjavaの批判になっちゃうのはよくある 679 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:38:30.72 ID:eiIG0jy5.net] >>655 Fighterだのなんだの空想の世界で語ってるせいでよく分からんが違うクラスのオブジェクトに対して 異なる処理をしたいこともあるんだし、したければすればいいだけ。 同じ処理でいいなら分ける必要はない。 その部分の動作は切り分けたいならvisitorパターンを使えばいい。 680 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:39:35.10 ID:fuiY39en.net] Fight()なら Fighter F Magician M Slime S Flame F MetalSlime MS として OptimalActsという関数テーブルを用意して 　　　　　F 　　　　　　M S　　　 Slash() Fire() F Slash() Blizzard() MS Use(holywater) Use(holywater) その通りに呼び出せばよいし、OptimalActsをとるかどうかは、MonsterKnowledgeで制御すればいい MonsterKnowledgeはmutableでなければならないし、OptimalActsはimmutableでもよい。 >>663 俺の指摘は、この問題を特にあたってJavaがCよりも有利な解決策を持ってないってことを示しているだけなんだけど よくRPGを使ってオブジェクト指向を例示する本があるけどさ、あれって無意味だと思うんだよね こういうちょっとでも問題が複雑になるとJavaはあまりにも無力だろ 681 名前：デフォルトの名無しさん [2016/06/05(日) 20:43:13.69 ID:MVcwnGuc.net] >>590 >オブジェクトという副作用の塊で immutableにすればいいのでは >>636 scalaだったら private[packege名]とやれば特定のpackageだけでさわれるprivateが指定できるので 単体テストだったら全然できる 682 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:44:16.06 ID:PAgdOZpu.net] >>590で > WalkのコンテクストではDogを主語として扱うことに意味はあるのかもしれない。 > しかしFightのコンテクストではDogあるいはCatを主語として扱うことに対する深い意味はないだろう。 こんなこと言ったのに、↓主語として扱う意味を見つけてしまったなぁｗ > もっとも、Fighterがwizのように何人も生成できて、キャラクター生成の度に、monsterknowledgeを初期化して生成する > っていうのはいかにもオブジェクトらしいけどな 結局オブジェクト指向としての設計の話をするならば、これのほうが正しいんだよ。 > Dog.Fight(Cat); > Cat.Fight(Dog); ただし設計とは別の観点、つまり「メンテナンス性のために戦うアルゴリズムだけを分離したい」となれば、 それは、アルゴリズムだけを収録したクラスを作って（あれ？将棋でも同じ話しなかったっけ？ｗ） それを入れ替えられるようにすればいい。それは上記の設計を変えずにできる。 設計は正しいままで、アルゴリズムを呼び出すようにする。 683 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:45:33.12 ID:8zGv30iU.net] すげーな39yenさん こういう問題をちゃんと文章にできるって羨ましいぜ 俺はその時々で舌打ちして終わり そして抱えたイライラは明日には忘れる 684 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:45:58.77 ID:MVcwnGuc.net] Visitorパターンはパターンマッチができる言語だったら パターンマッチで対処したほうがいいね 685 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:46:25.11 ID:PAgdOZpu.net] >>666 > こういうちょっとでも問題が複雑になるとJavaはあまりにも無力だろ 無力って言う割に、自力で解決できる簡単な方法を あなた自身が提示しましたが？ｗ 686 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:46:45.55 ID:fuiY39en.net] Javaを使ってRPGを記述しようとしても一切体系的に記述できないし、 2次元の関数テーブルのほうが、明らかにデータの凝集度としても上なんだよなあ オブジェクト指向の教義を信じて それぞれの役割に応じて最適行動を散らばらせても待ってるのは悲劇だけだから 例えばだけど、Flameに対する各役割の最適行動はなんですかという疑問を持ったとしよう。 オブジェクト指向だと、それぞれの役割に対して、いちいち聞いて回らないといけなくなるよね Fighter.OptimalAct() Magician.OptimalAct() Thief ・・・ ここで、BattleClassの必要性は確定しちゃうよね Foreachでぶん回すことを考えると、各職業を集約してまとめあげるようなスーパークラスあるいはインターフェースが必要になる もちろん我々はそんなことをしなくてもFの行を横に見ていくだけでわかるのにね 687 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:47:40.30 ID:PAgdOZpu.net] >>672 反論を無視して同じことを繰り返し言っても無駄ｗ 688 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:48:46.91 ID:PAgdOZpu.net] >>672 えとな、オブジェクト指向言語っていうのは 手続き型を踏まえてできたものなので、 手続き型でやれることは、オブジェクト指向言語でもできるんだよ。 689 名前：デフォルトの名無しさん [2016/06/05(日) 20:49:39.90 ID:MVcwnGuc.net] ID:fuiY39enはjavaは糞って言えば良かったんじゃないの それなら俺は同意する 690 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:50:05.15 ID:eiIG0jy5.net] >>670 どゆこと？ 691 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:51:06.18 ID:PAgdOZpu.net] マルチメソッドをサポートしたオブジェクト指向言語を使えば 問題解決ってことだよなぁ（笑） 692 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:52:11.61 ID:D6e8xYJD.net] >>655 > メソッドとデータ・タイプが分離されていないおかげ 元々はそこをくっつけてカプセル化しようという思想だからな。 だから形式的にはデータタイプは全て独自で、当然メソッドも全て独自ってわけだ。 現実的にはInt64もDateも同じだったりして、結果、addメソッドも同じバイナリで問題ないわけだが、 それでも Int64.add と Date.add の区別を付けるのは、俺は「税金」だと思っている。 >>666 Cはポインタポインタって言われるけど、真の実力は実は関数ポインタにあるんだろ。 関数ポインタを使いやすく、また色々文法的チェック機構を付けまくったら、オブジェクトとメソッドになるわけで。 生ポインタ使える奴がGC言語はゴミと言うようなもので、 生関数ポインタを使える奴がオブジェクト指向はゴミというのは、当たってはいるがそれ言っちゃ議論はおしまいだ。 693 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:53:12.42 ID:8zGv30iU.net] もうオブジェクト指向やめようぜ 構成図書いてデータフロー図書いて入出力表書いてシーケンス図書いて状態遷移図書いて画面遷移図書いてデータテーブル図書いて処理フロー書いて 作る従来の開発に戻ろうぜ 絶対そのほうがすんなり終わるよ クラス設計は悪夢だよ 694 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:57:11.65 ID:fuiY39en.net] >>668 オブジェクト指向らしいとはいったけど別に必須じゃないんだよな 新しいキャラクターを創設したいなら、そのキャラクターに対する行を追加すればいいだけだから 普通に関数と構造体(レコード)で処理できる 単にデータ・タイピングの問題なので >>671 Javaが第一級関数をサポートしてればよかったのにな 少なくとも継承、カプセル化、ポリモーフィズムはこういう問題の解決には無力だぞ 695 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:59:20.68 ID:nosfsWv3.net] >>672 ただ単に関数ポインタがJavaには無いって言えばいいじゃん それってCはヘッダとソースの二つに記載するから面倒臭いみたいなレベルの話でオブジェクト指向とか関係無いよね 696 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:59:47.89 ID:MVcwnGuc.net] >>676 Visitorパターンは構文木を扱う処理にとかにたいしてよく使われるけど パターンなんか使わなくて言語組み込みのパターンマッチ使えば簡単に書ける 697 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 20:59:52.24 ID:fuiY39en.net] >>678 俺は別にC使いじゃないからな Cに比べてオブジェクト指向は優れているという割には オブジェクト指向は多くの問題を引き連れていませんか？という当て馬として使ってる 最低限のシンタックスとセマンティクスは知ってるつもりだけど 698 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:02:36.26 ID:eiIG0jy5.net] >>682 パターンマッチングに限定されないから。 699 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:05:03.17 ID:MVcwnGuc.net] >>683 c VS OOP にするよりは 構造化プログラミング VS OOP にしたほうがいいのでは 言語比較なら c VS Rustとかにしちゃうぞ 700 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:05:28.23 ID:eiIG0jy5.net] >>683 ご満悦のようだが、俺の書き込みはスルーしてるじゃん。 メモリリークとか、クラスの参照範囲とか、指摘されて困っちゃったのかもしれないけど 何が問題だといいたいのか分からないからちゃんと説明してくれ。 モンスター云々だと分からないから理解できる例にしてくれ。 RPGだったら攻撃方法を選択するのはプレイヤーだろ。 何がしたいんだか分からん。 701 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:10:15.04 ID:MVcwnGuc.net] >>684 まぁGofの中でも結構批判される事が多いパターンじゃん？ 構造のあるものを再帰的に辿る以外に使う事ってそんなにあるかなこのパターン 702 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:12:04.61 ID:eiIG0jy5.net] >>687 基本はそうだろうけど、それがパターンマッチングに限定されない。 703 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:13:24.24 ID:MVcwnGuc.net] ググッたら 小田好教授も扱いにくいからパターンマッチング代わりに使え って言ってて吹いた 704 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:14:39.32 ID:fuiY39en.net] >>686 モンスターの例は勝手に誰かが出題したのに答えただけなんだが メモリーリークに関してはそして「オブジェクト指向言語である」C++に比べて Cはメモリーリークしうる要素が少なすぎるんだが？ javaがメモリーリークしにくいのはガベコレを積んでるだけであってオブジェクト指向言語の長所ではないよな あと下手な実装してたら、メモリーリークに対して一切手をだすことができないのも先述の通り クラスのスコープについてもCより改善されている部分なんてないだろ？ アクセス修飾子は、レキシカルスコープがあれば不要であることは指摘した。 さらにアクセス修飾子がテスタビリティを損ねていることも指摘した。もう終わったことなんだけど 705 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:16:03.72 ID:eiIG0jy5.net] >>689 ○○が言ってるって言うのはいい加減にしろｗ 706 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:16:54.20 ID:fuiY39en.net] 例えば、debug時にのみpublicにして、release時にはprivateにするといった アクセス修飾子はjavaには定義されてないよね IDEやライブラリによってはそういうのをサポートしてるのもたぶんあるだろうけどね 全てがprivateってあまりにもテストやりにくいんだけど、そのことわかってんのかな 707 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:19:08.52 ID:eiIG0jy5.net] >>690 Cとメモリリークは常に一緒なんだが…。常識を知らない相手と話すのは…。 >>654に対する反論になってねえし。 708 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:20:50.73 ID:fuiY39en.net] >>693 クラスは増えても問題無いって言うけど クラスを作るか作らないかってのもオブジェクト指向設計の一つのキモでありよく議論の対象になる部分だろ アクセス性については散々言ってる通り、アクセス性を決めるのはスコープで事足りている 過剰なprivateはテストの邪魔にしかならない 709 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:21:38.26 ID:bBqsqHAQ.net] ゲームの話してはダメ ゲームの話は荒れる ゲームはOOPが向いているようで向いてない場面も多々ある ゲームは普通のアプリとは違う 相互作用が余りにも多すぎる しかも相互作用の相手が固定でない 「当たり判定のあった者同士」が出合頭に相互作用を始めるカオス OOPはここまでのものは想定していない 普通のアプリでは当たり判定なんてものは精々マウスカーソルぐらい ゲームは違う、もれなく当たり判定があると言ってよい ぶつかった瞬間に互いに相互作用が開始する だからゲームは相互作用を上手に記述するためにみんな工夫して書いている 工夫の仕方は色々 OOPの一部の機能を利用して工夫している人もいれば 全く諦めて、別の方法で工夫している人もいる だから荒れる 710 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:22:56.36 ID:eiIG0jy5.net] >>694 「クラスは隠れたグローバル変数だ」っていう謎主張は撤回したってことな？ ちゃんと段階追って話そうな。 711 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:27:11.77 ID:fuiY39en.net] >>696 アクセス性を制御できることがキミにとってその解決になるのか？ publicをinternalにしたところで、パッケージがモノリシックなら、何の意味もなく そのパッケージ内でグローバル変数と同様に振る舞うということはわかるよね？ キミはpackageAからpackage Bの Class bが見えなくなれば、複雑性は解消されたと考えるのか？ bの中にClassが50個ほど並んでいても同じことが言えるのかな？ 712 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:27:38.14 ID:bBqsqHAQ.net] 普通のアプリは相互作用の相手が大体決まっている メンバに参照を持っているか、引数で渡すか、シングルトンかは知らないが 相互作用の相手は大体決まっている ロジックがそうさせる ゲームの場合は当たり判定があると相互作用が発生する ありとあらゆるものの間で相互作用の可能性がある だからみんな工夫して書く 工夫の仕方は色々 だから荒れるし、答えはない 713 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:29:38.59 ID:eiIG0jy5.net] >>697 パッケージがモノリシックってどういう意味？ 714 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:32:00.11 ID:fuiY39en.net] >>699 「モノリシック」は一枚板という意味で、ソフトウェア的には、全体が1つのモジュールでできていて、分割されていないことを意味する。 715 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:32:58.93 ID:MVcwnGuc.net] >>691 あ　いややっぱscalaの作者だからそう言うよなと思って面白かっただけ scalacはscalaで書かれてるからscalaのパースにはパターンマッチで十分なんだよな 716 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:34:25.03 ID:eiIG0jy5.net] >>700 クラスに分割するのはそれを解消するためだから パッケージがモノリシックってどういう意味か分からない。 設計がおかしいだけでは？ 717 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:36:18.20 ID:PAgdOZpu.net] >>697 > キミはpackageAからpackage Bの Class bが見えなくなれば、複雑性は解消されたと考えるのか？ > bの中にClassが50個ほど並んでいても同じことが言えるのかな？ 誰にとっての複雑性か？を考える必要がある。 package Aからpackage BのClass bが見えなくなれば、 package Aの複雑性は解消されたといえる。 一方package Bの複雑性は解消されていない。 これじゃ複雑性は解消されなてない。 見えない所まで全部見て考えるんだ！というならば、 関数の中、そしてOSのAPIまで見て考えるのか？という話。 複雑性を解消するための方法は、モジュールを小さく分けて 内部を見なくていい状態を作り上げていくことだ。 お前だって普通に開発してるときに汎用関数の中のコードまで読まないだろ？ そこにどんなに複雑なソート処理が実装されていたとしてもだ。 718 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:37:57.85 ID:MVcwnGuc.net] >>692 javaのmockライブラリによってprivateをmockにできるっぽいよ 使ったことないけど 719 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:38:38.28 ID:eiIG0jy5.net] パッケージがモノリシックという前提にしている時点で 設計が悪いオブジェクト指向システムを前提にしている。 そんなシステムに問題があるのは当然。 そんなものを批判しても意味ねえよｗ 720 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:44:33.59 ID:eiIG0jy5.net] ID:fuiY39enは知識も不十分な上に、背伸びした言葉を使い過ぎてるから議論する価値がないと判断する。 そんな半端な知識で 721 名前：批判するのはバカっぽいからもう少し勉強してから出直して来い。 んじゃ。 [] [ここ壊れてます] 722 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:49:17.07 ID:fuiY39en.net] >>703 複雑性を解消するための方法は、モジュールを小さく分けて 内部を見なくていい状態を作り上げていくことだ。 お前だって普通に開発してるときに汎用関数の中のコードまで読まないだろ？ そこにどんなに複雑なソート処理が実装されていたとしてもだ。 もちろんそれが理想だ、 そしてそれを実現する唯一の方法は、オブジェクト指向を捨てることだ コードを読まずにすむためには、結果が引数によってのみ確定し副作用を持たないということ つまり純粋関数であるということが、真の意味でのカプセル化だということだ オブジェクトは状態を内包している、だからこそのオブジェクト指向であり そうでないならば、staticオブジェクトで表現しても支障は起きない プログラマの仕事とは究極的に言えば状態を管理することにある それを隠蔽するような言語では、話にならないことぐらいわかると思うんだが 723 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:51:38.09 ID:fuiY39en.net] データ構造を隠蔽してメソッドだけを公開するということが どれだけオブジェクト内の動きをプログラマが把握することに手を焼かせられることなのか理解してからきてくださいね .net Frameworkの図体のでかさを見てから モノリシックなライブラリは設計が悪いと言ってくださいね 724 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:55:42.18 ID:D6e8xYJD.net] >>683 > オブジェクト指向は多くの問題を引き連れていませんか？という当て馬として使ってる まあこれはその通りなんだが、俺は元凶はアホが設計やることだと思っている。 例えばGC言語、本来は「煩雑なリソース管理に脳内リソースを割かれるよりは、 自動化できるところは自動化し、本来プログラミングすべき部分に注力する」なのだが、 実際は「リソース管理できない馬鹿でもGC言語ならプログラミングできます」という逆方向に使われている。 オブジェクト指向も「なければできません」の奴が使うから駄目なのであって、 「なくても出来ますが、今回はオブジェクト指向が適切なのでこれを選択します」である限り大丈夫だと思う。 >>690 > クラスのスコープについてもCより改善されている部分なんてないだろ？ 一応、Javaはクラス階層を自由に作成でき、親を ParentClass.this で参照できる。 だから手動レキシカルスコープみたいなことは出来る。 (ただし俺はJava使いではないので間違っているかも。なおC++はこれができない) 725 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:56:10.82 ID:PAgdOZpu.net] >>707 > つまり純粋関数であるということが、真の意味でのカプセル化だということだ C言語などの手続き型言語ではだめだって話に持っていくんだね わかったよｗ 726 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:57:10.61 ID:PAgdOZpu.net] >>708 > データ構造を隠蔽してメソッドだけを公開するということが > どれだけオブジェクト内の動きをプログラマが把握することに手を焼かせられることなのか理解してからきてくださいね データ構造を公開するメソッドを作ればいいだけでは？？？ 727 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:58:06.65 ID:fuiY39en.net] ?設計が悪いオブジェクト指向システムを前提にしている。 ○オブジェクト指向システムは設計が悪い、だってオブジェクト指向は設計者を手助けしてくれないから 　だからできの悪いライブラリが止まらず、間違った設計思想を信じるにわか設計者が後を絶たない だってどこをprivateにしてどこをpublicにして、どんなインターフェースを定義してというふうに それこそまともなスコープ制御を持った言語や、動的言語なら一切気にすることがない部分を いつまで経ってもちまちま考えさせられているから 最後の極めつけは、「僕はデザインパターンも勉強したし、オブジェクト指向設計も勉強したのだから 　　　　　　　　　　これが役に立たないはずがない、だって僕はこれに何年も時間を使ってしまった」という元を取りたがる考え方だ 俺がおすすめするオブジェクト指向設計の本はエリック・エヴァンスのドメイン駆動設計、これだけ これは他の言語に映っても使える示唆がある あとSOLID原則ってあるとおもうけど、あれ関数型のほうがよほど簡単に実現できるから ボブおじさんはその点でセンスはいいんだろうなって思うけど、それをオブジェクト指向でやろうとしたことが最高にセンスないよな 728 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 21:58:51.73 ID:PAgdOZpu.net] さっきも言わなかったっけ？ > だってどこをprivateにしてどこをpublicにして、どんなインターフェースを定義してというふうに > それこそまともなスコープ制御を持った言語や、動的言語なら一切気にすることがない部分を Javaだけがオブジェクト指向言語だって思ってるでしょ？ Rubyは動的言語かつオブジェクト指向だ。 729 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:02:56.64 ID:D6e8xYJD.net] >>707 > コードを読まずにすむためには、結果が引数によってのみ確定し副作用を持たないということ おっと？ということは君は関数型支持派か？ なお言っていることには同意。 >>708 > .net Frameworkの図体のでかさを見てから あれは切り出しなんて考えられてないからね。 それが組み込み系なら問題になるけど、PCなら結局の所DLL扱いだから1個ロードして終わり。 現実的には大して問題にならない。 730 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:06:12.78 ID:PAgdOZpu.net] オブジェクト指向を否定して関数型言語がいいと言って、 関数型言語なら俺はもっと素晴らしい物を開発できる！って 考えている人が滑稽なのは、 言語によって生産性に差が生まれるって考えてることなんだよね。 たしかに言語によってある程度の差はある。 だけど、それは些細な差でしか無い。 重要なのは、ライブラリの多さやフレームワークの機能なんだよ。 Railsは大きな生産性向上を果たすことに成功したが、Rubyだけでは不可能だった。 Railsというフレームワークによって生産性は大きく向上した。 残念ながら、言語による差なんて些細な事でしか無いんだよ。 フレームワークを自作するっていうのなら、また話は変わってくるが、 今は他人が作ったものを利用して開発をする時代。 MITがSICPを教えなくなった理由 cpplover.blogspot.jp/2016/05/mitsicp.html > > 今日では、状況が変わっている。 > > ソフトウェアでも状況は同じだ。プログラミング環境は、多大な機能を提供する > 巨大なライブラリ群の集合として存在している。 > > Sussmanの今日の生徒は、その時間の大半を、ライブラリのマニュアルを読み、 > どのように組み合わせれば目的が達成できるのかを把握することに費やしている。 731 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:06:24.35 ID:fuiY39en.net] rubyをオブジェクト指向言語として使ってる奴なんているの？ それをいったらpythonもオブジェクト指向言語だしJSもオブジェクト指向言語なんだけど さらにいえばScalaもそうだよな さらに言えばCommonLispですらCLOSがあるからオブジェクト指向言語なんだけど あんまり詳しくないけどCLOSのほうがJavaより出来がよさそうなのがマジで笑えるんだけど ゲッタやセッタ書かなくても確か自動生成されるんだろ 732 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:09:00.85 ID:PAgdOZpu.net] >>716 オブジェクト指向に決まってるだろ。 何言ってんだ？ Railsでモデルを作るときとか 継承しまくりだ 733 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:13:25.73 ID:fuiY39en.net] >>715 そうだね、ライブラリが利用しやすい言語ならライブラリを使ったほうがいいよね でも俺がオブジェクト指向を批判する理由は、このスレでとっくに書いているんだよね ライブラリが自分が想定している挙動と異なった場合、自分で手直しすることが不可能 俺はそこまでハッカーじゃないからね レゴのブロックのように構築できるライブラリもあれば、そうでないライブラリもあるわけで ライブラリ製作者が定義したオブジェクトまみれのライブラリより 純粋関数からなるライブラリのほうがまだマシなんだよ、関数なら相互作用性が引数と戻り値のみに制限されるからね マクロとかになると読むのが多少は厄介になるけど rubyがrailsの助けを受けたとあるが、railsがrubyを選択したのは楽にかけるからということだろう 短く書けない言語というのは、結局のところ読むのも大変でライブラリから吸収できる量というのも少なくなってしまう javaでrailsが生まれなかったのは、まあそういうことなんだろうな ライブラリを使う能力も重要だが、ライブラリのスキマを縫うグルーコードをかく技術、かけるパラダイムかってのが 全てに関わってくる 734 名前：デフォルトの名無しさん [2016/06/05(日) 22:14:05.59 ID:zc7alBMy.net] Rubyはオブジェクト指向だろ さもなきゃまつもとゆきひろはアホだろ 735 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:15:03.77 ID:fuiY39en.net] え？rubyはlispのパクリだって聞いてるけど？ 736 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:15:11.70 ID:PAgdOZpu.net] Ruby ・・・ Rails Python ・・・ Django JS ・・・ React、Express Scala ・・・ Play Framework ここらへんがよく使われている有名なフレームワークだな これらがオブジェクト指向ではないというのなら、 その根拠を提示せよ 737 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:15:59.00 ID:PAgdOZpu.net] >>718 > ライブラリが自分が想定している挙動と異なった場合、自分で手直しすることが不可能 > 俺はそこまでハッカーじゃないからね なんでだよｗ ソースコード修正すればいいだけだろ。 Rubyとかならモンキーパッチとかもできるし。 なんで不可能なんだ？ 738 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:18:11.36 ID:PAgdOZpu.net] >>720 > え？rubyはlispのパクリだって聞いてるけど？ lispはオブジェクト指向だよｗ 739 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:20:42.82 ID:PAgdOZpu.net] >>718 > rubyがrailsの助けを受けたとあるが、railsがrubyを選択したのは楽にかけるからということだろう この理屈から言えば、 railsがオブジェクト指向を採用したのは、楽に書けるからということだろうｗ 740 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 22:25:19.97 ID:qNlMN7jN.net] まあほにゃらら指向がどうたらってことばかり言ってないで テメーの仕事しろやって思う事はあるな。 そういう馬鹿に限ってテストさぼろうとするから。 741 名前：デフォルトの名無しさん [2016/06/05(日) 22:54:02.29 ID:/bruxSbe.net] >>725 コーダがテスタやるの？ 742 名前：デフォルトの名無しさん [2016/06/05(日) 22:55:58.82 ID:zc7alBMy.net] テストコードの事やろ 743 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 23:18:16.29 ID:D6e8xYJD.net] >>718 それについては既に指摘したけど、 A. ライブラリが完璧に動くか、 B. オープンソース であれば解決するから、オブジェクト指向の問題ではないと思う。 ただまあ、オブジェクト指向出身の奴が既に言われているように「隠蔽」を勘違いしていて、 そういうことになりがちなのかどうかは、俺には分からない。 > 純粋関数からなるライブラリのほうがまだマシなんだよ、関数なら相互作用性が引数と戻り値のみに制限されるからね これはその通りなんだが、どのみちオープンソースじゃないとやりにくいとは思うけど。 内部状態を持っているから、外面から見ると意味不明（脈略不明)な所でバグる危険性を言っている？ さすがにそんなライブラリは捨てるしかないと思うが。 みんなが使っている案牌しか使わないとかで対応するしかない。 ただ確かに、純粋関数のみのライブラリなら、 最悪辿っていって「ライブラリへの入力OK/出力NG」でそれが原因だと断定できる。 内部状態に依る場合、以前のどこかでおかしくなったということだから、ソースがないとどうやっても追い切れないね。 744 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 23:34:46.41 ID:MVcwnGuc.net] >>716 Scalaは作った人がオブジェクト指向と関数型の統合を目指した言語なのでオブジェクト指向 プリミティブや関数もオブジェクトなのでjavaよりもよりオブジェクト指向だと言える Rubyはまつもとゆきひろ自身が純粋なオブジェクト指向であると語ってるよ 745 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 23:41:50.70 ID:L71HvcLp.net] ねえねえ C#も仲間に入れてあげてよ 746 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:04:09.69 ID:UaKeA7lT.net] お前ら、相変わらず日本語が出来ないみたいだが、>>716が言っているのは、 > rubyをオブジェクト指向言語として使ってる奴なんているの？ (>>716) > として > javaでrailsが生まれなかったのは、まあそういうことなんだろうな (>>718) > Javaが第一級関数をサポートしてればよかったのにな (>>680) 制御機構の中心に何を据えているかを言っているんだよ。 第一級関数/高階関数を中心に据えているのなら、それは関数型的、 継承、カプセル化、ポリモーフィズムを中心に据えているのなら、それはオブジェクト指向的、 直接データに手を突っ込んであれこれするのなら、それは手続き型的、となる。 Rubyで書いてあればオブジェクト指向(ｷﾘｯとか言っちゃうような馬鹿では駄目なんだ。 それぞれの言語は基本的に既存言語のいいとこ取りをしているのであって、スタイルは選べる。 実用言語の中ではJavaだけがある意味「純粋オブジェクト指向」なんだよ。 そしてRubyで書かれている物もほとんどは関数型的じゃないか？という問いなんだ。 オブジェクト指向が中心であるなら、RailsはJava生まれるのが自然で、 逆に言えば、RailｓがJavaに見向きもしなかったのは、 Java（純粋オブジェクト指向）では駄目だったからだと言っているんだよ。 俺はこの見方（推測の仕方）は妥当だと思う。実際どうなのかは知らん。 747 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:14:54.26 ID:Tzc6nBCT.net] お前ら盛り上がり過ぎだろｗ 748 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:17:10.11 ID:Tzc6nBCT.net] >>731 しかしprimitivesがオブジェクトじゃないJavaは純粋オブジェクト指向だろうか？ 749 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:18:46.89 ID:s7mmSCjU.net] >>692 一応言っておくとJavaのアクセス修飾子は4種類ある public : 制限なし 修飾子なし : パッケージ無いのみアクセス可 protected : 自身及びサブクラスのみアクセス可 private : 自身のみアクセス可 でprivateがテストし辛いってのはリフレクションを知らないって事なの？それともリフレクションを利用しやすいようにしたライブラリの存在を知らないって事なの？ 750 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:19:11.11 ID:okPwaxJe.net] 純粋なオブジェクト指向なんか誰も必要としていない プリミティブ型はオブジェクトじゃなくて結構 751 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:25:24.78 ID:N6ydBJjg.net] >第一級関数/高階関数を中心に据えているのなら、それは関数型的、 イミフだわ　そんなの唯のオレオレ定義じゃん　一般的な定義から外れたオレオレ定義でいきなり語られてもこまる 第一プリミティブ型がオブジェクトじゃないjavaがどう「純粋オブジェクト指向」なんだ mutable objectを使いまくる(文字列からしてmutable)rubyが関数型とは笑止千万 752 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:28:47.72 ID:N6ydBJjg.net] >>735 プリミティブ型にメソッドはやせるのは結構便利だし 後　組み込みの演算子というのがなく演算子がメソッドなのは便利 753 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:36:09.08 ID:okPwaxJe.net] 俺が言ってるのは、プリミティブ型に仮想関数はいらないという事 メソッド生やしたりは記述の問題だけなのでどうでもよい 1+1も1.sum(1)もsum(1,1)も記述の問題だけで同じこと オブジェクトというからには仮想関数が欲しい しかしプリミティブ型に仮想関数はいらない むしろ、あると邪魔 754 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:43:28.32 ID:N6ydBJjg.net] rubyみたいなスクリプト言語なら仮想関数だろうがどうでもいいと思うし scalaだったら実行時のオーバーヘッドを無くす仕組みが備わっている 755 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 00:55:14.53 ID:okPwaxJe.net] もしプリミティブ型をオブジェクトのように扱いたいなら オブジェクト自体にvtableを持たせるという、大体のOOPの実装を変えなければならない まず、多態するときはポインタか参照を使って間接的に行うのが普通 さもなければスライジングが起こって大変なことになる ならば、オブジェクトにvtableを持たせるのではなく ポインタや参照がvtableを保持すればよい なぜなら、どうせ仮想関数はポインタか参照越しにしか呼ばないから そうすれば、intとか、Cの構造体とか、本来vtableを持ってないものを多態させることができる vtableを保持したポインタ越しにね 実際、C++のshared_ptrは似たような状態になっている shared_ptrは、仮想関数を持たない、言い換えればvtableを持たないオブジェクトが突っ込まれることもある その状態で、shared_ptrをアップキャストすると、本来のデストラクタを見失う ベースクラスのデストラクタしか見えなくなる このまま参照カウンタが0になって解放されると・・・ それじゃ困るので、shared_ptrは参照カウンタと一緒に本来のデストラクタを保持している 756 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:08:03.93 ID:N6ydBJjg.net] scalaはコンパイル前はプリミティブは完全にクラス ＆ 多態を使いたいなら静的ディスパッチ+マクロでzero-overhead だな 757 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:19:29.38 ID:pfL89vbp.net] いや39yenさんすげぇわ まあ、ここまで文章で表現できなくても 「なんかオブジェクト指向で設計しない方が問題起きなくね?」 ってのは常々思ってたけどね オブジェクト指向って利点ないんだよなぁ って言うと人格攻撃始めるしね（笑）

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef