オブジェクト指向ってクソかよPart5
■ このスレッドは過去ログ倉庫に格納されています
無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。 単なるマッチポンプ。 カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、 オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、 オブジェクトの実際の型を隠蔽したりすることをいう。 偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。 一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として 「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。 オブジェクト指向の発案者であるアラン・ケイもコーディング規約(頭文字にアンダースコアを付けるなどの命名規則)で 縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」 という概念はない。 https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 前前前前スレ オブジェクト指向ってクソじゃね? https://mevius.5ch.net/test/read.cgi/tech/1535085129/ 前前前スレ オブジェクト指向ってクソじゃねぇよ? Part2 https://mevius.5ch.net/test/read.cgi/tech/1539872441/ 前前スレ オブジェクト指向ってクソじゃねぇかよPart3 https://mevius.5ch.net/test/read.cgi/tech/1542884872/ 前スレ オブジェクト指向ってクソじゃねぇかよPart4 https://mevius.5ch.net/test/read.cgi/tech/1556462315/ スレでさんざ書いてきたことだし うえの議論のずれっぷり見ても十分理由だろう 弊社にもいたよ、独特のオブジェクト指向論を持ち、 変な理屈こねて、これぞオブジェクト指向だと自説を押し付けたり 他人を批判したりして、チームの仕事を停滞させ そのくせ、プログラムの開発をしてもらうとロクなコードが書けず、進捗が遅くて、 継承とメソッド呼び出しスパゲティーでバグだらけ 直る見込みがないので悪いけど間接部に移動してもらった。 いや、自分はさっきから議論がズレすぎてなんでOOPがクソ扱いされるのか未だに理解できないのだが。 台風が来た(わかる)→台風で死者が出た(わかる)→首相が悪い(は?) 並みに飛躍しすぎて意味不明なのだが。 どさくさに紛れてOOPをクソと結論付けるのはやめろよー。 >>150 うん、それはお気の毒に。 まぁ、そういう人はいるよね。このスレにも。 でも、それを根拠にOOPをクソ扱いするのは違うと思うんだ。 そもそも、そいつ自体がOOP理解しているか怪しいし。 いままでのレス読んで理解できないのは 読解力や個人の能力の問題。 それこそしらんがな >>152 そだな、そういう痛々しい人の問題は別にしても オブジェクトにどのような害があり、それを使ってソフトウエアのアーキテクチャ・構造の表現がしにくくて 大規模で複雑なシステムの構築上、人間が理解しにくいものが出来てしまうか さんざ書いてきたが、読んでねーか、まともなあたまをもってねーか、、、 痛々しい人の問題はその上にかぶって存在し、オブジェクトの 局所的な一見便利そうで利点に見えるが ある程度の規模の構造上 逆に欠点となる方法の押し売りなんだよ オブジェクトとはなにか、どういうやり方こそオブジェクトとして正しいか 意見の応酬などは論点じゃないんだけれど、 そういう論点好きは、痛々しい人とほぼ同類 コメントとコードであっても二重管理になって 同期が取れなくてトラブルのもとになるというのに 設計書とコメントとコードの三重管理とか気が狂いそうw >>153 今までのってどこの部分? 安価つけてほしいね。 ついでに、あなたは本当にOOPを理解している上で批判しているのかい? 聞いた話では他の人が書いた自称OOPコードを見てクソだと思ったのでしょ? 是非、そのクソだと思う部分を教えてほしいね。 >>133 みたいにコード書いてもいいんだよ?133はスルーされちゃったけど。 たとえば、 カプセル化とは何かの解釈の幅によらず、 カプセル化によるスコープやアクセスの管理は、ぱっと見とても有効に見えるが 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、 規模に応じ急激に複雑さをまして (レキシカなスコープ、エクステント管理に対し) 人間が管理把握しにくくなる因子であることは、 一定の理解を得られているはずだが そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから 他人を叩きのめすのに使えばいいんだよ 仕組みはどうあれ俺が気に入らないのでテメーは死刑だ >>156 「OOPを理解している上」 そうやってすぐ OOPの解釈議論に論点をずらそうとする… 痛々しいなあ >>158 科学的技術的な話ではないので ある意味そういうことだとおもうよ。 >>159 これが先に目についたのでこっちから答えるが、当然だろ。 スレタイは オブジェクト指向はクソかよ だ。 オブジェクト指向をまったく理解してないのにクソ呼ばわりはないだろ。 その大前提を崩すと、お前が非難しているのはOOPじゃなくてstaticおじさんの可能性すらあるんだよ? 痛々しい以前に論外過ぎるだろ。 正確な定義は理解していなかったとしても、自分ではこれがオブジェクト指向だという考えくらい持てよ。 まったく理解せず色々言うのはよくないが、 オブジェクト指向をまったく理解してないやつなんて そもそもいるのかよw それにOOP解釈によらずCでも頑張ってOOP的な書き方をしても >>157 のような問題はでるんだぜ 細かく派生した、場合によって人さまざまなOOPの解釈の違いによらない 欠点があるといってんだが、読み取れないのか。。。 オブジェクト指向のメリットを定義してよ って言うといつも逃げ出すじゃん 方法論にずれちゃうんだよね 良くて局所的なメリット論 >>158 > そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから どのような数字を上げれば良いのですか? オブジェクト指向以外で、数字を上げたメリット説明してるものを 参考として教えて下さい。 >>163 管理しやすくなるってメリット言っても 数字言えって言って逃げてるじゃんw だからオブジェクト指向は俺の股間に付いているってことなのさ! >>169 そうか、それでOOPはクソなんだ。 納得 >>163 逃げた覚えはないけどな。 まぁ、いいや。俺の意見だが。 思い付くメリットを列挙するとこんな感じだ。 (1)責務分割を行うため各コードの役割が明確になる。 →共同開発時、作業分担がしやすくなる。 →不具合が発生したとき、どこが悪いのか明確になる (2)必要な数だけオブジェクトを複製できる。 →例えば...組み込み開発だが、USBオブジェクトがあったとして、USBポートを一つから四つに増やしたいとき Usb usb[] = new Usb()[4]; といった記述で増やせる。 (3)ポリモーフィズムが可能 Storage s = new Usb(); ... s = new SDCard(); SDカード・USBの違いを区別することなくアクセス可能。 s.read(ファイル); 他にもメリットは腐る程あるが、そこは自分で調べてくれ。てか、質問スレでどうぞ。 >>166 数字?なんだそりゃ。 非OOPの品質が1ならOOPの品質は10 これでいい?納得した?しねーだろうなぁ(投げやり) スマホ入力つらい...PCもってくるか... >>171 (1)はstaticの利点でもあるな (2)はOOPの話じゃないだろ (3)は何が言いたくて何が利点だかよく分からないけど、 関数の共通化できますってことか?OOPにかぎらんだろ 長文乙だが、読んでて気がついたは あんたが書いている程度の規模のプログラムだと 何のパラダイムでも大して管理は変わらないと思う 何でこのレベルのひとが「OOPを理解している上で」とかえらそうなことを言うのかの方が疑問 >>172 いいよ持ってこなんで。 話を聞くだけこっちの時間の無駄 >>173 > 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、 > 規模に応じ急激に複雑さをまして > (レキシカなスコープ、エクステント管理に対し) > 人間が管理把握しにくくなる因子であることは、 > 一定の理解を得られているはずだが こんな意味不明な発言をする人に言われたくねーです。 >>175 これ分からないんだったら単に不勉強だと思う。 ここ数年間のソフトウエア工学の進歩を眺めてりゃ分かる程度のこと。 まぁ、多くのITエンジニアがやは不勉強なんだが。 不勉強で理解できないのは自然なことだ、しょうがない >>173 > 人間が管理把握しにくくなる因子であることは、 > 一定の理解を得られているはずだが ちんぽは本人ですら管理できない独立した生き物だが? >>177 そのうち、年取ると小便にしか使わなくなって 逆の意味で言うことを聞かなくなるから 心配要らないよ >>176 > 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、 > 規模に応じ急激に複雑さをまして > (レキシカなスコープ、エクステント管理に対し) > 人間が管理把握しにくくなるあることは、 > 一定の理解を得られているはずだが なんでカプセル化がこの問題に繋がるのか説明してくれる? コード書いてほしいな。或いはもう少し具体的に説明してくれないかな? 飛躍しすぎてわけがわからん。 >>179 過去スレでもさんざ書いたんだが 自分が不勉強なくせに、5chにでまた長々かけってか、、、 子供電話相談室じゃねんだが。。。 まずプログラミングの基礎である レキシカなスコープ、エクステントは 分かるよね? は? 全くわかんね 書いてあることがどうとかってより まず、 どうなるとオブジェクト指向なの? あとオブジェクト指向のもたらした依存の複雑化する問題は 理解しているよね? >>182 ごめんごめん、受けた? ○ レキシカルなスコープ 知ってる。そんなレベルの話ではなく、なぜ、そこに問題がでると思っているのかの話。 レキシカなスコープという時点で何かを感じるが。 >>185 ダイナミックスコープがまずいのは分かるだろ? いわゆる旧MS BASICのような。 では大規模ソフトでレキシカルスコープがなぜ大事か分かる? ここ40年くらいの間に普及したんだけれど。 >>183 これが抽象的過ぎてわからん。 なんで、毎回曖昧な表現使うかな...。 >>186 あっ...ここでもうわからんわ。 ダイナミックスコープがまずい? カプセルかってのは何やんのよ。 細かい解釈の違いは、頼むから横においておいてよ。 1) 型クラス 2) メンバのアクセス制限修飾 こきらまでは旧来のCもできましたよと。いいよね。 3) アクセスmethodを設け、calssまたはインスタンススコープを持たす そして「動的な」が好きな人は 4) 動的インスタンスの生成・消滅 ⇒エクステントはレキシカルとは結びつかず独自に管理せなあかん >>168 > だってそれお前の感想止まりじゃん 俺の感想じゃなくて世界の感想だってw >>188 スコープダイナミックって言うことは、外から見える変数ばっかりで プログラムがちょっと大きくなっただけで、局面局面で意識・管理せにゃならん 変数や状態が増大しくみ合わさって入り組んで見えたり、 あるいは実行時に呼ばれる順が変わると変数の内容が変わったり 管理不能になる 昔はそういう言語しかなかった CやShemeがlexical scoprやextentを導入して革命がおきた >>191 なんなら、関数型と手続き型と比較してみますか? データ出してみてください。 C#とnode.js使いだけど、ダウンロードできるオープンソースでオブジェクト指向じゃないコードを落とした経験がまったくない。 たぶん、業種によるんだろうな。 オブジェクト指向と無縁の業種とは無縁だから具体的に何かは知らないけど。 そうでしょっていうのは、お前が関数型と手続き型の データを持ってくるってことね。 自分で検証しなくていいのよ。お前がやりましょうってこと。 困ったな 俺はメンバ変数全部publicだし お前らの組み方だと組むときになって アレ?このメンバ変数privateだ! オラ、びっくらこいたーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー!!!!!!!! 設計を根本から見直さなきゃ! ってシーンがないとダメなんだろ 俺、そういうことねーし >>194 あたりまえやんけ、そんなこと。 そえはさておき >>189 がカプセル化の概要であるとして、 どのような弱点をもたらすか 1つはスコープの問題 メンバにアクセス修飾制限するのは一見いいことのように見える。 複合体型に基づくclassやインスタンスのメンバごとのスコープは フレームワーク的な中間レイヤの局所では一貫して明確に決めやすいけど 上位の複合的な機能のアプリレイヤに近づくと、型も色々持ち込んだ複合的な ものになるわけだし、動的に生成したインスタンスを動的なエクステントで使いまわす ので、メンバへのアクセス制限は局所局所で融通が利かず一貫性を維持しにくくなって 結局多くのメンバをアクセサを用意するはめに陥る。 これは、グローバルなscope、動的ななextentを持つ(名前階層を持った) 多数の変数でプログラムを組むことと同じ複雑さをもたらすでしょ。 そのなかでエクステントの管理もやっていくと、、、(弱点2) どMかよ> では >>183 と組み合わさって、さらにどのような弱点をもたらすか… なぜ変数やメソッド(メンバ関数)をprivateにするか? 少なからずの場合それらが試行的もしくは暫定的。 例えばシグネーチャがまだ流動的な場合とか。 自分も含めて勝手に使って欲しくない、少なくとも使われる箇所を完璧に把握しておきたいような場合。 >>187 >これが抽象的過ぎてわからん。 >なんで、毎回曖昧な表現使うかな...。 928 デフォルトの名無しさん 2018/11/21(水) 18:59:11.61 ID:8Yc2p7H1 >>922 >ナンチャッテメッセージングスタイルになったのは チンポ.オシッコを出す チンポ.オシッコを止める さっきトイレでやってきた。 929 デフォルトの名無しさん 2018/11/21(水) 19:07:17.83 ID:8Yc2p7H1 >>915 >単なる動的なメソッド呼び出しをメッセージと称し、ただしコールするメソッドが見つからない場合だけメッセージを >ハンドリングできる省コストなナンチャッテメッセージングスタイルに落ち着いた。 × 俺.オシッコを止める 俺.オシッコを出す ○ 俺.チンポに力を入れる 俺.チンポから力を抜く オブジェクト指向のもたらした依存爆発へのカプセル化の関与 多態はmin, max、abs くらいに制限しまずは捨てましょう。 継承はソースの合成レベルで大いなる依存を持ちむので、 特にアプリレイヤでの活用はホント色々問題あるんだけれど、 カプセル化はというと、 1つはdynamic なextentが好まれる点ね。 どっかで作られるインスタンス・メンバが、見通しやすいnest したlexicalなscopeを離れて 浮遊し、どっかで参照、更新されると。。。。 動的にだぞ?お前がやっているような小さいプログラムは何とでもなるかもしれないけどさ、 どうやって追っかけんだよ 二つ目はデータ構造間の依存、三つ目はデータ構造に対するメンバとmethodの依存 たとえば委譲した動的階層化データ構造の中の、ある局面で一見みえないメンバがどこか遠くで 定義され参照され更新され、、、、orz あるいは複合型クラスのインスタンスとメンバを多階層の継承と組み合わせた場合、、、、、 まぁ言わずもがな経験者は分かるだろう 管理不能なスパゲティ−の出来上がりだわな こうやってカプセル化した動的な型構造は依存を中継するハブ見たいな役割を果たしてしまうんだよ このたわけめ ここまで1から10まで説明させるとは、金取るぞホントに これがネットのどこにも落ちてない口伝でのみ伝えられるという奥義(゚A゚;)ゴクリ ( ゚д゚)ホントニハヤットンノカイ? 入門者とえせ講師を中心に日本中で絶賛大流行中だぜ。 もう新興宗教かめ威信か、比科学的もいいところ >>199 > ので、メンバへのアクセス制限は局所局所で融通が利かず一貫性を維持しにくくなって > 結局多くのメンバをアクセサを用意するはめに陥る。 なんでアクセサを用意したらダメなんて思ってんの? それが外部から触るなら、インターフェース化(≒仕様化)するってだけでしょ >>202 > 動的にだぞ? 動的ってどういうこと? 参考コード書いてよ >>202 > の、ある局面で一見みえないメンバがどこか遠くで > 定義され参照され更新され、、、、orz 参考コード書いてよ なんだろう、OOPってこんなに難しい話ではないと思ったのだが... 着目点が違うのだろうか。 OOPに関係のない概念まで出てきているような...。 誰か、理解、できた、人、いる? いや、static/lexical scope、dynamic scope、extent、依存、複合型クラス、インスタンス これらの用語が全然スッと頭に入ってこないのはなぜだろう。 >>202 > あるいは複合型クラスのインスタンスとメンバを多階層の継承と組み合わせた場合、、、、、 > まぁ言わずもがな経験者は分かるだろう ちゃんと書けよ >>209 着眼点がおかしくて、たぶん問題を解決するためにオブジェクト指向を使うんじゃなくて オブジェクト指向の問題点を見つけるためにコードを書いてるんだと思うよw >>206 せっかく内側に入れて隠そうとしたものが、 実は外からアクセスする必要にあるものでしたテヘペロというのは 設計のミスだったり複合型化すべきではないものだったりするじゃない。 それにプログラムが実行中にある局面から見える変数や環境、 あるいは関数は数が多くなっ足り独自のextentを持っていると 急激に人間には複雑に見えてくるでしょ だからアクセサを多数用意するのh簡単だけどそうした段階で、その後の管理苦労はもう目にみえているわけ 本とここは子供相談室かよ 機能一覧 →各機能の処理一覧 →それに対応する関数一覧 を作ってた昔のほうがシンプルだよ これ以上シンプルなモノがないのに 余計なことしてわざわざ難しくしてる >>213 > せっかく内側に入れて隠そうとしたものが、 > 実は外からアクセスする必要にあるものでしたテヘペロというのは > 設計のミスだったり複合型化すべきではないものだったりするじゃない。 お前の設計のミスでオブジェクト指向の問題じゃない >>217 おれはそんなことやんないって、何勘違いしてんだたわけが >> 206 になぜよくないか言っただけ >>213 だから具体的なコードを書けと。 あと複雑さをゼロにするものだって思ってないか? お前がオブジェクト指向に過剰に期待して、 オブジェクト指向はダメだって言ってるだけ。 例えて言うのなら お前「エアバッグは自動車事故を完璧に防ぐものだ」 お前「でもエアバッグでは自動車事故は完璧に防げない」 お前「だからエアバッグはだめなんだ」 このセリフを一人で言ってるだけ。 >>217 もうオブジェクト指向方法論にずらさないで 重箱の隅はどうでもいいので えっ、私だけ不勉強なの? どなたか、解説をしていただけないだろうか。 カプセル化がstatic scopeとextent管理に問題を及ぼす解説らしいのですが...。 >>218 俺もオブジェクト指向で、そんな設計ミスしたりしない。 お前の中の想像の人間の話でもしてんのか? >>219 複雑さを増大させるとかいたらすげー極論が出てきたな 論理的なものの考え方が苦手な人がよくブジェクト指向にはまる >>1214 オブジェクト指向が解決するのは、 > 機能一覧 > →各機能の処理一覧 > →それに対応する関数一覧 これらを組み合わせる時の問題 >>221 直訳すると テメーの態度が気に入らない ということになる >>223 俺が言ったことが極論でもなんでも良いから、 何か言い返せよw >>221 そういうのを論理の飛躍という 根拠なく利点と結びつける >>224 いらないよ 普通に関数一覧の関数作ったら終わりやで 入出力も明確や いいからさっさと作れ >>226 子供だな。 >お前「エアバッグは自動車事故を完璧に防ぐものだ」 >お前「でもエアバッグでは自動車事故は完璧に防げない」 >お前「だからエアバッグはだめなんだ」 エアバッグの性能を厳密に測定しないとわからないよね >>228 じゃあ、その関数一覧でさ、 アルゴリズムが、例えば AES暗号を使ったモジュール TDES暗号を使ったモジュール 2TDES暗号を使ったモジュール 3TDES暗号を使ったモジュール みたいに複数あって、 それらを交換可能にするときはどうするのさ? てんでバラバラの関数一覧があるだけではダメってのがわかるだろ? それらの関数一覧に対する共通の仕様(=インターフェース)が 定義されれてないとダメ。 それに関する問題を解決するのがオブジェクト指向なんだが そう言う問題以前に 誰も言っていないことを、お前は言ったとか 妄想か池沼かガキの言い分か 何を言ってるのかわからないけど、間違いなく3vnN9KRUはオブジェクト指向を有効活用しようとしたことがないのは分かった。 >>232 そんなもの昔からあるパラダイムで十分実現可能だし Cなどでそう実装されている >>235 それを発展させて汎用化したものがオブジェクト指向。 関数があるだけでは、それらを組み合わせる時の問題に対処できない。 >>234 分からないんじゃしょうがないだろ 分からないからこそオブジェクト指向の沼にはまってんだろ >>237 > Cなどでそう実装されている C言語でオブジェクト指向が実装されてるからなんだっていうのか? オブジェクト指向とオブジェクト指向言語の違いぐらい理解しろよ。 >>239 お前がオブジェクト指向の沼にハマってるだけだろw それともまた、「お前の考える想像上の人物」の話でもすんのか?w スコープダイナミック!www ギャバンダイナミック!wwwww >>239 ええ!? わからないのにあれだけ長々オブジェクト指向の批判してたの!? >>240 C言語を使ってオブジェクト指向のようなコードは(回りくどくなるが)記述しよとすればできるが、 C言語にはオブジェクト指向の機能は実装されていない。 他の言語も同様。 基地外だったか… >>243 やはりオブジェクト指向は一子相伝・・・ >>244 オブジェクト指向の機能が実装されて無くても、 オブジェクト指向は出来るんだよ。 オブジェクト指向の批判として捉えようとしたからダメだったのかな...。 うーん、もう一度読み直してみます。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる