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

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 623 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:11:09.44 ID:D6e8xYJD.net] ついでに言っておくと、俺は ID:n7HRsF8B についてもほぼ完全に同意だ。 異なるのは、俺は>>449にも完全に同意である点と、 リファクタリングはもう少し種類があってもいいだろ、という点だ。 624 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:16:20.94 ID:6ih2a7FC.net] こういう触ってほしくないところまでいじくり倒すバカがいるからこそのカプセル化なんだろうな ありがたみがよくわかるよ SOLID知らないバカと一緒に仕事をする事になったらアクセスを禁止して身を守るしかない ありがたみがよくわかるよ 625 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:19:19.30 ID:MVcwnGuc.net] >>601 もしそのライブラリが「理想的な」オブジェクト指向なら listという実装に依存していないインターフェースを公開するだろう オブジェクト指向だと継承よりもインターフェースについてプログラミングしたほうがいいので 626 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:23:32.02 ID:MVcwnGuc.net] 多重継承は禁止してmix-inはできるようにすればいいんじゃないかな 個人的にはscalaのコレクションなんかはいいOOの設計だと思う 利用者から見るとimmutableなんだけど 実装はmutableになっていてprivateでmutableな状態を隠してる 627 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:38:02.40 ID:D6e8xYJD.net] で、俺なりに何故1の>>1みたいな池沼に限ってOOPにすがるのかな？ということを考えてみたんだが、 「形」があるからじゃないかなと。 センスがない奴はいざ仕様を出されて「設計」しろと言われても、何をやっていいか分からない。 もちろん「設計」の中にはOOPならクラス分けもあるのだが、それ以前に、 例えばC++なら「手続き型」等も選べるのだが、それをどう選んでいいかも分からない。 その点、OOPならクラス分けしたら「設計」した気分になれるし、「継承」しておけば正しくOOPした気分になれる。 だから考えられない池沼にはOOPは割とフィットすると思うんだよ。 ただこれは、局所的な最適化でしかない。 例えば、熟練したプログラマは10,000行のコードまでは苦もなく扱えるというのが通説だが、 このとき、10,000行のスコープで最適化が行われる。 OOP信者はこの例でいうなら1,000-3,000行のスコープでの最適化しかしておらず、 その上の「手続き型」「関数型」等の階層での最適化が出来てない。 だからその上の最適化が出来る連中からは、異常にOOPにこだわる奴は馬鹿に見える。 もちろんOOPにも利点があるので使われているわけだが、初めからOOPありきとなるべきではない。 とはいえ、OOPの問題点だと言われているのは、 「正しくOOPできてない」事による物が多々紛れ込んでいるのも事実だと思うが。 628 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 16:58:11.35 ID:IqB6Pujt.net] 並程度の能力だと正しくOOP出来ないのがOOPの問題点 629 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:23:51.46 ID:nosfsWv3.net] >>581 オブジェクト指向言語にありがちな仕様なだけでオブジェクト指向って書き出しは少し強引では 630 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:24:03.06 ID:eiIG0jy5.net] >>601 え？Cプログラムでメモリリークがないと思ってんの？ 631 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:26:50.20 ID:eiIG0jy5.net] >>605 Cにもプライベート変数はあるんだが…。 不正確な記述が多くて主張したいことが分からない。 632 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:30:45.60 ID:eiIG0jy5.net] >>605 グローバル変数の利用まで推奨しちゃってんの？ 俺の知ってるCではグローバル変数の利用は控えるべきってのが常識なんだが グローバル変数を積極的に推奨するって異常だな。 633 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:34:05.48 ID:D6e8xYJD.net] >>615 > 多重継承は禁止してmix-inはできるようにすればいいんじゃないかな mix-inでもいいのは確かなんだけど、そもそも禁止する意図は何なんだ？ wikiの1-4なら、つまり「設計」が悪い。で終わってしまう。 > https://ja.wikipedia.org/wiki/%E7%B6%99%E6%89%BF_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) private/publicみたいに、結合度を「文法的に」確定させようということなのか？ (文法的に継承しにくい構造にして、オブジェクト間の粗結合化を促進する、つまり洗脳的） 俺としては、そこに書いてあるように、 「直感的」に書けない場合がある＝良い設計が見えているのに記述できない方が問題だと思うのだが。 634 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:35:20.84 ID:nosfsWv3.net] >>590 コンテキストが必要の無い場面はクラスメソッドになるのが当然で、それをオブジェクト指向を殺しているなんて誰も思っていない。 話が極端で盲目的過ぎ 635 名前：622 mailto:sage [2016/06/05(日) 17:37:35.59 ID:D6e8xYJD.net] 分かりにくかったから修正 × wikiの1-4 ○ wikiの「継承_(プログラミング)」のページ内、「多重継承と仮想継承」の下半分に書いてある1-4 636 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:39:58.20 ID:eiIG0jy5.net] >>622 多重継承はどちらの親から継承するか競合する場合があるからだろ。 コードとして分かりにくいし、名前の解決も複雑になる。 637 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 17:41:12.98 ID:k6yVAd6S.net] 真のオブジェクト指向は、 オブジェクト同士がシステムで規定した唯一のフォーマットだけでメッセージ交換して動作する物なんだから、 結合度も最弱でどの機能を挿げ替えるにも一瞬で済むはずなんだ。 今の実装方法が間違いだらけなんだ。 638 名前：デフォルトの名無しさん [2016/06/05(日) 17:47:45.40 ID:zc7alBMy.net] メッセージ交換のオブジェクト指向が本来なのは確かだけど今のオブジェクト指向は抽象データ型の方を指す場合が多いからねぇ 639 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:09:55.26 ID:fuiY39en.net] >>623 キミはコンテクストが必要な場面と不要な場面すら区別がついてないだろう？ いつ、クラスメソッドにしていつインスタンスメソッドとして実装すべきか明確な設計指針を持っているか？ 640 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:10:02.90 ID:RNuHfoku.net] そして感情は基本的な物を組み合わせれば、複雑な物が作れるはずだ 641 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:10:20.48 ID:RNuHfoku.net] 誤爆 642 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:18:56.22 ID:fuiY39en.net] 理想的なオブジェクト指向、正しいオブジェクト指向など存在しないだろ 欠点を指摘したら、理想的なオブジェクト指向設計であったならば、この問題は回避されたという だがその欠点を克服するために標準的なオブジェクト指向言語がどの程度のコード量を追加で要求し あるいはパフォーマンス上でのオーバーヘッドがどれだけ発生するかなんて知ったことではないという なぜならば　オブジェクト指向とは実装を隠蔽し、外部的からみた状況がうまくカプセル化されていればいいのだから もっともそんなことは単純な関数にだって出来るということは、誰も指摘しないし理解もできない 完全なオブジェクト指向であればという言葉は 単なるないものねだりを象徴する言葉で、言語が正しい設計を一切サポートせずに むしろ誤った方法を選ばせているという自白に過ぎない だいたい、システムを設計するのにそんな超自然的なセンスなど必要ない 計算すべき対象が、有限のメモリ空間、有限の時間で解ければいいだけだ やりとりの美しさや汎用 643 名前：性というものは存在するが、 オブジェクト指向という概念はその根底からして汎用的ではありえない クラスを定義するごとにメソッドの定義を要求されるというのはどこも汎用的な考えではない そしてそれを回避するために継承を行うというのも汎用的ではない 汎用性という概念でいうならば、 クラスオブジェクトは、構造体、あるいはハッシュテーブルに対して1mmも勝てる部分は存在しない [] [ここ壊れてます] 644 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:22:55.64 ID:eiIG0jy5.net] >>631 お前が例としてあげた欠点はCにもあること。 おまけにグローバル変数の多用などはCの世界でも忌むべき行為。 的外れな批判を繰り返してる。 間違ったコードを書きにくくなっただけでもオブジェクト指向は有用だとしか思えない。 645 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:26:04.99 ID:kjF/TSSS.net] グローバル汚染とかマジ勘弁して下さい 646 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:27:37.67 ID:DztPIEJ0.net] >>631 何にでも適用出来ることをOOPLにだけ当てはめて批判してるだけ 647 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:36:04.16 ID:nosfsWv3.net] >>590 Cがプリミティブを基本としてるってlibcとかの話でしょ 話がズレズレ 648 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:38:44.12 ID:fuiY39en.net] >>632 ごめんね、ちゃんと読み取れる人だけには意図が伝わるように書いたつもりなんだけどね こう言えばわかるよね オブジェクト指向のパッケージングが単一のクラスではなく複数のクラスからなる 比較的大きいモノリシックなものとなっているのは、オブジェクトが隠れたグローバル変数として機能しているから DRY原則に忠実になるためには、クラス定義もまた一つでなければならない もしこれがクラスではなく関数モジュールであったとしたならどうだろうか？ その関数モジュールのみを一つのパッケージとして切り出すことに何の問題もないだろう。 しかしクラスというのはメソッド定義だけではなくデータ・タイプの定義も兼ねている。 このデータタイプ定義とメソッド定義の重複を許すならば、 小さなパッケージとして、ライブラリを切り出すことができるだろう でもオブジェクト指向ライブラリではそんなことはしないよな 君たちの言葉で言えば、オブジェクト指向というのは凝集性が低い キミが言っている間違ったコードやグローバル変数の排除というのは Cでいうところのモジュールで制御できる それはオブジェクト指向の問題ではなくスコープ制御の問題だ グローバル変数を無くすという意味合いではレキシカルスコープをサポートしていれば十分なのに private修飾子を使うことにしたことで、オブジェクト指向はテスタビリティを捨てたんだよ 間違ったコードならデバッグすればいい、事実デバッグできる だが間違った設計指針で突っ切ればそれじゃ済まないのは痛いほど理解しているよな？ 何年経っても結合テストで悲鳴を上げ続ければいいんじゃねえの？ 単体テストすら簡単にはできねえのにな 649 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:40:17.09 ID:fuiY39en.net] 間違ったコードを書かないという観点で言えば 関数型言語のほうがよほどオブジェクト指向よりも安全性をサポートしている 650 名前：デフォルトの名無しさん [2016/06/05(日) 18:49:57.16 ID:/bruxSbe.net] 関数型は遅いからな 現実的には使いものにならないことが多いだろう 651 名前：デフォルトの名無しさん [2016/06/05(日) 18:53:18.70 ID:zc7alBMy.net] よし じゃあrust使えば解決だな！ 652 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:53:40.94 ID:fuiY39en.net] オブジェクト指向の問題点は Cよりも後発であるにも関わらず、より問題やシンタックスを複雑にしていて それもコード上で解決する問題から、設計上に関わる問題へと進化させている どれだけ俺達が頑張ろうとも機能を実現するのはアルゴリズムで有るにも関わらず カプセル化の海にアルゴリズムを沈め、不可視とした もっともプログラマが検討すべきデータ構造とアルゴリズムという観点をカプセル化の海に沈めた そしてもっとも重要ではないテクニカルなシンタックスについての井戸端会議を始めだした オブジェクト指向ユーザーは(Cに比べて)保守性や安全性が優れているというが、本当にそうだろうか？ Cのポインタは確かに不要な機能かもしれないが、モジュール機能があれば最低限のスコープ制御はできる。 オブジェクト指向は名前をどのようにつけるかを気にしている。 もしそうでないならば、何かを継承する必要もないし、ポリモーフィズムも必要ない オブジェクト指向は確かに高尚な概念だ、しかしそれで創りだされるプロダクトがゴミでは意味が無いだろう オブジェクト指向をフル活用してどんなプログラムが作るかというと、それこそ電卓計算機以上のものは作れないし、作ってもいないだろ。 653 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 18:56:27.86 ID:fuiY39en.net] 僕らはそんな電卓計算機、あるいはタイプマッチングディスパッチャなんて 設計無しで書けますから 654 名前：デフォルトの名無しさん [2016/06/05(日) 19:04:37.43 ID:/bruxSbe.net] >>640 どっかの洋書のマルコピか？ 655 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:07:18.20 ID:eiIG0jy5.net] >>636 「オブジェクトが隠れたグローバル変数として機能している」ってどういう意味？ 「DRY原則に忠実になるためには、クラス定義もまた一つでなければならない」 とあるが、同じクラスを繰り返し定義することなんてDRY以前にあり得ない。 知ってる言葉を必死に繋げてる感じは伝わってくるんだけど、もっと平易に理解できるように書いてくれ。 何を言いたいのか分からん。 656 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 19:13:58.38 ID:eiIG0jy5.net] >>636 専門用語を使いたいお年頃なのかもしれないけど、文章の流れとかで理解度は分かるから。 Cはメモリリークがないと言っちゃうところとかからも。 背伸びするより伝わる文章書いたほうが印象いいよ。 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の図体のでかさを見てから モノリシックなライブラリは設計が悪いと言ってくださいね

---

---

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

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