- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
609 ：デフォルトの名無しさん[sage]：2016/06/05(日) 15:54:35.34 ID:D6e8xYJD - >>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
> 然るにまともにテストもできないし動作もさせられないからこそ
オブジェクト志向は「設計」に重視で、「テスタビリティ」については考えられていないのはその通りだ。
その点、確かに「副作用がない」点に於いて関数型は「テスタビリティ」がいいのも事実だ。
ただし実際に「関数型ガー」と主張する馬鹿共は無理に状態変数を除去したおかしなコードで(ｷﾘｯ
する事も多く、これまた何でそうなるのかはかなり疑問なのだが。
とはいえ、確かに、「テスタビリティ」について何も考えられていないオブジェクト志向は、
今となっては時代遅れなのかもしれない。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
610 ：デフォルトの名無しさん[sage]：2016/06/05(日) 15:55:25.83 ID:D6e8xYJD - >>601
> 単方向リストで実装されている
配列の間違いか？
一応、単方向リストならノードを抜けるので、正しく実装されていればGCは為され、OutOfMemoryは発生しない。
ただし、「正しく実装」されているかは確認できないが。
逆に、間違った実装であることは確認できる。例えば、マイナス方向へのシークが出来るとか。
>>605
言っていることは分かるが、それはオブジェクト志向ではなく、オープンソースでないことの問題のように思われる。
とはいえ、
> もっとも効率よくDRY原則を行うにはどうすればよいのか？それはグローバル変数を使うということだ
> グローバル変数を用いればもっとも効率よく状態を共有することができる
これについては同意だ。厳密に重複コードを排除したいのなら、オブジェクト間はだんだん密結合になっていく。
だから、どこまで厳密にやるかはその人次第で、オブジェクトがどれだけ粗結合を保てるかもそれ次第になる。
その点、巨大な固まりのリリースが多いかどうかは俺は知らない。
先に言っておくが、俺は1の>>1程度の池沼を相手にする気はない。
レスを要求するのなら、池沼でないことを自らの書き込みで示せ。
お前らには池沼であり続ける権利はあるし、俺にはそれを止める権利はない。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
612 ：デフォルトの名無しさん[sage]：2016/06/05(日) 16:11:09.44 ID:D6e8xYJD - ついでに言っておくと、俺は ID:n7HRsF8B についてもほぼ完全に同意だ。
異なるのは、俺は>>449にも完全に同意である点と、
リファクタリングはもう少し種類があってもいいだろ、という点だ。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
616 ：デフォルトの名無しさん[sage]：2016/06/05(日) 16:38:02.40 ID:D6e8xYJD - で、俺なりに何故1の>>1みたいな池沼に限ってOOPにすがるのかな？ということを考えてみたんだが、
「形」があるからじゃないかなと。
センスがない奴はいざ仕様を出されて「設計」しろと言われても、何をやっていいか分からない。
もちろん「設計」の中にはOOPならクラス分けもあるのだが、それ以前に、
例えばC++なら「手続き型」等も選べるのだが、それをどう選んでいいかも分からない。
その点、OOPならクラス分けしたら「設計」した気分になれるし、「継承」しておけば正しくOOPした気分になれる。
だから考えられない池沼にはOOPは割とフィットすると思うんだよ。
ただこれは、局所的な最適化でしかない。
例えば、熟練したプログラマは10,000行のコードまでは苦もなく扱えるというのが通説だが、
このとき、10,000行のスコープで最適化が行われる。
OOP信者はこの例でいうなら1,000-3,000行のスコープでの最適化しかしておらず、
その上の「手続き型」「関数型」等の階層での最適化が出来てない。
だからその上の最適化が出来る連中からは、異常にOOPにこだわる奴は馬鹿に見える。
もちろんOOPにも利点があるので使われているわけだが、初めからOOPありきとなるべきではない。
とはいえ、OOPの問題点だと言われているのは、
「正しくOOPできてない」事による物が多々紛れ込んでいるのも事実だと思うが。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
622 ：デフォルトの名無しさん[sage]：2016/06/05(日) 17:34:05.48 ID:D6e8xYJD - >>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みたいに、結合度を「文法的に」確定させようということなのか？
(文法的に継承しにくい構造にして、オブジェクト間の粗結合化を促進する、つまり洗脳的）
俺としては、そこに書いてあるように、
「直感的」に書けない場合がある＝良い設計が見えているのに記述できない方が問題だと思うのだが。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
624 ：622[sage]：2016/06/05(日) 17:37:35.59 ID:D6e8xYJD - 分かりにくかったから修正
× wikiの1-4
○ wikiの「継承_(プログラミング)」のページ内、「多重継承と仮想継承」の下半分に書いてある1-4
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
656 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:14:28.99 ID:D6e8xYJD - >>631
言いたいことは分かるが、現実的に多態は有用だ。
もちろんオブジェクト構文を用いずに無理矢理多態することは出来るが、
専用文法があるのならそれを用いた方が見やすいのは事実だ。
問題は「クラス作成」「継承」さえすればいいと思っている馬鹿が多いことだと思う。
これは関数型にも同様に言えて、こちらは「状態を持たない」「副作用がない」になる。
>>636
言いたいことは分かる。
> グローバル変数を無くすという意味合いではレキシカルスコープをサポートしていれば十分なのに
特にこれなんて本当にそう思うし、クラス階層がまともに作れないC++は仕様に欠陥があると思う。
ただ正直、レキシカルスコープはGC言語には似合うがスタック言語には似合わない。
だからC++のラムダはアレな仕様に「見た目は」なっている。
実際には確かに妥当な仕様なのだが、綺麗に便利に書こうって感じじゃない。
まあこれは脱線だが。
>>640
> Cよりも後発であるにも関わらず、より問題やシンタックスを複雑にしていて
> それもコード上で解決する問題から、設計上に関わる問題へと進化させている
ここについては俺の見解は少し異なる。
俺はタイプ量は気にしない。
型にしてもシンタックスにしても、それはコンパイル時点で静的にバグを落とすためだ。
静的に落とせるバグは全て静的に落とすべきだ。動的にテストで落とすよりも断然生産性が高い。
とはいえ、いちいちシンタックスがウザイのも事実だが、これは税金だと思っている。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
678 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:52:11.61 ID:D6e8xYJD - >>655
> メソッドとデータ・タイプが分離されていないおかげ
元々はそこをくっつけてカプセル化しようという思想だからな。
だから形式的にはデータタイプは全て独自で、当然メソッドも全て独自ってわけだ。
現実的にはInt64もDateも同じだったりして、結果、addメソッドも同じバイナリで問題ないわけだが、
それでも Int64.add と Date.add の区別を付けるのは、俺は「税金」だと思っている。
>>666
Cはポインタポインタって言われるけど、真の実力は実は関数ポインタにあるんだろ。
関数ポインタを使いやすく、また色々文法的チェック機構を付けまくったら、オブジェクトとメソッドになるわけで。
生ポインタ使える奴がGC言語はゴミと言うようなもので、
生関数ポインタを使える奴がオブジェクト指向はゴミというのは、当たってはいるがそれ言っちゃ議論はおしまいだ。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
709 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:55:42.18 ID:D6e8xYJD - >>683
> オブジェクト指向は多くの問題を引き連れていませんか？という当て馬として使ってる
まあこれはその通りなんだが、俺は元凶はアホが設計やることだと思っている。
例えばGC言語、本来は「煩雑なリソース管理に脳内リソースを割かれるよりは、
自動化できるところは自動化し、本来プログラミングすべき部分に注力する」なのだが、
実際は「リソース管理できない馬鹿でもGC言語ならプログラミングできます」という逆方向に使われている。
オブジェクト指向も「なければできません」の奴が使うから駄目なのであって、
「なくても出来ますが、今回はオブジェクト指向が適切なのでこれを選択します」である限り大丈夫だと思う。
>>690
> クラスのスコープについてもCより改善されている部分なんてないだろ？
一応、Javaはクラス階層を自由に作成でき、親を ParentClass.this で参照できる。
だから手動レキシカルスコープみたいなことは出来る。
(ただし俺はJava使いではないので間違っているかも。なおC++はこれができない)
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
714 ：デフォルトの名無しさん[sage]：2016/06/05(日) 22:02:56.64 ID:D6e8xYJD - >>707
> コードを読まずにすむためには、結果が引数によってのみ確定し副作用を持たないということ
おっと？ということは君は関数型支持派か？
なお言っていることには同意。
>>708
> .net Frameworkの図体のでかさを見てから
あれは切り出しなんて考えられてないからね。
それが組み込み系なら問題になるけど、PCなら結局の所DLL扱いだから1個ロードして終わり。
現実的には大して問題にならない。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
728 ：デフォルトの名無しさん[sage]：2016/06/05(日) 23:18:16.29 ID:D6e8xYJD - >>718
それについては既に指摘したけど、
A. ライブラリが完璧に動くか、
B. オープンソース
であれば解決するから、オブジェクト指向の問題ではないと思う。
ただまあ、オブジェクト指向出身の奴が既に言われているように「隠蔽」を勘違いしていて、
そういうことになりがちなのかどうかは、俺には分からない。
> 純粋関数からなるライブラリのほうがまだマシなんだよ、関数なら相互作用性が引数と戻り値のみに制限されるからね
これはその通りなんだが、どのみちオープンソースじゃないとやりにくいとは思うけど。
内部状態を持っているから、外面から見ると意味不明（脈略不明)な所でバグる危険性を言っている？
さすがにそんなライブラリは捨てるしかないと思うが。
みんなが使っている案牌しか使わないとかで対応するしかない。
ただ確かに、純粋関数のみのライブラリなら、
最悪辿っていって「ライブラリへの入力OK/出力NG」でそれが原因だと断定できる。
内部状態に依る場合、以前のどこかでおかしくなったということだから、ソースがないとどうやっても追い切れないね。
|