カプセル化は愚かな考え

**デフォルトの名無しさん** · 2020/07/29(水) 17:17:58.13

■危険性

かつて偏差値の低い学校向けの情報処理系教科書において「カプセル化は大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心とした「インターネットを作った人たち」は「階層化の有害性（RFC 3439)」として「カプセル化は絶対にやめろ」としている。

大雑把にいうと、教科書の上では素晴らしく、開発を始めた最初のうちは良いが、将来的な改修の際に隠蔽されたデータにアクセスできないと解決できない問題が出てきて、非常に高確率でデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」などという概念はない。

ソースコードが存在し改修が可能であればカプセル化しても問題ない。ソースコードがあってもライセンス的に改修できない場合や、そもそもバイナリのライブラリしかない場合などは絶望的である。

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)

**デフォルトの名無しさん** · 2020/07/29(水) 17:19:08.69

■ 実例

XNA（MonoGame）では標準で3Dモデルを手軽に扱えるModelクラスが用意されている。１行で読み込み、１行で描画できる素晴らしいものだ。

ただしこのModelクラスを使うと頂点データは遮蔽されておりアクセスできない。物理演算エンジンに食わせるのにどうしても頂点データが必要なのにだ。

世界中の誰もが同じ問題で悩んでいるようでstackoverflowに回避策が書いてあった。内部でGPUへ送信したときに使用したGPUにアクセスする関数ポインタは公開されているのでGetData関数でそのまま返してもらうトリッキーなコードでめでたく回避できた。

しかし、時は流れこの方法では動かない環境が登場した。iOSやAndroidだ。こいつらが採用するOpenGL ESはGPUとの通信が一方通行だ。そこで事前に3Dモデルから頂点データを抜き出し別ファイルに保存しておくという一段とトリッキーな方法で回避する。みごと1モデルのファイルが２個になりました。

さらに時は流れた。あるとき謎の不具合が発生。連日連夜のデバッグ作業。原因は片方のファイルの更新を忘れていただけでした。

カプセル化は恐ろしいね！！

https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Graphics/Model.cs

**デフォルトの名無しさん** · 2020/07/29(水) 17:20:04.13

そもそも>>1-2はテスト以前の問題です。

カプセル化■プライベートメソッドをテストする方法
https://mevius.5ch.net/test/read.cgi/tech/1593949666/

**デフォルトの名無しさん** · 2020/07/29(水) 17:21:10.32

仕様変更

それは雲の上で決まったことなので底辺社畜のITドカタにはどうすることもできない。
意見を言おうにも雲の上にいる奴らの顔すら知らない。
それこそが階層化で起きることだ。

オブジェクト指向云々ではない。

**デフォルトの名無しさん** · 2020/07/29(水) 17:21:26.28

シンプルなほうが解読しやすいよね
散逸して現物しか残ってない場合とか特に

**デフォルトの名無しさん** · 2020/07/29(水) 17:21:57.79

データベースに出し入れするだけの業務システムなんかは問題ない。
データベース上のデータなんてグローバル変数となんら変わらない。
クラスは構造体としてしか使わないから深い階層化も起きないし。

**デフォルトの名無しさん** · 2020/07/29(水) 17:22:26.03

>>1
C++が流行りだしたころに、これ言ったら変な目で見られたわ。
設計能力と未来を見通す能力がある人限定なんだよ。
大人数だと低い方に合わされるから、大人数プロジェクトには不向き。優秀な少数精鋭プロジェクトなら良いんだけどね。

**デフォルトの名無しさん** · 2020/07/29(水) 17:22:44.93

日本の場合はカプセル化されてようがいまいが基底クラスなんて弄ったら再テストしなきゃいけないから
同じ機能を持ったクラスを作るので意味が無い

**デフォルトの名無しさん** · 2020/07/29(水) 17:23:04.24

昔作ったクラスを継承したり再利用したりなんて殆どない

データと関数数個だけで済むものを
無駄にクラス化して
ヘッダと実装にわけて無駄にコード追いにくくするのはあかん

**デフォルトの名無しさん** · 2020/07/29(水) 17:23:37.53

>>2
この実例は良くないよね
Modelクラスが何かにラップされてるならその元を探して改良すべきなのに、
それやらないでトリッキーな方法で回避するから余計面倒になってる

**デフォルトの名無しさん** · 2020/07/29(水) 17:24:14.15

>>10
その相手が壮大なオープンソースのフレームワークで
改変した修正パッチが開発チームから拒絶されたら死ぬ。

フォークしたとして誰がメンテナンスするんだよ

**デフォルトの名無しさん** · 2020/07/29(水) 17:24:30.77

内部に状態を持つな

**デフォルトの名無しさん** · 2020/07/29(水) 17:24:41.28

オブジェクト指向で設計やるとしばしば手段が目的化してしまって不必要に複雑化する

**デフォルトの名無しさん** · 2020/07/29(水) 17:25:11.25

想像を絶する馬鹿が想像を絶するカプセル化をしてしまうんだよなあ……

**デフォルトの名無しさん** · 2020/07/29(水) 17:25:39.61

>>2
特定の事例はオブジェクト指向とかクラスが悪いわけじゃなくて
その設計が失敗してるだけですね

**デフォルトの名無しさん** · 2020/07/29(水) 17:27:31.45

>>15
XNAというマイクロソフトの天才たちが推し進めたプロジェクトでも失敗しているという事例だし、凡人だったらもっと悲惨なことになる。

**デフォルトの名無しさん** · 2020/07/29(水) 17:28:38.45

おっそろしーなぁ

**デフォルトの名無しさん** · 2020/07/29(水) 17:28:52.07

オブジェクト思考って何？
誰か説明して

**デフォルトの名無しさん** · 2020/07/29(水) 17:29:11.35

オブジェクト原理主義者のコードを引き継ぐ事になった時の絶望感は異常

**デフォルトの名無しさん** · 2020/07/29(水) 17:29:25.85

「カプセル化は悪」「カプセル化はオブジェクト指向ではない」というのがやっと広まりだした。

**デフォルトの名無しさん** · 2020/07/29(水) 17:29:41.38

ようするに「仕様変更の恐ろしさは異常」

**デフォルトの名無しさん** · 2020/07/29(水) 17:29:50.61

未来予測できるが勝負所

**デフォルトの名無しさん** · 2020/07/29(水) 17:30:12.05

カプセル化は隠蔽体質ってことですね

**デフォルトの名無しさん** · 2020/07/29(水) 17:30:38.36

>>15
XNA作ったマイクロソフトの超エリートたちですら設計ミスをするくらいオブジェクト指向は難しい。

**デフォルトの名無しさん** · 2020/07/29(水) 17:31:42.76

組み込みだと細分化し過ぎるんじゃね？
業務システムで細分化することはまずない。

**デフォルトの名無しさん** · 2020/07/29(水) 17:32:08.32

業務システムだとDBいじくるだけだから深い階層構造に関わることはまずないだろ。
DBというグローバル変数をクラスという名の構造体にコピーして、編集して、書き戻すという単純作業の繰り返し。

**デフォルトの名無しさん** · 2020/07/29(水) 17:32:50.34

結論：privateにしたら、必ずgetterを用意しておきましょう。

**デフォルトの名無しさん** · 2020/07/29(水) 17:33:09.46

小規模なら問題ない

**デフォルトの名無しさん** · 2020/07/29(水) 17:33:58.47

今一番勢いのある言語であるPythonは完全なプライベートじゃ無いんだよな