- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
578 ：デフォルトの名無しさん[sage]：2016/06/05(日) 13:37:31.89 ID:fuiY39en - >>546
デザインパターンはオブジェクト指向の欠陥の見本市ですよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
581 ：デフォルトの名無しさん[sage]：2016/06/05(日) 13:48:48.08 ID:fuiY39en - オブジェクト指向がいいってやつはセンスがない
自分が何やってるかもわかってねえ奴ばかりだ
オブジェクト指向というのは関数の第一引数を贔屓にして
所詮関数の第一引数を元に、メソッドをパッケージング、ディスパッチしているものに過ぎない
それがどれだけ抽象化を妨げているのか、バカにはわからないよ
カプセル化といくらほざいたところでnullpoがある時点で何も安全じゃないし、
それこそ型推論が完全な言語に比べてどれだけ劣っているかも知っていない
究極的に言えばオブジェクト指向というのはDRY原則を満たすのに明らかに適していない思想であるにもかかわらず
(∵関数の第一引数(クラス)に応じて、わざわざ挙動を変更しようとするから
クラスを定義するごとに、ToStringのオーバーライドをしないと、ToStringすら使い物にならない
はっきり言ってね、ここまで低レベルなことをサポートできない言語なんて他にはないんだけど？
そんなしょうもないことのためにまさか継承すんの？
モジュールを定義するにも、クラス構文でやるとかバカなんじゃねえの？冗長にも程があるわ)
君たちがやってることは、言語的に欠陥があり不自由でしかない言語で、
なんとかDRY原則を守ろうと、こねくり回しているだけ、もちろん保守性においてDRY原則は重要だよ
だが俺の考えを言えば多重継承をサポートしないかぎり、DRYは満足できない
しかしJavaはその多重継承すら捨てちまった、まあ英断ではあるけどな
結論：ゴミみたいなパラダイムからはゴミみたいなシステムしか産出されない
オブジェクト指向が流行った理由？SunとMSの営業戦略にバカなエンジニアが引っかかってるだけだよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
583 ：デフォルトの名無しさん[sage]：2016/06/05(日) 13:54:31.58 ID:fuiY39en - オブジェクト指向ライブラリを少しでも触れば
微妙な挙動が制御できるかどうかは、そのライブラリ作者が挙動を制御できるように
APIを書いているか否かで決まってしまう
内部実装をカプセル化するということは、ライブラリユーザーが
内部の細かい挙動を制御できないということをそのまま意味する
なぜわざわざ目隠ししたままプログラミングをしなければいけないのか？
カプセル化によって論理エラーの検出性、テスタビリティが損なわれているにも関わらず
オブジェクト指向ではテスト・テストといっている
いいか？結局オブジェクト指向技術で話題になる技術ってのは
結局のところ「オブジェクト指向」がサポートしないものなんだよ
よくあがる議題：再利用性、テスト、保守性、etc
これらが言語のコア、基本的な設計思想として含まれていないからこそ
いつまで経っても議論が終わらないし、最終的な答え、共通見解に行き着かないってことぐらい
いい加減わかったほうがいいんじゃないのか？
君たちは単に営業戦略に引っかかってるだけ
そしてそれに費やした時間を否定したくないだけ、自分の食い扶持である技術が
そんなにヘボいものだと認めたくないだけなんだよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
590 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:08:56.97 ID:fuiY39en - >>582
Dog.Walk(5) オブジェクト指向言語
Walk(Dog,5) C、関数型
オブジェクト指向信者は
Dog.Walk(5)のほうがシンタックス的にいけていると言うのだ
これがもしFightという関数になったとき
Dog.Fight(Cat);
Cat.Fight(Dog);
Fight(Dog,Cat);
これでいいたいことはうっすらわかりましたかね？
WalkのコンテクストではDogを主語として扱うことに意味はあるのかもしれない。
しかしFightのコンテクストではDogあるいはCatを主語として扱うことに対する深い意味はないだろう。
言うなれば、主語を要しない文脈においても、主語を必要とする。
これを回避する方法はクラス・メソッドを使うという方法だ、
しかしそれは結局のところオブジェクト指向を殺している、
オブジェクト指向信者がバカにしているstaticおじさんの手法に過ぎない
こんな単純なことすら穏便に解決できず、議論になりうる言語で一体何を設計しろと？
俺らは間違いなく
Walk(animal,length)という関数を設計しFight(animal,animal)という関数を設計する
さらに言えばFight(animal,animal.animal,・・・)といった可変長引数の関数を設計する
そちらのほうが汎用性が高いのは自明だからだ
>>584
Cのライブラリをテストするのとオブジェクト指向ライブラリをテストするのでは大きく違うだろ
Cは所詮プリミティブを基本としているからこそ、簡単に関数の挙動をテストできるのに対して
Javaはオブジェクトを基本にしているからこそ、わざわざモックオブジェクトを定義してやって
食わせてやらないと、簡単に構文エラーをはくだろ
さらに言えばオブジェクトがカプセル化している状態(state)によっても、結果が異なる
聞きたいんだけど、オブジェクトという副作用の塊で何をどれだけテストするの？
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
591 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:12:47.82 ID:fuiY39en - 然るにまともにテストもできないし動作もさせられないからこそ
テストという技術に重きが置かれるのである。
シンタックスエラーに怯え、さらには論理エラー(つまり実現したいロジックそのもののエラー)の検出性も低い
シンタックスエラーが多いのは、君たちがアホなんじゃなくてシンタックスがいけてないってことなんだよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
593 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:19:25.59 ID:fuiY39en - >>592
標準ライブラリの話か、テストしないね
俺が問題にしているのは外部ライブラリの問題だからな
基本的にオブジェクト指向ってのは外部ライブラリを参照しながらアプリケーション構築するもんでしょ
でなきゃ使いもんにならねえしな
外部ライブラリのテストはどうやるの？
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
595 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:36:17.04 ID:fuiY39en - >>594
内部実装は見ないの？
なぜ見ないのか
1.内部実装は隠蔽されているから
2.内部実装は多量なコードからなり読む気が失せるから
3.外部からの振る舞いが正しければいいので、精査はせずに動かす、動けばいいよ
だってそれがオブジェクト指向だから
疑問に思うのは、答えが3だとして、その外部ライブラリのパフォーマンスをどのように推定するか？ということだ
そしてどの程度テストコードを書けば「自分が思ったような挙動をしている」と確信に至ることができるかだ
テストすべき対象はオブジェクトが内包しているプライベート変数の数kに比例するだろう
もっと言えば、n個ののオブジェクトの相互作用を考えると爆発的に増えるだろう
最悪なのは、プライベート変数のゲッタは公開されているがセッタは公開されていない場合だ
プライベート変数のセッタが公開されていない場合、オブジェクトのテストはどうやってするの？
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
596 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:38:23.48 ID:fuiY39en - というよりオブジェクト指向のファクトリパターンを使われたら
例えばオブジェクトの単純なコンストラクタも隠蔽されているよね
このプライベート変数が状態Aから状態Bに遷移する条件が
ドキュメントに記されていないってこともあるわけだが、
いったいどうやってテストするんだろうなあ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
598 ：デフォルトの名無しさん[sage]：2016/06/05(日) 14:48:46.08 ID:fuiY39en - >>597
ネットワークIOに関わるライブラリで、
ネットワークストリーム(websocket)をキャプチャするライブラリである。
このライブラリを連続して稼働させたいが、
ガベージコレクトしようにも、ネットワークストリームのデータは単方向リストで構成されており、
単純に言えば長期稼働によりOutOfMemoryの可能性がある
私はこの挙動に満足できないので、プロクシパターンでも使って改変しようと思っていたのだが
オブジェクトのセッタ及びゲッタが満足に公開されておらず、そうすることもできない
これのどこに再利用性が？
この部分的な挙動以外の全てにおいて俺は満足しているが、
長期稼働を前提としない設計のおかげで、全てが台無しになっている
俺はどうすれば俺が期待するように稼働させられるかを知っているが、
たったこの一点だけでこのライブラリは「使えない」んだが
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
601 ：デフォルトの名無しさん[sage]：2016/06/05(日) 15:08:36.99 ID:fuiY39en - このライブラリは複数の構成要素からなっている
httpのキャプチャ この機能は使える
データストリームのencrypt decrypt この機能も使える
パケットのファイルへの書き出し この機能も使える
websocketのキャプチャ この機能も使える
ただし、データ構造は単方向リストで実装されている は？ は？
これはライブラリ作者が悪いの？俺が悪いの？
結局オブジェクト指向というのは、適切に全ての情報を開示できなきゃ成り立たないし
ライブラリ作者と俺の考えが少しでも違ったら、場合によってはその全てがダメになっちまう
言っておくがライブラリ作者の考え方は間違いではないよ、もっとも汎用性のある構造はリストだからな
キューを使ったりすると、そのデータストリームの速度によっては、キューからデータがあふれる事もありえる
もっとも汎用的な解がリストだ、そしてそれは俺の求めるものじゃない
なぜこの機能が別々のパッケージとして切り出せないのか？
オブジェクト指向は巨大なライブラリを構築するための概念らしいが、
さて、実際のところは小さなライブラリにできない理由があるんだろうね
>>599
もしライブラリが関数であれば、その当該関数のみを自作することができる
構造体であったとしても構造体がどのようなデータから構成されているかを見ることは出来る
ところがオブジェクト指向であると、まずオブジェクトを構成して
プライベート変数をセットして(時には自由にセットすらさせてもらえなくて)
さらにはオブジェクトがどのようなデータから成っているかは「ドキュメントが公開されていないかぎり知ることはできない」
>>600
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
Cプログラムでメモリリークなんて聞いたことがあるだろうか。今では、メモリリークの発見が大産業になってしまった。
全部見つけるのは費用がかかりすぎるから、たいていの会社はあきらめて、山ほどリークのあるプログラムを出荷してしまう。
I： ツールはあるけど…。 S： そのツールも、ほとんどは C++ で書かれているんだよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
605 ：デフォルトの名無しさん[sage]：2016/06/05(日) 15:21:10.78 ID:fuiY39en - 結局ライブラリを改変するためにはハッキングじみたことをするしかない
それならば、自分で1から書いたほうが早い
なぜそんなマネをしないといけないのかというと、
オブジェクトがプライベート変数という状態を隠しもっており、
それが自分自身の思うように統御できないように構成されているからだ
さらにはそのオブジェクトはパッケージを横断しており、
だからパッケージの一部分のみを切り出して小さなパッケージとすることもできない
これは事実上のグローバル変数だ
もしencryptやdecryptの部分だけを切り出して公開してくれていればよかったのに
でもおそらくDRY原則とやらがそれを妨げるのだろう
もっとも効率よくDRY原則を行うにはどうすればよいのか？それはグローバル変数を使うということだ
グローバル変数を用いればもっとも効率よく状態を共有することができる
さらに言えばファクトリにオブジェクト生成を投げたりして
単純なオブジェクト生成すら封じられている場合もよくある
>>602
もし単純な関数であるならば、その引数と返り値だけを気にしていればよい、それのみをプロクシすればよい
もしその部分さえ隠蔽していたならば、ライブラリとして一切利用できず、誰かに不平を言われることもない
オブジェクト指向は本来ユーザが定義すべき状態すらも隠蔽するので、確かに手軽に利用できる
しかしライブラリ作者が規定した挙動がユーザの求めている挙動と同一であるという保証はない。
だからライブラリをしばらく使った後に捨てることになる 「やっぱあのライブラリイケてねえわ」
果たしてCや関数型のライブラリでこんな事になり得るだろうか？
1.最初から使えないか、2.思ったより遅いか、3.何度でも使える
この3つにしかならないだろう。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
606 ：デフォルトの名無しさん[sage]：2016/06/05(日) 15:25:24.73 ID:fuiY39en - オブジェクト指向というのは、
大きなシステム、大きなパッケージを作るための思想ではなく
小さなシステム、小さなパッケージを作らせてもらえない思想のことである
UNIX思想の対極に存在するものであり、つまるところはwebの思想にも反するものである
言語のコアとライブラリを編みこむようにプログラムを構築できず
巨大なビルディングブロックを積み上げて、施工誤差に耐えながらも、
出来上がった行数を見てこんな巨大なものを作り上げたと悦に入る
もちろん成果物も巨大であるからこそ、他人には保守することができない
このオブジェクトがどのような状態、変数からなり、どのオブジェクトから継承されていて、
何をしていいのか、何をしてはいけないのかなどどこにも書かれてはいない
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
628 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:09:55.26 ID:fuiY39en - >>623
キミはコンテクストが必要な場面と不要な場面すら区別がついてないだろう？
いつ、クラスメソッドにしていつインスタンスメソッドとして実装すべきか明確な設計指針を持っているか？
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
631 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:18:56.22 ID:fuiY39en - 理想的なオブジェクト指向、正しいオブジェクト指向など存在しないだろ
欠点を指摘したら、理想的なオブジェクト指向設計であったならば、この問題は回避されたという
だがその欠点を克服するために標準的なオブジェクト指向言語がどの程度のコード量を追加で要求し
あるいはパフォーマンス上でのオーバーヘッドがどれだけ発生するかなんて知ったことではないという
なぜならば オブジェクト指向とは実装を隠蔽し、外部的からみた状況がうまくカプセル化されていればいいのだから
もっともそんなことは単純な関数にだって出来るということは、誰も指摘しないし理解もできない
完全なオブジェクト指向であればという言葉は
単なるないものねだりを象徴する言葉で、言語が正しい設計を一切サポートせずに
むしろ誤った方法を選ばせているという自白に過ぎない
だいたい、システムを設計するのにそんな超自然的なセンスなど必要ない
計算すべき対象が、有限のメモリ空間、有限の時間で解ければいいだけだ
やりとりの美しさや汎用性というものは存在するが、
オブジェクト指向という概念はその根底からして汎用的ではありえない
クラスを定義するごとにメソッドの定義を要求されるというのはどこも汎用的な考えではない
そしてそれを回避するために継承を行うというのも汎用的ではない
汎用性という概念でいうならば、
クラスオブジェクトは、構造体、あるいはハッシュテーブルに対して1mmも勝てる部分は存在しない
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
636 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:38:44.12 ID:fuiY39en - >>632
ごめんね、ちゃんと読み取れる人だけには意図が伝わるように書いたつもりなんだけどね
こう言えばわかるよね
オブジェクト指向のパッケージングが単一のクラスではなく複数のクラスからなる
比較的大きいモノリシックなものとなっているのは、オブジェクトが隠れたグローバル変数として機能しているから
DRY原則に忠実になるためには、クラス定義もまた一つでなければならない
もしこれがクラスではなく関数モジュールであったとしたならどうだろうか？
その関数モジュールのみを一つのパッケージとして切り出すことに何の問題もないだろう。
しかしクラスというのはメソッド定義だけではなくデータ・タイプの定義も兼ねている。
このデータタイプ定義とメソッド定義の重複を許すならば、
小さなパッケージとして、ライブラリを切り出すことができるだろう
でもオブジェクト指向ライブラリではそんなことはしないよな
君たちの言葉で言えば、オブジェクト指向というのは凝集性が低い
キミが言っている間違ったコードやグローバル変数の排除というのは
Cでいうところのモジュールで制御できる
それはオブジェクト指向の問題ではなくスコープ制御の問題だ
グローバル変数を無くすという意味合いではレキシカルスコープをサポートしていれば十分なのに
private修飾子を使うことにしたことで、オブジェクト指向はテスタビリティを捨てたんだよ
間違ったコードならデバッグすればいい、事実デバッグできる
だが間違った設計指針で突っ切ればそれじゃ済まないのは痛いほど理解しているよな？
何年経っても結合テストで悲鳴を上げ続ければいいんじゃねえの？
単体テストすら簡単にはできねえのにな
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
637 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:40:17.09 ID:fuiY39en - 間違ったコードを書かないという観点で言えば
関数型言語のほうがよほどオブジェクト指向よりも安全性をサポートしている
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
640 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:53:40.94 ID:fuiY39en - オブジェクト指向の問題点は
Cよりも後発であるにも関わらず、より問題やシンタックスを複雑にしていて
それもコード上で解決する問題から、設計上に関わる問題へと進化させている
どれだけ俺達が頑張ろうとも機能を実現するのはアルゴリズムで有るにも関わらず
カプセル化の海にアルゴリズムを沈め、不可視とした
もっともプログラマが検討すべきデータ構造とアルゴリズムという観点をカプセル化の海に沈めた
そしてもっとも重要ではないテクニカルなシンタックスについての井戸端会議を始めだした
オブジェクト指向ユーザーは(Cに比べて)保守性や安全性が優れているというが、本当にそうだろうか？
Cのポインタは確かに不要な機能かもしれないが、モジュール機能があれば最低限のスコープ制御はできる。
オブジェクト指向は名前をどのようにつけるかを気にしている。
もしそうでないならば、何かを継承する必要もないし、ポリモーフィズムも必要ない
オブジェクト指向は確かに高尚な概念だ、しかしそれで創りだされるプロダクトがゴミでは意味が無いだろう
オブジェクト指向をフル活用してどんなプログラムが作るかというと、それこそ電卓計算機以上のものは作れないし、作ってもいないだろ。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
641 ：デフォルトの名無しさん[sage]：2016/06/05(日) 18:56:27.86 ID:fuiY39en - 僕らはそんな電卓計算機、あるいはタイプマッチングディスパッチャなんて
設計無しで書けますから
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
650 ：デフォルトの名無しさん[sage]：2016/06/05(日) 19:56:32.50 ID:fuiY39en - >>643
Cでグローバル変数（が増える）が嫌な理由は、
1.大域的にその変数にアクセスできることが嫌であること
2.グローバル変数のおかげでモジュールの分割が滞ること
javaでクラス定義（が増える）のが嫌な理由は、
1.大域的にクラスをコンストラクトできるということが嫌であるということ
事実、そのクラスに無関係なコンテクストでもコンストラクトできる
そんなことはしないとキミは言うかも知れないが、それならCのグローバル変数だって大差ないね、俺もそんなことはしない
これは事実上のパッケージ内でのグローバルオブジェクトだ
そしてそうであるがために、必要以上に脳みそを使わざるを得ない
このオブジェクトは、あのオブジェクトと関係がある、そしてそのオブジェクトとは関係がないってね
2.クラス定義のおかげで、パッケージ分割が滞ること
クラスが増えるということはクラスの依存性そのものが増えるということだ、
もしクラスAがBにクラスBがCにクラスCがDに依存している場合、
そのパッケージはクラスA,B,C,Dを内包するものになるだろう。
そのうちBはFやGに依存するようになり DはV W X Y Zに依存するようになるだろう。
そうしてパッケージはモノリシックなものになっていくし、
事実オブジェクト指向ライブラリは俺の知る限り関数型のライブラリよりも一つ一つの粒度が大きい。
そしてそのライブラリの使い方を調べることほど面倒なことはない
パッケージ分割されていないからこそ、オブジェクトの関係性や依存関係を整理することが苦痛で、複雑性が増す
なぜこんなことになるのかというとオブジェクトがデータ・タイプとメソッド定義を混在させているからに他ならない
もしオブジェクトがメソッドをもたないのであれば、オブジェクト同士の依存性やヒエラルキーは発生しない
俺も正直なぜデータタイプとメソッドを混在させておきながらSRPやDRYが達成できるのか理解できないのだよ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
655 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:13:12.23 ID:fuiY39en - 俺は十分説明したと思う
オブジェクト指向はCよりも遥かに複雑な依存関係を作り出せるし
テストはしにくいし、よって論理エラーを補足しにくく、結合テストで悲鳴を上げる事になり、
メソッドとデータ・タイプが分離されていないおかげで、クラス構造の設計（という名のお絵かき）は大変になるわ、
デザインパターンとかいう言語仕様の欠陥の見本市に付き合わされるわ
ToStringすらオーバーライドしないと使いものにならないし
オブジェクトを主語としたおかげで汎用性はないし、
クラス・メソッド(関数)は用意されているもののおまけ程度で、関数型には程遠い使い勝手で
単純なことをするには必要以上に複雑で、複雑なことをするにはなおいっそう複雑で
その主張がわかってくれればいいよ
結局Cが抱えていた問題を解決したといって、確かにその問題は解決できたのかもしれないが、
Cよりも規模の大きい、厄介な問題を引き連れていることに気が付かないようではな
>>651
Fighter.Fight(Slime) →たたかう
Fighter.Fight(metalSlime) →聖水
まずこんな動作させたら、このメソッドを使うユーザープログラマが混乱するよね
百歩譲ってそれでいいとしよう、聖水を使うのは、ライブラリプログラマの配慮であり慈悲であると
問題はこれはオブジェクト指向の問題ではないってことだ
この動作をオブジェクト指向で実現するなら、
FighterクラスのFightメソッドの中にif文をずらずらと並べて
if(slime) {"slash"}else if (metalSlime) {"use holywalter"});とするしかない。
でもってmagicianクラスのFightメソッドには
if(slime) {"Fire"} else if (Flame) {"Blizzard"} ...
なぜならばオブジェクト指向言語はマルチメソッドという概念をサポートしていないからだ
キミの指摘はオブジェクト指向がダメな部分を改めてあげつらっているに過ぎない
ちなみに俺ならまずは2次元配列を使ってそれを実装することを考えるけどな
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
661 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:30:40.15 ID:fuiY39en - >>657
Fighter.OptimalAct()ってことね
で、その知性をオブジェクト指向で表現するにはどうするのかってことだが、
例えばFighter.monsterknowlegde というプライベート変数で
それぞれのモンスターに対する知識ハッシュテーブルを定義してやればキミのやりたいことは出来る。
さらに言えばmagicianにも同じ変数が必要だから
これはBattleClassというクラスから継承するのがおおよそ正しいオブジェクト指向だと考えられる
そしてそれがオブジェクト指向的に正しい解であると同時に、俺がやらない方法でも有る
>>658
真面目にやればそうだろうね、マルチメソッドも結局はif文みたいなもんだし
というよりディスパッチ自体が実質if文だからね
まあ俺は、2次元の関数配列を書いて処理しますけどね
オブジェクト指向に従うと、Fighterに対して一次元のハッシュテーブル、というふうにしないといけない
さらには継承を使わないといけない
もっとも、Fighterがwizのように何人も生成できて、キャラクター生成の度に、monsterknowledgeを初期化して生成する
っていうのはいかにもオブジェクトらしいけどな
まあ、結局2次元の配列で処理できるんですが
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
666 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:39:35.10 ID:fuiY39en - 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はあまりにも無力だろ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
672 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:46:45.55 ID:fuiY39en - Javaを使ってRPGを記述しようとしても一切体系的に記述できないし、
2次元の関数テーブルのほうが、明らかにデータの凝集度としても上なんだよなあ
オブジェクト指向の教義を信じて
それぞれの役割に応じて最適行動を散らばらせても待ってるのは悲劇だけだから
例えばだけど、Flameに対する各役割の最適行動はなんですかという疑問を持ったとしよう。
オブジェクト指向だと、それぞれの役割に対して、いちいち聞いて回らないといけなくなるよね
Fighter.OptimalAct() Magician.OptimalAct() Thief ・・・
ここで、BattleClassの必要性は確定しちゃうよね
Foreachでぶん回すことを考えると、各職業を集約してまとめあげるようなスーパークラスあるいはインターフェースが必要になる
もちろん我々はそんなことをしなくてもFの行を横に見ていくだけでわかるのにね
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
680 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:57:11.65 ID:fuiY39en - >>668
オブジェクト指向らしいとはいったけど別に必須じゃないんだよな
新しいキャラクターを創設したいなら、そのキャラクターに対する行を追加すればいいだけだから
普通に関数と構造体(レコード)で処理できる
単にデータ・タイピングの問題なので
>>671
Javaが第一級関数をサポートしてればよかったのにな
少なくとも継承、カプセル化、ポリモーフィズムはこういう問題の解決には無力だぞ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
683 ：デフォルトの名無しさん[sage]：2016/06/05(日) 20:59:52.24 ID:fuiY39en - >>678
俺は別にC使いじゃないからな
Cに比べてオブジェクト指向は優れているという割には
オブジェクト指向は多くの問題を引き連れていませんか？という当て馬として使ってる
最低限のシンタックスとセマンティクスは知ってるつもりだけど
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
690 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:14:39.32 ID:fuiY39en - >>686
モンスターの例は勝手に誰かが出題したのに答えただけなんだが
メモリーリークに関してはそして「オブジェクト指向言語である」C++に比べて
Cはメモリーリークしうる要素が少なすぎるんだが？
javaがメモリーリークしにくいのはガベコレを積んでるだけであってオブジェクト指向言語の長所ではないよな
あと下手な実装してたら、メモリーリークに対して一切手をだすことができないのも先述の通り
クラスのスコープについてもCより改善されている部分なんてないだろ？
アクセス修飾子は、レキシカルスコープがあれば不要であることは指摘した。
さらにアクセス修飾子がテスタビリティを損ねていることも指摘した。もう終わったことなんだけど
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
692 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:16:54.20 ID:fuiY39en - 例えば、debug時にのみpublicにして、release時にはprivateにするといった
アクセス修飾子はjavaには定義されてないよね
IDEやライブラリによってはそういうのをサポートしてるのもたぶんあるだろうけどね
全てがprivateってあまりにもテストやりにくいんだけど、そのことわかってんのかな
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
694 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:20:50.73 ID:fuiY39en - >>693
クラスは増えても問題無いって言うけど
クラスを作るか作らないかってのもオブジェクト指向設計の一つのキモでありよく議論の対象になる部分だろ
アクセス性については散々言ってる通り、アクセス性を決めるのはスコープで事足りている
過剰なprivateはテストの邪魔にしかならない
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
697 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:27:11.77 ID:fuiY39en - >>696
アクセス性を制御できることがキミにとってその解決になるのか？
publicをinternalにしたところで、パッケージがモノリシックなら、何の意味もなく
そのパッケージ内でグローバル変数と同様に振る舞うということはわかるよね？
キミはpackageAからpackage Bの Class bが見えなくなれば、複雑性は解消されたと考えるのか？
bの中にClassが50個ほど並んでいても同じことが言えるのかな？
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
700 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:32:00.11 ID:fuiY39en - >>699
「モノリシック」は一枚板という意味で、ソフトウェア的には、全体が1つのモジュールでできていて、分割されていないことを意味する。
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
707 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:49:17.07 ID:fuiY39en - >>703
複雑性を解消するための方法は、モジュールを小さく分けて
内部を見なくていい状態を作り上げていくことだ。
お前だって普通に開発してるときに汎用関数の中のコードまで読まないだろ？
そこにどんなに複雑なソート処理が実装されていたとしてもだ。
もちろんそれが理想だ、
そしてそれを実現する唯一の方法は、オブジェクト指向を捨てることだ
コードを読まずにすむためには、結果が引数によってのみ確定し副作用を持たないということ
つまり純粋関数であるということが、真の意味でのカプセル化だということだ
オブジェクトは状態を内包している、だからこそのオブジェクト指向であり
そうでないならば、staticオブジェクトで表現しても支障は起きない
プログラマの仕事とは究極的に言えば状態を管理することにある
それを隠蔽するような言語では、話にならないことぐらいわかると思うんだが
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
708 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:51:38.09 ID:fuiY39en - データ構造を隠蔽してメソッドだけを公開するということが
どれだけオブジェクト内の動きをプログラマが把握することに手を焼かせられることなのか理解してからきてくださいね
.net Frameworkの図体のでかさを見てから
モノリシックなライブラリは設計が悪いと言ってくださいね
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
712 ：デフォルトの名無しさん[sage]：2016/06/05(日) 21:58:06.65 ID:fuiY39en - ?設計が悪いオブジェクト指向システムを前提にしている。
○オブジェクト指向システムは設計が悪い、だってオブジェクト指向は設計者を手助けしてくれないから
だからできの悪いライブラリが止まらず、間違った設計思想を信じるにわか設計者が後を絶たない
だってどこをprivateにしてどこをpublicにして、どんなインターフェースを定義してというふうに
それこそまともなスコープ制御を持った言語や、動的言語なら一切気にすることがない部分を
いつまで経ってもちまちま考えさせられているから
最後の極めつけは、「僕はデザインパターンも勉強したし、オブジェクト指向設計も勉強したのだから
これが役に立たないはずがない、だって僕はこれに何年も時間を使ってしまった」という元を取りたがる考え方だ
俺がおすすめするオブジェクト指向設計の本はエリック・エヴァンスのドメイン駆動設計、これだけ
これは他の言語に映っても使える示唆がある
あとSOLID原則ってあるとおもうけど、あれ関数型のほうがよほど簡単に実現できるから
ボブおじさんはその点でセンスはいいんだろうなって思うけど、それをオブジェクト指向でやろうとしたことが最高にセンスないよな
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
716 ：デフォルトの名無しさん[sage]：2016/06/05(日) 22:06:24.35 ID:fuiY39en - rubyをオブジェクト指向言語として使ってる奴なんているの？
それをいったらpythonもオブジェクト指向言語だしJSもオブジェクト指向言語なんだけど
さらにいえばScalaもそうだよな
さらに言えばCommonLispですらCLOSがあるからオブジェクト指向言語なんだけど
あんまり詳しくないけどCLOSのほうがJavaより出来がよさそうなのがマジで笑えるんだけど
ゲッタやセッタ書かなくても確か自動生成されるんだろ
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
718 ：デフォルトの名無しさん[sage]：2016/06/05(日) 22:13:25.73 ID:fuiY39en - >>715
そうだね、ライブラリが利用しやすい言語ならライブラリを使ったほうがいいよね
でも俺がオブジェクト指向を批判する理由は、このスレでとっくに書いているんだよね
ライブラリが自分が想定している挙動と異なった場合、自分で手直しすることが不可能
俺はそこまでハッカーじゃないからね
レゴのブロックのように構築できるライブラリもあれば、そうでないライブラリもあるわけで
ライブラリ製作者が定義したオブジェクトまみれのライブラリより
純粋関数からなるライブラリのほうがまだマシなんだよ、関数なら相互作用性が引数と戻り値のみに制限されるからね
マクロとかになると読むのが多少は厄介になるけど
rubyがrailsの助けを受けたとあるが、railsがrubyを選択したのは楽にかけるからということだろう
短く書けない言語というのは、結局のところ読むのも大変でライブラリから吸収できる量というのも少なくなってしまう
javaでrailsが生まれなかったのは、まあそういうことなんだろうな
ライブラリを使う能力も重要だが、ライブラリのスキマを縫うグルーコードをかく技術、かけるパラダイムかってのが
全てに関わってくる
|
- オブジェクト指向システムの設計 170 [無断転載禁止]©2ch.net
720 ：デフォルトの名無しさん[sage]：2016/06/05(日) 22:15:03.77 ID:fuiY39en - え？rubyはlispのパクリだって聞いてるけど？
|