オブジェクト指向ってクソじゃね？

**デフォルトの名無しさん** · 2018/08/24(金) 13:32:09.36

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

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

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

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

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

**デフォルトの名無しさん** · 2018/08/24(金) 13:35:00.08

なにをいまさら

**デフォルトの名無しさん** · 2018/08/24(金) 13:35:14.51

よくある

**デフォルトの名無しさん** · 2018/08/24(金) 13:44:30.12

アホだな

**デフォルトの名無しさん** · 2018/08/24(金) 13:44:39.27

マジかよ

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:48:32.20

>>696-701
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:48:49.10

>>188-193
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:48:49.93

>>188-193
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:06.65

>>936-941
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:07.52

>>936-941
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:24.49

>>475-480
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:25.25

>>475-480
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:42.00

>>504-509
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:42.66

>>504-509
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:49:59.43

>>10-15
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:00.16

>>10-15
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:17.05

>>846-851
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:17.68

>>846-851
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:34.99

>>794-799
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:35.59

>>794-799
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:52.74

>>594-599
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:50:53.52

>>594-599
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:10.36

>>74-79
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:10.98

>>74-79
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:27.73

>>865-870
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:28.57

>>865-870
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:46.63

>>193-198
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:51:47.62

>>193-198
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:04.41

>>639-644
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:05.28

>>639-644
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:22.20

>>743-748
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:22.85

>>743-748
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:39.73

>>2-7
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:40.36

>>2-7
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:57.00

>>300-305
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:52:57.69

>>300-305
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:14.69

>>423-428
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:15.30

>>423-428
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:32.47

>>227-232
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:33.30

>>227-232
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:50.36

>>150-155
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:53:51.27

>>150-155
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:07.98

>>715-720
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:08.57

>>715-720
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:25.45

>>57-62
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:26.08

>>57-62
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:42.76

>>856-861
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:54:43.68

>>856-861
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:00.44

>>595-600
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:01.09

>>595-600
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:17.72

>>314-319
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:18.39

>>314-319
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:36.07

>>632-637
ハロワ！

**♨デフォルトの名無しさん** · 2018/08/24(金) 13:55:36.71

>>632-637
ハロワ！

**デフォルトの名無しさん** · 2018/08/24(金) 14:27:45.99

>>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな

**デフォルトの名無しさん** · 2018/08/25(土) 00:54:02.71

オブジェクト指向は、ウンコのようにニガい

**デフォルトの名無しさん** · 2018/08/25(土) 13:13:07.84

砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない

**デフォルトの名無しさん** · 2018/08/25(土) 13:25:46.59

オブジェクト指向が無くなった場合
メソッドは全部グローバル関数になるの？

PersonRename(Person p,string newName);
PersonSetAge(Person p,int age);
PersonGetAge();

FirePersonCreate(Person p);

FirePersonRename(Person p,string newName);
FirePersonSetAge(Person p,int age);
FirePersonGetAge();

**デフォルトの名無しさん** · 2018/08/25(土) 13:27:10.91

訂正

PersonRename(Person p,string newName);
PersonSetAge(Person p,int age);
PersonGetAge();

FirePersonCreate(Person p);

FirePersonRename(FirePerson p,string newName);
FirePersonSetAge(FirePerson p,int age);
FirePersonGetAge();

**デフォルトの名無しさん** · 2018/08/27(月) 19:47:07.71

クソはオブジェクトやぞ

**デフォルトの名無しさん** · 2018/08/31(金) 19:34:28.84

文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。

**デフォルトの名無しさん** · 2018/09/05(水) 05:14:03.10

>>1
オブジェクト指向で組めない君らがクソ

**デフォルトの名無しさん** · 2018/09/05(水) 05:21:15.30

スタティックおじさんの皆さん

**デフォルトの名無しさん** · 2018/09/05(水) 09:21:08.12

カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな

**デフォルトの名無しさん** · 2018/09/05(水) 09:22:22.65

設計のないスタティックおじさん方式は柔軟かもわからんね↓

**デフォルトの名無しさん** · 2018/09/05(水) 15:30:35.02

>>61
正しく組めば重複が減ってコード量は減る

>>64
普通はカプセル化しないことで
開発できなくなることの方が多い
グローバル変数を使うとか

**デフォルトの名無しさん** · 2018/09/05(水) 23:23:20.11

オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ？

**デフォルトの名無しさん** · 2018/09/06(木) 01:28:19.10

>>67
https://thinkit.co.jp/article/13487

> ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
>
> ・アクターはバウンダリのみ関連線（矢印）が引ける
> ・バウンダリはコントロールとアクターのみ関連線が引ける
> ・エンティティはコントロールのみ関連線が引ける
> ・コントロールはコントロール同士とバウンダリのみ関連線が引ける

残念ながらフロー（流れ）を示す線は書けないので
フローチャートにはならない。特に条件分岐やループなどがない

**デフォルトの名無しさん** · 2018/09/06(木) 03:27:30.57

>>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい

**デフォルトの名無しさん** · 2018/09/06(木) 07:33:26.04

本には書いてないオブジェクト指向
https://www.arksystems.co.jp/closeupit/object_oriented/

こいつを見てくれ、こいつをどう思う？

**デフォルトの名無しさん** · 2018/09/06(木) 07:42:10.81

/** リストの要素をゼロで置き換える **/
private void clearList() {
　for (Integer el : someList) {
　　el = new Integer(0);
　}
}

なかなかファンキーなロケンロールだぜ

**デフォルトの名無しさん** · 2018/09/06(木) 08:26:13.84

>>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか？

**デフォルトの名無しさん** · 2018/09/06(木) 08:28:15.97

>>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ

**デフォルトの名無しさん** · 2018/09/06(木) 08:31:32.42

構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの

**デフォルトの名無しさん** · 2018/09/06(木) 12:51:58.13

オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ

**デフォルトの名無しさん** · 2018/09/06(木) 13:33:23.77

>>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか？

**デフォルトの名無しさん** · 2018/09/06(木) 13:46:11.74

インターフェースを切って実装を分離することを言ってるんじゃないか？

**デフォルトの名無しさん** · 2018/09/06(木) 13:50:58.27

そもそも、継承関係で隠蔽しちゃい合うのが問題なだけで、
インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。

**デフォルトの名無しさん** · 2018/09/06(木) 23:36:20.94

>>70
そのサイトには賛成できる部分と反対の部分がある

「クラスとはデータ構造」で
「責務はクラスではない」というのには大反対

クラスは責務そのものという方が
オブジェクト指向の主流の教え方

**デフォルトの名無しさん** · 2018/09/06(木) 23:37:17.79

>>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向

**デフォルトの名無しさん** · 2018/09/07(金) 08:35:51.18

>>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います！

**デフォルトの名無しさん** · 2018/09/07(金) 08:40:25.09

責務ごとにクラスを作るのがどうして主流だよね？ってことですよ

**デフォルトの名無しさん** · 2018/09/07(金) 09:19:04.85

責務ごとに分離したら凝集度が低下します

**デフォルトの名無しさん** · 2018/09/07(金) 19:25:29.09

>>81
それもそうか

>>82
変更コストが下がるから

>>83
いやむしろ凝集度は上がるよ？

凝集度を上げるっていうのは
でかいクラスを作ることじゃないよ？

**デフォルトの名無しさん** · 2018/09/07(金) 19:40:40.77

ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？
どうもUI部の設計は苦手だ。

**デフォルトの名無しさん** · 2018/09/07(金) 20:33:13.60

>>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります

**デフォルトの名無しさん** · 2018/09/07(金) 20:36:30.67

ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです

**デフォルトの名無しさん** · 2018/09/07(金) 20:48:57.91

>>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う

**デフォルトの名無しさん** · 2018/09/07(金) 20:49:13.32

>>86
＞データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる

>>87
ドメインオブジェクトの数が増えていくのは普通だが
1オブジェクトの行数が増えていくのは肥大化

**デフォルトの名無しさん** · 2018/09/07(金) 21:07:16.42

>>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと

行数が増えたからオブジェクト分けましょうなんてのは
オブジェクト指向の理念に反する

データをカプセル化してデータに対する責務を持つのが
オブジェクトなんだよ

**デフォルトの名無しさん** · 2018/09/07(金) 21:09:02.84

データに対する振る舞いが集まるんだから凝集度は高まるんです

**デフォルトの名無しさん** · 2018/09/07(金) 21:12:47.16

オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます

**デフォルトの名無しさん** · 2018/09/07(金) 21:15:03.24

皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。

いや、分かるよ。俺がViewの設計が下手っぴなのは認める。

**デフォルトの名無しさん** · 2018/09/07(金) 21:16:51.88

>>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。

**デフォルトの名無しさん** · 2018/09/07(金) 22:12:16.23

>>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋

>>91
>>83
別人の発言かもしれないがこの発言の関係に疑問が残る

責務ごとにクラスを作ることで凝集度が上がるのであって
複数の責務をひとつのクラスに混ぜたら凝集度は下がるよ

**デフォルトの名無しさん** · 2018/09/07(金) 22:14:41.41

>>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事

>>93
大きくなったら分割するのは何も悪くない

全体の規模が大きくなっていく時に
ひとつのクラスの行数が増えるのが肥大化
クラス数を増やしていくのが正しいOOP

**デフォルトの名無しさん** · 2018/09/07(金) 22:15:21.48

つか、ワンオブジェクトワンファイルなんてルールは無いから。

**デフォルトの名無しさん** · 2018/09/07(金) 22:58:43.86

このｽﾚにいるような池沼が作らなければ
ｸﾗｽﾗｲﾌﾞﾗﾘも階層や種類で作るからな

低い階層に行けばいくほど単純な簡単な機能を提供するｸﾗｽになる
階層は完全に分離させて独立したﾗｲﾌﾞﾗﾘにする

そして明確に種類の異なるﾌﾟﾘﾐﾃｨﾌﾞがある場合は
ﾗｲﾌﾞﾗﾘを完全に分離させて独立したﾗｲﾌﾞﾗﾘにする

その上にｱﾌﾟﾘｹｰｼｮﾝを実現するｸﾗｽ群がのっかる

低学歴知恵遅れが作るとすべて同じ階層で同じ種類になる

**デフォルトの名無しさん** · 2018/09/08(土) 02:09:56.99

クラスに階層があるなんて寝言は寝て言うべきだと思うの