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

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん2018/08/24(金) 13:32:09.36ID:ifygL6bT
カプセル化(英語:encapsulation)とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

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

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

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

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

2デフォルトの名無しさん2018/08/24(金) 13:35:00.08ID:vJMsvnBL
なにをいまさら

3デフォルトの名無しさん2018/08/24(金) 13:35:14.51ID:ZAZ1bDZG
よくある

4デフォルトの名無しさん2018/08/24(金) 13:44:30.12ID:dWZiPnfz
アホだな

5デフォルトの名無しさん2018/08/24(金) 13:44:39.27ID:GnRKIAsQ
マジかよ

6デフォルトの名無しさん2018/08/24(金) 13:48:32.20ID:JNQXY3hm
>>696-701
ハロワ!

7デフォルトの名無しさん2018/08/24(金) 13:48:49.10ID:JNQXY3hm
>>188-193
ハロワ!

8デフォルトの名無しさん2018/08/24(金) 13:48:49.93ID:JNQXY3hm
>>188-193
ハロワ!

9デフォルトの名無しさん2018/08/24(金) 13:49:06.65ID:JNQXY3hm
>>936-941
ハロワ!

10デフォルトの名無しさん2018/08/24(金) 13:49:07.52ID:JNQXY3hm
>>936-941
ハロワ!

11デフォルトの名無しさん2018/08/24(金) 13:49:24.49ID:JNQXY3hm
>>475-480
ハロワ!

12デフォルトの名無しさん2018/08/24(金) 13:49:25.25ID:JNQXY3hm
>>475-480
ハロワ!

13デフォルトの名無しさん2018/08/24(金) 13:49:42.00ID:JNQXY3hm
>>504-509
ハロワ!

14デフォルトの名無しさん2018/08/24(金) 13:49:42.66ID:JNQXY3hm
>>504-509
ハロワ!

15デフォルトの名無しさん2018/08/24(金) 13:49:59.43ID:JNQXY3hm
>>10-15
ハロワ!

16デフォルトの名無しさん2018/08/24(金) 13:50:00.16ID:JNQXY3hm
>>10-15
ハロワ!

17デフォルトの名無しさん2018/08/24(金) 13:50:17.05ID:JNQXY3hm
>>846-851
ハロワ!

18デフォルトの名無しさん2018/08/24(金) 13:50:17.68ID:JNQXY3hm
>>846-851
ハロワ!

19デフォルトの名無しさん2018/08/24(金) 13:50:34.99ID:JNQXY3hm
>>794-799
ハロワ!

20デフォルトの名無しさん2018/08/24(金) 13:50:35.59ID:JNQXY3hm
>>794-799
ハロワ!

21デフォルトの名無しさん2018/08/24(金) 13:50:52.74ID:JNQXY3hm
>>594-599
ハロワ!

22デフォルトの名無しさん2018/08/24(金) 13:50:53.52ID:JNQXY3hm
>>594-599
ハロワ!

23デフォルトの名無しさん2018/08/24(金) 13:51:10.36ID:JNQXY3hm
>>74-79
ハロワ!

24デフォルトの名無しさん2018/08/24(金) 13:51:10.98ID:JNQXY3hm
>>74-79
ハロワ!

25デフォルトの名無しさん2018/08/24(金) 13:51:27.73ID:JNQXY3hm
>>865-870
ハロワ!

26デフォルトの名無しさん2018/08/24(金) 13:51:28.57ID:JNQXY3hm
>>865-870
ハロワ!

27デフォルトの名無しさん2018/08/24(金) 13:51:46.63ID:JNQXY3hm
>>193-198
ハロワ!

28デフォルトの名無しさん2018/08/24(金) 13:51:47.62ID:JNQXY3hm
>>193-198
ハロワ!

29デフォルトの名無しさん2018/08/24(金) 13:52:04.41ID:JNQXY3hm
>>639-644
ハロワ!

30デフォルトの名無しさん2018/08/24(金) 13:52:05.28ID:JNQXY3hm
>>639-644
ハロワ!

31デフォルトの名無しさん2018/08/24(金) 13:52:22.20ID:JNQXY3hm
>>743-748
ハロワ!

32デフォルトの名無しさん2018/08/24(金) 13:52:22.85ID:JNQXY3hm
>>743-748
ハロワ!

33デフォルトの名無しさん2018/08/24(金) 13:52:39.73ID:JNQXY3hm
>>2-7
ハロワ!

34デフォルトの名無しさん2018/08/24(金) 13:52:40.36ID:JNQXY3hm
>>2-7
ハロワ!

35デフォルトの名無しさん2018/08/24(金) 13:52:57.00ID:JNQXY3hm
>>300-305
ハロワ!

36デフォルトの名無しさん2018/08/24(金) 13:52:57.69ID:JNQXY3hm
>>300-305
ハロワ!

37デフォルトの名無しさん2018/08/24(金) 13:53:14.69ID:JNQXY3hm
>>423-428
ハロワ!

38デフォルトの名無しさん2018/08/24(金) 13:53:15.30ID:JNQXY3hm
>>423-428
ハロワ!

39デフォルトの名無しさん2018/08/24(金) 13:53:32.47ID:JNQXY3hm
>>227-232
ハロワ!

40デフォルトの名無しさん2018/08/24(金) 13:53:33.30ID:JNQXY3hm
>>227-232
ハロワ!

41デフォルトの名無しさん2018/08/24(金) 13:53:50.36ID:JNQXY3hm
>>150-155
ハロワ!

42デフォルトの名無しさん2018/08/24(金) 13:53:51.27ID:JNQXY3hm
>>150-155
ハロワ!

43デフォルトの名無しさん2018/08/24(金) 13:54:07.98ID:JNQXY3hm
>>715-720
ハロワ!

44デフォルトの名無しさん2018/08/24(金) 13:54:08.57ID:JNQXY3hm
>>715-720
ハロワ!

45デフォルトの名無しさん2018/08/24(金) 13:54:25.45ID:JNQXY3hm
>>57-62
ハロワ!

46デフォルトの名無しさん2018/08/24(金) 13:54:26.08ID:JNQXY3hm
>>57-62
ハロワ!

47デフォルトの名無しさん2018/08/24(金) 13:54:42.76ID:JNQXY3hm
>>856-861
ハロワ!

48デフォルトの名無しさん2018/08/24(金) 13:54:43.68ID:JNQXY3hm
>>856-861
ハロワ!

49デフォルトの名無しさん2018/08/24(金) 13:55:00.44ID:JNQXY3hm
>>595-600
ハロワ!

50デフォルトの名無しさん2018/08/24(金) 13:55:01.09ID:JNQXY3hm
>>595-600
ハロワ!

51デフォルトの名無しさん2018/08/24(金) 13:55:17.72ID:JNQXY3hm
>>314-319
ハロワ!

52デフォルトの名無しさん2018/08/24(金) 13:55:18.39ID:JNQXY3hm
>>314-319
ハロワ!

53デフォルトの名無しさん2018/08/24(金) 13:55:36.07ID:JNQXY3hm
>>632-637
ハロワ!

54デフォルトの名無しさん2018/08/24(金) 13:55:36.71ID:JNQXY3hm
>>632-637
ハロワ!

55デフォルトの名無しさん2018/08/24(金) 14:27:45.99ID:0hzqlpOd
>>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな

56デフォルトの名無しさん2018/08/25(土) 00:54:02.71ID:6mB8j9/9
オブジェクト指向は、ウンコのようにニガい

57デフォルトの名無しさん2018/08/25(土) 13:13:07.84ID:00w/RGH3
砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない

58デフォルトの名無しさん2018/08/25(土) 13:25:46.59ID:bFeNHPVf
オブジェクト指向が無くなった場合
メソッドは全部グローバル関数になるの?

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();

59デフォルトの名無しさん2018/08/25(土) 13:27:10.91ID:bFeNHPVf
訂正

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();

60デフォルトの名無しさん2018/08/27(月) 19:47:07.71ID:y3uHC3Z/
クソはオブジェクトやぞ

61デフォルトの名無しさん2018/08/31(金) 19:34:28.84ID:lHXkvQer
文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。

62デフォルトの名無しさん2018/09/05(水) 05:14:03.10ID:UEpkpswy
>>1
オブジェクト指向で組めない君らがクソ

63デフォルトの名無しさん2018/09/05(水) 05:21:15.30ID:w7O3HrXU
スタティックおじさんの皆さん

64デフォルトの名無しさん2018/09/05(水) 09:21:08.12ID:BLSFUWnl
カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな

65デフォルトの名無しさん2018/09/05(水) 09:22:22.65ID:BLSFUWnl
設計のないスタティックおじさん方式は柔軟かもわからんね↓

66デフォルトの名無しさん2018/09/05(水) 15:30:35.02ID:UEpkpswy
>>61
正しく組めば重複が減ってコード量は減る

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

67デフォルトの名無しさん2018/09/05(水) 23:23:20.11ID:BuNkH2Jq
オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ?

68デフォルトの名無しさん2018/09/06(木) 01:28:19.10ID:uUC4mFDs
>>67
https://thinkit.co.jp/article/13487

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

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

69デフォルトの名無しさん2018/09/06(木) 03:27:30.57ID:OdtAawkS
>>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい

70デフォルトの名無しさん2018/09/06(木) 07:33:26.04ID:ndioKak8
本には書いてないオブジェクト指向
https://www.arksystems.co.jp/closeupit/object_oriented/

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

71デフォルトの名無しさん2018/09/06(木) 07:42:10.81ID:ndioKak8
/** リストの要素をゼロで置き換える **/
private void clearList() {
 for (Integer el : someList) {
  el = new Integer(0);
 }
}

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

72デフォルトの名無しさん2018/09/06(木) 08:26:13.84ID:abjuqq+M
>>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか?

73デフォルトの名無しさん2018/09/06(木) 08:28:15.97ID:abjuqq+M
>>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ

74デフォルトの名無しさん2018/09/06(木) 08:31:32.42ID:abjuqq+M
構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの

75デフォルトの名無しさん2018/09/06(木) 12:51:58.13ID:ntAiYVJq
オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ

76デフォルトの名無しさん2018/09/06(木) 13:33:23.77ID:uUC4mFDs
>>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか?

77デフォルトの名無しさん2018/09/06(木) 13:46:11.74ID:abjuqq+M
インターフェースを切って実装を分離することを言ってるんじゃないか?

78デフォルトの名無しさん2018/09/06(木) 13:50:58.27ID:BY1c9tpo
そもそも、継承関係で隠蔽しちゃい合うのが問題なだけで、
インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。

79デフォルトの名無しさん2018/09/06(木) 23:36:20.94ID:OdtAawkS
>>70
そのサイトには賛成できる部分と反対の部分がある

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

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

80デフォルトの名無しさん2018/09/06(木) 23:37:17.79ID:OdtAawkS
>>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向

81デフォルトの名無しさん2018/09/07(金) 08:35:51.18ID:avaKv6NM
>>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います!

82デフォルトの名無しさん2018/09/07(金) 08:40:25.09ID:avaKv6NM
責務ごとにクラスを作るのがどうして主流だよね?ってことですよ

83デフォルトの名無しさん2018/09/07(金) 09:19:04.85ID:avaKv6NM
責務ごとに分離したら凝集度が低下します

84デフォルトの名無しさん2018/09/07(金) 19:25:29.09ID:ZCXZkOYn
>>81
それもそうか

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

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

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

85デフォルトの名無しさん2018/09/07(金) 19:40:40.77ID:Nc+ifFiB
ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな?
どうもUI部の設計は苦手だ。

86デフォルトの名無しさん2018/09/07(金) 20:33:13.60ID:avaKv6NM
>>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります

87デフォルトの名無しさん2018/09/07(金) 20:36:30.67ID:avaKv6NM
ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです

88デフォルトの名無しさん2018/09/07(金) 20:48:57.91ID:ZCXZkOYn
>>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う

89デフォルトの名無しさん2018/09/07(金) 20:49:13.32ID:ZCXZkOYn
>>86
>データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる

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

90デフォルトの名無しさん2018/09/07(金) 21:07:16.42ID:0j44DGgx
>>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと

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

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

91デフォルトの名無しさん2018/09/07(金) 21:09:02.84ID:0j44DGgx
データに対する振る舞いが集まるんだから凝集度は高まるんです

92デフォルトの名無しさん2018/09/07(金) 21:12:47.16ID:0j44DGgx
オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます

93デフォルトの名無しさん2018/09/07(金) 21:15:03.24ID:Nc+ifFiB
皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。

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

94デフォルトの名無しさん2018/09/07(金) 21:16:51.88ID:lg5TGvmQ
>>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。

95デフォルトの名無しさん2018/09/07(金) 22:12:16.23ID:ZCXZkOYn
>>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋

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

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

96デフォルトの名無しさん2018/09/07(金) 22:14:41.41ID:ZCXZkOYn
>>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事


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

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

97デフォルトの名無しさん2018/09/07(金) 22:15:21.48ID:JescaW/f
つか、ワンオブジェクトワンファイルなんてルールは無いから。

98デフォルトの名無しさん2018/09/07(金) 22:58:43.86ID:B/yxkRYZ
このスレにいるような池沼が作らなければ
クラスライブラリも階層や種類で作るからな

低い階層に行けばいくほど単純な簡単な機能を提供するクラスになる
階層は完全に分離させて独立したライブラリにする

そして明確に種類の異なるプリミティブがある場合は
ライブラリを完全に分離させて独立したライブラリにする

その上にアプリケーションを実現するクラス群がのっかる

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

99デフォルトの名無しさん2018/09/08(土) 02:09:56.99ID:WAR6v8yR
クラスに階層があるなんて寝言は寝て言うべきだと思うの

100デフォルトの名無しさん2018/09/08(土) 02:15:00.94ID:WAR6v8yR
このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ

■ このスレッドは過去ログ倉庫に格納されています