オブジェクト指向は愚かな考え
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。
かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性」として「カプセル化は絶対にやめろ」としている。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)
大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
実例
XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。
ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。
世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。頂点データをGPUに送信した直後にGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。
しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。
さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。
カプセル化は恐ろしいね！！ これオブジェクト指向が悪んじゃないだろ
オブジェクト指向が誤解されて広まったせいだろ サーバクライアントモデルだと
サーバ内部は雪駄下駄でしかアクセスできないから
カプセル化されているようなもの 人間オブジェクトを作った
このオブジェクトを継承した美少女オブジェクトはあらゆるプロパティを隠蔽したい
しかし変態オブジェクトは公開されるべきだ
かくしてオブジェクト指向はクソでした 業務システムでこれやるとだいたいセキュリティホールになる ケースバイケースだろ。プライベートなメンバ変数を定義して、その全てにSetterを用意する阿呆な設計は論外だけどな。 ＞将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、
これってオブジェクト指向が生み出す問題ちゃうやろ？ >>2
ゲッタセッタ使えよｗゲッタセッタ実装できないほどプライベートならそれはもう本当に使ってほしくないんだろ コード生成こそAIにやらせろ。いいコード書くぞ絶対。 カプセル化というと噛みつかれるけど
独立性を高めるというと黙る不思議 >>22
問題はその精製AIを書くAIが必要な事だ オブジェクト言語は情弱→手続言語は情弱→アセンブラは情弱→機械語は情弱→？？？ そうは言うがクラス内部でしか使われないクソみたいな変数が外から見えてるようなライブラリ使いたいか？ オブジェクトベースかタスクベースかって話じゃないのか >>31
触るとコンパイラ警告を出すだけで十分だと思うけどね。 アホがコード書くから改修が面倒になるだけでオブジェクト指向関係ないだろ 追加の開発がない売りきりだと問題は起きないんだけどね >>28
だな、そして、プログラマーの9割がゴミプログラマーである
ゆえに、「オブジェクト指向は愚かな考え」という結論に至る 鋼鉄の鎧を着たらウンコできなくなって漏らすようなもんだな 結局COBOLが言語として一番素晴らしいつてことか 他人の作ったライブラリを組み合わせてるとよく起きる privateとfinalは要らんと思うがprotectedは必要
継承すれば制約外れるようにしとけば問題ないしカプセル化の問題じゃないよね 美少女オブジェクトを作った
それはオタクオブジェクトと交信すると大金を取得する事が出来た
しかし、やがて管理者が変わり、オタクの他、おじさんオブジェクトとも交信させようとしたが、
結果でオタクオブジェクトが交信しなくなってしまった
同時におじさんオブジェクトも交信しなくなりシステムは停止してしまった
実はオタクオブジェクトとおじさんオブジェクトとの間では衝突を回避する為、美少女オブジェクトは自身の交際情報を彼らに提出していたのだ
このシステムは結局、元にも戻せず破綻してしまった
とか？ >>3
カプセル化がわるいのではなく
そのクラスの設計が悪いだけじゃないか
必要なものは外部からアクセスさせるべき 昔、通信ライブラリで送信元の情報がバッサリ消えているのがあったな。
構造体に1個追加させるのに東京と京都を往復しまくって半年かかった。 オブジェクト指向のおかげでプログラミング辞められました(´・ω・｀) ＞大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
何言ってんだこいつ カプセル化すれば内部は隠蔽されていても、入出力がはっきり分かれば
それを組み合させて簡単にシステム構築できるんじゃないのか？
まあ、よくわからんが。 >>52
必要な人は少数
必要ない人には触らせたくない
どうするのが正解なの？ >>40
宇宙でアムロが新型ガンダムを受け取って乗ったら足を操作する為の装置がなかった
宇宙で戦ってる間は問題なかったが、地上に降りることになって詰みました 変数に関数なんか入れられっかっての
そんなこんなでいつもストレスが(´・ω・｀) 俺もこの考えに賛成だ。OOPは要らなかった
では何が問題だったのか、C言語を例に上げると、
文字列操作、リスト、GC、など。
つまりGo言語に行き着くわけだが、
Go言語もなんか違うんだよなｗ データ構造にメスを入れるならオブジェクト指向じゃなくても大改修にならないか
影響範囲をつかみを把握しづらいことを指摘してるのかな >>57
データベースいじるだけの業務システムだと発生しにくいからな。
深い階層構造になることもないし。
昔某社のエンジンの試験システムでアホみたいに階層を深くしてる馬鹿がいて怒鳴りつけたことあるわ。 >>57
医学的に言えば以下が意味不明だな
医学を知らない奴が考えた文章だろう C++に挫折して、TURBOPascalでプログラミング勉強したんだけど、
おかげで意識せずオブジェクト化という概念を最初から理解できたと思う。
C++に固執してたら何一つ理解せずに終わってたかな。
あれは自由すぎてプログラミング言語としては最悪だね。 >>40
存在が余りにヤバ過ぎるんで∀タイプを地層処分にしたら後代になって発掘されてウエポンベイに牛が詰められた。 情報系じゃないからよく分からないけど、変数とは何かちがうのか。 カプセル化しっかりしてなかったらその前にデスマーチなのでは 業務システム作るだけのプログラマなら、最初からデルファイやC#やJAVAで
はっきりとしたオブジェクトプログラミングしてればいいし、他人の作った定義をそのまま鵜呑みにしてればいいだけ。 単発IDが多いのにこんだけ専門的な話題が成立してるのに驚くw RDBとOOPのインピーダンスミスマッチ
性能問題がついてまわる 外面さえ合わせてしまえば、中はある程度自由に書けるのが利点かと思ってた
継承しすぎるとわけわからんのは困りものだけど 諸悪の根源はC++だろ。オブジェクト自体の定義も自分でできてしまうような自由さが、むしろ初心者プログラマの理解を阻む。
そもそもアメリカではエリートしか使わないような言語なのに、JAVAが出てくるまで日本では、文系Fランや専門卒すらこれで
プログラミングさせてたから最悪。なんでデルファイが日本ではやらなかったのか本当に疑問よ。 関数オブジェクトなんて定義してるプロジェクトには近づくな 人間クラスの排便メソッドがprivateになってんのがおかしいって結論出てただろ >>1
これオブジェクト指向と全然かんけーない。
単に「他人の作ったコードが理解出来ないと直せない」と言ってるだけ。 CPUの種類毎にバイナリデータは変わる事があるはずなのに、バイナリデータしかないというのは謎 >>8
C++のオブジェクト指向実装がそびえ立つウンコだったのや
アランケイのsmalltalkこそ本物のオブジェクト指向 「C++はひどい言語だ。
これをさらにひどいものにしているのは、
水準以下のプログラマーが数多く使用していることで、
またさらに簡単に完全なゴミを作り出せるようになっている点だ。
Gitだけの一発屋のリーナスとかの言葉 >>84
諸悪の根源は言い過ぎだと思うけど、エリートしか使っちゃいけない言語だよなC++は サンデープログラマーの俺には必要無い概念だな
c++もベターc以上の事はやってない
とは言っても業務とか大規模プロジェクトに関わっている人達にはある程度必要なんだろうなとは思う >>27
じゃあそのaiにai作らせれば良いじゃん Adaで作ったF-22は予定通りローンチしたのに
C++で作ったF-35は永遠に未完成で既にスパゲッティ化して手に負えなくなって来てる 俺がプログラミングを始めた小学生の頃
エッチなお姉さんを作ろうとして
おっぱいやオマンコを作っていけばできるんじゃね？と思っていた
しかしプログラミング（BASIC）の勉強をするうちに
そういう"物"を作るのではないと知った
さらにそれから数年後、オブジェクト指向を知って
そういう"物"を作って組み合わせていくことでシステムが完成することを知り
あのときの子供の発想は間違っていたわけじゃないことを知った
別に子供の頃の俺がすごいっていみじゃなく
人間の自然な発想はオブジェクト指向なんだろうなってこと オブジェクトトゥ
アマプラに日本のいちばん長い日が来て
新旧見てるとこ
役所広司版は駄作だと思っていたけど、割と面白い Javaとかクソだわ
勉強すればするほどイラついてくる
Cやり直してるレベル C++は悲惨な言語だ。
しかも、少なからぬ数のプログラマーが使っていて、
完全無欠のどうしようもないクソを生成するのがめちゃめちゃ簡単になっているという点で、よけいに悲惨だ。
マジで、Cを選択する理由が「何もなかった」としてもだ、
C++プログラマー避けになるというだけで、Cを使う大義名分になる。
〜
俺の出した結論では、プロジェクトにCよりC++を使いたがるプログラマーは、むしろいやがらせして追い返したほうがいい。
そうすれば、そんなヤツは俺のプロジェクトにやってきて、ひっかきまわしたりしないからな。 そこそこ以上に賢い奴にはバカのやることは想像できないだろうからな >>102
Javaってイラつくか？gofを取り入れたそこそこ面白い言語だと思うけどな。 C++じゃなくてC--じゃねーかといつも思って胃が痛くなってました(´・ω・｀) おまえらオブジェクト指向わかるんだすげーな
俺やってみたけど全然わかんなかったわ… >>109
メンテナンス性を考えていけば自然とオブジェクト指向になるよ 5〜6年前だったかな
アキバでいろいろ物色してたら
おそらくアキバにオフィスがあるだろうオタリーマンが
オブジェクトがなんとかとかAPIがなんとかとか意識の高い話を大声でしていた オブジェクト指向はシステムの設計者のためのものであると考えたほうが良い
つまり歯車を組み合わせる人のためのもの
オブジェクト指向を理解できない人は歯車を 作ってるレベル人ばかりだよ
見えてる世界が全然違ってる オブジェクト指向のキモはモジュール分割だぞ
継承とか再利用とかそんなのは夢物語に過ぎない
大きなシステムが合理的に分割され、
個々人が少しでも独立して勝手に仕事をすすめられるようになればそれでいいのだ ＶＢＡ作って遊んでればいい事務仕事のワイに死角はなかった オブジェクト指向は使えるかどうかじゃないんだよね
オブジェクト指向を使うレベルの仕事をするか下っ端か オブジェクト指向は素晴らしい考えだけど、現実の開発現場の事情とはマッチしない場合が多いので、後で大変な目に遭うよ
って話 >>1
問題の本質はオブジェクト思考ではない。
同じイメージを共有できていないことが1番の問題。
つまりコミュニケーション。 結局楽しいのはアルゴリズム考えてる時だけだよね(´・ω・｀) × 現実の開発現場の事情
○ 自分の開発現場の事情
結局さ、できるやつは上に行ってオブジェクト指向も使う
できないやつは、ひたすら当たれられた同じような手続きを
何度も繰り返し書くだけなんだよ オブジェクト指向を理解できないやつも
結局オブジェクト指向で設計された道具を使って仕事をしてるわけで
自分の仕事の範囲が、オブジェクト指向で設計するレベルにまで
到達できてないってだけなのよね。設計はできないが使う >>30
真の強者はCMOSを配置して命令セットを作成する オブジェクトでしかプログラミング出来なくなってしまった。
C関数しかないプログラム見ると、解析したくなくなってしまう。 どの分野のプログラムを刷るかで全然話が変ってくるから
おそらく1000行くまで平行線なんだろうな
昨今の表示に時間のかかる重たいホームページと阿部寛のページのようなシンプルな物
どっちがいいのかという話のごとく >>124
設計の話だから言語によらないよ
アセンブラでもオブジェクト指向設計はできるし、
ハードウェアでもできる
そもそもCでオブジェクト指向的な事をやってた人たちはいたんだぜ
オブジェクト指向言語ができる前にオブジェクト指向という概念が無かったなら、オブジェクト指向言語はどうやって生まれたんだい？ >>83
その外面が後々変わるので修正困難になると言っている。 外からいじってほしくない変数をいじられてオブジェクト全体の
整合性を壊すリスクを考えたら継承させて新しいクラスを作るほうが
リスクが少なくていいんじゃないのかなｗ >>129
阿部寛のホームページ作るのに、
クリーンアーキテクチャ、コンポーネント設計するのはやりすぎでアホらしいが、
例えばショッピングサイト作るのにそれらを適用しないのはアホの極み privateにしておかないと勝手に変数変更しておいて動作がおかしいとかほざく奴が現れるからしょうがない オブジェクト指向の類って多数の人間が部分的にコーディングに参加しても破綻しないためってことなんだろ
逆にそれが破綻する原因になってるなら使わなければいいだけなのでは 大切なのはオブジェクトでもカプセル化でもなくポリモーフィズム
でもオブジェクト指向の教科書の後ろの方にちょこっとしか書いてないんだよな >>137
オブジェクト指向＋多数の人間で破綻するなら
非オブジェクト指向＋多数の人間でも破綻する
技術力の問題だから オブジェクト指向おじさんさぁ
時代はもうクラウドの時代なんですよ
FaaSでマイクロサービス
メッセージパッシングこそオブジェクト指向のキモという
アランケイの描いた未来になって来た >>136
全部public staticで構わん 今はComponentなどのサブシステムが増えているから
階層が増えるのは仕方ない
オブジェクト指向が万能ではないけど、他の方法よりはマシなのが現状 >>141
> オブジェクト指向おじさんさぁ
> 時代はもうクラウドの時代なんですよ
クラウドで使われてるのはオブジェクト指向 >>2
＞バイナリのライブラリしかない場合などは絶望的である。
あるある 全変数はグローバル変数。
変数と関数のみで作る。
可変変数禁止。最初に各変数の大きさを決める。
これの方がすっきり軽いプログラムができる。 記事を読むに、jarだけと仕様書だけを使い回してソースとかはいつまでも保持しないのかな？
日本はそういったケースは少ないから記事のデメリットを感じることはなさそう >>142
それだとインスタンスとクラス変数が1対1にならなくて困る iPhoneだめじゃん。
オブジェクト指向開発の宝庫。
データをアプリで隠蔽するから、アプリ使わないとデータにアクセスできない。確かに不便だと思った。 クラスやオブジェクト指向のせいで、メモリリークが発生するソフトだらけになった。 >>147
スッキリ軽いプログラムを作るという仕事はない >>19
データを他人が直接意識してる時点で設計がおかしいだろ >>151
そんなウンコなJava使ってるからだよ
C#に来なよ >>151
バッチ処理のプログラムを、オンラインに転用するとそうなりやすいわ オブジェクト思考でよく例えられるのが車とタイヤの関係
しかし、長年仕事やってきてほとんどが特注品だと言うことに気がついた 20世紀で頭が止まってる元COBOLerなんだけどコピー句みたいなもん？ >>147
staticおじさんこんばんわ
中規模システムは作れましたか？ >>159
初見
仕組みは知らんくても、何をするものかくらいは知っとけよと
おまじないかよ！ pythonではprivateという概念が無いのには衝撃を受けた >>161
全然ちゃうでぇ
サブルーチンの変数は外から見せへんてだけやぁ 新海誠がオブジェクト指向って言われるけどどういうこと？
女がモノ扱いされてるってこと？ > 最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて
設計が間違っているだけだろうな
手法は大して問題ではない オブジェクト指向は偉大なんだよ
ただ最近オブジェクト指向に異を唱える者達が増えてきた
何故かというと、なかった時代を忘れてる、もしくは知らないから
プロジェクトの半数が失敗してた時代もあるのにな
アホが設計してアホが実装してアホが使っても、ちゃんと動くからJavaとオブジェクト指向は偉大なんだよ >>171
親のDNAを受け継いだお前さんもオブジェクト指向ってことだ >>168
WEBの世界でMVCやろうとするのは愚の骨頂 自動車のECU開発してるとオブジェクト指向とはほぼ無縁だけど、
いつまでもこんな仕事してるからテスラとか新規勢に追い抜かれんだよって思う
奴らは組み込みの世界でがんがんオブジェクト指向入れてるっしょ データベースに出し入れするだけのシステムだと、全部グローバル変数みたいなもんだからな。
そういうのばかり作ってるとオブジェクト指向でも困ることはあまりない。
ただの構造体としてしか使わんから。 >>87
ちょっと違うだろ。
バットノウハウはいつ使えなくなるかわからない的な話だろ。 >>169
設計を間違える人の方が多いから多少間違えてても後で対応しやすい構造の方がいいじゃん >>168
MVCわからんと派生系のクリーンアーキテクチャやFlux系もわからんだろ
基本だから知っとけというか、使えるようになっとけ 手が使えなくて足で頑張ったら、いつの間にか手が使えるようになって、今までの俺の苦労は何だったの？もう知らんわボケ
ってのがオブジェクト指向 >>181
エンタープライズシステムの要であるデータ中心設計とオブジェクト指向は
むっちゃ相性が悪いよな
てかオブジェクト指向設計なんかで会計システム作れないだろw 馬鹿にあわせるって発想だからね
プログラミングに限らないでしょ
まともな人から見たらどれだけアホなことか 既存資産まともなメンテ出来ないジャップには無理
そのくせコストケチってゴミを流用したがるからゴミからゴミを生み出す魔窟のようなコードが出来上がるわ >>188
現代のプログラミングしらないやつがどや顔すんあ >>185
手が生えたと思ったら頭に首に胸まで出来て、あれ？オブジェクト指向とは何ぞや
までがセット アスペクト指向との違いが説明できるレベルなら話聞いてやるよ オブジェクト指向厨はじゃあさ
給付金システムどう設計するのか言ってみろよ 結局複雑になって、PG参加者の敷居上げただけ。
再利用性云々いうが、別にオブジェクト指向でなくてもそんなのは昔からやってる。
で、Javaにのめり込んだ日本は他の言語全然カバー出来てないしまつ。今頃PythonだのNode.jsだの言ってる。
SIerとかいうクズの吹き溜まりを活かすためだけの利権でしかないよ。もはや JavaでAndroidのプログラムを作ったことがあるが、あのせいで脳細胞が100億個は死んだ そんなんデータの可視性など仕様の問題だろ
内部データだから隠蔽するんであって外部で使う可能性のあるデータなんで隠蔽してんだよ >>196
おまえは要件もわからないのにいきなり設計するんけ？ iPhoneアプリ開発に必須のobjective-cやswiftもカプセル化はできない。
人工知能で大流行のpythonもカプセル化はできないようになってる。 Smalltalkでは全てが「オブジェクト」
この思想を受け継ぐ唯一の言語こそRuby！
それ以外はOOP風味のCもどき言語に過ぎん 「カプセル化は悪」「カプセル化はオブジェクト指向ではない」という真実がやっと広まりだした。 いざカプセルの中を改修しようとしてもソースコードが無くて出来ないってだけの話じゃん >>201
Swiftはカプセル化あったような気がするが
アクセッサみたいなのなかったかな。 >>196
const kyufukin = nakanukiObj.input(money);
console.log(kyufukin);
完璧！ >>175
そうそう。Cでまともにコーディングできないバカが粋がってるだけ。
PythonだRubyだと言ってる奴らは、再帰処理とかメモリ管理とかちんぷんかんぷんだからな。 >>1
発言者をカテゴリー分けして優秀な人や有名な人が言ってることだから正しいと主張するのもカプセル化の一種 >>206
自主規制みたいなもんでアクセスしようと思えばいくらでもできてしまう。 >>166
さよか。
聞き慣れん用語が氾濫してきた頃に業界離れて正解やったわ
2000年問題の頃まではCOBOLしかわからん俺でも
派遣でそこそこ稼げたもんなんだけどな >>200
ど底辺にも要件想像しやすいように卑近な例を挙げただけだぞ
管理会計システム設計とか例に出してもどうせちんぷんかんぷんだろ？ (´・ω・｀)オブジェクト指向は言語の文法を知れば
(´・ω・｀)いいのではなく、オブジェクト指向の思想を
(´・ω・｀)理解しなくてはならない
(´・ω・｀)アホが間違ったカプセル化するから駄目なのであって
(´・ω・｀)カプセル化の概念自体はなんら問題ない
(´・ω・｀)必要ならセッタゲッタすればいいし、
(´・ω・｀)不要なら隠蔽する
(´・ω・｀)ただこれだけの話 >>59
フレームワーク開発者に一部の隠蔽を解除するのが全体に有益であることを納得させる >>3
こいつ馬鹿だろ
オブジェクト指向はどっちかというと馬鹿に自由にさせない記述方式だろ
自由にアクセスしたいなら生のライブラリでも何でも呼べばいい もうこういう是非を語る情熱はなくなったわ
そこの現場の宗教に合わせて（ユーザーに合わせるとはいってない）設計して作るだけですわｗ
ま >>205
たとえばそれが壮大なオープンソースのライブラリだとして、そこに穴を開ける修正パッチが公式メンバーに拒絶されたらどうする？
理論上はフォークはできるだろうけど、現実問題それ誰がメンテナンスするの？ >>205
ラップして新しいクラスをこしらえればいいだけなのに、騒ぎすぎなんだよ この辺の議論て30年くらい進歩ないよね。
技術的な伸び代がもうないんだろうな >>210
そうなのかー。
まあオブジェクト言語のカプセル化も
リフレクション使えばアクセスできちゃうんだけどな。 ひとりで開発、1社で開発というのなら何とでもなる。 日本で流行ってるのは
「極力さわるな、そのまま置いておけ」
というオブジェ思考 これはプログラミングだけにいえることじゃないな
会社の中で各部署が自分たちのプロセスを公開せずに、アウトプットだけだすとしたら、プロセスの最適化が行えず、無駄な仕事を排除できない 頂点座標取れないなんてのは文句言うなって話でしか無い カプセル化がダメならサーバ- クライアントのAPI指向なんかもダメになるわけだが
疎結合にするのは重要だろ >>218
protectedではなくprivateだとどうにもならんだろ。
iOSみたいにリフレクションも使えない実行環境だと、解決策は車輪の再発明しかない。 切り分けろ
拡張分は別口で用意して
インターフェースあたりで
外から都合の良い物に見せかけろ >>226
それクラス指向ではなくstatic関数だろ
呼び出しにソケット使うstatic関数 >>226
Web APIってオブジェクト指向とはまったく関係なくね？ >>218
ラップしても見えないものは見えないだろ？
同じ様なものをイチから作るしかない staticおじさん最強って事で結論つきましたね。 >>224
IBMが同じこと言ってたな。
効率化のために社員の階級分けをものすごく薄くした云々 >>227
privateにアクセスしたくなるというのはprivateにしてはいけないメンバなので
privateになっていること自体が問題なわけで
privateにできること自体は問題ではない (´・ω・｀)最適化のマーフィーの法則
(´・ω・｀)最適化するな！
(´・ω・｀)オブジェクト指向はこれ 何事も原理主義に走り始めるとおかしくなるもんだ
存在を知っている程度でいい
たまに利用できる程度がスマートだ
その方が代替手段も作りやすい
ってか設計センスの問題だと思う カプセル化なんてほんのたまに使う程度でいいんだよ
そのことに異論のある人間はいないだろ パッケージ化信仰が強い今の開発現場だと記事みたいなことが起こりかねん >>219
ここ10年ぐらいで関数型プログラミングの大ムーブメントあったのに
ここにいるオブジェクト指向おじさん達は時代に取り残されてて知らないだけよ
そもそもKubernetesもVue.jsもgolang知らない
もしかしたらRESTfulやMongoDBすら知らないのかもしれない
ここだけ時が止まっているんや カプセル化ってようは文章要約だからな。
文章要約を繰り返したら意味がわからなくなってあたりまえ。
120分映画を伝言ゲームで要約しまくったら最終的に「全米が泣いた」になって意味不明すぎになったようなもん。 >>90
ああそれで
Smalltalkいいのになんでこう世間は不便なんだと思ったらC++
の責任だったのか・・・ >>2
privateやprotectedにしても結局読み出し用アクセッサは付けることが多い気がする
破壊させない目的だけはそれでも維持されているのだが
>>3
頂点データは見られないとダメだろJK
レンダリングエンジンとの結びつきどうなってるんだ >>84
C++は下手に使うと核地雷にしかならないよな…
組み込み界はC使いが基本だからか、評価用ツールをWin32のCってのが多くて
たまに無惨なC++が生み出されることがあって…それはもう酷い >>87
そもそもコード無しのライブラリは拡張できないのは当たり前なのにそれを問題視してる寄生虫が騒いでるだけかと。 多重継承は書くのが楽で読むのが辛い。
保守性を下げるから（自分のために）自主規制すべきだと思う。 >>261
やっぱりあのXNAか、普及しかけていた記憶はあったが
そのままだと他への流用には向かないなあ javaはラムダ式やストリームが出て完全に死んだ
あんなパッと見で分かりにくくて理解しにくい仕様は
初心者どころか俺みたいな超玄人にすら受け入れられなかった
ある意味これらがパーフェクトオブジェクト指向言語だったjavaを
ぐだぐだにしてしまったと言っても過言ではない OpenGL ESはファイルからテクスチャ1枚読み込むｂﾌにもアホみたｂ｢に面倒臭いかｂ轤ﾈw
OpenGLの手法すら使えないとか何故そこまで削った…って感じだし GUIのプログラムばっかり書いてるから、オブジェクト指向はありがたい。 そのくらいの仕様変更はザラにある。
それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。
オブジェクト指向云々ではない。 >>263
えー便利じゃん
ループしてグダグダやってたのサラっと書けて >バイナリのライブラリしかない場合などは絶望的である。
もうオブジェクト指向どうこうの問題じゃねーな ３Dモデルの話も、人が作ったものが納得いかないけど、自分じゃ作れないから使い回しているだけだよね？ >>270
そう。オブジェクト指向関係なく、外部から情報参照の手段がないっていうだけ。
switchのゲームはMOD作れないからクソっていってるようなもん オブジェクト指向はGUIのための概念だから
ビジネスロジック組むのには要らない なにが困るってこういうのに影響されて方針がコロコロ変わるのが一番困る >>263
自分が理解できないからクソって・・・
恥ずかしくないの？ どうせモデル化に失敗するんだから最初からカプセル化なんかするなって事？
で、スパゲティになるの？ pythonこそ究極のオブジェクト指向言語だろ
型がないからインターフェースという回りくどい(俺は好きだが)実装すら必要なく、ポリモーフィズムを効かせられる
と思ったら関数型の書き方もできるし、すごい汎用性の高い言語
もうこれ以外使いたくない このスレでもオブジェクト指向の真髄であるポリモーフィズムを理解してる奴が殆ど居ないというところを見ると、オブジェクト指向不要論を語る以前の話に見える
ポリモーフィズムがわからなければデザインパターンも使えないし、オブジェクト指向は足枷にしかならん 理想と現実の乖離がデカイ。
現実寄りの方がまあマシって話しか？ >>278
型の無い言語っていくつかあるけどさ、最低限数値なのか文字列なのか、或いは何かの参照なのかの区別は有った方が良くないか？
プログラマーから見て 設計とかすっ飛ばしてCで手続き順にだらだら書くのらくちんだよなあ ぼかぁオブジェクト指向ってなにか分からないんだなぁ >>280
typescriptがよく使われてるのを見ると実際のところはね 全部おっぴろげたらテストケースヤバいことにならんのか？ カプセル化するスコープが間違っていて、カプセル化をやり過ぎているのが問題。
公式や絶対法則等の不変性の高い部分のみをカプセル化して、そこに任意性が必要なのであれば別途継承クラスを作れば良い。 本読んでみたことあるが、結局何がしたいんだか理解できんかったｗ オブジェクト指向否定おじさんはマルチスレッドで並列処理やったことないだろ python悪い言語ではないのだが、他の言語なんか知らんがpython最高！
pythonしか使いたくない！みたいなやつが結構いるんだよな
しかもC言語とかJavaを馬鹿にするんだよね
よくよく聴くと型もろくに知らないし、プログラミングの基礎知識全くないケースが多々ある
pythonでライブラリ使ってるだけで凄腕プログラマーみたいな意識になってるんだよな、恥を知った方がいいわ 一長一短だよ
全てパブリックにしてしまったらとんでもないことになる >>241
いわゆる「構造化プログラミング」だって
厳密に守った言語はほぼ皆無でしょう
Brainfuckくらいか？（笑） 人間が作ってるんだから品質がばらつくのは自然
そのうちAIが最適なモジュール分割、データ配置してくれるようになったら、人間なんて要らなくなるかな >>40
ある日アムロが「ニューガンダムの腕の調子が悪い」とアストナージさんに言いました。
アストナージさんが原因を調べると、どうもシリンダーの内の一本の設計にもともと問題があったようだ。
しかし修理しようにもアストナージさんはシリンダーを交換するためのハッチの鍵を持っていないためその問題の解決には至りませんでした。 >40
ターンAやレコンキスタで、使い方は分かるけど、修理改良出来なくなるようなモノ？ >>266
GUIのプログラムやってるとオブジェクト指向の
ありがたさが身に染みるよな >>2
先頭にアンダースコア付けるとMISRA違反になる
MISRAって意味のないルール（というか壊れたコンパイラを前提にした防御策）多いけどな OOPはフレームワークの作者が神になるものだったな。
メンテナンスは神がやるなら問題ないが引き継ぐと面倒になる。
OSSなんかC++からCに書き直したものもあったし可読性を考えると要らないんだろうな。 >>1
そもそも社会生活がオブジェクト指向なんだから
それを表現するにはオブジェクト指向が最適 >>289
こういうのも十分にウザい。pythonの
ライブラリ熟知するだけで大抵のものはかけるようになるし
何でもかんでも基礎から知らなければだめという考えが
そもそもだめだってことがなぜわからないのかね。
小ウイウやつに限って本人対して知識もないんだwｗ 後から当初目的とは違う使い方、違うスコープが必要になっただけじゃんw
クラス使わないでも起きうる話。 日本のプログラマって、自分は何も生み出さないくせに
他人に対するマウンティング大好きなおっさんばかりなんだよな。
こういうおっさんに限って「海外では技術的にどうこう」みたいな話が大好きだが
GITでかんたんに海外のオープンソースが見れるようになってわかったことは
「GAFA経験があるようなやつでも結構ろくでもないプログラム書いてんなー」って
ことなのよ。ただ、向こうは口も動かすけど手も動かす。
日本のプログラマは口ばっかりで手が動かない。ツイッターのPGクラスタで威張ってるアルファとか見てみ
なんも生み出してないやつばっか。 >>294
ちがうだろ、それを言うなら
ガンダムの腕のシリンダーの設計に問題ありそうだがが
現場の技術者はシリンダーのことはよくわからないのでどうしようもなかった
という話だろ。 >>304
WindowsでC++使ってると標準GUIライブラリがいかにありがたいかがよくわかる
MFCは色々小回りきかないし下手にC時代からやってるせいでWTLも馴染めず結局最低限のを自作した
Pythonは用途というか次元が違うからなあ
複雑な用途のためのスクリプト
同じ事C++でやろうとすると敷居が高すぎる
Javaなら何とかなるかもしれないが 結局よくわからなかったよ私には
アセンブラでごりごり書いてるのが好きだった >>310
VC++って結局の所DOSの時代に直接ハードウェアのポート
叩いてた時代と労力変わらんからな。ただ、ハードを
個別で意識しなくても済むようになっただけで。
カプセル化は悪ってw w w w w w
「オブジェクト指向＝カプセル化」ってどんなレイヤーでプログラム組んでんだよw w w w w w w
>>315
フレームワーク使わないと深い階層の関数をコールするのが大変そう >>314
リンクライブラリと可換のクラスしか作らない人なんじゃないのw オブジェクト指向が銀の弾丸ではないのは確か。
1から教育するのが大変だし、慣れるとCOBOLがかったるくなる。
カプセルカガーはモデルの変数にアクセスしようとしてるのかコントローラの変数にアクセスしようとしてるのかすら理解できてない
モデルの変数がアクセサであれなんであれ公開されてなかったり、コントローラの公開されてない変数にアクセスしなければならない、のであればそれは設計が間違っている
オブジェクト指向云々以前の話
>>272
これなんだよね
でもオブジェクト指向至上主義者は何でもオブジェクト指向の流儀に合わさせようとする
WEBのシステムとかに無理やりMVC持ち込みオブジェクト指向設計的に合わない所を
DDDやらORマッパー宛てはめようとかしてぐしゃぐしゃになる
データ中心設計してフロントエンドはフレームワーク無しPHPでSQLべた書きコピペしたほうが
はるかに生産性もメンテ性も高いぜ
WEBはGUIをブラウザが担い、ステートレスなHTMLファイルとHTTPリクエストをサーバーサイドが生成するだけなんだから
そこを無理くりオブジェクトでラッピングしようとするからぐしゃぐしゃになるのよ 大方、当初に無い仕様が出てきて、それを行うにはクラスの内部変数参照する必要が出てきたけど、ライブラリがバイナリ化されてて手詰まりになると。 変化する設計に対して柔軟に対応出来れば何でもOK。オブジェクト指向ありきで考えても失敗することはある。 オブジェクト指向が優れているのはマルチスレッドにおいてのみ
シングルトンみたいなクラスにしない限り別メモリで実行される事が保証されている
それ以外のメリットはない
別にメンテしやすいとか言うのもない こういうのカプセル化の話は出るけどポリモーフィズムとかの話は出ないなあ >>326
あのさ、自分でメリット上げておいて
そのメリット以外にはメリットないって言うのやめたら？ｗ
箱の中身は全部アタリ。なぜならハズレ以外にハズレがない
っていってるようなもんだ 第一マルチスレッドにおいて別メモリで実行されることが保証されているならば、
シングルスレッドでも別メモリで実行されることが保証されているわけだ
それもメリットだよね >>316
官公庁向けの案件だと、フレームワークすら1から作ることもざらにある。
既存のやつだと、特性を知っていればハックできてしまうから致し方ない所もあるが。 結論：privateにしたら、必ずsetterを用意しておきましょう。 >>316
フレームワークを操作するフレームワークが重なって
私のフレームワークは53万層ですよ 隠蔽しないとバカがめちゃくちゃして改修できなくなるから >>3
ファイルを2つに増やした段階で、2つのファイルを同期させるような仕組みを導入するべき Cで言うと「弄れなくなるからconstは使うな」って主張するようなもん？ コレコレ。
俺は知らないから唯物論か何かだと思ったけど
やっぱりＩＴ関連スレは突っ込んだ論点で話するよな 隠蔽されたデータに直接アクセスするって、それスパゲティコード生み出すだけじゃねーか
この職種向いてねぇから今すぐ辞めろ >>328
>>1があげてる例は多態性は関係ないしね。
頂点を取るようにインターフェイスの実装、アブストラクトクラスの継承をした場合、リスコフ置換の原則に反することになる。
この例の場合、設計が実態にそぐわないんだから、新しいクラスを用意すればいいだけ。 >>339
情報をどのレベルで隠蔽するかって話
結論は、必要なアクセサが無いならそのライブラリ使うなって事だw Cの引数のconstポインタはさ、OOPの考え方とは逆なんだよ
変数を使う側がconstを保障するんじゃなくて、使われる側が変更不可能な値を提供すべきだ
つまりconstを返すゲッタを書くのが真のOOP >>339
食材を詰めると料理が出てくる機械。
でも調理過程は見えない。これがカプセル化。
シェフ「これでは私好みの味付けにできない。オブジェクト指向は糞」これがこの記事の主張。 中途入社のやつに、お試しでプロジェクト任せたら、すべての変数をグローバル変数にして、不穏な動作するコード書いてるやついたな。関数の戻り値まで共通のグローバル変数にして、こいつ大丈夫かと思ったは。 >>350
カプセル化はメンバを外部から隠蔽することを指すでしょ。
調理過程を見えなくするのはオブジェクト指向であって、その調理過程をパターン化したものがgofに代表されるデザインパターン。 >>159
エンジンの仕組みがわからなくてもアクセルペダルを踏むことさえわかっていれば車は走らせることができるってやつか >>350
そのシェフ理由を言ってないよね？
シェフ「これでは私好みの味付けにできない。なぜなら手を洗えと書いてあるからだ。オブジェクト指向は糞」これがこの記事の主張。
こういう感じでは？ｗ
手を洗うと時間がかかる。その間に味が落ちてしまうのだ。
手を洗わなければ、最高の状態になったとわかった時反応できる
とかいう意味不明な理屈でしょ 初級者「オブジェクト指向はクソ」
中級者「オブジェクト指向は便利」
上級者「オブジェクト指向はクソ」 >>339
DLLが必要な機能を提供しないウンコだったらどうしましょう、って事じゃないの リミッターがあると最高速度が出せない
俺ならリミッターなしでもマシンを操れる
つまりリミッターはクソ
まあこういう理屈だろ。事実かもしれないが
普段からリミッター外して運用するのかよって話
ごくまれに意味があるかからといって普段からリミッター外すやつは馬鹿
オブジェクト指向もそれと一緒で、普段は使うべきもの
ごくまれに使わない例があったとしてもそれは例外でしかない
それにしても>>350の「主張」は本当に
「オブジェクト指向は糞」と言ってるやつの主張そのものだよ。
つまり「理由」を書かずに「オブジェクト指向は糞」と言ってるという例になってる オブジェクト指向は理想はいいのかもしれないけど
現場ではゴミの量産に一役買ってるからデメリットの方が大きいんだよな 的を得ない比喩で説明するから勘違いするやつが増えたんだよ >>359
オブジェクト指向・・・技術の話
現場・・・（お前の）人の話
デメリットが大きいのは技術ではなくて人の問題 また明日来て下さい。本物のクソコードをお見せしますよ 半端理解でつまんねぇ例えをする奴が大量に沸いてくる
オブジェクト指向の一番の問題点 >>364
知ったかの集まりだからな
業務でプログラマをやったことあるやつすら少なそう にわかとか知ったかとかでマウント取るのもオブジェクト指向スレらしいよな
難なく素人でも使いやすい方がいいに決まってる >>362
多くの人に受け入れられるのが技術の目的だろ
AIにでも書かせるならいいだろうけど >>367
> 多くの人に受け入れられるのが技術の目的だろ
受け入れられるとはどういう意味？それはだれが言ってるんだ？
飛行機の操縦も技術だが、多くの人に受け入れられてるか？
「素人でも使える」は「技術の目的」などではない 素人に使えるに超したことはないだろ
現実問題クソコード量産してんだから なんでもかんでもBaseクラスに機能を突っ込んどけば良い風潮 >>370
その理屈だと、全部ひらがなで書けば
「小学生でも読めるに越したことはないだろう」という話になる
上級者は技術を使いより複雑なものを作れるのに
なんで素人に合わせて苦労しないといけないんだ
先輩・上司は、お前はまだまだ技術力が足りん！などと言って
新人を引っ張っていかなきゃいけないためなのに
なんでへりくだって、あ、はい新人のあなたのレベルに合わせて
コードを書きますって言わなきゃならんのだ？
自己完結できない奴がコーディングなんてしちゃダメですよ実際のところ
つまり最後まで自分で責任を負って生産したことがない奴はコーディングなんてしちゃダメです
あれもできますこれもできますとかあれは自分がやったみたいなアレオレ詐欺とかどんなにお上手にアピールしたところで
テメェの生み出したウンコの片づけを他人に押しつけ転々といろんな現場と言語をこなしてきた奴はダメ
テメェの糞片付けずコピペの技術だけは一丁前でセイサンセーガーとスピード効率重視した挙句しまいには35歳定年を唱える
そりゃそうだ
テメェのやってきたことなんざファミレスのコックのアルバイトと同じレベルだからな
どっかから運ばれてきたものを温めたり焼き色つけたりしてノっけてモるだけなら時給９００円レベルで高校生だ
作った人が作ったプログラムが動いてる間ずっとそばにいるなんて殆どないんだからソースとか設計書とかはちゃんと引き継いでいかなきゃダメよ >>377
データだったりウィンドウだったりゲームの中のキャラだったり場合によっては装備品だったり色々
WindowsのWin32 APIでハンドルとかコンテキストとかあるけど、あれも典型的なオブジェクトだよ
例えばHDCっていう値と、それを使うための関数群なんてC++でいうとこのクラスみたいなもんだし、
HPENなんかをHGDIOBJにキャストして使うのはポリモーフィズムだ
逆にこういう連中のためにオブジェクト指向言語が作られたとも言える オブジェクト指向は正解を提示しているわけではなく、考え方でしかない。哲学なので >>351
グローバル社会にふさわしいグローバル変数
ローカルに閉じ込もってはだめ！ どんなものでも適切に使える人間にとっては役に立つし
使えない人間には危険なものになりうる
というか使えない人間そのものが危険なのか 俺がVBで書いたプロジェクトを見て
「VBとかだっせｗC#勉強して使えるようになれｗ」
ってバカにしてたオッサン「クラス」も「構造体」も知らなかった。 内容がよく分からないけど、一本糞が良いと言いたいの？ オブジェクト指向は愚かな考え。
排便メソッドを実装した人間クラスから美少女クラスが作れない。
http://monobook.org/wiki/オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない。
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れないとは、オブジェクト指向の設計の難しさを表現したものである。
概要 >>216
全く同感。普遍的なのは構造化でもOOPでもすっきりとした設計、明確なエラー処理につきるわ 腕自慢する年頃なのは判るけどw 言語は合わせるからプロジェクトは粛々と終わらせようぜ 定年まであと５年だわw オブジェクトが満足に作れないなら、何をしても駄目なんじゃ？ >>391
オブジェクト指向を全否定してるわけではなく、経年劣化する設計やコードにオブジェクト指向を適用すると大変な目に合う、ということ。
10年先を見据えて変更しやすいコードを書くのはオブジェクト指向関係なく困難だけど、オブジェクト指向でガチガチに書いちゃうと結局メリットだったはずの部分がデメリットになっちゃうってこと。 ■ このスレッドは過去ログ倉庫に格納されています
