オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 う～ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。
何らかの問題を解決したい、もっと便利で問題の発生しない手法は無いだろうかというような要望があって、
それを実現するためにオブジェクト指向なるものが発明されたとすれば、
同じ考えでオブジェクト指向を採用するのも良いだろうけど、
最初からオブジェクト指向ありきはダメなんじゃないの?
なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。 >>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に変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話 んで思うのが
どうもアメリカらしくないなと
あれだけメリットとデメリットと数値化にこだわる国がなんでこんな丼勘定やねんと
オブジェクト指向なんて出回った頃にはもうすでに向こうではプログラミングは
無意味な公共事業の一環になっていたのではないか？
そしてそれにはもはや意味がなくて
できるだけ時間がかかる方法だけが採用されたと >>297
オブジェクトが状態を持つとテストがしにくいからといって
オブジェクトに状態を持たせなかったとしても、
状態を持ってるアプリケーションから状態を消し去ることは不可能なわけで
どこかに状態が存在するので、結局その部分のテストはしにくくなるよ
単にテストしにくい場所が変わるだけの話 >>299
メリットとデメリットにこだわってるから
オブジェクト指向を使ってるのでは？ >>300
まず、それが見えているかどうかが問題
引数から渡す形ならドキュメントに記述を強制できる
さらに同じ引数で実行したらなるべく同じ結果が返って来ることも保証できる
これで気をつけるのはファイルアクセスやDBアクセス、日時、通信などに限定できる
オブジェクト指向は全てのクラスが失敗作であると言える >>302
いや、どんな言語で作ろうが、
アドベンチャーのフラグ管理は大変だよ
関数型言語なんか、実装が不可能なレベル オブジェクト指向を捨てたGO言語を使おうってこと？ 実は倍精度浮動小数点数のインスタンス変数があったら2^64個の状態があるって話だ
もしくは10x10x10と10+10+10がほぼ一緒の値という主張だよ >>297
そんなことない
本格的なオブジェクト指向では
>>260みたいに小さなオブジェクト数にして
状態数も減らして単体テストしやすくする
むしろ関数型で複雑な状態遷移を実装するのは難しい
現にゲーム制作ではぜんぜん関数型が流行ってないからな >>306
何年か前にOOPのそのトレーニングやったけど
今にして思えばおかしなことをしてたなって思う
素直にGO使ったほうがいいよ
今は制約を気にせず非常に楽にコードが書ける
それでいてOOPのころの糞コードからかなり離れている
GOのおかげ GOのtypeは非常に見通しがいい
c/c++のヘッダファイルはなんだったのかと 状態を持たないオブジェクトwww
もはやオブジェクトちゃうやんw何の受け売りやそれw アクセスパターンを限定化する
これを理解出来ないなら
オブジェクト思考プログラミングはし無い方が良い
どういう訳か
凄まじい自信の有る人程解っていない
というのがこの界隈 OOPで良いとされているが一番の間違いは
単機能の小さなクラスを沢山作ること
これはクラス数の爆発を産んでるので一番の害悪
例えば特定のファイルを読むためのクラス
そしてそのインターフェイスとDI用のクラスとテストケース
本当にこれが無駄
内部の状態に依存せず単機能でいいなら関数でつくればいいと気が付いた >>310
不変オブジェクトがあっても別にいい
>>312
＞単機能の小さなクラスを沢山作ること
小さなクラスをたくさん作るからこそ変更しやすくなる
クラスの数を大きくして数を減らしてしまうと
作るときは一見楽に見えても後で変更コストが上がる >>313
それはOOP自体が悪いからそう見えるだけ
クラス数の爆発のほうが本当の害悪
上のトレーニングもクラスをちいさくする良い理由の一つとして
エディタの一画面にはいるから…
クラスが一ファイル内にないといけないその言語の制約だろう
パッケージ内に在ればいい言語に乗り換えよう クラスが小さいと困ることがある
インスタンス変数を２つに絞るのは愚か
確実にクラス設計が困難になる
変数をどこが持つべきかを設計しないといけない
そしてそれが間違っていた場合大規模な再設計とコーディングが必要になる
中程度のクラスにある程度必要とされる変数が入れておく方が開発工数は減る 状態を持たない
そもそもが小さい
ならクラスじゃなくて関数を使え >>313
不変ゆうんは状態を持つから不変なんやぞw
受け売りでイキるのやめときw >>260
改めて書くけどこれはほとんどがもう古いし
本当の意味でOOPの弱点をカバーしてない TCP接続をOOPで書くとして、オブジェクトの外側でTCPの例の状態遷移を気にする必要あるんかいな 不変オブジェクト自体が一つの状態であることは確かだと思うが、語弊がありそうだな。
可換原則的には互換性のある小さなクラスをたくさん作る、が正しいだろうけど、
実際にそれすると、とんでもないバカが現れて瞬時に全壊するのも見たことあるし。
やっぱり一概には言えないと思うわ。 >>316
関数でもいい場合はあるが
クラスにするメリットもある
>>317
それは難癖でしかない
再代入しないことによって
状態変化のデメリットが生じないので問題ない >>319
気にする必要が無いように組んでもいいし組まなくてもいい
でもテストは全状態に対して行わなくてはならない
現状はおそらくそれをやってる奴が少ないのがまずい
ここではさもやるのが当然とばかりに主張はするがそのテスト方法は提案すら挙げられない雑魚 ■ このスレッドは過去ログ倉庫に格納されています
