-
カプセル化（英語：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」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
- >>2
ゲッタセッタ使えよｗゲッタセッタ実装できないほどプライベートならそれはもう本当に使ってほしくないんだろ
実例XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。
ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。
世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。頂点データをGPUに送信した直後にGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。
しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。
さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。
カプセル化は恐ろしいね！！
- >>3
カプセル化がわるいのではなく
そのクラスの設計が悪いだけじゃないか
必要なものは外部からアクセスさせるべき - >>52
必要な人は少数
必要ない人には触らせたくないどうするのが正解なの？
- >>59
読取専用 - 底辺が集まる環境では重要
- 未来を見通せるなら問題ないよね
- 使う人の中な変な人混じると変になる
- 適材適所
- これオブジェクト指向が悪んじゃないだろ
オブジェクト指向が誤解されて広まったせいだろ - 堀井社長↓
- ぼく係長「この愚か者めが！」
- デスマーチになって初めて設計ミスに気がつく
- 消えたデータ
- サーバクライアントモデルだと
サーバ内部は雪駄下駄でしかアクセスできないから
カプセル化されているようなもの - よくある
- ポリモーフィズムでみんな挫折するよねｗ
- 業務システムでこれやるとだいたいセキュリティホールになる
- ケースバイケースだろ。プライベートなメンバ変数を定義して、その全てにSetterを用意する阿呆な設計は論外だけどな。
- ＞将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、
これってオブジェクト指向が生み出す問題ちゃうやろ？
- アクセサメソッド用意しとけば問題ないだろ
- コード生成こそAIにやらせろ。いいコード書くぞ絶対。
- >>22
問題はその精製AIを書くAIが必要な事だ - 玄人指向
- 未だにこの考え方が理解できない。
- >>1
オブジェクト指向で挫折した人？ - カプセル化というと噛みつかれるけど
独立性を高めるというと黙る不思議 - OOPはゴミプログラマーが混ざると破綻する
- >>28
だな、そして、プログラマーの9割がゴミプログラマーである
ゆえに、「オブジェクト指向は愚かな考え」という結論に至る - じゃ、カプセルホテルはいけないっていうのかよ？
- オブジェクト言語は情弱→手続言語は情弱→アセンブラは情弱→機械語は情弱→？？？
- そうは言うがクラス内部でしか使われないクソみたいな変数が外から見えてるようなライブラリ使いたいか？
- >>31
触るとコンパイラ警告を出すだけで十分だと思うけどね。 - これこそ
考えるな、感じろ
の分野だと思ってるわ - オブジェクトベースかタスクベースかって話じゃないのか
- そもそもカプセル化はオブジェクト指向ではない
- せめてprotectedにしておいてほしいよな
- アホがコード書くから改修が面倒になるだけでオブジェクト指向関係ないだろ
- >>37
コードより前に設計がアホなんだろう - この記事書いた人頭悪そう
- あとから出てきた環境では対処できないとかよくある
- 全然わからん。
ガンダムでたとえてくれ。 - >>40
宇宙でアムロが新型ガンダムを受け取って乗ったら足を操作する為の装置がなかった
宇宙で戦ってる間は問題なかったが、地上に降りることになって詰みました - >>62
すげーわかった気がするサンキュ - アホ仕様
- 追加の開発がない売りきりだと問題は起きないんだけどね
- 改修の限界
- 鋼鉄の鎧を着たらウ●コできなくなって漏らすようなもんだな
- 結局COBOLが言語として一番素晴らしいつてことか
- 他人の作ったライブラリを組み合わせてるとよく起きる
- privateとfinalは要らんと思うがprotectedは必要
継承すれば制約外れるようにしとけば問題ないしカプセル化の問題じゃないよね - オブジェクトの考え方が人によって違うから
- 今はどんなのが良いの？
- 昔、通信ライブラリで送信元の情報がバッサリ消えているのがあったな。
構造体に1個追加させるのに東京と京都を往復しまくって半年かかった。 - 排便メソッド
- オブジェクト指向のおかげでプログラミング辞められました(´・ω・｀)
- >>56
転職したの？ - ＞大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。医学的にいえば「手術ができない存在」であるといえる。
何言ってんだこいつ
- >>57
経験ないの？ - カプセル化すれば内部は隠蔽されていても、入出力がはっきり分かれば
それを組み合させて簡単にシステム構築できるんじゃないのか？
まあ、よくわからんが。 - 変数に関数なんか入れられっかっての
そんなこんなでいつもストレスが(´・ω・｀)
オブジェクト指向は愚かな考え
ニュー速
コメント一覧