オブジェクト指向ってクソかよ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等がある。

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

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

ようするに、今話をしてるのは、オブジェクト指向のカプセル化とはどういうことなのか？
という話なのだから、特定の言語での実装の話をするのは間違い。

"オブジェクトがカプセル化されていれば" インターフェースを変えること無く
内部の実装を変更することが可能になる。

言い方を逆にすると、インターフェースを変えること無く内部の実装を変更することが可能であれば
"そのオブジェクトはカプセル化されている" ということ

**デフォルトの名無しさん** · 2019/10/10(木) 05:56:07.99

継承は、10年くらい前はmixinだのtraitだの流行ったけど、今やどうでもいいわって感じだな

**デフォルトの名無しさん** · 2019/10/10(木) 08:58:56.73

1のテンプレ、時代遅れすぎないか？

**デフォルトの名無しさん** · 2019/10/10(木) 09:35:51.74

最先端だろ

**デフォルトの名無しさん** · 2019/10/10(木) 22:18:20.63

>>40
カプセル化の概念を狭く捉えすぎ
Javaのgetter/setterやRubyのアクセサ、C#のプロパティなんかは
カプセル化を実現するための手段の一つであってそれイコールカプセル化じゃない

それにJSでもRubyでもC#でも直接インスタンス変数にアクセスしてるコードを
getter/setterやアクセサやプロパティ経由に変更した場合に呼び出し側に変更が必要な場合もあるから
デフォルトでカプセル化されてるとか考えるのは間違ってるよ

人にもう少し勉強したほうが良いよとか言う前に自分が勉強しようね

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

…カプセル化じゃない
…間違ってるよ
…勉強しようね

**デフォルトの名無しさん** · 2019/10/11(金) 01:26:24.59

>>46
それな。自分の意見を何一つ言ってないｗｗｗ

**デフォルトの名無しさん** · 2019/10/11(金) 01:37:36.70

たまにクラスにprivateが無いからカプセル化できないと言ってるやつがいるが、
「_で始まる変数名はprivateとする」という規約を作れば実現可能

C言語でオブジェクト指向をするという話と同じなんだよ。
C言語はオブジェクト指向言語ではないのでクラスなどが無いが
だからといってC言語でオブジェクト指向ができないわけじゃない。

言語機能として、privateやプロパティはカプセル化専用の機能であるが
カプセル化専用の機能がないからと言って、カプセル化ができないわけじゃない。
カプセル化専用の機能がなくとも、「_で始まる変数名はprivateとする」
「publicフィールドを使わずに、関数経由で読み書きする」という"規約"でカプセル化出来る。

関数経由で読み書きするのは、カプセル化専用の機能（の一つ）が無いJavaで
カプセル化するための"規約"に過ぎず、多くの言語では関数経由にする必要がない。

いずれにしろ、カプセル化をどうやって実現するかは言語の機能によって変わるが
カプセル化の概念は、内部構造とインターフェースを分離するして
外から内部構造を直接いじらないようにすること

**デフォルトの名無しさん** · 2019/10/11(金) 07:28:14.10

プログラムの基礎であるメンバのスコープまたは
シンボルの命名規則を使ったアクセス制限規約のこと言ってんのかよ
元々簡単な筈のことなのに説明が下手にくどくて、
煙に巻かれて読んで損したような気分

**デフォルトの名無しさん** · 2019/10/11(金) 08:30:07.55

>>49
間違い。文章短いのに何もわかってない
いや、短いからわかってないのかｗ

**デフォルトの名無しさん** · 2019/10/11(金) 12:59:52.11

larabelとかよくできてるじゃん

**デフォルトの名無しさん** · 2019/10/11(金) 14:21:29.12

カプセル化はデータとデータに対する操作をセットにすること

privateでデータを隠すのはデータ隠蔽
インターフェースで実装を隠すのは情報隠蔽

**デフォルトの名無しさん** · 2019/10/11(金) 14:35:13.43

× カプセル化はデータとデータに対する操作をセットにすること
○ オブジェクト指向はデータとデータに対する操作をセットにすること

データとデータに対する操作をセットにすることは、カプセル化とは関係ない

**デフォルトの名無しさん** · 2019/10/11(金) 14:38:29.98

privateでデータを隠すのはデータ隠蔽
インターフェースで実装を隠すのは情報隠蔽

そしてカプセル化という概念は、
「データ隠蔽」と「情報隠蔽」を使って実現するもの

privateやインターフェースがなくても規約等で「データ隠蔽」と
「情報隠蔽」相当のことを行うことも可能だが面倒になりやすい。
そのために言語が用意してくれる機能がprivateやインターフェース

**デフォルトの名無しさん** · 2019/10/11(金) 14:42:40.80

オレオレ定義の押しつけあいで言葉遊びしてて虚しくねぇの？

**デフォルトの名無しさん** · 2019/10/11(金) 14:45:08.49

一般的な定義を言ってるんだが？

**デフォルトの名無しさん** · 2019/10/11(金) 15:05:22.26

>>53
それどこ情報？

**デフォルトの名無しさん** · 2019/10/11(金) 15:06:27.08

>>54
カプセル化の定義は何？

**デフォルトの名無しさん** · 2019/10/11(金) 15:11:03.25

ちなみにワイはwikipedia
オブジェクト指向はオブジェクトを大事にします
ってことなので値と操作をセットにすることとは違うよ

**デフォルトの名無しさん** · 2019/10/11(金) 15:24:31.99

>>57
https://stackoverflow.com/questions/13913174/encapsulation-vs-information-hiding

**デフォルトの名無しさん** · 2019/10/11(金) 15:28:02.10

>>60のリンク先を更に探すとここにたどり着いた

http://web.archive.org/web/20080906224409/http://www.itmweb.com/essay550.htm

**デフォルトの名無しさん** · 2019/10/11(金) 15:29:01.27

読めない(´・ω・`)

**デフォルトの名無しさん** · 2019/10/11(金) 15:30:20.85

>>60
僕のが正しいですよね

**デフォルトの名無しさん** · 2019/10/11(金) 15:34:07.32

いいえ

**デフォルトの名無しさん** · 2019/10/11(金) 15:53:18.86

>>64
いいえじゃないが

**デフォルトの名無しさん** · 2019/10/11(金) 15:54:47.89

ちなみに僕はJavaのブロンズの資格持ちです
Javaの試験では僕が示したとおりに解答しないと落ちます

**デフォルトの名無しさん** · 2019/10/11(金) 15:56:16.21

僕の定義は一般的ですよ
全世界で行われてるプログラミングの最も人気のある試験での模範解答なので

**デフォルトの名無しさん** · 2019/10/11(金) 15:58:39.66

そしてあなたはカプセル化を説明できていない

**デフォルトの名無しさん** · 2019/10/11(金) 16:01:06.01

カプセル化とは何か？

**デフォルトの名無しさん** · 2019/10/11(金) 16:03:57.37

ウインダムとかミクラスとかアギラとか

**デフォルトの名無しさん** · 2019/10/11(金) 16:06:36.86

>>41で書いたとおり

"オブジェクトがカプセル化されていれば" インターフェースを変えること無く
内部の実装を変更することが可能になる。

言い方を逆にすると、インターフェースを変えること無く内部の実装を変更することが可能であれば
"そのオブジェクトはカプセル化されている" ということ

**デフォルトの名無しさん** · 2019/10/11(金) 16:15:29.39

>>71
それ情報隠蔽やで

**デフォルトの名無しさん** · 2019/10/11(金) 16:15:57.04

試験落ちてまうど

**デフォルトの名無しさん** · 2019/10/11(金) 16:17:48.83

>>72
情報を隠蔽することは必ずとも必須ではない
すべてさらけ出していたとしても、
インターフェースを変えること無く内部の実装を変更することが
可能になっていればカプセル化されてると言える。

**デフォルトの名無しさん** · 2019/10/11(金) 16:19:56.39

>>74
君の思いはわかったけど独りよがりの思い込みに価値などない、君はJavaブロンズに受からない

**デフォルトの名無しさん** · 2019/10/11(金) 16:20:25.93

君は完全に間違っている

**デフォルトの名無しさん** · 2019/10/11(金) 16:21:29.10

カプセル化は値と操作の一体化のこと

**デフォルトの名無しさん** · 2019/10/11(金) 16:26:03.75

Javaブロンズの前で君たちの浅はかな理解など取るに足らぬ

**デフォルトの名無しさん** · 2019/10/11(金) 16:43:07.90

カプセル化おじさんはちからをためている。

**デフォルトの名無しさん** · 2019/10/11(金) 17:10:40.83

どうしてキャプセレチオンしないのよーッ！

**デフォルトの名無しさん** · 2019/10/11(金) 17:48:10.46

ところで、ここまでオブジェクト指向をクソだとする根拠があがらないのはなぜ？
オブジェクト指向プログラマーvs誰がとは言わんがオブジェクト指向プログラマー気取りが激突するスレかな？

**デフォルトの名無しさん** · 2019/10/11(金) 17:57:40.40

>>81
そもそも、オブジェクト指向にメリットが無いからな
強いて言えば単に費やす時間が無駄なだけ

オブジェクト指向とはソースファイルのどこに処理を書くか？
ただそれだけの技術である

→実はどこに書いたって動く（核爆）

**デフォルトの名無しさん** · 2019/10/11(金) 18:02:01.44

オブジェクト指向がクソなのはインスタンス変数の存在のせい

できるだけメソッドの行数を減らすとかインスタンス変数を使わないメソッドはオブジェクト指向じゃないとか巷で言われてるせいでそれを真に受けた意識高い初心者がゴミのようなコードを量産してしまうところにオブジェクト指向の限界を僕は感じましたよ

**デフォルトの名無しさん** · 2019/10/11(金) 18:14:37.08

オブジェクト指向で作られたhello worldを見ればわかるがオブジェクト指向は過度な抽象化を促進する抽象化圧力つまりアブストラクションプレッシャリングアクセラレイトがかかるからそれをいなせる胆力がないと使いこなすのは難しい

**デフォルトの名無しさん** · 2019/10/11(金) 18:21:24.34

>>83
なるほど、staticおじさんがstaticおじさんになった時の主張に似ているね。

オブジェクト指向の定義はさておき、インスタンス化のメリットはクラスという型から必要な数だけオブジェクトを生成できること。
そのメリットが無いのならJavaやC#のMathみたいにstatic化すればいいじゃんって思うし、オブジェクト指向をクソ呼ばわりする根拠が弱い気がするが...。

実際、自分もMathみたいにインスタンス化が不要であればstaticにするし。
まぁ、staticおじさんみたいに全部static化はしないが。

>>82
まぁ、既存の方法で困っていないのならオブジェクト指向は採用しなくてもいいんじゃないかな？
クソ呼ばわりしたら、なんで？って聞くけど。
コーディングの行数は比較したことがないからなんとも言えないが、オブジェクト指向導入で工数削減なら実現した事例は、いくらでもあるよ。
書いたコードを再利用しやすいのがオブジェクト指向のメリットの一つだからね。

**デフォルトの名無しさん** · 2019/10/11(金) 18:54:22.09

>>83
× オブジェクト指向の限界
○ お前の友の限界。類友

**デフォルトの名無しさん** · 2019/10/11(金) 20:44:45.28

細胞が膜で覆われてるのに似てる。
中身のものを直接扱えないのもな。

**デフォルトの名無しさん** · 2019/10/11(金) 20:59:44.57

カプセル化を説明するときはリモコンや自販機や車とか、あとお店のサービスで普通例えない？

的外れな例えはむしろ害となりがち

**デフォルトの名無しさん** · 2019/10/12(土) 00:05:00.41

変なのがワラワラ湧いてきたな。
オブジェクト指向はまるで池沼ホイホイだな。

**デフォルトの名無しさん** · 2019/10/12(土) 03:38:52.22

カプセル化と継承を同じレベルで考えてるやつがいるからな。
継承は「行うこと」だが、カプセル化は「行うこと」じゃなくて概念。

カプセル化という概念がわかっていて、その概念に従って設計すれば
こういうメリットがありますよーっていう話だから

カプセル化という概念に従った設計をするときに使える便利な道具が
privateやインターフェース。だからといって別に使う必要があるわけじゃない。

多く言語ではカプセル化という概念を取り入れて言語を作っているから、
publicプロパティを使っていても、カプセル化に従うことが出来るが、
Javaではsetter/getterというワークアラウンド（_で始まる名前をprivate変数とするという規約と同じ）が
必要になるが、多くの言語ではそんな事気にしなくてもカプセル化という概念を満たすコードが書ける

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

カプセル化とは何か人によって解釈がさまざまで、よく話が発散するが、
カプセル化を含むオブジェクト指向の害を弾劾するこのスレにおいて
自分の考えこそカプセル化として正しいとか主張すること自体
スレ違いなのは理解できている？

**デフォルトの名無しさん** · 2019/10/12(土) 06:31:54.75

腹いてえ下痢だよゲリぃ
グリーンピース食べすぎたわ

**デフォルトの名無しさん** · 2019/10/12(土) 06:34:02.05

ボッチしとけよ

**デフォルトの名無しさん** · 2019/10/12(土) 09:27:37.09

>>91
カプセル化とは人それぞれである
カプセル化の説明すること事態がスレ違いだ
理解してるかー？

**デフォルトの名無しさん** · 2019/10/12(土) 09:40:03.04

オブジェクト戦士（バカ）多いな

**デフォルトの名無しさん** · 2019/10/12(土) 09:48:44.50

> 変なのがワラワラ湧いてきたな。
> オブジェクト指向はまるで池沼ホイホイだな。

> オブジェクト戦士（バカ）多いな

ここは罵り合うだけのスレかな？
やーい、お前のソースコードs t a t i c！

**デフォルトの名無しさん** · 2019/10/12(土) 10:28:24.31

カプセル化おじさんのレス見て思うのは
自分の無知や間違いを認められなくなったら技術者としては終わりだなってこと
歳を取ると老害が増える理由

**デフォルトの名無しさん** · 2019/10/12(土) 10:31:11.04

↑このように自分の意見を何一つ言わず、
相手を批難するばかりになったらお終い

**デフォルトの名無しさん** · 2019/10/12(土) 10:33:55.10

↑このように自分の意見を何一つ言わず、
相手を批難するばかりになったらお終い

**デフォルトの名無しさん** · 2019/10/12(土) 10:37:18.66

>>99
俺は意見を言ってるからそれは的外れ

**デフォルトの名無しさん** · 2019/10/12(土) 10:40:44.08

>>97も意見じゃね？
老害の件はわからんが。

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

>>101
オブジェクト指向に関する意見に決まってるだろｗ

**デフォルトの名無しさん** · 2019/10/12(土) 10:47:40.84

> オブジェクト指向に関する意見に決まってるだろｗ

？？？

**デフォルトの名無しさん** · 2019/10/12(土) 10:58:35.93

ここはオブジェクト指向のスレなんだから
カプセル化についての主張をするのは正しい

だけど、それは間違いだーっていうだけで
何が正しいのかの自分の意見を言わないのは老害でしかない。

という話だよ

**デフォルトの名無しさん** · 2019/10/12(土) 11:08:34.26

>>104
それな。間違ってるって言うだけなら
何も知らなくても出来る。

**デフォルトの名無しさん** · 2019/10/12(土) 11:17:25.67

てっきり、いきなり現れた奴がブーメラン発言したのかと思った。
直前に>>95みたいなのもいたし。

名無しさんのままだと、誰が何を言ったのかわからん...。
大体、察したが。

**デフォルトの名無しさん** · 2019/10/12(土) 11:55:42.30

相変わらずオブジェクト戦士はバカばっかりだな

**デフォルトの名無しさん** · 2019/10/12(土) 12:02:36.13

おじさんってだけで拒否反応や反抗心から若者の意見を理解しない老害扱いするけど、
若者がおじさんの主張に耳を傾けてないのは結局おじさんと同じことしてるよね

おじさんの局所的な経験則やノウハウにも局所解としての妥当性を認めていいんじゃないかな？
銀の弾丸はないんだし

自分は関数型言語は型理論を触った程度の理解をしつつ、
オブジェクト指向推進派だったけど、長いことやってると
確かにオブジェクト指向に疑問を感じるときがある

例えば、複数のオブジェクトで協調動作させようとすると、
クラス内にカプセル化できなくなって、～コントローラや～マネージャーとか
どちらかというと抽象的なオブジェクトで溢れかえる設計ってとてもよく見るし自分も書く

C#のstaticクラスのstaticメソッドとかはそれへの部分的な解決法になるけど、
オブジェクト指向っていうより関数型的な感じがする

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

曰く、銀の弾丸はない
でも、金の睾丸は？

**デフォルトの名無しさん** · 2019/10/12(土) 12:24:36.42

>>108
コントローラーやマネージャーがが
クラス内の内部構造に直接アクセスするってどういう事？

**デフォルトの名無しさん** · 2019/10/12(土) 12:50:30.72

>>104
>だけど、それは間違いだーっていうだけで
>何が正しいのかの自分の意見を言わないのは老害でしかない

いい歳したおっさんが二元論でしか物事を考えられない
答えを教えてくれないから「自分の意見を言わない」といって批判する
こういう考え方が老害そのもの

>>108
カプセル化おじさんとブロンズ君のやり取り見れば主張に耳を傾けてないのはどちらか明らか
中身の良し悪しは別にしてブロンズ君はカプセル化おじさんの意見に耳を傾けた上で論拠を持って適切に反論してる
かたやカプセル化おじさんは…

**デフォルトの名無しさん** · 2019/10/12(土) 12:51:06.93

>>111
だからそんな話じゃなくて
オブジェクト指向関連の話をしろよ
自覚ないのが一番たちが悪い

**デフォルトの名無しさん** · 2019/10/12(土) 13:25:11.09

オブジェクト指向にメリットなんかねー時点で議論など無駄

**デフォルトの名無しさん** · 2019/10/12(土) 13:36:07.11

>>110
オブジェクトの内部構造に関係ない協調動作に関する処理を
どこに配置するべきかって話

専用のコントローラや専用のマネージャークラスが頻繁に作られるけど、
別のアプローチ（C#のstaticクラスのstaticメソッドとか）が可能なこともあるし、
別のパラダイムも検討する価値あるんじゃないかなと思うようになった

他の例をあげるなら、特殊な数値クラスを作ったとして二項演算子などの
演算子を数値クラス内にカプセル化するべきかって話も
協調動作の問題と重なってる部分があると思う
（ここまで行くと言語側に手を加えるレベルの話になるけど）

**デフォルトの名無しさん** · 2019/10/12(土) 13:50:47.60

オブジェクト指向が人の間に広まっていくうちに
どうしてだんだん変なやり方に変わってゆき
非科学的で都市伝説みたいな方法論になってしまったのか
よく分かる流れだな

**デフォルトの名無しさん** · 2019/10/12(土) 14:12:10.68

複雑なものをシンプルに扱えるようにしましょうという
人間の心の話なのになんで科学がでてくるの？

**デフォルトの名無しさん** · 2019/10/12(土) 14:26:06.65

>>108

> C#のstaticクラスのstaticメソッドとかはそれへの部分的な解決法になるけど、
> オブジェクト指向っていうより関数型的な感じがする

オブジェクト指向に関数型を適用してはいけないなんてルールは無いと思う。
そんなこと言い出したらOOPする際はラムダ式使うなって話になりそう。

あと、Mathクラスの解釈だが...
自分はMtahクラスみたいにstatic化するべきクラスでも、最初は非staticで設計する。
つまり、こうなる。
Math m = new Math();
int x = m.abs(引数);

でも、これだとstaticおじさんの言うとおり、オブジェクト指向ってしっくりこないんです状態。
※元ネタのstaticおじさんは具体例は挙げなかったが。

そこで、オブジェクト指向プログラマーは気を効かせ、static化する。
int x = Math.abs(引数);

つまり、static化は省略できるものは省略しよう...という、オブジェクト指向プログラマーの気遣い。
そういう解釈でいいと思うよ。

まぁ、どうしても「そんなのオブジェクト指向じゃねえ！」と言うのならオブジェクト指向の型を破ると解釈してもいいけどね。
このスレ的にはOOPの解釈を曖昧にするのは駄目な気もするが、個人的には扱いやすいクラスさえ作れれば何でもいいや。

**デフォルトの名無しさん** · 2019/10/12(土) 14:35:40.11

はぁ？absをオブジェクト指向にするなら
Number n = new Integer(-123)
n.abs() やろ

**デフォルトの名無しさん** · 2019/10/12(土) 14:40:25.05

>>118
ソウダネー。

**デフォルトの名無しさん** · 2019/10/12(土) 14:44:19.05

>>119
そうだよ。Rubyとか勉強してみな

**デフォルトの名無しさん** · 2019/10/12(土) 14:44:35.81

>>116
そういいながら、逆にシンプルなものを複雑にして
迷信じみたことを技術の世界に持ち込むから

**デフォルトの名無しさん** · 2019/10/12(土) 14:49:19.34

そうあってほしいと>>121が考えてるだけ

**デフォルトの名無しさん** · 2019/10/12(土) 14:50:23.73

>>120
(うわっ、こいつ面倒くせ)
そんなにMathが気にくわないのなら、俺じゃなくてOracleやMicrosoftに連絡すれば？
別にabsの実装について話がしたかったわけではないし。

**デフォルトの名無しさん** · 2019/10/12(土) 14:50:31.28

今まさにオブジェクト指向によってもたらされている混乱から目をそむけないほうがいいよ

**デフォルトの名無しさん** · 2019/10/12(土) 20:22:58.57

>>85
>オブジェクト指向の定義はさておき、

ところで「チンボがシコシコする」という日本語表現は、文法的に正しいのか？

チンボ「を」シコシコするのではなくて、チンボ「が」シコシコする。この場合、「チンボ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンボ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンボがシコシコする」はダメな理由を、５０字以内で述べろ！

**デフォルトの名無しさん** · 2019/10/12(土) 20:28:17.23

>>125
それは興味深い考察ですね
ちんぽがシコシコするはダメなのですか？

**デフォルトの名無しさん** · 2019/10/12(土) 20:31:23.42

つまりオブジェクト指向とは、俺の股間に付いているモノなのである！

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　　,　　　　　　　　　　　　　　　　　　　ｬ　　ｨE5!..　　　　　　　　　　　　　
　..　　　　　　　　　　　,,.e;〆　　　　　　　　　　　　.、　　　w===|====!.　　　　　π　.e､ｘ＆　　　　　　　　　　　　　
　..　　　　　　　　　　^~　！　　　　　　``=　　　　π　　　　　,,　ｶ.　_　　　　_￣ｵ⌒|!　`ﾍ　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　fラ⌒￣l｢~~~＾.　　　　　　　　,.ﾀ.　　　　　.ﾙ　.ll　~＼_　　　〃　〃.　　＾..　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　.ｵ..　　　　　　,...＿_,xｆ~.　　　　　　^　　f!　　､　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　'^´　　　　　　　　￣￣..　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　．.　　　　　　　　　　　　　　　　　　　l|..　　　　　　　ｒ=キ'⌒..　　　　　　　　　　　
　.　　　　　　　　　`!、　　　　　　　　~~~~~~⌒...　　　　l｝　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　⌒ｈeィ~.　　　　　.+ｓ_、_e.　　　　　.＾+--w=ｆ　　　`ｦse､._　_、...　　　　　′　　　　　

チンポは独立した生き物であり、本人の意思とは無関係に、自らの意思で勃起してシコシコする！

**デフォルトの名無しさん** · 2019/10/12(土) 20:35:24.78

質問に答えてください！

**デフォルトの名無しさん** · 2019/10/12(土) 22:42:46.45

人類の歴史を作ってきたのはおじさんだからな
おじさんの言うことを聞いていればだいたい間違いはないが、重大な間違いを犯すのもまたおじさん

**デフォルトの名無しさん** · 2019/10/12(土) 22:45:21.43

>>128
だからオブジェクト指向は俺の股間に付いているのだ！

**デフォルトの名無しさん** · 2019/10/13(日) 03:57:42.23

だからそれは、糞だってばおじぃちゃん

**デフォルトの名無しさん** · 2019/10/13(日) 09:50:19.58

カプセル化って
中に有るものを見たり使ったり出来ないようにしないと意味が無い
getter,setterで使い捲くるのでは余り意味が無い(初期設定はしないといけないからsetterなりコンストラクタで設定する必要は有る)
それではグローバル変数となんら変わりは無い

ただそれをどうやればいいのか?
と聞かれるとセオリーや具体的な手法が存在していない

それがオブジェクト指向プログラミングが糞と言われてしまう原因になってる
現状では属人的に出来る人だけが使えるようになってしまっている

**デフォルトの名無しさん** · 2019/10/13(日) 10:07:37.44

>>132 の発言を自分がちゃんと理解しているか怪しいのだが...

> getter,setterで使い捲くるのでは余り意味が無い(初期設定はしないといけないからsetterなりコンストラクタで設定する必要は有る)
> それではグローバル変数となんら変わりは無い

んん？具体例がほしいな。
こういうこと？

class test｛
private:
int x;
public:
int getX(){
return x;
}
void setX(int a){
x = a;
}
｝

これってあんまり意味ねーよね？って話？

**デフォルトの名無しさん** · 2019/10/13(日) 10:40:41.09

>>132
まーた間違ってる。

グローバル変数がなぜ悪かというと、プロジェクト全体から
読み書きできてしまうのでどこで参照してるかわからないから。
つまりスコープの範囲が広すぎるという問題。パブリックであることと何の関係もない。

それにカプセル化は、隠さなくて良いものまで隠せと言ってるわけじゃない。
隠すもの（内部構造）と隠さななくて良いもの（インターフェース）を
きっちりワケましょう、それによってメンテナンス性が上がりますという概念

すべて隠さなくていいオブジェクトだって存在する。それはそうするのが正しいので
カプセル化を破壊してることにはならない。隠すべき内部構造がないと言うだけ。
なんで隠してなければ、カプセル化破壊だと思うんだろうか？

getter,setterってまたJavaの話をしてるんだろうけど、
それはJavaという言語にカプセル化を実現するための機能が不足してるから
規約でカバーしてるだけ。他のオブジェクト指向言語であれば
お前の言うgetter,setterが無い言語もある。

お前がオブジェクト指向を理解してない＝お前が糞なのであって
それをオブジェクト指向のせいにするな。
あと知識が狭すぎる。Javaしか知らないんだろ。

**デフォルトの名無しさん** · 2019/10/13(日) 10:50:13.80

俺も昔はグローバル変数についてそういう認識だったけど

そもそもスコープがどうであれ
ドキュメントに何もねぇ変数を把握する事自体
やってらんねぇよクソッタレって認識に変わった

本質はドキュメントに書いてないことが問題であって
スコープが仕様を形成するものであってはならない

**デフォルトの名無しさん** · 2019/10/13(日) 10:57:17.16

>>135
イミフ。有名なオープンソースのコードを見て良いコードとは
コメントが書かれてないコードだと知ったほうが良いよ。
そんな物無くてもメンテナンスしやすいような構造になってる。
あとスコープが仕様を形成するなんて話は誰もしてない。

**デフォルトの名無しさん** · 2019/10/13(日) 10:57:38.28

× コメントが書かれてない
○ コメントが重要なところにしか書かれてない

**デフォルトの名無しさん** · 2019/10/13(日) 10:59:10.44

コメントに頼らなくてもある程度理解できるコードと言いたいのでは？

コメントはあったらあったで助かるよ。

**デフォルトの名無しさん** · 2019/10/13(日) 11:01:53.95

>>136
バカじゃん
テメーが考えたコメントをソースに書いてんのか？

コメントってのは設計書の文言をコピペしてこそ意味があるんだよ
ソースにあるコメントで設計書を検索してヒットしない成果物いりませぇん

**デフォルトの名無しさん** · 2019/10/13(日) 11:15:03.63

設計書に書いてあるなら、どこそこの設計書見れでいいじゃん
コピペ作業に金払わされてるとか、経営者が可哀想でならん

**デフォルトの名無しさん** · 2019/10/13(日) 11:15:55.03

どこそこの設計書見れって書いてないから、
設計書を"検索"するはめになるわけで（苦笑）

**デフォルトの名無しさん** · 2019/10/13(日) 11:25:05.37

>>134
>グローバル変数がなぜ悪かというと、

チンポは独立した生き物であり、自我でコントロール出来るわけてはないからな！

**デフォルトの名無しさん** · 2019/10/13(日) 11:46:53.61

>>141
自己流で書いたコメントはそれすらできないからね

**デフォルトの名無しさん** · 2019/10/13(日) 11:54:13.80

>>143
あの、もしかして、お前が言ってるほうが
「自己流」のやり方だって気づいてないですか？

ぐぐって調べてみてください。
誰もそんなことしてないですよ。

**デフォルトの名無しさん** · 2019/10/13(日) 11:55:34.36

なんか、凄まじい話の脱線風景を見てしまった...。
なんで>>135からコメントの書き方バトルに発展するのか...。

**デフォルトの名無しさん** · 2019/10/13(日) 11:58:21.06

やっぱオブジェクト指向ってクソだなｗ

**デフォルトの名無しさん** · 2019/10/13(日) 11:58:46.69

>>144
はぁ？
だからデスマになるんでしょ？
テメーの気持ち悪い親切心で書いたコメントなんかいるかよ
気持ち悪いから早く死ね
重要なのはそのコードが設計書のどこの部分かってことだけだ

**デフォルトの名無しさん** · 2019/10/13(日) 12:00:10.60

>>146
具体的理由を述べてどうぞ。
呟くだけならTwitterでどうぞ。

**デフォルトの名無しさん** · 2019/10/13(日) 12:46:04.52

スレでさんざ書いてきたことだし
うえの議論のずれっぷり見ても十分理由だろう

**デフォルトの名無しさん** · 2019/10/13(日) 12:55:49.57

弊社にもいたよ、独特のオブジェクト指向論を持ち、
変な理屈こねて、これぞオブジェクト指向だと自説を押し付けたり
他人を批判したりして、チームの仕事を停滞させ
そのくせ、プログラムの開発をしてもらうとロクなコードが書けず、進捗が遅くて、
継承とメソッド呼び出しスパゲティーでバグだらけ
直る見込みがないので悪いけど間接部に移動してもらった。

**デフォルトの名無しさん** · 2019/10/13(日) 12:57:06.58

いや、自分はさっきから議論がズレすぎてなんでOOPがクソ扱いされるのか未だに理解できないのだが。

台風が来た(わかる)→台風で死者が出た(わかる)→首相が悪い(は？)

並みに飛躍しすぎて意味不明なのだが。
どさくさに紛れてOOPをクソと結論付けるのはやめろよー。

**デフォルトの名無しさん** · 2019/10/13(日) 13:00:05.28

>>150
うん、それはお気の毒に。
まぁ、そういう人はいるよね。このスレにも。
でも、それを根拠にOOPをクソ扱いするのは違うと思うんだ。
そもそも、そいつ自体がOOP理解しているか怪しいし。

**デフォルトの名無しさん** · 2019/10/13(日) 13:00:24.46

いままでのレス読んで理解できないのは
読解力や個人の能力の問題。
それこそしらんがな

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

>>152
そだな、そういう痛々しい人の問題は別にしても

オブジェクトにどのような害があり、それを使ってソフトウエアのアーキテクチャ・構造の表現がしにくくて
大規模で複雑なシステムの構築上、人間が理解しにくいものが出来てしまうか
さんざ書いてきたが、読んでねーか、まともなあたまをもってねーか、、、

痛々しい人の問題はその上にかぶって存在し、オブジェクトの
局所的な一見便利そうで利点に見えるが
ある程度の規模の構造上逆に欠点となる方法の押し売りなんだよ

オブジェクトとはなにか、どういうやり方こそオブジェクトとして正しいか
意見の応酬などは論点じゃないんだけれど、
そういう論点好きは、痛々しい人とほぼ同類

**デフォルトの名無しさん** · 2019/10/13(日) 13:22:03.21

コメントとコードであっても二重管理になって
同期が取れなくてトラブルのもとになるというのに
設計書とコメントとコードの三重管理とか気が狂いそうｗ

**デフォルトの名無しさん** · 2019/10/13(日) 13:24:19.42

>>153
今までのってどこの部分？
安価つけてほしいね。

ついでに、あなたは本当にOOPを理解している上で批判しているのかい？
聞いた話では他の人が書いた自称OOPコードを見てクソだと思ったのでしょ？

是非、そのクソだと思う部分を教えてほしいね。
>>133みたいにコード書いてもいいんだよ？133はスルーされちゃったけど。

**デフォルトの名無しさん** · 2019/10/13(日) 13:25:10.20

たとえば、

カプセル化とは何かの解釈の幅によらず、

カプセル化によるスコープやアクセスの管理は、ぱっと見とても有効に見えるが
実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
規模に応じ急激に複雑さをまして
（レキシカなスコープ、エクステント管理に対し）
人間が管理把握しにくくなる因子であることは、
一定の理解を得られているはずだが

**デフォルトの名無しさん** · 2019/10/13(日) 13:26:15.07

そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから
他人を叩きのめすのに使えばいいんだよ

仕組みはどうあれ俺が気に入らないのでテメーは死刑だ

**デフォルトの名無しさん** · 2019/10/13(日) 13:26:18.10

>>156
「OOPを理解している上」
そうやってすぐ
OOPの解釈議論に論点をずらそうとする…
痛々しいなあ

**デフォルトの名無しさん** · 2019/10/13(日) 13:27:38.97

>>158
科学的技術的な話ではないので
ある意味そういうことだとおもうよ。

**デフォルトの名無しさん** · 2019/10/13(日) 13:33:44.13

>>159
これが先に目についたのでこっちから答えるが、当然だろ。
スレタイはオブジェクト指向はクソかよだ。

オブジェクト指向をまったく理解してないのにクソ呼ばわりはないだろ。
その大前提を崩すと、お前が非難しているのはOOPじゃなくてstaticおじさんの可能性すらあるんだよ？

痛々しい以前に論外過ぎるだろ。
正確な定義は理解していなかったとしても、自分ではこれがオブジェクト指向だという考えくらい持てよ。

**デフォルトの名無しさん** · 2019/10/13(日) 13:40:37.70

まったく理解せず色々言うのはよくないが、
オブジェクト指向をまったく理解してないやつなんて
そもそもいるのかよｗ

それにOOP解釈によらずCでも頑張ってOOP的な書き方をしても
>>157
のような問題はでるんだぜ
細かく派生した、場合によって人さまざまなOOPの解釈の違いによらない
欠点があるといってんだが、読み取れないのか。。。

**デフォルトの名無しさん** · 2019/10/13(日) 13:42:49.52

オブジェクト指向のメリットを定義してよ

って言うといつも逃げ出すじゃん

**デフォルトの名無しさん** · 2019/10/13(日) 13:43:44.18

方法論にずれちゃうんだよね
良くて局所的なメリット論

**デフォルトの名無しさん** · 2019/10/13(日) 13:43:50.79

>>158
> そもそもオブジェクト指向なんて数字を上げたメリット説明できねぇんだから

どのような数字を上げれば良いのですか？
オブジェクト指向以外で、数字を上げたメリット説明してるものを
参考として教えて下さい。

**デフォルトの名無しさん** · 2019/10/13(日) 13:44:20.01

>>163
管理しやすくなるってメリット言っても
数字言えって言って逃げてるじゃんｗ

**デフォルトの名無しさん** · 2019/10/13(日) 13:45:47.26

小さいプログラムだったらな。

**デフォルトの名無しさん** · 2019/10/13(日) 13:46:22.87

>>166
だってそれお前の感想止まりじゃん

**デフォルトの名無しさん** · 2019/10/13(日) 13:47:20.41

だからオブジェクト指向は俺の股間に付いているってことなのさ！

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

>>169
そうか、それでOOPはクソなんだ。
納得

**デフォルトの名無しさん** · 2019/10/13(日) 14:01:26.96

>>163
逃げた覚えはないけどな。

まぁ、いいや。俺の意見だが。
思い付くメリットを列挙するとこんな感じだ。
(1)責務分割を行うため各コードの役割が明確になる。
→共同開発時、作業分担がしやすくなる。
→不具合が発生したとき、どこが悪いのか明確になる
(2)必要な数だけオブジェクトを複製できる。
→例えば...組み込み開発だが、USBオブジェクトがあったとして、USBポートを一つから四つに増やしたいとき
Usb usb[] = new Usb()［4］;
といった記述で増やせる。
(3)ポリモーフィズムが可能
Storage s = new Usb();
...
s = new SDCard();

SDカード・USBの違いを区別することなくアクセス可能。
s.read(ファイル);

他にもメリットは腐る程あるが、そこは自分で調べてくれ。てか、質問スレでどうぞ。

**デフォルトの名無しさん** · 2019/10/13(日) 14:03:55.40

>>166
数字？なんだそりゃ。
非OOPの品質が1ならOOPの品質は10

これでいい？納得した？しねーだろうなぁ(投げやり)

スマホ入力つらい...PCもってくるか...

**デフォルトの名無しさん** · 2019/10/13(日) 14:08:17.56

>>171
(1)はstaticの利点でもあるな
(2)はOOPの話じゃないだろ
(3)は何が言いたくて何が利点だかよく分からないけど、
　関数の共通化できますってことか？OOPにかぎらんだろ

長文乙だが、読んでて気がついたは
あんたが書いている程度の規模のプログラムだと
何のパラダイムでも大して管理は変わらないと思う
何でこのレベルのひとが「OOPを理解している上で」とかえらそうなことを言うのかの方が疑問

**デフォルトの名無しさん** · 2019/10/13(日) 14:09:33.40

>>172
いいよ持ってこなんで。
話を聞くだけこっちの時間の無駄

**デフォルトの名無しさん** · 2019/10/13(日) 14:11:43.73

>>173
> 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
> 規模に応じ急激に複雑さをまして
> （レキシカなスコープ、エクステント管理に対し）
> 人間が管理把握しにくくなる因子であることは、
> 一定の理解を得られているはずだが

こんな意味不明な発言をする人に言われたくねーです。

**デフォルトの名無しさん** · 2019/10/13(日) 14:15:29.59

>>175
これ分からないんだったら単に不勉強だと思う。
ここ数年間のソフトウエア工学の進歩を眺めてりゃ分かる程度のこと。
まぁ、多くのITエンジニアがやは不勉強なんだが。
不勉強で理解できないのは自然なことだ、しょうがない

**デフォルトの名無しさん** · 2019/10/13(日) 14:20:32.14

>>173
> 人間が管理把握しにくくなる因子であることは、
> 一定の理解を得られているはずだが

ちんぽは本人ですら管理できない独立した生き物だが？

**デフォルトの名無しさん** · 2019/10/13(日) 14:22:28.82

>>177
そのうち、年取ると小便にしか使わなくなって
逆の意味で言うことを聞かなくなるから
心配要らないよ

**デフォルトの名無しさん** · 2019/10/13(日) 14:24:26.49

>>176
> 実は大きな弱点を持っていて、依存のハブみたいな役割を果たし、
> 規模に応じ急激に複雑さをまして
> （レキシカなスコープ、エクステント管理に対し）
> 人間が管理把握しにくくなるあることは、
> 一定の理解を得られているはずだが

なんでカプセル化がこの問題に繋がるのか説明してくれる？
コード書いてほしいな。或いはもう少し具体的に説明してくれないかな？
飛躍しすぎてわけがわからん。

**デフォルトの名無しさん** · 2019/10/13(日) 14:28:09.59

>>179
過去スレでもさんざ書いたんだが
自分が不勉強なくせに、5chにでまた長々かけってか、、、
子供電話相談室じゃねんだが。。。

まずプログラミングの基礎である
レキシカなスコープ、エクステントは
分かるよね？

**デフォルトの名無しさん** · 2019/10/13(日) 14:28:12.58

は？
全くわかんね
書いてあることがどうとかってより
まず、

どうなるとオブジェクト指向なの？

**デフォルトの名無しさん** · 2019/10/13(日) 14:29:28.54

歴史家なスコープｗｗ

**デフォルトの名無しさん** · 2019/10/13(日) 14:29:31.33

あとオブジェクト指向のもたらした依存の複雑化する問題は
理解しているよね？

**デフォルトの名無しさん** · 2019/10/13(日) 14:31:24.11

>>182
ごめんごめん、受けた？
○ レキシカルなスコープ

**デフォルトの名無しさん** · 2019/10/13(日) 14:31:33.43

知ってる。そんなレベルの話ではなく、なぜ、そこに問題がでると思っているのかの話。
レキシカなスコープという時点で何かを感じるが。

**デフォルトの名無しさん** · 2019/10/13(日) 14:34:25.96

>>185
ダイナミックスコープがまずいのは分かるだろ？
いわゆる旧MS BASICのような。

では大規模ソフトでレキシカルスコープがなぜ大事か分かる？
ここ40年くらいの間に普及したんだけれど。

**デフォルトの名無しさん** · 2019/10/13(日) 14:34:33.36

>>183
これが抽象的過ぎてわからん。
なんで、毎回曖昧な表現使うかな...。

**デフォルトの名無しさん** · 2019/10/13(日) 14:38:29.75

>>186
あっ...ここでもうわからんわ。
ダイナミックスコープがまずい？

**デフォルトの名無しさん** · 2019/10/13(日) 14:39:06.61

カプセルかってのは何やんのよ。
細かい解釈の違いは、頼むから横においておいてよ。

1) 型クラス
2) メンバのアクセス制限修飾
こきらまでは旧来のCもできましたよと。いいよね。
3) アクセスmethodを設け、calssまたはインスタンススコープを持たす
そして「動的な」が好きな人は
4) 動的インスタンスの生成・消滅
　⇒エクステントはレキシカルとは結びつかず独自に管理せなあかん

**デフォルトの名無しさん** · 2019/10/13(日) 14:39:31.69

>>168
> だってそれお前の感想止まりじゃん

俺の感想じゃなくて世界の感想だってｗ

**デフォルトの名無しさん** · 2019/10/13(日) 14:41:40.12

>>190
なにかそういうデータあるんですか？

**子供電話相談室対応中** · 2019/10/13(日) 14:43:21.45

>>188
スコープダイナミックって言うことは、外から見える変数ばっかりで
プログラムがちょっと大きくなっただけで、局面局面で意識・管理せにゃならん
変数や状態が増大しくみ合わさって入り組んで見えたり、
あるいは実行時に呼ばれる順が変わると変数の内容が変わったり
管理不能になる

昔はそういう言語しかなかった
CやShemeがlexical scoprやextentを導入して革命がおきた

**デフォルトの名無しさん** · 2019/10/13(日) 14:43:42.54

>>191
なんなら、関数型と手続き型と比較してみますか？
データ出してみてください。

**デフォルトの名無しさん** · 2019/10/13(日) 14:45:01.83

C#とnode.js使いだけど、ダウンロードできるオープンソースでオブジェクト指向じゃないコードを落とした経験がまったくない。
たぶん、業種によるんだろうな。
オブジェクト指向と無縁の業種とは無縁だから具体的に何かは知らないけど。

**デフォルトの名無しさん** · 2019/10/13(日) 14:46:16.66

>>193
え？俺らが初検証？

**デフォルトの名無しさん** · 2019/10/13(日) 14:47:45.65

>>195
そりゃそうでしょｗ

**デフォルトの名無しさん** · 2019/10/13(日) 14:48:20.57

そうでしょっていうのは、お前が関数型と手続き型の
データを持ってくるってことね。
自分で検証しなくていいのよ。お前がやりましょうってこと。

**デフォルトの名無しさん** · 2019/10/13(日) 14:57:39.71

困ったな
俺はメンバ変数全部publicだし

お前らの組み方だと組むときになって

アレ？このメンバ変数privateだ!

オラ、びっくらこいたーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー!!!!!!!!
設計を根本から見直さなきゃ!

ってシーンがないとダメなんだろ
俺、そういうことねーし

**デフォルトの名無しさん** · 2019/10/13(日) 14:59:44.04

>>194 あたりまえやんけ、そんなこと。

そえはさておき >>189 がカプセル化の概要であるとして、
どのような弱点をもたらすか

1つはスコープの問題
メンバにアクセス修飾制限するのは一見いいことのように見える。

複合体型に基づくclassやインスタンスのメンバごとのスコープは
フレームワーク的な中間レイヤの局所では一貫して明確に決めやすいけど
上位の複合的な機能のアプリレイヤに近づくと、型も色々持ち込んだ複合的な
ものになるわけだし、動的に生成したインスタンスを動的なエクステントで使いまわす
ので、メンバへのアクセス制限は局所局所で融通が利かず一貫性を維持しにくくなって
結局多くのメンバをアクセサを用意するはめに陥る。
これは、グローバルなscope、動的ななextentを持つ(名前階層を持った)
多数の変数でプログラムを組むことと同じ複雑さをもたらすでしょ。

そのなかでエクステントの管理もやっていくと、、、(弱点2)
どMかよ＞

では >>183 と組み合わさって、さらにどのような弱点をもたらすか…

**デフォルトの名無しさん** · 2019/10/13(日) 15:07:21.54

なぜ変数やメソッド(メンバ関数)をprivateにするか？

少なからずの場合それらが試行的もしくは暫定的。
例えばシグネーチャがまだ流動的な場合とか。
自分も含めて勝手に使って欲しくない、少なくとも使われる箇所を完璧に把握しておきたいような場合。