オブジェクト指向ってクソかよPart5

**デフォルトの名無しさん** · 2019/10/08(火) 15:46:57.38

無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

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

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

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

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

前前前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/
前前前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/
前前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/
前スレ
オブジェクト指向ってクソじゃねぇかよPart4
https://mevius.5ch.net/test/read.cgi/tech/1556462315/

**デフォルトの名無しさん** · 2019/10/08(火) 16:32:40.81

オブジェクト指向はクソじゃなかったよ Part3
https://mevius.5ch.net/test/read.cgi/tech/1542885246/

**デフォルトの名無しさん** · 2019/10/08(火) 16:33:29.66

状態管理技術★オブジェクト指向 VS モナド(関数型)
https://mevius.5ch.net/test/read.cgi/tech/1538080434/

[転載禁止] オブジェクト指向を今すぐやってください(c)2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1414409620/

オブジェクト指向は愚かな考え。この世は計算式 ★3©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1451927425/

LinuxカーネルはC言語なのにオブジェクト指向
https://mevius.5ch.net/test/read.cgi/tech/1543063194/

C++はクソだがオブジェクト指向がクソなのではない
https://mevius.5ch.net/test/read.cgi/tech/1544632246/

オブジェクト指向以外のメリットを書くスレ
https://mevius.5ch.net/test/read.cgi/tech/1542808008/

オブジェクト指向の活用方法を教えて下さい
https://mevius.5ch.net/test/read.cgi/tech/1395751447/

**デフォルトの名無しさん** · 2019/10/08(火) 21:07:58.90

前スレ最後の一ヶ月でドドっと進んだな

**デフォルトの名無しさん** · 2019/10/08(火) 22:15:07.68

staticおじさん超バカにしてたんだけど
前スレにリンクあったから約10年ぶりに読んでみたらちょっと印象変わったわ
むしろOOを必死に説明しようとしてる人たちの煽り耐性の低さと中身の薄さに驚いた
https://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html

**デフォルトの名無しさん** · 2019/10/08(火) 23:03:10.93

信者は盲目で物事の本質よりも自分が信じた教条や面子が大事だからな
だまされたともしらず

**デフォルトの名無しさん** · 2019/10/08(火) 23:12:45.74

それは、このスレについても一緒

**デフォルトの名無しさん** · 2019/10/08(火) 23:56:30.29

なにげに１スレが良スレ

staticおじさんのほうが自分がわからないことを認めてル分だけマシ

なにがメリットなのか説明できないのに、
持論を押しつけてくるバカが湧いてくるのは変わらん

**デフォルトの名無しさん** · 2019/10/09(水) 01:01:29.83

改めて1スレ読んでみた。
身分がヨパラテ書いた批判ﾚｽの誤記がやけに目立ったｗ

**デフォルトの名無しさん** · 2019/10/09(水) 01:06:10.21

>>9
× 身分
○ 自分

…orz

**デフォルトの名無しさん** · 2019/10/09(水) 04:24:15.79

当時はRailsが流行ってたからなんじゃないの

**デフォルトの名無しさん** · 2019/10/09(水) 07:09:04.23

なんで「カプセル化ってクソかよ」ってスレタイにしなかったの？

**デフォルトの名無しさん** · 2019/10/09(水) 09:11:51.05

>>1のマッチポンプという言葉に触発されてチンポをシコシコするようになったのかな

**デフォルトの名無しさん** · 2019/10/09(水) 09:20:02.77

継承・カプセル化・多態のオブジェクト指向三本柱マンのうち最初に倒壊したのはカプセル化じゃなくて継承なんだがな。
やれ継承より委譲だの、継承よりコンポジションだの、オブジェクト指向界隈内外からボッコボコよ。

**デフォルトの名無しさん** · 2019/10/09(水) 09:47:07.00

まじかよ2019年にもなってこんなこと言う奴いるのかよ。終わってるな日本。

**デフォルトの名無しさん** · 2019/10/09(水) 12:41:20.40

>>15
それ3000年前に土器焼きながら埴輪が言ってた

**デフォルトの名無しさん** · 2019/10/09(水) 13:12:12.54

最初に倒壊したのは多態じゃないの?
ぱっと見きれいに書けるんだけど、次第にグダグダになる
カプセル化が次かな。setter と getter を使わないと書けない
というところで破綻している

**デフォルトの名無しさん** · 2019/10/09(水) 13:48:29.97

>>17
多態は普通に使われてるし、
カプセル化の話に、setter、getterは関係ない

**デフォルトの名無しさん** · 2019/10/09(水) 15:17:31.68

完全に倒壊して以後作られた言語が腫れ物に触るように扱ってるのは継承だけ。
逆に言うと他二つは生きてる。
三本柱→二足歩行だから、
おじいちゃんから青年に若返ったとも言える。

**デフォルトの名無しさん** · 2019/10/09(水) 15:38:09.54

>>19
いや、継承も普通に使われるから。
さっきから話が飛躍しすぎているのだが、何なの？
何かの記事の引用？

**デフォルトの名無しさん** · 2019/10/09(水) 17:06:48.31

まあアレだよね。自分の設計の下手さを
言語のせいにしてるっていうよくある構図

**デフォルトの名無しさん** · 2019/10/09(水) 17:33:28.21

>>18
多態がきれいに決まった例を教えてくれ。
グダグダになった例しか私は知らないが

カプセルかは引数経由でしか内部状態の参照、書き換えを
許さないという意味だから、setter, getter の話では?

**デフォルトの名無しさん** · 2019/10/09(水) 17:47:56.44

>>22
お前なんか考え方がおかしいぞ。
なんだよきれいに決まるって

既存の物理法則か何かを多態で表現できるかどうかとか
そういう話してるんじゃないぞ

「ソフトウェアを作る時」に多態を使うんだよ。
当てはめるんじゃない。ソフトウェアの設計の話だ

多態の例ならGUIシステムで多用されてるだろ。
各コンポーネントはrender()メソッドを持っていて
各コンポーネントそれぞれのやり方で見た目を描画するとかさ

**デフォルトの名無しさん** · 2019/10/09(水) 17:50:35.35

>>22
> カプセルかは引数経由でしか内部状態の参照、書き換えを
> 許さないという意味だから

ぜんぜん違う。

obj.value = obj.value + 1

↑これはカプセル化が行われてるかつ、引数経由ではない内部状態の参照・書き換え方法だ

**デフォルトの名無しさん** · 2019/10/09(水) 18:05:43.18

だからさー、頭いいやつがGUIのフレームワークとか作るのはおおいに結構だし、
凡人がそのサブクラスで画面を作るのもいいんだよ

ただ凡人がクラスデザインを語るなっつーの

**デフォルトの名無しさん** · 2019/10/09(水) 18:13:03.42

凡人は画面にボタンとかポトペタすればいいし、
クリックのイベントに業務のロジックを構造化プログラミングすればいいんだよ

ボタンと画面の描画は、フレームワークが適切なイベントで描画してくれるよ
画面とボタンの描画イベントが呼ばれるし、ボタンも画面もウィンドウのサブクラスかもしれないけど
凡人は気にするな

**デフォルトの名無しさん** · 2019/10/09(水) 18:20:51.58

>>22
自分は18ではないが...

strage = usb
または
strage = sdCard

string text = strage.read(ファイル名)

みたいな記述はよくやる。
※組み込み開発

**デフォルトの名無しさん** · 2019/10/09(水) 18:23:55.93

>>24
カプセル化の唯一無二の定義があるわけじゃないからそこをすり合わせないと。

それにその例はカプセル化が行われると言えるかどうか外からでは分からないよね
↓こういうコードの一部だったら一般的にはカプセル化されてるとは言わないと思う

struct Object
{
int value;
};

struct Object object = {0, 0};
object.value = object.value + 1;

あとRubyみたく'value='メソッドに引数を渡してる糖衣構文と捉えることもできるから
引数経由(メソッド経由のことだよね？)と言えなくもない

object.value=(object.value + 1)

**デフォルトの名無しさん** · 2019/10/09(水) 18:44:13.89

>>28
> カプセル化の唯一無二の定義があるわけじゃないからそこをすり合わせないと。

オブジェクトの内部表現とインターフェースを分離させること

この分離により、複雑な内部構造をシンプルに見せたり
インターフェースを変更すること無く、内部のデータ構造を効率のいい形に改善したり
互換性を保ちつつリファクタリングしたりと言ったことが用意になる

**デフォルトの名無しさん** · 2019/10/09(水) 18:54:59.17

>>25
凡人とそうでないやつの違いがわからんし
お前も聞くたびに違うこと言うから誰も相手にしなくなったんだろう

**デフォルトの名無しさん** · 2019/10/09(水) 18:56:06.05

カプセル化されていれば、インターフェースを変えることなく
内部構造を変更可能になる。

ということは、Rubyなんかは、普通に書いてもそれが出来るので
必ずカプセル化が使われていると言える。

**デフォルトの名無しさん** · 2019/10/09(水) 19:47:12.49

>>22
カプセル化はもっと、シンプルに考えた方がいい。
カプセル化の意義は責務分割を行うことに意義がある。
setterとgetterを用意することが本質ではない。
※結果的に、private変数にアクセスするためのメソッドを用意する形になるが、それが本質ではない。

カプセル化する際は、クラスを使う人側の気持ちを考えて実装すべし。
setX,getYというメソッドを並べまくっても使いにくいクラスが出来上がるだけだから注意だ。

**デフォルトの名無しさん** · 2019/10/09(水) 22:25:07.64

何か滑った感のある、新興宗教で頭わいたようなレスだな

あ · 2019/10/09(水) 23:03:33.40

>>29
俺もほぼ同じ理解なんだけど
そうするとgetter/setterは呼び出し側が依存してるインターフェースを変えずに
内部の実装を変更できるようにする目的で用意するものなので
カプセル化を実現する手段の一つに該当するんじゃないの？

ん、あれ、カプセル化にgetter/setter関係ないって書いたのと同じ人だと勘違いしてた
ま、カプセル化 == getter/setterでしょって言われるとそりゃ違うよってなるよね

**デフォルトの名無しさん** · 2019/10/09(水) 23:58:13.23

継承は間違った使い方が多すぎるから批判されてる
単なるコード共通化とかな
それなら無くしちまえってのが最近の流れでは

**デフォルトの名無しさん** · 2019/10/10(木) 00:06:58.68

>>34
もう少し勉強したほうが良いよ。getter/setterを別の関数として
用意しなければいけないのはJavaぐらいだから

**デフォルトの名無しさん** · 2019/10/10(木) 00:11:30.44

>>35
間違ってるも糞もないと思うんだけど

**デフォルトの名無しさん** · 2019/10/10(木) 00:38:19.01

>>36
関数用意しなければいいとかそういう便宜上の問題じゃないだろ
たわけ

**デフォルトの名無しさん** · 2019/10/10(木) 01:48:18.01

>>38
だから関数を使わない（つまり引数も使わない）で
obj.value = 1 とか v = obj.value が使える状態で
カプセル化できるって言ってんだよ。多くの言語では。

↓ これが間違いだってわかるだろ

> カプセルかは引数経由でしか内部状態の参照、書き換えを
> 許さないという意味だから

**デフォルトの名無しさん** · 2019/10/10(木) 02:06:50.75

自分で書こうと思ったコードがまんま見つかったので拝借ｗ

JavaScriptの例な
https://qiita.com/hogefuga/items/eefbbf6f4d2ff682c7e0

console.log(object.value); // no value
object.value = 'test';
console.log(object.value); // value: test

↑これは明らかにカプセル化されてる。
（リンク先を見ればgetter/setter経由なのがわかる）

しかし、objectの実装を以下のように変えても全く同じように動く
const object = {value: 'no value'};

ここでなんかおかしな話だなと気づかなければいけない。
クラスのインターフェースは全く変わらないというのに
クラスの実装によってカプセル化されてる or されてないが決定するのはおかしな話。
もちろんそんな変なことはない。両方とも「カプセル化されてる」んだよ。

Javaにおいて、カプセル化するというのは「getX/setX関数のみを使いパブリックフィールドを直接触らないようにすること」
その理由はパブリックフィールドを直接使うと、内部実装を変更したときにインターフェースが変わってしまうことがあるから

だから、Javaでは全てを「getX/setX関数経由でアクセス」すること＝カプセル化であるが、
JavaScriptにおいては、パブリックプロパティを直接参照しても、内部実装を変更したときにインターフェースが
変わらないようになってるから、JavaSciprtではデフォルトで全てのオブジェクトがカプセル化されてると言える

このように言語仕様でデフォルトでカプセル化されてる（もしくはカプセル化のための専用の機能がある）言語には
C#、Ruby、Python、PHP等がある。

言語仕様にカプセル化サポートの機能がある言語では、「引数経由でしか内部状態の参照、書き換えない」は間違い。