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

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 607 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:38:23.48 ID:fuiY39en.net] というよりオブジェクト指向のファクトリパターンを使われたら 例えばオブジェクトの単純なコンストラクタも隠蔽されているよね このプライベート変数が状態Aから状態Bに遷移する条件が ドキュメントに記されていないってこともあるわけだが、 いったいどうやってテストするんだろうなあ 608 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:39:23.97 ID:eiIG0jy5.net] >>595 想定している状況を明確にしよう。 言語の標準には含まれないけど信頼できる第三者が提供しているライブラリないしクラスならテストせずに利用する。 そもそもソース自体が提供されないことも多いから。 で、想定している具体的なケースは？ 609 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:48:46.08 ID:fuiY39en.net] >>597 ネットワークIOに関わるライブラリで、 ネットワークストリーム(websocket)をキャプチャするライブラリである。 このライブラリを連続して稼働させたいが、 ガベージコレクトしようにも、ネットワークストリームのデータは単方向リストで構成されており、 単純に言えば長期稼働によりOutOfMemoryの可能性がある 私はこの挙動に満足できないので、プロクシパターンでも使って改変しようと思っていたのだが オブジェクトのセッタ及びゲッタが満足に公開されておらず、そうすることもできない これのどこに再利用性が？ この部分的な挙動以外の全てにおいて俺は満足しているが、 長期稼働を前提としない設計のおかげで、全てが台無しになっている 俺はどうすれば俺が期待するように稼働させられるかを知っているが、 たったこの一点だけでこのライブラリは「使えない」んだが 610 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:52:11.66 ID:DztPIEJ0.net] そのライブラリがOO以外で書かれてたらどう対応するの？ 611 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:52:56.61 ID:eiIG0jy5.net] >>598 メモリリークが発生するコードがだめなだけでオブジェクト指向関係ないのでは。 Cのライブラリだったとして、メモリリークが発生するライブラリが使えないのは一緒じゃん。 612 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:08:36.99 ID:fuiY39en.net] このライブラリは複数の構成要素からなっている httpのキャプチャ　　　　　　　　この機能は使える データストリームのencrypt decrypt　この機能も使える パケットのファイルへの書き出し　　　この機能も使える websocketのキャプチャ この機能も使える ただし、データ構造は単方向リストで実装されている　　は？　は？ これはライブラリ作者が悪いの？俺が悪いの？ 結局オブジェクト指向というのは、適切に全ての情報を開示できなきゃ成り立たないし ライブラリ作者と俺の考えが少しでも違ったら、場合によってはその全てがダメになっちまう 言っておくがライブラリ作者の考え方は間違いではないよ、もっとも汎用性のある構造はリストだからな キューを使ったりすると、そのデータストリームの速度によっては、キューからデータがあふれる事もありえる もっとも汎用的な解がリストだ、そしてそれは俺の求めるものじゃない なぜこの機能が別々のパッケージとして切り出せないのか？ オブジェクト指向は巨大なライブラリを構築するための概念らしいが、 さて、実際のところは小さなライブラリにできない理由があるんだろうね >>599 もしライブラリが関数であれば、その当該関数のみを自作することができる 構造体であったとしても構造体がどのようなデータから構成されているかを見ることは出来る ところがオブジェクト指向であると、まずオブジェクトを構成して プライベート変数をセットして(時には自由にセットすらさせてもらえなくて) さらにはオブジェクトがどのようなデータから成っているかは「ドキュメントが公開されていないかぎり知ることはできない」 >>600 www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html Cプログラムでメモリリークなんて聞いたことがあるだろうか。今では、メモリリークの発見が大産業になってしまった。 全部見つけるのは費用がかかりすぎるから、たいていの会社はあきらめて、山ほどリークのあるプログラムを出荷してしまう。 I： ツールはあるけど…。　S： そのツールも、ほとんどは C++ で書かれているんだよ 613 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:10:13.16 ID:6ih2a7FC.net] >>598 関数Fの動作が少し気に入らないから改造したい しかしFの実装詳細はソースとして公開されていないから手が出せない って状況と同じ事だよね？ OOP全く関係ないけど認識なんか違う？ 614 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:12:40.93 ID:8zGv30iU.net] >>601 仕様で一週間に一度自動で再起動かける仕様にしておけば 再起動する仕組みさえ動けば ランニングは2週間も持てば良い ってして逃げてる（笑） 615 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:13:45.22 ID:k6yVAd6S.net] 隠蔽しちまったら安全に継承も出来ないよな。 616 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:21:10.78 ID:fuiY39en.net] 結局ライブラリを改変するためにはハッキングじみたことをするしかない それならば、自分で1から書いたほうが早い なぜそんなマネをしないといけないのかというと、 オブジェクトがプライベート変数という状態を隠しもっており、 それが自分自身の思うように統御できないように構成されているからだ さらにはそのオブジェクトはパッケージを横断しており、 だからパッケージの一部分のみを切り出して小さなパッケージとすることもできない これは事実上のグローバル変数だ もしencryptやdecryptの部分だけを切り出して公開してくれていればよかったのに でもおそらくDRY原則とやらがそれを妨げるのだろう もっとも効率よくDRY原則を行うにはどうすればよいのか？それはグローバル変数を使うということだ グローバル変数を用いればもっとも効率よく状態を共有することができる さらに言えばファクトリにオブジェクト生成を投げたりして 単純なオブジェクト生成すら封じられている場合もよくある >>602 もし単純な関数であるならば、その引数と返り値だけを気にしていればよい、それのみをプロクシすればよい もしその部分さえ隠蔽していたならば、ライブラリとして一切利用できず、誰かに不平を言われることもない オブジェクト指向は本来ユーザが定義すべき状態すらも隠蔽するので、確かに手軽に利用できる しかしライブラリ作者が規定した挙動がユーザの求めている挙動と同一であるという保証はない。 だからライブラリをしばらく使った後に捨てることになる　「やっぱあのライブラリイケてねえわ」 果たしてCや関数型のライブラリでこんな事になり得るだろうか？ 1.最初から使えないか、2.思ったより遅いか、3.何度でも使える この3つにしかならないだろう。 617 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:25:24.73 ID:fuiY39en.net] オブジェクト指向というのは、 大きなシステム、大きなパッケージを作るための思想ではなく 小さなシステム、小さなパッケージを作らせてもらえない思想のことである UNIX思想の対極に存在するものであり、つまるところはwebの思想にも反するものである 言語のコアとライブラリを編みこむようにプログラムを構築できず 巨大なビルディングブロックを積み上げて、施工誤差に耐えながらも、 出来上がった行数を見てこんな巨大なものを作り上げたと悦に入る もちろん成果物も巨大であるからこそ、他人には保守することができない このオブジェクトがどのような状態、変数からなり、どのオブジェクトから継承されていて、 何をしていいのか、何をしてはいけないのかなどどこにも書かれてはいない 618 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:50:36.62 ID:DztPIEJ0.net] >>601 その機能構成なら普通は1クラスにはまとめないよ OOでもキャプチャクラスを書き直すだけだと思うけど 619 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:54:03.14 ID:8YdCKwaE.net] 大抵はクラス分けに失敗しているのと、表層だけをオブジェクト指向で設計して細部を放置のまま実装に入っちゃうケースばっかり。 620 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:54:35.34 ID:D6e8xYJD.net] >>581 > だが俺の考えを言えば多重継承をサポートしないかぎり、DRYは満足できない 同意。 多重継承に関しては出来ないことによる問題の方が大きい気がしている。 >>590 > これを回避する方法はクラス・メソッドを使うという方法だ、（中略） > オブジェクト指向信者がバカにしているstaticおじさんの手法に過ぎない 俺の理解では、staticおじさんの手法ってのは全関数をstaticにしてフラットにアクセス、 つまりC的にするということであって、クラスメソッドを使うことではないと思う。 それはさておき、実は.NETはクラスメソッドが主流で、Array.indexOf(array, value)となっている。 > https://msdn.microsoft.com/ja-jp/library/7eddebat(v=vs.110).aspx これについては俺も若干謎なんだが、とにかくインスタンスメソッドではない。 なぜだか知っている人が居たら教えて欲しいのだが、 少なくともヘルスバーグは君と同意見だったのだろう。 >>591 > 然るにまともにテストもできないし動作もさせられないからこそ オブジェクト志向は「設計」に重視で、「テスタビリティ」については考えられていないのはその通りだ。 その点、確かに「副作用がない」点に於いて関数型は「テスタビリティ」がいいのも事実だ。 ただし実際に「関数型ガー」と主張する馬鹿共は無理に状態変数を除去したおかしなコードで(ｷﾘｯ する事も多く、これまた何でそうなるのかはかなり疑問なのだが。 とはいえ、確かに、「テスタビリティ」について何も考えられていないオブジェクト志向は、 今となっては時代遅れなのかもしれない。 621 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:55:25.83 ID:D6e8xYJD.net] >>601 > 単方向リストで実装されている 配列の間違いか？ 一応、単方向リストならノードを抜けるので、正しく実装されていればGCは為され、OutOfMemoryは発生しない。 ただし、「正しく実装」されているかは確認できないが。 逆に、間違った実装であることは確認できる。例えば、マイナス方向へのシークが出来るとか。 >>605 言っていることは分かるが、それはオブジェクト志向ではなく、オープンソースでないことの問題のように思われる。 とはいえ、 > もっとも効率よくDRY原則を行うにはどうすればよいのか？それはグローバル変数を使うということだ > グローバル変数を用いればもっとも効率よく状態を共有することができる これについては同意だ。厳密に重複コードを排除したいのなら、オブジェクト間はだんだん密結合になっていく。 だから、どこまで厳密にやるかはその人次第で、オブジェクトがどれだけ粗結合を保てるかもそれ次第になる。 その点、巨大な固まりのリリースが多いかどうかは俺は知らない。 先に言っておくが、俺は1の>>1程度の池沼を相手にする気はない。 レスを要求するのなら、池沼でないことを自らの書き込みで示せ。 お前らには池沼であり続ける権利はあるし、俺にはそれを止める権利はない。 622 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 15:55:43.41 ID:8zGv30iU.net] 俺は39yenさんの言いたいことが痛いほどわかるぜ オブジェクト指向は怪しい ぶっちゃけ使わないほうが開発がうまくいく 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に対する反論になってねえし。

---

---

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

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