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

レス数が1000を超えています。これ以上書き込みはできません。
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
このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ

101デフォルトの名無しさん2018/09/08(土) 02:18:28.54ID:j/6nk0eH
当然、低レベルな部分を実現するクラスライブラリと
アプリケーションが主に利用する中間層のクラスライブラリと
アプリケーション自体を記述するクラス群は
シロウトでもないかぎり完全に分離するからな

低レベルな部分を実現するクラスライブラリは
当然、中間層のクラスライブラリやアプリケーション自体を記述するクラス群を
参照することはまずない

アプリケーションが主に利用する中間層のクラスライブラリは
アプリケーション自体を記述するクラス群を参照することはまずない

低学歴知恵遅れが作ると酷い依存関係ができる
コレはオブジェクト指向関係なくライブラリの基本だからな

102デフォルトの名無しさん2018/09/08(土) 04:34:33.80ID:xpw/+eIi
>>99
継承はクラス間の階層構造だろ?

>>100
行数だけの問題じゃないけど
プログラムを単純化するために
間接的なクラスを作ることはあるぞ?

103デフォルトの名無しさん2018/09/08(土) 09:24:01.98ID:t/+GvP7Y
× このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。

「行数を減らす」は「責務」ではない。「責務」を分離することで
得られる結果(メリット)の一つだ

104デフォルトの名無しさん2018/09/08(土) 12:06:19.78ID:GaM457i+
>70のサイト読んでると

プログラミングでどの様にしてプログラミングするか
というのと
実際のシステム要件なんかからどうやって設計するか
というのがごっちゃに書かれている感じがする

105デフォルトの名無しさん2018/09/08(土) 12:33:05.14ID:1I6Cu01I
>>103
鋭い

106デフォルトの名無しさん2018/09/08(土) 12:41:12.60ID:j/6nk0eH
責務とアホみたいなこといってるわ
組織でたとえるならこうなるからな

 経営者クラス 社員をこき使う
  ↓
 社員クラス ← 派遣をこき使う(職階ごとの複数の中間層)
  ↓
 派遣クラス ← キミラが担当するような低レベルな部分の単純作業(つまりキミラ)

派遣は社員の作業も役員の作業もしない
社員は役員の作業はしない

行数が多いのは
作業を整理して作業を手順化して
派遣にうまく単純作業を割り当てれてないのと同じだからな
つまり、人に仕事させないと自分の作業が増える

キミラは派遣だからな、そういう作業はできないのは分かる

作業ミス(例外)が発生してスルーし続けてたら上までいくからな

107デフォルトの名無しさん2018/09/08(土) 12:52:36.37ID:j/6nk0eH
例えば扱うビジネスの領域が違えば
部門を分けることになる

会社に複数の部門があっても一つの会社だからな
種類で分けるというのはそういうことになる

キミラみたいな一種類の単純作業しかしてないヤツラには関係ない

108デフォルトの名無しさん2018/09/08(土) 13:03:07.35ID:j/6nk0eH
というわけでな
キミラは刺身にタンポポのせる作業に戻りなさい
キミラにはムリ

109デフォルトの名無しさん2018/09/08(土) 13:03:32.85ID:t/+GvP7Y
キミラには・・・キミラには・・・

110デフォルトの名無しさん2018/09/08(土) 13:11:07.86ID:j/6nk0eH
あ、オマエは刺身の醤油入れに醤油つめる作業だったか
いや、醤油入れのキャップをしめる作業だったか

ともかく、キミの細かい作業なんかオレは知らないからな
作業ミスが発生したらちゃんと報告するようにな

まずキミの直属の上長にだ

分かった?

111デフォルトの名無しさん2018/09/08(土) 13:22:45.36ID:t/+GvP7Y
キミラは下で俺が上だ・・・上なんだ・・・

112デフォルトの名無しさん2018/09/08(土) 14:59:23.20ID:1I6Cu01I
>>106
それだと上位が下位に依存して
組織が硬直化する
インタフェスを挟んで依存関係を逆転させる

(経営者クラス → 社員インタフェス) ← (社員クラス → 派遣インタフェス) ← 派遣クラス

これがInversion Of Control

113デフォルトの名無しさん2018/09/08(土) 15:00:32.82ID:t/+GvP7Y
>>112
それどこの定義?
それと同じような説明をしてる場所教えて

114デフォルトの名無しさん2018/09/08(土) 15:11:58.88ID:1I6Cu01I
Inversion of Controlパターンでコンポーネント間の結びつきを弱める:CodeZine(コードジン)
https://codezine.jp/article/detail/60

こことか

115デフォルトの名無しさん2018/09/08(土) 15:40:47.46ID:j/6nk0eH
ただのリフレクションやんけ
昔のウンコMFCのコントロールのリフレクションとほとんど同じ
結局親のコントロールに大量のリフレクションのコードを埋め込むことになる

コントロールごとに処理記述するほうがはるかに分かりやすい

116デフォルトの名無しさん2018/09/08(土) 15:43:54.64ID:j/6nk0eH
×結びつきを弱める
○もともと末端ではなにもしない処理にする

117デフォルトの名無しさん2018/09/08(土) 15:51:53.40ID:1I6Cu01I
何もしないだと・・・
じゃあたんぽぽ担当は何のために

118デフォルトの名無しさん2018/09/08(土) 16:07:40.80ID:j/6nk0eH
いちいちタンポポ載せてる作業経過報告はいらない
作業の補助とか、いちいち次になにをするかとかとか指示はしないからな

タンポポが地面に落ちたとかこのタンポポのハナ小さいとか
そういう報告もいらない
捨てときなさい
それぐらい分かるだろう

タンポポが足りなくなりそうになったら
この台帳に書いときなさい
コレだけはたまに見といてやるからな

119デフォルトの名無しさん2018/09/08(土) 16:11:08.60ID:1I6Cu01I
台帳によって疎結合になるわけですね

120デフォルトの名無しさん2018/09/08(土) 16:11:29.17ID:1I6Cu01I
台帳オブジェクトの発見、これがドメイン分析

121デフォルトの名無しさん2018/09/09(日) 00:27:26.13ID:fJdKrV9d
タンポポの弾幕

122デフォルトの名無しさん2018/09/09(日) 01:14:12.52ID:0bXk8YdS
DBのテーブル数や列数が少なくて
テーブル設計が洗練されているならオブジェクト指向っていいんだろうね。
でも現実のシステム考えるとアホみたいにテーブルの数が多くて
アホみたいに列の数が多くて、整理もされていないわけじゃん。
そしてアホみたいに文言の定数定義とかも多い。
そうすると、階層構造作ってレイヤの数を増やして
結果的1つの機能を達成するのに作るファイルの数が増えるほど、
それらのアホみたいに多くて長い列名をレイヤの数だけ書きまくる
みたいな苦行が待っているわけじゃん。
少しでも項目名の変更があったらそれらのファイル部書き換えたり
クラス名に変更がありでもしたらファイル名やフォルダ名とか、
テーブル名、import文とか全部書き換えになるわけじゃん。
それにオブジェクト指向でどう頑張っても最終的に値を
埋め込む画面が汚くなるのは避けることができない。
そうするとオブジェクト指向設計で無理にファイルを分けて
構造化するリスクってやばいと思う。
そうなると少ないファイルオブジェクト指向クソ喰らえみたいな勢いで
構造化プログラミングだけでゴリッと書くほうが早いと思うんだよね。
命名規則もいちいち気を使わないで勢いで書くんだよ。
ファイルの中関数定義だらけになるが、
その中で似たような処理の関数見つけてきて、複製して、
今必要な処理ができるように改変して新たな関数を作る。これで十分だ。
1ファイルの中で完結しているんだから不具合は波及しない。
ファイルをまたいでimportして無理にファイルの昨日使う必要性なんて
どこにも有りはしないだろ。ファイルの頭からimportやextend inplementだらけ
とか吐き気がするよ。
オブジェクト指向ってファイル間の関連性追ったり、
ファイル構造を含んだデバッグの苦痛は無視してんのか?って思う。

123デフォルトの名無しさん2018/09/09(日) 02:14:14.22ID:rd2vglUK
今北産業

124デフォルトの名無しさん2018/09/09(日) 06:49:20.59ID:O317ycPa
>>122
簡単に言うと短期間しか使わないシステムなら
構造化+DBで組むのも良いと思うけど
長期間使う大規模なシステムは
オブジェクト指向で組んだ方が
保守まで含めた全体のコストは下がる
だから企業もOOを採用している

125デフォルトの名無しさん2018/09/09(日) 07:29:49.35ID:QdIWFdtA
>>122
それオブジェクト指向の問題じゃなく、システムの基本設計が破綻してるだけ。

126デフォルトの名無しさん2018/09/09(日) 07:53:15.67ID:B5kEXEZS
>オブジェクト指向ってファイル間の関連性追ったり、
>ファイル構造を含んだデバッグの苦痛は無視してんのか?って思う。

それはその通りだと思う
ただ関連性はプログラムではなくてクラス構造図やオブジェクト生成手順図みたいなので判断するもので所謂上から下に辿って見て行く物でも辿って出きる物でも無い
オブジェクト指向プログラミングをすると設計図をちゃんと描いてから作ってる
って感じがするし
ただまともに且つ効果的に作るのは難しくて解っていない人が無理やり作ってしまうと反って酷くなる
そういう風にしか作れなかったりそういう風な人しか居ないならオブジェクト指向プログラミングは止めておいた方が良いそういう風な所はcobolみたいなのが一番向いていると思う
ただしオブジェクト指向プログラミングに効果的な使い方が有り実際に行われているのでオブジェクト指向プログラミングその物がおかしいというのは間違い
多くの人が
使えるか?
使うべきか?
となるとそれは無理なのかなぁ
とは思う
どっちかって言うと解らないなら無理して使うなという物だと思う
解らない人が有る程度居る?沢山居る?ということならプロジェクトで使わないという判断する
というのが重要なんだと思う
解らない人には苦痛でしかないし解らない人が作った物は本人にも他に人にも迷惑でしかないだろうなぁ

127デフォルトの名無しさん2018/09/10(月) 23:59:27.90ID:R+xXPRjE
オブジェクト指向がよくわからんド素人俺にはlinqは感動した。
web系フレームワークの真似事+継承だらけのコードのメンテは地獄だった。素人が手をだしたらアカン代物だわ。

128デフォルトの名無しさん2018/09/17(月) 13:28:16.75ID:hCpxPlj7
ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html

129デフォルトの名無しさん2018/09/17(月) 13:30:49.79ID:27GPeyCI
>>128
なんか気持ち悪い、アスペっぽい

130デフォルトの名無しさん2018/09/17(月) 13:30:59.69ID:6+Wt0ENU
またお前か

131デフォルトの名無しさん2018/09/17(月) 22:41:39.72ID:AYOVQ736
>>130
なんか気持ち悪い、糖質っぽい

132デフォルトの名無しさん2018/09/19(水) 05:57:49.26ID:zGAoAQgA
>>128
そのブログ前も見たけど説明が下手だなあ……

何でデザインパターンが必要なのかとか
自分の言葉でほとんど説明できてないじゃん
分かりやすさ以前に分かる説明をしていない

133デフォルトの名無しさん2018/09/19(水) 19:25:49.89ID:3+BPTz35
>>125
そらーオブジェクト指向はオブジェクト使うからオブジェクトの構造をちゃんと綺麗に作れば問題は起きないな
オブジェクトの構造と言えばオブジェクト同士の繋がり方関連性も含まれるだろうからそのまま全体像にも繋がるから個々のオブジェクトさえちゃんと作れば全部が良くなるとも言えるはず

問題はシステムの基本設計が破錠しないように作ればいい、ということではなくて破錠しやすいという所にあるような

134デフォルトの名無しさん2018/09/19(水) 23:52:24.34ID:YoDbSZZU
>>133
知ったかツマラン。

135デフォルトの名無しさん2018/09/20(木) 00:25:31.99ID:UYyYb6vq
>>134
そやな。俺が知ってる唯一の情報がオブジェクト指向はシステムの基本設計が破綻するってだけだからな。

136デフォルトの名無しさん2018/09/20(木) 08:07:35.90ID:v1EqyHAs
俺が知ってる情報は次の2つだ
1.バカが使うとどんな言語でも破綻する
2.>>133-135はそのバカに属する

137デフォルトの名無しさん2018/09/20(木) 17:06:26.63ID:UYyYb6vq
>>136
問題はそこからやな
バカが使わなければ破錠しないのか、隠蔽のコスパが手続き型や関数型で作るコスパを本当に上回ってんのか

138デフォルトの名無しさん2018/09/20(木) 19:40:11.95ID:v1EqyHAs
>>137
隠蔽のコスパとか言うバカ乙 w

139デフォルトの名無しさん2018/09/21(金) 19:22:25.43ID:+zpU6K4O
オブジェクト指向は複雑な構造を構築するわけだから
別に破綻はしないだろう
むしろ見た目は良い

140デフォルトの名無しさん2018/09/21(金) 20:28:00.82ID:qgyq16h9
オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと

141デフォルトの名無しさん2018/09/21(金) 20:46:48.28ID:qgyq16h9
小規模ならいいが大規模だと設計必須
とりあえず書き始めると最後に詰まるのがオブジェクト指向

小っちゃいパーツを作ってって最後に組み合わせるとき全然組み合わなかったり
つなぎ目の形が合わないのがオブジェクト指向

普通は小さいパーツが出来てるならある程度楽できるはずなのに逆に苦しくなる
本当におかしい

142デフォルトの名無しさん2018/09/21(金) 20:51:36.57ID:qgyq16h9
クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく
インターフェイスを考えた上の設計がないと後で詰まる
当たり前に思ってるけどそれはオブジェクト指向の限界というか弊害

143デフォルトの名無しさん2018/09/22(土) 08:52:06.62ID:seN9Vjts
つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな

144デフォルトの名無しさん2018/09/22(土) 09:44:45.27ID:jtQ8570T
>>140
境界定義なんて、モノリシックアプリでも必須なんだが?
その認識もないままオブジェクト指向とかマイクロサービスに手を出すとグダる。

開発チームを苦しめるマイクロサービス(翻訳)
https://techracho.bpsinc.jp/hachi8833/2018_01_29/51135

145デフォルトの名無しさん2018/09/22(土) 09:58:06.00ID:LHC7cNdc
>>142
限界? 弊害?

>>142のどこに限界や弊害が書いてあるの?

146デフォルトの名無しさん2018/09/22(土) 14:09:59.67ID:ycLOp2uz
>>145
あんまりそこにしっかり書かれていないから語弊ありきで言うんだが
その抽象的間接的に作らなきゃいけないてことやな
作ってもいい、じゃなくて作らなきゃいけないという

147デフォルトの名無しさん2018/09/22(土) 15:20:24.84ID:LHC7cNdc
>>146
そりゃ大規模プログラムをメンテナンス性あげて作ろうとしたら
オブジェクト指向に限らず、考えなきゃいけないことだろな。

でも破綻していいなら、別に抽象的間接的に作らなくていい。
小さなツール程度ならゴットクラスで破綻状態でもなんとかできるだろうさ
そういう点で、オブジェクト指向の限界でも弊害でも何でも無い

148デフォルトの名無しさん2018/09/23(日) 01:13:41.68ID:MlhnYRcx
>>147
いや俺の言う破綻てのは別にオブジェクトオンリーにこだわって
細かいとこをクロージャで逃げたり、その場しのぎ的に小さいオブジェクトで茶を濁すのもダメって意味じゃないんよ
小さいオブジェクトならオブジェクト同士やシステムが密結合になりえないだろうしな

オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな

149デフォルトの名無しさん2018/09/23(日) 04:48:40.07ID:N8r2Gw6d
> オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな

因果関係が逆

密結合の時・・・問題や破綻が起きる(オブジェクト指向に限らない)

話はこれだけだろう?単純だろうが

150デフォルトの名無しさん2018/09/23(日) 10:01:28.60ID:y+eZw7HP
普通に組めばいいじゃん

151デフォルトの名無しさん2018/09/23(日) 11:37:45.64ID:0vXeudiz
>>149
おまえめちゃめちゃバカやなw

152デフォルトの名無しさん2018/09/23(日) 12:09:34.69ID:loi8GnJQ
まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。
〜指向全般に言えるけれど、結局は一つの指標みたいなもんで
指標上げることが目的になったらクソになるのは当たり前だよね。

153デフォルトの名無しさん2018/09/23(日) 12:29:12.02ID:0vXeudiz
バカすぎて意味がつながっとらんw

154デフォルトの名無しさん2018/09/23(日) 15:43:38.58ID:w6QfJYdi
オブジェクト指向に継承って要る?
もともとのオブジェクト指向の発想からすれば、別に無くてもいいっていうか、むしろ邪魔じゃね?

155デフォルトの名無しさん2018/09/23(日) 16:17:15.71ID:NWkg7eaT
>>154
継承でコードを書く量を減らせるってのはあるが、他の仕組みで代わりになるなら無くても良い

156デフォルトの名無しさん2018/09/23(日) 16:31:30.62ID:NWkg7eaT
ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ

157デフォルトの名無しさん2018/09/23(日) 16:37:33.42ID:MlhnYRcx
>>149
ちゃうねん

複雑で大規模なモノは何で組もうが問題や破綻が起きやすくなる、って話と
オブジェクト指向は複雑で 大規模なモノを作ると破綻する、ってのは意味が違う
何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。話の流れで言うと前者により後者が悪質な形で発動する

ただ当然理想論言えば問題を元々起こさなきゃいいっちゃいい話よ理想を言えば

158デフォルトの名無しさん2018/09/23(日) 16:50:39.86ID:N8r2Gw6d
> 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。
前提が間違っているから話にならん。

まず標準ライブラリの時点ですでに大規模で複雑
それが隠蔽されてるから単純に見えるってことに気づいていない
大規模で複雑なものを作るためだけのものだからというのなら、
ほとんどのものが大規模で複雑なんだから、オブジェクト指向を
使うのは当然ということになる


そして隠蔽されている部分は無視するという話なら、(オブジェクト指向の)
標準ライブラリを使うだけの簡単なコードは作れる
例えば、Rubyでprint "hello world"と書いただけでもオブジェクト指向が使われてる
オブジェクト指向であっても、小規模で単純なものを作れるものである証拠

159デフォルトの名無しさん2018/09/23(日) 17:11:55.75ID:MlhnYRcx
>>158
オブジェクト指向言語の標準ライブラリとか1番破綻しないオブジェクト指向のパターンじゃないか?
そりゃ全てのオブジェクト指向で作った物が全て破綻することはないだろう

大規模に向いてるオブジェクト指向をあえて小規模なもの作るに都合いいから流用するのはいい事だろう。個人的には自分で作ったクラスを多数のところで使い回してるならそれぞれ小規模でも全体でみたら中、大規模じゃんってなる所はあるけども

とわいえ、それでもやっぱりオブジェクト指向は大規模なものの為”だけ”にあって、そのため”だけ”の機能があって、そのせいで破綻するってのが俺の考えよ

160デフォルトの名無しさん2018/09/23(日) 17:22:45.03ID:N8r2Gw6d
>>159
だからオブジェクト指向で小規模なものを作る例あげたじゃん。
馬鹿なの?

大規模なら破綻するのは、オブジェクト指向で無くても同じ

つまりお前の理屈は
 オブジェクト指向・・・小規模は作れない、大規模は作れる
 ???指向・・・小規模は作れる、大規模も作れる
って言ってるだけでしょ

で大規模であれば、破綻するのはどちらも同じなんだから
大規模に置いてはオブジェクト指向も???指向も変わらない
だからオブジェクト指向で、小規模は作れないと言ってるだけだよね?
(実際にはオブジェクト指向で小規模なものが作れる)

161デフォルトの名無しさん2018/09/23(日) 17:45:57.32ID:cRG95Xcq
この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる

 @公開インタフェースは可能な限り少なくする
 A原則として、よほど適切な理由がないかぎり、可能な限り継承よりコンポジション使う
 B下位階層(ここでの階層は>>101>>106の意味)のクラスが上位階層のクラスのインターフェースに絶対に直接アクセスしてはいけない
  ※ 当然、下位クラスが上位クラスのインターフェースを直接呼びだすようなリフレクションは禁止
 C下位階層のインスタンスが非同期で上位のインスタンスに処理を依頼したい状況が発生した場合(可能な限りこんな状況が起きる設計は当然避けるべき)、
  処理のやりとりはメッセージキューで行い、可能な限り少ない回数で簡潔なメッセージを用いて簡単に完結できるようにする、複雑なメッセージシーケンスも禁止
  (コレは並立するインスタンス間でも同じ)
 D同じ階層に並立するインスタンスをムダに乱立させるのは当然禁止

コンポジションとメッセージシーケンス、クラスの階層(ここでの階層は>>101>>106の意味)、インスタンスの生存期間さえ
ドキュメントで適切におさえることができる状態になっていれば
問題やエンハンスが発生しても持続可能対応できる

162デフォルトの名無しさん2018/09/23(日) 19:29:44.09ID:y+eZw7HP
オブジェクト指向にメリットなんて無いからね

163デフォルトの名無しさん2018/09/23(日) 20:20:35.62ID:MlhnYRcx
>>160
そりゃ作れないなんて言ってないがな。
「オブジェクト指向は大規模なモノを作る為だけにある」って話であって「オブジェクト指向は小規模なモノは絶対に作れない」とはならんからな

ただオブジェクト指向で小規模なモノ作ったらデータをオブジェクトでラッピングしやすいてのがあるけど
あれ完全に全くの偶然でデータをオブジェクトにまとめるのがオブジェクト指向の本丸じゃないように、オブジェクト指向の本丸ではないサブシステムが運良くそこにハマったってだけで
特にそこもオブジェクト指向は大規模なモノを作る為”だけ”にあるってのは意味は変わってないからな

俺が言ってるのは一般的にモノが複雑になれば破綻しやすいという話ではなくて
、”その上で更に”オブジェクト指向は独特の破綻を招くって話であって

164デフォルトの名無しさん2018/09/23(日) 21:48:23.69ID:N8r2Gw6d
>>163
あー、わかったわかった、つまりこういうことだろ?

墜落事故は飛行機特有の問題だ
自動車は飛べないから墜落自体ありえない

自動車で遠くにいくなら時間はかかるし
距離も長いから事故の確率も上がるし大変だが
飛べないから墜落事故は起きないのだ

165デフォルトの名無しさん2018/09/23(日) 21:50:15.95ID:N8r2Gw6d
そう主張することで、飛行機の何を否定しているのかわからんのと
どうように、オブジェクト指向の何を否定しているのかわからんがなw

166デフォルトの名無しさん2018/09/23(日) 21:51:15.19ID:0vXeudiz
おまえら破綻しすぎじゃね?w
どうやったらそんなに破綻を量産できんねんw

167デフォルトの名無しさん2018/09/23(日) 22:02:41.85ID:MlhnYRcx
>>164
オブジェクト指向の話で悪い例え話したら1番イカンやろ。抽象的なもんの取り扱いなんだから。しかも何言ってるかわからんけど多分それは違うしな

>>166
いやまさにそういう事よ。多人数が動く大規模で抽象的な流れは上手くいくはずがないわ。しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する

168デフォルトの名無しさん2018/09/23(日) 22:26:37.81ID:N8r2Gw6d
>>167
> オブジェクト指向の話で悪い例え話したら1番イカンやろ。

は?なんで?
反論できない言い訳にもほどがあるわ

169デフォルトの名無しさん2018/09/23(日) 22:28:04.83ID:N8r2Gw6d
> しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する

しない。
オブジェクト指向を使わないほうが破綻するし、
破綻した後のリカバリーはオブジェクト指向よりも大変

お前は単に両方とも破綻するが
オブジェクト指向的破綻をするのはオブジェクト指向だけと言ってるだけだろ

破綻する時点で問題なんだよ。オブジェクト指向の方が破綻しない

170デフォルトの名無しさん2018/09/23(日) 22:42:45.15ID:MlhnYRcx
>>169
>オブジェクト指向的破綻をするのはオブジェクト指向だけと
そういう事や。楽をするためにそれをするメリットが上回ってデメリットのが下回らなきゃいけないのはオブジェクト指向の完全必須項目なんだが
大規模複雑はこの完全必須項目がどんどん難易度が上がってくる。
途中の間違い失敗のリカバリのコストは確実にオブジェクト指向のが上

理想論一般論で言えば間違えなくちゃんと作ればいい、どの作り方でも大きいのは大変は大変、以上!て言えばそりゃそうだが
その問題を防ぐための記法が裏目に出て逆効果なら理想論一般論で片付けたらいかんでしょ

171デフォルトの名無しさん2018/09/23(日) 23:17:04.84ID:N8r2Gw6d
>>170
ほらな。

> >オブジェクト指向的破綻をするのはオブジェクト指向だけと
> そういう事や。

墜落事故を起すのは飛行機だけだと言ってるのと同じ
だからなの?状態なんだよwww

172デフォルトの名無しさん2018/09/23(日) 23:18:16.29ID:N8r2Gw6d
結局、小規模アプリでも大規模アプリでも
オブジェクト指向のほうが良いって結論なわけだよ。

そして、大規模で破綻するのはオブジェクト指向じゃなくても同じこと

173デフォルトの名無しさん2018/09/23(日) 23:18:37.66ID:N8r2Gw6d
ただの言葉遊びだったな

174デフォルトの名無しさん2018/09/23(日) 23:26:41.71ID:loi8GnJQ
そうなりやすいのがオブジェクト指向論争

175デフォルトの名無しさん2018/09/23(日) 23:28:46.55ID:cRG95Xcq
バカに限って抽象化とかいって
サルみたいにうれしがって継承するからな

破綻はそこから始まる

しばらくたつと
データ受け渡しするために
無秩序に相互参照しはじめる

こうなったら終わりの始まり

176デフォルトの名無しさん2018/09/23(日) 23:33:26.91ID:N8r2Gw6d
同じものを作る時、オブジェクト指向はオブジェク手と指向破綻をしやすいが
オブジェクト指向じゃないものを使うと、オブジェクト指向じゃない破綻をする
って言ってるだけ。

オブジェクト指向だと大規模なものを作れる。
オブジェクト指向じゃないと大規模なものは作れない

177デフォルトの名無しさん2018/09/24(月) 00:03:50.44ID:+ob6DU4m
オブジェクト指向じゃなくしたから
大規模なシステムを作れるようになった
って話はあまり聞かない

178デフォルトの名無しさん2018/09/24(月) 01:12:57.64ID:oYzwCf5A
オブジェクト指向にメリットなんて無いからね

179デフォルトの名無しさん2018/09/24(月) 09:54:20.13ID:dKKNaNpJ
ただモジュール境界を明確にしただけなのをオブジェクト指向って言い張ってるだけだろうな。

「オブジェクト指向じゃないと大規模なものは作れない」
この結論ありきで論法を組み立てるとそうなる。

180デフォルトの名無しさん2018/09/24(月) 16:52:34.59ID:JEGqIfby
>>171
そのアカン例えを使うなと

事故が多発しないはずのシステムでそのシステム特有の事故が多発したって話やな
まぁ、その、悪い例えにあえて乗っかるなら自動車で事故りそうだから飛行機に乗ったら墜落事故起こしたって、だからなんだよって言ったらそりゃダメだよってなるような話で

いややっぱアカンやろこの例え、設計を抽象的な部分から見直せ

181デフォルトの名無しさん2018/09/24(月) 18:34:58.60ID:jnbiRGGY
まぁオブジェクト指向は「銀の弾丸」じゃないですからね
オブジェクト指向の採用による成功事例は数多く存在する一方で、
オブジェクト指向を採用したにもかかわらず失敗した事例も
少数とはいえ存在するのも事実

たとえば、以下は「一貫性」という設計哲学が無視されてしまったため、
標準ライブラリ設計に失敗した言語の例

 http://mevius.2ch.net/test/read.cgi/tech/1491491123/44-45/
 http://mevius.2ch.net/test/read.cgi/tech/1530664695/527/

スレタイに沿って返すとすれば:
・あらゆる言語においてオブジェクト指向ってクソじゃね?
  => いいや、そんなことはない
・Pythonにおいてオブジェクト指向ってクソじゃね?
  => たしかに、Pythonではクソかもしれない

182デフォルトの名無しさん2018/09/24(月) 18:36:05.95ID:csv6kfNU
>>180
とりあえずお前が馬鹿だっていうのはわかった

大規模なものはどちらにしろ問題が発生する。
オブジェクト指向的問題か
非オブジェクト指向的問題かの
どちらかだ。

オブジェクト指向を使わなかったら
今度は非オブジェクト指向問題が発生するだろ

183デフォルトの名無しさん2018/09/24(月) 18:37:21.47ID:csv6kfNU
>>181
Pythonで大規模アプリ作って失敗したら
Python的問題が発生したということさ
C言語で失敗したらC言語的問題が発生したということさ

184デフォルトの名無しさん2018/09/24(月) 18:42:13.65ID:csv6kfNU
仮にオブジェクト指向設計を採用せずに
構造化設計を採用したとしよう。
大規模プログラムで密結合になってると失敗する
そうすると構造化設計特有の問題が発生したということで
それはオブジェクト指向よりもリカバリーが大変

185デフォルトの名無しさん2018/09/24(月) 18:42:49.46ID:FEoaRsa5
どうでもいい話だな

186デフォルトの名無しさん2018/09/24(月) 18:43:48.46ID:JEGqIfby
>>182
んなもん当たり前だろ別のやり方すれば別の問題があるに決まってやろ
そんな何にでも通ずる一般論じゃないの

オブジェクト指向がそれ専用なのに逆効果だから色々言ってるの
これは何にでも通ずるフラットな一般論じゃないぞ?何故ならオブジェクト指向はそれ専用なのに逆効果だからな、いわばイレギュラーで根本的な問題

187デフォルトの名無しさん2018/09/24(月) 18:44:29.97ID:csv6kfNU
そう。ただの言葉遊びしてるだけだからどうでもいいこと
結局は構造化設計を選んで失敗したから
構造化設計に問題があると言ってるだけなんだから
自分の非を認めたくないからそういことをしてる
あ、オブジェクト指向が使えないんだっけか?w

188デフォルトの名無しさん2018/09/24(月) 18:45:02.09ID:csv6kfNU
>>186
いつからオブジェクト指向がそれ専用になったんでーすかーw

おかしいですねwww

189デフォルトの名無しさん2018/09/24(月) 18:46:46.24ID:csv6kfNU
構造化設計は大規模に向かないのである

構造化設計で大規模をやると
失敗する確率が大幅に上がる
構造化設計+大規模でなんども経験している

そしてオブジェクト指向で設計すると
失敗する確率は大幅に下がるわけだが
それでも失敗してしまったら文句を言おう

オブジェクト指向が問題だったんだー!

190デフォルトの名無しさん2018/09/24(月) 18:54:12.30ID:JEGqIfby
>>188
>いつからか
そらー最初からやな。そのため”だけ”やしな

191デフォルトの名無しさん2018/09/24(月) 18:55:45.99ID:JEGqIfby
>>189
おっ?そうだなオブジェクト指向が問題が問題だったんだ。なんだかんだ同意見やったんやな

192デフォルトの名無しさん2018/09/24(月) 19:07:39.30ID:jnbiRGGY
>>189
>そしてオブジェクト指向で設計すると
>失敗する確率は大幅に下がるわけだが

ここは同意しますけど、

>それでも失敗してしまったら文句を言おう
>
>オブジェクト指向が問題だったんだー!

勘弁してください
数ある言語の中でも失敗してるのはPythonだけなんですから(>>181)、
失敗をオブジェクト指向のせいにしようとしても
それに納得するのはPython信者だけですよ

>>183でもご自分で「Python的問題」と語っていますから、矛盾してます

193デフォルトの名無しさん2018/09/24(月) 19:08:50.83ID:csv6kfNU
>>190
> そらー最初からやな。そのため”だけ”やしな

そのためって、オブジェクト指向は大規模のときに使うってこと?

ってことは、大規模で問題が起きたら、
それはオブジェクト指向が原因ではないってことだね

だって、単に大規模だからオブジェクト指向を使ったってだけで
大規模で失敗するのは構造化であっても同じだから

>>191
皮肉もわからんのかーwww

194デフォルトの名無しさん2018/09/24(月) 19:13:55.57ID:csv6kfNU
まとめ

構造化・・・大規模に適していない
オブジェクト指向・・・大規模に適している

構造化で小規模・・・失敗しにくい(所詮小規模なので)
オブジェクト指向で小規模・・・失敗しにくい(小規模に使えないとは誰も言ってない)

構造化で大規模・・・適していないので失敗しやすい
オブジェクト指向で大規模・・・適しているので失敗しにくい


構造化で大規模で失敗・・・失敗して当然。構造化に問題があった
オブジェクト指向で大規模で失敗・・・適した道具を使っても失敗した
                  使ってるやつの能力に問題がある
                  責任転嫁としてオブジェクト指向使ったから失敗したんやーと叫ぶw

195デフォルトの名無しさん2018/09/24(月) 19:14:23.90ID:Kxio7RVg
Cで書かれたOSはくさるほどある
C++で書かれたOSなんかあんの

196デフォルトの名無しさん2018/09/24(月) 19:18:02.09ID:JEGqIfby
>>192
もう謎のテンション上げで冷静な会話無理やろ、
1レス目の冷静そうな語り口調急にが帰ってきたらそれはそれでキモイけど、、

197デフォルトの名無しさん2018/09/24(月) 19:21:50.21ID:Kxio7RVg
超大規模なMS WindowsもCで書かれてる

198デフォルトの名無しさん2018/09/24(月) 19:21:52.45ID:csv6kfNU
>>196
お前の会話が非論理的だからしょうがない。

オブジェクト指向に問題があったんじゃなくて
大規模で密結合にしたから失敗があっただけだろ?
構造化であっても密結合にしたら失敗するんだから

で、構造化使って密結合にして失敗したら構造化のせいにせずに
オブジェクト指向を使って密結合にして失敗したら
オブジェクト指向のせいにしてるんだろ?

199デフォルトの名無しさん2018/09/24(月) 19:23:43.41ID:csv6kfNU
どちらにしろ
構造化よりもオブジェクト指向のほうが大規模に強いのは変わらん

オブジェクト指向が大規模のために作られたと言っても
小規模で使えないことにもならない
実際に小規模でも使える

オブジェクト指向で失敗するようなら構造化でも失敗する。
能力不足が原因だからな。

で、能力不足を認めたくないから、
オブジェクト指向のせいにしてるんだろ?

200デフォルトの名無しさん2018/09/24(月) 19:23:52.69ID:0XIVTMWe
そもそも破綻している、と言える状態はどんな場合だろうか

201デフォルトの名無しさん2018/09/24(月) 19:24:42.73ID:Kxio7RVg
だいたいわかる

ウンコスクリプトしか使えないような低学歴知恵遅れが
ムダにオブジェクト指向あげしてる

202デフォルトの名無しさん2018/09/24(月) 19:26:39.65ID:csv6kfNU
馬鹿「オブジェクト指向で失敗したら、オブジェクト指向特有の・・・」

じゃあ、構造化で失敗したら構造化特有のやり方が原因なんやな?

馬鹿「ぐぬぬ」

↑イマココ

203デフォルトの名無しさん2018/09/24(月) 19:27:16.94ID:Kxio7RVg
で、ウンコスクリプトで
山盛りのウンコをつくる

rubyとpython作ってるような
ウンコスクリプター

204デフォルトの名無しさん2018/09/24(月) 19:30:25.06ID:Kxio7RVg
コイツラの場合
ウンコスクリプトフレームワーク()使っても
破たんさせるほどの特殊能力がある

だいたいこういうの使ってるヤツラは
そういうヤツラだ

205デフォルトの名無しさん2018/09/24(月) 19:34:16.94ID:JEGqIfby
>>198
皮肉もわからんのかーwwwとか言うやつが急に非論理的だ、とか笑わせに来てんのか貴様は

なんだろうなお前の言い分は都合が悪いと全部一般論にして逃げてる感あるな、大規模なモノが破綻するのはオブジェクト指向に限らずみんな一緒とか。
それを言うならオブジェクト指向使わず手続き型で組んでも破綻しないように組めばいいじゃんってなるんだよな。
その先が見えないわけよな。もはや何の為にオブジェクト指向使ってるんという

206デフォルトの名無しさん2018/09/24(月) 19:36:53.39ID:JEGqIfby
>>200
オブジェクト指向の破綻はルール守る為に手続き型のコストを超えた時やろな

207デフォルトの名無しさん2018/09/24(月) 19:40:51.50ID:Kxio7RVg
ノータリン言語の開発現場には
ノータリンが集まる

コレは宿命

208デフォルトの名無しさん2018/09/24(月) 19:42:38.68ID:JEGqIfby
>>207
上でな、オブジェクト指向は壊れると言ったら壊れないように作ればいいという身も蓋も事を言われたんや
言語はそういう人のために作らないといけないかもしれん

209デフォルトの名無しさん2018/09/24(月) 19:45:46.24ID:BNNY8GPf
いつまで自演しとんねん

210デフォルトの名無しさん2018/09/24(月) 19:47:43.48ID:csv6kfNU
>>208
当たり前だろ

どんなものでも壊れるというのは大前提
どれだけ壊れにくいか?という壊れにくさの話をしてるのに、

お前は「オブジェクト指向は銀の弾丸でなければならないが
銀の弾丸でないことが判明したらどうする?」と言ってるだけだろ?

誰もオブジェクト指向が銀の弾丸なんていってない
だが強力な武器なんだよ。

211デフォルトの名無しさん2018/09/24(月) 19:48:10.66ID:dKKNaNpJ
とりあえずオブジェクト指向で作るってことがなんなのかから判別しようか。
例えばlinux kernelはオブジェクト指向でバリバリ作ってると思われてんのかね?

212デフォルトの名無しさん2018/09/24(月) 19:49:06.45ID:Kxio7RVg
ハードが壊れるのと
低学歴知恵遅れのオツムが壊れてるのは
別問題

213デフォルトの名無しさん2018/09/24(月) 19:50:21.60ID:BNNY8GPf
まだ自演を続けんのかよ
いい加減にしろ

214デフォルトの名無しさん2018/09/24(月) 19:57:16.26ID:Kxio7RVg
システムが壊れてるワケじゃない
壊れてるのは低学歴知恵遅れのオツム

オツムが壊れてないヤツが作れば
壊れたシステムはできあがらない

オブジェクト指向はキチガイに刃物

ノータリンにオブジェクト指向を促すこと自体が常軌を逸してる
ノータリンがオブジェクト指向で開発しようとすること自体が銃刀法違反並の重罪

215デフォルトの名無しさん2018/09/24(月) 20:01:34.39ID:H/ciA4Rj
オブジェクト指向って何ですか?
C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか?

216デフォルトの名無しさん2018/09/24(月) 20:07:21.20ID:Kxio7RVg
X11やMS Windowsもオブジェクト指向で設計されてる
ただ、低学歴知恵遅れでは、C言語でそれを実現することはできない

そしてそれを簡単に実現できる言語を使うと
なにが便利であるか核心的な部分が理解できずに使って
別のろくでもない問題をおこすわけ

217デフォルトの名無しさん2018/09/24(月) 20:10:52.64ID:Kxio7RVg
ハンドラやコンテキストつかって
オブジェクトを操作するのはまさしくオブジェクト指向の便利な部分だからな

UNIXのi/oなんかもハードウェアがうまく抽象化されてる
ファイルディスクリプタ使って簡単に読み書きができるからな

218デフォルトの名無しさん2018/09/24(月) 20:13:11.48ID:oYzwCf5A
オブジェクト指向にメリットなんて無いからね

219デフォルトの名無しさん2018/09/24(月) 20:17:40.60ID:csv6kfNU
>>215
> C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか?
大変だけどできるよ

作りやすいかどうか、失敗しやすいかどうかだから

220デフォルトの名無しさん2018/09/24(月) 20:22:15.20ID:csv6kfNU
結局の所、小規模なものはオブジェクト指向使っても失敗しない
大規模なものは、オブジェクト指向を使うと失敗しにくくなる
って所が重要なんじゃないですかね?


失敗したときにそれがオブジェクト指向的な原因か
構造化的な原因か、なんてことよりよりも

221デフォルトの名無しさん2018/09/24(月) 20:30:44.15ID:Kxio7RVg
低学歴知恵遅れにオブジェクト指向はまずムリ
日本では、ITドカタは低学歴底辺がなる職業だからな

だいたい程度がしれたヤツラが群がってくる
この板みれば分かるとおり

222デフォルトの名無しさん2018/09/24(月) 20:31:28.52ID:e4NBE4Fp
う〜ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。

何らかの問題を解決したい、もっと便利で問題の発生しない手法は無いだろうかというような要望があって、
それを実現するためにオブジェクト指向なるものが発明されたとすれば、
同じ考えでオブジェクト指向を採用するのも良いだろうけど、
最初からオブジェクト指向ありきはダメなんじゃないの?

なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。

223デフォルトの名無しさん2018/09/24(月) 20:32:33.20ID:csv6kfNU
>>222
お前の書き込みは、オブジェクト指向がクソだということが目的になっていて、
その他の何かが、オブジェクト指向よりも優れているという話になってない

224デフォルトの名無しさん2018/09/24(月) 20:35:08.38ID:csv6kfNU
>>221
優れた人が優れた道具を使う

それに対抗するために、もっと優れた道具ができたとしても
それだって優れた人が使ったほうがもっと効果が高いわけで

優れてない人が、優れてない道具を使って勝つには
人海戦術しかないんだよね

225デフォルトの名無しさん2018/09/24(月) 20:38:06.78ID:Kxio7RVg
ぜんぜん分かってないわ
刃物は道具でもあるし
人を殺すこともできる

226デフォルトの名無しさん2018/09/24(月) 20:38:44.95ID:Kxio7RVg
あやまった使い方をすれば
簡単にケガをする

227デフォルトの名無しさん2018/09/24(月) 20:42:45.07ID:e4NBE4Fp
>>223
いや、オブジェクト指向をクソだなんて思ってないよ。
むしろ好きな方なんで。

でも、肯定派の人ってありきでしょ。
それは違うかなって。

228デフォルトの名無しさん2018/09/24(月) 20:50:20.68ID:Kxio7RVg
教育コストはものすごいかかるが
手続き型言語でオブジェクト指向をみっちり体験してから
オブジェクト指向の教育に移行したほうがいい

この手順踏んだほうが間違いが少ない

そうでないと
ID:csv6kfNU ← コイツ
みたいに頭悪いのが大量に量産され続ける

229デフォルトの名無しさん2018/09/24(月) 21:03:48.14ID:u7Hms91/
>>228
バカにコストかけて教育するのもなんだかなー
バカとハサミは使いよう、というけれど、なかなか良い使いようが見つからんね。

230デフォルトの名無しさん2018/09/24(月) 21:19:43.39ID:AdxflhqI
オブジェクト指向のメリットって何?
この問いに今だかつて一人も答えてくれた事は無い
どっか他の文献指差して丸投げとか
逃げと食い下がりを駆使して結局答えないとか

231デフォルトの名無しさん2018/09/24(月) 21:47:42.62ID:oYzwCf5A
>>230
困ったことにどっかの文献ですら
ちゃんと理詰めで仕組みを解説してるものは皆無
完全なオカルトテクノロジー

232デフォルトの名無しさん2018/09/24(月) 21:48:43.99ID:FEoaRsa5
低学歴は無理せずにIT土方やってなさい

233デフォルトの名無しさん2018/09/24(月) 23:07:18.05ID:Kxio7RVg
転ばぬ先の杖
STOP オブジェクト指向

234デフォルトの名無しさん2018/09/24(月) 23:31:05.04ID:JEGqIfby
>>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う

235デフォルトの名無しさん2018/09/25(火) 08:11:13.05ID:ffbXNZny
色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか?
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ

236デフォルトの名無しさん2018/09/25(火) 08:46:47.22ID:Eix7hoc3
>>235
意味不明すぎてふいた

237デフォルトの名無しさん2018/09/25(火) 08:48:25.26ID:Eix7hoc3
オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ

238デフォルトの名無しさん2018/09/25(火) 08:48:47.92ID:Eix7hoc3
わかってんのかお前ら

239デフォルトの名無しさん2018/09/25(火) 11:00:50.48ID:bhDxFTjN
さっぱりわからない
オブジェクト指向のメリットとか特に

240デフォルトの名無しさん2018/09/25(火) 12:27:26.16ID:6l+mHu1d
ぶち込んだ経験ないやつには難しいやろな

241デフォルトの名無しさん2018/09/25(火) 12:30:49.14ID:Ti214GxU
オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた!

242デフォルトの名無しさん2018/09/25(火) 15:04:59.78ID:GnoTTlW7
>>215
>オブジェクト指向って何ですか?
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む

>C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい

243デフォルトの名無しさん2018/09/25(火) 15:05:47.22ID:GnoTTlW7
>>230
>オブジェクト指向のメリット
プログラムの変更コストが下がること

244デフォルトの名無しさん2018/09/25(火) 17:07:50.15ID:bhDxFTjN
>>243
どういう理由で?
オブジェクト単位に分けると仕様が消えるの?

245デフォルトの名無しさん2018/09/25(火) 18:10:21.54ID:GnoTTlW7
>>244
疎結合になるから

246デフォルトの名無しさん2018/09/25(火) 18:52:32.16ID:bhDxFTjN
>>245
それって君が想定した変更のときだけだよね?

247デフォルトの名無しさん2018/09/25(火) 18:58:18.78ID:bhDxFTjN
そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね?
無意味じゃない?

248デフォルトの名無しさん2018/09/25(火) 19:02:25.86ID:GnoTTlW7
>>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい

249デフォルトの名無しさん2018/09/25(火) 19:05:45.05ID:bhDxFTjN
>>248
別れてるからこそ変更しにくいって状況になったことがない?
経験不足じゃない?

250デフォルトの名無しさん2018/09/25(火) 19:10:47.09ID:bhDxFTjN
例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと

でもヘッダーは他の全てを知らないので関連するオブジェクト全てに手を入れなければならないと

こういうの想像できないの?
レベル低くね?

251デフォルトの名無しさん2018/09/25(火) 19:16:48.81ID:GnoTTlW7
>>249
いやいやそれこそ
オブジェクト指向開発での経験不足

252デフォルトの名無しさん2018/09/25(火) 19:22:34.13ID:GnoTTlW7
>>250
>ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト(クラス)にする

そのオブジェクトは当然関連するデータを知っているので
変更もスムーズにできる
一方オブジェクト指向でない場合には
それらのデータがバラバラになっているから変更しにくい

この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる

253デフォルトの名無しさん2018/09/25(火) 19:28:22.29ID:bhDxFTjN
>>252
って変更を各オブジェクトに入れないとできないよね?
c言語だと普通に処理書くだけやで

254デフォルトの名無しさん2018/09/25(火) 19:40:26.69ID:du+nhKJd
オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする

255デフォルトの名無しさん2018/09/25(火) 19:54:06.59ID:o8KZiItl
これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと

256デフォルトの名無しさん2018/09/25(火) 20:13:12.32ID:BMMTvniR
データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない

オブジェクト指向を勘違いしている人はオブジェクト指向を、
不可能なことを可能にする技術だと勘違いしておいて
不可能なことを可能にしてないと(自分の勘違いを)批判してる

オブジェクト指向は従来のやり方でも可能ではあるが
大変なことをより分かりやすく簡単に実現するための技術

257デフォルトの名無しさん2018/09/25(火) 20:53:51.26ID:GnoTTlW7
>>253
>c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい

258デフォルトの名無しさん2018/09/25(火) 21:06:16.95ID:BMMTvniR
オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない

259デフォルトの名無しさん2018/09/25(火) 21:51:35.20ID:CZcrESgD
強制的にOOに慣れるためのプログラミングスタイル、ってありませんか?

260デフォルトの名無しさん2018/09/25(火) 21:56:25.48ID:GnoTTlW7

261デフォルトの名無しさん2018/09/25(火) 22:15:26.66ID:CZcrESgD
>>260
thx a lot !!!

262デフォルトの名無しさん2018/09/25(火) 22:46:19.22ID:FLKmzsJJ
>>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと(自分の勘違いを)批判してる

こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい

263デフォルトの名無しさん2018/09/25(火) 22:57:23.11ID:BRabQ1iT
流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか?

264デフォルトの名無しさん2018/09/26(水) 00:31:24.02ID:bs5egenN
オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ

まあ嘘である

265デフォルトの名無しさん2018/09/26(水) 00:44:41.52ID:bs5egenN
>>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな

266デフォルトの名無しさん2018/09/26(水) 04:39:27.51ID:8XNtqdsN
セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。

おれの居るところ真逆のプロジェクトだ使いまくりでワロタ

267デフォルトの名無しさん2018/09/26(水) 06:02:50.00ID:Jt0rVGX1
セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな?

268デフォルトの名無しさん2018/09/26(水) 08:59:38.32ID:cdctReAr
>267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない

269デフォルトの名無しさん2018/09/26(水) 21:23:07.74ID:2wWeimMK
>>268
納得できる説明なのにおかしな改行で台無し・・・

270デフォルトの名無しさん2018/09/26(水) 22:10:14.19ID:Ye0laooE
メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。

271デフォルトの名無しさん2018/09/26(水) 22:27:48.39ID:xMAwDWlb
ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ

同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合したような糞

272デフォルトの名無しさん2018/09/26(水) 22:42:34.06ID:yzZF1GUc
>>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ

オブジェクトのメソッドの大半はオブジェクトの状態を取得または変化させる
(状態を参照しないならそのオブジェクトに持たせる必要はないわけで)

オブジェクトのメソッドのうち、一つの変数を変更するものがsetterで
一つの変数を取得するものがgetter・・・になってることが多いが別にそうする必要はない。

例えば内部変数が配列で要素の0番目を読み書きするsetter/getter
要素の1番目を読み書きするsetter/getterを作っても良い
もちろんsetter/getterではなくメソッドでやっても良い
どちらでも同じことができる。

言い換えると、システムを作るのに、メソッドだけでも実現できるし
プロパティ (setter/getter) だけでも実現できるということ

メソッドとプロパティ (setter/getter) の違いは
UMLのクラス図を書いたことがあればわかる。
UMLのクラス図には操作と属性の両方が存在するんだよ。
なぜか? それは人間の思考を反映させた結果だから
実装段階の思考ではなくて設計段階の思考ですでに操作と属性が別れてる。

メソッドとプロパティは本質的には同じものでコンピュータから
見れば同じものとして扱えるが、我々は人間なんだ。

人間がそれは操作、それは属性って分類して考えてるから、
それをコードに反映させられる記述能力の高さを求めた結果
メソッドとプロパティができたんだよ

しかたないね。人間だもの

273デフォルトの名無しさん2018/09/26(水) 23:05:14.04ID:xMAwDWlb
> メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> (以下ポエム略)

??
なぜそれを俺にレスしたのか不明

274デフォルトの名無しさん2018/09/26(水) 23:25:48.93ID:+un+mAjX
むしろおまえ以外の誰にレスしろというのか不明w

275デフォルトの名無しさん2018/09/27(木) 00:13:38.88ID:oacq4Bqj
だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな

276デフォルトの名無しさん2018/09/27(木) 00:30:43.91ID:Fk1HpByz
>>275
つまり、

× getter/setterが悪い
○ getter/setterの間違った使い方が悪い

277デフォルトの名無しさん2018/09/27(木) 00:35:00.12ID:pq96CSzd
刺身にタンポポのせてるヤツが
ちゃんとキリキリ働いてるか
その働きぶりをたまに覗きたいことはある

こっちからなにをするということはない

278デフォルトの名無しさん2018/09/27(木) 00:42:24.43ID:oacq4Bqj
>>276
確かに悪い使い方が都市伝説みたいに普及しすぎて、ろくろくまともな開発したことの
無い輩まで頓珍漢なオレオレオブジェクト指向論を吹聴するにいたったブームには参ったが、、

使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ

279デフォルトの名無しさん2018/09/27(木) 00:54:06.21ID:oacq4Bqj
>>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。

280デフォルトの名無しさん2018/09/27(木) 01:41:53.45ID:DSKWvsHE
いや、単純にオブジェクト指向なんてやったって地獄に落ちるだけ
クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ

単純にプログラムを

入力→処理→出力

という繰り返しの塊にしなければならない
メソッドを呼ぶたびに状態が変化
するようなもん誰も管理できない

281デフォルトの名無しさん2018/09/27(木) 01:45:45.45ID:oacq4Bqj
オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか

282デフォルトの名無しさん2018/09/27(木) 01:46:43.86ID:pq96CSzd
オブジェクト指向でも
詳細化したらデータフロー図に落とせる設計でないと
お話にならない

283デフォルトの名無しさん2018/09/27(木) 01:47:55.67ID:DSKWvsHE
状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か?

284デフォルトの名無しさん2018/09/27(木) 01:50:10.34ID:pq96CSzd
以前(>>161)にも書いたとおり
コレ以外方法はない

この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる

 @公開インタフェースは可能な限り少なくする
 A原則として、よほど適切な理由がないかぎり、可能な限り継承よりコンポジション使う
 B下位階層(ここでの階層は>>101>>106の意味)のクラスが上位階層のクラスのインターフェースに絶対に直接アクセスしてはいけない
  ※ 当然、下位クラスが上位クラスのインターフェースを直接呼びだすようなリフレクションは禁止
 C下位階層のインスタンスが非同期で上位のインスタンスに処理を依頼したい状況が発生した場合(可能な限りこんな状況が起きる設計は当然避けるべき)、
  処理のやりとりはメッセージキューで行い、可能な限り少ない回数で簡潔なメッセージを用いて簡単に完結できるようにする、複雑なメッセージシーケンスも禁止
  (コレは並立するインスタンス間でも同じ)
 D同じ階層に並立するインスタンスをムダに乱立させるのは当然禁止

コンポジションとメッセージシーケンス、クラスの階層(ここでの階層は>>101>>106の意味)、インスタンスの生存期間さえ
ドキュメントで適切におさえることができる状態になっていれば
問題やエンハンスが発生しても持続可能対応できる

285デフォルトの名無しさん2018/09/27(木) 01:52:11.89ID:DSKWvsHE
単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん

こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか?
というぐらい一切メリットがない

286デフォルトの名無しさん2018/09/27(木) 01:54:14.64ID:DSKWvsHE
>>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ

287デフォルトの名無しさん2018/09/27(木) 01:58:10.12ID:oacq4Bqj
もう今日は寝ろよハゲども
ノシ

288デフォルトの名無しさん2018/09/27(木) 02:02:11.90ID:oacq4Bqj
単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ

289デフォルトの名無しさん2018/09/27(木) 02:41:53.03ID:y/NaeiDF
割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする

290デフォルトの名無しさん2018/09/27(木) 02:47:01.34ID:Fk1HpByz
そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってことさ、AHAHAHAHA〜

291デフォルトの名無しさん2018/09/27(木) 03:51:07.23ID:fvjtmZUM
>>260
部分的に構造化プログラミング養成ギプスのような気がする

292デフォルトの名無しさん2018/09/27(木) 03:53:07.34ID:fvjtmZUM
メソッドを呼び出す順番に依存してはならない

293デフォルトの名無しさん2018/09/27(木) 07:40:33.24ID:zZL/tnLy
>>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。

内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。

294デフォルトの名無しさん2018/09/27(木) 08:19:49.02ID:emgF57xx
状態を持つなって言ってるのは関数型の考えから?
常にオブジェクト指向言語の方がメジャーなんだが

295デフォルトの名無しさん2018/09/27(木) 08:20:57.92ID:BciEc+9A
昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。

結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。

296デフォルトの名無しさん2018/09/27(木) 08:24:56.86ID:emgF57xx
グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと

297デフォルトの名無しさん2018/09/27(木) 09:26:17.13ID:DSKWvsHE
>>294
状態を持つと単純にテストがしにくい

あるクラスにprivateでドキュメントにも記述のないメンバ変数が10個あって
その内包するクラスにもメンバが10個あって・・・なんてプログラムだと
そのクラスの持つ状態は10*10*・・・
みたいに増えていく
完璧にプログラムを制御しようとすると
その全てを把握しなければならない
実際にはそれは不可能なのでオブジェクト指向的に組んだプログラムはそもそもバグっている

298デフォルトの名無しさん2018/09/27(木) 09:32:35.44ID:wRik+4En
>>295
あんたは使うべきの意味を理解してないよ
使うべきっていうのは今も一緒。

まずクラスのpublicフィールドを直接読み書きしたらいけないというルールがある。
そしてもう一つ、クラスのインターフェースを頻繁に変更してはいけないというルールがある

この2つのルールにより、publicフィールドを直接読み書きしていて、あとから読み書きに
何かしらの制限を書けたくなったときにgetter/setterに置き換えたらインターフェースが変わってしまう。
例えば obj.foo だったものを obj.getFoo() に書き換えないといけない
だから常にgetter/setterを使いましょうと言われていた

だけど今はプロパティを備えた言語ができた。
プロパティを備えた言語であれば、クラスのpublicフィールドというインターフェースを変えることなく
getter/setterにできるためあえて禁止する理由がなくなった
(obj.foo = 1 とかいて obj.foo に代入してるように見えて実は関数呼び出しになってる)

今はインターフェース(名前)を変えることなく、フィールドからgetter/setterに変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話

299デフォルトの名無しさん2018/09/27(木) 09:32:48.24ID:DSKWvsHE
んで思うのが
どうもアメリカらしくないなと
あれだけメリットとデメリットと数値化にこだわる国がなんでこんな丼勘定やねんと

オブジェクト指向なんて出回った頃にはもうすでに向こうではプログラミングは
無意味な公共事業の一環になっていたのではないか?
そしてそれにはもはや意味がなくて
できるだけ時間がかかる方法だけが採用されたと

300デフォルトの名無しさん2018/09/27(木) 09:34:56.57ID:wRik+4En
>>297
オブジェクトが状態を持つとテストがしにくいからといって
オブジェクトに状態を持たせなかったとしても、
状態を持ってるアプリケーションから状態を消し去ることは不可能なわけで
どこかに状態が存在するので、結局その部分のテストはしにくくなるよ
単にテストしにくい場所が変わるだけの話

301デフォルトの名無しさん2018/09/27(木) 09:35:52.22ID:wRik+4En
>>299
メリットとデメリットにこだわってるから
オブジェクト指向を使ってるのでは?

302デフォルトの名無しさん2018/09/27(木) 09:45:20.17ID:DSKWvsHE
>>300
まず、それが見えているかどうかが問題
引数から渡す形ならドキュメントに記述を強制できる
さらに同じ引数で実行したらなるべく同じ結果が返って来ることも保証できる
これで気をつけるのはファイルアクセスやDBアクセス、日時、通信などに限定できる
オブジェクト指向は全てのクラスが失敗作であると言える

303デフォルトの名無しさん2018/09/27(木) 09:59:43.55ID:wRik+4En
>>302
いや、どんな言語で作ろうが、
アドベンチャーのフラグ管理は大変だよ
関数型言語なんか、実装が不可能なレベル

304デフォルトの名無しさん2018/09/27(木) 10:51:21.68ID:zzHSqWZa
オブジェクト指向を捨てたGO言語を使おうってこと?

305デフォルトの名無しさん2018/09/27(木) 11:05:48.54ID:fvjtmZUM
実は倍精度浮動小数点数のインスタンス変数があったら2^64個の状態があるって話だ
もしくは10x10x10と10+10+10がほぼ一緒の値という主張だよ

306デフォルトの名無しさん2018/09/27(木) 11:44:32.68ID:emgF57xx
>>297
そんなことない

本格的なオブジェクト指向では
>>260みたいに小さなオブジェクト数にして
状態数も減らして単体テストしやすくする

むしろ関数型で複雑な状態遷移を実装するのは難しい
現にゲーム制作ではぜんぜん関数型が流行ってないからな

307デフォルトの名無しさん2018/09/27(木) 11:52:41.46ID:DSKWvsHE
>>306
理由が全くねーじゃん

308デフォルトの名無しさん2018/09/27(木) 12:15:48.09ID:zzHSqWZa
>>306
何年か前にOOPのそのトレーニングやったけど
今にして思えばおかしなことをしてたなって思う

素直にGO使ったほうがいいよ
今は制約を気にせず非常に楽にコードが書ける
それでいてOOPのころの糞コードからかなり離れている
GOのおかげ

309デフォルトの名無しさん2018/09/27(木) 12:17:39.22ID:zzHSqWZa
GOのtypeは非常に見通しがいい
c/c++のヘッダファイルはなんだったのかと

310デフォルトの名無しさん2018/09/27(木) 12:19:15.86ID:99b9Jx0M
状態を持たないオブジェクトwww
もはやオブジェクトちゃうやんw何の受け売りやそれw

311デフォルトの名無しさん2018/09/27(木) 12:24:21.66ID:nvNAA/EB
アクセスパターンを限定化する
これを理解出来ないなら
オブジェクト思考プログラミングはし無い方が良い
どういう訳か
凄まじい自信の有る人程解っていない
というのがこの界隈

312デフォルトの名無しさん2018/09/27(木) 12:31:34.84ID:zzHSqWZa
OOPで良いとされているが一番の間違いは
単機能の小さなクラスを沢山作ること

これはクラス数の爆発を産んでるので一番の害悪

例えば特定のファイルを読むためのクラス
そしてそのインターフェイスとDI用のクラスとテストケース
本当にこれが無駄

内部の状態に依存せず単機能でいいなら関数でつくればいいと気が付いた

313デフォルトの名無しさん2018/09/27(木) 12:37:21.63ID:emgF57xx
>>310
不変オブジェクトがあっても別にいい

>>312
>単機能の小さなクラスを沢山作ること
小さなクラスをたくさん作るからこそ変更しやすくなる

クラスの数を大きくして数を減らしてしまうと
作るときは一見楽に見えても後で変更コストが上がる

314デフォルトの名無しさん2018/09/27(木) 12:43:37.80ID:tnNln14X
>>313
それはOOP自体が悪いからそう見えるだけ
クラス数の爆発のほうが本当の害悪

上のトレーニングもクラスをちいさくする良い理由の一つとして
エディタの一画面にはいるから…

クラスが一ファイル内にないといけないその言語の制約だろう
パッケージ内に在ればいい言語に乗り換えよう

315デフォルトの名無しさん2018/09/27(木) 12:47:39.73ID:tnNln14X
クラスが小さいと困ることがある
インスタンス変数を2つに絞るのは愚か
確実にクラス設計が困難になる

変数をどこが持つべきかを設計しないといけない
そしてそれが間違っていた場合大規模な再設計とコーディングが必要になる

中程度のクラスにある程度必要とされる変数が入れておく方が開発工数は減る

316デフォルトの名無しさん2018/09/27(木) 12:49:58.82ID:tnNln14X
状態を持たない
そもそもが小さい
ならクラスじゃなくて関数を使え

317デフォルトの名無しさん2018/09/27(木) 12:53:47.09ID:99b9Jx0M
>>313
不変ゆうんは状態を持つから不変なんやぞw
受け売りでイキるのやめときw

318デフォルトの名無しさん2018/09/27(木) 12:55:53.67ID:tnNln14X
>>260
改めて書くけどこれはほとんどがもう古いし
本当の意味でOOPの弱点をカバーしてない

319デフォルトの名無しさん2018/09/27(木) 13:18:51.56ID:M9UbUXxK
TCP接続をOOPで書くとして、オブジェクトの外側でTCPの例の状態遷移を気にする必要あるんかいな

320デフォルトの名無しさん2018/09/27(木) 14:18:04.82ID:mMx24hKT
不変オブジェクト自体が一つの状態であることは確かだと思うが、語弊がありそうだな。
可換原則的には互換性のある小さなクラスをたくさん作る、が正しいだろうけど、
実際にそれすると、とんでもないバカが現れて瞬時に全壊するのも見たことあるし。
やっぱり一概には言えないと思うわ。

321デフォルトの名無しさん2018/09/27(木) 14:21:34.40ID:emgF57xx
>>316
関数でもいい場合はあるが
クラスにするメリットもある

>>317
それは難癖でしかない
再代入しないことによって
状態変化のデメリットが生じないので問題ない

322デフォルトの名無しさん2018/09/27(木) 15:03:29.89ID:DSKWvsHE
>>319
気にする必要が無いように組んでもいいし組まなくてもいい
でもテストは全状態に対して行わなくてはならない
現状はおそらくそれをやってる奴が少ないのがまずい
ここではさもやるのが当然とばかりに主張はするがそのテスト方法は提案すら挙げられない雑魚

323デフォルトの名無しさん2018/09/27(木) 15:09:59.98ID:wRik+4En
はっきりさせておかないといけないのは
オブジェクト指向と関数型で条件が違う比較をしてるってこと

つまり
「オブジェクト指向で状態を扱う必要がある問題」
VS
「関数型言語で状態を扱わない問題」
という違った問題で比較している


アプリケーションから状態をなくすのは不可能なので
「関数型言語で状態を扱う問題」を解かなければいけないのだが
なぜか状態はすべてなくすことができるんだという間違った前提で
状態がない優しい問題を解いているだけになってる

324デフォルトの名無しさん2018/09/27(木) 15:43:16.13ID:emgF57xx
>>323
これはそうだな

状態遷移が複雑なシステムをどう組めばいいか
関数型主義者から具体案を聞いたことがないね

325デフォルトの名無しさん2018/09/27(木) 17:55:02.31ID:34EufdvK
おれは関数型主義じゃじゃないけど適切にルール組んでその通りにやればいいだけじゃないか?

関数型はオブジェクト内に状態が隠蔽されてないから
やりやすいだけ

326デフォルトの名無しさん2018/09/27(木) 17:57:15.64ID:34EufdvK
Cだと構造体がなければほぼ全部シグネチャーに書きださなければならなかったけど
関数型は関数で組み合わせてあるから楽なんだろうなとは思う

327デフォルトの名無しさん2018/09/27(木) 18:00:53.71ID:34EufdvK
オブジェクト指向でもやりようによっては状態の遷移がわかりやすくはかける
fluxとかじゃ状態はイミュータブル
actionを適用したらその都度新しい状態オブジェクトを作ってストアしてる
古い状態は書き換えられずに破棄される

328デフォルトの名無しさん2018/09/27(木) 19:04:14.07ID:DZkTxoQs
状態が複雑になる場合もなるべく明示した方が嬉しいよねってのが関数型のスタンス
Haskellは状態を持つ部分をモナド型クラスのインスタンス(=型)にするし、ML系は非数値状態を型に持たせて型検査の形で明示する

個人的には基本関数型で組んで、状態が必要不可欠な問題に対しては意味論的に隠蔽されているのが正しいならprivateでそれ以外はミュータビリティと型で制御が妥当かなと
その後でパフォーマンスが必要ならその部分をミュータブルなクラスベースOOPにする

329デフォルトの名無しさん2018/09/27(木) 22:11:06.04ID:y/NaeiDF
>>324
まあ冒頭副作用的な臭いからひっぺがしのモナドが思いつくなこれは

330デフォルトの名無しさん2018/09/27(木) 22:52:16.03ID:ojLVUDGL
オブジェクト指向ってウェブサイトの構築以外でどうやって使うんだ?
phpとかrubyはわかるがjava、c#やらでどういうシステム作れるか教えて

331デフォルトの名無しさん2018/09/27(木) 22:55:44.14ID:pq96CSzd
poco使ってc++でwebサーバーの振る舞い自体を組み込みで書く

332デフォルトの名無しさん2018/09/27(木) 23:41:51.25ID:emgF57xx
>>330
>オブジェクト指向ってウェブサイトの構築以外でどうやって使う
一般的なアプリケーション作成全般
よほど高速な実行速度が要求されるもの以外

333デフォルトの名無しさん2018/09/28(金) 00:59:07.19ID:2dxGIytS
そもそもストラウプトのC++がまずかったんだよ

334デフォルトの名無しさん2018/09/28(金) 01:09:58.28ID:2dxGIytS
>>324
functionalは状態の管理手法じゃないのになに言ってんだ。
functionalは構造の再帰的分割による細分化やリスト処理の宣言的記述に有効であって
状態は必要なければなるたけ持たないほうが良いのはいろはのイ、セオリーだぞ
そして状態遷移は本当に必要ならオブジェクト指向を流用するのではなく
状態をきちんと管理するんだよ。
それをgetter/setterで要らぬところに状態持ち込んでishaだのhasaだの言ってるから
子供にまで後ろ指差されて笑われるんだよ。
言っとくが別にオレはfunctionalマンセーじゃないぜ。

335デフォルトの名無しさん2018/09/28(金) 02:01:07.68ID:HosvZzhg
オブジェクト指向はWebよりjavaとかc#のイメージのが強いな
Webのがメジャーな人もいるのか

336デフォルトの名無しさん2018/09/28(金) 02:06:06.17ID:EiOshXgh
>>334
何言ってんの……?

>状態は必要なければなるたけ持たないほうが良い
あのね、ビジネスソフトには状態が必要なの!!

いくら関数型が状態を排除するのが理想だからって
ビジネスを道具の方に合わせることはできない

そんなことも分からないんだから嫌になる
これじゃいつまでたっても関数型が普及しないよな

>状態をきちんと管理する
だからその具体案を聞いたことがないんだって

本当馬鹿じゃないかと思う

337デフォルトの名無しさん2018/09/28(金) 05:08:03.15ID:FhArznfq
>>335
Spring, ASP.NET Core

338デフォルトの名無しさん2018/09/28(金) 08:02:53.14ID:pE+2cSJR
>>336
>何言ってんの……?

何言ってるか理解にすら至ってないようだな…

339デフォルトの名無しさん2018/09/28(金) 08:05:29.06ID:8utkG/Cm
システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がおると聞いて

340デフォルトの名無しさん2018/09/28(金) 10:00:32.06ID:bPXaydqo
>>338
その「何言ってんの?」は

何を言ってるかわからないという意味じゃなくて
お前は何(馬鹿なこと)を言ってるの?って意味だろ

日本語の時点で

341デフォルトの名無しさん2018/09/28(金) 12:17:05.53ID:pLiz6ELv
オブジェクト内部に状態は持たないほうがいいと言うのは当たり前すぐる気がするけどね

342デフォルトの名無しさん2018/09/28(金) 12:54:45.76ID:bPXaydqo
>>341

そこは「オブジェクト外部に状態を持ったほうが良い」と言わなきゃだめ
状態をなくせるわけじゃないんだから

343デフォルトの名無しさん2018/09/28(金) 13:12:28.51ID:GxtNhjDw
オブジェクト外部に状態持っても、結局そのオブジェクトを包含している上位のオブジェクトがあるので、行き着くところは「アプリケーションオブジェクトの外部に状態を持ったほうが良い」ってならない?
どこでラインを引くかはセンスってことでOK?

344デフォルトの名無しさん2018/09/28(金) 13:19:48.03ID:1UhvtMTy
他のオブジェクトの持つ変数を必要とする事自体がおかしい。
必要な引数を渡したら、処理を任せて、必要な値をリターンさえしてもらえればよい。

345デフォルトの名無しさん2018/09/28(金) 13:32:05.28ID:bPXaydqo
>>343
そのアプリケーションオブジェクトの外部ってのが
なんのことかわからない。

ファイルに保存のことなのかもしれないが、保存するまでは
総てのデータはアプリケーション内部にあるわけで
結局、仮想的なストレージ(ようするにメモリ)に
保存するしか無いでしょう?

346デフォルトの名無しさん2018/09/28(金) 15:21:40.87ID:GxtNhjDw
>>345
そうだよ、俺もそう思うのでアプリの外に状態はあり得ないだろうと。
なのでどこかで線引きをしないといけないんだけど、結局それはセンスという便利かつ曖昧なな言葉で片付けられちゃいそう。

347デフォルトの名無しさん2018/09/28(金) 18:23:35.77ID:KV7CiVPs
>>343
ん?それでテストできるならやれば?
実際は制御不能でしょ?
だから駄目だって言ってんの

348デフォルトの名無しさん2018/09/28(金) 18:37:56.35ID:++iDCvgk
>>347
んんん?
じゃ、具体的にアプリケーションオブジェクト以下に状態を一切持たなくてどうやって実装するのん?
BrowserでもOfficeでもいいから、一般的なアプリでアプリケーションオブジェクト外部に通信中にファイルオープン済みか否かやなんやらかんやら全ての状態を無理せず実装するエレガントな方法教えて。
一切の状態をアプリに持ってたら駄目だよ。
いくらなんでもこれは反論する自信あるわ。

349デフォルトの名無しさん2018/09/28(金) 18:41:30.51ID:++iDCvgk
>>347
分かってると思うけど、今どの画面が表示されてるとか項目の何が選択されてるかも全て状態だからね。
さぁ、エレガントな説明してみて。

350デフォルトの名無しさん2018/09/28(金) 18:57:00.64ID:/ke/2lv3
いつまでずれた馬鹿な話してんの?

例えば犬クラスがあってポチオブジェクトがあった
そいつに餌を毎日おなじ餌をあげてたけど(戻り値 完食)
ある日半分しか食べなかった(戻り値 半分)
後でわかったけどポチは病気だった
かわいそうなポチ

犬クラス内部に状態があって同じメソッドを使ってても動作変わってるのが厄介だと言ってるんだろ
それがわからないのかなあ?

351デフォルトの名無しさん2018/09/28(金) 19:01:55.81ID:/ke/2lv3
ポチはたまたま病気だとわかったけど
わからなかったら何で半分しか食べないのかわからない

事前に誰かが餌をやったのかもしれない
失恋でショックだったのかもしれない
気分がたまたまそうじゃなかったとしたら解剖しても理由はわからない

未来のテクノロジーでその時の内部状態を再現した無数のポチを作って条件に分けて
えさやり動作チェックするなんて考えただけでも寒気がする

352デフォルトの名無しさん2018/09/28(金) 19:02:47.77ID:1UhvtMTy
それはポリモーフィズムを理解してないだけでは。

353デフォルトの名無しさん2018/09/28(金) 19:03:10.43ID:++iDCvgk
>>350
厄介だけど、どこかのレイヤで病気か否の状態は必要だろ?
それがアプリケーションレイヤよりさらに上なんてのはあり得ない。

354デフォルトの名無しさん2018/09/28(金) 19:08:25.24ID:++iDCvgk
ポリモーフィズムは参照先インスタンスに依存するので、それは間接的とはいえ状態そのものやね。

355デフォルトの名無しさん2018/09/28(金) 19:11:12.35ID:/ke/2lv3
>>353
だから対象オブジェクト内部に値を持たせないで関数のシグネチャーにして渡せと

関数に
病気かどうか
失恋かどうか
気分が悪いかどうか
前食べてからどのぐらい時間がたったか
と餌の量を値として渡せと

356デフォルトの名無しさん2018/09/28(金) 19:13:30.49ID:++iDCvgk
>>355
そのシグニチャを渡すのは誰?
全ての状態を人間であるユーザーが渡すのん?

357デフォルトの名無しさん2018/09/28(金) 19:18:47.60ID:/ke/2lv3
>>356
関数を使うものが渡す
その関数は勝手に知らない場所にある値を使わない
同じ値の組を与えたら必ず同じ値を返す

358デフォルトの名無しさん2018/09/28(金) 19:19:57.74ID:UT33gEiF
>>348
え?誰がそんなこと言ったの?
内部に持ってアクセスできないのが駄目だって何度も言ってるじゃん
関数実行したら出力全部出せよ
同じ引数で実行したら絶対同じ結果を返せ

359デフォルトの名無しさん2018/09/28(金) 19:22:08.98ID:++iDCvgk
>>357
関数を使う、突き詰めればOfficeのユーザーがどの設定画面のどのタブでどのチェックボックスが有効でどのボタンを押したかを一度に伝えるのん?
俺はそんなことはしてないなぁ。
少なくともどの画面が表示されてて何が選択されてるかはアプリの状態に依存してるわ。

360デフォルトの名無しさん2018/09/28(金) 19:23:07.62ID:TedNHSTO
犬に餌をやらなくても満腹にできる魔法

361デフォルトの名無しさん2018/09/28(金) 19:24:11.70ID:/ke/2lv3
何でモデルとアプリの状態の話を混同してるかがわからない

362デフォルトの名無しさん2018/09/28(金) 19:25:06.97ID:++iDCvgk
>>358
OKボタン押したら絶対に同じ結果になるのん??
仮に条件によりOKボタンが押せないなら、それはOKボタンを押せない条件がアプリにあるってことになる。

363デフォルトの名無しさん2018/09/28(金) 19:32:21.07ID:++iDCvgk
>>362
普通は分かるけどへんに誤解があるかもなので訂正。
誤 OKボタンを押せない条件
正 OKボタンを押せない状態

364デフォルトの名無しさん2018/09/28(金) 19:36:02.78ID:UT33gEiF
>>362
引数は同じなの?
お前さっきから人の話聞いてるのか?

365デフォルトの名無しさん2018/09/28(金) 19:37:20.39ID:UT33gEiF
>>362
そもそもお前のアプリって
同じ画像保存してもクリックするたび画像変わるんだろ?
さっさとクビ吊れよ

366デフォルトの名無しさん2018/09/28(金) 19:38:21.84ID:++iDCvgk
俺がはなっから言ってるのは、アプリ以下のどこかに状態は必要なはずで、それよりも外に状態を追い出すのは無理があるってことだけ。

367デフォルトの名無しさん2018/09/28(金) 19:39:58.48ID:++iDCvgk
>>365
お前のアプリは画像選択もしてないのに突然エロ画像表示するのかw
児ポで捕まっとけw

368デフォルトの名無しさん2018/09/28(金) 19:44:25.53ID:+9bdVI5n
システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がハッスルしちゃっとると聞いてw

369デフォルトの名無しさん2018/09/28(金) 19:45:26.35ID:/X9jOxDh
>>323-324
それな
関数型言語っつうのも所詮そんなもん

370デフォルトの名無しさん2018/09/28(金) 19:47:14.39ID:++iDCvgk
システム、つまりアプリの状態は少なくともアプリケーションオブジェクト以下が制御してるので、全てのオブジェクトが状態を管理しないってのは無理があるって話。
最初からそう言ってる。

371デフォルトの名無しさん2018/09/28(金) 19:50:57.15ID:lTwZu9zK
つか関数型餌やりだと餌やり関数から出力される犬は入力された犬のクローンじゃないのか?

372デフォルトの名無しさん2018/09/28(金) 20:15:03.29ID:UT33gEiF
>>366
理由は?
outputでstatusも出しゃいいじゃん
ハイ、論破

373デフォルトの名無しさん2018/09/28(金) 20:18:19.44ID:+9bdVI5n
>>371にどう答えるかでバカのレベルが計れるw
いまのとこ華麗にスルーした>>372がキングやねw

374デフォルトの名無しさん2018/09/28(金) 20:20:36.12ID:++iDCvgk
>>372
具体的にどんな大多数のアプリがそう実装してるの?
悪魔の証明を避けるにはお前に実証責任があるからね。

375デフォルトの名無しさん2018/09/28(金) 20:21:59.66ID:+9bdVI5n
>>374
今はおまえがしゃべっていい時間やないで

376デフォルトの名無しさん2018/09/28(金) 20:23:45.55ID:++iDCvgk
>>375
あ、すんません。
誰が喋っていい時間なのかよく分からないけど黙っときます。

377デフォルトの名無しさん2018/09/28(金) 20:25:39.72ID:+9bdVI5n
>>376
うむ、おまえは既に名誉バカの称号を持っとるからここに参戦すべきやない
すこしおとなしくしとけ

378デフォルトの名無しさん2018/09/28(金) 20:26:26.12ID:++iDCvgk
>>377
あい、すんません。

379デフォルトの名無しさん2018/09/28(金) 20:28:27.44ID:UT33gEiF
>>374
c言語でグローバル変数使わなかったら他どんな組み方があるの?
引数か戻り値で渡すしかないでしょ?
グローバル変数使用禁止が作法のように語られてたんだから
昔の人は何をするべきかわかってたんだよ

380デフォルトの名無しさん2018/09/28(金) 20:56:14.71ID:/X9jOxDh
OOPは糞かもしれんが
じゃあ何がいいのかと言われたら別に他にこれといってないのが現状

381デフォルトの名無しさん2018/09/28(金) 21:12:44.75ID:k5h2WtG4
頭悪いヤツにかぎって
うれしがってなんでも継承して抽象化とかいってるからな

ホモを人間クラスから派生するぐらい愚かなことやってる

382デフォルトの名無しさん2018/09/28(金) 21:16:43.74ID:l603LAAk
基本は当たり前すぎて、階層化であり局所化であり
順序回的な「無用な」状態保持は極力回避し組みあわせ回路的・関数的構造にし、、、、
関連はネットワーク構造よりもツリー構造を指向して見通しよくし、
関連性の強い物は近くにおき(遠くのファイルからあちこち継承してクロスファイルでmethod取り込むようなことはせず)、
といった、、、アー効けく茶後期ツのための基本セオリー。
その表現技法は言語のパラダイムによって変わるだろう。

問題はオブジェクト指向がそういった基本セオリーに反するような手法として普及してしまったことだよ。

383デフォルトの名無しさん2018/09/28(金) 21:17:57.02ID:l603LAAk
>>382 ひでえ誤字すまん
×「アー効けく茶後期ツ」
○「アーキテクチャー構築」

384デフォルトの名無しさん2018/09/28(金) 21:23:02.60ID:/X9jOxDh
なんでコイツ急にポエりだしたん?

385デフォルトの名無しさん2018/09/28(金) 21:25:30.29ID:k5h2WtG4
オレぐらいのレベルでないと
オブジェクト指向は使いこなせない

386デフォルトの名無しさん2018/09/28(金) 21:27:24.36ID:l603LAAk
たとえば関数型であれば、クロージャーや部分適用を使うことにより、
クラスをイロイロ作ったり状態instance変数でオブジェクトに特徴をもたせ分けるより
非常にシンプルに表現できるし、
また、解法を関数の段階的 細分化で構成することにより、
内側の回関数は小さくなるにつれ速やかに単純な構造になる上、
(再帰も含めた)関数呼び出しの引数リストと帰り値のスタック階層および局所変数が、
自然と個々の階層の参照する「近くにあるべき」状態を単純な木構増階層のかたちで保持できる。

ちなみに上にも書いたけど俺はfunctinalマンセーじゃないからな。

387デフォルトの名無しさん2018/09/28(金) 21:29:55.72ID:l603LAAk
>>385
俺の周りでは、素人に毛がはえたか分からんような又派遣さんが、
専門学校でインチキ教わったのか知らないが、
そういう薀蓄をたれながら、くそコード量産して要らぬバグ入れて
残業大会やってるよ

388デフォルトの名無しさん2018/09/28(金) 21:33:34.54ID:k5h2WtG4
あえていえば
できるだけ自律的であることが適切で
なおかつそのようにほぼ自律的に振舞うように実装されていれば
内部状態が保持されることは実装として適切

ただし、すべて外部的な要因で翻弄される続けるオブジェクトが内部状態を保持することは
適切な理由がないかぎり、できるだけ避けるべきといっていい

389デフォルトの名無しさん2018/09/28(金) 21:35:43.41ID:l603LAAk
問題によってどうしても必要な内部状態というものはあるからな。
そこまでだれも否定はしてない

390デフォルトの名無しさん2018/09/28(金) 21:36:39.96ID:k5h2WtG4
刺身の上にタンポポ乗せる作業なんか
ほっといってもいい

そのクラスだけでほぼ完結できる

391デフォルトの名無しさん2018/09/28(金) 21:37:59.71ID:/X9jOxDh
> 外部的な要因で翻弄される続けるオブジェクトが内部状態を保持する

まぁアンタの言うように避けたようがよさげにも見えるが
ここでふと思い出されるのはコンテクストとかビルダの働き

java.awt.Graphicsみたいなコンテクストオブジェクトをグニグニいじったり
java.lang.StringBuilderのようなビルだオブジェクトをグニグニいじったり
そういうところこそにOOPの楽しみがあるように俺には少し思えるんだ

392デフォルトの名無しさん2018/09/28(金) 22:12:55.17ID:bBdkrZUa
ボタンやチェックボックスがGUIの共通の振る舞いを制御する親クラスがいるのはC++で書かれる前から実装継承するように設計されていた。

一方、普通預金、当座預金、定期預金の共通関数があったとして、預金というスーパークラスを書いているシステムはないぞ。メガバンクの情報系であってもな。

393デフォルトの名無しさん2018/09/28(金) 22:24:55.23ID:+9bdVI5n
お、キングを抜いた奴がでたでw
今は>>389がバカキングなw

394デフォルトの名無しさん2018/09/28(金) 22:51:26.95ID:HosvZzhg
>>259
OOコード養成ギブス
http://d.hatena.ne.jp/akkt/20080424/1209051266

置いとくぞ忘れてはならない戒め

395デフォルトの名無しさん2018/09/28(金) 23:17:45.51ID:EiOshXgh

396デフォルトの名無しさん2018/09/28(金) 23:49:37.69ID:/ke/2lv3
普通はそれってオブジェクト指向エクササイズっていうんだけど
同じ表現だから同じひとなんじゃないかな

397デフォルトの名無しさん2018/09/29(土) 01:23:56.63ID:NuLdKSCl
そいやオブジェクト指向てデザパタとかメジャーなのに肝心のこっちは影が薄いな

398デフォルトの名無しさん2018/09/29(土) 01:57:58.03ID:MMtb4Amd
プロパティとはなんと罪深い発明か

399デフォルトの名無しさん2018/09/29(土) 02:12:47.80ID:IuTgmxg/
バカでも作れる処理は
入力の構造体と出力の構造体を関数に渡す程度で済む処理

400デフォルトの名無しさん2018/09/29(土) 09:11:35.70ID:nymKFaQh
>>398
IDEと組み合わせるには相性がよかったのかもね
あと典型的なGUIのパーツであるとか
インスペクトしたときズラズラっと出るのが気持ち良いような物に対しては

401デフォルトの名無しさん2018/09/30(日) 01:13:02.43ID:2u8tHsEV
age

402デフォルトの名無しさん2018/10/02(火) 00:59:29.31ID:clFFurIb

403デフォルトの名無しさん2018/10/02(火) 01:05:20.08ID:A7JQSPUH
考察が浅い

404デフォルトの名無しさん2018/10/02(火) 01:13:19.56ID:HjCi0xKJ
長すぎるから産業

405デフォルトの名無しさん2018/10/02(火) 07:20:53.80ID:JB7ad13/
>>403
確かに浅いな
オブジェクト指向のメリットは全くわからなかった
解説してる内容もそもそもクラスを使う側が構造を知ってないと使えない例で書かれてて笑う

406デフォルトの名無しさん2018/10/02(火) 07:35:05.76ID:ju0/OZW1
キータって参考になる記事あんまりないんだよな。ある程度の知識もっているのが前提になってるし
プログラミング関連で検索すると常に上位でヒットするのが嫌だわ

407デフォルトの名無しさん2018/10/02(火) 09:44:25.77ID:3qG7W8x7
>>402
こういう嘘歴史書いて悦に入っちゃう自称識者のほうがゴリラみたいな底辺コンサルよりずっと始末が悪い

408デフォルトの名無しさん2018/10/02(火) 10:15:48.80ID:ti/Lih16
見た目が? 何がゴリラなん?

409デフォルトの名無しさん2018/10/02(火) 10:49:30.13ID:6qOrAQgQ
力だろ?

410デフォルトの名無しさん2018/10/02(火) 12:34:43.67ID:AvMzrL7k
ゴリラコンサルの所業

朝礼で歌を歌わせる、挨拶の練習
○○(会社の名前)イズムの継承と言ってブラック労働を肯定する
定期的に変なセミナーに通わされる

411デフォルトの名無しさん2018/10/02(火) 15:30:45.55ID:/tnW96SL
知能がゴリラ

412デフォルトの名無しさん2018/10/02(火) 18:20:49.67ID:/RdnJML/
qiita.comは動機が不明
なぜ頼まれもしないのに不確かな二次情報を書き散らすのか
なぜ頼まれもしないのにノイズをせっせとネットに増やすのか
あれってお金でももらって記事を書いてるのか?

stackoverflow.comは単純
質問者がいて、答えてあげたい人が要る
質問にも回答にも評価がされるようになっており
有益な情報が共有できるようにつくられてる
質問者、回答者、閲覧者の動機がよくわかる

413デフォルトの名無しさん2018/10/02(火) 18:28:36.78ID:6qOrAQgQ
評価ならqiitaでもされるだろ

414デフォルトの名無しさん2018/10/02(火) 19:04:58.66ID:TcNkDYl8
stackoverflow で答えてあげたい人と大差ないだろ

415デフォルトの名無しさん2018/10/02(火) 19:39:52.33ID:YrRJAaFS
承認欲求なのです・・・

416デフォルトの名無しさん2018/10/02(火) 19:50:57.77ID:eaArETqj
教えたがりのクズのくせに答えたあげたいとか言っちゃう気持ち悪さw

417デフォルトの名無しさん2018/10/02(火) 19:56:41.61ID:YaWzkSZx
>>412
書いたことあるけど、昔はもうちょっと面白い場だった。
こんなの面白かったよ、とか試してみた、とか。
今は何かというとポエムやら言う奴が出てきたり、本気でレベル低い人も何番煎じかわからん記事書いたりして、収拾ついてない。
コミュニティとしては死んでいってると思う。

418デフォルトの名無しさん2018/10/02(火) 19:59:28.60ID:Weccy6g3
>>412は便所の落書きのアホさ加減が光る書き込み

419デフォルトの名無しさん2018/10/02(火) 20:06:51.71ID:eaArETqj
昔は良かったボクちゃんw

420デフォルトの名無しさん2018/10/02(火) 20:24:30.19ID:JlZ/oy05
qiitaはメモ帳として結構便利
家で調べて纏めて仕事ですぐ使えるようにする
githubにテンプレートを置いとくと尚良

421デフォルトの名無しさん2018/10/02(火) 20:28:55.64ID:6qOrAQgQ
gistつかえよ

422デフォルトの名無しさん2018/10/02(火) 20:30:00.28ID:clFFurIb
俺は結構便利だと思ってるけどな
新しいことのとっかかりにしたり
頭の中にない情報を得るのに使ってるわ

まあゴミ記事も多いけど

423デフォルトの名無しさん2018/10/02(火) 20:35:43.11ID:YrRJAaFS
技術的な事読みたいのにポエムばかり上位にくるqiita

424デフォルトの名無しさん2018/10/02(火) 20:38:05.56ID:eaArETqj
そもそもなんでqiita検索しとんねんwアホやろw

425デフォルトの名無しさん2018/10/02(火) 20:43:51.32ID:YrRJAaFS
ほんの少しだけいい記事もある。

今オブジェクト指向に関するポエムが乱立してるのはアホみたいだがな。

426デフォルトの名無しさん2018/10/02(火) 21:14:37.02ID:R8M7QKDK
qiitaみたいなしょうもない個人の日記帳読んでるヤツいるの

427デフォルトの名無しさん2018/10/02(火) 21:27:51.22ID:WxkRXB6W
個人の日記帳として読んでる

428デフォルトの名無しさん2018/10/02(火) 22:21:33.48ID:HWestuUb
5chみたいな便所落書き読んでる奴いるの?

429デフォルトの名無しさん2018/10/02(火) 22:35:01.96ID:/RdnJML/
便所の落書きはむしろ健全なんだよ
書くほうも読むほうももうそれは分かってるから

>>417
> 何番煎じかわからん記事

ほんとそれ
検索結果を汚すのはもうやめて…
つべの歌ってみたレベルで悲しい

430デフォルトの名無しさん2018/10/02(火) 22:35:39.44ID:BVvmn2A/
そんなことは自己紹介板に書きなよ

431デフォルトの名無しさん2018/10/02(火) 22:37:06.75ID:BVvmn2A/
>>430>>428

432デフォルトの名無しさん2018/10/02(火) 22:49:52.65ID:m0qWbxoK
何か上から目線だけどどこのサイトでもいいから
自分で正しいこと書けばいいんじゃないの?

それで次に言うのは
「ゴミポエムだらけでオレの記事が正しく評価されない」

433デフォルトの名無しさん2018/10/02(火) 22:55:41.37ID:YrRJAaFS
ゴミポエムだらけでオレの記事が正しく評価されない

434デフォルトの名無しさん2018/10/02(火) 23:00:45.18ID:1/02bXao
>>432
結果として自分のブログに戻ったよ、俺は。
まあゴミに埋もれる程度ならその程度の評価だと思うし。

435デフォルトの名無しさん2018/10/02(火) 23:02:07.94ID:/RdnJML/
> 自分で正しいこと書けばいいんじゃないの?

何で分かってくれないの…
自分で正しいと思ったことを「書かないで」と言ってる

歌ってみた?歌わんでいい
書いてみた?書かんでいい

436デフォルトの名無しさん2018/10/02(火) 23:07:36.42ID:YrRJAaFS
>>435
有益な情報はどこで仕入れてるの

437デフォルトの名無しさん2018/10/02(火) 23:26:49.40ID:R8M7QKDK
オレのレスは有益

438デフォルトの名無しさん2018/10/02(火) 23:29:31.38ID:LVKvBfXE
全てを分かってるやつが嘘っぱちを自信満々で流すのが厄介

439デフォルトの名無しさん2018/10/02(火) 23:34:15.18ID:YrRJAaFS
そこはわかってない奴じゃないのか?

440デフォルトの名無しさん2018/10/02(火) 23:59:13.66ID:LVKvBfXE
>>439
ワザと嘘を流す奴がいる

441デフォルトの名無しさん2018/10/03(水) 00:49:14.98ID:p3pJJViF
そんな奴は他の奴に指摘されて恥をかくのさ。

442デフォルトの名無しさん2018/10/03(水) 00:59:18.00ID:75/JdiDV
オブジェクト指向とは何で
何が良くて
何が悪くて
そしてどうしたらよかったのかとか
纏められるといいんだけれどもねえ

443デフォルトの名無しさん2018/10/03(水) 01:01:35.24ID:75/JdiDV
目的指向というよりも
手段指向というか方法論指向で始終しちゃって
明後日の方向に愚民を導いて
混乱をもたらしたのは
なんともむなしい

444デフォルトの名無しさん2018/10/03(水) 01:03:16.82ID:75/JdiDV
日本の失われた20年とちょうど時期が重なる
日本のITの暗黒時代

445デフォルトの名無しさん2018/10/03(水) 01:03:23.91ID:Uljc2mte
>>441
手強いよ
さらに誰に金もらってるのか
特定の言語や商品の悪評を流すことを目的としてるから

446デフォルトの名無しさん2018/10/03(水) 04:50:56.65ID:gboWSeYU
260はいい記事やったけど402はイマイチやったな。てか全部読んでないけど

447デフォルトの名無しさん2018/10/03(水) 10:56:50.79ID:gykQQ827
邪魔する奴の中に
単純に自分を有利にしておきたいから他人が自分の居るレベルまでこれ無い様に邪魔をする
という奴も居るからな
相対的な位置で報酬は決まるから他人を蹴落とす
というのを息をするようにやる奴がかなり居る
全体が進展するより停滞させて自分だけ有利にしようとする下劣な奴が結構居る
教育を変える必要が有るのに今のままでいい
とか言ってる奴もそういう連中

448デフォルトの名無しさん2018/10/03(水) 17:15:26.13ID:bSsx2t9M
>>412
stackoverflow.comって初めて知ったわ。
teratailよりいい?

449デフォルトの名無しさん2018/10/03(水) 17:55:44.54ID:H+WLzHql
>>448
teratailなんて比較対象にすらならない

450デフォルトの名無しさん2018/10/03(水) 19:12:16.15ID:p3pJJViF
stackoverflow人少なすぎない?

451デフォルトの名無しさん2018/10/03(水) 19:23:56.48ID:ksSGRyva
まさか日本語版とかいうゴミ見てるんじゃないだろうな…まさかな…

452デフォルトの名無しさん2018/10/03(水) 19:32:35.85ID:p3pJJViF
紹介されたから見に行ったら日本語版だったの

453デフォルトの名無しさん2018/10/03(水) 19:42:27.24ID:bSsx2t9M
英語版なんて読めないよ・・・
コードはなんとなくわかるが質問文が

454デフォルトの名無しさん2018/10/03(水) 20:03:14.53ID:OyXOgA+h
>>444
その時期に書かれたコードでOOPを正しく実践してるものなんて見たこと無い
OOPが悪いのではなくOOPじゃなかったから悪いということになるな

455デフォルトの名無しさん2018/10/03(水) 20:24:40.36ID:p3pJJViF
英語版いいな。情報量が圧倒的に多い。センキュー

456デフォルトの名無しさん2018/10/03(水) 20:50:59.00ID:L7SsoV0I
海外でHelp me, Stackoverflow. You’re my only hope.って書かれたTシャツ着たやつ見るくらい

457デフォルトの名無しさん2018/10/03(水) 22:09:14.84ID:2Mgu08sP
>>454
今なら正しくOOPを実践してるコードばかりなの?
そもそも正しいOOPってどんなものなの?
第一デザパタは前の方がさかんに取りざたされていたじゃない。

振り返って今だからこそ分かるんじゃじゃないの?
世に流布していたOOPはくそコードを量産した元になったと。

458デフォルトの名無しさん2018/10/03(水) 23:08:05.48ID:G0/tEBDY
我々はね、間違うのよ
だいたいのことを間違うの

OOPだから糞コードになったんじゃなくて
OOP関係なく、糞コードにしかならないの
その一点についてすら自覚が無いの

459デフォルトの名無しさん2018/10/03(水) 23:16:15.49ID:p3pJJViF
main関数から始まるc++はオブジェクト指向か?
(オブジェクト指向をちっとも理解してないものの意見です)

460デフォルトの名無しさん2018/10/03(水) 23:39:24.91ID:YTuGf5mm
>>459
C++はオブジェクト指向(をサポートした)言語だよ
Cと違って継承や多態の機能が標準であるでしょ?
今からふり返ると中途半端な部分もあるけど

ただそのC++を使って書いたコードが
オブジェクト指向らしく書けているかは別の話
OOPとOOA(D)の違い

461デフォルトの名無しさん2018/10/04(木) 00:22:43.55ID:e2lTbi2R
>>458
OOPの弊害について議論して来たのに
「OOP関係なく、糞コードにしかならない」と言われると、
OOPは糞コードの元となる害なかった無関係だと暗にほのめかしているようで
論点をすり替えてずるくごまかされたような印象を受けるよ

462デフォルトの名無しさん2018/10/04(木) 00:28:26.90ID:bhAz8In7
OOPが原因で糞コードになるんなら
どうすればいいか一目瞭然じゃん
よかったな世界が平和になって

463デフォルトの名無しさん2018/10/04(木) 00:32:28.79ID:e2lTbi2R
本当はいいものとなる筈だったのに、
ボタンを掛け違えたのか、変な使い方が一人歩きして普及しちゃったというか
なんというか、、、

最近は継承を廃止したり
他のパラダイムも併せた言語がどんどん出てきて
より良い解はいっぱい出て来るでしょう

464デフォルトの名無しさん2018/10/04(木) 00:44:45.46ID:s35zoLCp
継承の時にc++のprotectedは有害か?

465デフォルトの名無しさん2018/10/04(木) 00:53:04.18ID:e2lTbi2R
んなもん使い方しだいにきまっとろうが
基本的に依存が込み入る元なので
十分静的に設計し尽くしてよほど律して使用するならともかく
変なテクニックを披露するため乱用したら害だろうな
悲惨だわ

466デフォルトの名無しさん2018/10/04(木) 19:08:28.34ID:bhAz8In7
典型的なフワフワ野郎やなこいつ

467デフォルトの名無しさん2018/10/04(木) 21:04:04.79ID:lUzJxSj8
関数型の弊害の話をしたら必然的にオブジェクト指向の弊害の話になると思うの

468デフォルトの名無しさん2018/10/04(木) 21:07:13.85ID:vhCji18k
弊害ちゃう元からおまえの頭が悪いだけや

469デフォルトの名無しさん2018/10/05(金) 01:42:06.04ID:GLbBoG3S
これがオブジェクト指向を吹聴していた者たちの反論か…
科学的工学的有効性のかけらも無い

470デフォルトの名無しさん2018/10/05(金) 06:56:18.75ID:u1B1EyaQ
>>469
アアン!?
何ガン飛ばしてんじゃコラァ!

みたいなやり取りばっかだよねw

471デフォルトの名無しさん2018/10/05(金) 08:22:51.05ID:jK12bSnX
>>464
c++自体有害

472デフォルトの名無しさん2018/10/05(金) 10:34:10.65ID:kQel6lTj
>>467
オブジェクト指向と関数型に何の関係があるんだ?

473デフォルトの名無しさん2018/10/05(金) 10:55:46.34ID:4oQp/Mop
>>472
プログラミングパラダイムという同じ上位概念を持つ
関係があるやろ

474デフォルトの名無しさん2018/10/05(金) 10:58:14.90ID:kQel6lTj
>>473
その理屈だと、むしろ無関係なもの探す方が難しいなw

475デフォルトの名無しさん2018/10/05(金) 11:10:54.95ID:HilDODP3
クソとか言っている人間の方がよっぽど
>科学的工学的有効性のかけらも無い
と思うけど

476デフォルトの名無しさん2018/10/05(金) 12:04:19.49ID:4oQp/Mop
>>474
なに言うてんねん、必死やな

477デフォルトの名無しさん2018/10/05(金) 14:35:10.66ID:kQel6lTj
べつにオブジェクト指向の概念は関数で実装しなくてもいいんだよ?
メッセージでもいいしな。

478デフォルトの名無しさん2018/10/06(土) 00:01:51.18ID:LmyRE988
OcamlやF#のようにオブジェクト指向と関数型パラダイムを合わせて持つ言語もあるが、
内容は覚えていないけど本質的・理論的にはこの二つのパラダイムは相反するものだと聞いている。
確かに局所的、ミクロに上手くかかれた関数型の呼び出しは
型クラスのような複合構造の使う余地はもはや無く、自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
相反するのもうなずける話だと思っている。
OcamlやF#は詳しくないがどのレイヤでオブジェクト指向と関数型を使うかが分かれるんじゃないかな
numpyで関数の返り値が気がつくと内部クラスのオブジェクトになってた、みたいな。

479デフォルトの名無しさん2018/10/06(土) 00:23:54.73ID:wNGV+/Yb
>自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
この辺が気になる
オブジェクト指向プログラミングの場合は
クラス内に操作対象(変数)を封じ込めてクラス外からアクセス出来ないようにして
グローバル変数が各所からアクセスされることで無限のアクセスパターンになるというのを避けている
というのが肝なんだと自分は思ってるんだけど
関数プログラミングは難しくてさっぱり且つ入門もまともにやった事ないんだけど
状態なんかを副作用?とか呼んでなるだけ外に出す
という方法で対処する
みたいだそうなんだけど?
その辺どうなんだろうか?
少し上の方にその話になりそうな流れが有って少し期待してたんだけど
違う方向に流れたようで残念だったんだけど

480デフォルトの名無しさん2018/10/06(土) 00:49:03.56ID:LmyRE988
>>479
俺の書ける範囲で述べると、
身近な局所変数>一層外側のブロックの内部変数>。。。>大外側の大域変数
というスコープ階層は知ってるよね?

これに加えて関数呼び出しの階層
特に相似的階層構造の再帰で自然に繰り返しの表現(最終的には末尾再帰を
最適化で単純なloopに変換したコードが生成されるのだけれども)

この論理的(≠物理的)関数呼び出し階層構造では、
各階層における引数リストと返り値リストの相似的階層構造が
型クラスとその継承や委譲による階層構造のようなランダムで管理しにくいネットワーク構造としなくても
管理しやすい入れ子のスコープおよびエクステントの階層構造としてメモリ上に構築し自然に
アクセスできるイメージ

これで伝わるかな…

481デフォルトの名無しさん2018/10/06(土) 00:59:33.53ID:LmyRE988
>>480
lexical scope・extentと
関数呼び出し階層のネスト・木構造
で複雑なデータ構造の関連性が自然に細分化できる
同時に処理の細分化も速やかにできる
勉強している人にはこれで伝わると思う

型クラスとかアクセサでカプセルかとか継承とか全いらない

482デフォルトの名無しさん2018/10/06(土) 01:01:28.94ID:qfHN3zvO
関数型というかHaskellのええ所は>>260でいうパーツの切り分けが強制的になる所もあるよな
全てパターンマッチのワンライナーで関数が細かくブツ切りで出来るから後の編集しやすい

483デフォルトの名無しさん2018/10/06(土) 01:02:29.25ID:LmyRE988
ただまぁ万能ではなく、
別の弱点(副作用のアル処理の扱い、学習コスト含む)
もあるので俺はfunctionalマンセーではないけれど

484デフォルトの名無しさん2018/10/06(土) 01:31:10.16ID:LmyRE988
多態性についても文句あんだよねおれは。
あんあもの動的言語ではそもそも意識する必要も無い空気みたいなもの
それを変に応用して話をややこしくして…
まあ別途機会があれば書くかもしれないけれど。
かかないかおもしれない。

あどオブジェクト指向とその変な一時的流行で迷惑したのは
非科学的で誤ったオブジェクト指向論を信条として、それを宗教のように吹いてまわり
周りに強制し、反論すれば非難。でも自分ではたいしたソリューションのためのソフト開発できない
みたいな工程論・方法論者が跋扈して
開発者を煩わせたこと

485デフォルトの名無しさん2018/10/06(土) 01:38:18.52ID:9tCZRFgp
書籍も全部一色だったし
MSが金出してただろうししゃーない
雑誌社も何の根拠もないのにオブジェクト指向マンセーだったよね
本当に技術を見定める能力があればそれが詐欺であると気づいたんだろうな
多くの人間はそうでは無かった

486デフォルトの名無しさん2018/10/06(土) 01:41:57.53ID:LmyRE988
本当に有効な機能だけ自律して使えば有効な面もあったかもしれないけど
人間てそんなに器用じゃないし
群衆や社会問題って
チコちゃんの言う氷河期からそんなものだったのかもしれない

487デフォルトの名無しさん2018/10/06(土) 01:43:22.02ID:LmyRE988
今でもオブジェクト指向からDNNやAiにステージを移して
同じようなことが続いている

488デフォルトの名無しさん2018/10/06(土) 02:03:28.62ID:LmyRE988
でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
ソフトウエアの構造を表現している。そしてすごいスピードでreviseする。
べらぼうな才能と手間と時間をかけてクラスベースOOPでソフトウエアを表現しようとしている
あれは(個人的に好きではないけど)見事だとうなってしまう。
優秀な者が活躍して、採用したパラダイムが茨の道に密だとしてある水準まで力強く構築しようとしていると思う。

翻って上のレスで揚げたような日の本のオブジェクト方法論指向論者は
なんと
プアーなことか

同じOOPでも同列にみなしてはいけないんだろうな

489デフォルトの名無しさん2018/10/06(土) 02:13:25.41ID:LmyRE988
ちなみにpythonの言語仕様自体は
涙なくして語れないほどのクソだと俺は思っている

なんか文句あるか?
               ___
               /     \
             / ─    ─ \
            /  (●)  (●) \
              |     (__人__)     | <かかってこいよ
           ,.゙-‐- 、  `⌒´   ,/    おらー
        ┌、. /     ヽ ー‐  <.
         ヽ.X、- 、   ,ノi      ハ
      ⊂>'">┐ヽノ〃     / ヘ
       入 ´// ノ        } ,..,.._',.-ァ
      /   `ー''"´      ,'  c〈〈〈っ<
     /          __,,..ノ ,ノヽー'"ノ
      {          ´    /  ``¨´
    /´¨`'''‐、._        ,'\
     ∨´     `ヽ、     ノ   ゙ヽ
      ∨      ヽ _,,..-'"    `ヽ
     ∨       〈-=、.__       }
      ヽ、     }   ``7‐-.  /
          ヽ     リ    /′  ノ
          /′  , {     /   /
        {     !   ,ノ  ,/′
          !    /  /   `‐-、
        !   ,/   ゙ー''' ー---'
          ',  /
        {   }
           ゙Y `ヽ、
            ゙ー--‐'

490デフォルトの名無しさん2018/10/06(土) 07:19:55.96ID:hM5EPMW3
pythonにprivate変数はありません。
pythonにswitch文はありません。
pythonのクラス関数はselfを第一引数に
命名規則は決められたものを守りましょう
インデントはスペース4つ
括弧の書き方でsetになったりdictになったりします
一列の文字数は79文字以内

(一部言語仕様でないのも書いてるけど)利点でもあり欠点でもあるな

491デフォルトの名無しさん2018/10/06(土) 07:35:40.78ID:vpFDdLxA
>>181

まとめると:
  Python のオブジェクト指向はクソ

492デフォルトの名無しさん2018/10/06(土) 11:22:52.91ID:LmyRE988
>>490
一番クソなのは初期の段階でブロックとlexical scopeを配慮して言語設計しなかったこと
今でも引きずっている

493デフォルトの名無しさん2018/10/06(土) 12:56:22.72ID:sXtVjY80
ID:LmyRE988
↑なんでこいつすぐポエってしまうん?

494デフォルトの名無しさん2018/10/06(土) 13:08:17.37ID:LmyRE988
>>493
飲んで2chにポエム書くことくらい大目に見なよ

495デフォルトの名無しさん2018/10/06(土) 13:36:23.41ID:o3SQFYgr
>>492
blockは無いし頑なに追加しようとしないけど
lexical scope な言語ではあるだろ
何か勘違いしてるんじゃない?用語の意味わかってる?

496デフォルトの名無しさん2018/10/06(土) 13:43:55.83ID:LmyRE988
>>495
・関数の大外のfile scopeの変数を外部から参照させることが出来ない
classにする必要が無くてもclass objectを作ってclass変数とし無ければならない
・関数の内側は平坦なlocal scopeのみ、また外側の変数は参照のみ、更新できない(かった<3)
・block(てきなもの)がnestしてもscopeがnestしない
したがって関数bodyがでかくなると見えなくて良い遠くの変数を隠せない

>>492
で配慮していないと一言で言おうとしたのは
具体的にはこういった欠点

497デフォルトの名無しさん2018/10/06(土) 13:59:20.11ID:LmyRE988
>>495
モダンな言語なら必ず備えているコードのlexicalな階層構造と
変数のscopeの階層の明確な対応が出来ているとは
とても言いがたい

498デフォルトの名無しさん2018/10/06(土) 14:02:40.61ID:LmyRE988
さて、三連休だ、旅行に行ってくるわ。
あばよ、ノシ

499デフォルトの名無しさん2018/10/06(土) 14:04:15.02ID:o3SQFYgr
だから一言blockが無いで良いじゃん
lexical scopeは関係ない
それにpython 3だけで大抵の言語のシェアを上回ってるのに、
未だに2の批判するのも意味分からん

500デフォルトの名無しさん2018/10/06(土) 14:05:12.84ID:o3SQFYgr
>>496
>>495
>・関数の大外のfile scopeの変数を外部から参照させることが出来ない

これ意味分からんかったわ
どういうこと?

501デフォルトの名無しさん2018/10/06(土) 14:06:48.29ID:c8T9aSvT
>でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
>よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
>ソフトウエアの構造を表現している。
numpy、tensorflowがオブジェクト志向?
そんな気は全くしないんだが、定義が全く違うのかな?

502デフォルトの名無しさん2018/10/06(土) 14:08:53.96ID:o3SQFYgr
それと pythonでnonlocal や global を使いたくなるケースは
根本的に設計間違ってるから、クソコード撒き散らす前に設計見直した方が良いよ

503デフォルトの名無しさん2018/10/06(土) 14:18:09.40ID:o3SQFYgr
>>501
numpyやtfの中のコードの事だろ
使う側は手続き型で書ける
tfは計算グラフを構築してから実行するから宣言型かもな

504デフォルトの名無しさん2018/10/06(土) 14:21:52.83ID:sXtVjY80
>>501
そいつはここで気持ちよくポエりたいだけだから
レス返しても有益な情報は得られないよ
ポエ逃げしたいだけの人種だから

505デフォルトの名無しさん2018/10/06(土) 14:28:45.50ID:9tCZRFgp
スレッド内にカプセル化されとる

506デフォルトの名無しさん2018/10/06(土) 21:20:49.04ID:vpFDdLxA
>>503
まとめると:
・numpy や tf は C/C++ で書かれ内部はオブジェクト指向で設計された
・それらライブラリのAPIを Python は手続き的に利用している

つまりスレ的には、「Pythonのオブジェクト指向はクソ(>>181)」であると、
Python信者が認めたわけだ

507デフォルトの名無しさん2018/10/06(土) 21:28:26.10ID:c8T9aSvT
numpyの中身は知らんがtensorflowのどこがオブジェクト指向?
ホントにコード読んでんのかよ。。
なんか胡散臭い奴しかいねーな。。

508デフォルトの名無しさん2018/10/06(土) 21:38:32.17ID:9xvvgu9Y
>>506
数式を表現するのにオブジェクト指向なんていらん
行列演算したいだけなのにオブジェクト指向なんて強制されたらクソだわ

あ、数式使わないドカタの反論は不要なのでよろしく
ドカタには分からん世界があるんだよ

509デフォルトの名無しさん2018/10/06(土) 22:10:42.51ID:vpFDdLxA
>>508
Python信者からも賛同意見を頂けるとは嬉しい限り

・次世代言語12 Go Rust Swift Kotlin TypeScript
 http://mevius.2ch.net/test/read.cgi/tech/1530664695/963/
 >> 失礼な!!Python は FORTRAN/COBOL/BASIC に代表される
 >> 伝統的な手続き型言語の正当な後継スクリプト言語、
 >> 次世代の純粋手続き型言語です
 >>
 >> 関数型?オブジェクト指向?
 >> そんなのは飾りです、偉い人にはそれが分からんのですよ(必死

510デフォルトの名無しさん2018/10/06(土) 22:21:37.35ID:84qwAd3v
節子、それ便所の…

511デフォルトの名無しさん2018/10/06(土) 23:25:06.73ID:wNGV+/Yb
>>480さんへ
479です
自分は関数型に関しては完全に素人なのでなかなかに難しいです
単純に受けたイメージだとなんか凄くモノリシックに大きくなってしまいそう見えてしまう
関数型って何時もどういう風に制御するのか解らないなぁという感じで
基本的に難しい物なので自分には理解できないという感じなんだろうと思いつつ
今回は状態を通して何か掴めるかな?
と思いましたがそんなに甘くない感じですね
何にしても回答どうもです
関数型ってオブジェクト指向プログラミングシステムより更に難しいそうなのでオブジェクト指向より使える人が増えないような予感がします・・・

512デフォルトの名無しさん2018/10/07(日) 01:21:33.80ID:Nojuqsx1
>>502
そもそも nonlocal やら global などという
スコープ宣言に限定した予約語が存在するのは
Python が(歴史上、おそらくは)唯一の存在である、
という事実を忘れてやいませんか?

言い換えると、スコープに関して Python2 以前の
新規リリースの時点から「根本的に設計を間違えていた」のがPythonなわけ
で、根本的解決を採用せず、行き当たりばったりに
nonlocal やら golobal といった泥縄式対策を採用したのがPython3

513デフォルトの名無しさん2018/10/07(日) 01:25:43.47ID:iX7g/tHs
ゴローバルってなんかカッコええやん。
ゴローさん風味が出ててさ。

514デフォルトの名無しさん2018/10/07(日) 02:05:51.72ID:dWI643/y
nonlocalってセンスがウケるなw
いっそのことnonglobalも用意したらどうかwwww

515デフォルトの名無しさん2018/10/07(日) 14:29:17.30ID:+Rd5+blg
オブジェクト指向のスレでなんで延々と特定言語の言語実装の話してんの?
バカなの?

516デフォルトの名無しさん2018/10/07(日) 18:24:53.01ID:FMwg69WX
OOPの結果としては
クラスライブラリとかは文句なしに使いやすいと思うんだけどね
String, Map, List, Set, Threadなんかは十分使いやすいよね?
その点を否定するやつはさすがにおらんやろ?

517デフォルトの名無しさん2018/10/07(日) 18:26:20.74ID:qTxqyvp+
やっぱりクラスライブラリは使いやすいよね
文字列をポインタで操作してたCの時代に戻りたくない

518デフォルトの名無しさん2018/10/07(日) 18:37:23.80ID:FMwg69WX
そうなんよね
その点で見ればOOP大成功に見える

ただ、自前でクラスやクラスライブラリを書けつったときに
とたんにゴミの山になりかねないという

519デフォルトの名無しさん2018/10/07(日) 18:59:53.35ID:blwtBRQv
>>516
何と比べて?
別に同じ機能の関数あればええで

520デフォルトの名無しさん2018/10/07(日) 19:18:00.94ID:zvJnD+aL
>>516
使いやすいが、そこまで一般的なインターフェイスにするまで
いろんなソフトウェアの歴史があってこそなわけだ。
ユーザー定義でそのレベルのものを用意しようとすると途端に何も進まないか
クソインターフェイスをひたすら強要される現場となる。

521デフォルトの名無しさん2018/10/07(日) 19:37:46.92ID:FoRhSX54
クラス単体はオブジェクト指向だけど結局それを使うところでは手続き型にしてしまう。

522デフォルトの名無しさん2018/10/07(日) 22:20:34.82ID:mIq+f5AO
ならC++のメソッドをすべてスタティックで書けばいい
そうすればメンバ変数も不要
スタティックのメソッドは当然メンバ変数にはアクセスできない

手続き型なら、入力の構造体と出力の構造体を関数を別で渡す程度で済むハズ
オブジェクトの状態を常に外側で管理する必要があることになる

MS-WindowsのAPIは
ウィンドウハンドラをひとつのオブジェクトとみなして
ウィンドウハンドラを経由して操作や設定を行ってる

ウィンドウハンドラも一つのオブジェクトで入力も出力もできるシロモノになってるからな

523デフォルトの名無しさん2018/10/07(日) 22:25:31.13ID:mIq+f5AO
UNIXクローンのシステム関数にもwriteやreadがある
readやwriteはファイルディスクリプタを経由して
なにかしらに読んだり書いたりする関数だからな

つまりファイルディスクリプタをオブジェクトとみなして
読んだり書いたりしてるとみなしてると考えて差し支えない

コレはC++のようなオブジェクト指向言語で継承して実現できる内容と同じとみなせる

524デフォルトの名無しさん2018/10/07(日) 22:36:06.11ID:B8+uQuvb
オッカムの剃刀の逆を地で行ってるなw
オブジェクト指向の何がダメか腑に落ちた気がするよ。ありがとう。

525デフォルトの名無しさん2018/10/07(日) 22:46:39.84ID:qTxqyvp+
全部スタティックにするってそれ
スタティックおじさんじゃねーか!

526デフォルトの名無しさん2018/10/07(日) 22:48:32.68ID:9pTh9QRI
>>511
モノリシックに大きくなってしまうという印象は杞憂。
むしろ関数呼び出を一行ずつ言い切りみたいにつらねた宣言的書き方に近づく
リスト = 関数 リスト;
リスト = 関数 関数 リスト;
...
見たいな感じ。
状態は、本当に必要なもの以外は自然に登場してこなくなりその分複雑さを低減できる感じ。
どうしても状態管理が必要な処理は、
副作用の排除された純粋な言語の場合モナドみたいな物を持ち出さなければならないかもしれないが
副作用も許容している言語では、手続き的書き方をして状態を管理する形になると思われ、
どうしても必要な状態管理の煩雑さを関数型パラダイムで根本解決できるとはオレ的にはちょっと考えにくい。
難易度に関して言えば確かに学習コストは若干かかるけど、
いまはJavaやC++にもStreamやfoldなど関数型的なプログラミングのための機能が大急ぎで(かなりあせっている感じ)
取り入れられつつあるのであんまり肩肘張らないで、
ttps://qiita.com/stkdev/items/5c021d4e5d54d56b927c
https://ubiteku.oinker.me/2017/05/08/purpose-of-functional-programming/
といった導入的な情報などを参考にm日々の設計・開発の
局所的なコーディング範囲でもいいから使えるとことから使っていけば技術的な視野が広がるんじゃないかと思う。
ちなみに俺はそのサイトとは何の関係もないし、functionalマンセーではない

527デフォルトの名無しさん2018/10/07(日) 22:51:20.95ID:9RTjDYv/
ミドルウェアは天才が書くから天才の好む言語で書く
クライアントコードはアホが書くからアホでも分かる手続き型で書く
開発者の能力に応じて分業可能にした功績はある
だいたい天才とアホが同じ言語使ってたのが頭おかしい発想だった

528デフォルトの名無しさん2018/10/07(日) 22:52:56.75ID:9RTjDYv/
アホはひらがなだけ使え
漢字を使うと他のアホが読めなくなる

529デフォルトの名無しさん2018/10/07(日) 22:52:57.06ID:9pTh9QRI
そ、そうなのか…
なんか熱でもあるんじゃね?

530デフォルトの名無しさん2018/10/07(日) 23:03:08.28ID:zvJnD+aL
いやレイヤーや粒度によって向き不向きな言語、パラダイムがあるってだけだろ。
天才とかアホとか関係ねーわ。
まあそういう判断しかできない奴は例外なくアホだろうけれど。

531デフォルトの名無しさん2018/10/07(日) 23:07:07.43ID:9RTjDYv/
まあ例外なくアホとかいう恥ずかしい書き込みをするような奴は例外なく知的障害者だろうけど。例外なく、なw

5325212018/10/07(日) 23:12:36.26ID:4NXYL+If
staticに使い道なんてあったんだ・・・

533デフォルトの名無しさん2018/10/07(日) 23:20:21.45ID:9pTh9QRI
>>516
それらlibraryレイヤははよく練り上げられてまぁ使いやすいと思うよ。
でもよく考えてみてよ、納品を決められ短期間に仕様の策定からQAまでこなさなければならない
アプリケーションソフトウエア開発とそういった長年同じような機能のライブラリが繰り返し作り
直されてきたものは同一に論じることは無理でしょ。
それにレイヤが全然違うじゃない。
下から見れば数百個程度の機械語>言語の文法レベル>アルゴリズムのライブラリレベル
>それらを組み合わせ具体的なあるぴにための処理を折りませたアプリレイヤ>…
レイヤによって全然特性が違うんだよ。適した表現手段は当然違うと俺は思う。
つまりアルゴリズムのライブラリレベルに適した表現手段が必ずしもその上位にある
複雑な応用レベルの表現には適しているとは言いがたいのではないかということ。(ここ伝わりにくいと思う)
これは今でも俺も日々とても悩まされている問題。でもまそれはしzでんげんしょうみたいなものでしょうがないいんだよ。
誰も悪くないし。
本当に問題は、オブジェクト指向の名の下に非科学的非合理的で変な表現手段が流布し
(一部の人間が意図的に拡散させ)ソフトウエア開発の技術的水神をを後退させ混乱させてしまったこと。
俺はこの一点を問題視しているんだよ。

また飲みながらのポエムで悪いな。

534デフォルトの名無しさん2018/10/07(日) 23:22:20.26ID:9pTh9QRI
>>533 誤記多いなスマソ
しzでんげんしょう → 自然現象
技術的水神 → 技術的水準

535デフォルトの名無しさん2018/10/07(日) 23:26:20.11ID:FMwg69WX
>>533
大変申し訳ないが今後一切のポエムは不要ですんで分かってください

536デフォルトの名無しさん2018/10/07(日) 23:28:24.29ID:9pTh9QRI
>>535
そんなことよりポエムでもいいからなんか内容を書けよ
なんかむかついたのかw

537デフォルトの名無しさん2018/10/07(日) 23:28:51.19ID:FMwg69WX

538デフォルトの名無しさん2018/10/07(日) 23:31:09.36ID:9pTh9QRI
OOPの幻想を追いながらゴミの山量産してて頂戴

539デフォルトの名無しさん2018/10/07(日) 23:44:00.68ID:mIq+f5AO
https://ideone.com/PErfVu
コレがオブジェクト指向なコーディング

540デフォルトの名無しさん2018/10/07(日) 23:52:58.21ID:GYr8Tket
だからねえ、凡人プログラマがいきがってOOを語るなっつーの

それなりに名が売れてる人以外、講釈垂れ禁止にしたいよね

541デフォルトの名無しさん2018/10/07(日) 23:53:56.52ID:FMwg69WX
>>540
いっけん暴論だが
それはそれで正しい

542デフォルトの名無しさん2018/10/07(日) 23:58:46.68ID:9pTh9QRI
そしたら日本にいないぞ
>>540>>541 も 論外、対象外だし

おれはそもそもOOの講釈をたれたことは無いので自由だ。

543デフォルトの名無しさん2018/10/08(月) 00:05:22.29ID:SHTmPUE+
と低学歴知恵遅れの底辺がいってもな

544デフォルトの名無しさん2018/10/08(月) 00:08:53.96ID:YlFF3Gbm
日本人がプログラミングで実績残せないのはなぜだろうと思うけど
(まつもとゆきひろとか神レベルを除く)
講釈垂れは、1億円程度の案件でも沸いてくるんだわ
しかもたいていFランとか専門卒の地頭の悪さを自認できない語り部

俺のガンダムはさー、とか言い出す小学生と変わらんのよ

545デフォルトの名無しさん2018/10/08(月) 00:09:05.00ID:5FzXpRZO
そういう非論理的揚げ足取り未満のレスが着き始めると
ああ、OOP信者はねた切れなのかあるいは
そもそも何か問題のある人たちだったとつくづく思う

546デフォルトの名無しさん2018/10/08(月) 00:10:40.27ID:5FzXpRZO
そう言った人たちにみんなだまされ続けていたと

547デフォルトの名無しさん2018/10/08(月) 00:13:06.68ID:5FzXpRZO
>>545>>543 宛ね
念のため

548デフォルトの名無しさん2018/10/08(月) 00:13:33.24ID:YlFF3Gbm
細かいところの揚げ足取りで、議論になり得ないのも底辺の特徴ね

なので2ちゃん5ちゃんみたいな底辺8割の落書きでOOのメリットデメリットが議論できるわけがない
数年前はちょっと期待してたけど

549デフォルトの名無しさん2018/10/08(月) 00:15:48.02ID:5FzXpRZO
そうだけどそれでも決して悪いことではないと思う。
別に理想の場をもとめて誰もきているわけじゃない
しかしその一方、これもひとつの社会の縮図で
そのなかで自分も生きていくことには変わりは無い

550デフォルトの名無しさん2018/10/08(月) 00:18:20.98ID:5FzXpRZO
が、しかしだ。
オブジェクト指向ってのは実はクソだったと思う。
そして講釈をたれて変なオブジェクト指向を吹聴していた奴らはクソだった。
これは変わりない。

551デフォルトの名無しさん2018/10/08(月) 00:23:48.49ID:YlFF3Gbm
新しいものを無条件に礼讃するのはヲタの特徴だからしかたがない

問題なのはそれを実業に持ち込むバカと語り部がいることなんだよ

この業界は敷居が低いからヲタの比率が高くなりがちで、困るのは自己顕示欲が大勢な新しモノ知ってるぞヲタ

552デフォルトの名無しさん2018/10/08(月) 00:26:00.79ID:4+4YIfxx
このスレはレッテル張りばかりで中身のないレスが多いな

553デフォルトの名無しさん2018/10/08(月) 00:27:52.21ID:5FzXpRZO
日本のIT産業産業全体にいえることじゃん。
いま世界で絶賛ぼろ負け中だけど。
やITに限らない、はば広くぼろ負け中。絶賛衰退中。
OOP現象も同じだと思うんだよ。
純粋な技術的問題じゃないんだよね、社会的問題というか、人の問題というか。
CMMIもISO9000も

554デフォルトの名無しさん2018/10/08(月) 00:31:01.24ID:5FzXpRZO
中身のアルレス
よろしくお願いしまーす

555デフォルトの名無しさん2018/10/08(月) 00:36:06.65ID:YlFF3Gbm
俺もこの業界に長くいて新三大嫌悪感があるのが、多重請負、ISOとか監査もの、OOやDIの語り部

どれもこれも欧米被れというか、日本人が背伸びして、品質と生産性を落としてるだけだわ

そういえば技術じゃなくて社会的な問題かもね

556デフォルトの名無しさん2018/10/08(月) 00:43:44.28ID:5FzXpRZO
腹黒い奴がどう他人を操るかの手法として利用されてきたか側面はあると思う

洩れの周りでの話だけれど、OOPのカプセル化、getter/setter、
継承による(後付の)コード再利用性による開発量削減・コスト低減を社内でうたい始めた奴は
実は自分ではコードは書けず無論設計は出来ず、マネージメントもできず、忖度と口先でしのいできて
くいっぱぐれるまえにJavaの流行を察知して社内OOP論者になり、布教に励み
それが下火になるとCMMI,IPISOの流行にのってQA論者に衣替えした

557デフォルトの名無しさん2018/10/08(月) 00:47:41.87ID:5FzXpRZO
それにさんざだまされてうっかりJava信者になって
いまも問題点に気がつかず変なコード書いてる、あるいは部下や外注さんに強要して
迷惑がられている奴ら多数
これを暗黒時代と言わずしてなんというのだろうか

558デフォルトの名無しさん2018/10/08(月) 00:48:42.81ID:88AHsTr8
>>551
新しいもの?

559デフォルトの名無しさん2018/10/08(月) 00:52:04.16ID:5FzXpRZO
んなこたどうでもいい。
結論
オブジェクト指向はクソだった
都市伝説みたいな迷信だった。
沢山の人がだまされた
以上。

560デフォルトの名無しさん2018/10/08(月) 00:53:59.74ID:Kbmtp0Cm
ボトムアップドメイン駆動設計
https://ddd-community-jp.connpass.com/event/103428/

ぜひ参加してください!

561デフォルトの名無しさん2018/10/08(月) 00:58:34.19ID:5FzXpRZO
つぎに
関数型はクソだった
って言うスレが建てば一過言あんだけれどもな…

562デフォルトの名無しさん2018/10/08(月) 01:00:35.78ID:Z0JUGcFO
OOPに批判的な奴は最初から一定数いたよな
ちょろい奴を操る手法もまあ腹黒いが、批判を無力化する手法の方がもっと腹黒い

563デフォルトの名無しさん2018/10/08(月) 01:02:55.95ID:YlFF3Gbm
俺の会社では語り部は淘汰されたけど、糞コードは負の遺産として急には捨てられなくて困ってる

ロジックをトレースしづらいだけの継承とか、呼び出し順が分かりにくいだけのテンプレートメソッドとか、背伸びしまくりの知ったかぶりOO

564デフォルトの名無しさん2018/10/08(月) 01:10:27.58ID:5FzXpRZO
OOPって、それじゃあ全然ダメだったかというとそうでもなくて
頑張ればそれを使って(向いてないレイヤ・アプリでも)何とかソフトウエアを構成できたんだよ。
それはgotoを乱用してもがんばれば何とかソフトウエアを構成できたのと実は大差ないことだと
俺は思っているんだけれど。

それが厄介ごとの元。
上手くいかなかったときはOOPの理解が足りないからだとか、
低学歴には無理wとか批判されて、
そう、自分ではまともなコードををかけない奴に批判される
一体OOPは何のための手法なんだろうか

565デフォルトの名無しさん2018/10/08(月) 01:10:43.98ID:YGZFPxYk
手続き型しか分からないと言ってるのと同じ

566デフォルトの名無しさん2018/10/08(月) 01:11:52.30ID:5FzXpRZO
いや名誉のために言っておくと俺は低学歴ではないw

567デフォルトの名無しさん2018/10/08(月) 01:12:22.52ID:SHTmPUE+
オブジェクト指向は低学歴にはムリ
それはあってる

オマエも含めてな

568デフォルトの名無しさん2018/10/08(月) 01:13:21.14ID:5FzXpRZO
>>565
手続き型とオブジェクト指向てscopeのもちかたとその応用以外特に差はないよ

569デフォルトの名無しさん2018/10/08(月) 01:14:58.10ID:SHTmPUE+
低学歴知恵遅れはレスみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

オツムの程度をみても
低学歴知恵遅れにオブジェクト指向はまずムリ

570デフォルトの名無しさん2018/10/08(月) 01:15:28.69ID:tiRNksmV
手続き型言語で取り返しのつかない設計ミスって結構あったんだよ
そういう部分でオブジェクト指向には意味があると思うんだけどな
とりあえずデザパタどおりにしとけば何とかなる的な

571デフォルトの名無しさん2018/10/08(月) 01:16:28.07ID:5FzXpRZO
あんたあちこちで毎日こんなレスばっかかいてるね
いろんな人がいるなこの世には

543 名前:デフォルトの名無しさん[] 投稿日:2018/10/08(月) 00:05:22.29 ID:SHTmPUE+
と低学歴知恵遅れの底辺がいってもな

567 名前:デフォルトの名無しさん[] 投稿日:2018/10/08(月) 01:12:22.52 ID:SHTmPUE+
オブジェクト指向は低学歴にはムリ
それはあってる

オマエも含めてな

569 名前:デフォルトの名無しさん[] 投稿日:2018/10/08(月) 01:14:58.10 ID:SHTmPUE+
低学歴知恵遅れはレスみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

オツムの程度をみても
低学歴知恵遅れにオブジェクト指向はまずムリ

572デフォルトの名無しさん2018/10/08(月) 01:19:37.41ID:5FzXpRZO
>>571 は ID:SHTmPUE+ 宛
念のため


>>570
デザパタとか言うけどsingletonとか後論されつくしている通り
糞だぞ

573デフォルトの名無しさん2018/10/08(月) 01:20:11.16ID:SHTmPUE+
この必死さ

自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のサンプルをみるにつけ、最近段々と経験から分かるようになってきた

残念なことにすぐに分かっちゃう

574デフォルトの名無しさん2018/10/08(月) 01:21:42.91ID:YlFF3Gbm
人間が持つ分類の概念が似ているもの、GUIとか、そのサブクラスで違和感なくロジックがdispatchできるものが適用範囲なんじゃね?

欧米人のように、複数のオブジェクトが協調しあうような高度、かつうまく行くようなクラス設計できるようなセンスの持ち主が日本のIT業界に割り当てられるとは思えんし、実際に出くわしたこともない

絵空事のパワポの達人にはよく出くわすけどな

575デフォルトの名無しさん2018/10/08(月) 01:22:14.15ID:5FzXpRZO
いろんな人がいるな
法を犯さなければ野放しだから

576デフォルトの名無しさん2018/10/08(月) 01:23:47.08ID:5FzXpRZO
>>574
応用レイヤのclass設計で言うと見事と思えるものは海外にはある?

577デフォルトの名無しさん2018/10/08(月) 01:30:22.12ID:5FzXpRZO
この必死さ

自己評価だけは高い低学歴知恵遅れで底辺にありがち
低学歴知恵遅れで底辺であるからこそそうであるといえることが、
同様のサンプルをみるにつけ、最近段々と経験から分かるようになってきた

残念なことにすぐに分かっちゃう

578デフォルトの名無しさん2018/10/08(月) 01:30:49.29ID:5FzXpRZO
低学歴知恵遅れはレスみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

オツムの程度をみても
低学歴知恵遅れにオブジェクト指向はまずムリ

579デフォルトの名無しさん2018/10/08(月) 01:31:05.39ID:5FzXpRZO
オブジェクト指向は低学歴にはムリ
それはあってる

オマエも含めてな

580デフォルトの名無しさん2018/10/08(月) 01:32:16.55ID:5FzXpRZO
と低学歴知恵遅れの底辺がいってもな

581デフォルトの名無しさん2018/10/08(月) 01:33:25.88ID:YlFF3Gbm
>>576
オープンじゃないけど時価配信でObserverパターンになってるのはよく見るな

GUIだとDelphiだね、古いけど基本は同じだろう

582デフォルトの名無しさん2018/10/08(月) 01:33:53.33ID:5FzXpRZO
ハードが壊れるのと
低学歴知恵遅れのオツムが壊れてるのは
別問題

583デフォルトの名無しさん2018/10/08(月) 01:34:34.01ID:5FzXpRZO
システムが壊れてるワケじゃない
壊れてるのは低学歴知恵遅れのオツム

オツムが壊れてないヤツが作れば
壊れたシステムはできあがらない

オブジェクト指向はキチガイに刃物

ノータリンにオブジェクト指向を促すこと自体が常軌を逸してる
ノータリンがオブジェクト指向で開発しようとすること自体が銃刀法違反並の重罪

584デフォルトの名無しさん2018/10/08(月) 01:34:43.31ID:SHTmPUE+
低学歴知恵遅れがなんか壊れた

585デフォルトの名無しさん2018/10/08(月) 01:35:07.92ID:5FzXpRZO
だいたいわかる

ウンコスクリプトしか使えないような低学歴知恵遅れが
ムダにオブジェクト指向あげしてる

586デフォルトの名無しさん2018/10/08(月) 01:36:03.72ID:5FzXpRZO
>>584
お前さんの今までのレスをコピペして遊んでいただけだよ

587デフォルトの名無しさん2018/10/08(月) 01:36:36.34ID:5FzXpRZO
内容のあるレスを探したがが1つもなかったよ

588デフォルトの名無しさん2018/10/08(月) 01:40:06.65ID:5FzXpRZO
オレぐらいのレベルでないと
オブジェクト指向は使いこなせない

589デフォルトの名無しさん2018/10/08(月) 01:40:53.29ID:5FzXpRZO
もっとからかっちゃおうかなフフ

590デフォルトの名無しさん2018/10/08(月) 01:43:12.51ID:SHTmPUE+
ID:B/yxkRYZ
ID:j/6nk0eH
ID:cRG95Xcq
ID:Kxio7RVg
ID:pq96CSzd
ID:k5h2WtG4
ID:IuTgmxg/
ID:R8M7QKDK
ID:mIq+f5AO
ID:SHTmPUE+

このスレのオレのレスはコレがすべてだ
オマエみたいな内容のない低学歴知恵遅れと違って
たくさん有益なレスをしてる

低学歴知恵遅れには理解できないし読めないのはわかる
知能に著しい欠陥があるからな

591デフォルトの名無しさん2018/10/08(月) 01:44:25.97ID:SHTmPUE+
低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる

592デフォルトの名無しさん2018/10/08(月) 01:46:21.56ID:5FzXpRZO
>>590
乙。暇だね。
これはあくまで親心で申し上げるが、頭の病院いったほうがいいレベルですよ。

593デフォルトの名無しさん2018/10/08(月) 01:47:52.93ID:SHTmPUE+
バカは自分がバカであることに気づけないからな
キチガイには健常者がキチガイにみえるのと同じ

594デフォルトの名無しさん2018/10/08(月) 01:49:05.52ID:5FzXpRZO
いやなら別に病院に行かないでそのままひとり病んでてもいいけど
他人にはつくづく迷惑かけないようにね

595デフォルトの名無しさん2018/10/08(月) 01:49:23.87ID:SHTmPUE+
バカは自分がバカであることに気づけない
つまりバカは一生治らない
まずバカはバカの自覚をもつことができない

596デフォルトの名無しさん2018/10/08(月) 01:50:24.26ID:5FzXpRZO
つかこんなにレスしてたんだ
ぱっとみノイズレスだと思って読んでなかった

597デフォルトの名無しさん2018/10/08(月) 01:50:32.93ID:SHTmPUE+
病んでるのは間違いなくオマエだからな
低学歴知恵遅れで底辺になると発症する病気にかかってる

598デフォルトの名無しさん2018/10/08(月) 01:52:18.66ID:5FzXpRZO
ま火事とがいしは2chの華か

599デフォルトの名無しさん2018/10/08(月) 01:58:28.42ID:SHTmPUE+
まあオマエはオツムの病院へいったほうがいいわ
オツムが壊れてる

間違いなく軽度の知的障害がある

600デフォルトの名無しさん2018/10/08(月) 01:59:16.72ID:5FzXpRZO
お前さんは重度だぞw

601デフォルトの名無しさん2018/10/08(月) 02:00:38.48ID:5FzXpRZO
つーかいい子だからもうオナニーでもしてネナヨ
おじさんは忙しいんだから

602デフォルトの名無しさん2018/10/08(月) 02:04:10.21ID:5FzXpRZO
オナニー中らしいですww

603デフォルトの名無しさん2018/10/08(月) 07:42:27.80ID:kgyl4Ui4
オブジェクト指向のメリットは出たかな?

604デフォルトの名無しさん2018/10/08(月) 08:00:16.00ID:s8MF6MAn
クラス単体のプログラムが出来るのは利点だと思う。
そのクラス同士のまとめが難しい

605デフォルトの名無しさん2018/10/08(月) 08:22:40.86ID://kQ6Yzy
ID:5FzXpRZO大発狂しちゃってるやん…
応酬見てると半角のほうがまだまともに見えてくる件w

>>574
みたいに人種に原因を求めるのは実は面白いと思う
本人たちが従ってる働き方に既に問題があって
そこに疑問を持たないしどうしようとも考えない
足並みそろえて稲植えてたら収穫できるって発想

たがいの独立性や多様性をベースとした協調
直交性のあるもんを組み合わせるという日常
ってのはやっぱあちらさんに向いてるんだろうね

606デフォルトの名無しさん2018/10/08(月) 09:15:06.72ID:r/3VlGF9
自由で独立した人間は因果関係に縛られないんだぜ
原因はこれだから結果は必ずこうなるとか思ってない

607デフォルトの名無しさん2018/10/08(月) 09:31:21.11ID:rY7QFOOR
>>606
それはお前の思い込みですね

608デフォルトの名無しさん2018/10/08(月) 09:54:42.20ID:r/3VlGF9
思い込みではなく分類
因果関係に逆らえないのはモノや動物のように扱われる
それ以外が人間

609デフォルトの名無しさん2018/10/08(月) 10:16:09.72ID:rY7QFOOR
思い込みではなく分類というのは話が噛み合ってない
そういう分類があるという思い込みなんだから

思い込み or 根拠がある という話なんだから、
思い込みじゃないなら根拠を示すべき

610デフォルトの名無しさん2018/10/08(月) 10:19:41.89ID:zWcMcpmc
>>607
それはお前の思いこみだな

こんな糞レスへの反論なんてこれで十分なんじゃね?

611デフォルトの名無しさん2018/10/08(月) 10:34:48.33ID:r/3VlGF9
いや、こういうのでいいんだよ
分類に根拠がないという意見と、OOPに根拠がないという意見は似ている

612デフォルトの名無しさん2018/10/08(月) 10:36:56.72ID:kgyl4Ui4
それでオブジェクト指向にメリットはあるのかい?

613デフォルトの名無しさん2018/10/08(月) 11:23:00.34ID:rY7QFOOR
>>611
だから分類の話はしてない。

> 自由で独立した人間は因果関係に縛られないんだぜ
> 原因はこれだから結果は必ずこうなるとか思ってない

↑これが思い込みだって話をしている

614デフォルトの名無しさん2018/10/08(月) 11:23:35.59ID:rY7QFOOR
どや? 話をずらそうとしても、毎回戻されるのって苦痛やろう?www

615デフォルトの名無しさん2018/10/08(月) 12:12:51.99ID:Py80K8TM
半角さんは逃げてこんなスレでも足りない知識でドヤしてるんだwww

616デフォルトの名無しさん2018/10/08(月) 13:57:02.86ID:HrAB4JNP
GUIみたいに誰もが抽象化のイメージがわきやすいクラスと、Webフレームワークのような、使う人が継承して使えばなんとなく便利なクラスでは、抽象化のやりかたそのものが学問になりそうだよな

一般人はおとなしく継承したクラスの中に、業務ロジックを構造化プログラミングしてなさいってこった

617デフォルトの名無しさん2018/10/08(月) 14:15:51.85ID:kgyl4Ui4
>>616
抽象化に何のメリットがあるの?

618デフォルトの名無しさん2018/10/08(月) 15:37:04.77ID:aKFx8hdA
>>617
GUIの座標とか描画とか、共通関数にするよりもスーパークラスに持たせた方が共通処理と分岐処理が別れて、分岐判断の引数とか減るだろ?

別にオブジェクト志向言語じゃなくても構造体でも出来るし、事実、WindowsだってCで書かれてるけどな

619デフォルトの名無しさん2018/10/08(月) 15:55:28.49ID:kgyl4Ui4
>>618
いや別に分岐が必要な仕様じゃないんだけど

620デフォルトの名無しさん2018/10/08(月) 16:12:29.55ID:HqDSWn9/
>>618
WindowsはC++では?

621デフォルトの名無しさん2018/10/08(月) 16:30:04.70ID:IMi/szTI
>>619
分岐が必要な仕様じゃないってことは、
分岐が必要な仕様の場合は?

622デフォルトの名無しさん2018/10/08(月) 16:46:43.13ID:kgyl4Ui4
>>621
switch case

623デフォルトの名無しさん2018/10/08(月) 16:55:14.91ID:IMi/szTI
>>622
なんで不分岐が必要ない仕様とか言い出したの?
自分が都合がいい例にしたかった?w

624デフォルトの名無しさん2018/10/08(月) 17:20:09.48ID:kgyl4Ui4
>>623
いや、テメーで勝手に分岐が必要なブッサイクなクラス作っておいて
それはないなと
それにクラス構造で分岐しないでくんない?
読み辛い
はっきり言ってクソ
仕様書にどんな条件で分岐してるのか書きにくい
控えめに言って死ね

625デフォルトの名無しさん2018/10/08(月) 17:24:49.00ID:Tz+BH4lq
>>623
こういう奴がパラダイムの違いを理解しないまま書くからOOPが害悪になるんだよな

626デフォルトの名無しさん2018/10/08(月) 17:28:45.60ID:SHTmPUE+
windowsでは普通にイベント分岐処理でもswitch文使う
それを隠蔽化するために仮想関数にして実現するどうかは作るヤツのセンスで決まる

627デフォルトの名無しさん2018/10/08(月) 17:30:28.51ID:kgyl4Ui4
>>626
それすげーやめてほしい
こっちはテメーが作ったただでさえうんこみたいな設計書に
そう書いてあるから見に行ったのに
そのとおり作ってないとか設計書ゴミ箱に捨てんぞ糞が

628デフォルトの名無しさん2018/10/08(月) 17:43:41.49ID:YlFF3Gbm
いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。Windowsの低レベルプログラムは。

629デフォルトの名無しさん2018/10/08(月) 17:45:55.46ID:IMi/szTI
>>628
> いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。

オブジェクト指向で作らないからそうなる

630デフォルトの名無しさん2018/10/08(月) 17:48:29.61ID:lYyho1IC
MFCのメッセージマップは嫌いだった。
switchのほうが100倍分かりやすい。

631デフォルトの名無しさん2018/10/08(月) 17:54:08.00ID:YlFF3Gbm
MFCが出てくる前は、Cでゴリゴリ書いてたのよ
MFCが曲者っつー話はさておき、
Cでクライアントプログラムを書くわけだが、Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる

632 ◆QZaw55cn4c 2018/10/08(月) 18:53:59.21ID:Vh0J6/Nb
>>626
>windowsでは普通にイベント分岐処理でもswitch文使う
pedzold では終始一貫して switch なのは、ちょっとどうかな、と当時でさえ思っていました

>それを隠蔽化するために仮想関数にして実現するどうかは作るヤツのセンスで決まる
今思うに、これは悪手なのではないかと

633 ◆QZaw55cn4c 2018/10/08(月) 18:58:32.67ID:Vh0J6/Nb
>>631
>Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる
それ、今でもよくわからないですね
::RegisterClass() ってコンストラクタに該当するのですか?なぜ ::CreateWindow() とは別に定義したのでしょうか?私はこの二つはラッピングしちゃってます…

634デフォルトの名無しさん2018/10/08(月) 19:22:15.46ID:Tqf3ZL+v
WindowsをCで書くわけにはいまさら中々いかないだろう。
かといってgcのある言語やインタプリタのようにアプリ寄りの言語で書くのは不可能だろ。
そうやってnative codeを出せかつOSの記述も(苦労するが何とか)記述可能な言語は
消去法でC++しかなくなる。DとかRustじゃ無理。

また、Windowsと言う位だから、上位には何らかのOOP GUI IFを提供しなければならない。
別にC++のOOP機能が優れていたからWindowsがC++が記述されたわけではない。
ここ勘違いしないように。

635デフォルトの名無しさん2018/10/08(月) 19:25:35.43ID:lYyho1IC
WindowsがOOそのものの思想、と言うのはハンドルまみれなAPI群があるので素直に同意できないけど、ウィンドウ周りは多少は頑張った感あるよね。
>>633
ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時にメモリが節約できるというメリットがあるかと。

636デフォルトの名無しさん2018/10/08(月) 19:29:38.91ID:5naxcKBN
シグナルが何とかならないかと思うけど
atomとかもう使いたくない

637デフォルトの名無しさん2018/10/08(月) 20:24:37.00ID:Z6PD3tJ3
>>526さんへ

示された所じゃなくて
その下に有ったリンク先を読んで解った事が有った
https://qiita.com/hiruberuto/items/26a813ab2b188ca39019
読んでいて何が自分に難しいのか?

関数型の場合
処理対象全域を考えて関数で並ぶように作らないといけない
副作用やその他の物を一時に頭に入れて整理し無いといけない
(リンク先にはそうではないと書かれているが自分にはそう見える)

けどオブジェクト指向の場合
対象となる処理を分割して個々に作っていく
分割して個々に作っていった物を連携させて
最終的にはその集合体が出来上がれば機能する
という方が自分に向いている

頭が悪い人間と言うのは広く色んな要素が一編に出て来る物の状態を正確に把握して
それを組み立てる
というのが苦手なのよ

関数型プログラミングは間違いなく
使える人が限られる
そういう物になるだろあなぁ

でもc++なんかでも標準ライブラリーに既にそれっぽいのが有るから
使える程度には理解しないといけなくなるんだろうねぇ
その程度ならなんとかなるかなぁ(笑)

何にしても参考になりました

638デフォルトの名無しさん2018/10/08(月) 20:28:18.73ID:kgyl4Ui4
>>637
バカじゃん
テメー以外の奴が作ったときに
privateにされたらそれでしめーだろーが

そういう当たり前の想像力が欠落してるからテメーは何考えても
ダメダメのうんこちゃんなんだよ

639デフォルトの名無しさん2018/10/08(月) 20:31:49.61ID:kgyl4Ui4
メソッド呼ぶたびにクソクラスの内部のウンコがどうなってるのか
ケツアナほじって掻き出さなきゃいけねーんだよ

640デフォルトの名無しさん2018/10/08(月) 20:35:33.15ID:IMi/szTI
標準ライブラリのprivateメソッドとか
もうソースコード読みまくりだからな

641 ◆QZaw55cn4c 2018/10/08(月) 20:52:27.06ID:Vh0J6/Nb
>>635
>ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時に
同じウィンドウクラスを使いまわすっていうのが、そういうことをやる機会があるかどうか、という点でいまいち、なんです
つまり現状のウインドウクラスにてウィンドウプロシージャを設定する、というのが疑問でして、ウィンドウプロシージャが ::CreateWindow() の引数だったら、使いまわす、ってことも検討したかもしれませんが

642デフォルトの名無しさん2018/10/08(月) 21:30:56.46ID:811LgONL
>>637
foreach, map, reduce, filter などを使うことによって、
for ループやif分岐や一時変数を使う助長で古典的な書き方から脱却し
リストの要素間の多対応・変換を宣言的に記述し切っていく、
既存言語に拡張されつつある関数プログラミングパラダイムの
限定的でも美味しいとこ取り的な使い方からはじめても全然いいんジャマイカ

643デフォルトの名無しさん2018/10/08(月) 21:35:43.59ID:811LgONL
あと、詳しく書くと長くなるので一言ずつ書くと
繰り返しではなく末尾再帰を使えるところでは活用する
クラスを設けて多様性をあらわすのではなく、クロージャーや部分適用で簡潔に表現する
遅延評価や関数変換を使って有効なところで使う
とか

644デフォルトの名無しさん2018/10/08(月) 21:36:52.15ID:IMi/szTI
関数型とオブジェクト指向は実は相性がよくて、
オブジェクト指向でオブジェクトとしての構造を
そしてオブジェクト指向の中で使う関数は関数型と
組み合わせて使うのが最強なんだ

645デフォルトの名無しさん2018/10/08(月) 21:39:02.72ID:811LgONL
>>644
だからそれはレイヤやグレインの観点から上手くいかないんじゃないかって
上で書いたのに。
上手くいく方法があったら披露してよ

646デフォルトの名無しさん2018/10/08(月) 21:43:02.58ID:IMi/szTI
末尾再帰の話が出てきたから、知識の浅い人に説明しておくと

関数型は再帰で実装するから手続き型のループを使う方法よりも遅いという常識を
特定の条件を満たしている場合にループに変換することで、遅くならない
というもの。決してループよりも速くなるわけではない

647デフォルトの名無しさん2018/10/08(月) 21:45:21.28ID:IMi/szTI
>>645
何ができたらうまくいくってことになるんだ?

俺にとっては開発が楽になることがうまくいくことだ
楽になってるのでうまくいっている

648デフォルトの名無しさん2018/10/08(月) 21:45:58.21ID:811LgONL
>>644
あとcontinuationとかyieldとか使うと幸せになることがたまにあるぜよ

649デフォルトの名無しさん2018/10/08(月) 21:46:30.31ID:IMi/szTI
>>648
はい。オブジェクトの内部で使います

650デフォルトの名無しさん2018/10/08(月) 21:47:17.86ID:811LgONL
>>647
何の言語で何をどう作ってんだか知らないが
上手く言っているなら方法論を披露プリーズ

651デフォルトの名無しさん2018/10/08(月) 21:48:12.08ID:811LgONL
>>649
methodの中つまり関数の中でだろ

652デフォルトの名無しさん2018/10/08(月) 21:50:45.37ID:811LgONL
明日出勤なので寝るぜ
あばよはげどもノシ

653デフォルトの名無しさん2018/10/08(月) 21:51:32.33ID:IMi/szTI
>>650
方法論ってなにがほしいのか知らんが、
関数型言語で作ったライブラリは状態を持たないから
汎用的な関数ライブラリになる。
それを便利にオブジェクトで使用する

654デフォルトの名無しさん2018/10/08(月) 21:53:09.64ID:kgyl4Ui4
オブジェクト指向のメリットは説明できたかい?

定期的に貼らないと関係ないこと主張する奴がわくからな
これが説明できないならクソ

655デフォルトの名無しさん2018/10/08(月) 21:56:30.02ID:IMi/szTI
オブジェクト指向のメリットは状態を
簡潔にわかりやすく持たせることができる

アルゴリズムならともかくシステムから
状態をなくすのは不可能なので
それをどれだけ直感的に扱うか不可欠になる

それが関数型に対するオブジェクト指向のメリット

656デフォルトの名無しさん2018/10/08(月) 22:00:12.76ID:811LgONL
>>655
直感ですか…

657デフォルトの名無しさん2018/10/08(月) 22:01:29.15ID:r/3VlGF9
OOPのメリットを教えてくれる奴なんていくらでもいたよな
それでOOPが普及して
ふと気付いたらメリットが何だったのか思い出せない

ここでまたメリットを教えられても無限にループするだけだ

658デフォルトの名無しさん2018/10/08(月) 22:05:17.61ID:IMi/szTI
>>656
そう。3歳の子供でも、リンゴとミカンの色や形
犬や猫の鳴き声の違いぐらいわかるだろう。
それぐれいオブジェクト指向は人間の思考と一致している

659デフォルトの名無しさん2018/10/08(月) 22:05:31.32ID:811LgONL
型クラス、クラスscope、オブジェクトscope,
同じ名前の多態(振る舞いの違い)、
継承によるあっちこっちに無難格納したソースファイルの
似たmethon部分の短冊のような共有による依存性のジャングル

これらについて理論的、科学的に有効性を述べないとだめだよ

660デフォルトの名無しさん2018/10/08(月) 22:11:45.44ID:811LgONL
そう、そしてそれらがある程度規模の大きく複雑な
アプリケーションレイヤのソフトウエアの構造表現として
どう有効なのか理論的、科学的に述べないと…

661デフォルトの名無しさん2018/10/08(月) 22:19:30.00ID:r/3VlGF9
確実にメリットがあるなら人には教えないで独占する
それが理論的で合理的

確実ではないギャンブルなら人に教える

662デフォルトの名無しさん2018/10/08(月) 22:28:08.41ID:811LgONL
>>661
つまりメリットは無いとw

663デフォルトの名無しさん2018/10/08(月) 22:33:36.33ID:811LgONL
オブジェクト指向は低学歴にはムリ
それはあってる

オマエも含めてな

664デフォルトの名無しさん2018/10/08(月) 22:34:58.92ID:6UIbz9ua
たまに見るけど100%でない=0%の人の思考はどうなってんだろうね

665デフォルトの名無しさん2018/10/08(月) 22:35:17.30ID://kQ6Yzy
パニックでも起しちゃってるのかなこの子

666デフォルトの名無しさん2018/10/08(月) 22:37:03.95ID:811LgONL
低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる

667デフォルトの名無しさん2018/10/08(月) 22:38:24.97ID:811LgONL
だいたいわかる

ウンコスクリプトしか使えないような低学歴知恵遅れが
ムダにオブジェクト指向あげしてる

668デフォルトの名無しさん2018/10/08(月) 22:44:26.66ID:YGZFPxYk
まーたお前かいつも必死だな

669デフォルトの名無しさん2018/10/08(月) 22:51:37.06ID:811LgONL
節子それfake

670デフォルトの名無しさん2018/10/08(月) 23:13:05.52ID:r/3VlGF9
1bit思考の中で最悪なのは、需要と供給
買う方が100%自己責任と思ってるから売ってる側は罪悪感0

671デフォルトの名無しさん2018/10/08(月) 23:18:57.76ID:811LgONL
その論点から起こしてだね、
オブジェクト指向の有効性を非論理的、寝技的に布教しようとするのは
いくらなんでももう、無理があるよ

672デフォルトの名無しさん2018/10/08(月) 23:40:30.66ID:C02Vpegg
ここの議論でもそうだけどカプセル化とかインターフェイスに対するプログラミングとか
ここの要素について話すのは意味があるが
「オブジェクト指向」って言葉でまとめると途端にクソ議論になる。
その意味ではやっぱり失敗だろう。

673デフォルトの名無しさん2018/10/09(火) 02:31:35.79ID:GxJd+3a3
>>672
その辺はポジティブな意味合いが強いからな
ただメリットがあるからってデメリットがどうなるかは別問題として

674デフォルトの名無しさん2018/10/09(火) 06:16:50.45ID:1H6kld1Z
カプセル化とかは「学習コスト」だから100%ネガティブ
コストを消費する代わりに何かメリットがないとポジティブどころか中立にもならねえ

675デフォルトの名無しさん2018/10/09(火) 06:53:21.12ID:Fv2MSo0/
今になって思うのは、オブジェクト指向にまつわる説明で特徴的な何々は何々であるだから何々があるはずだ的な事は製作者側の考え方の根本だったんだろうな。
ここに共感してないから触ってても疑問がつきまとう。
それでもってこういう考え方をする奴は布教的な奴が多い。こういう奴らは本当本当に嫌いだわ。人のその後に対する考えなんてみじんも無い。
例えばウェブ上で人気の言語的なランキングで上位に入ってる言語と周りを見渡して実際触られる言語の食い違いがひどい。
他の奴の意見見てると大体同じ感覚で変な笑いがでる。

676デフォルトの名無しさん2018/10/09(火) 07:05:27.74ID:xcSr1k5g
振り返ると、信仰宗教みたいな流行だった

677デフォルトの名無しさん2018/10/09(火) 10:12:33.99ID:hleJLyKe
オブジェクト指向の宗教的側面と、Rubyの宗教的側面がかけ合わさって
ドン引きするレベルの狂信者が出現した

もはや言語は死につつあるのに狂信者は毎日板を荒らし回ってる

678デフォルトの名無しさん2018/10/09(火) 10:58:21.87ID:MhhKJFZu
>>674
学習コストはなんにでも適用できる
一般的すぎて無視できる

プログラムを作るにはカロリーを消費すると
言うようなもの、そらそうだで終わり

679デフォルトの名無しさん2018/10/09(火) 11:01:37.61ID:MhhKJFZu
カプセル化してしてデータを閉じ込めることこそ
オブジェクト指向の真髄、データに対する責務を
集約する事でプログラムを作りやすく堅牢で
メンテナンスしやすくできる

680デフォルトの名無しさん2018/10/09(火) 11:40:52.35ID:1H6kld1Z
>>678
コストがあるから見返りにメリットが必要だったんだが
コストを無視するならもうメリットがあってもなくてもいいぞ

681デフォルトの名無しさん2018/10/09(火) 12:02:03.11ID:MhhKJFZu
>>680
一般論過ぎてオブジェクト指向の話になってないやん

682デフォルトの名無しさん2018/10/09(火) 12:02:46.32ID:MhhKJFZu
赤信号なら止まると良いぞと言ってるようなもの
当たり前やん

683デフォルトの名無しさん2018/10/09(火) 12:05:55.31ID:MhhKJFZu
オブジェクト指向テクニックを使うと外から壊されにくい
堅牢なデータ構造を作ることができてプログラムの
完全性を保証できる、オブジェクトを組み合わせて
より大きなプログラムを作れるっていうのが
オブジェクト指向のメリット

684デフォルトの名無しさん2018/10/09(火) 12:11:49.02ID:1H6kld1Z
当たり前すぎるってあれだよな
反証不可能ってやつ
反証したい勢力と対立煽りするくらいがちょうどいいんだよな

685デフォルトの名無しさん2018/10/09(火) 12:12:29.16ID:MhhKJFZu
データ隠蔽が有害っていうのは嘘だ
データは隠してなんぼ、オブジェクトを使う側に
データの存在を意識させないようにする事で堅牢な
プログラムを構築できる

686デフォルトの名無しさん2018/10/09(火) 12:44:03.73ID:3cHmJpwL
大規模開発はオブジェクト志向が、
とか喧伝する低偏差値信者もおとなしくなり、
一歩下がって、そんなに良いものだったっけ?と振り帰られる雰囲気がでてきたのは良いこと

いつまでも熱狂信者の思惑通りにはいかないよ
時がたてば、本当にコストペイするものだけが生き残る

687デフォルトの名無しさん2018/10/09(火) 15:34:08.86ID:s6lFROtd
>>685
テストもできないのが不味い
結局使用する側が状態を意識しなくてもいい造りなら問題はおきない

でもinitメソッド連発で呼ばれると死ぬだろ現実
initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
ってのが呼ぶ側の主張

688デフォルトの名無しさん2018/10/09(火) 16:17:24.49ID:MhhKJFZu
>>687

689デフォルトの名無しさん2018/10/09(火) 16:51:04.98ID:DgfNcklC
>>688

690デフォルトの名無しさん2018/10/09(火) 17:11:39.56ID:UgeI4/Dm
>>687
> でもinitメソッド連発で呼ばれると死ぬだろ現実
> initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ

どんな場合でも初期状態に移行すればいいだけでは?

691デフォルトの名無しさん2018/10/09(火) 17:18:38.78ID:n+YH3pNB
別スレッドでアクセス中でもか?

692デフォルトの名無しさん2018/10/09(火) 17:23:43.77ID:UgeI4/Dm
>>691
別スレッドでアクセスさせなければいいだけ

693デフォルトの名無しさん2018/10/09(火) 17:54:07.48ID:MhhKJFZu
スレドセーフじゃないのなら仕方ない

694デフォルトの名無しさん2018/10/09(火) 18:17:11.30ID:o83bbsRF
>>690
でも実際はハードに近い部分のinitだったりするとそうはいかないケースがあるよね?
って可能性が想定できないなら君は設計を語るレベルにないんじゃない?

695デフォルトの名無しさん2018/10/09(火) 18:33:33.36ID:UgeI4/Dm
>>694
自分の都合がいい条件じゃないと当てはまらないと
認めているようなもんじゃないかw

696デフォルトの名無しさん2018/10/09(火) 18:37:20.67ID:o83bbsRF
>>695
いやいや、この場合そういうケースがあることを説明できればいいよね

697デフォルトの名無しさん2018/10/09(火) 18:50:57.71ID:UgeI4/Dm
>>696
じゃあそういうケース以外には当てはまらないってことでいいよね
例外中の例外なんてどうでもいいわ

698デフォルトの名無しさん2018/10/09(火) 18:51:36.15ID:UgeI4/Dm
それに関数型だとハードに近い部分はさわれないし

699デフォルトの名無しさん2018/10/09(火) 18:52:15.46ID:jSAcVkU7
メソッド呼ぶほうが呼び出し順にナーバスな設計というのが糞
内部を隠蔽できてねーやんというだけのこと

700デフォルトの名無しさん2018/10/09(火) 19:29:52.46ID:o83bbsRF
>>697
問題はオブジェクトが状態を内包しちゃってることなんだけど?

701デフォルトの名無しさん2018/10/09(火) 19:31:40.73ID:o83bbsRF
んでそれを踏まえて
お前のクソクラスは息してんの?
って話
レアケースだから死ぬわってお前
言ってるように聞こえるけど
バカなん?

702デフォルトの名無しさん2018/10/09(火) 20:06:57.87ID:9OTFAl28
>>689

うるせぇエビフライぶつけんぞ

,.、,、,..,、、.,、,、、..,_  /i
;’`;、、:、. .`゙:.:゙`’’’:,’.´ -‐i
‘、;: …: ,:. :.、..; .;;.‐’゛ ̄  ̄
   ヽ(´・ω・)ノ
     |  /
     UU

703デフォルトの名無しさん2018/10/09(火) 20:08:18.35ID:UgeI4/Dm
>>700
オブジェクトが状態を内包するか
オブジェクトの外に状態を置くかの違いでしか無いですね

704デフォルトの名無しさん2018/10/09(火) 21:39:06.76ID:o83bbsRF
>>703
だからその一点でクソだって言い続けてるじゃん
カプセル化がどうとかバカの妄想だろ
テメーの状態がわからねーのが一番のリスクなんだよ
何がカプセル化だよ
早く死ねよ

705デフォルトの名無しさん2018/10/09(火) 21:45:21.47ID:Z2FoPQmM
localなデータを局所に隠蔽するべきなのはソフトウエア工学上、
当然のことでカプセル化の専売特許ではない。
ほぼすべての最近の言語はlocal scopeを持っている。
だがオブジェクト指向のカプセル化によるデータの内包とアクセサは
他の言語の持つモダンな階層的scopeに管理工学的にはるかに劣る。
ここ勘違いしないように。

706デフォルトの名無しさん2018/10/09(火) 21:51:03.83ID:9yAlTK3b
>>705
日本語w

707デフォルトの名無しさん2018/10/09(火) 21:54:07.22ID:Fg4seD6E
テクニカルタームで煙に巻くのも便所の落書き

708デフォルトの名無しさん2018/10/09(火) 21:57:54.52ID:n+YH3pNB
まあ、forループの回数カウンタなんかローカルで充分だしな。

709デフォルトの名無しさん2018/10/09(火) 21:58:49.50ID:Z2FoPQmM
この程度でテクニカルターム…

710デフォルトの名無しさん2018/10/09(火) 22:30:33.22ID:UgeI4/Dm
>>704
ようするにテストはプライベート変数を見たいってだけですよね?
テスト以外では必要ないですよね
カプセル化バンザイですよね?

711デフォルトの名無しさん2018/10/09(火) 23:05:57.02ID:5o1aZXWL
どれくらいのアクセス度がいいかはそのクラスのそれぞれによるところはある。
STLのvectorなんて見方によってはかなりオープンだけれどあれはあれで適切な開け方。

712デフォルトの名無しさん2018/10/09(火) 23:18:00.29ID:uKgwXIAC
内部の状態が心配なら
ちゃんとクラスに内部の状態を(コンポジションなら当然再帰的に)ダンプする関数ぐらいつけてんだろうな
つけてないならお話にならない

外部で状態を管理して
外部で構造体を監視するのと
そう変わらない

713デフォルトの名無しさん2018/10/10(水) 00:01:14.01ID:j7g+1zT7
>>710
テストだけではないな
その関数が同一の結果を返す条件を固定したい
っていうかできねープログラムなんてぶっちゃけクソもいいとこだろ

714デフォルトの名無しさん2018/10/10(水) 00:06:10.55ID:+GhPUDy2
仕事関係なく趣味でソフト作ったやつの意見は尊重できる。仕事だけで横文字多様してる奴のはフィルター推奨だな。

715デフォルトの名無しさん2018/10/10(水) 00:10:05.04ID:+GhPUDy2
流石にいないか。それは。

716デフォルトの名無しさん2018/10/10(水) 00:54:19.42ID:T78UR1cm
本当にそれは状態として動的に管理すべき対象なのか
十分吟味してないだろ

717デフォルトの名無しさん2018/10/10(水) 01:07:23.22ID:YM9RoEIA
>>716
ん?
じゃあ、クソインスタンスがどんな状態でメソッドを呼んでも絶対同じ結果返すんだな?
その時点でメンバ変数いらねーけど

718デフォルトの名無しさん2018/10/10(水) 01:35:56.64ID:T78UR1cm
>>717
日本語読めるようになってからレスした方が良いよ

719デフォルトの名無しさん2018/10/10(水) 01:48:46.78ID:s7T/eKYL
>>713
お前は現在時刻を返す関数は一生使うなよ
クソなんだろ?

720デフォルトの名無しさん2018/10/10(水) 02:19:17.93ID:vuJDL2IF
Haskellでいう副作用なら標準入出力、ファイルio、時間、ランダムなどが副作用なるな
モナド並にリッチなシステムをオブジェクト指向で組んで副作用を過敏排除するなら楽しそうやんけ

721デフォルトの名無しさん2018/10/10(水) 06:36:14.84ID:az2ldVPt
>>713
> その関数が同一の結果を返す条件を固定したい

引数Aにaを入れる、引数Bにbを入れる、引数Cにcを入れる
引数A、B、Cで関数funcを呼び出す

メソッドAでaを入れる、メソッドBでbを入れる、メソッドCでcを入れる
メソッドfuncを呼び出す


関数の引数に値を入れる代わりにオブジェクトに入れるだけの違いでしか無い

722デフォルトの名無しさん2018/10/10(水) 07:54:35.27ID:75F81x8u
>>719
現在時刻しか返ってこねーだろ?
テメーのは指定してもいないのにサマータイム返すクソだろ

723デフォルトの名無しさん2018/10/10(水) 07:55:48.71ID:75F81x8u
>>721
でも入力値は使用する側が意図的に入れるものだけど
メンバ変数は何になっているかわからない

この差がデカイ

724デフォルトの名無しさん2018/10/10(水) 08:08:36.10ID:WWPIMa8b
>>713
>その関数が同一の結果を返す条件を固定したい
同じ条件で違う結果が返ってくる関数ってハードウェア乱数発生器とかしか思い浮かばないんだけど、具体的にこんな関数ってのある?

725デフォルトの名無しさん2018/10/10(水) 08:42:05.46ID:00uAZtDo
>>714
結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
簡単な事を冗長的にフレームワークのようにしたコードが多くてただの社内での点数稼ぎなんだろうと伝わってくる。そして少し環境を変えてシステムを構築し直す時に問題が出て来るのって大抵そういうコードだったりする。

726デフォルトの名無しさん2018/10/10(水) 08:49:14.91ID:az2ldVPt
>>723
> でも入力値は使用する側が意図的に入れるものだけど
> メンバ変数は何になっているかわからない

変数に文字列入れたって、それがどういうフォーマットで入っているかなんてわからんだろ

文字コードは何なのか、内部エンコーディングなのか
文字列の最初に文字列長情報がついているのか
文字の終わりは\0なのか

変数に数値入れたって、それがどういうフォーマットで
入っているかなんてわからんだろ

32bitで保存されているのか、64bitなのか

変数に入れようがメソッド呼び出そうが
ある一定の手順の操作を行えば、それで状態は確定するんだよ

727デフォルトの名無しさん2018/10/10(水) 08:50:44.41ID:az2ldVPt
>>725
> 結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。

あぁ、プロの将棋を素人が見ても、凄さを理解できないのと同じだな
んで、何やってるか理解できないから、直すこともできない

728デフォルトの名無しさん2018/10/10(水) 09:25:59.20ID:lh7vR7+I
凄さを理解されなくても半分諦めてるプロって
ラノベ主人公でよくあるやつじゃん

729デフォルトの名無しさん2018/10/10(水) 10:18:56.28ID:00uAZtDo
素人とプラグラマーに根本的な差を感じてる奴はちょっと怪しいな。

730デフォルトの名無しさん2018/10/10(水) 10:58:13.09ID:00uAZtDo
素人だからこそ言い切れる。プログラミングって9割はツールを使いこなせるでしか無いよ。
将棋に関してもたぶん君は将棋について詳しくない人だと思うな。

731デフォルトの名無しさん2018/10/10(水) 11:03:52.32ID:az2ldVPt
素人が言い切れるわけ無いだろ。常識で物を言えや

732デフォルトの名無しさん2018/10/10(水) 11:48:06.40ID:00uAZtDo
ま、分かったじゃあそう思っとけ。このご時世どんなに賢ぶってもそんなに凄いプログラマーが日本に溢れてないのが透けて見えてるんだけどな。

733デフォルトの名無しさん2018/10/10(水) 12:27:49.69ID:AVL6Qil2
俺もオブジェクト指向を中途半端にかじった中途半端な優等生が、
これ見よがしに作った自社製フレームワーク(全然便利ではない)しか
見たことないわ

作ったのは一流大卒の大手ベンダーの開発推進チームなんだが、
日本人ってその程度だと思うよ

Stringクラスって便利ー!ぐらいのほうが幸せになれるぞ

734デフォルトの名無しさん2018/10/10(水) 12:30:14.49ID:AVL6Qil2
中途半端な優等生の成果物がその程度なんだから、
三流大卒のおまいらの成果物なんて推して知るべくだよな

735デフォルトの名無しさん2018/10/10(水) 12:35:08.25ID:Vh7YHzSV
べつに透かさんでも直接見えるやろw変なやつw

736デフォルトの名無しさん2018/10/10(水) 12:49:50.06ID:2nqQsSqL
>>726
でもprivateだとわからないよね

737デフォルトの名無しさん2018/10/10(水) 13:52:34.56ID:VeUMq7t7
プログラミングセンスと学力ランキングは比例しないんだよなぁ

738デフォルトの名無しさん2018/10/10(水) 13:57:58.08ID:VeUMq7t7
むしろ個人の性格の方がそのまんま実装に現れて来るからな。

739デフォルトの名無しさん2018/10/10(水) 14:27:07.52ID:DTkCRDr0
学力ランキングを批判するだけなら良いぞ
だが、学力の対案は性格っていうのがダメだ
おかしな対案を出すより何も出さない方がマシ

740デフォルトの名無しさん2018/10/10(水) 17:10:39.36ID:az2ldVPt
>>736
分かる必要がないよね。

どうせ関数型だって内部メモリの構造なんてわからないんだから

741デフォルトの名無しさん2018/10/10(水) 17:55:56.61ID:DTc0bT+8
>>733
大手企業のフレームワークは派遣さんがアホなことをしないようにあえて機能を制限してる
生産性が多少犠牲になっても非常識な派遣さんがやらかしてしまうリスクを減らすことが重要と考えたんだね
そういう意味ではオブジェクト指向の基本であるカプセル化は非常に役に立っていると言える

742デフォルトの名無しさん2018/10/10(水) 18:01:10.70ID:az2ldVPt
>>741
なら派遣を使うことがリスクなのでそれをやめればいいと思います。

本当のリスクは・・・無理なコスト削減なのでは?
コスト削減のために、無駄なコストをかける。

うーん、馬鹿なのでしょうね

743デフォルトの名無しさん2018/10/10(水) 18:25:41.34ID:crjMMeGj
既存のフレームワークにケチつけたい人は
それ以上のものを作れる人なの?
それとも、作れないし作ったことも無いけどケチつけたい人なの?

煽りじゃなくて純粋な疑問
ぜひ、小学生のような瞳をしてそっと教えて欲しい

744デフォルトの名無しさん2018/10/10(水) 19:14:20.95ID:DTkCRDr0
それを教えないのが正義っていうのが情報隠蔽、カプセル化

745デフォルトの名無しさん2018/10/10(水) 19:28:47.64ID:AZXT33MT
ママ役は薄幸そうな石田ゆり子かな

異論は認める

746デフォルトの名無しさん2018/10/10(水) 19:29:51.69ID:AZXT33MT
すまん、誤爆だ

747デフォルトの名無しさん2018/10/10(水) 20:28:30.09ID:DTc0bT+8
>>742
派遣さんを切ったら中抜きで稼いでる人達が困る
派遣さんは使う、でもバカな真似はやらせたくない
このバランスが大事

748デフォルトの名無しさん2018/10/10(水) 20:31:47.32ID:1d6HAJSZ
最近は中抜きはまだまともな行為だと思えてきた。
バカがクソみたいな意見押し通してくるよりマシだ。
そういう意味でベイシックインカム賛成。

749デフォルトの名無しさん2018/10/10(水) 20:32:00.42ID:az2ldVPt
>>747
結局、中抜きで困るからっていうのが本当の理由なのね(笑)

750デフォルトの名無しさん2018/10/10(水) 21:57:06.99ID:YM9RoEIA
>>740
え?グローバル変数使わなければ戻り値か引数が全てだけど?

751デフォルトの名無しさん2018/10/10(水) 22:09:31.63ID:crjMMeGj
>>750
つ[クロージャ]

752デフォルトの名無しさん2018/10/11(木) 06:25:53.98ID:o+Pj5MkJ
有識者、燃料投下ヨロ

くだらなくてつまんない

753デフォルトの名無しさん2018/10/11(木) 17:52:18.63ID:lqVwZR/7
んじゃクロージャ出たから

オブジェクト指向で末端の人、要は上の誰かが作った仕組みやクラス使って自分はそこからオブジェクト弄るだけの人は可能な限りクロージャ使いまくった方がと思うんだよな
よく委譲処理でこのふたつどちらか選ぶ事あると思うんだが末端なら即クロージャ

754デフォルトの名無しさん2018/10/11(木) 19:53:44.01ID:hrM+9Jlq
>>714
仕事は範囲が限られているからね
その仕事でやらなければならない範囲だけ出来れば
後は何が出来ようが出来まいが関係なくなるからね
一言で言えば視野が狭い
横文字を多用する人は狭い世界で通じてそれでokになっちゃってる
多種ではないし世界が兎に角狭い
実際ゲームなんかでは敵クラスを作って敵が増えるたびにオブジェクトを生成する
ってやると感覚的に凄く簡単

755デフォルトの名無しさん2018/10/11(木) 20:31:48.13ID:m9vsKwrk
>>752
どんな話題が面白いの?
このスレ的にはオブジェクト指向のメリットが説明できなければ
終わりなんだけど

756デフォルトの名無しさん2018/10/11(木) 20:34:12.11ID:U1kKB/4M
逆でしょ?説明されれば終わりなのがいやだから
答えが出てるのに、同じことをくり返し聞く

757デフォルトの名無しさん2018/10/11(木) 20:38:52.62ID:m9vsKwrk
>>756
え?メリット出てる?
見たことないよ
毎回、バカが長文書くだけで
品質向上なのか工数削減なのか、それが起こるロジックが全くの謎

758デフォルトの名無しさん2018/10/11(木) 21:05:36.68ID:o+Pj5MkJ
犬がワン、猫がニャン
→なにそれ美味しいの?

大規模じゃないとメリット説明しにくいよ
→説明できないって、大規模なプログラムを経験して体で覚えろと?

要するに、簡単には説明できないよ
→だったら学習コストとの天秤では?

俺の中ではこんな感じ

759デフォルトの名無しさん2018/10/11(木) 21:06:47.80ID:U1kKB/4M
品質向上だし工数削減にもなる

馬鹿はそこでなぜか品質向上と工数削減のために
追加作業が増えるとダメだと話を聞かない

760デフォルトの名無しさん2018/10/11(木) 21:07:43.81ID:o+Pj5MkJ
ちな俺、初心者プログラマだけど宮廷文系

761デフォルトの名無しさん2018/10/11(木) 21:48:27.62ID:29n02hV2
いわゆる土方候補生か

762デフォルトの名無しさん2018/10/11(木) 22:35:19.32ID:FTrPBrPb
>>753
関数ポインタと汎用のvoidポインタ渡すインターフェイスより明らかに良いとは思うけど、
ガベコレない言語では上手くいかんだろ。
その場合は継承させるしかないっていうc++の選択は間違いじゃない。

763デフォルトの名無しさん2018/10/12(金) 00:40:23.27ID:U1NbXGxJ
>>762
そういう欠点解消するため、
結構前に拡張されたのに何で勉強しないのかねOOP厨はホントにもう
https://cpprefjp.github.io/lang/cpp11/lambda_expressions.html

764デフォルトの名無しさん2018/10/12(金) 00:47:17.48ID:U1NbXGxJ
オレぐらいのレベルでないと
オブジェクト指向は使いこなせない

765デフォルトの名無しさん2018/10/12(金) 00:47:48.97ID:U1NbXGxJ
だいたいわかる

低学歴知恵遅れが
ムダにオブジェクト指向あげしてる

766デフォルトの名無しさん2018/10/12(金) 00:48:51.77ID:mmIXjKhu
メリットの挙げられない技術を採用するな

767デフォルトの名無しさん2018/10/12(金) 07:03:34.63ID:ogDn0rIL
>>762
全く解消されてないだろ。。
キャプチャーしてる変数の寿命を考慮してなきゃならんし、こんなん使わねーわ。

768デフォルトの名無しさん2018/10/12(金) 08:23:50.28ID:8+F5vpV5
型の問題と寿命の問題を分離しない
OSとGUIを分離しない
フルスタックな環境を作る密結合指向って感じ

769デフォルトの名無しさん2018/10/12(金) 10:20:48.35ID:4mK9L0RW
>>768
それただの設計の問題じゃね?

770デフォルトの名無しさん2018/10/12(金) 11:04:22.00ID:8+F5vpV5
>>769
その設計にオブジェクト指向が関与していると疑われている
その問題の解決にオブジェクト指向は全く寄与しない、と宣言すれば疑いは晴れる

771デフォルトの名無しさん2018/10/12(金) 11:12:44.85ID:4mK9L0RW
>>770
いや、どう見ても設計の機能分けの問題
オブジェクト指向の前にレイヤーってあんだろ?

772デフォルトの名無しさん2018/10/12(金) 17:19:28.65ID:5jm0P0/q
オブジェクト指向信者もDI信者も同じ臭いがするね

【Java】DIコンテナって本当に便利か?
http://mevius.5ch.net/test/read.cgi/tech/1219242206/

次は何を担ぐのやら


外国で流行って育っていくのだから、それなりのメリットはあるんだろうけど、なぜか仕事では恩恵にあずかったことはない

773デフォルトの名無しさん2018/10/12(金) 20:33:03.38ID:4mK9L0RW
設計のセンスの無い奴はどんな流行が来たって糞な設計しか出来ないんだよなぁ
センスがある奴はなんとなくどんな流行のスタイルでもこなして来るからなぁ

774デフォルトの名無しさん2018/10/12(金) 20:41:34.47ID:CecLyO81
どーでもいーけどコーディングの事設計てゆーのいーかげん恥ずかしくね?w

775デフォルトの名無しさん2018/10/12(金) 20:45:43.93ID:4mK9L0RW
は?
設計はコーディングじゃねーよw
四角い箱描いて矢印や電線で繋げて遊ぶ奴だぞ。

776デフォルトの名無しさん2018/10/12(金) 20:45:57.27ID:SyXP90mj
ある一定以下に対して理解できるような教範が出てこない
だから一部の人しか使えないようになってる
結局は出来る人の間で持て囃されるだけになってしまう
この何か新しいやり方を創造するのと一般に使えるようにする
というのは本来両輪なんだけど
普通以下の人達が使えるようになる教範を作る
というのはかなり難しい上に
それをやる人には余りメリットがないから
なかなか出てこない
だから
オブジェクト指向プログラミングにしても
関数型プログラミングにしてもその他の技術にしても
広く(普通程度以下)使われるのは難しいし
このスレのタイトルみたいな感想を持つしかなくなる
後は自分が出来るけど他の人が出来ないままのほうが出来る人には得だから妨害する
みたいなのが居るくらいだろうかねぇ

777デフォルトの名無しさん2018/10/12(金) 20:48:39.65ID:4mK9L0RW
あー電線繋げては遊ばないわ、危ないしw
点線の間違いだわ。

778デフォルトの名無しさん2018/10/12(金) 21:12:49.59ID:CecLyO81
ガチでわかっとらん奴やったw

779デフォルトの名無しさん2018/10/12(金) 21:17:29.38ID:mCoAwEvP
>>772
DIはほんと便利
めちゃくちゃ開発が楽になった

780デフォルトの名無しさん2018/10/12(金) 21:21:05.43ID:xVyRtSc0
少なくともこのスレにいるような低学歴知恵遅れのドカタには
オブジェクト指向言語を適切に使いこなせない

781デフォルトの名無しさん2018/10/12(金) 21:27:17.84ID:d1sPni1g
少なくともこのスレにいるような低学歴知恵遅れのドカタには
オブジェクト指向言語を適切に使いこなせない

782デフォルトの名無しさん2018/10/12(金) 22:41:19.80ID:F7y/wInK
>>772
テストしたことないのかい?

783デフォルトの名無しさん2018/10/12(金) 23:12:30.21ID:xVyRtSc0
日銀短観のDIは便利
池沼あげのDIはtraitsなみにウンコくさい

784デフォルトの名無しさん2018/10/13(土) 10:26:58.14ID:YNebL+WU
今時DIも使いこなせない人材とか組織にとってのリスクでしか無いよ
あっちこっち結合しまくったクソコードを社内リポジトリにばらまくとか悪夢そのものじゃん

785デフォルトの名無しさん2018/10/13(土) 10:58:13.65ID:H4Y+M12v
DI使っても結合しまくったくそコードはくそのままだ
業務分析の時点でコケて役割分担がぐちゃぐちゃなんだからDI導入したって解決しない

786デフォルトの名無しさん2018/10/13(土) 21:25:17.45ID:YNebL+WU
>>785
DIを使わないから業務分析の時点でコケて役割分担がぐちゃぐちゃになるのでは?
設計者にDIを学習させてDIを使う前提で設計させればそのあたりの分担がキレイになるように意識して設計するようになるよ

787デフォルトの名無しさん2018/10/13(土) 22:13:29.66ID:An0DfPZD
>>786
それで成功した例なんてあんの?

788デフォルトの名無しさん2018/10/13(土) 22:15:51.44ID:L3Dj2/gz
cのたくさんの構造体にいっぱい変数や関数ポインタもたせて
それ入力にして処理するのと同じ

789デフォルトの名無しさん2018/10/13(土) 22:29:25.59ID:HA3RUpZg
DIはたしかにきれいな設計になるが、めんどくて工数がかかる。
作業者にはYAGNIのほうが優先度高いから勝手に採用できない

だからそういうのはトップエンジニアが最初に管理方針としてきめとくもんだ
末端のプログラマーに責任押し付けるのは酷

790デフォルトの名無しさん2018/10/13(土) 22:38:19.49ID:HA3RUpZg
今のDIはめんどすぎる
既存コードをいじらないで中身をすげかえる
もっと楽な方法はないものか

791デフォルトの名無しさん2018/10/13(土) 22:42:51.86ID:An0DfPZD
DIは言語自体に組み込まれるべきもの
高級言語はどんどん高級になるべきだが
ガベコレ搭載あたりで停滞してしまったからね

本来はDIやデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない

792デフォルトの名無しさん2018/10/13(土) 22:44:08.09ID:L3Dj2/gz
インターフェースを決め打ちにしたテンプレート作る間抜けな作りと
大してかわらないからな

793デフォルトの名無しさん2018/10/13(土) 22:48:54.83ID:c+yfSqJ1
使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい

794デフォルトの名無しさん2018/10/13(土) 22:54:18.52ID:An0DfPZD
逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。

795デフォルトの名無しさん2018/10/13(土) 22:59:41.42ID:c+yfSqJ1
>>794
もちろんそうだろ

796デフォルトの名無しさん2018/10/13(土) 23:21:29.03ID:An0DfPZD
>>795
あ、そうだって認めたねw

つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ

797デフォルトの名無しさん2018/10/13(土) 23:38:37.37ID:L3Dj2/gz
クソが余計なことをして
余計にクソなコードを生産するサイクルが途絶えることはない

798デフォルトの名無しさん2018/10/13(土) 23:45:30.90ID:An0DfPZD
SEが余計なことをして
クソコードを量産することになるのは
よくある話だな

799デフォルトの名無しさん2018/10/14(日) 11:01:28.22ID:RzJcTIeH
DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな

800デフォルトの名無しさん2018/10/14(日) 12:27:39.55ID:mBxOrkWE
え?どんなコードが入るの?
ありえないのに

801デフォルトの名無しさん2018/10/15(月) 20:24:46.22ID:vo4hBZ/w
なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの?
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。

802デフォルトの名無しさん2018/10/15(月) 20:30:03.66ID:1WHouwEf
ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった

803デフォルトの名無しさん2018/10/15(月) 21:16:54.08ID:E6pr56BO
 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

804デフォルトの名無しさん2018/10/16(火) 03:09:47.94ID:ou8fzFot
この記事拍手の数すげぇな。まだ伸び続けてる
Goodbye, Object Oriented Programming
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53

805デフォルトの名無しさん2018/10/16(火) 07:54:43.79ID:Z3LiiLXa
誰か和訳してよ

806デフォルトの名無しさん2018/10/16(火) 07:57:35.98ID:Z3LiiLXa
オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね

807デフォルトの名無しさん2018/10/16(火) 08:20:25.22ID:Jp8CUHhN
Banana Monkey Jungle Solution

まで読んだ

808デフォルトの名無しさん2018/10/16(火) 09:47:48.81ID:hiAtkD1Q
Elm最高まで読んだ

809デフォルトの名無しさん2018/10/16(火) 10:44:44.96ID:KsONw+2K
結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ

810デフォルトの名無しさん2018/10/16(火) 10:49:18.08ID:hiAtkD1Q
現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ

811デフォルトの名無しさん2018/10/16(火) 11:00:52.85ID:sVO7hlJ7
アクセス修飾子について分かりやすい説明しているサイトない?
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか

812デフォルトの名無しさん2018/10/16(火) 11:06:30.91ID:HqnwAz6t
>>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる

813デフォルトの名無しさん2018/10/16(火) 11:07:25.98ID:HqnwAz6t
ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない

814デフォルトの名無しさん2018/10/16(火) 11:39:32.23ID:8J+M5yKD
あとから処理をフックできるぞ!

815デフォルトの名無しさん2018/10/16(火) 11:40:12.83ID:Ul6KAhVk
setget時にログ出したいときに一括でできるぐらいか?

816デフォルトの名無しさん2018/10/16(火) 13:06:07.08ID:GbK/byr7
>>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ

多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい

817デフォルトの名無しさん2018/10/16(火) 13:22:26.52ID:sVO7hlJ7
>>816
色々サイトみてるけど不要論も結構あるんだよな

よくわからないけどありがとう

818デフォルトの名無しさん2018/10/16(火) 14:20:20.47ID:cFNbEHw0
言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね?

819デフォルトの名無しさん2018/10/16(火) 14:59:03.86ID:8J+M5yKD
それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔

820デフォルトの名無しさん2018/10/16(火) 15:33:44.68ID:pkWZobMJ
今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。

821デフォルトの名無しさん2018/10/16(火) 16:52:45.97ID:nQomBRvE
セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う

設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ

822デフォルトの名無しさん2018/10/16(火) 17:08:05.58ID:JHQMnpCL
>>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる

823デフォルトの名無しさん2018/10/16(火) 17:10:16.39ID:JHQMnpCL
>>821
> セットなんちゃらって書く場面を考えると

セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更

824デフォルトの名無しさん2018/10/16(火) 18:13:44.49ID:AosmVSTK
いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん

本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな

825デフォルトの名無しさん2018/10/16(火) 18:57:36.52ID:PnSVhV/K
言われたらそうだなw盲点だった

826デフォルトの名無しさん2018/10/16(火) 19:03:13.54ID:JHQMnpCL
そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ?

一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ

827デフォルトの名無しさん2018/10/16(火) 19:04:22.70ID:JHQMnpCL
>>825
盲点でも何でも無いよw

例えば、Configクラスであっても、いつの時点のConfigかわからんだろ?
一年前の設定がほしいかもしれない。

828デフォルトの名無しさん2018/10/16(火) 19:12:47.50ID:AosmVSTK
>>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどc#は引数を渡せない

829デフォルトの名無しさん2018/10/16(火) 19:22:26.29ID:AzP++FB2
状態状態ってよく悪者にされるけどOOPの肝はのへんににあると思う
#include <iostream>
struct logger {
std::ostream *out;
logger() : out(0) {}
void p(const char *s) {
if (out) *out << s << std::endl;
}
};
void f(logger &l) {
l.p("foo");
l.p("bar");
}
int main() {
logger g;
f(g);
g.out = &std::cout;
f(g);
g.out = &std::cerr;
f(g);
return 0;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと?

830デフォルトの名無しさん2018/10/16(火) 19:24:41.24ID:GbK/byr7
Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw

831デフォルトの名無しさん2018/10/16(火) 19:26:14.38ID:OiVT6sa2
読み取りのプロパティは冪等であるべきじゃないの?

832デフォルトの名無しさん2018/10/16(火) 19:27:08.86ID:JHQMnpCL
Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。

つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話

833デフォルトの名無しさん2018/10/16(火) 19:30:01.71ID:GbK/byr7
>>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう

834デフォルトの名無しさん2018/10/16(火) 19:33:44.42ID:JHQMnpCL
>>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる

835デフォルトの名無しさん2018/10/16(火) 19:34:54.98ID:AosmVSTK
話がずれてる
本質が理解されてないらしい

836デフォルトの名無しさん2018/10/16(火) 19:35:57.94ID:JHQMnpCL
本質は>>832に書いたとおり

> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話

837デフォルトの名無しさん2018/10/16(火) 19:37:46.55ID:AosmVSTK
誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない

ロジックが散らばるのはよくないからクラスが持つべきではないかと思う

838デフォルトの名無しさん2018/10/16(火) 19:38:15.60ID:eMqRZshQ
大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。

一昔前のオブジェクト指向設計が売りの会社たちは、
オナニー会社として、まるで奮わなかったもんな

やっぱ適正レベルってもんが大事だよね

839デフォルトの名無しさん2018/10/16(火) 19:40:14.57ID:GbK/byr7
>>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは

840デフォルトの名無しさん2018/10/16(火) 19:41:53.17ID:eMqRZshQ
C++はベターCとして、文字列いじるときとか楽できればいいんじゃね?

でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの

841デフォルトの名無しさん2018/10/16(火) 19:43:35.70ID:AosmVSTK
>>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない

誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる

842デフォルトの名無しさん2018/10/16(火) 19:43:50.71ID:eMqRZshQ
だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね

843デフォルトの名無しさん2018/10/16(火) 19:46:28.35ID:JHQMnpCL
つーか簡単だろ?

日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する

Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする


テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要(すでにやってる)
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい


特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい

844デフォルトの名無しさん2018/10/16(火) 19:47:01.66ID:JHQMnpCL
>>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない

理由ぐらい書けよな

845デフォルトの名無しさん2018/10/16(火) 19:47:46.46ID:JHQMnpCL
dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな

846デフォルトの名無しさん2018/10/16(火) 19:47:59.81ID:GbK/byr7
>>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ

847デフォルトの名無しさん2018/10/16(火) 19:48:53.47ID:tUmXldvA
>>843
じーちゃん132歳とか出るパターンじゃね?

848デフォルトの名無しさん2018/10/16(火) 19:49:01.40ID:JHQMnpCL
国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなw

849デフォルトの名無しさん2018/10/16(火) 19:54:14.32ID:nQomBRvE
みんな賢いねぇ

850デフォルトの名無しさん2018/10/16(火) 20:36:04.05ID:83dvK2wh
俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う

851デフォルトの名無しさん2018/10/16(火) 20:39:51.39ID:+sj1AQoJ
普通に考えたら person と基準日を表すオブジェクトから年齢を返す関数を作るってことになると思うんだが。

852デフォルトの名無しさん2018/10/16(火) 20:42:25.71ID:H029zngb
>>850
定義もわからんもの作んなカスwwww

853デフォルトの名無しさん2018/10/16(火) 21:14:56.44ID:83dvK2wh
>>852
定義がわからんからオブジェクト指向やろう
というか俺はプロパティで済ますわ

854デフォルトの名無しさん2018/10/16(火) 22:05:40.03ID:t+SGPyRj
もうメンバー変数とメンバー関数が混在するクラスは作るな
関数しかないinterfaceで十分
関数が一つしかないならlambdaでいい

855デフォルトの名無しさん2018/10/16(火) 22:35:26.96ID:uJDDS3c2
それ、区別する必要あるの?

856デフォルトの名無しさん2018/10/16(火) 22:42:29.73ID:H029zngb
正直必要かどうかはわからない
ただおまえが欲しい
だめか?それだけじゃ?

857デフォルトの名無しさん2018/10/16(火) 22:45:36.90ID:VMcjBADQ
その低学歴知恵遅れが作ったメソッドは
うるう年考慮してなさそうで変なバグが入ってそうだわ

2000年10月20日生まれなら
普通にintで
(20181016-20001020)/1000
でしまいだからな

858デフォルトの名無しさん2018/10/16(火) 22:48:30.57ID:VMcjBADQ
そもそも常識的に
特殊なケースを除いて日付の引き算で
経過年数がかえってくるという発想はないからな

経過日数はあったとしてもな

859デフォルトの名無しさん2018/10/16(火) 22:52:46.85ID:VMcjBADQ
(20181016-20001020)/10000
こうだな
危ない。。。

860デフォルトの名無しさん2018/10/16(火) 22:54:43.61ID:VMcjBADQ
このとおり、
やっぱりな低学歴知恵遅れが
オブジェクト指向にふれるのは危険

オレぐらいのレベルがないとムリ

861デフォルトの名無しさん2018/10/16(火) 23:02:22.64ID:+0KL0EUx
俺の周りじゃあ
バカほど大喜びで使っているよ

862デフォルトの名無しさん2018/10/17(水) 08:20:36.48ID:K4tsdk4L
>>832
勝手に変わるか、と言う意味では、生年月日は不変だけど、年齢は変わるんでは?

>>833
なるほど。そもそもそれはプロパティとは言ってなかったんだな。
それはおっしゃるとおり、関数にすべきだと思う。

863デフォルトの名無しさん2018/10/17(水) 08:22:14.61ID:K4tsdk4L
>>857
年齢はその前日の満了を持って加算される、のルールで抜けるパターンがあるんじゃね?
半角さんは間抜けなの?

864デフォルトの名無しさん2018/10/17(水) 09:03:37.20ID:Vm5CNq+z
半角さんを怒らせたら低学歴知恵遅れにされちゃうよ

865デフォルトの名無しさん2018/10/17(水) 09:56:27.08ID:18gBK5Xa
大抵の場合、正しく理解せずに中途半端な実装してる案件にぶち当たって嫌な思いした奴がここに集うんだろ?

866デフォルトの名無しさん2018/10/17(水) 10:09:33.91ID:nljGc94P
実装レベルの議論してるやつと設計レベルの議論してるやつ
さらにもーちょい上から俯瞰して物を言ってるやつ
全部ごちゃ混ぜになってて面白いね

867デフォルトの名無しさん2018/10/17(水) 12:01:54.30ID:vk6wOayh
自分はプログラムの観点からだけで話してる
上にあった英語の奴もプログラムが主だったなぁ
設計は知らない
話題をスレで分けた方が良いのかねぇ?

868デフォルトの名無しさん2018/10/17(水) 12:20:31.30ID:BZlH8+Xm
設計レベルの話とかでとらんけどw

869デフォルトの名無しさん2018/10/17(水) 14:05:39.44ID:K4tsdk4L
やっぱ平年の3/1に、うるう年の2/29に生まれた人の年齢が狂うな。
しかしこういう知ったかぶりが、ひどいバグを生んで改修大変になる。
と言うか、これを保存時にやられるとデータ修正ものなので、場合によっては偉いさんが頭下げに行って、出世の道が遠のくパターン。

870デフォルトの名無しさん2018/10/17(水) 14:07:46.09ID:18gBK5Xa
設計って、機能ごとに必要な処理をリストアップしたら、そのまんまオブジェクト指向なんじゃね?

871デフォルトの名無しさん2018/10/17(水) 15:04:16.60ID:fcCyZegY
「誕生日の前日が終了する瞬間(すなわち誕生日をむかえる午前0時00分の直前)
に1歳を加えることになる」の部分の解釈には
前日に1日加えると解釈される場合と
当日に1日加えると解釈される場合の2種類がある

872デフォルトの名無しさん2018/10/17(水) 15:32:27.26ID:lTftiJN1
2/29日生まれの人は4でわらないとね

873デフォルトの名無しさん2018/10/17(水) 16:00:02.67ID:K4tsdk4L
>>871
一番問題になる学教法にならうべきじゃないんかな。
前日に歳を取る、ただし前日の24:00を使用する。表記や概念的には、って感じで。
だから、4/1生まれは4/2生まれと学年が違う。4/1生まれは、3月中に歳をとってるから。

874デフォルトの名無しさん2018/10/17(水) 16:02:31.73ID:aR4OF1u3
誕生から1年経過することに1つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。

875デフォルトの名無しさん2018/10/17(水) 16:08:03.45ID:DrCNXevb
学校教育法17条 「保護者は、子の満六歳に達した日の翌日以後における最初の学年の初めから・・・」

876デフォルトの名無しさん2018/10/17(水) 16:09:22.06ID:t+3zMNmx
年齢の扱いをどうするかは法律で強制されているわけじゃないので
システムによって異なってもOK

だからどういう実装でも公平な実装であれば問題ないといえる。
例えば20歳おめでとうキャンペーンで、20歳になっていなくても
その月に20歳の誕生日を迎える人を対象にしても良いわけだ

だから何が正解かを議論することに意味はない

仕事の話をするなら
年齢の計算はどうしましょうか?と客に仕様を聞くべきか
年齢の計算はこのようにしますがよろしいですか?と客に仕様の確認するべきか?
そういったことを考えたほうが良い

877デフォルトの名無しさん2018/10/17(水) 16:10:12.75ID:t+3zMNmx
ふ、無能共にマジレスしてしまったぜw

878デフォルトの名無しさん2018/10/17(水) 16:11:46.81ID:4yuTjZOF
式の間違い云々よりも、皆ageはただの例示であることは前提とした上でOOPでどう表現するかの話をしてたのに
いきなり実装に踏み込んでくる思考が謎い

879デフォルトの名無しさん2018/10/17(水) 16:15:47.15ID:DrCNXevb
Personインスタンスのageのゲッターで計算しとく。
Personインスタンスが無い時にも年齢の計算が必要になったら、クラスメソッドにしてPersonのゲッター内部から使う

880デフォルトの名無しさん2018/10/17(水) 16:18:57.58ID:t+3zMNmx
プロパティが優れているのは
ageのように、

年齢?そんなものオブジェクトのフィールドにしておけばいいだろ?
え?生年月日から計算するようにしたい?
なら、そのフィールドをプロパティにして計算して返すだけだな

とクラスのインターフェースを変えることなく
実装を関数に変更できるところにある

881デフォルトの名無しさん2018/10/17(水) 16:32:11.49ID:DrCNXevb
年齢じゃなくてBMI値の計算にしようぜ

882デフォルトの名無しさん2018/10/17(水) 16:33:10.53ID:t+3zMNmx
>>881
俺もこれ見たよ

肥満の指標・BMIは営利目的で生まれたもので医学的根拠がない?「何を信じれば」と驚愕の声や「そやろな」と納得の声など #初耳学
https://togetter.com/li/1275152

883デフォルトの名無しさん2018/10/17(水) 16:48:54.97ID:DrCNXevb
>>882
いやw年齢だとシンプルすぎるかなと思っただけw

884デフォルトの名無しさん2018/10/17(水) 16:59:07.49ID:cz0N+1z5
>>882
マジかよ保険会社最低だな
バレンタイン広めた菓子会社と同じくらい最低

885デフォルトの名無しさん2018/10/17(水) 17:15:22.09ID:K4tsdk4L
>>876
まあ、わかってて公平な実装と、それで良いと思ってるけど漏れがある実装は、仕様と不具合と大きく異なるけどね。

>>878
ほんといつも、半角さんがでしゃばった上に間違うからこんな事になる。

でもAgeはオブジェクトのプロパティとしては俺はおかしいと思うよ。
環境によって刻々と変わったり、恣意的に変えられる値は、オブジェクトとオブジェクトの演算で出るべきだと思う。
環境オブジェクトなり、指定時刻オブジェクトなりの、時刻を表すオブジェクトと、Personを組み合わせて、初めてAgeが出るんだし。
Personを含む生年月日があるオブジェクト.ageAt(時刻オブジェクト point)で年齢オブジェクトが出るなら理解できる。

886デフォルトの名無しさん2018/10/17(水) 18:34:11.00ID:K4tsdk4L
言い換えると、オブジェクトのプロパティはそのオブジェクトだけで表現可能なものに縛ったほうが良いと思う。

887デフォルトの名無しさん2018/10/17(水) 18:41:50.33ID:JdG8Y6gT
誕生日はプロパティにしてもよく、年齢は日付けに依存するから関数か

888デフォルトの名無しさん2018/10/17(水) 18:58:38.46ID:DrCNXevb
特定の日時の年齢が必要になったら
getAgeからgetAgeAt呼べばいいだけやん
言語によっていろいろやり方あるけどね
getAgeAt(Date.Today)しか書かれてないプログラムとかマヌケじゃん

既存クラスにメソッド追加できる言語なら
最終的にはDateにyears_between何ちゃら書く事になりそうだが

889デフォルトの名無しさん2018/10/17(水) 19:05:52.01ID:MwWLHD/k
それで言ったらPersonオブジェクトがどういう扱いなのかによってもAgeがプロパティか関数か違いそうだな。
データベース的な一回表示するだけだったら関数でも良いけど、ゲームやSNSのアバター的なのだったら、ステータス表示するたびに計算してたら無駄が多い。
誕生日イベントでもない限り1日くらいは1歳違う程度は許容されるなら、オブジェクト作成時(ログイン時)に計算して結果をAgeに入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか?
モバイルゲームとかなら尚更。

890デフォルトの名無しさん2018/10/17(水) 19:07:22.09ID:pcmrmHBT
お前らQiitaでも喧嘩してんのかよwwwww

891デフォルトの名無しさん2018/10/17(水) 19:21:58.46ID:QBZICbug
くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ

892デフォルトの名無しさん2018/10/17(水) 19:41:36.97ID:lTftiJN1
バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな

893デフォルトの名無しさん2018/10/17(水) 19:45:33.46ID:e5Vejsh/
プログラミング系の文章は長いのが多いw
Qiitaも無駄に長いし

894デフォルトの名無しさん2018/10/17(水) 19:48:24.97ID:MwWLHD/k
そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。

895デフォルトの名無しさん2018/10/17(水) 19:49:12.51ID:PbHb58aB
保守性、生産性なんてどーでもいいみたいだなw

896デフォルトの名無しさん2018/10/17(水) 20:48:03.60ID:SmhZ3W9+
保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない

897デフォルトの名無しさん2018/10/17(水) 21:11:18.05ID:MCL000/y
>>893
いわゆる職業病だな

898デフォルトの名無しさん2018/10/17(水) 21:15:15.43ID:t+3zMNmx
言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに

899デフォルトの名無しさん2018/10/17(水) 21:29:59.95ID:MCL000/y

900デフォルトの名無しさん2018/10/17(水) 22:12:39.18ID:Ny9Q/0jK
低学歴知恵遅れは日付クラスにそんな頭悪いコードを入れると書いてるからな
>>843 ← このとおり

901デフォルトの名無しさん2018/10/17(水) 22:16:19.44ID:Ny9Q/0jK
普通に考えてな
日付クラスにそんな頭悪いコードなんかいれない

低学歴知恵遅れはいろんなもんに利用する日付クラスに
年齢求めるコードをいれると書いてる

低学歴知恵遅れがクラスを設計()すると
こういうバカな作りになるという典型的な例といっていい

この板にいるような低学歴知恵遅れにはやっぱりな
オブジェクト指向なんかムリ

902デフォルトの名無しさん2018/10/17(水) 22:18:11.61ID:vodxAkHQ
>>891
契約時年齢だって

903デフォルトの名無しさん2018/10/17(水) 22:21:21.35ID:Ny9Q/0jK
ただの起算日の違いの問題だからな
計算方法はかわらない

そもそも日付クラス()なんかやるようなもんじゃない

904デフォルトの名無しさん2018/10/17(水) 22:26:45.89ID:Ny9Q/0jK
ともかくあきれるぐらい頭が悪い

905デフォルトの名無しさん2018/10/17(水) 22:29:57.57ID:t+3zMNmx
>>901
日付クラスに入れるのは、年の差を計算するロジックやで?
日付同士の差を求める演算。結果の年だけを取得する

誰が年齢の差のはなししてるんだよw

906デフォルトの名無しさん2018/10/17(水) 22:30:36.34ID:MwWLHD/k
確かになー。。。
と言うか、大抵のフレームワークに日付クラスがあるのに、わざわざ改造して年齢計算メソッド付けるって発想が浮かばない。
普通はPersonに付けるだろうし、スマホゲームとかならクライアントに計算させてバッテリー減り過ぎも困るから、場合によっては鯖側に管理クラス作ってそっちに付ける。

907デフォルトの名無しさん2018/10/17(水) 22:30:39.23ID:Ny9Q/0jK
ホント頭悪いわ

908デフォルトの名無しさん2018/10/17(水) 22:35:00.27ID:SmhZ3W9+
アタマが悪いと短いレスすら誤解して読んでしまうらしい
ほんとかな?

909デフォルトの名無しさん2018/10/17(水) 22:35:22.24ID:t+3zMNmx
>>906
日付クラスに入れるのは日付の計算(もちろんすでに入ってるのならそれを使う)
年齢はPersonクラス、仕様が一致してるなら日付クラスのメソッドを呼ぶだけでいい

日付の計算と年齢の計算は(仮にロジックが一致していたとしても)別物
そういうことを考えるのが抽象化

910デフォルトの名無しさん2018/10/17(水) 22:54:19.67ID:MwWLHD/k
>>909
入ってるのは今の所見たことないけど、メソッドにする程か?
日付クラス同士の足し算引き算出来るはずで、年数計算って結局ただの引き算やぞ。

別に駄目とは言わんが、Ageメソッド内で「今日の日付−生年月日」するのと、「日付クラス.年数計算(今日の日付,生年月日)」するのと手間は同じ。
むしろ長くなる。

911デフォルトの名無しさん2018/10/17(水) 23:03:02.79ID:4yuTjZOF
operator - が日付クラス内で定義されてる例なんていっぱいあるでしょ

912デフォルトの名無しさん2018/10/17(水) 23:05:08.82ID:t+3zMNmx
>>910
Personクラスの属性にしていれば、
内部の実装が変わってもインターフェースを
変えなくてすむんだよ。

それにオブジェクト指向の特徴だが人間のメンタルモデルに近いから
理解しやすい。例えば「あなたの年齢は?」みたいに聞くだろう?
年齢を知りたいときに、あなたの生年月日は?って聞いてからわざわざ計算しないだろ?

"あなた"が知っていることは、"あなた"に問い合わせればよい。
というのが人間にとって一番理解しやすいんだよ

913デフォルトの名無しさん2018/10/17(水) 23:05:26.01ID:Ny9Q/0jK
日付クラスの - オペレーターで
経過日数ではなく経過年数を返す作りになるのか。。。

さすが低学歴知恵遅れがいうことは斬新だわ

914デフォルトの名無しさん2018/10/17(水) 23:07:02.95ID:Ny9Q/0jK
やっぱり低学歴知恵遅れって感じ
もうすぐに分かってしまう

まともな教育を受けてればでてここないような発想が
ポンポンでてくる

低学歴知恵遅れのレスってすぐにわかる
いちいち低学歴知恵遅れですと自白するからな。。。

915デフォルトの名無しさん2018/10/17(水) 23:09:12.35ID:t+3zMNmx
弱い犬ほど?

916デフォルトの名無しさん2018/10/17(水) 23:09:52.03ID:Ny9Q/0jK
バカはバカであることに気づけない
ホントになよくわかるわ

917デフォルトの名無しさん2018/10/17(水) 23:17:38.65ID:pcmrmHBT
関数型論者だったら「人」はDNAだけで表し、生まれた日、場所、その他その瞬間の宇宙の諸環境をすべて引数で与えて最後に経過時間も与えるのかな?
なんだ、関数型論者って決定論者だったんだな。

918デフォルトの名無しさん2018/10/17(水) 23:30:29.90ID:4yuTjZOF
>>910が日付の計算が日付クラスのメンバーになっているのを見たことがないと言っているので
それに対して俺は>>911で知らないうちに演算子オーバーロードの恩恵を受けているのではと言っているだけ

「今日の日付−生年月日」は日数で「日付クラス.年数計算」の「年数」とは一致しないが
そんな事は気にせずに単にdateの計算をどこに置くかの話をしているだけ
繰り返すが日付自体がただの例示だから、単位だの閏年だの細部を詰めることに意味はないと皆わかってる

そこから一人実装を始めたり短絡的にoperator -で年数を返すと変な結びつけ方をしたりして
自分が作り上げた架空の敵相手に憤ってしまうのがもうね

919デフォルトの名無しさん2018/10/17(水) 23:33:06.41ID:LhMTIXwM
>>917
それは関数型論者でなくて適切な抽象度が理解できないただの抽象馬鹿だろ。

920デフォルトの名無しさん2018/10/17(水) 23:48:24.78ID:MwWLHD/k
>>913
あれ?日付クラス(Date)の中にYaer、Man、Dayって年クラス、月クラス、日クラスって無かったっけ?
すまんね。
だいぶ離れてて、うろ覚え。

>>912
うん?
だからPersonクラスがAgeプロパティだかメソッド持つんだろ?
日付クラスだか時間クラスだかが年数計算メソッド持つ必要は無い。
時間はただ時間、日付はただ日付。
年齢もただ年齢ってのもある意味じゃ正しい。
システム上不都合なら管理クラスに計算させて、結果を受け取るだけでも良い。

オブジェクト指向は、必ずしも現実と同じ区分けでなくて良い。
責任分担をキッチリするための道具でしかない。
保守性に問題なければ、システムの特性に合わせてどちらが管理するのか決めれば良い。
(むしろ現実と離れることが多いから、あんまり現実だとこうだから〜とか、こだわり過ぎない方がいい)

921デフォルトの名無しさん2018/10/17(水) 23:55:39.80ID:RzUo3BE1
生年月日は、属性・インスタンス変数

年齢は、computed・算出プロパティ

922デフォルトの名無しさん2018/10/18(木) 00:04:29.24ID:/P5hGycw
Ruby で、年齢をクラス化したもの

誕生日から年齢を計算するhappybirthday gemをリリースしました
https://takanamito.hateblo.jp/entry/2018/05/15/091820

923デフォルトの名無しさん2018/10/18(木) 00:08:50.77ID:8YBQxCvu
るびぃ〜すとwwwww

924デフォルトの名無しさん2018/10/18(木) 00:19:48.94ID:qf9NxgCD
>>918
年齢計算や年数計算は大事な場所じゃ無かったし、言う通り日付クラスに年数計算メソッド付けるべき?が話題の中心だったと思う。


年齢計算や年数計算は
_______日付クラスA = 今日の日付 − 生年月日(または任意の年月日)
return 日付クラスA.Yaer

とかだった気がする。
うろ覚えだが。

925デフォルトの名無しさん2018/10/18(木) 00:25:14.97ID:855u7n6N
難しい物なんだから
話が長くなるのは当たり前
既に知っている事を話す以外だと
相手に解る様に話すのに分量が掛かる
当然だろう

926デフォルトの名無しさん2018/10/18(木) 00:35:20.72ID:/ofNkRJS
>>924
日付(年の差)計算と年齢計算をごっちゃにしてはいけない
日付クラスにつけるのは年の差計算処理
年齢の計算のことは考えてはいけない

Personクラスにつけるのは年齢プロパティ
中で日付クラスを使うかどうかは実装による

年齢計算の方法が複数あるというのなら、ストラテジーパターンを導入し
アルゴリズムを切り替えられるようにしておけばいいだろう
>>843で書いたことの繰り返しだがな

927デフォルトの名無しさん2018/10/18(木) 00:36:08.12ID:THsg9J3q
いや低学歴知恵遅れは
頭ワルイという病気

不治のヤマイ

928デフォルトの名無しさん2018/10/18(木) 00:38:55.28ID:/ofNkRJS
またワンワンって聞こえる

929デフォルトの名無しさん2018/10/18(木) 00:40:38.70ID:d31P7rqb
>>927
あなたのその病治らなくて大変ですね

930デフォルトの名無しさん2018/10/18(木) 00:56:35.59ID:qf9NxgCD
>>921
これ言うと元も子もないが、実際にはアカウント作る際に生年月日と年齢を別々に書かされる通り、計算なんて何処もしちゃいない。
気が付いたらユーザーが書き直してねって。

お勉強でもなけりゃ年齢計算はしない。
年計算用途の方が実践で使われてるかもね。

931デフォルトの名無しさん2018/10/18(木) 01:06:50.02ID:qf9NxgCD
>>926
うーん?
誕生日を生年月日にしただけで、同じ意見に見えるが。。。
閏年に誕生日が〜とかも含めるって事?
だから、実際のサイトじゃ年齢も入力させる形なのかね?

932デフォルトの名無しさん2018/10/18(木) 06:47:29.90ID:8rVApEa4
class Age {
public DateTime BirthDay { get; }
private DateTime Today { get; }
public int Years { get {
int b = BirthDay.Year * 10000 + BirthDay.Month * 100 + BirthDay.Day;
int t = Today.Year * 10000 + Today.Month * 100 + Today.Day;
return (t - b) / 10000; }}
public Age(DateTime b, DateTime t) { ...

class Person {
public DateTime BirthDay { get; set; }
private DateTime Today { get; set; }
public Age Age => new Age(BirthDay, Today);
public Person(DateTime b, DateTime t) { ...

933デフォルトの名無しさん2018/10/18(木) 08:12:51.70ID:0Dh4HQ87
>>912
その質問は暗黙に(今の)が入ってるんじゃない?

934デフォルトの名無しさん2018/10/18(木) 08:15:28.19ID:0Dh4HQ87
半角さんは設計スキルないんだからもう書き込むなよ。
実際間違った実装を想定して設計の話ししただろ?

935デフォルトの名無しさん2018/10/18(木) 08:19:16.70ID:0Dh4HQ87
>>930
電子カルテだとまあまず患者マスタに年齢は持たないよ。
いつ時点に、何歳か、って方が大事だから。
どのタイミングで年齢計算するかとなると、入院中に歳を取るパターンがあるので結局毎日計算するハメになる。

それこそ業務によると思うが。
ただ普通のウェブサイトでも、生年月日聞くところで年齢を聞かれる事はあんまり無いんじゃないかな。

936デフォルトの名無しさん2018/10/18(木) 08:45:54.88ID:qf9NxgCD
>>935
なるほど、カルテだったら閏年で何歳ってより、生物として生まれて何年目、的な意味合いの方が重要だし、有りかも。

年齢まで求める場所減ってるか知らないけど、情報的な価値は低いかもね。
統計的に扱うだろうから、生年月日で何年生まれか分かれば十分だし。

937デフォルトの名無しさん2018/10/18(木) 11:41:18.85ID:ia232fMX
手術した日から何年経ったか表示してと言われて裏で誕生日クラスが使われる

938デフォルトの名無しさん2018/10/18(木) 12:26:47.14ID:PmW8gRMT
>>891
>くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
>それが答えだ

これで解決する議論をぐだぐだとまあ…
何がしたいんだ?
年齢にまつわる宇宙の真理をクラス化したいのか?

939デフォルトの名無しさん2018/10/18(木) 12:45:03.88ID:0Dh4HQ87
>>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。

医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。

940デフォルトの名無しさん2018/10/18(木) 12:45:24.34ID:b1Fs59oz
日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。

941デフォルトの名無しさん2018/10/18(木) 13:23:27.88ID:b1Fs59oz
無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。

942デフォルトの名無しさん2018/10/18(木) 14:01:33.21ID:bqWuTIEf
だから業務共通クラスの1メソッドにしとくんだろ、普通

バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど

943デフォルトの名無しさん2018/10/18(木) 14:13:24.19ID:A+ZA0oir
クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。

944デフォルトの名無しさん2018/10/18(木) 14:59:01.57ID:6luTq9qj
>>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな

945デフォルトの名無しさん2018/10/18(木) 15:25:24.79ID:3douRw4T
Person.birthday.dateなの?

946デフォルトの名無しさん2018/10/18(木) 16:59:23.38ID:A+ZA0oir
2つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね?
変にクラス内に閉じ込めてもメリット無いと思うんだけど?
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。

947デフォルトの名無しさん2018/10/18(木) 17:52:04.62ID:/ofNkRJS
>>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう

Personクラスはどういう属性を持っているか?
それを考えるのが設計。実装のことは一旦忘れましょう

948デフォルトの名無しさん2018/10/18(木) 17:55:05.67ID:80M+etW5
関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな

949デフォルトの名無しさん2018/10/18(木) 18:03:23.12ID:b1Fs59oz
誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。

950デフォルトの名無しさん2018/10/18(木) 18:12:21.82ID:vIc/Em84
>>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう

951デフォルトの名無しさん2018/10/18(木) 18:17:11.53ID:b1Fs59oz
それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。

952デフォルトの名無しさん2018/10/18(木) 18:20:48.86ID:vIc/Em84
>>951
重複コードがほぼ一掃されるので全体のコード量は減る
利用者側は年齢にまつわる詳細なルールを知らなくても使えるようになるから複雑性も解消される

953デフォルトの名無しさん2018/10/18(木) 18:29:38.57ID:3douRw4T
棒グラフにするの大変やな

954デフォルトの名無しさん2018/10/18(木) 18:32:26.45ID:3douRw4T
平均年齢もきつい

955デフォルトの名無しさん2018/10/18(木) 18:34:20.75ID:7CPcoAfm
設計がおかしいとおかしなクラスが乱造される

一クラス一機能をつら抜いてFileRemoverとかFileRenamerクラス作ってる人は死んだほうがいい
MultiFileRemoverとか本当に必要なら作れよと思う

956デフォルトの名無しさん2018/10/18(木) 18:37:53.29ID:b1Fs59oz
>>952
だから呪い。実際、出来上がってるものの大半は真逆の事になってるんじゃないかね。

957デフォルトの名無しさん2018/10/18(木) 18:42:34.52ID:80M+etW5
オブジェクト指向は書く量と段取りを増やすデメリットをもって
パーツや責任関係の切り分けを行う作業と理解しております

958デフォルトの名無しさん2018/10/18(木) 18:45:45.21ID:b1Fs59oz
それならわかる。

959デフォルトの名無しさん2018/10/18(木) 19:06:46.96ID:vIc/Em84
日付型とかあるじゃん
あれ中身はただの整数値だけどだからってじゃあ整数値のままでいいじゃんとはならない
なぜなら整数値を日付とみなして注意深く扱うよりも
さっさと日付型を作ってしまったほうが間違いが減って問い合わせや演算が楽になり理解しやすくなるから
同じことをドメインでもやりましょうというだけの話なんだけど何をそんなに恐れてるのだろう

960デフォルトの名無しさん2018/10/18(木) 19:25:21.20ID:7CPcoAfm
架空言語にて

private Name name=new Name()

public Person(string name){
Name tmpName=new Name(name);
if(tmpName != null){
this.name=tmpName;
}
}

961デフォルトの名無しさん2018/10/18(木) 19:26:39.70ID:qf9NxgCD
>>947
そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
ある程度はどっちに比重置くか考えて作った方がいい。
そういう所こそ設計の腕の見せ所。

962デフォルトの名無しさん2018/10/18(木) 19:30:01.60ID:/ofNkRJS
> そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。

全く無関係の話をされても困るんだが?

963デフォルトの名無しさん2018/10/18(木) 19:39:03.88ID:qf9NxgCD
理想と現実は違うって事。
人間のこと考えたいけど、仕様変更繰り返すうちにグダグダになる。
出来る事は破綻しない様に事前に想定される事に対処して、その後も破綻しない様に管理することだけ。

964デフォルトの名無しさん2018/10/18(木) 19:50:43.92ID:KBtBXMK/
>>963
だからオブジェクト指向が必要なんだよね

965デフォルトの名無しさん2018/10/18(木) 19:54:07.63ID:qf9NxgCD
>>964
そう。
そのはずだ。
入門書でAnimalクラスを継承してDogクラスとCatクラスが〜とか例えた弊害か、人間の事をとかなる。
人間の事を考えるなら顧客の事だ。

966デフォルトの名無しさん2018/10/18(木) 19:54:59.16ID:/ofNkRJS
従業員かもしれんし、何を言ってんだお前は?

967デフォルトの名無しさん2018/10/18(木) 20:37:26.00ID:4AdjqlvR
>>938
エキスパートと思われる人にヒアリングしたら
そいつが「年齢にまつわる宇宙の真理」とか求め出すというクソ案件はたくさんある。

968デフォルトの名無しさん2018/10/18(木) 21:17:00.48ID:A+ZA0oir
>>947
だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
それじゃ無いと、様々な業務に適用させる度に微妙に違う属性を返さなきゃならんくなるだろ?

969デフォルトの名無しさん2018/10/18(木) 21:24:05.33ID:/ofNkRJS
> だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。

Personクラスはそもそも業務に特化したクラスだろう?

現実世界の人間を完全シミュレートする。それがオブジェクト指向だって
考えてるのはお前だけやで

970デフォルトの名無しさん2018/10/18(木) 21:25:37.05ID:A+ZA0oir
>>969
いや、そもそもオブジェクト指向はパーツの使い回しがテーマだからな。

971デフォルトの名無しさん2018/10/18(木) 21:26:42.98ID:/ofNkRJS
パーツの使い回しはオブジェクト指向じゃなくてもできるんで
それは全然違いますー

972デフォルトの名無しさん2018/10/18(木) 21:28:20.39ID:/ofNkRJS
いやはや驚きだ。これが馬鹿というものか

まさか、どんな業務にでも通用する
Personクラスを想定していたとは

世界にたった一つPersonクラスがあれば
ゲームから業務まで何でも使えるものを想定していたとはな

愚かとしか言いようがない

973デフォルトの名無しさん2018/10/18(木) 21:32:01.02ID:A+ZA0oir
少なくとも会社や自分の作るアプリで使い回す為にオブジェクト指向で作るんだからな。
おまえみたいに毎回特定業務に特化してフルスクラッチから作るとかバカしかやらんぞ。

974デフォルトの名無しさん2018/10/18(木) 21:33:57.36ID:/ofNkRJS
>>973

え?お前こういったじゃん

> やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。

お前は、使い回すために業務クラス作ってんのか?
どんな業務でも汎用的に使えるもの = 業務クラスだったのか?

975デフォルトの名無しさん2018/10/18(木) 21:35:16.82ID:/ofNkRJS
使い回さ(せ)ないもの = 業務クラス
Personクラスは使い回せない = 業務クラス

俺はこう言ってるだけなんだが、
こいつは何を言ってるんだろうか?

976デフォルトの名無しさん2018/10/18(木) 21:37:02.39ID:A+ZA0oir
アホに構ってしまった。
personなんて一般的な名前で個別に特化したクラスを作るあほは社会の迷惑だからしんでくれ。

977デフォルトの名無しさん2018/10/18(木) 21:38:08.80ID:/ofNkRJS
>>976
キミはネームスペースというものを知ったほうが良いぞ
多くの言語ではクラスはネームスペースの中に入れるから
一般的な名前が使えるんだよ

978デフォルトの名無しさん2018/10/18(木) 21:43:24.79ID:A+ZA0oir
それじゃ解決できねーんだよw

979デフォルトの名無しさん2018/10/18(木) 21:59:23.07ID:d31P7rqb
マクロ使ってスコープ無視してるんじゃね

980デフォルトの名無しさん2018/10/18(木) 22:04:29.72ID:A+ZA0oir
つうか、使いまわせないから却下。

981デフォルトの名無しさん2018/10/18(木) 22:20:46.14ID:d31P7rqb
名前空間内に入っていてその業務に特化したpersonという標準クラスはok派。
それを継承して使いまわしてもいいじゃない。

982デフォルトの名無しさん2018/10/18(木) 22:53:19.65ID:2FmMLZik
名前空間のせいで型名が長い
その反動で関数名は短すぎるから型を省略したら情報が少なすぎて読めない

型を宣言する言語としない言語の対立が最も激しくなる仕組み

983デフォルトの名無しさん2018/10/18(木) 23:03:48.89ID:vIc/Em84
personに関わる宇宙の真理を考えてる奴がマジでいてクソワロタwww

984デフォルトの名無しさん2018/10/18(木) 23:17:56.72ID:sfuI0a7S
オブジェクト指向で作った時点で失敗

メンバ変数の状態の数だけパターンが増えていく
これを仕様で固定せず
オブジェクトの状態数×オブジェクトの状態数
の工数爆発を汎用性による品質の向上とか思ってるキチガイばっかで救いようがない

無限の汎用性とは無限のバグ数を持っていることを悟るべき

985デフォルトの名無しさん2018/10/18(木) 23:19:33.39ID:/ofNkRJS
> オブジェクト指向で作った時点で失敗

いきなり結論ありきw

986デフォルトの名無しさん2018/10/18(木) 23:19:44.24ID:THsg9J3q
人類クラスからホモクラスを導出するぐらい頭ワルイことを平気でするからな

987デフォルトの名無しさん2018/10/18(木) 23:22:42.95ID:Buojxy+7
オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない

988デフォルトの名無しさん2018/10/18(木) 23:25:00.93ID:qf9NxgCD
>>973-974
あー。。。
オブジェクト指向は素晴らしいかもしれん。
だがな。
納期に追われた焦った脳で扱うには手が余る。
精々次の一回使い回せたら使えたってのが現実。
(と言うか、そんなんだから継承は悪とか言われるわけで)

上で誰かがライブラリ的な方が嬉しいとか書いてたろ?
あれが真実。(誓って書いたのは俺じゃあない)
流石にまんま関数をライブラリにしなくて、関数とクラスをまとめたライブラリにするが。(むしろ気持ち悪いかこれは)

だから言ったろ?
現実と理想は違うって。

理想を追い求めて納期間に合わなくて、クビになったら元も子もないやろ?
いつかは。。。とか思いつつ、その連続よ。

989デフォルトの名無しさん2018/10/18(木) 23:26:14.41ID:/ofNkRJS
>>988
お前の現実の話なんか
他人には関係ない

990デフォルトの名無しさん2018/10/18(木) 23:28:09.99ID:qf9NxgCD
そう思うんなら、まだ現実を知らない。

991デフォルトの名無しさん2018/10/18(木) 23:28:24.82ID:THsg9J3q
一番頭ワルイやつが大量にレスしてるわ。。。
まさに典型的な頭の悪さ

992デフォルトの名無しさん2018/10/18(木) 23:28:41.89ID:/ofNkRJS
お前の現実なんか知らんわw

993デフォルトの名無しさん2018/10/18(木) 23:33:25.51ID:/ofNkRJS
>>988
Personのような業務クラスは使いまわしできるわけがないのは常識で
どうせ作る力ないんだから作るな。使え。
オープンソースなんかの汎用クラスを使え
見事にオブジェクト指向で世界中使い回し出来てるんだから。

994デフォルトの名無しさん2018/10/18(木) 23:35:05.22ID:THsg9J3q
業務でどこの馬の作ったか分からんような
ちゃんと試験されたかどうかすらわからんようなコードを使うとかな
コイツは間違いなくニート

995デフォルトの名無しさん2018/10/18(木) 23:43:20.55ID:/ofNkRJS
ちゃんと試験すればいいだけじゃね?

どうせ自分で作っても試験するんだから
他人が作ったものを試験するほうが
作るコストが節約できる

第一そもそも作る能力がないレベルなんだから
他人のが使えませんと言っても
自分で作ることもできませんっていうのが落ちだろう

996デフォルトの名無しさん2018/10/18(木) 23:45:03.61ID:THsg9J3q
クソニートの世界では手続きとういもんがないのは分かる

997デフォルトの名無しさん2018/10/18(木) 23:46:15.45ID:/ofNkRJS
ダメな奴は
できる方法を考えるのではなく
できない理由を考える

998デフォルトの名無しさん2018/10/18(木) 23:46:31.81ID:/ofNkRJS
はい、さっき次スレ立てましたよー

オブジェクト指向ってクソじゃねぇよ? Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/

999デフォルトの名無しさん2018/10/18(木) 23:46:57.71ID:THsg9J3q
オマエはこのスレで頭わるいことばっかり書きこむまえに
ハロワへいく必要がある

1000デフォルトの名無しさん2018/10/18(木) 23:47:17.33ID:vIc/Em84
>>984
状態をクラスにカプセル化することによって独立性を保てる境界ができる
すると状態の組み合わせ数が激減するんだよ

10011001Over 1000Thread
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 55日 10時間 15分 8秒

10021002Over 1000Thread
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。


───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────

会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。

▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/

▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php

レス数が1000を超えています。これ以上書き込みはできません。