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

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 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さんすげぇわ まあ、ここまで文章で表現できなくても 「なんかオブジェクト指向で設計しない方が問題起きなくね?」 ってのは常々思ってたけどね オブジェクト指向って利点ないんだよなぁ って言うと人格攻撃始めるしね（笑） 758 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:23:23.27 ID:N6ydBJjg.net] >>742 そんなに人格批判されてたか オブジェクト指向の批判と言いつつjavaの批判ばっかしてたような気が 759 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:25:21.33 ID:pfL89vbp.net] >>743 いや別のスレでもさ オブジェクト指向役に立たないよ って言うと 真のオブジェクト指向使いが来てレベルが低くてお話にならないって お墨付きをくれるじゃん 760 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:31:29.24 ID:N6ydBJjg.net] >>744 いや別のスレの話されても知らんがな 2chだからそういう人ばっかなのはしょうがないし それに関数型界隈からみてオブジェクト指向批判って昨今そんなに珍しくないじゃん？ 761 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 01:42:10.16 ID:UaKeA7lT.net] >>738 俺はRuby使いでもないんだが、個人的に思うのは、 あれは多分「対称性」を増して多態（または同一関数で処理）するためではないかと。 多態する時、中身がオブジェクト（参照渡し）とプリミティブ（値渡し）だと扱いを変えないといけない時が多い。 また、オブジェクトの場合にはgetter等での対応も可能なのだが、プリミティブだとこれができない。 結果、要するに一つの記述で済ませられなくてウザイ。 とにかく、形が揃っていることが重要。 単発でプリミティブに積極的に仮想関数はやして、ってのはそちらの言うとおり要らないと思うが、 オブジェクトと多態しようとすると、オブジェクト的アクセスが出来ないと無理だ。 だからRubyの仕様は、あれば便利だろうなとは思う。 >>740 Rubyは速度を気にする言語ではないので、多分Rubyは全てが全部ガチのオブジェクトなのではないかと思う。 ただ繰り返すが、俺はRuby使いではないし、詳しい仕様も知らないから、完全に推測だが。 762 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 02:13:17.50 ID:okPwaxJe.net] RubyはRubyで涙ぐましいことやっているよ ポインタは必ず4の倍数になるから ポインタとして絶対使わない値に数値を詰め込んでいる ただ、個人的にはそこまでしてプリミティブ型をオブジェクトにしなくてもよいと思っている 理由はコンピュータにとって、その方が自然だから 素直な実装を好むのでね 763 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 02:13:48.35 ID:yxmdKndQ.net] Rubyも、primitive っぽく、オブジェクトへのポインタに、 直接、Fixnum(小さい数値)・Symbol・nil・真偽値の値を納めて、メモリを節約している そしてたぶん、それらをオブジェクトとして扱うと、 (オブジェクトのメソッドを呼び出す際、) 何か特別な処理をするのだろう。Boxing, Unboxing 764 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 02:52:03.94 ID:N6ydBJjg.net] >>747 へー勉強になるわ 俺はてっきり他のオブジェクトと同じように扱うのかと思ってた 765 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 14:20:59.62 ID:88+5arvI.net] >>708 > .net Frameworkの図体のでかさを見てから って言ってるけど「図体のでかさ」ってどういう意味？対象範囲が広いってこと？ 具体的に何を指して.net Frameworkはモノリシックだと言っているんだ？ そして、その問題はオブジェクト指向じゃなければどうやって解消できたんだ？ すべてを説明して初めてまともな主張になるのに相変わらずの単語の羅列。 単語を羅列して満足するのは中学生っぽいからやめよう。 766 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 19:29:59.14 ID:4wogmex0.net] パソコンの構造自体がオブジェクト指向が出来る様になって無いんだから 誤魔化すしか無いんだ。 767 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 20:34:02.75 ID:I5hI2Tg9.net] 関数型がOOよりマシに感じるのはOOに比べて普及してないから OOでクソ設計してる連中もそろそろそっちに行くから関数型に代わるパラダイムを探しとけ 768 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 20:57:47.03 ID:88+5arvI.net] 関数型だけでシステムを設計できんの？ データオブジェクトの更新とかどうすんだ？ 769 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:09:20.34 ID:okPwaxJe.net] というかマルチパラダイムでよいんだよ 一つの方法で全てしなければならない必要はどこにもないからな 770 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:17:51.69 ID:88+5arvI.net] >>754 併用するやり方は知ってるけど オブジェクト指向から関数型みたいな書き込みがちらほらあるのは分かってない奴が書いてるだけ？ 771 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:23:28.39 ID:I5hI2Tg9.net] 立ち位置コロコロ変えながら長文で煙に巻いとる奴への皮肉で書いとるだけやぞ 772 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:28:12.06 ID:Box2vTFt.net] >>753 C言語でアプリは作れないの? 773 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:29:12.26 ID:okPwaxJe.net] あーこれは荒れる予感 774 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:31:58.39 ID:UaKeA7lT.net] >>747-748 いやそれは使い方にもよるが、多分プリミティブをオブジェクトにするためではなく、 GCヒープの二重ポインタアクセス **obj をケチっているだけだぞ。 V8(ChromeのJavaScriptエンジン)でも同じだ。 > V8 は Ruby と同様, 整数値はヒープにとらずポインタに埋め込む. だから 整数値をあらわす Smi (small integer) クラスのコードは少し面白いことになる. > // objects-inl.h > int Smi::value() { > return reinterpret_cast<int>(this) >> kSmiTagSize; > } > steps.dodgson.org/bn/2008/09/07/ (モロにRubyと書いてあるが、気にしてなかったわ、、、) JavaScriptでは整数はプリミティブだ。 それでも、**obj よりも (int)(*obj)>>1の方がケチれるし速い。（とgoogleは考えた） これは型無しGCヒープだからだよ。 プリミティブは固定長だから管理ヒープのヘッダ側に突っ込める。 丁寧にやるのなら、オブジェクトヒープ（可変長）とプリミティブヒープ（固定長）を分けろということになるが、 2つ作るのは管理上かなり面倒な事になる。 したがって、ヘッダ側に突っ込むのは悪いアイデアではない。 というか、これについては大して努力も要らないし、O(1)で済むし、（貧民からすると）涙ぐましいと言うほどでもない。 C的といえばそうだ。1ビットでもケチろうというのが元来の(富豪プログラミングではない）Cの世界だ。 だから生まれながらの大富豪が「涙ぐましい」と感じるのも分かる。 余談だがV8のチームはド貧民ではない。同URLで > // objects.h > // Formats of Object*: > // Smi: [31 bit signed int] 0 > // HeapObject: [32 bit direct pointer] (4 byte aligned) | 01 > // Failure: [30 bit signed int] 11 となっている。ド貧民なら書き込み時のOR命令をケチるためにHeapObjectを00にアサインする。 Matzが貧民なのかド貧民なのかは俺は知らない。 775 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 21:35:52.33 ID:okPwaxJe.net] うん、俺もそう思う 776 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 22:08:36.12 ID:88+5arvI.net] >>756 そういうことな。 777 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 22:09:43.70 ID:88+5arvI.net] >>757 オブジェクト、関数型って区別するときはCは手続き型だろ。 778 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 23:30:38.18 ID:UaKeA7lT.net] 収まったか？ここまでに分かったことを纏めておくぞ。 1. 1の>>1は無能。 2. Javaはゴミ。 3. OOPはまやかし。 異論ある奴は96時間以内に反対弁論を適宜開始してくれ。 無ければ次の議題があればそれ、それもなければ解散だろう。 次の議題の優先提出権は ID:fuiY39en にあるとするのが妥当だろう。 779 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 23:39:18.18 ID:88+5arvI.net] >>763 お前>>1を意識し過ぎｗ 論破されたのがよっぽど悔しかったんだなｗ 780 名前：デフォルトの名無しさん mailto:sage [2016/06/06(月) 23:52:53.12 ID:qaNk8WrT.net] Collectionとか有名どころのフレームワークとか使う時は気にならないけど 同僚がOOP的に作った物使ったり、自分でそういうのを目指すときは凄い違和感がある 781 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:10:23.92 ID:Gat57in+.net] ついでに言っておくけど、 >>752 > 関数型がOOよりマシに感じるのはOOに比べて普及してないから これは俺もそう思う。叩かれてないから埃も出てないだけ。 とはいえ、選択肢が増えることはいいことではある。 >>765 それはいわゆるスタティックおじさんの主張と一致する。 「馬鹿製のOOPなんて糞の役にも立たない。 謹製クラスはパーツとしては極めて優秀なので、それだけ使っていれば事足りる」って奴だ。 俺はこれについては「使い方が悪い」という立場だが、(OOPは正しく使えば有用） 達人にしか使えないシステムなんてつまりゴミ、という考え方も出来る。 >>631はそれ以前で、そもそも筋が悪いからゴミ、という立場のようだが。 782 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:13:04.94 ID:AF8c7GVP.net] というか、多くのフレームワークが オブジェクト指向を採用していることからも オブジェクト指向が有用だってのは火を見るよりも明らかなわけで 783 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:23:09.28 ID:AF8c7GVP.net] あと関数型であればテストしやすいのは確かだけど、 関数型であればアプリを作りやすいとは限らないよね。 784 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:27:18.57 ID:a1/3IcbT.net] >>768 テストがしにくい方がアプリが作りやすいとおっしゃる? 785 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:29:10.50 ID:wZ7jqyPr.net] >>769 テストだけが構築のしやすさを決める要因じゃないだろ。 786 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:35:25.39 ID:a1/3IcbT.net] >>770 いや全部テストだと思うわ 不具合が一件もなければ誰も設計なんてせんもん したらテストがしにくいってのはかなりコアな部分でダメなんだよ 787 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:42:39.37 ID:wZ7jqyPr.net] >>771 バグがなければ設計しなくなるのはどうして？？？ >不具合が一件もなければ誰も設計なんてせんもん 788 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:47:09.94 ID:Gat57in+.net] >>767 LispやHaskellが本格的に使用され始めたら、関数型のフレームワークがごろごろ出て来ますー（棒） 789 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 00:48:44.00 ID:nXPTtP+t.net] >>773 じゃあ一生無いですね 790 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 01:13:07.58 ID:AF8c7GVP.net] >>771 例えばデータベースを使うウェブアプリってのは、殆どというぐらいたくさんある。 実績のあるMySQLを使う。 その中で例えば、フォームからユーザーの作成ボタンを押したらユーザーを作成する。 この時データベースにはユーザー名とメールアドレスと仮パスワードが記録されてており メールアドレスにメールが送信される。 そのメールのアドレスを表示すると仮パスワードと新しいパスワードを 入力するフォームが表示され、そこに仮パスワードを新しいパスワードを入力し、 仮パスワードが一致すれば、新しいパスワードを登録して、ユーザー登録が完了する。 いうとありがちなテストを、関数型言語（と関数型用のフレームワーク）で記述するとどうなるの？ 面倒なら具体的に書かなくてもいいけど、どういったツールを使って どんな感じでやるのか教えてくれない？ まったく想像つかないんだよね。 791 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 01:14:33.37 ID:Gat57in+.net] >>771 内容については同意。 ただ、だからといって関数型の時代が来るとは思わないが。 普通に考えれば、テスタビリティに問題があるのならそこを改善した「改善版OOP」を使おうということになる。 本質的に駄目な場合は諦めるしかないが、そこまで駄目だとも思わない。 なお、どうも馬鹿が2匹いる。 俺は付いて来れない奴は置いていった方がいいという立場だ。 当たり前の事を説明しても無駄に時間がかかるだけ。 ある程度の議論速度を保ったほうが質のいい議論が出来る。 792 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 01:17:12.72 ID:wZ7jqyPr.net] >>776 矛盾したこと言って説明できなくなるバカ二匹の自己紹介乙。 793 名前：775 mailto:sage [2016/06/07(火) 01:29:47.52 ID:AF8c7GVP.net] 少し質問が曖昧かもしれないからもう少し具体的に書く。 まずオブ� 794 名前：Wェクト指向と関数型言語のハイブリッドである Scalaならこれらをどうやるかだいたい想像できるので省く。 これらのアプリのテストを行う時 1. 関数型言語には何を使う？ 2. ウェブフレームワークには何を使う？ 3. 開発用のウェブサーバーには何を使う？ 4. URLとコントローラ相当へのルーティングの例 5. モデル相当に必要なデータベースと関数型へのマッピング？とかはどうするのか？ 　　（ORMはオブジェクトへのマッピングだから違うだろう？） 6. ビュー（HTMLへのテンプレートエンジン）は何を使う？ 7. JavaScriptとCSSへのサポート機能（Railsでいうアセットパイプライン的な仕組み） 8. テストコード（ユニットテスト相当）は何で書く 9. エンドツーエンドテストには何を使う？ 例えばRailsとかはこれらを包括的にサポートしてるんだよね。 このレベルでアプリを開発しやすいと言っているわけよ [] [ここ壊れてます] 795 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 02:03:02.34 ID:Gat57in+.net] >>778 そりゃ自分で答え言っているのと同じじゃん。君の意見は、 「Railsには素晴らしいフレームワークがあるからアプリ開発がしやすい」だろ。 なら関数型もエコシステムが回り始めたらこの点は改善されてしまうのさ。 しかもテストしやすい＝デバッグにかかる時間が短い＝フレームワークが出来上がる速度も速い、なんだよ。 （最大の問題は、その日が来るのかどうかだが） 今の議題は、「関数型」「OOP」のどちらがアプリ開発しやすいか？だろ。 「『今』フレームワークが揃っているから」というのは「現在」限定ならいいが、上記議題なら論点がずれているだろ。 テストしやすいってのは本質的にプログラミングしやすいって事なんだよ。 「関数型」が糞だって言われているのは実行速度の方だろ。 あれは本質的に遅いから、今後とも改善しないと思うし。 煽るだけしかできないもう一匹の池沼と比べて、食らいついてこようとするその姿勢は評価するぜ。 だから説明を書いた。 796 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 03:28:03.53 ID:AF8c7GVP.net] >>779 机上の空論はどうでもいいよ。 それでアプリは開発しにくいんだよね？ 797 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 03:28:55.02 ID:AF8c7GVP.net] 関数型が本当に開発しやすいならば、 フレームワークはとっくにできていておかしくないはずだ。

---

---

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

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