カプセル化（英語：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)
大雑把にいうと、教科書の上では素晴らしく、最初は良くても、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。
医学的にいえば「手術ができない存在」であるといえる。- >>2
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。
ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。
実例
XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。 １行で読み込み、１行で描画できる素晴らしいものだ。ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。 物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。
そこで頂点データをGPUに送信後にGetData関数で返してもらうというトリッキーなコードで回避する。 しかし、この方法では動かない環境がある。 iOSやAndroidのOpenGL ESなんかがそうだ。 こいつらはGPUとの通信が一方通行。
そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくトリッキーな方法で回避する。 ファイルが２個になりました。 謎の不具合が発生しています。 片方のファイルの更新を忘れました。
カプセル化は恐ろしいね！
- シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に - 逆張りおじさん
- なんか基本情報技術者止まりの学生さんって感じの文章
- つまりどういうことや
- 8番のモジュールまだ～？
- 美少女クラスに排便メソッドを実行できない
- 俺が初めてつくったゲーム全体でシングル関数になってて笑う
関数の頭から後ろまでで1フレームの描画だからある意味美しくもあるけど - 究極のところアプリケーションの出力を他のアプリから自在に扱えるOSってのが理想
マーケットスピードなんかを利用して
株の自動売買を構築しようと思っても
内部データを読み出せないしな
自前描画のJava製となるとメモリハックも厳しい - オブジェクト指向プログラミング出来ない老害はとことん出来ないからな
- 頂点読めないのはプログラムのカプセル化とは関係ないだろ
だいたい、privateにしておこうと思ったようなデータに後からアクセスするようなことしてまともに動くわけがない
それこそデスマーチ確実だろ - 副作用の起きない処理はpublicでも問題ないだろうな
問題が起きるとすれば運用側の問題 - オブジェクト志向じゃないとツール使ったテストが難しくなりそうだが
その辺はどうなんだろね - 一般に公開されたライブラリとしてはパブリックな静的メソッドの集合の方が使い勝手が良い場合もあるが
自分たちで作ってるフレームワークとかだとクラス化して責任範囲明確化した方が安全だろ
どうしても後から公開しないといけないデータやメソッドが出てきたら単にソースいじって公開すれば良いだけだし - ファイルアイコンをクリックしたらアプリが立ち上がるのもオブジェクト指向でいいのか？
- 今更オブジェクト指向やめますって言われても
昔書いてた形で今風のアプリ作れなんて無理だわ、もう体に染み付いちゃたし - 俺プログラマだけどこういう話全然分かんね
何してたら理解できるようになるんだ？ - >>21
まだ経験の少ない若い人なら、もう少し経験積めば良い。
炎上プロジェクトを何度か経験すると、何が原因だとか、何によってコードが複雑化するのか、とかそういうのを考えるようになる。 - >>21
ほんとにプログラマか？ - この事例だと導入するライブラリを間違ってるだけでしょ
大量のグローバル変数地獄のほうがきついよ - 日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い - 振る舞いがわかってるんだから、必要になった時にそのオブジェクトだけ差し替えたら？
- そもそもアランケイの考えたものと今のオブジェクト指向が違うっていうね
オブジェクトなんて名前を使ったせいでオブジェクトが重要だと勘違いしてるし全員
よって失敗
ただ発展には貢献したそれだけ - >>27
smalltalkはあんま普及してない？ - Staticおじさんスレ？
- よー分からんな
実例の話は始めから触れないと問題ある部分があるのに選択したのが間違いじゃないの？
オブジェクト指向じゃなくても痒いとこに手が届かないみたいなことはあるよね - >>29
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに
それやらないでトリッキーな方法で回避するから余計面倒になってる - 昔作ったクラスを継承したり再利用したりなんて殆どない
データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん - 内部に状態を持つな
- オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する
オブジェクト指向は愚かな考え
コメント