オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 どちらにしろ
構造化よりもオブジェクト指向のほうが大規模に強いのは変わらん
オブジェクト指向が大規模のために作られたと言っても
小規模で使えないことにもならない
実際に小規模でも使える
オブジェクト指向で失敗するようなら構造化でも失敗する。
能力不足が原因だからな。
で、能力不足を認めたくないから、
オブジェクト指向のせいにしてるんだろ？ そもそも破綻している、と言える状態はどんな場合だろうか だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる 馬鹿「オブジェクト指向で失敗したら、オブジェクト指向特有の・・・」
じゃあ、構造化で失敗したら構造化特有のやり方が原因なんやな？
馬鹿「ぐぬぬ」
↑イマココ で、ｳﾝｺｽｸﾘﾌﾟﾄで
山盛りのｳﾝｺをつくる
rubyとpython作ってるような
ｳﾝｺｽｸﾘﾌﾟﾀｰ ｺｲﾂﾗの場合
ｳﾝｺｽｸﾘﾌﾟﾄﾌﾚｰﾑﾜｰｸ（）使っても
破たんさせるほどの特殊能力がある
だいたいこういうの使ってるﾔﾂﾗは
そういうﾔﾂﾗだ >>198
皮肉もわからんのかーwwwとか言うやつが急に非論理的だ、とか笑わせに来てんのか貴様は
なんだろうなお前の言い分は都合が悪いと全部一般論にして逃げてる感あるな、大規模なモノが破綻するのはオブジェクト指向に限らずみんな一緒とか。
それを言うならオブジェクト指向使わず手続き型で組んでも破綻しないように組めばいいじゃんってなるんだよな。
その先が見えないわけよな。もはや何の為にオブジェクト指向使ってるんという >>200
オブジェクト指向の破綻はルール守る為に手続き型のコストを超えた時やろな ﾉｰﾀﾘﾝ言語の開発現場には
ﾉｰﾀﾘﾝが集まる
ｺﾚは宿命 >>207
上でな、オブジェクト指向は壊れると言ったら壊れないように作ればいいという身も蓋も事を言われたんや
言語はそういう人のために作らないといけないかもしれん >>208
当たり前だろ
どんなものでも壊れるというのは大前提
どれだけ壊れにくいか？という壊れにくさの話をしてるのに、
お前は「オブジェクト指向は銀の弾丸でなければならないが
銀の弾丸でないことが判明したらどうする？」と言ってるだけだろ？
誰もオブジェクト指向が銀の弾丸なんていってない
だが強力な武器なんだよ。 とりあえずオブジェクト指向で作るってことがなんなのかから判別しようか。
例えばlinux kernelはオブジェクト指向でバリバリ作ってると思われてんのかね？ ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題 ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ
ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない
ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物
ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪 オブジェクト指向って何ですか？
C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？ X11やMS Windowsもｵﾌﾞｼﾞｪｸﾄ指向で設計されてる
ただ、低学歴知恵遅れでは、C言語でそれを実現することはできない
そしてそれを簡単に実現できる言語を使うと
なにが便利であるか核心的な部分が理解できずに使って
別のろくでもない問題をおこすわけ ﾊﾝﾄﾞﾗやｺﾝﾃｷｽﾄつかって
ｵﾌﾞｼﾞｪｸﾄを操作するのはまさしくｵﾌﾞｼﾞｪｸﾄ指向の便利な部分だからな
UNIXのi/oなんかもﾊｰﾄﾞｳｪｱがうまく抽象化されてる
ﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀ使って簡単に読み書きができるからな >>215
> C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
大変だけどできるよ
作りやすいかどうか、失敗しやすいかどうかだから 結局の所、小規模なものはオブジェクト指向使っても失敗しない
大規模なものは、オブジェクト指向を使うと失敗しにくくなる
って所が重要なんじゃないですかね？
失敗したときにそれがオブジェクト指向的な原因か
構造化的な原因か、なんてことよりよりも 低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
日本では、ITﾄﾞｶﾀは低学歴底辺がなる職業だからな
だいたい程度がしれたﾔﾂﾗが群がってくる
この板みれば分かるとおり う～ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。
何らかの問題を解決したい、もっと便利で問題の発生しない手法は無いだろうかというような要望があって、
それを実現するためにオブジェクト指向なるものが発明されたとすれば、
同じ考えでオブジェクト指向を採用するのも良いだろうけど、
最初からオブジェクト指向ありきはダメなんじゃないの?
なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。 >>222
お前の書き込みは、オブジェクト指向がクソだということが目的になっていて、
その他の何かが、オブジェクト指向よりも優れているという話になってない >>221
優れた人が優れた道具を使う
それに対抗するために、もっと優れた道具ができたとしても
それだって優れた人が使ったほうがもっと効果が高いわけで
優れてない人が、優れてない道具を使って勝つには
人海戦術しかないんだよね ぜんぜん分かってないわ
刃物は道具でもあるし
人を殺すこともできる >>223
いや、オブジェクト指向をクソだなんて思ってないよ。
むしろ好きな方なんで。
でも、肯定派の人ってありきでしょ。
それは違うかなって。 教育ｺｽﾄはものすごいかかるが
手続き型言語でｵﾌﾞｼﾞｪｸﾄ指向をみっちり体験してから
ｵﾌﾞｼﾞｪｸﾄ指向の教育に移行したほうがいい
この手順踏んだほうが間違いが少ない
そうでないと
ID:csv6kfNU ← ｺｲﾂ
みたいに頭悪いのが大量に量産され続ける >>228
バカにコストかけて教育するのもなんだかなー
バカとハサミは使いよう、というけれど、なかなか良い使いようが見つからんね。 オブジェクト指向のメリットって何？
この問いに今だかつて一人も答えてくれた事は無い
どっか他の文献指差して丸投げとか
逃げと食い下がりを駆使して結局答えないとか >>230
困ったことにどっかの文献ですら
ちゃんと理詰めで仕組みを解説してるものは皆無
完全なオカルトテクノロジー >>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う 色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか？
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ さっぱりわからない
オブジェクト指向のメリットとか特に オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた！ >>215
＞オブジェクト指向って何ですか？
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む
＞C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい >>230
＞オブジェクト指向のメリット
プログラムの変更コストが下がること >>243
どういう理由で？
オブジェクト単位に分けると仕様が消えるの？ >>245
それって君が想定した変更のときだけだよね？ そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね？
無意味じゃない？ >>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい >>248
別れてるからこそ変更しにくいって状況になったことがない？
経験不足じゃない？ 例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと
でもヘッダーは他の全てを知らないので関連するオブジェクト全てに手を入れなければならないと
こういうの想像できないの？
レベル低くね？ >>249
いやいやそれこそ
オブジェクト指向開発での経験不足 >>250
＞ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト（クラス）にする
そのオブジェクトは当然関連するデータを知っているので
変更もスムーズにできる
一方オブジェクト指向でない場合には
それらのデータがバラバラになっているから変更しにくい
この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる >>252
って変更を各オブジェクトに入れないとできないよね？
c言語だと普通に処理書くだけやで オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない
オブジェクト指向を勘違いしている人はオブジェクト指向を、
不可能なことを可能にする技術だと勘違いしておいて
不可能なことを可能にしてないと（自分の勘違いを）批判してる
オブジェクト指向は従来のやり方でも可能ではあるが
大変なことをより分かりやすく簡単に実現するための技術 >>253
＞c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない 強制的にOOに慣れるためのプログラミングスタイル、ってありませんか？ >>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと（自分の勘違いを）批判してる
こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい 流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか？ オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ
まあ嘘である >>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。
おれの居るところ真逆のプロジェクトだ使いまくりでワロタ セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな？ >267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない >>268
納得できる説明なのにおかしな改行で台無し・・・ メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。 ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ
同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合したような糞 >>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ
オブジェクトのメソッドの大半はオブジェクトの状態を取得または変化させる
（状態を参照しないならそのオブジェクトに持たせる必要はないわけで）
オブジェクトのメソッドのうち、一つの変数を変更するものがsetterで
一つの変数を取得するものがgetter・・・になってることが多いが別にそうする必要はない。
例えば内部変数が配列で要素の0番目を読み書きするsetter/getter
要素の1番目を読み書きするsetter/getterを作っても良い
もちろんsetter/getterではなくメソッドでやっても良い
どちらでも同じことができる。
言い換えると、システムを作るのに、メソッドだけでも実現できるし
プロパティ (setter/getter) だけでも実現できるということ
メソッドとプロパティ (setter/getter) の違いは
UMLのクラス図を書いたことがあればわかる。
UMLのクラス図には操作と属性の両方が存在するんだよ。
なぜか？ それは人間の思考を反映させた結果だから
実装段階の思考ではなくて設計段階の思考ですでに操作と属性が別れてる。
メソッドとプロパティは本質的には同じものでコンピュータから
見れば同じものとして扱えるが、我々は人間なんだ。
人間がそれは操作、それは属性って分類して考えてるから、
それをコードに反映させられる記述能力の高さを求めた結果
メソッドとプロパティができたんだよ
しかたないね。人間だもの > メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> （以下ポエム略）
？？
なぜそれを俺にレスしたのか不明 だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな >>275
つまり、
× getter/setterが悪い
○ getter/setterの間違った使い方が悪い 刺身にﾀﾝﾎﾟﾎﾟのせてるﾔﾂが
ちゃんとｷﾘｷﾘ働いてるか
その働きぶりをたまに覗きたいことはある
こっちからなにをするということはない >>276
確かに悪い使い方が都市伝説みたいに普及しすぎて、ろくろくまともな開発したことの
無い輩まで頓珍漢なｵﾚｵﾚオブジェクト指向論を吹聴するにいたったブームには参ったが、、
使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ >>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。 いや、単純にオブジェクト指向なんてやったって地獄に落ちるだけ
クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ
単純にプログラムを
入力→処理→出力
という繰り返しの塊にしなければならない
メソッドを呼ぶたびに状態が変化
するようなもん誰も管理できない オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか ｵﾌﾞｼﾞｪｸﾄ指向でも
詳細化したらﾃﾞｰﾀﾌﾛｰ図に落とせる設計でないと
お話にならない 状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か？ 以前(>>161)にも書いたとおり
ｺﾚ以外方法はない
この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる
①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止
ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる 単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん
こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか？
というぐらい一切メリットがない >>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ 単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ 割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってことさ、AHAHAHAHA～ >>260
部分的に構造化プログラミング養成ギプスのような気がする >>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。
内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。 状態を持つなって言ってるのは関数型の考えから？
常にオブジェクト指向言語の方がメジャーなんだが 昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。
結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。 グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと >>294
状態を持つと単純にテストがしにくい
あるクラスにprivateでドキュメントにも記述のないメンバ変数が10個あって
その内包するクラスにもメンバが10個あって・・・なんてプログラムだと
そのクラスの持つ状態は10*10*・・・
みたいに増えていく
完璧にプログラムを制御しようとすると
その全てを把握しなければならない
実際にはそれは不可能なのでオブジェクト指向的に組んだプログラムはそもそもバグっている >>295
あんたは使うべきの意味を理解してないよ
使うべきっていうのは今も一緒。
まずクラスのpublicフィールドを直接読み書きしたらいけないというルールがある。
そしてもう一つ、クラスのインターフェースを頻繁に変更してはいけないというルールがある
この２つのルールにより、publicフィールドを直接読み書きしていて、あとから読み書きに
何かしらの制限を書けたくなったときにgetter/setterに置き換えたらインターフェースが変わってしまう。
例えば obj.foo だったものを obj.getFoo() に書き換えないといけない
だから常にgetter/setterを使いましょうと言われていた
だけど今はプロパティを備えた言語ができた。
プロパティを備えた言語であれば、クラスのpublicフィールドというインターフェースを変えることなく
getter/setterにできるためあえて禁止する理由がなくなった
（obj.foo = 1 とかいて obj.foo に代入してるように見えて実は関数呼び出しになってる）
今はインターフェース（名前）を変えることなく、フィールドからgetter/setterに変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話 ■ このスレッドは過去ログ倉庫に格納されています
