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

1 名前：デフォルトの名無しさん mailto:sage [2016/05/30(月) 23:08:42.31 ID:pIEuB3Z3.net] オブジェクト指向に限らず、理由もなく小さく細分化させるのはアホ オブジェクト指向は役割でオブジェクトに分割するものであって 処理で分割するものではない。 563 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 06:29:39.07 ID:YNBwuY3J.net] >>545 オブジェクト指向にデザインパターン持ち出すのは何でなの？ いつから設計思想とプログラム構造がゴッチャになっちゃったの？ オブジェクト指向が、日本に最初に広まったときからだと思う。 その悪影響がずっと続いて現在に至る。 564 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 07:14:25.23 ID:8YdCKwaE.net] 歴史的にはデザインパターンの方が後だと思うけど？ プログラミング実装の分類整理の研究で出て来たのがデザインパターンだよ。 主にデータとプログラムの関係性につての研究だったかな？ プログラミングをブロックを積み上げるみたいに行う方向を目指してた感じ？ なので、デザインパターンやってればオブジェクト指向かというとそうでは無いし オブジェクト指向ならデザインパターンで実装しないといけないというものでも無い。 565 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 07:38:00.95 ID:8YdCKwaE.net] オブジェクト指向は、現実にある対象の複雑さをいかに捉えて、プログラムという別の表現系に写し取るかを研究して出来た考え方。 複雑に見えるものでも一つ一つは単純な機能の積み上げでしかなくて、それぞれを扱う仕組みや動作は幾つかの同じ概念に集約できる。 そうやって単純な機能に分けて考えましょうってのがオブジェクト指向。 現実をいかに単純な似たようなかたまりで捉えるかが主な目的。 ところが運の悪いことにオブジェクト指向の誤った解釈のせいかやたら隠蔽だのといって同じコードをみんなが他人に公開せず自前で用意する事態に陥る始末だった。 そりゃ生産性に逆行してる罠w 566 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 07:54:16.76 ID:8YdCKwaE.net] 朝から連投で申し訳ない。 ここまで読めばオブジェクト指向とデザインパターンは別々の考え方だってのが分かると思うけど でも、デザインパターンがオブジェクト指向の舌足らずになりがちな実装面での問題を解決してくれているって一面もあるんだよね。 567 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:03:17.23 ID:8zGv30iU.net] >>552 自分の言葉で説明できないの? そもそもそこに抜けがあったらデザパタはゴミなんだからね 568 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:16:17.51 ID:kjF/TSSS.net] デザインパターンなんて「実際に作ってる時によく使ってたパターンに名前付けてまとめた、名前付けたおかげで(それを知っている者同士なら)説明が省けて楽」ぐらいの意味しかないだろ 適所で使えば便利だが、何も考えずに乱用すれば逆効果にもなり得る 逆効果なケースしか見ずに全否定する無能も全肯定して乱用する信者も迷惑だ 569 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:33:04.83 ID:PAgdOZpu.net] >>556 いやさ、デザインパターンと共に歩んできてないの？って思ったんだが デザインパターンといえば、有名なのはこの本だよね。 https://en.wikipedia.org/wiki/Design_Patterns 出版は1994年。もちろん研究レベルではもっと前からあるのだろうけど、 それを言ったらオブジェクト指向ももっと前からある。 で、この本自体に書いてあったと思うけど、デザインパターンというのは 巷にあふれる（当時主流となりつつあるオブジェクト指向言語の）設計のパターンをカタログ化したもの。 サンプルコードはこれまた当時主流で勢いもあったJava言語で記述されていた。 （ちなみにRubyは1995年生まれ） 今から勉強しているような人は、デザインパターンがすでにあって、 それを勉強してオブジェクト指向を理解するんだろうけど、 俺とかは逆。オブジェクト指向言語を使っていて、こういう場合は実装しよう？ こうやればうまくいいんじゃね？と考えていたことを、体系化したものがデザインパターン。 デザインパターンは書籍化された当時（1994年ごろ）の問題、つまりオブジェクト指向の問題を 解決するものであり、それよりも前からオブジェクト指向はあったのだから、別々の考えだし、 設計をカタログ化すると言うアイデアは、オブジェクト指向にかぎらないものと、 他の分野にも広がっていったのは、常識なんだが。 570 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:35:22.10 ID:PAgdOZpu.net] >>558 > デザインパターンなんて「実際に作ってる時によく使ってたパターンに名前付けてまとめた、 > 名前付けたおかげで(それを知っている者同士なら)説明が省けて楽」ぐらいの意味しかないだろ 知ってる者にとってはその通り。俺とかデザパタ本を、 やっぱりこんな感じで実装するんだねとか、 こんな抜け道が有るなとか、こうやって解決すればいいのか などと自分の経験と重ねながら読んでた。 でもそういった経験がない人にとっては「よく使っていたパターン」が無いわけだから、 新しい技術を勉強するといった扱いだよ。 571 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:37:21.20 ID:PAgdOZpu.net] >>545 > オブジェクト指向にデザインパターン持ち出すのは何でなの？ > いつから設計思想とプログラム構造がゴッチャになっちゃったの？ 今でこそデザインパターンはオブジェクト指向に限らない概念になったが、 そもそもデザインパターンは当時の問題である 「オブジェクト指向における設計手法」をまとめた本。 だからオブジェクト指向にデザインパターンを持ち出すのは当たり前の話。 572 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:40:19.17 ID:PAgdOZpu.net] ちなみに、オブジェクト指向が普及する前の技術を カタログ化したものは、アルゴリズムと呼ばれていた。 昔は構造と呼ばれるようなレベルに発展しておらず、 処理レベルの話で終わっていたからだ。 573 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 09:45:01.70 ID:PAgdOZpu.net] >>555 > ところが運の悪いことにオブジェクト指向の誤った解釈のせいかやたら隠蔽だのといって同じコードをみんなが他人に公開せず自前で用意する事態に陥る始末だった。 おまえ、オープンソースが正しいオブジェクト指向だとかいいそうだなｗ 隠蔽と言ったって、それはあくまでオブジェクトから見た時の話で、 ソースコードは（オープンソースじゃないだけで） 関係者なら誰でも見れるって、たとえプライベートメソッドであったとしても。 自前で用意するとかいうのは、隠蔽されてるからじゃねーよ。 アホかｗ 574 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 10:22:15.35 ID:vibNsuKz.net] 型システムが貧弱で、抽象化の手段がOOくらいしか無い言語を使うとデザインパターンの出番増えるよ。 575 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11:17:38.97 ID:+OMR19AC.net] 書籍以外で絶賛してる奴を見たことがないし そもそも仕様書や構成図から見えないクラスがいきなり登場してるのも ビジネスだと説明できない 576 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11:27:09.25 ID:eiIG0jy5.net] >>557 オブジェクト指向すら知らない奴に説明するのはめんどくさ〜い。 知らないくせに批判するバカだとなおさら。 オブジェクト指向についてちょっとでも興味があって本を読めば書かれているから。 知らない＝本すら読んでない。 知らない概念を批判するってすごいバカだと思わない？ 577 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11:31:27.48 ID:eiIG0jy5.net] >>559 「サンプルコードはこれまた当時主流で勢いもあったJava言語で記述されていた」 え？え？？ Each pattern also includes code that demonstrates how it may be implemented in object-oriented programming languages like C++ or Smalltalk. って書いてあるけどｗｗｗｗ 読んでないのに語るなよ恥ずかしいからｗｗｗ 578 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11:34:33.87 ID:eiIG0jy5.net] >>562 アルゴリズムとデザインパターンは全然違うぞ。 579 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11:39:37.67 ID:eiIG0jy5.net] >>565 Javaの標準APIのあちこちにデザインパターンが出てくるんだけど…。 評価うんぬんじゃなくて、そこにあるもの。 デザインパターンを理解していないとどうしてそんな構成になっているか理解できない。 580 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 11: ] [ここ壊れてます] 581 名前：46:21.88 ID:L71HvcLp.net mailto: デザパタって優秀なエンジニア達の良い設計に見られる共通項をパターン化したものだよね [] [ここ壊れてます] 582 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 12:00:30.99 ID:+OMR19AC.net] >>570 その「優秀」が怪しいって言ってるの それでも地球は回ってるわけで 583 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 12:03:32.73 ID:eiIG0jy5.net] >>571 >>565みたいなことを言っちゃう奴に理解しろと言っても無理なのはまあ分かる。 素人には難しい。 584 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 12:34:18.99 ID:L71HvcLp.net] >>571 そうか・・・信用できないなら仕方ないね 僕は先人達の英知を無駄にはしないけどね 585 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 12:35:32.63 ID:3IJ+HIal.net] >>571 ある特定の場合に役に立つってだけなので理解できないなら使わないほうがいいし使っても見当違いな使い方してデザパタは使えないとかいう馬鹿が生まれるだけ 586 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 12:37:23.17 ID:8YdCKwaE.net] >>563 実際にオブジェクト指向を曲解して工数がべらぼうになった某携帯電話の共通化プロジェクトってのがあってだなw 587 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:07:21.68 ID:kjF/TSSS.net] 勘違いした馬鹿がやらかした失敗例を元に、他に成功例が多数存在する手法すべてがダメだと断じるのは やらかした馬鹿と同じレベルの馬鹿の思考パターンよな、普通は失敗例と成功例を比較して使い所を見極めるものだと思うんだ >>559 4人のギャング共が最初にデザインパターンをまとめたのはJavaの登場より少し前だよ Javaで書かれたサンプルが多いのは、Java登場が1995年でたまたま注目された時期が被ったに過ぎない 588 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:22:15.21 ID:8zGv30iU.net] 失敗例とか成功例って言うけど 失敗と成功の基準は何なのさ? 589 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:37:31.89 ID:fuiY39en.net] >>546 デザインパターンはオブジェクト指向の欠陥の見本市ですよ 590 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:37:49.19 ID:8YdCKwaE.net] 隠蔽で皆が同じコードを書く羽目になるのは 実装コードの結合度の問題なんで、オブジェクト指向とは直接関係無い話なんだけどな おまいら皆まで言わないと分からないんだな。 部品の共通化が結合度を強めてオブジェクト指向の思想にそぐわないので じゃあみんな同じコードを別々に実装しようとしてそうなったまでさ。 まあ、ここでは部品の共通化って部分が眉唾なんだ。 それは上手く部品のオブジェクト化が出来てないから結合度の高さが問題になるんじゃないのかってね。 本当に共通な所だけが共通化されてないから結合度の高さが問題になるんじゃないかってね。 591 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:43:05.93 ID:eiIG0jy5.net] >>579 「隠蔽」で皆が同じコードを書く羽目になる というスタートからおかしいな。 「隠蔽」をどう定義しているか分からないのと 「隠蔽」するとどうして同じコードを書く羽目になるのかおかしい。 「隠蔽」すれば内部のコードを意識する必要がなくなるんだから自分で書く必要性を減らす方向に働くようにしか思えない。 592 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:48:48.08 ID:fuiY39en.net] オブジェクト指向がいいってやつはセンスがない 自分が何やってるかもわかってねえ奴ばかりだ オブジェクト指向というのは関数の第一引数を贔屓にして 所詮関数の第一引数を元に、メソッドをパッケージング、ディスパッチしているものに過ぎない それがどれだけ抽象化を妨げているのか、バカにはわからないよ カプセル化といくらほざいたところでnullpoがある時点で何も安全じゃないし、 それこそ型推論が完全な言語に比べてどれだけ劣っているかも知っていない 究極的に言えばオブジェクト指向というのはDRY原則を満たすのに明らかに適していない思想であるにもかかわらず (∵関数の第一引数(クラス)に応じて、わざわざ挙動を変更しようとするから クラスを定義するごとに、ToStringのオーバーライドをしないと、ToStringすら使い物にならない はっきり言ってね、ここまで低レベルなことをサポートできない言語なんて他にはないんだけど？ そんなしょうもないことのためにまさか継承すんの？ モジュールを定義するにも、クラス構文でやるとかバカなんじゃねえの？冗長にも程があるわ) 君たちがやってることは、言語的に欠陥があり不自由でしかない言語で、 なんとかDRY原則を守ろうと、こねくり回しているだけ、もちろん保守性においてDRY原則は重要だよ だが俺の考えを言えば多重継承をサポートしないかぎり、DRYは満足できない しかしJavaはその多重継承すら捨てちまった、まあ英断ではあるけどな 結論：ゴミみたいなパラダイムからはゴミみたいなシステムしか産出されない 　　　オブジェクト指向が流行った理由？SunとMSの営業戦略にバカなエンジニアが引っかかってるだけだよ 593 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:52:36.96 ID:eiIG0jy5.net] >>581 すごい熱量を感じる。 ただ、残念なことに「第一引数を贔屓にして 」とか、「関数の第一引数(クラス)に応じて、わざわざ挙動を変更しようとするから」とか理解できない文言が多い。 他の人に伝わる文章で書いて欲しい。 594 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:54:31.58 ID:fuiY39en.net] オブジェクト指向ライブラリを少しでも触れば 微妙な挙動が制御できるかどうかは、そのライブラリ作者が挙動を制御できるように APIを書いているか否かで決まってしまう 内部実装をカプセル化するということは、ライブラリユーザーが 内部の細かい挙動を制御できないということをそのまま意味する なぜわざわざ目隠ししたままプログラミングをしなければいけないのか？ カプセル化によって論理エラーの検出性、テスタビリティが損なわれているにも関わらず オブジェクト指向ではテスト・テストといっている いいか？結局オブジェクト指向技術で話題になる技術ってのは 結局のところ「オブジェクト指向」がサポートしないものなんだよ よくあがる議題：再利用性、テスト、保守性、etc これらが言語のコア、基本的な設計思想として含まれていないからこそ いつまで経っても議論が終わらないし、最終的な答え、共通見解に行き着かないってことぐらい いい加減わかったほうがいいんじゃないのか？ 君たちは単に営業戦略に引っかかってるだけ そしてそれに費やした時間を否定したくないだけ、自分の食い扶持である技術が そんなにヘボいものだと認めたくないだけなんだよ 595 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:58:38.65 ID:eiIG0jy5.net] >>583 Cは評価しているのかな？ Cの標準ライブラリを使うとき、ライブラリの正しさをチェックしてる？ 596 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 13:59:09.84 ID:8zGv30iU.net] >>580 同僚が「隠蔽」してあるって言うから じゃ、テストもやらなくていいの? って聞いたら駄目だって言われた 隠蔽って誰に対して隠蔽してるの? 今まさにここを修正しようとしてる俺に対しても隠蔽してんの? って聞いたらよくわからない返答しか返って来なかった 597 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:00:34.20 ID:8zGv30iU.net] 後で見たら問題点シートからも削除されてて色んな意味で隠蔽されてた 598 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:01:18.81 ID:eiIG0jy5.net] >>585 同僚がどういう意味で「隠蔽」を使ってるかなんて俺には分からんよ。 お前は意味も分からないのに「隠蔽」と言ったのか？ それじゃ会話にならんよ。 599 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:02:27.54 ID:8zGv30iU.net] >>587 俺もわかんないんだよ（笑） 600 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:03:32.47 ID:eiIG0jy5.net] >>588 お前の同僚なんて俺たちは知らないから意味が分からない言葉を使うな。 601 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:08:56.97 ID:fuiY39en.net] >>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)によっても、結果が異なる 聞きたいんだけど、オブジェクトという副作用の塊で何をどれだけテストするの？ 602 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:12:47.82 ID:fuiY39en.net] 然るにまともにテストもできないし動作もさせられないからこそ テストという技術に重きが置かれるのである。 シンタックスエラーに怯え、さらには論理エラー(つまり実現したいロジックそのもののエラー)の検出性も低い シンタックスエラーが多いのは、君たちがアホなんじゃなくてシンタックスがいけてないってことなんだよ 603 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:16:01.21 ID:eiIG0jy5.net] >>590 DogとかCatとかを例に出す時点でどうかと思う。 非現実的な空想で語られても…。 後半は回答をごまかしてるけど、Cの標準ライブラリはテストせずに使ってるだろ？ オブジェクト指向も標準ライブラリはテストしないで使う。 どっちも同じ。 604 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:19:25.59 ID:fuiY39en.net] >>592 標準ライブラリの話か、テストしないね 俺が問題にしているのは外部ライブラリの問題だからな 基本的にオブジェクト指向ってのは外部ライブラリを参照しながらアプリケーション構築するもんでしょ でなきゃ使いもんにならねえしな 外部ライブラリのテストはどうやるの？ 605 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:22:50.15 ID:eiIG0jy5.net] >>593 作成したクラスはテストコード書いてテストする。 606 名前：デフォルトの名無しさん mailto:sage [2016/06/05(日) 14:36:17.04 ID:fuiY39en.net] >>594 内部実装は見ないの？ なぜ見ないのか 1.内部実装は隠蔽されているから 2.内部実装は多量なコードからなり読む気が失せるから 3.外部からの振る舞いが正しければいいので、精査はせずに動かす、動けばいいよ 　だってそれがオブジェクト指向だから 疑問に思うのは、答えが3だとして、その外部ライブラリのパフォーマンスをどのように推定するか？ということだ そしてどの程度テストコードを書けば「自分が思ったような挙動をしている」と確信に至ることができるかだ テストすべき対象はオブジェクトが内包しているプライベート変数の数kに比例するだろう もっと言えば、n個ののオブジェクトの相互作用を考えると爆発的に増えるだろう 最悪なのは、プライベート変数のゲッタは公開されているがセッタは公開されていない場合だ プライベート変数のセッタが公開されていない場合、オブジェクトのテストはどうやってするの？ 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が達成できるのか理解できないのだよ [] [ここ壊れてます]

---

---

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

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