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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 01/10 03:06 / Filesize : 285 KB / Number-of Response : 1039
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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

1 名前：デフォルトの名無しさん [2018/08/24(金) 13:32:09.36 ID:ifygL6bT.net]: カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

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

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

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

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96
2 名前：デフォルトの名無しさん mailto:sage [2018/08/24(金) 13:35:00.08 ID:vJMsvnBL.net]: なにをいまさら
3 名前：デフォルトの名無しさん [2018/08/24(金) 13:35:14.51 ID:ZAZ1bDZG.net]: よくある
4 名前：デフォルトの名無しさん [2018/08/24(金) 13:44:30.12 ID:dWZiPnfz.net]: アホだな
5 名前：デフォルトの名無しさん mailto:sage [2018/08/24(金) 13:44:39.27 ID:GnRKIAsQ.net]: マジかよ
6 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:48:32.20 ID:JNQXY3hm.net]: >>696-701
ハロワ！
7 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:48:49.10 ID:JNQXY3hm.net]: >>188-193
ハロワ！
8 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:48:49.93 ID:JNQXY3hm.net]: >>188-193
ハロワ！
9 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:06.65 ID:JNQXY3hm.net]: >>936-941
ハロワ！
10 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:07.52 ID:JNQXY3hm.net]: >>936-941
ハロワ！
11 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:24.49 ID:JNQXY3hm.net]: >>475-480
ハロワ！
12 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:25.25 ID:JNQXY3hm.net]: >>475-480
ハロワ！
13 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:42.00 ID:JNQXY3hm.net]: >>504-509
ハロワ！
14 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:42.66 ID:JNQXY3hm.net]: >>504-509
ハロワ！
15 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:49:59.43 ID:JNQXY3hm.net]: >>10-15
ハロワ！
16 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:00.16 ID:JNQXY3hm.net]: >>10-15
ハロワ！
17 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:17.05 ID:JNQXY3hm.net]: >>846-851
ハロワ！
18 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:17.68 ID:JNQXY3hm.net]: >>846-851
ハロワ！
19 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:34.99 ID:JNQXY3hm.net]: >>794-799
ハロワ！
20 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:35.59 ID:JNQXY3hm.net]: >>794-799
ハロワ！
21 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:52.74 ID:JNQXY3hm.net]: >>594-599
ハロワ！
22 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:50:53.52 ID:JNQXY3hm.net]: >>594-599
ハロワ！
23 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:10.36 ID:JNQXY3hm.net]: >>74-79
ハロワ！
24 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:10.98 ID:JNQXY3hm.net]: >>74-79
ハロワ！
25 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:27.73 ID:JNQXY3hm.net]: >>865-870
ハロワ！
26 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:28.57 ID:JNQXY3hm.net]: >>865-870
ハロワ！
27 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:46.63 ID:JNQXY3hm.net]: >>193-198
ハロワ！
28 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:51:47.62 ID:JNQXY3hm.net]: >>193-198
ハロワ！
29 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:04.41 ID:JNQXY3hm.net]: >>639-644
ハロワ！
30 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:05.28 ID:JNQXY3hm.net]: >>639-644
ハロワ！
31 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:22.20 ID:JNQXY3hm.net]: >>743-748
ハロワ！
32 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:22.85 ID:JNQXY3hm.net]: >>743-748
ハロワ！
33 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:39.73 ID:JNQXY3hm.net]: >>2-7
ハロワ！
34 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:40.36 ID:JNQXY3hm.net]: >>2-7
ハロワ！
35 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:57.00 ID:JNQXY3hm.net]: >>300-305
ハロワ！
36 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:52:57.69 ID:JNQXY3hm.net]: >>300-305
ハロワ！
37 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:14.69 ID:JNQXY3hm.net]: >>423-428
ハロワ！
38 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:15.30 ID:JNQXY3hm.net]: >>423-428
ハロワ！
39 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:32.47 ID:JNQXY3hm.net]: >>227-232
ハロワ！
40 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:33.30 ID:JNQXY3hm.net]: >>227-232
ハロワ！
41 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:50.36 ID:JNQXY3hm.net]: >>150-155
ハロワ！
42 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:53:51.27 ID:JNQXY3hm.net]: >>150-155
ハロワ！
43 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:07.98 ID:JNQXY3hm.net]: >>715-720
ハロワ！
44 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:08.57 ID:JNQXY3hm.net]: >>715-720
ハロワ！
45 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:25.45 ID:JNQXY3hm.net]: >>57-62
ハロワ！
46 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:26.08 ID:JNQXY3hm.net]: >>57-62
ハロワ！
47 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:42.76 ID:JNQXY3hm.net]: >>856-861
ハロワ！
48 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:54:43.68 ID:JNQXY3hm.net]: >>856-861
ハロワ！
49 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:00.44 ID:JNQXY3hm.net]: >>595-600
ハロワ！
50 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:01.09 ID:JNQXY3hm.net]: >>595-600
ハロワ！
51 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:17.72 ID:JNQXY3hm.net]: >>314-319
ハロワ！
52 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:18.39 ID:JNQXY3hm.net]: >>314-319
ハロワ！
53 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:36.07 ID:JNQXY3hm.net]: >>632-637
ハロワ！
54 名前：♨デフォルトの名無しさん [2018/08/24(金) 13:55:36.71 ID:JNQXY3hm.net]: >>632-637
ハロワ！
55 名前：デフォルトの名無しさん mailto:sage [2018/08/24(金) 14:27:45.99 ID:0hzqlpOd.net]: >>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな
56 名前：デフォルトの名無しさん mailto:sage [2018/08/25(土) 00:54:02.71 ID:6mB8j9/9.net]: オブジェクト指向は、ウンコのようにニガい
57 名前：デフォルトの名無しさん mailto:sage [2018/08/25(土) 13:13:07.84 ID:00w/RGH3.net]: 砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない
58 名前：デフォルトの名無しさん mailto:sage [2018/08/25(土) 13:25:46.59 ID:bFeNHPVf.net]: オブジェクト指向が無くなった場合
メソッドは全部グローバル関数になるの？

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 名前：デフォルトの名無しさん mailto:sage [2018/08/25(土) 13:27:10.91 ID:bFeNHPVf.net]: 訂正

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 名前：デフォルトの名無しさん mailto:sage [2018/08/27(月) 19:47:07.71 ID:y3uHC3Z/.net]: クソはオブジェクトやぞ
61 名前：デフォルトの名無しさん mailto:sage [2018/08/31(金) 19:34:28.84 ID:lHXkvQer.net]: 文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。
62 名前：デフォルトの名無しさん [2018/09/05(水) 05:14:03.10 ID:UEpkpswy.net]: >>1
オブジェクト指向で組めない君らがクソ
63 名前：デフォルトの名無しさん mailto:sage [2018/09/05(水) 05:21 ]: [ここ壊れてます]
64 名前：:15.30 ID:w7O3HrXU.net mailto: スタティックおじさんの皆さん []: [ここ壊れてます]
65 名前：デフォルトの名無しさん mailto:sage [2018/09/05(水) 09:21:08.12 ID:BLSFUWnl.net]: カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな
66 名前：デフォルトの名無しさん mailto:sage [2018/09/05(水) 09:22:22.65 ID:BLSFUWnl.net]: 設計のないスタティックおじさん方式は柔軟かもわからんね↓
67 名前：デフォルトの名無しさん mailto:sage [2018/09/05(水) 15:30:35.02 ID:UEpkpswy.net]: >>61
正しく組めば重複が減ってコード量は減る

>>64
普通はカプセル化しないことで
開発できなくなることの方が多い
グローバル変数を使うとか
68 名前：デフォルトの名無しさん [2018/09/05(水) 23:23:20.11 ID:BuNkH2Jq.net]: オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ？
69 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 01:28:19.10 ID:uUC4mFDs.net]: >>67
https://thinkit.co.jp/article/13487

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

残念ながらフロー（流れ）を示す線は書けないので
フローチャートにはならない。特に条件分岐やループなどがない
70 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 03:27:30.57 ID:OdtAawkS.net]: >>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい
71 名前：デフォルトの名無しさん [2018/09/06(木) 07:33:26.04 ID:ndioKak8.net]: 本には書いてないオブジェクト指向
https://www.arksystems.co.jp/closeupit/object_oriented/

こいつを見てくれ、こいつをどう思う？
72 名前：デフォルトの名無しさん [2018/09/06(木) 07:42:10.81 ID:ndioKak8.net]: /** リストの要素をゼロで置き換える **/
private void clearList() {
　for (Integer el : someList) {
　　el = new Integer(0);
　}
}

なかなかファンキーなロケンロールだぜ
73 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 08:26:13.84 ID:abjuqq+M.net]: >>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか？
74 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 08:28:15.97 ID:abjuqq+M.net]: >>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ
75 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 08:31:32.42 ID:abjuqq+M.net]: 構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの
76 名前：デフォルトの名無しさん [2018/09/06(木) 12:51:58.13 ID:ntAiYVJq.net]: オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ
77 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 13:33:23.77 ID:uUC4mFDs.net]: >>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか？
78 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 13:46:11.74 ID:abjuqq+M.net]: インターフェースを切って実装を分離することを言ってるんじゃないか？
79 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 13:50:58.27 ID:BY1c9tpo.net]: そもそも、継承関係で隠蔽しちゃい合うのが問題なだ�
80 名前：ｯで、 インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。 []: [ここ壊れてます]
81 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:36:20.94 ID:OdtAawkS.net]: >>70
そのサイトには賛成できる部分と反対の部分がある

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

クラスは責務そのものという方が
オブジェクト指向の主流の教え方
82 名前：デフォルトの名無しさん mailto:sage [2018/09/06(木) 23:37:17.79 ID:OdtAawkS.net]: >>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向
83 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:35:51.18 ID:avaKv6NM.net]: >>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います！
84 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 08:40:25.09 ID:avaKv6NM.net]: 責務ごとにクラスを作るのがどうして主流だよね？ってことですよ
85 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 09:19:04.85 ID:avaKv6NM.net]: 責務ごとに分離したら凝集度が低下します
86 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 19:25:29.09 ID:ZCXZkOYn.net]: >>81
それもそうか

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

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

凝集度を上げるっていうのは
でかいクラスを作ることじゃないよ？
87 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 19:40:40.77 ID:Nc+ifFiB.net]: ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？
どうもUI部の設計は苦手だ。
88 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:33:13.60 ID:avaKv6NM.net]: >>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります
89 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:36:30.67 ID:avaKv6NM.net]: ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです
90 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:48:57.91 ID:ZCXZkOYn.net]: >>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う
91 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 20:49:13.32 ID:ZCXZkOYn.net]: >>86
＞データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる

>>87
ドメインオブジェクトの数が増えていくのは普通だが
1オブジェクトの行数が増えていくのは肥大化
92 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 21:07:16.42 ID:0j44DGgx.net]: >>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと

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

データをカプセル化してデータに対する責務を持つのが
オブジェクトなんだよ
93 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 21:09:02.84 ID:0j44DGgx.net]: データに対する振る舞いが集まるんだから凝集度は高まるんです
94 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 21:12:47.16 ID:0j44DGgx.net]: オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます
95 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 21:15:03.24 ID:Nc+ifFiB.net]: 皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。

いや、分かるよ。俺がViewの設計が下手っぴなのは認める。
96 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 21:16:51.88 ID:lg5TGvmQ.net]: >>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。
97 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:12:16.23 ID:ZCXZkOYn.net]: >>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋

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

責務ごとにクラスを作ることで凝集度が上がるのであって
複数の責務をひとつのクラスに混ぜたら凝集度は下がるよ
98 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:14:41.41 ID:ZCXZkOYn.net]: >>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事

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

全体の規模が大きくなっていく時に
ひとつのクラスの行数が増えるのが肥大化
クラス数を増やしていくのが正しいOOP
99 名前：デフォルトの名無しさん mailto:sage [2018/09/07(金) 22:15:21.48 ID:JescaW/f.net]: つか、ワンオブジェクトワンファイルなんてルールは無いから。
100 名前：デフォルトの名無しさん [2018/09/07(金) 22:58:43.86 ID:B/yxkRYZ.net]: このｽﾚにいるような池沼が作らなければ
ｸﾗｽﾗｲﾌﾞﾗﾘも階層や種類で作るからな

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

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

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

低学歴知恵遅れが作るとすべて同じ階層で同じ種類になる
101 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 02:09:56.99 ID:WAR6v8yR.net]: クラスに階層があるなんて寝言は寝て言うべきだと思うの
102 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 02:15:00.94 ID:WAR6v8yR.net]: このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ
103 名前：デフォルトの名無しさん [2018/09/08(土) 02:18:28.54 ID:j/6nk0eH.net]: 当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群は
ｼﾛｳﾄでもないかぎり完全に分離するからな

低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘは
当然、中間層のｸﾗｽﾗｲﾌﾞﾗﾘやｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を
参照することはまずない

ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘは
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を参照することはまずない

低学歴知恵遅れが作ると酷い依存関係ができる
ｺﾚはｵﾌﾞｼﾞｪｸﾄ指向関係なくﾗｲﾌﾞﾗﾘの基本だからな
104 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 04:34:33.80 ID:xpw/+eIi.net]: >>99
継承はクラス間の階層構造だろ？

>>100
行数だけの問題じゃないけど
プログラムを単純化するために
間接的なクラスを作ることはあるぞ？
105 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 09:24:01.98 ID:t/+GvP7Y.net]: × このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。

「行数を減らす」は「責務」ではない。「責務」を分離することで
得られる結果（メリット）の一つだ
106 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 12:06:19.78 ID:GaM457i+.net]: >70のサイト読んでると

プログラミングでどの様にしてプログラミングするか
というのと
実際のシステム要件なんかからどうやって設計するか
というのがごっちゃに書かれている感じがする
107 名前：デフォルトの名無しさん [2018/09/08(土) 12:33:05.14 ID:1I6Cu01I.net]: >>103
鋭い
108 名前：デフォルトの名無しさん [2018/09/08(土) 12:41:12.60 ID:j/6nk0eH.net]: 責務とｱﾎみたいなこといってるわ
組織でたとえるならこうなるからな

　経営者ｸﾗｽ　社員をこき使う
　　↓
　社員ｸﾗｽ　←　派遣をこき使う（職階ごとの複数の中間層）
　　↓
　派遣ｸﾗｽ　←　ｷﾐﾗが担当するような低ﾚﾍﾞﾙな部分の単純作業（つまりｷﾐﾗ）

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

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

ｷﾐﾗは派遣だからな、そういう作業はできないのは分かる

作業ﾐｽ（例外）が発生してｽﾙｰし続けてたら上までいくからな
109 名前：デフォルトの名無しさん [2018/09/08(土) 12:52:36.37 ID:j/6nk0eH.net]: 例えば扱うﾋﾞｼﾞﾈｽの領域が違えば
部門を分けることになる

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

ｷﾐﾗみたいな一種類の単純作業しかしてないﾔﾂﾗには関係ない
110 名前：デフォルトの名無しさん [2018/09/08(土) 13:03:07.35 ID:j/6nk0eH.net]: というわけでな
ｷﾐﾗは刺身にﾀﾝﾎﾟﾎﾟのせる作業に戻りなさい
ｷﾐﾗにはﾑﾘ
111 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 13:03:32.85 ID:t/+GvP7Y.net]: ｷﾐﾗには・・・ｷﾐﾗには・・・
112 名前：デフォルトの名無しさん [2018/09/08(土) 13:11:07.86 ID:j/6nk0eH.net]: あ、ｵﾏｴは刺身の醤油入れに醤油つめる作業だったか
いや、醤油入れのｷｬｯﾌﾟをしめる作業だったか

ともかく、ｷﾐの細かい作業なんかｵﾚは知らないからな
作業ﾐｽが発生したらちゃんと報告するようにな

まずｷﾐの直属の上長にだ

分かった？
113 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 13:22:45.36 ID:t/+GvP7Y.net]: キミラは下で俺が上だ・・・上なんだ・・・
114 名前：デフォルトの名無しさん [2018/09/08(土) 14:59:23.20 ID:1I6Cu01I.net]: >>106
それだと上位が下位に依存して
組織が硬直化する
インタフェスを挟んで依存関係を逆転させる

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

これがInversion Of Control
115 名前：デフォルトの名無しさん mailto:sage [2018/09/08(土) 15:00:32.82 ID:t/+GvP7Y.net]: >>112
それどこの定義？
それと同じような説明をしてる場所教えて
116 名前：デフォルトの名無しさん [2018/09/08(土) 15:11:58.88 ID:1I6Cu01I.net]: Inversion of Controlパターンでコンポーネント間の結びつきを弱める：CodeZine（コードジン）
https://codezine.jp/article/detail/60

こことか
117 名前：デフォルトの名無しさん [2018/09/08(土) 15:40:47.46 ID:j/6nk0eH.net]: ただのﾘﾌﾚｸｼｮﾝやんけ
昔のｳﾝｺMFCのｺﾝﾄﾛｰﾙのﾘﾌﾚｸｼｮﾝとほとんど同じ
結局親のｺﾝﾄﾛｰﾙに大量のﾘﾌﾚｸｼｮﾝのｺｰﾄﾞを埋め込むことになる

ｺﾝﾄﾛｰﾙごとに処理記述するほうがはるかに分かりやすい
118 名前：デフォルトの名無しさん [2018/09/08(土) 15:43:54.64 ID:j/6nk0eH.net]: ×結びつきを弱める
○もともと末端ではなにもしない処理にする
119 名前：デフォルトの名無しさん [2018/09/08(土) 15:51:53.40 ID:1I6Cu01I.net]: 何もしないだと・・・
じゃあたんぽぽ担当は何のために
120 名前：デフォルトの名無しさん [2018/09/08(土) 16:07:40.80 ID:j/6nk0eH.net]: いちいちﾀﾝﾎﾟﾎﾟ載せてる作業経過報告はいらない
作業の補助とか、いちいち次になにをするかとかとか指示はしないからな

ﾀﾝﾎﾟﾎﾟが地面に落ちたとかこのﾀﾝﾎﾟﾎﾟのﾊﾅ小さいとか
そういう報告もいらない
捨てときなさい
それぐらい分かるだろう

ﾀﾝﾎﾟﾎﾟが足りなくなりそうになったら
この台帳に書いときなさい
ｺﾚだけはたまに見といてやるからな
121 名前：デフォルトの名無しさん [2018/09/08(土) 16:11:08.60 ID:1I6Cu01I.net]: 台帳によって疎結合になるわけですね
122 名前：デフォルトの名無しさん [2018/09/08(土) 16:11:29.17 ID:1I6Cu01I.net]: 台帳オブジェクトの発見、これがドメイン分析
123 名前：デフォルトの名無しさん mailto:sage [2018/09/09(日) 00:27:26.13 ID:fJdKrV9d.net]: タンポポの弾幕
124 名前：デフォルトの名無しさん [2018/09/09(日) 01:14:12.52 ID:0bXk8YdS.net]: DBのテーブル数や列数が少なくて
テーブル設計が洗練されているならオブジェクト指向っていいんだろうね。
でも現実のシステム考えるとアホみたいにテーブルの数が多くて
アホみたいに列の数が多くて、整理もされていないわけじゃん。
そしてアホみたいに文言の定数定義とかも多い。
そうすると、階層構造作ってレイヤの数を増やして
結果的1つの機能を達成するのに作るファイルの数が増えるほど、
それらのアホみたいに多くて長い列名をレイヤの数だけ書きまくる
みたいな苦行が待っているわけじゃん。
少しでも項目名の変更があったらそれらのファイル部書き換えたり
クラス名に変更がありでもしたらファイル名やフォルダ名とか、
テーブル名、import文とか全部書き換えになるわけじゃん。
それにオブジェクト指向でどう頑張っても最終的に値を
埋め込む画面が汚くなるのは避けることができない。
そうするとオブジェクト指向設計で無理にファイルを分けて
構造化するリスクってやばいと思う。
そうなると少ないファイルオブジェクト指向クソ喰らえみたいな勢いで
構造化プログラミングだけでゴリッと書くほうが早いと思うんだよね。
命名規則もいちいち気を使わないで勢いで書くんだよ。
ファイルの中関数定義だらけになるが、
その中で似たような処理の関数見つけてきて、複製して、
今必要な処理ができるように改変して新たな関数を作る。これで十分だ。
1ファイルの中で完結しているんだから不具合は波及しない。
ファイルをまたいでimportして無理にファイルの昨日使う必要性なんて
どこにも有りはしないだろ。ファイルの頭からimportやextend inplementだらけ
とか吐き気がするよ。
オブジェクト指向ってファイル間の関連性追ったり、
ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。
125 名前：デフォルトの名無しさん mailto:sage [2018/09/09(日) 02:14:14.22 ID:rd2vglUK.net]: 今北産業
126 名前：デフォルトの名無しさん mailto:sage [2018/09/09(日) 06:49:20.59 ID:O317ycPa.net]: >>122
簡単に言うと短期間しか使わないシステムなら
構造化＋DBで組むのも良いと思うけど
長期間使う大規模なシステムは
オブジェクト指向で組んだ方が
保守まで含めた全体のコストは下がる
だから企業もOOを採用している
127 名前：デフォルトの名無しさん mailto:sage [2018/09/09(日) 07:29:49.35 ID:QdIWFdtA.net]: >>122
それオブジェクト指向の問題じゃなく、システムの基本設計が破綻してるだけ。
128 名前：デフォルトの名無しさん mailto:sage [2018/09/09(日) 07:53:15.67 ID:B5kEXEZS.net]: >オブジェクト指向ってファイル間の関連性追ったり、
>ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。

それはその通りだと思う
ただ関連性はプログラムではなくてクラス構造図やオブジェクト生成手順図みたいなので判断するもので所謂上から下に辿って見て行く物でも辿って出きる物でも無い
オブジェクト指向プログラミングをすると設計図をちゃんと描いてから作ってる
って感じがするし
ただまともに且つ効果的に作るのは難しくて解っていない人が無理やり作ってしまうと反って酷くなる
そういう風にしか作れなかったりそういう風な人しか居ないならオブジェクト指向プログラミングは止めておいた方が良いそういう風な所はcobolみたいなのが一番向いていると思う
ただしオブジェクト指向プログラミングに効果的な使い方が有り実際に行われているのでオブジェクト指向プログラミングその物がおかしいというのは間違い
多くの人が
使えるか?
使うべきか?
となるとそれは無理なのかなぁ
とは思う
どっちかって言うと解らないなら無理して使うなという物だと思う
解らない人が有る程度居る?沢山居る?ということならプロジェクトで使わないという判断する
というのが重要なんだと思う
解らない人には苦痛でしかないし解らない人が作った物は本人にも他に人にも迷惑でしかないだろうなぁ
129 名前：デフォルトの名無しさん mailto:sage [2018/09/10(月) 23:59:27.90 ID:R+xXPRjE.net]: オブジェクト指向がよくわからんド素人俺にはlinqは感動した。
web系フレームワークの真似事+継承だらけのコードのメンテは地獄だった。素人が手をだしたらアカン代物だわ。
130 名前：デフォルトの名無しさん [2018/09/17(月) 13:28:16.75 ID:hCpxPlj7.net]: ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html
131 名前：デフォルトの名無しさん [2018/09/17(月) 13:30:49.79 ID:27GPeyCI.net]: >>128
なんか気持ち悪い、アスペっぽい
132 名前：デフォルトの名無しさん mailto:sage [2018/09/17(月) 13:30:59.69 ID:6+Wt0ENU.net]: またお前か
133 名前：デフォルトの名無しさん [2018/09/17(月) 22:41:39.72 ID:AYOVQ736.net]: >>130
なんか気持ち悪い、糖質っぽい
134 名前：デフォルトの名無しさん mailto:sage [2018/09/19(水) 05:57:49.26 ID:zGAoAQgA.net]: >>128
そのブログ前も見たけど説明が下手だなあ……

何でデザインパターンが必要なのかとか
自分の言葉でほとんど説明できてないじゃん
分かりやすさ以前に分かる説明をしていない
135 名前：デフォルトの名無しさん mailto:sage [2018/09/19(水) 19:25:49.89 ID:3+BPTz35.net]: >>125
そらーオブジェクト指向はオブジェクト使うからオブジェクトの構造をちゃんと綺麗に作れば問題は起きないな
オブジェクトの構造と言えばオブジェクト同士の繋がり方関連性も含まれるだろうからそのまま全体像にも繋がるから個々のオブジェクトさえちゃんと作れば全部が良くなるとも言えるはず

問題はシステムの基本設計が破錠しないように作ればいい、ということではなくて破錠しやすいという所にあるような
136 名前：デフォルトの名無しさん mailto:sage [2018/09/19(水) 23:52:24.34 ID:YoDbSZZU.net]: >>133
知ったかツマラン。
137 名前：デフォルトの名無しさん mailto:sage [2018/09/20(木) 00:25:31.99 ID:UYyYb6vq.net]: >>134
そやな。俺が知ってる唯一の情報がオブジェクト指向はシステムの基本設計が破綻するってだけだからな。
138 名前：デフォルトの名無しさん mailto:sage [2018/09/20(木) 08:07:35.90 ID:v1EqyHAs.net]: 俺が知ってる情報は次の２つだ
1.バカが使うとどんな言語でも破綻する
2.>>133-135はそのバカに属する
139 名前：デフォルトの名無しさん mailto:sage [2018/09/20(木) 17:06:26.63 ID:UYyYb6vq.net]: >>136
問題はそこからやな
バカが使わなければ破錠しないのか、隠蔽のコスパが手続き型や関数型で作るコスパを本当に上回ってんのか
140 名前：デフォルトの名無しさん mailto:sage [2018/09/20(木) 19:40:11.95 ID:v1EqyHAs.net]: >>137
隠蔽のコスパとか言うバカ乙 w
141 名前：デフォルトの名無しさん mailto:sage [2018/09/21(金) 19:22:25.43 ID:+zpU6K4O.net]: オブジェクト指向は複雑な構造を構築するわけだから
別に破綻はしないだろう
むしろ見た目は良い
142 名前：デフォルトの名無しさん mailto:sage [2018/09/21(金) 20:28:00.82 ID:qgyq16h9.net]: オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと
143 名前：デフォルトの名無しさん mailto:sage [2018/09/21(金) 20:46:48.28 ID:qgyq16h9.net]: 小規模ならいいが大規模だと設計必須
とりあえず書き始めると最後に詰まるのがオブジェクト指向

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

普通は小さいパーツが出来てるならある程度楽できるはずなのに逆に苦しくなる
本当におかしい
144 名前：デフォルトの名無しさん mailto:sage [2018/09/21(金) 20:51:36.57 ID:qgyq16h9.net]: クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく
インターフェイスを考えた上の設計がないと後で詰まる
当たり前に思ってるけどそれはオブジェクト指向の限界というか弊害
145 名前：デフォルトの名無しさん mailto:sage [2018/09/22(土) 08:52:06.62 ID:seN9Vjts.net]: つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな
146 名前：デフォルトの名無しさん [2018/09/22(土) 09:44:45.27 ID:jtQ8570T.net]: >>140
境界定義なんて、モノリシックアプリでも必須なんだが？
その認識もないままオブジェクト指向とかマイクロサービスに手を出すとグダる。

開発チームを苦しめるマイクロサービス（翻訳）
https://techracho.bpsinc.jp/hachi8833/2018_01_29/51135
147 名前：デフォルトの名無しさん mailto:sage [2018/09/22(土) 09:58:06.00 ID:LHC7cNdc.net]: >>142
限界？弊害？

>>142のどこに限界や弊害が書いてあるの？
148 名前：デフォルトの名無しさん mailto:sage [2018/09/22(土) 14:09:59.67 ID:ycLOp2uz.net]: >>145
あんまりそこにしっかり書かれていないから語弊ありきで言うんだが
その抽象的間接的に作らなきゃいけないてことやな
作ってもいい、じゃなくて作らなきゃいけないという
149 名前：デフォルトの名無しさん mailto:sage [2018/09/22(土) 15:20:24.84 ID:LHC7cNdc.net]: >>146
そりゃ大規模プログラムをメンテナンス性あげて作ろうとしたら
オブジェクト指向に限らず、考えなきゃいけないことだろな。

でも破綻していいなら、別に抽象的間接的に作らなくていい。
小さなツール程度ならゴットクラスで破綻状態でもなんとかできるだろうさ
そういう点で、オブジェクト指向の限界でも弊害でも何でも無い
150 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 01:13:41.68 ID:MlhnYRcx.net]: >>147
いや俺の言う破綻てのは別にオブジェクトオンリーにこだわって
細かいとこをクロージャで逃げたり、その場しのぎ的に小さいオブジェクトで茶を濁すのもダメって意味じゃないんよ
小さいオブジェクトならオブジェクト同士やシステムが密結合になりえないだろうしな

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

因果関係が逆

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

話はこれだけだろう？単純だろうが
152 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 10:01:28.60 ID:y+eZw7HP.net]: 普通に組めばいいじゃん
153 名前：デフォルトの名無しさん [2018/09/23(日) 11:37:45.64 ID:0vXeudiz.net]: >>149
おまえめちゃめちゃバカやなw
154 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 12:09:34.69 ID:loi8GnJQ.net]: まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。
〜指向全般に言えるけれど、結局は一つの指標みたいなもんで
指標上げることが目的になったらクソになるのは当たり前だよね。
155 名前：デフォルトの名無しさん [2018/09/23(日) 12:29:12.02 ID:0vXeudiz.net]: バカすぎて意味がつながっとらんw
156 名前：デフォルトの名無しさん [2018/09/23(日) 15:43:38.58 ID:w6QfJYdi.net]: オブジェクト指向に継承って要る？
もともとのオブジェクト指向の発想からすれば、別に無くてもいいっていうか、むしろ邪魔じゃね？
157 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 16:17:15.71 ID:NWkg7eaT.net]: >>154
継承でコードを書く量を減らせるってのはあるが、他の仕組みで代わりになるなら無くても良い
158 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 16:31:30.62 ID:NWkg7eaT.net]: ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ
159 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 16:37:33.42 ID:MlhnYRcx.net]: >>149
ちゃうねん

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

ただ当然理想論言えば問題を元々起こさなきゃいいっちゃいい話よ理想を言えば
160 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 16:50:39.86 ID:N8r2Gw6d.net]: > 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。
前提が間違っているから話にならん。

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

そして隠蔽されている部分は無視するという話なら、（オブジェクト指向の）
標準ライブラリを使うだけの簡単なコードは作れる
例えば、Rubyでprint "hello world"と書いただけでもオブジェクト指向が使われてる
オブジェクト指向であっても、小規模で単純なものを作れるものである証拠
161 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 17:11:55.75 ID:MlhnYRcx.net]: >>158
オブジェクト指向言語の標準ライブラリとか1番破綻しないオブジェクト指向のパターンじゃないか？
そりゃ全てのオブジェクト指向で作った物が全て破綻することはないだろう

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

とわいえ、それでもやっぱりオブジェクト指向は大規模なものの為”だけ”にあって、そのため”だけ”の機能があって、そのせいで破綻するってのが俺の考えよ
162 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 17:22:45.03 ID:N8r2Gw6d.net]: >>159
だからオブジェクト指向で小規模なものを作る例あげたじゃん。
馬鹿なの？

大規模なら破綻するのは、オブジェクト指向で無くても同じ
163 名前： つまりお前の理屈は オブジェクト指向・・・小規模は作れない、大規模は作れる ？？？指向・・・小規模は作れる、大規模も作れる って言ってるだけでしょ で大規模であれば、破綻するのはどちらも同じなんだから 大規模に置いてはオブジェクト指向も？？？指向も変わらない だからオブジェクト指向で、小規模は作れないと言ってるだけだよね？ （実際にはオブジェクト指向で小規模なものが作れる） []: [ここ壊れてます]
164 名前：デフォルトの名無しさん [2018/09/23(日) 17:45:57.32 ID:cRG95Xcq.net]: この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる

　①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
　②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
　③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
　　※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
　④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
　　処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
　　（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
　⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止

ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる
165 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 19:29:44.09 ID:y+eZw7HP.net]: オブジェクト指向にメリットなんて無いからね
166 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 20:20:35.62 ID:MlhnYRcx.net]: >>160
そりゃ作れないなんて言ってないがな。
「オブジェクト指向は大規模なモノを作る為だけにある」って話であって「オブジェクト指向は小規模なモノは絶対に作れない」とはならんからな

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

俺が言ってるのは一般的にモノが複雑になれば破綻しやすいという話ではなくて
、”その上で更に”オブジェクト指向は独特の破綻を招くって話であって
167 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 21:48:23.69 ID:N8r2Gw6d.net]: >>163
あー、わかったわかった、つまりこういうことだろ？

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

自動車で遠くにいくなら時間はかかるし
距離も長いから事故の確率も上がるし大変だが
飛べないから墜落事故は起きないのだ
168 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 21:50:15.95 ID:N8r2Gw6d.net]: そう主張することで、飛行機の何を否定しているのかわからんのと
どうように、オブジェクト指向の何を否定しているのかわからんがなｗ
169 名前：デフォルトの名無しさん [2018/09/23(日) 21:51:15.19 ID:0vXeudiz.net]: おまえら破綻しすぎじゃね？w
どうやったらそんなに破綻を量産できんねんw
170 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 22:02:41.85 ID:MlhnYRcx.net]: >>164
オブジェクト指向の話で悪い例え話したら1番イカンやろ。抽象的なもんの取り扱いなんだから。しかも何言ってるかわからんけど多分それは違うしな

>>166
いやまさにそういう事よ。多人数が動く大規模で抽象的な流れは上手くいくはずがないわ。しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する
171 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 22:26:37.81 ID:N8r2Gw6d.net]: >>167
> オブジェクト指向の話で悪い例え話したら1番イカンやろ。

は？なんで？
反論できない言い訳にもほどがあるわ
172 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 22:28:04.83 ID:N8r2Gw6d.net]: > しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する

しない。
オブジェクト指向を使わないほうが破綻するし、
破綻した後
173 名前：のリカバリーはオブジェクト指向よりも大変 お前は単に両方とも破綻するが オブジェクト指向的破綻をするのはオブジェクト指向だけと言ってるだけだろ 破綻する時点で問題なんだよ。オブジェクト指向の方が破綻しない []: [ここ壊れてます]
174 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 22:42:45.15 ID:MlhnYRcx.net]: >>169
>オブジェクト指向的破綻をするのはオブジェクト指向だけと
そういう事や。楽をするためにそれをするメリットが上回ってデメリットのが下回らなきゃいけないのはオブジェクト指向の完全必須項目なんだが
大規模複雑はこの完全必須項目がどんどん難易度が上がってくる。
途中の間違い失敗のリカバリのコストは確実にオブジェクト指向のが上

理想論一般論で言えば間違えなくちゃんと作ればいい、どの作り方でも大きいのは大変は大変、以上！て言えばそりゃそうだが
その問題を防ぐための記法が裏目に出て逆効果なら理想論一般論で片付けたらいかんでしょ
175 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 23:17:04.84 ID:N8r2Gw6d.net]: >>170
ほらな。

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

墜落事故を起すのは飛行機だけだと言ってるのと同じ
だからなの？状態なんだよｗｗｗ
176 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 23:18:16.29 ID:N8r2Gw6d.net]: 結局、小規模アプリでも大規模アプリでも
オブジェクト指向のほうが良いって結論なわけだよ。

そして、大規模で破綻するのはオブジェクト指向じゃなくても同じこと
177 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 23:18:37.66 ID:N8r2Gw6d.net]: ただの言葉遊びだったな
178 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 23:26:41.71 ID:loi8GnJQ.net]: そうなりやすいのがオブジェクト指向論争
179 名前：デフォルトの名無しさん [2018/09/23(日) 23:28:46.55 ID:cRG95Xcq.net]: ﾊﾞｶに限って抽象化とかいって
ｻﾙみたいにうれしがって継承するからな

破綻はそこから始まる

しばらくたつと
ﾃﾞｰﾀ受け渡しするために
無秩序に相互参照しはじめる

こうなったら終わりの始まり
180 名前：デフォルトの名無しさん mailto:sage [2018/09/23(日) 23:33:26.91 ID:N8r2Gw6d.net]: 同じものを作る時、オブジェクト指向はオブジェク手と指向破綻をしやすいが
オブジェクト指向じゃないものを使うと、オブジェクト指向じゃない破綻をする
って言ってるだけ。

オブジェクト指向だと大規模なものを作れる。
オブジェクト指向じゃないと大規模なものは作れない
181 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 00:03:50.44 ID:+ob6DU4m.net]: オブジェクト指向じゃなくしたから
大規模なシステムを作れるようになった
って話はあまり聞かない
182 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 01:12:57.64 ID:oYzwCf5A.net]: オブジェクト指向にメリットなんて無いからね
183 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 09:54:20.13 ID:dKKNaNpJ.net]: ただモジュール境界を明確にしただけなのをオブジェクト指向って言い張ってるだけだろうな。

「オブジェクト指向じゃないと大規模なものは作れない」
この結論ありきで論法を組み立てるとそうなる。
184 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 16:52:34.59 ID:JEGqIfby.net]: >>171
そのアカン例えを使うなと

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

いややっぱアカンやろこの例え、設計を抽象的な部分から見直せ
185 名前：デフォルトの名無しさん [2018/09/24(月) 18:34:58.60 ID:jnbiRGGY.net]: まぁオブジェクト指向は「銀の弾丸」じゃないですからね
オブジェクト指向の採用による成功事例は数多く存在する一方で、
オブジェクト指向を採用したにもかかわらず失敗した事例も
少数とはいえ存在するのも事実

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

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

スレタイに沿って返すとすれば：
・あらゆる言語においてオブジェクト指向ってクソじゃね？
　　=> いいや、そんなことはない
・Pythonにおいてオブジェクト指向ってクソじゃね？
　　=> たしかに、Pythonではクソかもしれない
186 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:36:05.95 ID:csv6kfNU.net]: >>180
とりあえずお前が馬鹿だっていうのはわかった

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

オブジェクト指向を使わなかったら
今度は非オブジェクト指向問題が発生するだろ
187 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:37:21.47 ID:csv6kfNU.net]: >>181
Pythonで大規模アプリ作って失敗したら
Python的問題が発生したということさ
C言語で失敗したらC言語的問題が発生したということさ
188 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:42:13.65 ID:csv6kfNU.net]: 仮にオブジェクト指向設計を採用せずに
構造化設計を採用したとしよう。
大規模プログラムで密結合になってると失敗する
そうすると構造化設計特有の問題が発生したということで
それはオブジェクト指向よりもリカバリーが大変
189 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:42:49.46 ID:FEoaRsa5.net]: どうでもいい話だな
190 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:43:48.46 ID:JEGqIfby.net]: >>182
んなもん当たり前だろ別のやり方すれば別の問題があるに決まってやろ
そんな何にでも通ずる一般論じゃないの

オブジェクト指向がそれ専用なのに逆効果だから色々言ってるの
これは何にでも通ずるフラットな一般論じゃないぞ？何故ならオブジェクト指向はそれ専用なのに逆効果だからな、いわばイレギュラーで根本的な問題
191 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:44:29.97 ID:csv6kfNU.net]: そう。ただの言葉遊びしてるだけだからどうでもいいこと
結局は構造化設計を選んで失敗したから
構造化設計に問題があると言ってるだけなんだから
自分の非を認めたくないからそういことをしてる
あ、オブジェクト指向が使えないんだっけか？ｗ
192 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:45:02.09 ID:csv6kfNU.net]: >>186
いつからオブジェクト指向がそれ専用になったんでーすかーｗ

おかしいですねｗｗｗ
193 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:46:46.24 ID:csv6kfNU.net]: 構造化設計は大規模に向かないのである

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

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

オブジェクト指向が問題だったんだー！
194 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:54:12.30 ID:JEGqIfby.net]: >>188
>いつからか
そらー最初からやな。そのため”だけ”やしな
195 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 18:55:45.99 ID:JEGqIfby.net]: >>189
おっ？そうだなオブジェクト指向が問題が問題だったんだ。なんだかんだ同意見やったんやな
196 名前：デフォルトの名無しさん [2018/09/24(月) 19:07:39.30 ID:jnbiRGGY.net]: >>189
>そしてオブジェクト指向で設計すると
>失敗する確率は大幅に下がるわけだが

ここは同意しますけど、

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

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

>>183でもご自分で「Python的問題」と語っていますから、矛盾してます
197 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:08:50.83 ID:csv6kfNU.net]: >>190
> そらー最初からやな。そのため”だけ”やしな

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

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

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

>>191
皮肉もわからんのかーｗｗｗ
198 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:13:55.57 ID:csv6kfNU.net]: まとめ

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

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

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

構造化で大規模で失敗・・・失敗して当然。構造化に問題があった
オブジェクト指向で大規模で失敗・・・適した道具を使っても失敗した
　　　　　　　　　　　　　　　　　　使ってるやつの能力に問題がある
　　　　　　　　　　　　　　　　　　責任転嫁としてオブジェクト指向使ったから失敗したんやーと叫ぶｗ
199 名前：デフォルトの名無しさん [2018/09/24(月) 19:14:23.90 ID:Kxio7RVg.net]: Cで書かれたOSはくさるほどある
C++で書かれたOSなんかあんの
200 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:18:02.09 ID:JEGqIfby.net]: >>192
もう謎のテンション上げで冷静な会話無理やろ、
1レス目の冷静そうな語り口調急にが帰ってきたらそれはそれでキモイけど、、
201 名前：デフォルトの名無しさん [2018/09/24(月) 19:21:50.21 ID:Kxio7RVg.net]: 超大規模なMS WindowsもCで書かれてる
202 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:21:52.45 ID:csv6kfNU.net]: >>196
お前の会話が非論理的だからしょうがない。

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

で、構造化使って密結合にして失敗したら構造化のせいにせずに
オブジェクト指向を使って密結合にして失敗したら
オブジェクト指向のせいにしてるんだろ？
203 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:23:43.41 ID:csv6kfNU.net]: どちらにしろ
構造化よりもオブジェクト指向のほうが大規模に強いのは変わらん

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

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

で、能力不足を認めたくないから、
オブジェクト指向のせいにしてるんだろ？
204 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:23:52.69 ID:0XIVTMWe.net]: そもそも破綻している、と言える状態はどんな場合だろうか
205 名前：デフォルトの名無しさん [2018/09/24(月) 19:24:42.73 ID:Kxio7RVg.net]: だいたいわかる

ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる
206 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:26:39.65 ID:csv6kfNU.net]: 馬鹿「オブジェクト指向で失敗したら、オブジェクト指向特有の・・・」

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

馬鹿「ぐぬぬ」

↑イマココ
207 名前：デフォルトの名無しさん [2018/09/24(月) 19:27:16.94 ID:Kxio7RVg.net]: で、ｳﾝｺｽｸﾘﾌﾟﾄで
山盛りのｳﾝｺをつくる

rubyとpython作ってるような
ｳﾝｺｽｸﾘﾌﾟﾀｰ
208 名前：デフォルトの名無しさん [2018/09/24(月) 19:30:25.06 ID:Kxio7RVg.net]: ｺｲﾂﾗの場合
ｳﾝｺｽｸﾘﾌﾟﾄﾌﾚｰﾑﾜｰｸ（）使っても
破たんさせるほどの特殊能力がある

だいたいこういうの使ってるﾔﾂﾗは
そういうﾔﾂﾗだ
209 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:34:16.94 ID:JEGqIfby.net]: >>198
皮肉もわからんのかーwwwとか言うやつが急に非論理的だ、とか笑わせに来てんのか貴様は

なんだろうなお前の言い分は都合が悪いと全部一般論にして逃げてる感あるな、大規模なモノが破綻するのはオブジェクト指向に限らずみんな一緒とか。
それを言うならオブジェクト指向使わず手続き型で組んでも破綻しないように組めばいいじゃんってなるんだよな。
その先が見えないわけよな。もはや何の為にオブジェクト指向使ってるんという
210 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:36:53.39 ID:JEGqIfby.net]: >>200
オブジェクト指向の破綻はルール守る為に手続き型のコストを超えた時やろな
211 名前：デフォルトの名無しさん [2018/09/24(月) 19:40:51.50 ID:Kxio7RVg.net]: ﾉｰﾀﾘﾝ言語の開発現場には
ﾉｰﾀﾘﾝが集まる

ｺﾚは宿命
212 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:42:38.68 ID:JEGqIfby.net]: >>207
上でな、オブジェクト指向は壊れると言ったら壊れないように作ればいいという身も蓋も事を言われたんや
言語はそういう人のために作らないといけないかもしれん
213 名前：デフォルトの名無しさん [2018/09/24(月) 19:45:46.24 ID:BNNY8GPf.net]: いつまで自演しとんねん
214 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:47:43.48 ID:csv6kfNU.net]: >>208
当たり前だろ

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

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

誰もオブジェクト指向が銀の弾丸なんていってない
だが強力な武器なんだよ。
215 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 19:48:10.66 ID:dKKNaNpJ.net]: とりあえずオブジェクト指向で作るってことがなんなのかから判別しようか。
例えばlinux kernelはオブジェクト指向でバリバリ作ってると思われてんのかね？
216 名前：デフォルトの名無しさん [2018/09/24(月) 19:49:06.45 ID:Kxio7RVg.net]: ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題
217 名前：デフォルトの名無しさん [2018/09/24(月) 19:50:21.60 ID:BNNY8GPf.net]: まだ自演を続けんのかよ
いい加減にしろ
218 名前：デフォルトの名無しさん [2018/09/24(月) 19:57:16.26 ID:Kxio7RVg.net]: ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ

ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない

ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物

ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪
219 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:01:34.39 ID:H/ciA4Rj.net]: オブジェクト指向って何ですか？
C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
220 名前：デフォルトの名無しさん [2018/09/24(月) 20:07:21.20 ID:Kxio7RVg.net]: X11やMS Windowsもｵﾌﾞｼﾞｪｸﾄ指向で設計されてる
ただ、低学歴知恵遅れでは、C言語でそれを実現することはできない

そしてそれを簡単に実現できる言語を使うと
なにが便利であるか核心的な部分が理解できずに使って
別のろくでもない問題をおこすわけ
221 名前：デフォルトの名無しさん [2018/09/24(月) 20:10:52.64 ID:Kxio7RVg.net]: ﾊﾝﾄﾞﾗやｺﾝﾃｷｽﾄつかって
ｵﾌﾞｼﾞｪｸﾄを操作するのはまさしくｵﾌﾞｼﾞｪｸﾄ指向の便利な部分だからな

UNIXのi/oなんかもﾊｰﾄﾞｳｪｱがうま�
222 名前：ｭ抽象化されてる ﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀ使って簡単に読み書きができるからな []: [ここ壊れてます]
223 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:13:11.48 ID:oYzwCf5A.net]: オブジェクト指向にメリットなんて無いからね
224 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:17:40.60 ID:csv6kfNU.net]: >>215
> C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
大変だけどできるよ

作りやすいかどうか、失敗しやすいかどうかだから
225 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:22:15.20 ID:csv6kfNU.net]: 結局の所、小規模なものはオブジェクト指向使っても失敗しない
大規模なものは、オブジェクト指向を使うと失敗しにくくなる
って所が重要なんじゃないですかね？

失敗したときにそれがオブジェクト指向的な原因か
構造化的な原因か、なんてことよりよりも
226 名前：デフォルトの名無しさん [2018/09/24(月) 20:30:44.15 ID:Kxio7RVg.net]: 低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
日本では、ITﾄﾞｶﾀは低学歴底辺がなる職業だからな

だいたい程度がしれたﾔﾂﾗが群がってくる
この板みれば分かるとおり
227 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:31:28.52 ID:e4NBE4Fp.net]: う～ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。

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

なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。
228 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:32:33.20 ID:csv6kfNU.net]: >>222
お前の書き込みは、オブジェクト指向がクソだということが目的になっていて、
その他の何かが、オブジェクト指向よりも優れているという話になってない
229 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:35:08.38 ID:csv6kfNU.net]: >>221
優れた人が優れた道具を使う

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

優れてない人が、優れてない道具を使って勝つには
人海戦術しかないんだよね
230 名前：デフォルトの名無しさん [2018/09/24(月) 20:38:06.78 ID:Kxio7RVg.net]: ぜんぜん分かってないわ
刃物は道具でもあるし
人を殺すこともできる
231 名前：デフォルトの名無しさん [2018/09/24(月) 20:38:44.95 ID:Kxio7RVg.net]: あやまった使い方をすれば
簡単にｹｶﾞをする
232 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 20:42:45.07 ID:e4NBE4Fp.net]: >>223
いや、オブジェクト指向をクソだなんて思ってないよ。
むしろ好きな方なんで。

でも、肯定派の人ってありきでしょ。
それは違うかなって。
233 名前：デフォルトの名無しさん [2018/09/24(月) 20:50:20.68 ID:Kxio7RVg.net]: 教育ｺｽﾄはものすごいかかるが
手続き型言語でｵﾌﾞｼﾞｪｸﾄ指向をみっちり体験してから
ｵﾌﾞｼﾞｪｸﾄ指向の教育に移行したほうがいい

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

そうでないと
ID:csv6kfNU　←　ｺｲﾂ
みたいに頭悪いのが大量に量産され続ける
234 名前：デフォルトの名無しさん [2018/09/24(月) 21:03:48.14 ID:u7Hms91/.net]: >>228
バカにコストかけて教育するのもなんだかなー
バカとハサミは使いよう、というけれど、なかなか良い使いようが見つからんね。
235 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 21:19:43.39 ID:AdxflhqI.net]: オブジェクト指向のメリットって何？
この問いに今だかつて一人も答えてくれた事は無い
どっか他の文献指差して丸投げとか
逃げと食い下がりを駆使して結局答えないとか
236 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 21:47:42.62 ID:oYzwCf5A.net]: >>230
困ったことにどっかの文献ですら
ちゃんと理詰めで仕組みを解説してるものは皆無
完全なオカルトテクノロジー
237 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 21:48:43.99 ID:FEoaRsa5.net]: 低学歴は無理せずにＩＴ土方やってなさい
238 名前：デフォルトの名無しさん [2018/09/24(月) 23:07:18.05 ID:Kxio7RVg.net]: 転ばぬ先の杖
STOP ｵﾌﾞｼﾞｪｸﾄ指向
239 名前：デフォルトの名無しさん mailto:sage [2018/09/24(月) 23:31:05.04 ID:JEGqIfby.net]: >>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う
240 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 08:11:13.05 ID:ffbXNZny.net]: 色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか？
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ
241 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 08:46:47.22 ID:Eix7hoc3.net]: >>235
意味不明すぎてふいた
242 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 08:48:25.26 ID:Eix7hoc3.net]: オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ
243 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 08:48:47.92 ID:Eix7hoc3.net]: わかってんのかお前ら
244 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 11:00:50.48 ID:bhDxFTjN.net]: さっぱりわからない
オブジェクト指向のメリットとか特に
245 名前：デフォルトの名無しさん [2018/09/25(火) 12:27:26.16 ID:6l+mHu1d.net]: ぶち込んだ経験ないやつには難しいやろな
246 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 12:30:49.14 ID:Ti214GxU.net]: オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた！
247 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 15:04:59.78 ID:GnoTTlW7.net]: >>215
＞オブジェクト指向って何ですか？
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む

＞C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい
248 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 15:05:47.22 ID:GnoTTlW7.net]: >>230
＞オブジェクト指向のメリット
プログラムの変更コストが下がること
249 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 17:07:50.15 ID:bhDxFTjN.net]: >>243
どういう理由で？
オブジェクト単位に分けると仕様が消えるの？
250 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 18:10:21.54 ID:GnoTTlW7.net]: >>244
疎結合になるから
251 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 18:52:32.16 ID:bhDxFTjN.net]: >>245
それって君が想定した変更のときだけだよね？
252 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 18:58:18.78 ID:bhDxFTjN.net]: そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね？
無意味じゃない？
253 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:02:25.86 ID:GnoTTlW7.net]: >>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい
254 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:05:45.05 ID:bhDxFTjN.net]: >>248
別れてるからこそ変更しにくいって状況になったことがない？
経験不足じゃない？
255 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:10:47.09 ID:bhDxFTjN.net]: 例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと

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

こういうの想像できないの？
レベル低くね？
256 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:16:48.81 ID:GnoTTlW7.net]: >>249
いやいやそれこそ
オブジェクト指向開発での経験不足
257 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:22:34.13 ID:GnoTTlW7.net]: >>250
＞ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト（クラス）にする

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

この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる
258 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:28:22.29 ID:bhDxFTjN.net]: >>252
って変更を各オブジェクトに入れないとできないよね？
c言語だと普通に処理書くだけやで
259 名前：デフォルトの名無しさん [2018/09/25(火) 19:40:26.69 ID:du+nhKJd.net]: オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする
260 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 19:54:06.59 ID:o8KZiItl.net]: これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと
261 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 20:13:12.32 ID:BMMTvniR.net]: データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない

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

オブジェクト指向は従来
262 名前：のやり方でも可能ではあるが 大変なことをより分かりやすく簡単に実現するための技術 []: [ここ壊れてます]
263 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 20:53:51.26 ID:GnoTTlW7.net]: >>253
＞c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい
264 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 21:06:16.95 ID:BMMTvniR.net]: オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない
265 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 21:51:35.20 ID:CZcrESgD.net]: 強制的にOOに慣れるためのプログラミングスタイル、ってありませんか？
266 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 21:56:25.48 ID:GnoTTlW7.net]: >>259
OOコード養成ギブス
d.hatena.ne.jp/akkt/20080424/1209051266
267 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 22:15:26.66 ID:CZcrESgD.net]: >>260
thx a lot !!!
268 名前：デフォルトの名無しさん mailto:sage [2018/09/25(火) 22:46:19.22 ID:FLKmzsJJ.net]: >>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと（自分の勘違いを）批判してる

こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい
269 名前：デフォルトの名無しさん [2018/09/25(火) 22:57:23.11 ID:BRabQ1iT.net]: 流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか？
270 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 00:31:24.02 ID:bs5egenN.net]: オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ

まあ嘘である
271 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 00:44:41.52 ID:bs5egenN.net]: >>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな
272 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 04:39:27.51 ID:8XNtqdsN.net]: セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。

おれの居るところ真逆のプロジェクトだ使いまくりでワロタ
273 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 06:02:50.00 ID:Jt0rVGX1.net]: セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな？
274 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 08:59:38.32 ID:cdctReAr.net]: >267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない
275 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 21:23:07.74 ID:2wWeimMK.net]: >>268
納得できる説明なのにおかしな改行で台無し・・・
276 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 22:10:14.19 ID:Ye0laooE.net]: メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。
277 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 22:27:48.39 ID:xMAwDWlb.net]: ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ

同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合した�
278 名前：謔､な糞 []: [ここ壊れてます]
279 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 22:42:34.06 ID:yzZF1GUc.net]: >>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ

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

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

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

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

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

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

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

しかたないね。人間だもの
280 名前：デフォルトの名無しさん mailto:sage [2018/09/26(水) 23:05:14.04 ID:xMAwDWlb.net]: > メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> （以下ポエム略）

？？
なぜそれを俺にレスしたのか不明
281 名前：デフォルトの名無しさん [2018/09/26(水) 23:25:48.93 ID:+un+mAjX.net]: むしろおまえ以外の誰にレスしろというのか不明w
282 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 00:13:38.88 ID:oacq4Bqj.net]: だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな
283 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 00:30:43.91 ID:Fk1HpByz.net]: >>275
つまり、

× getter/setterが悪い
○ getter/setterの間違った使い方が悪い
284 名前：デフォルトの名無しさん [2018/09/27(木) 00:35:00.12 ID:pq96CSzd.net]: 刺身にﾀﾝﾎﾟﾎﾟのせてるﾔﾂが
ちゃんとｷﾘｷﾘ働いてるか
その働きぶりをたまに覗きたいことはある

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

使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ
286 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 00:54:06.21 ID:oacq4Bqj.net]: >>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。
287 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:41:53.45 ID:DSKWvsHE.net]: いや、単純に�
288 名前：Iブジェクト指向なんてやったって地獄に落ちるだけ クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ 単純にプログラムを 入力→処理→出力 という繰り返しの塊にしなければならない メソッドを呼ぶたびに状態が変化 するようなもん誰も管理できない []: [ここ壊れてます]
289 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:45:45.45 ID:oacq4Bqj.net]: オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか
290 名前：デフォルトの名無しさん [2018/09/27(木) 01:46:43.86 ID:pq96CSzd.net]: ｵﾌﾞｼﾞｪｸﾄ指向でも
詳細化したらﾃﾞｰﾀﾌﾛｰ図に落とせる設計でないと
お話にならない
291 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:47:55.67 ID:DSKWvsHE.net]: 状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か？
292 名前：デフォルトの名無しさん [2018/09/27(木) 01:50:10.34 ID:pq96CSzd.net]: 以前(>>161)にも書いたとおり
ｺﾚ以外方法はない

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

　①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
　②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
　③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
　　※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
　④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
　　処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
　　（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
　⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止

ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる
293 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:52:11.89 ID:DSKWvsHE.net]: 単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん

こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか？
というぐらい一切メリットがない
294 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:54:14.64 ID:DSKWvsHE.net]: >>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ
295 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 01:58:10.12 ID:oacq4Bqj.net]: もう今日は寝ろよﾊｹﾞども
ﾉｼ
296 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 02:02:11.90 ID:oacq4Bqj.net]: 単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ
297 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 02:41:53.03 ID:y/NaeiDF.net]: 割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする
298 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 02:47:01.34 ID:Fk1HpByz.net]: そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってこと�
299 名前：ｳ、AHAHAHAHA～ []: [ここ壊れてます]
300 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 03:51:07.23 ID:fvjtmZUM.net]: >>260
部分的に構造化プログラミング養成ギプスのような気がする
301 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 03:53:07.34 ID:fvjtmZUM.net]: メソッドを呼び出す順番に依存してはならない
302 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 07:40:33.24 ID:zZL/tnLy.net]: >>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。

内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。
303 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 08:19:49.02 ID:emgF57xx.net]: 状態を持つなって言ってるのは関数型の考えから？
常にオブジェクト指向言語の方がメジャーなんだが
304 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 08:20:57.92 ID:BciEc+9A.net]: 昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。

結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。
305 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 08:24:56.86 ID:emgF57xx.net]: グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと
306 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:26:17.13 ID:DSKWvsHE.net]: >>294
状態を持つと単純にテストがしにくい

あるクラスにprivateでドキュメントにも記述のないメンバ変数が10個あって
その内包するクラスにもメンバが10個あって・・・なんてプログラムだと
そのクラスの持つ状態は10*10*・・・
みたいに増えていく
完璧にプログラムを制御しようとすると
その全てを把握しなければならない
実際にはそれは不可能なのでオブジェクト指向的に組んだプログラムはそもそもバグっている
307 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:32:35.44 ID:wRik+4En.net]: >>295
あんたは使うべきの意味を理解してないよ
使うべきっていうのは今も一緒。

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

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

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

今はインターフェース（名前）を変えることなく、フィールドからgetter/setterに変更できるので
言われてないだけ。でもこれはプロパティを備えた言語に限った話
308 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:32:48.24 ID:DSKWvsHE.net]: んで思うのが
どうもアメリカらしくないなと
あれだけメリットとデメリットと数値化にこだわる国がなんでこんな丼勘定やねんと

オブジェクト指向なんて出回った頃にはもうすでに向こうではプログラミングは
無意味な公共事業の一環になっていたのではないか？
そしてそれにはもはや意味がなくて
できるだけ時間がかかる方法だけが採用されたと
309 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:34:56.57 ID:wRik+4En.net]: >>297
オブジェクトが状態を持つとテストがしにくいからといって
オブジェクトに状態を持たせなかったとしても、
状態を持ってるアプリケーションから状態を消し去ることは不可能なわけで
どこかに状態が存在するので、結局その部分のテストはしにくくなるよ
単にテストしにくい場所が変わるだけの話
310 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:35:52.22 ID:wRik+4En.net]: >>299
メリットとデメリットにこだわってるから
オブジェクト指向を使ってるのでは？
311 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:45:20.17 ID:DSKWvsHE.net]: >>300
まず、それが見えているかどうかが問題
引数から渡す形ならドキュメントに記述を強制できる
さらに同じ引数で実行したらなるべく同じ結果が返って来ることも保証できる
これで気をつけるのはファイルアクセスやDBアクセス、日時、通信などに限定できる
オブジェクト指向は全てのクラスが失敗作であると言える
312 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 09:59:43.55 ID:wRik+4En.net]: >>302
いや、どんな言語で作ろうが、
アドベンチャーのフラグ管理は大変だよ
関数型言語なんか、実装が不可能なレベル
313 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 10:51:21.68 ID:zzHSqWZa.net]: オブジェクト指向を捨てたGO言語を使おうってこと？
314 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 11:05:48.54 ID:fvjtmZUM.net]: 実は倍精度浮動小数点数のインスタンス変数があったら2^64個の状態があるって話だ
もしくは10x10x10と10+10+10がほぼ一緒の値という主張だよ
315 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 11:44:32.68 ID:emgF57xx.net]: >>297
そんなことない

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

むしろ関数型で複雑な状態遷移を実装するのは難しい
現にゲーム制作ではぜんぜん関数型が流行ってないからな
316 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 11:52:41.46 ID:DSKWvsHE.net]: >>306
理由が全くねーじゃん
317 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:15:48.09 ID:zzHSqWZa.net]: >>306
何年か前にOOPのそのトレーニングやったけど
今にして思えばおかしなことをしてたなって思う

素直にGO使ったほうがいいよ
今は制約を気にせず非常に楽にコードが書ける
それでいてOOPのころの糞コードからかなり離れている
GOのおかげ
318 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:17:39.22 ID:zzHSqWZa.net]: GOのtypeは非常に見通しがいい
c/c++のヘッダファイルはなんだったのかと
319 名前：デフォルトの名無しさん [2018/09/27(木) 12:19:15.86 ID:99b9Jx0M.net]: 状態を持たないオブジェクトwww
もはやオブジェクトちゃうやんw何の受け売りやそれw
320 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:24:21.66 ID:nvNAA/EB.net]: アクセスパターンを限定化する
これを理解出来ないなら
オブジェクト思考プログラミングはし無い方が良い
どういう訳か
凄まじい自信の有る人程解っていない
というのがこの界隈
321 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:31:34.84 ID:zzHSqWZa.net]: OOPで良いとされているが一番の間違いは
単機能の小さなクラスを沢山作ること

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

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

内部の状態に依存せず単機能でいいなら関数でつくればいいと気が付いた
322 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:37:21.63 ID:emgF57xx.net]: >>310
不変オブジェクトがあっても別にいい

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

クラスの数を大きくして数を減らしてしまうと
作るときは一見楽に見えても後で変更コストが上がる
323 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:43:37.80 ID:tnNln14X.net]: >>313
それはOOP自体が悪いからそう見えるだけ
クラス数の爆発のほうが本当の害悪

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

クラスが一ファイル内にないといけないその言語の制約だろう
パッケージ内に在ればいい言語に乗り換えよう
324 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:47:39.73 ID:tnNln14X.net]: クラスが小さいと困ることがある
インスタンス変数を２つに絞るのは愚か
確実にクラス設計が困難になる

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

中程度のクラスにある程度必要とされる変数が入れておく方が開発工数は減る
325 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:49:58.82 ID:tnNln14X.net]: 状態を持たない
そもそもが小さい
ならクラスじゃなくて関数を使え
326 名前：デフォルトの名無しさん [2018/09/27(木) 12:53:47.09 ID:99b9Jx0M.net]: >>313
不変ゆうんは状態を持つから不変なんやぞw
受け売りでイキるのやめときw
327 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 12:55:53.67 ID:tnNln14X.net]: >>260
改めて書くけどこれはほとんどがもう古いし
本当の意味でOOPの弱点をカバーしてない
328 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 13:18:51.56 ID:M9UbUXxK.net]: TCP接続をOOPで書くとして、オブジェクトの外側でTCPの例の状態遷移を気にする必要あるんかいな
329 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 14:18:04.82 ID:mMx24hKT.net]: 不変オブジェクト自体が一つの状態であることは確かだと思うが、語弊がありそうだな。
可換原則的には互換性のある小さなクラスをたくさん作る、が正しいだろうけど、
実際にそれすると、とんでもないバカが現れて瞬時に全壊するのも見たことあるし。
やっぱり一概には言えないと思うわ。
330 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 14:21:34.40 ID:emgF57xx.net]: >>316
関数でもいい場合はあるが
クラスにするメリットもある

>>317
それは難癖でしかない
再代入しないことによって
状態変化のデメリットが生じないので問題ない
331 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 15:03:29.89 ID:DSKWvsHE.net]: >>319
気にする必要が無いように組んでもいいし組まなくてもいい
でもテストは全状態に対して行わなくてはならない
現状はおそらくそれをやってる奴が少ないのがまずい
ここではさもやるのが当然とばかりに主張はするがそのテスト方法は提案すら挙げられない雑魚
332 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 15:09:59.98 ID:wRik+4En.net]: はっきりさせておかないといけないのは
オブジェクト指向と関数型で条件が違う比較をしてるってこと

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

アプリケーションから状態をなくすのは不可能なので
「関数型言語で状態を扱う問題」を解かなければいけないのだが
なぜか状態はすべてなくすことができるんだという間違った前提で
状態がない優しい問題を解いているだけになってる
333 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 15:43:16.13 ID:emgF57xx.net]: >>323
これはそうだな

状態遷移が複雑なシステムをどう組めばいいか
関数型主義者から具体案を聞いたことがないね
334 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 17:55:02.31 ID:34EufdvK.net]: おれは関数型主義じゃじゃないけど適切にルール組んでその通りにやればいいだけじゃないか？

関数型はオブジェクト内に状態が隠蔽されてないから
やりやすいだけ
335 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 17:57:15.64 ID:34EufdvK.net]: Cだと構造体がなければほぼ全部シグネチャーに書きださなければならなかったけど
関数型は関数で組み合わせてあるから楽なんだろうなとは思う
336 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 18:00:53.71 ID:34EufdvK.net]: オブジェクト指向でもやりようによっては状態の遷移がわかりやすくはかける
fluxとかじゃ状態はイミュータブル
actionを適用したらその都度新しい状態オブジェクトを作ってストアしてる
古い状態は書き換えられずに破棄される
337 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 19:04:14.07 ID:DZkTxoQs.net]: 状態が複雑になる場合もなるべく明示した方が嬉しいよねってのが関数型のスタンス
Haskellは状態を持つ部分をモナド型クラスのインスタンス(=型)にするし、ML系は非数値状態を型に持たせて型検査の形で明示する

個人的には基本関数型で組んで、状態が必要不可欠な問題に対しては意味論的に隠蔽されているのが正しいならprivateでそれ以外はミュータビリティと型で制御が妥当かなと
その後でパフォ
338 名前：ーマンスが必要ならその部分をミュータブルなクラスベースOOPにする []: [ここ壊れてます]
339 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 22:11:06.04 ID:y/NaeiDF.net]: >>324
まあ冒頭副作用的な臭いからひっぺがしのモナドが思いつくなこれは
340 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 22:52:16.03 ID:ojLVUDGL.net]: オブジェクト指向ってウェブサイトの構築以外でどうやって使うんだ？
phpとかrubyはわかるがjava、c#やらでどういうシステム作れるか教えて
341 名前：デフォルトの名無しさん [2018/09/27(木) 22:55:44.14 ID:pq96CSzd.net]: poco使ってc++でwebｻｰﾊﾞｰの振る舞い自体を組み込みで書く
342 名前：デフォルトの名無しさん mailto:sage [2018/09/27(木) 23:41:51.25 ID:emgF57xx.net]: >>330
＞オブジェクト指向ってウェブサイトの構築以外でどうやって使う
一般的なアプリケーション作成全般
よほど高速な実行速度が要求されるもの以外
343 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 00:59:07.19 ID:2dxGIytS.net]: そもそもｽﾄﾗｳﾌﾟﾄのC++がまずかったんだよ
344 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 01:09:58.28 ID:2dxGIytS.net]: >>324
functionalは状態の管理手法じゃないのになに言ってんだ。
functionalは構造の再帰的分割による細分化やリスト処理の宣言的記述に有効であって
状態は必要なければなるたけ持たないほうが良いのはいろはのイ、セオリーだぞ
そして状態遷移は本当に必要ならオブジェクト指向を流用するのではなく
状態をきちんと管理するんだよ。
それをgetter/setterで要らぬところに状態持ち込んでishaだのhasaだの言ってるから
子供にまで後ろ指差されて笑われるんだよ。
言っとくが別にオレはfunctionalﾏﾝｾｰじゃないぜ。
345 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 02:01:07.68 ID:HosvZzhg.net]: オブジェクト指向はWebよりjavaとかc#のイメージのが強いな
Webのがメジャーな人もいるのか
346 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 02:06:06.17 ID:EiOshXgh.net]: >>334
何言ってんの……？

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

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

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

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

本当馬鹿じゃないかと思う
347 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 05:08:03.15 ID:FhArznfq.net]: >>335
Spring, ASP.NET Core
348 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 08:02:53.14 ID:pE+2cSJR.net]: >>336
>何言ってんの……？

何言ってるか理解にすら至ってないようだな…
349 名前：デフォルトの名無しさん [2018/09/28(金) 08:05:29.06 ID:8utkG/Cm.net]: システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がおると聞いて
350 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 10:00:32.06 ID:bPXaydqo.net]: >>338
その「何言ってんの？」は

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

日本語の時点で
351 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 12:17:05.53 ID:pLiz6ELv.net]: オブジェクト内部に状態は持たないほうがいいと言うのは当たり前すぐる気がするけどね
352 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 12:54:45.76 ID:bPXaydqo.net]: >>341

そこは「オブジェクト外部に状態を持ったほうが良い」と言わなきゃだめ
状態をなくせるわけじゃないんだから
353 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 13:12:28.51 ID:GxtNhjDw.net]: オブジェクト外部に状態持っても、結局そのオブジェクトを包含している上位のオブジェクトがあるので、行き着くところは「アプリケーションオブジェクトの外部に状態を持ったほうが良い」ってならない？
どこでラインを引くかはセンスってことでOK？
354 名前：デフォルトの名無しさん [2018/09/28(金) 13:19:48.03 ID:1UhvtMTy.net]: 他のオブジェクトの持つ変数を必要とする事自体がおかしい。
必要な引数を渡したら、処理を任せて、必要な値をリターンさえしてもらえればよい。
355 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 13:32:05.28 ID:bPXaydqo.net]: >>343
そのアプリケーションオブジェクトの外部ってのが
なんのことかわからない。

ファイルに保存のことなのかもしれないが、保存するま
356 名前：では 総てのデータはアプリケーション内部にあるわけで 結局、仮想的なストレージ（ようするにメモリ）に 保存するしか無いでしょう？ []: [ここ壊れてます]
357 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 15:21:40.87 ID:GxtNhjDw.net]: >>345
そうだよ、俺もそう思うのでアプリの外に状態はあり得ないだろうと。
なのでどこかで線引きをしないといけないんだけど、結局それはセンスという便利かつ曖昧なな言葉で片付けられちゃいそう。
358 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 18:23:35.77 ID:KV7CiVPs.net]: >>343
ん？それでテストできるならやれば？
実際は制御不能でしょ？
だから駄目だって言ってんの
359 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 18:37:56.35 ID:++iDCvgk.net]: >>347
んんん？
じゃ、具体的にアプリケーションオブジェクト以下に状態を一切持たなくてどうやって実装するのん？
BrowserでもOfficeでもいいから、一般的なアプリでアプリケーションオブジェクト外部に通信中にファイルオープン済みか否かやなんやらかんやら全ての状態を無理せず実装するエレガントな方法教えて。
一切の状態をアプリに持ってたら駄目だよ。
いくらなんでもこれは反論する自信あるわ。
360 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 18:41:30.51 ID:++iDCvgk.net]: >>347
分かってると思うけど、今どの画面が表示されてるとか項目の何が選択されてるかも全て状態だからね。
さぁ、エレガントな説明してみて。
361 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 18:57:00.64 ID:/ke/2lv3.net]: いつまでずれた馬鹿な話してんの？

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

犬クラス内部に状態があって同じメソッドを使ってても動作変わってるのが厄介だと言ってるんだろ
それがわからないのかなあ？
362 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:01:55.81 ID:/ke/2lv3.net]: ポチはたまたま病気だとわかったけど
わからなかったら何で半分しか食べないのかわからない

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

未来のテクノロジーでその時の内部状態を再現した無数のポチを作って条件に分けて
えさやり動作チェックするなんて考えただけでも寒気がする
363 名前：デフォルトの名無しさん [2018/09/28(金) 19:02:47.77 ID:1UhvtMTy.net]: それはポリモーフィズムを理解してないだけでは。
364 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:03:10.43 ID:++iDCvgk.net]: >>350
厄介だけど、どこかのレイヤで病気か否の状態は必要だろ？
それがアプリケーションレイヤよりさらに上なんてのはあり得ない。
365 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:08:25.24 ID:++iDCvgk.net]: ポリモーフィズムは参照先インスタンスに依存するので、それは間接的とはいえ状態そのものやね。
366 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:11:12.35 ID:/ke/2lv3.net]: >>353
だから対象オブジェクト内部に値を持たせないで関数のシグネチャーにして渡せと

関数に
病気かどうか
失恋かどうか
気分が悪いかどうか
前食べてからどのぐらい時間がたったか
と餌の量を値として渡せと
367 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:13:30.49 ID:++iDCvgk.net]: >>355
そのシグニチャを渡すのは誰？
全ての状態を人間であるユーザーが渡すのん？
368 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:18:47.60 ID:/ke/2lv3.net]: >>356
関数を使うものが渡す
その関数は勝手に知らない場所にある値を使わない
同じ値の組を与えたら必ず同じ値を返す
369 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:19:57.74 ID:UT33gEiF.net]: >>348
え？誰がそんなこと言ったの？
内部に持ってアクセスできないのが駄目だって何度も言ってるじゃん
関数実行したら出力全部出せよ
同じ引数で実行したら絶対同じ結果を返せ
370 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:22:08.98 ID:++iDCvgk.net]: >>357
関数を使う、突き詰めればOfficeのユーザーがどの設定画面のどのタブでどのチェックボックスが有効でどのボタンを押したかを一度に伝えるのん？
俺はそんなことはしてないなぁ。
少なくともどの画面が表示されてて何が選択されてるかはアプリの状態に依存してるわ。
371 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:23:07.62 ID:TedNHSTO.net]: 犬に餌をやらなくても満腹にできる魔法
372 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:24:11.70 ID:/ke/2lv3.net]: 何でモデルとアプリの状態の話を混同してるかがわからない
373 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:25:06.97 ID:++iDCvgk.net]: >>358
OKボタン押したら絶対に同じ結果になるのん？？
仮に条件によりOKボタンが押せないなら、それはOKボタンを押せない条件がアプリにあるってことになる。
374 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:32:21.07 ID:++iDCvgk.net]: >>362
普通は分かるけどへんに誤解があるかもなので訂正。
誤　OKボタンを押せない条件
正　OKボタンを押せない状態
375 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:36:02.78 ID:UT33gEiF.net]: >>362
引数は同じなの？
お前さっきから人の話聞いてるのか？
376 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:37:20.39 ID:UT33gEiF.net]: >>362
そもそもお前のアプリって
同じ画像保存してもクリックするたび画像変わるんだろ？
さっさとクビ吊れよ
377 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:38:21.84 ID:++iDCvgk.net]: 俺がはなっから言ってるのは、アプリ以下のどこかに状態は必要なはずで、それよりも外に状態を追い出すのは無理があるってことだけ。
378 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:39:58.48 ID:++iDCvgk.net]: >>365
お前のアプリは画像選択もしてないのに突然エロ画像表示するのかw
児ポで捕まっとけw
379 名前：デフォルトの名無しさん [2018/09/28(金) 19:44:25.53 ID:+9bdVI5n.net]: システムの状態とオブジェクトの状態をごちゃまぜにしちゃう無能がハッスルしちゃっとると聞いてw
380 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:45:26.35 ID:/X9jOxDh.net]: >>323-324
それな
関数型言語っつうのも所詮そんなもん
381 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:47:14.39 ID:++iDCvgk.net]: システム、つまりアプリの状態は少なくともアプリケーションオブジェクト以下が制御してるので、全てのオブジェクトが状態を管理しないってのは無理があるって話。
最初からそう言ってる。
382 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 19:50:57.15 ID:lTwZu9zK.net]: つか関数型餌やりだと餌やり関数から出力される犬は入力された犬のクローンじゃないのか？
383 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:15:03.29 ID:UT33gEiF.net]: >>366
理由は？
outputでstatusも出しゃいいじゃん
ハイ、論破
384 名前：デフォルトの名無しさん [2018/09/28(金) 20:18:19.44 ID:+9bdVI5n.net]: >>371にどう答えるかでバカのレベルが計れるw
いまのとこ華麗にスルーした>>372がキングやねw
385 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:20:36.12 ID:++iDCvgk.net]: >>372
具体的にどんな大多数のアプリがそう実装してるの？
悪魔の証明を避けるにはお前に実証責任があるからね。
386 名前：デフォルトの名無しさん [2018/09/28(金) 20:21:59.66 ID:+9bdVI5n.net]: >>374
今はおまえがしゃべっていい時間やないで
387 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:23:45.55 ID:++iDCvgk.net]: >>375
あ、すんません。
誰が喋っていい時間なのかよく分からないけど黙っときます。
388 名前：デフォルトの名無しさん [2018/09/28(金) 20:25:39.72 ID:+9bdVI5n.net]: >>376
うむ、おまえは既に名誉バカの称号を持っとるからここに参戦すべきやない
すこしおとなしくしとけ
389 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:26:26.12 ID:++iDCvgk.net]: >>377
あい、すんません。
390 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:28:27.44 ID:UT33gEiF.net]: >>374
c言語でグローバル変数使わなかったら他どんな組み方があるの？
引数か戻り値で渡すしかないでしょ？
グローバル変数使用禁止が作法のように語られてたんだから
昔の人は何をするべきかわかってたんだよ
391 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 20:56:14.71 ID:/X9jOxDh.net]: OOPは糞かもしれんが
じゃあ何がいいのかと言われたら別に他にこれといってないのが現状
392 名前：デフォルトの名無しさん [2018/09/28(金) 21:12:44.75 ID:k5h2WtG4.net]: 頭悪いﾔﾂにかぎって
うれしがってなんでも継承して抽象化とかいってるからな

ﾎﾓを人間ｸﾗｽから派生するぐらい愚かなことやってる
393 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:16:43.74 ID:l603LAAk.net]: 基本は当たり前すぎて、階層化であり局所化であり
順序回的な「無用な」状態保持は極力回避し組みあわせ回路的・関数的
394 名前：構造にし、、、、 関連はﾈｯﾄワーク構造よりもツリー構造を指向して見通しよくし、 関連性の強い物は近くにおき(遠くのファイルからあちこち継承してクロスファイルでmethod取り込むようなことはせず)、 といった、、、アー効けく茶後期ﾂのための基本セオリー。 その表現技法は言語のパラダイムによって変わるだろう。 問題はオブジェクト指向がそういった基本セオリーに反するような手法として普及してしまったことだよ。 []: [ここ壊れてます]
395 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:17:57.02 ID:l603LAAk.net]: >>382 ひでえ誤字すまん
×「アー効けく茶後期ﾂ」
○「アーキテクチャー構築」
396 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:23:02.60 ID:/X9jOxDh.net]: なんでコイツ急にポエりだしたん？
397 名前：デフォルトの名無しさん [2018/09/28(金) 21:25:30.29 ID:k5h2WtG4.net]: ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない
398 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:27:24.36 ID:l603LAAk.net]: たとえば関数型であれば、クロージャーや部分適用を使うことにより、
クラスをｲﾛｲﾛ作ったり状態instance変数でオブジェクトに特徴をもたせ分けるより
非常にシンプルに表現できるし、
また、解法を関数の段階的細分化で構成することにより、
内側の回関数は小さくなるにつれ速やかに単純な構造になる上、
(再帰も含めた)関数呼び出しの引数リストと帰り値のスタック階層および局所変数が、
自然と個々の階層の参照する「近くにあるべき」状態を単純な木構増階層のかたちで保持できる。

ちなみに上にも書いたけど俺はfunctinalﾏﾝｾｰじゃないからな。
399 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:29:55.72 ID:l603LAAk.net]: >>385
俺の周りでは、素人に毛がはえたか分からんような又派遣さんが、
専門学校でインチキ教わったのか知らないが、
そういう薀蓄をたれながら、くそコード量産して要らぬバグ入れて
残業大会やってるよ
400 名前：デフォルトの名無しさん [2018/09/28(金) 21:33:34.54 ID:k5h2WtG4.net]: あえていえば
できるだけ自律的であることが適切で
なおかつそのようにほぼ自律的に振舞うように実装されていれば
内部状態が保持されることは実装として適切

ただし、すべて外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持することは
適切な理由がないかぎり、できるだけ避けるべきといっていい
401 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:35:43.41 ID:l603LAAk.net]: 問題によってどうしても必要な内部状態というものはあるからな。
そこまでだれも否定はしてない
402 名前：デフォルトの名無しさん [2018/09/28(金) 21:36:39.96 ID:k5h2WtG4.net]: 刺身の上にﾀﾝﾎﾟﾎﾟ乗せる作業なんか
ほっといってもいい

そのｸﾗｽだけでほぼ完結できる
403 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 21:37:59.71 ID:/X9jOxDh.net]: > 外部的な要因で翻弄される続けるｵﾌﾞｼﾞｪｸﾄが内部状態を保持する

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

java.awt.Graphicsみたいなコンテクストオブジェクトをグニグニいじったり
java.lang.StringBuilderのようなビルだオブジェクトをグニグニいじったり
そういうところこそにOOPの楽しみがあるように俺には少し思えるんだ
404 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:12:55.17 ID:bBdkrZUa.net]: ボタンやチェックボックスがGUIの共通の振る舞いを制御する親クラスがいるのはC++で書かれる前から実装継承するように設計されていた。

一方、普通預金、当座預金、定期預金の共通関数があったとして、預金というスーパークラスを書いているシステムはないぞ。メガバンクの情報系であってもな。
405 名前：デフォルトの名無しさん [2018/09/28(金) 22:24:55.23 ID:+9bdVI5n.net]: お、キングを抜いた奴がでたでw
今は>>389がバカキングなw
406 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 22:51:26.95 ID:HosvZzhg.net]: >>259
OOコード養成ギブ�
407 名前：X http://d.hatena.ne.jp/akkt/20080424/1209051266 置いとくぞ忘れてはならない戒め []: [ここ壊れてます]
408 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 23:17:45.51 ID:EiOshXgh.net]: >>394
>>260
409 名前：デフォルトの名無しさん mailto:sage [2018/09/28(金) 23:49:37.69 ID:/ke/2lv3.net]: 普通はそれってオブジェクト指向エクササイズっていうんだけど
同じ表現だから同じひとなんじゃないかな
410 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 01:23:56.63 ID:NuLdKSCl.net]: そいやオブジェクト指向てデザパタとかメジャーなのに肝心のこっちは影が薄いな
411 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 01:57:58.03 ID:MMtb4Amd.net]: プロパティとはなんと罪深い発明か
412 名前：デフォルトの名無しさん [2018/09/29(土) 02:12:47.80 ID:IuTgmxg/.net]: ﾊﾞｶでも作れる処理は
入力の構造体と出力の構造体を関数に渡す程度で済む処理
413 名前：デフォルトの名無しさん mailto:sage [2018/09/29(土) 09:11:35.70 ID:nymKFaQh.net]: >>398
IDEと組み合わせるには相性がよかったのかもね
あと典型的なGUIのパーツであるとか
インスペクトしたときズラズラっと出るのが気持ち良いような物に対しては
414 名前：デフォルトの名無しさん [2018/09/30(日) 01:13:02.43 ID:2u8tHsEV.net]: age
415 名前：デフォルトの名無しさん mailto:hage [2018/10/02(火) 00:59:29.31 ID:clFFurIb.net]: https://qiita.com/raccy/items/58254f842788707f8c53
416 名前：デフォルトの名無しさん [2018/10/02(火) 01:05:20.08 ID:A7JQSPUH.net]: 考察が浅い
417 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 01:13:19.56 ID:HjCi0xKJ.net]: 長すぎるから産業
418 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 07:20:53.80 ID:JB7ad13/.net]: >>403
確かに浅いな
オブジェクト指向のメリットは全くわからなかった
解説してる内容もそもそもクラスを使う側が構造を知ってないと使えない例で書かれてて笑う
419 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 07:35:05.76 ID:ju0/OZW1.net]: キータって参考になる記事あんまりないんだよな。ある程度の知識もっているのが前提になってるし
プログラミング関連で検索すると常に上位でヒットするのが嫌だわ
420 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 09:44:25.77 ID:3qG7W8x7.net]: >>402
こういう嘘歴史書いて悦に入っちゃう自称識者のほうがゴリラみたいな底辺コンサルよりずっと始末が悪い
421 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 10:15:48.80 ID:ti/Lih16.net]: 見た目が？何がゴリラなん？
422 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 10:49:30.13 ID:6qOrAQgQ.net]: 力だろ？
423 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 12:34:43.67 ID:AvMzrL7k.net]: ゴリラコンサルの所業

朝礼で歌を歌わせる、挨拶の練習
○○（会社の名前）イズムの継承と言ってブラック労働を肯定する
定期的に変なセミナーに通わされる
424 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 15:30:45.55 ID:/tnW96SL.net]: 知能がゴリラ
425 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 18:20:49.67 ID:/RdnJML/.net]: qiita.comは動機が不明
なぜ頼まれもしないのに不確かな二次情報を書き散らすのか
なぜ頼まれもしないのにノイズをせっせとネットに増やすのか
あれってお金でももらって記事を書いてるのか？

stackoverflow.comは単純
質問者がいて、答えてあげたい人が要る
質問にも回答にも評価がされるようになっており
有益な情報が共有できるようにつくられてる
質問者、回答者、閲覧者の動機がよくわかる
426 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 18:28:36.78 ID:6qOrAQgQ.net]: 評価ならqiitaでもされるだろ
427 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 19:04:58.66 ID:TcNkDYl8.net]: stackoverflow で答えてあげたい人と大差ないだろ
428 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 19:39:52.33 ID:YrRJAaFS.net]: 承認欲求なのです・・・
429 名前：デフォルトの名無しさん [2018/10/02(火) 19:50:57.77 ID:eaArETqj.net]: 教えたがりのクズのくせに答えたあげたいとか言っちゃう気持ち悪さw
430 名前：デフォルトの名無しさん mailto:sage [2018/ ]: [ここ壊れてます]
431 名前：10/02(火) 19:56:41.61 ID:YaWzkSZx.net mailto: >>412
書いたことあるけど、昔はもうちょっと面白い場だった。
こんなの面白かったよ、とか試してみた、とか。
今は何かというとポエムやら言う奴が出てきたり、本気でレベル低い人も何番煎じかわからん記事書いたりして、収拾ついてない。
コミュニティとしては死んでいってると思う。 []: [ここ壊れてます]
432 名前：デフォルトの名無しさん [2018/10/02(火) 19:59:28.60 ID:Weccy6g3.net]: >>412は便所の落書きのアホさ加減が光る書き込み
433 名前：デフォルトの名無しさん [2018/10/02(火) 20:06:51.71 ID:eaArETqj.net]: 昔は良かったボクちゃんw
434 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 20:24:30.19 ID:JlZ/oy05.net]: qiitaはメモ帳として結構便利
家で調べて纏めて仕事ですぐ使えるようにする
githubにテンプレートを置いとくと尚良
435 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 20:28:55.64 ID:6qOrAQgQ.net]: gistつかえよ
436 名前：デフォルトの名無しさん mailto:hage [2018/10/02(火) 20:30:00.28 ID:clFFurIb.net]: 俺は結構便利だと思ってるけどな
新しいことのとっかかりにしたり
頭の中にない情報を得るのに使ってるわ

まあゴミ記事も多いけど
437 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 20:35:43.11 ID:YrRJAaFS.net]: 技術的な事読みたいのにポエムばかり上位にくるqiita
438 名前：デフォルトの名無しさん [2018/10/02(火) 20:38:05.56 ID:eaArETqj.net]: そもそもなんでqiita検索しとんねんwアホやろw
439 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 20:43:51.32 ID:YrRJAaFS.net]: ほんの少しだけいい記事もある。

今オブジェクト指向に関するポエムが乱立してるのはアホみたいだがな。
440 名前：デフォルトの名無しさん [2018/10/02(火) 21:14:37.02 ID:R8M7QKDK.net]: qiitaみたいなしょうもない個人の日記帳読んでるﾔﾂいるの
441 名前：デフォルトの名無しさん [2018/10/02(火) 21:27:51.22 ID:WxkRXB6W.net]: 個人の日記帳として読んでる
442 名前：デフォルトの名無しさん [2018/10/02(火) 22:21:33.48 ID:HWestuUb.net]: 5chみたいな便所落書き読んでる奴いるの？
443 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 22:35:01.96 ID:/RdnJML/.net]: 便所の落書きはむしろ健全なんだよ
書くほうも読むほうももうそれは分かってるから

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

ほんとそれ
検索結果を汚すのはもうやめて…
つべの歌ってみたレベルで悲しい
444 名前：デフォルトの名無しさん [2018/10/02(火) 22:35:39.44 ID:BVvmn2A/.net]: そんなことは自己紹介板に書きなよ
445 名前：デフォルトの名無しさん [2018/10/02(火) 22:37:06.75 ID:BVvmn2A/.net]: >>430は>>428宛
446 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 22:49:52.65 ID:m0qWbxoK.net]: 何か上から目線だけどどこのサイトでもいいから
自分で正しいこと書けばいいんじゃないの？

それで次に言うのは
「ゴミポエムだらけでオレの記事が正しく評価されない」
447 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 22:55:41.37 ID:YrRJAaFS.net]: ゴミポエムだらけでオレの記事が正しく評価されない
448 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:00:45.18 ID:1/02bXao.net]: >>432
結果として自分のブログに戻ったよ、俺は。
まあゴミに埋もれる程度ならその程度の評価だと思うし。
449 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:02:07.94 ID:/RdnJML/.net]: > 自分で正しいこと書けばいいんじゃないの？

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

歌ってみた？歌わんでいい
書いてみた？書かんでいい
450 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:07:36.42 ID:YrRJAaFS.net]: >>435
有益な情報はどこで仕入れてるの
451 名前：デフォルトの名無しさん [2018/10/02(火) 23:26:49.40 ID:R8M7QKDK.net]: ｵﾚのﾚｽは有益
452 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:29:31.38 ID:LVKvBfXE.net]: 全てを分かってるやつが嘘っぱちを自信満々で流すのが厄介
453 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:34:15.18 ID:YrRJAaFS.net]: そこはわかってない奴じゃないのか？
454 名前：デフォルトの名無しさん mailto:sage [2018/10/02(火) 23:59:13.66 ID:LVKvBfXE.net]: >>439
ワザと嘘を流す奴がいる
455 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 00:49:14.98 ID:p3pJJViF.net]: そんな奴は他の奴に指摘されて恥をかくのさ。
456 名前：デフォルトの名無しさん [2018/10/03(水) 00:59:18.00 ID:75/JdiDV.net]: オブジェクト指向とは何で
何が良くて
何が悪くて
そしてどうしたらよかったのかとか
纏められるといいんだけれどもねえ
457 名前：デフォルトの名無しさん [2018/10/03(水) 01:01:35.24 ID:75/JdiDV.net]: 目的指向というより
458 名前：も 手段指向というか方法論指向で始終しちゃって 明後日の方向に愚民を導いて 混乱をもたらしたのは なんともむなしい []: [ここ壊れてます]
459 名前：デフォルトの名無しさん [2018/10/03(水) 01:03:16.82 ID:75/JdiDV.net]: 日本の失われた20年とちょうど時期が重なる
日本のITの暗黒時代
460 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 01:03:23.91 ID:Uljc2mte.net]: >>441
手強いよ
さらに誰に金もらってるのか
特定の言語や商品の悪評を流すことを目的としてるから
461 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 04:50:56.65 ID:gboWSeYU.net]: 260はいい記事やったけど402はイマイチやったな。てか全部読んでないけど
462 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 10:56:50.79 ID:gykQQ827.net]: 邪魔する奴の中に
単純に自分を有利にしておきたいから他人が自分の居るレベルまでこれ無い様に邪魔をする
という奴も居るからな
相対的な位置で報酬は決まるから他人を蹴落とす
というのを息をするようにやる奴がかなり居る
全体が進展するより停滞させて自分だけ有利にしようとする下劣な奴が結構居る
教育を変える必要が有るのに今のままでいい
とか言ってる奴もそういう連中
463 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 17:15:26.13 ID:bSsx2t9M.net]: >>412
stackoverflow.comって初めて知ったわ。
teratailよりいい？
464 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 17:55:44.54 ID:H+WLzHql.net]: >>448
teratailなんて比較対象にすらならない
465 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 19:12:16.15 ID:p3pJJViF.net]: stackoverflow人少なすぎない？
466 名前：デフォルトの名無しさん [2018/10/03(水) 19:23:56.48 ID:ksSGRyva.net]: まさか日本語版とかいうゴミ見てるんじゃないだろうな…まさかな…
467 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 19:32:35.85 ID:p3pJJViF.net]: 紹介されたから見に行ったら日本語版だったの
468 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 19:42:27.24 ID:bSsx2t9M.net]: 英語版なんて読めないよ・・・
コードはなんとなくわかるが質問文が
469 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 20:03:14.53 ID:OyXOgA+h.net]: >>444
その時期に書かれたコードでOOPを正しく実践してるものなんて見たこと無い
OOPが悪いのではなくOOPじゃなかったから悪いということになるな
470 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 20:24:40.36 ID:p3pJJViF.net]: 英語版いいな。情報量が圧倒的に多い。センキュー
471 名前：デフォルトの名無しさん [2018/10/03(水) 20:50:59.00 ID:L7SsoV0I.net]: 海外でHelp me, Stackoverflow. You’re my only hope.って書かれたTシャツ着たやつ見るくらい
472 名前：デフォルトの名無しさん [2018/10/03(水) 22:09:14.84 ID:2Mgu08sP.net]: >>454
今なら正しくOOPを実践してるコードばかりなの？
そもそも正しいOOPってどんなものなの？
第一デザパタは前の方がさかんに取りざたされていたじゃない。

振り返って今だからこそ分かるんじゃじゃないの？
世に流布していたOOPはくそコードを量産した元になったと。
473 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 23:08:05.48 ID:G0/tEBDY.net]: 我々はね、間違うのよ
だいたいのことを間違うの

OOPだから糞コードになったんじゃなくて
OOP関係なく、糞コードにしかならないの
その一点についてすら自覚が無いの
474 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 23:16:15.49 ID:p3pJJViF.net]: main関数から始まるc++はオブジェクト指向か？
（オブジェクト指向をちっとも理解してないものの意見です）
475 名前：デフォルトの名無しさん mailto:sage [2018/10/03(水) 23:39:24.91 ID:YTuGf5mm.net]: >>459
C++はオブジェクト指向（をサポートした）言語だよ
Cと違って継承や多態の機能が標準であるでしょ？
今からふり返ると中途半端な部分もあるけど

ただそのC++を使って書いたコードが
オブジェクト指向らしく書けているかは別の話
OOPとOOA（D）の違い
476 名前：デフォルトの名無しさん [2018/10/04(木) 00:22:43.55 ID:e2lTbi2R.net]: >>458
OOPの弊害について議論して来たの�
477 名前：ﾉ 「OOP関係なく、糞コードにしかならない」と言われると、 OOPは糞コードの元となる害なかった無関係だと暗にほのめかしているようで 論点をすり替えてずるくごまかされたような印象を受けるよ []: [ここ壊れてます]
478 名前：デフォルトの名無しさん mailto:sage [2018/10/04(木) 00:28:26.90 ID:bhAz8In7.net]: OOPが原因で糞コードになるんなら
どうすればいいか一目瞭然じゃん
よかったな世界が平和になって
479 名前：デフォルトの名無しさん [2018/10/04(木) 00:32:28.79 ID:e2lTbi2R.net]: 本当はいいものとなる筈だったのに、
ボタンを掛け違えたのか、変な使い方が一人歩きして普及しちゃったというか
なんというか、、、

最近は継承を廃止したり
他のパラダイムも併せた言語がどんどん出てきて
より良い解はいっぱい出て来るでしょう
480 名前：デフォルトの名無しさん mailto:sage [2018/10/04(木) 00:44:45.46 ID:s35zoLCp.net]: 継承の時にc++のprotectedは有害か？
481 名前：デフォルトの名無しさん [2018/10/04(木) 00:53:04.18 ID:e2lTbi2R.net]: んなもん使い方しだいにきまっとろうが
基本的に依存が込み入る元なので
十分静的に設計し尽くしてよほど律して使用するならともかく
変なテクニックを披露するため乱用したら害だろうな
悲惨だわ
482 名前：デフォルトの名無しさん mailto:sage [2018/10/04(木) 19:08:28.34 ID:bhAz8In7.net]: 典型的なフワフワ野郎やなこいつ
483 名前：デフォルトの名無しさん mailto:sage [2018/10/04(木) 21:04:04.79 ID:lUzJxSj8.net]: 関数型の弊害の話をしたら必然的にオブジェクト指向の弊害の話になると思うの
484 名前：デフォルトの名無しさん [2018/10/04(木) 21:07:13.85 ID:vhCji18k.net]: 弊害ちゃう元からおまえの頭が悪いだけや
485 名前：デフォルトの名無しさん [2018/10/05(金) 01:42:06.04 ID:GLbBoG3S.net]: これがオブジェクト指向を吹聴していた者たちの反論か…
科学的工学的有効性のかけらも無い
486 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 06:56:18.75 ID:u1B1EyaQ.net]: >>469
アアン!?
何ガン飛ばしてんじゃコラァ!

みたいなやり取りばっかだよねｗ
487 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 08:22:51.05 ID:jK12bSnX.net]: >>464
c++自体有害
488 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 10:34:10.65 ID:kQel6lTj.net]: >>467
オブジェクト指向と関数型に何の関係があるんだ？
489 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 10:55:46.34 ID:4oQp/Mop.net]: >>472
プログラミングパラダイムという同じ上位概念を持つ
関係があるやろ
490 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 10:58:14.90 ID:kQel6lTj.net]: >>473
その理屈だと、むしろ無関係なもの探す方が難しいなw
491 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 11:10:54.95 ID:HilDODP3.net]: クソとか言っている人間の方がよっぽど
>科学的工学的有効性のかけらも無い
と思うけど
492 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 12:04:19.49 ID:4oQp/Mop.net]: >>474
なに言うてんねん、必死やな
493 名前：デフォルトの名無しさん mailto:sage [2018/10/05(金) 14:35:10.66 ID:kQel6lTj.net]: べつにオブジェクト指向の概念は関数で実装しなくてもいいんだよ？
メッセージでもいいしな。
494 名前：デフォルトの名無しさん [2018/10/06(土) 00:01:51.18 ID:LmyRE988.net]: OcamlやF#のようにオブジェクト指向と関数型パラダイムを合わせて持つ言語もあるが、
内容は覚えていないけど本質的・理論的にはこの二つのパラダイムは相反するものだと聞いている。
確かに局所的、ミクロに上手くかかれた関数型の呼び出しは
型クラスのような複合構造の使う余地はもはや無く、自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
相反するのもうなずける話だと思っている。
OcamlやF#は詳しくないがどのレイヤでオブジェクト指向と関数型を使うかが分かれるんじゃないかな
numpyで関数の返り値が気がつくと内部クラスのオブジェクトになってた、みたいな。
495 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 00:23:54.73 ID:wNGV+/Yb.net]: >自然なスコープで
各記憶クラスのインスタンスにアクセスを表現できるから
この辺が気になる
オブジェクト指向プログラミングの場合は
クラス内に操作対象(変数)を封じ込めてクラス外からアクセス出来ないようにして
グローバル変数が各所からアクセスされることで無限のアクセスパターンになるというのを避けている
というのが肝なんだと自分は思ってるんだけど
関数プログラミングは難しくてさっぱり且つ入門もまともにやった事ないんだけど
状態なんかを副作用?とか呼んでなるだけ外に出す
という方法で対処する
みたいだそうなんだけど?
その辺どうなんだろうか?
少し上の方にその話になりそうな流れが有って少し期待してたんだけど
違う方向に流れたようで残念だったんだけど
496 名前：デフォルトの名無しさん [2018/10/06(土) 00:49:03.56 ID:LmyRE988.net]: >>479
俺の書ける範囲で述べると、
身近な局所変数＞一層外側のブロックの内部変数＞。。。＞大外側の大域変数
というスコープ階層は知ってるよね？

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

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

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

型クラスとかアクセサでカプセルかとか継承とか全いらない
498 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 01:01:28.94 ID:qfHN3zvO.net]: 関数型というかHaskellのええ所は>>260でいうパーツの切り分けが強制的になる所もあるよな
全てパターンマッチのワンライナーで関数が細かくブツ切りで出来るから後の編集しやすい
499 名前：デフォルトの名無しさん [2018/10/06(土) 01:02:29.25 ID:LmyRE988.net]: ただまぁ万能ではなく、
別の弱点(副作用のｱﾙ処理の扱い、学習コスト含む)
もあるので俺はfunctionalﾏﾝｾｰではないけれど
500 名前：デフォルトの名無しさん [2018/10/06(土) 01:31:10.16 ID:LmyRE988.net]: 多態性についても文句あんだよねおれは。
あんあもの動的言語ではそもそも意識する必要も無い空気みたいなもの
それを変に応用して話をややこしくして…
まあ別途機会があれば書くかもしれないけれど。
かかないかおもしれない。

あどオブジェクト指向とその変な一時的流行で迷惑したのは
非科学的で誤ったオブジェクト指向論を信条として、それを宗教のように吹いてまわり
周りに強制し、反論すれば非難。でも自分ではたいしたソリューションのためのソフト開発できない
みたいな工程論・方法論者が跋扈して
開発者を煩わせたこと
501 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 01:38:18.52 ID:9tCZRFgp.net]: 書籍も全部一色だったし
MSが金出してただろうししゃーない
雑誌社も何の根拠もないのにオブジェクト指向マンセーだったよね
本当に技術を見定める能力があればそれが詐欺であると気づいたんだろうな
多くの人間はそうでは無かった
502 名前：デフォルトの名無しさん [2018/10/06(土) 01:41:57.53 ID:LmyRE988.net]: 本当に有効な機能だけ自律して使えば有効な面もあったかもしれないけど
人間てそんなに器用じゃないし
群衆や社会問題って
チコちゃんの言う氷河期からそんなものだったのかもしれない
503 名前：デフォルトの名無しさん [2018/10/06(土) 01:43:22.02 ID:LmyRE988.net]: 今でもオブジェクト指向からDNNやAiにステージを移して
同じようなことが続いている
504 名前：デフォルトの名無しさん [2018/10/06(土) 02:03:28 ]: [ここ壊れてます]
505 名前：.62 ID:LmyRE988.net mailto: でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
ソフトウエアの構造を表現している。そしてすごいスピードでreviseする。
べらぼうな才能と手間と時間をかけてクラスベースOOPでソフトウエアを表現しようとしている
あれは(個人的に好きではないけど)見事だとうなってしまう。
優秀な者が活躍して、採用したパラダイムが茨の道に密だとしてある水準まで力強く構築しようとしていると思う。

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

同じOOPでも同列にみなしてはいけないんだろうな []: [ここ壊れてます]
506 名前：デフォルトの名無しさん [2018/10/06(土) 02:13:25.41 ID:LmyRE988.net]: ちなみにpythonの言語仕様自体は
涙なくして語れないほどのクソだと俺は思っている

なんか文句あるか？
　　　　　　　　　　　　　　＿＿_
　　　　　　　　　　　　　／　　　＼
　　　　　　　　　　　　／ ─　　 ─ ＼
　　　　　　　　　　／　（●）　（●）　＼
　　　　　　　　 |　　　（__人__）　　　 |　＜かかってこいよ
　　　　　　　　　　,.ﾞ-‐- ､　｀⌒´　　　,／　　　　おらー
　　　　　 ┌､.　/　　　ヽ　ー‐　　＜.
　　　　　　ヽ.X､- ､　　 ,ﾉi　　　　　ハ
　　　　　　⊂＞'">┐ヽノ〃　　　　　/　ﾍ
　　　　　　　入 ´／/ ﾉ　　　　　　　 } ,..,.._',.-ｧ
　　　　　／　｀ｰ''"´　　　　　 ,'　ｃ〈〈〈っ<
　　　　 /　　　　　　　　　　__,,..ノ　,ノヽー'"ﾉ
　　　 {　　　　　　　　　　´　　 /　　｀`¨´
　　　　/´¨`'''‐､._　　　　　　　　,'＼
　　　 ∨´　　　｀ヽ、　　　　ﾉ　ﾞヽ
　　　 ∨　　　　　　ヽ　_,,..-'"　　　　｀ヽ
　　　　　∨　　　　〈-=､.__　　　　　　　}
　　　　　　ヽ、　　　　 }　　　｀`７‐-.　　/
　　　　　ヽ　　　ﾘ　　　 /′　　ノ
　　　　　 /′　　, { 　　 /　　／
　　　　　　 {　　　　　!　　 ,ﾉ　 ,/′
　　　　　 !　　　　/　　/　　　`‐-､
　　　　　　　 !　　　,/　　ﾞー''' ｰ---'
　　　　　　 ',　　/
　　　　　　　　{ 　 }
　　　　　　ﾞY　｀ヽ､
　　　　　　　ﾞｰ--‐'
507 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 07:19:55.96 ID:hM5EPMW3.net]: pythonにprivate変数はありません。
pythonにswitch文はありません。
pythonのクラス関数はselfを第一引数に
命名規則は決められたものを守りましょう
インデントはスペース4つ
括弧の書き方でsetになったりdictになったりします
一列の文字数は79文字以内

（一部言語仕様でないのも書いてるけど）利点でもあり欠点でもあるな
508 名前：デフォルトの名無しさん [2018/10/06(土) 07:35:40.78 ID:vpFDdLxA.net]: >>181

まとめると：
　　Python のオブジェクト指向はクソ
509 名前：デフォルトの名無しさん [2018/10/06(土) 11:22:52.91 ID:LmyRE988.net]: >>490
一番クソなのは初期の段階でブロックとlexical scopeを配慮して言語設計しなかったこと
今でも引きずっている
510 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 12:56:22.72 ID:sXtVjY80.net]: ID:LmyRE988
↑なんでこいつすぐポエってしまうん？
511 名前：デフォルトの名無しさん [2018/10/06(土) 13:08:17.37 ID:LmyRE988.net]: >>493
飲んで2chにポエﾑ書くことくらい大目に見なよ
512 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 13:36:23.41 ID:o3SQFYgr.net]: >>492
blockは無いし頑なに追加しようとしないけど
lexical scope な言語ではあるだろ
何か勘違いしてるんじゃない？用語の意味わかってる？
513 名前：デフォルトの名無しさん [2018/10/06(土) 13:43:55.83 ID:LmyRE988.net]: >>495
・関数の大外のfile scopeの変数を外部から参照させることが出来ない
514 名前： classにする必要が無くてもclass objectを作ってclass変数とし無ければならない ・関数の内側は平坦なlocal scopeのみ、また外側の変数は参照のみ、更新できない（かった<3) ・block(てきなもの)がnestしてもscopeがnestしない したがって関数bodyがでかくなると見えなくて良い遠くの変数を隠せない >>492 で配慮していないと一言で言おうとしたのは 具体的にはこういった欠点 []: [ここ壊れてます]
515 名前：デフォルトの名無しさん [2018/10/06(土) 13:59:20.11 ID:LmyRE988.net]: >>495
モダンな言語なら必ず備えているコードのlexicalな階層構造と
変数のscopeの階層の明確な対応が出来ているとは
とても言いがたい
516 名前：デフォルトの名無しさん [2018/10/06(土) 14:02:40.61 ID:LmyRE988.net]: さて、三連休だ、旅行に行ってくるわ。
あばよ、ﾉｼ
517 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:04:15.02 ID:o3SQFYgr.net]: だから一言blockが無いで良いじゃん
lexical scopeは関係ない
それにpython 3だけで大抵の言語のシェアを上回ってるのに、
未だに2の批判するのも意味分からん
518 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:05:12.84 ID:o3SQFYgr.net]: >>496
＞>>495
＞・関数の大外のfile scopeの変数を外部から参照させることが出来ない

これ意味分からんかったわ
どういうこと？
519 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:06:48.29 ID:c8T9aSvT.net]: >でもまnumpyやtensorflow,kerasなどのFWソースをたまに眺めると
>よくまあここまで練り上げたなと感心するくらい上手にクラスベースOOPをつかって
>ソフトウエアの構造を表現している。
numpy、tensorflowがオブジェクト志向？
そんな気は全くしないんだが、定義が全く違うのかな？
520 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:08:53.96 ID:o3SQFYgr.net]: それと pythonでnonlocal や global を使いたくなるケースは
根本的に設計間違ってるから、クソコード撒き散らす前に設計見直した方が良いよ
521 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:18:09.40 ID:o3SQFYgr.net]: >>501
numpyやtfの中のコードの事だろ
使う側は手続き型で書ける
tfは計算グラフを構築してから実行するから宣言型かもな
522 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:21:52.83 ID:sXtVjY80.net]: >>501
そいつはここで気持ちよくポエりたいだけだから
レス返しても有益な情報は得られないよ
ポエ逃げしたいだけの人種だから
523 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 14:28:45.50 ID:9tCZRFgp.net]: スレッド内にカプセル化されとる
524 名前：デフォルトの名無しさん [2018/10/06(土) 21:20:49.04 ID:vpFDdLxA.net]: >>503
まとめると：
・numpy や tf は C/C++ で書かれ内部はオブジェクト指向で設計された
・それらライブラリのAPIを Python は手続き的に利用している

つまりスレ的には、「Pythonのオブジェクト指向はクソ(>>181)」であると、
Python信者が認めたわけだ
525 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 21:28:26.10 ID:c8T9aSvT.net]: numpyの中身は知らんがtensorflowのどこがオブジェクト指向？
ホントにコード読んでんのかよ。。
なんか胡散臭い奴しかいねーな。。
526 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 21:38:32.17 ID:9xvvgu9Y.net]: >>506
数式を表現するのにオブジェクト指向なんていらん
行列演算したいだけなのにオブジェクト指向なんて強制されたらクソだわ

あ、数式使わないドカタの反論は不要なのでよろしく
ドカタには分からん世界があるんだよ
527 名前：デフォルトの名無しさん [2018/10/06(土) 22:10:42.51 ID:vpFDdLxA.net]: >>508
Python信者からも賛同意見を頂けるとは嬉しい限り

・次世代言語12 Go Rust Swift Kotlin TypeScript
　mevius.2ch.net/test/read.cgi/tech/1530664695/963/
　>> 失礼な！！Python は FORTRAN/COBOL/BASIC に代表される
　>> 伝統的な手続き型言語の正当な後継スクリプト言語、
　>> 次世代の純粋手続き型言語です
　>>
　>> 関数型？オブジェクト指向？
　>> そんなのは飾りです、偉い人にはそれが分からんのですよ（必死
528 名前：デフォルトの名無しさん [2018/10/06(土) 22:21:37.35 ID:84qwAd3v.net]: 節子、それ便所の…
529 名前：デフォルトの名無しさん mailto:sage [2018/10/06(土) 23:25:06.73 ID:wNGV+/Yb.net]: >>480さんへ
479です
自分は関数型に関しては完全に素人なのでなかなかに
530 名前：難しいです 単純に受けたイメージだとなんか凄くモノリシックに大きくなってしまいそう見えてしまう 関数型って何時もどういう風に制御するのか解らないなぁという感じで 基本的に難しい物なので自分には理解できないという感じなんだろうと思いつつ 今回は状態を通して何か掴めるかな? と思いましたがそんなに甘くない感じですね 何にしても回答どうもです 関数型ってオブジェクト指向プログラミングシステムより更に難しいそうなのでオブジェクト指向より使える人が増えないような予感がします・・・ []: [ここ壊れてます]
531 名前：デフォルトの名無しさん [2018/10/07(日) 01:21:33.80 ID:Nojuqsx1.net]: >>502
そもそも nonlocal やら global などという
スコープ宣言に限定した予約語が存在するのは
Python が(歴史上、おそらくは)唯一の存在である、
という事実を忘れてやいませんか？

言い換えると、スコープに関して Python2 以前の
新規リリースの時点から「根本的に設計を間違えていた」のがPythonなわけ
で、根本的解決を採用せず、行き当たりばったりに
nonlocal やら golobal といった泥縄式対策を採用したのがPython3
532 名前：デフォルトの名無しさん [2018/10/07(日) 01:25:43.47 ID:iX7g/tHs.net]: ゴローバルってなんかカッコええやん。
ゴローさん風味が出ててさ。
533 名前：デフォルトの名無しさん [2018/10/07(日) 02:05:51.72 ID:dWI643/y.net]: nonlocalってセンスがウケるなｗ
いっそのことnonglobalも用意したらどうかｗｗｗｗ
534 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 14:29:17.30 ID:+Rd5+blg.net]: オブジェクト指向のスレでなんで延々と特定言語の言語実装の話してんの？
バカなの？
535 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 18:24:53.01 ID:FMwg69WX.net]: OOPの結果としては
クラスライブラリとかは文句なしに使いやすいと思うんだけどね
String, Map, List, Set, Threadなんかは十分使いやすいよね？
その点を否定するやつはさすがにおらんやろ？
536 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 18:26:20.74 ID:qTxqyvp+.net]: やっぱりクラスライブラリは使いやすいよね
文字列をポインタで操作してたCの時代に戻りたくない
537 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 18:37:23.80 ID:FMwg69WX.net]: そうなんよね
その点で見ればOOP大成功に見える

ただ、自前でクラスやクラスライブラリを書けつったときに
とたんにゴミの山になりかねないという
538 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 18:59:53.35 ID:blwtBRQv.net]: >>516
何と比べて？
別に同じ機能の関数あればええで
539 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 19:18:00.94 ID:zvJnD+aL.net]: >>516
使いやすいが、そこまで一般的なインターフェイスにするまで
いろんなソフトウェアの歴史があってこそなわけだ。
ユーザー定義でそのレベルのものを用意しようとすると途端に何も進まないか
クソインターフェイスをひたすら強要される現場となる。
540 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 19:37:46.92 ID:FoRhSX54.net]: クラス単体はオブジェクト指向だけど結局それを使うところでは手続き型にしてしまう。
541 名前：デフォルトの名無しさん [2018/10/07(日) 22:20:34.82 ID:mIq+f5AO.net]: ならC++のﾒｿｯﾄﾞをすべてｽﾀﾃｨｯｸで書けばいい
そうすればﾒﾝﾊﾞ変数も不要
ｽﾀﾃｨｯｸのﾒｿｯﾄﾞは当然ﾒﾝﾊﾞ変数にはｱｸｾｽできない

手続き型なら、入力の構造体と出力の構造体を関数を別で渡す程度で済むﾊｽﾞ
ｵﾌﾞｼﾞｪｸﾄの状態を常に外側で管理する必要があることになる

MS-WindowsのAPIは
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗをひとつのｵﾌﾞｼﾞｪｸﾄとみなして
ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗを経由して操作や設定を行ってる

ｳｨﾝﾄﾞｳﾊﾝﾄﾞﾗも一つのｵﾌﾞｼﾞｪｸﾄで入力も出力もできるｼﾛﾓﾉになってるからな
542 名前：デフォルトの名無しさん [2018/10/07(日) 22:25:31.13 ID:mIq+f5AO.net]: UNIXｸﾛｰﾝのｼｽﾃﾑ関数にもwriteやreadがある
readや
543 名前：writeはﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀを経由して なにかしらに読んだり書いたりする関数だからな つまりﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀをｵﾌﾞｼﾞｪｸﾄとみなして 読んだり書いたりしてるとみなしてると考えて差し支えない ｺﾚはC++のようなｵﾌﾞｼﾞｪｸﾄ指向言語で継承して実現できる内容と同じとみなせる []: [ここ壊れてます]
544 名前：デフォルトの名無しさん [2018/10/07(日) 22:36:06.11 ID:B8+uQuvb.net]: オッカムの剃刀の逆を地で行ってるなｗ
オブジェクト指向の何がダメか腑に落ちた気がするよ。ありがとう。
545 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 22:46:39.84 ID:qTxqyvp+.net]: 全部スタティックにするってそれ
スタティックおじさんじゃねーか！
546 名前：デフォルトの名無しさん [2018/10/07(日) 22:48:32.68 ID:9pTh9QRI.net]: >>511
モノリシックに大きくなってしまうという印象は杞憂。
むしろ関数呼び出を一行ずつ言い切りみたいにつらねた宣言的書き方に近づく
リスト = 関数リスト;
リスト = 関数関数リスト;
...
見たいな感じ。
状態は、本当に必要なもの以外は自然に登場してこなくなりその分複雑さを低減できる感じ。
どうしても状態管理が必要な処理は、
副作用の排除された純粋な言語の場合モナドみたいな物を持ち出さなければならないかもしれないが
副作用も許容している言語では、手続き的書き方をして状態を管理する形になると思われ、
どうしても必要な状態管理の煩雑さを関数型パラダイムで根本解決できるとはｵﾚ的にはちょっと考えにくい。
難易度に関して言えば確かに学習コストは若干かかるけど、
いまはJavaやC++にもStreamやfoldなど関数型的なプログラミングのための機能が大急ぎで(かなりあせっている感じ)
取り入れられつつあるのであんまり肩肘張らないで、
ttps://qiita.com/stkdev/items/5c021d4e5d54d56b927c
https://ubiteku.oinker.me/2017/05/08/purpose-of-functional-programming/
といった導入的な情報などを参考にｍ日々の設計・開発の
局所的なコーディング範囲でもいいから使えるとことから使っていけば技術的な視野が広がるんじゃないかと思う。
ちなみに俺はそのサイトとは何の関係もないし、functionalﾏﾝｾｰではない
547 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 22:51:20.95 ID:9RTjDYv/.net]: ミドルウェアは天才が書くから天才の好む言語で書く
クライアントコードはアホが書くからアホでも分かる手続き型で書く
開発者の能力に応じて分業可能にした功績はある
だいたい天才とアホが同じ言語使ってたのが頭おかしい発想だった
548 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 22:52:56.75 ID:9RTjDYv/.net]: アホはひらがなだけ使え
漢字を使うと他のアホが読めなくなる
549 名前：デフォルトの名無しさん [2018/10/07(日) 22:52:57.06 ID:9pTh9QRI.net]: そ、そうなのか…
なんか熱でもあるんじゃね？
550 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:03:08.28 ID:zvJnD+aL.net]: いやレイヤーや粒度によって向き不向きな言語、パラダイムがあるってだけだろ。
天才とかアホとか関係ねーわ。
まあそういう判断しかできない奴は例外なくアホだろうけれど。
551 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:07:07.43 ID:9RTjDYv/.net]: まあ例外なくアホとかいう恥ずかしい書き込みをするような奴は例外なく知的障害者だろうけど。例外なく、なｗ
552 名前：521 [2018/10/07(日) 23:12:36.26 ID:4NXYL+If.net]: staticに使い道なんてあったんだ・・・
553 名前：デフォルトの名無しさん [2018/10/07(日) 23:20:21.45 ID:9pTh9QRI.net]: >>516
それらlibraryレイヤははよく練り上げられてまぁ使いやすいと思うよ。
でもよく考えてみてよ、納品を決められ短期間に仕様の策定からQAまでこなさなければならない
アプリケーションソフトウエア開発とそういった長年同じような機能のライブラリが繰り返し作り
直されてきたものは同一に論じることは無理でしょ。
それにレイヤが全然違う�
554 名前：ｶゃない。 下から見れば数百個程度の機械語＞言語の文法レベル＞ｱﾙｺﾞﾘｽﾞﾑのライブラリレベル ＞それらを組み合わせ具体的なあるぴにための処理を折りませたアプリレイヤ＞… レイヤによって全然特性が違うんだよ。適した表現手段は当然違うと俺は思う。 つまりｱﾙｺﾞﾘｽﾞﾑのライブラリレベルに適した表現手段が必ずしもその上位にある 複雑な応用レベルの表現には適しているとは言いがたいのではないかということ。(ここ伝わりにくいと思う) これは今でも俺も日々とても悩まされている問題。でもまそれはしｚでんげんしょうみたいなものでしょうがないいんだよ。 誰も悪くないし。 本当に問題は、オブジェクト指向の名の下に非科学的非合理的で変な表現手段が流布し （一部の人間が意図的に拡散させ）ソフトウエア開発の技術的水神をを後退させ混乱させてしまったこと。 俺はこの一点を問題視しているんだよ。 また飲みながらのポエムで悪いな。 []: [ここ壊れてます]
555 名前：デフォルトの名無しさん [2018/10/07(日) 23:22:20.26 ID:9pTh9QRI.net]: >>533 誤記多いなｽﾏｿ
しｚでんげんしょう → 自然現象
技術的水神 → 技術的水準
556 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:26:20.11 ID:FMwg69WX.net]: >>533
大変申し訳ないが今後一切のポエムは不要ですんで分かってください
557 名前：デフォルトの名無しさん [2018/10/07(日) 23:28:24.29 ID:9pTh9QRI.net]: >>535
そんなことよりポエムでもいいからなんか内容を書けよ
なんかむかついたのかｗ
558 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:28:51.19 ID:FMwg69WX.net]: ？
559 名前：デフォルトの名無しさん [2018/10/07(日) 23:31:09.36 ID:9pTh9QRI.net]: OOPの幻想を追いながらゴミの山量産してて頂戴
560 名前：デフォルトの名無しさん [2018/10/07(日) 23:44:00.68 ID:mIq+f5AO.net]: https://ideone.com/PErfVu
ｺﾚがｵﾌﾞｼﾞｪｸﾄ指向なｺｰﾃﾞｨﾝｸﾞ
561 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:52:58.21 ID:GYr8Tket.net]: だからねえ、凡人プログラマがいきがってOOを語るなっつーの

それなりに名が売れてる人以外、講釈垂れ禁止にしたいよね
562 名前：デフォルトの名無しさん mailto:sage [2018/10/07(日) 23:53:56.52 ID:FMwg69WX.net]: >>540
いっけん暴論だが
それはそれで正しい
563 名前：デフォルトの名無しさん [2018/10/07(日) 23:58:46.68 ID:9pTh9QRI.net]: そしたら日本にいないぞ
>>540 も >>541 も論外、対象外だし

おれはそもそもOOの講釈をたれたことは無いので自由だ。
564 名前：デフォルトの名無しさん [2018/10/08(月) 00:05:22.29 ID:SHTmPUE+.net]: と低学歴知恵遅れの底辺がいってもな
565 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:08:53.96 ID:YlFF3Gbm.net]: 日本人がプログラミングで実績残せないのはなぜだろうと思うけど
(まつもとゆきひろとか神レベルを除く)
講釈垂れは、１億円程度の案件でも沸いてくるんだわ
しかもたいていＦランとか専門卒の地頭の悪さを自認できない語り部

俺のガンダムはさー、とか言い出す小学生と変わらんのよ
566 名前：デフォルトの名無しさん [2018/10/08(月) 00:09:05.00 ID:5FzXpRZO.net]: そういう非論理的揚げ足取り未満のレスが着き始めると
ああ、OOP信者はねた切れなのかあるいは
そもそも何か問題のある人たちだったとつくづく思う
567 名前：デフォルトの名無しさん [2018/10/08(月) 00:10:40.27 ID:5FzXpRZO.net]: そう言った人たちにみんなだまされ続けていたと
568 名前：デフォルトの名無しさん [2018/10/08(月) 00:13:06.68 ID:5FzXpRZO.net]: >>545 は >>543 宛ね
念のため
569 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:13:33.24 ID:YlFF3Gbm.net]: 細かいところの揚げ足取りで、議論になり得ないのも底辺の特徴ね

なので2ちゃん５ちゃんみたいな底辺８割の落書きでOOのメリットデメリットが議論できるわけがない
数年前はちょっと期待してたけど
570 名前：デフォルトの名無しさん [2018/10/08(月) 00:15:48.02 ID:5FzXpRZO.net]: そうだけどそれでも決して悪いことではないと思う。
別に理想の場をもとめて誰もきているわけじゃない
しかしその一方、これもひとつの社会の縮図で
そのなかで自分も生きていくことには変わ�
571 名前：閧ﾍ無い []: [ここ壊れてます]
572 名前：デフォルトの名無しさん [2018/10/08(月) 00:18:20.98 ID:5FzXpRZO.net]: が、しかしだ。
オブジェクト指向ってのは実はクソだったと思う。
そして講釈をたれて変なオブジェクト指向を吹聴していた奴らはクソだった。
これは変わりない。
573 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:23:48.49 ID:YlFF3Gbm.net]: 新しいものを無条件に礼讃するのはヲタの特徴だからしかたがない

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

この業界は敷居が低いからヲタの比率が高くなりがちで、困るのは自己顕示欲が大勢な新しモノ知ってるぞヲタ
574 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:26:00.79 ID:4+4YIfxx.net]: このスレはレッテル張りばかりで中身のないレスが多いな
575 名前：デフォルトの名無しさん [2018/10/08(月) 00:27:52.21 ID:5FzXpRZO.net]: 日本のIT産業産業全体にいえることじゃん。
いま世界で絶賛ぼろ負け中だけど。
やITに限らない、はば広くぼろ負け中。絶賛衰退中。
OOP現象も同じだと思うんだよ。
純粋な技術的問題じゃないんだよね、社会的問題というか、人の問題というか。
CMMIもISO9000も
576 名前：デフォルトの名無しさん [2018/10/08(月) 00:31:01.24 ID:5FzXpRZO.net]: 中身のｱﾙレス
よろしくお願いしまーす
577 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:36:06.65 ID:YlFF3Gbm.net]: 俺もこの業界に長くいて新三大嫌悪感があるのが、多重請負、ISOとか監査もの、OOやDIの語り部

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

そういえば技術じゃなくて社会的な問題かもね
578 名前：デフォルトの名無しさん [2018/10/08(月) 00:43:44.28 ID:5FzXpRZO.net]: 腹黒い奴がどう他人を操るかの手法として利用されてきたか側面はあると思う

洩れの周りでの話だけれど、OOPのカプセル化、getter/setter、
継承による(後付の)コード再利用性による開発量削減・コスト低減を社内でうたい始めた奴は
実は自分ではコードは書けず無論設計は出来ず、マネージメントもできず、忖度と口先でしのいできて
くいっぱぐれるまえにJavaの流行を察知して社内OOP論者になり、布教に励み
それが下火になるとCMMI,IPISOの流行にのってQA論者に衣替えした
579 名前：デフォルトの名無しさん [2018/10/08(月) 00:47:41.87 ID:5FzXpRZO.net]: それにさんざだまされてうっかりJava信者になって
いまも問題点に気がつかず変なコード書いてる、あるいは部下や外注さんに強要して
迷惑がられている奴ら多数
これを暗黒時代と言わずしてなんというのだろうか
580 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 00:48:42.81 ID:88AHsTr8.net]: >>551
新しいもの？
581 名前：デフォルトの名無しさん [2018/10/08(月) 00:52:04.16 ID:5FzXpRZO.net]: んなこたどうでもいい。
結論
オブジェクト指向はクソだった
都市伝説みたいな迷信だった。
沢山の人がだまされた
以上。
582 名前：デフォルトの名無しさん [2018/10/08(月) 00:53:59.74 ID:Kbmtp0Cm.net]: ボトムアップドメイン駆動設計
https://ddd-community-jp.connpass.com/event/103428/

ぜひ参加してください！
583 名前：デフォルトの名無しさん [2018/10/08(月) 00:58:34.19 ID:5FzXpRZO.net]: つぎに
関数型はクソだった
って言うｽﾚが建てば一過言あんだけれどもな…
584 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 01:00:35.78 ID:Z0JUGcFO.net]: OOPに批判的な奴は最初から一定数いたよな
ちょろい奴を操る手法もまあ腹黒いが、批判を無力化する手法の方がもっと腹黒い
585 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 01:02:55.95 ID:YlFF3Gbm.net]: 俺の会社では語り部は淘汰されたけど、糞コードは負の遺産として急には捨てられなくて困ってる

ロジックをトレースしづらいだけの継承とか、呼び出し順が分かりにくいだけのテンプレートメソッドとか、背伸びしまくりの知ったかぶりOO
586 名前：デフォルトの名無しさん [2018/10/08(月) 01:10:27.58 ID:5FzXpRZO.net]: OOPって、それじゃあ全然ﾀﾞﾒだったかというとそうでもなくて
頑張ればそれを使って(向いてないレイヤ・アプリでも)何とかソフトウエアを構成できたんだよ。
それはgotoを乱用してもがんばれば何とかソフトウエアを構成できたのと実は大差ないことだと
俺は思っているんだけれど。

それが厄介ごとの元。
上手くいかなかったときはOOPの理解が足りないからだとか、
低学歴には無理ｗとか批判されて、
そう、自分ではまともなコードををかけない奴に批判される
一体OOPは何のための手法なんだろうか
587 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 01:10:43.98 ID:YGZFPxYk.net]: 手続き型しか分からないと言ってるのと同じ
588 名前：デフォルトの名無しさん [2018/10/08(月) 01:11:52.30 ID:5FzXpRZO.net]: いや名誉のために言っておくと俺は低学歴ではないｗ
589 名前：デフォルトの名無しさん [2018/10/08(月) 01:12:22.52 ID:SHTmPUE+.net]: ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる

ｵﾏｴも含めてな
590 名前：デフォルトの名無しさん [2018/10/08(月) 01:13:21.14 ID:5FzXpRZO.net]: >>565
手続き型とオブジェクト指向てscopeのもちかたとその応用以外特に差はないよ
591 名前：デフォルトの名無しさん [2018/10/08(月) 01:14:58.10 ID:SHTmPUE+.net]: 低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
592 名前：デフォルトの名無しさん [2018/10/08(月) 01:15:28.69 ID:tiRNksmV.net]: 手続き型言語で取り返しのつかない設計ミスって結構あったんだよ
そういう部分でオブジェクト指向には意味があると思うんだけどな
とりあえずデザパタどおりにしとけば何とかなる的な
593 名前：デフォルトの名無しさん [2018/10/08(月) 01:16:28.07 ID:5FzXpRZO.net]: あんたあちこちで毎日こんなレスばっかかいてるね
いろんな人がいるなこの世には

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+
低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
594 名前：デフォルトの名無しさん [2018/10/08(月) 01:19:37.41 ID:5FzXpRZO.net]: >>571 は ID:SHTmPUE+ 宛
念のため

>>570
デザパタとか言うけどsingletonとか後論されつくしている通り
糞だぞ
595 名前：デフォルトの名無しさん [2018/10/08(月) 01:20:11.16 ID:SHTmPUE+.net]: この必死さ

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

残念なことにすぐに分かっちゃう
596 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 01:21:42.91 ID:YlFF3Gbm.net]: 人間が持つ分類の概念が似ているもの、GUIとか、そのサブクラスで違和感なくロジックがdispatchできるものが適用範囲なんじゃね？

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

絵空事のパワポの達人にはよく出くわすけどな
597 名前：デフォルトの名無しさん [2018/10/08(月) 01:22:14.15 ID:5FzXpRZO.net]: いろんな人がいるな
法を犯さなければ野放しだから
598 名前：デフォルトの名無しさん [2018/10/08(月) 01:23:47.08 ID:5FzXpRZO.net]: >>574
応用レイヤのclass設計で言うと見事と思えるものは海外にはある？
599 名前：デフォルトの名無しさん [2018/10/08(月) 01:30:22.12 ID:5FzXpRZO.net]: この必死さ

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

残念なことにすぐに分かっちゃう
600 名前：デフォルトの名無しさん [2018/10/08(月) 01:30:49.29 ID:5FzXpRZO.net]: 低学歴知恵遅れはﾚｽみても分かる通り
知能にも著しい欠陥があるのがすぐに分かちゃうからな

ｵﾂﾑの程度をみても
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
601 名前：デフォルトの名無しさん [2018/10/08(月) 01:31:05.39 ID:5FzXpRZO.net]: ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる

ｵﾏｴも含めてな
602 名前：デフォルトの名無しさん [2018/10/08(月) 01:32:16.55 ID:5FzXpRZO.net]: と低学歴知恵遅れの底辺がいってもな
603 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 01:33:25.88 ID:YlFF3Gbm.net]: >>576
オープンじゃないけど時価配信でObserverパターンになってるのはよく見るな

GUIだとDelphiだね、古いけど基本は同じだろう
604 名前：デフォルトの名無しさん [2018/10/08(月) 01:33:53.33 ID:5FzXpRZO.net]: ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題
605 名前：デフォルトの名無しさん [2018/10/08(月) 01:34:34.01 ID:5FzXpRZO.net]: ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ

ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない

ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物

ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常�
606 名前：Oを逸してる ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪 []: [ここ壊れてます]
607 名前：デフォルトの名無しさん [2018/10/08(月) 01:34:43.31 ID:SHTmPUE+.net]: 低学歴知恵遅れがなんか壊れた
608 名前：デフォルトの名無しさん [2018/10/08(月) 01:35:07.92 ID:5FzXpRZO.net]: だいたいわかる

ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる
609 名前：デフォルトの名無しさん [2018/10/08(月) 01:36:03.72 ID:5FzXpRZO.net]: >>584
お前さんの今までのレスをコピペして遊んでいただけだよ
610 名前：デフォルトの名無しさん [2018/10/08(月) 01:36:36.34 ID:5FzXpRZO.net]: 内容のあるレスを探したがが1つもなかったよ
611 名前：デフォルトの名無しさん [2018/10/08(月) 01:40:06.65 ID:5FzXpRZO.net]: ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない
612 名前：デフォルトの名無しさん [2018/10/08(月) 01:40:53.29 ID:5FzXpRZO.net]: もっとからかっちゃおうかなﾌﾌ
613 名前：デフォルトの名無しさん [2018/10/08(月) 01:43:12.51 ID:SHTmPUE+.net]: ID:B/yxkRYZ
ID:j/6nk0eH
ID:cRG95Xcq
ID:Kxio7RVg
ID:pq96CSzd
ID:k5h2WtG4
ID:IuTgmxg/
ID:R8M7QKDK
ID:mIq+f5AO
ID:SHTmPUE+

このｽﾚのｵﾚのﾚｽはｺﾚがすべてだ
ｵﾏｴみたいな内容のない低学歴知恵遅れと違って
たくさん有益なﾚｽをしてる

低学歴知恵遅れには理解できないし読めないのはわかる
知能に著しい欠陥があるからな
614 名前：デフォルトの名無しさん [2018/10/08(月) 01:44:25.97 ID:SHTmPUE+.net]: 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる
615 名前：デフォルトの名無しさん [2018/10/08(月) 01:46:21.56 ID:5FzXpRZO.net]: >>590
乙。暇だね。
これはあくまで親心で申し上げるが、頭の病院いったほうがいいレベルですよ。
616 名前：デフォルトの名無しさん [2018/10/08(月) 01:47:52.93 ID:SHTmPUE+.net]: ﾊﾞｶは自分がﾊﾞｶであることに気づけないからな
ｷﾁｶﾞｲには健常者がｷﾁｶﾞｲにみえるのと同じ
617 名前：デフォルトの名無しさん [2018/10/08(月) 01:49:05.52 ID:5FzXpRZO.net]: いやなら別に病院に行かないでそのままひとり病んでてもいいけど
他人にはつくづく迷惑かけないようにね
618 名前：デフォルトの名無しさん [2018/10/08(月) 01:49:23.87 ID:SHTmPUE+.net]: ﾊﾞｶは自分がﾊﾞｶであることに気づけない
つまりﾊﾞｶは一生治らない
まずﾊﾞｶはﾊﾞｶの自覚をもつことができない
619 名前：デフォルトの名無しさん [2018/10/08(月) 01:50:24.26 ID:5FzXpRZO.net]: つかこんなにレスしてたんだ
ぱっとみノイズレスだと思って読んでなかった
620 名前：デフォルトの名無しさん [2018/10/08(月) 01:50:32.93 ID:SHTmPUE+.net]: 病んでるのは間違いなくｵﾏｴだからな
低学歴知恵遅れで底辺になると発症する病気にかかってる
621 名前：デフォルトの名無しさん [2018/10/08(月) 01:52:18.66 ID:5FzXpRZO.net]: ま火事とがいしは2chの華か
622 名前：デフォルトの名無しさん [2018/10/08(月) 01:58:28.42 ID:SHTmPUE+.net]: まあｵﾏｴはｵﾂﾑの病院へいったほうがいいわ
ｵﾂﾑが壊れてる

間違いなく軽度の知的障害がある
623 名前：デフォルトの名無しさん [2018/10/08(月) 01:59:16.72 ID:5FzXpRZO.net]: お前さんは重度だぞｗ
624 名前：デフォルトの名無しさん [2018/10/08(月) 02:00:38.48 ID:5FzXpRZO.net]: つーかいい子だからもうオナニーでもしてネナヨ
おじさんは忙しいんだから
625 名前：デフォルトの名無しさん [2018/10/08(月) 02:04:10.21 ID:5FzXpRZO.net]: オナニー中らしいですｗｗ
626 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 07:42:27.80 ID:kgyl4Ui4.net]: オブジェクト指向のメリットは出たかな？
627 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 08:00:16.00 ID:s8MF6MAn.net]: クラス単体のプログラムが出来るのは利点だと思う。
そのクラス同士のまとめが難しい
628 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 08:22:40.86 ID://kQ6Yzy.net]: ID:5FzXpRZO大発狂しちゃってるやん…
応酬見てると半角のほうがまだまともに見えてくる件ｗ

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

たがいの独立性や多様性をベースとした協調
直交性のあるもんを組み合わせるという日常
ってのはやっぱあちらさんに向いてるんだろうね
629 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 09:15:06.72 ID:r/3VlGF9.net]: 自由で独立した人間は因果関係に縛られないんだぜ
原因はこれだから結果は必ずこうなるとか思ってない
630 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 09:31:21.11 ID:rY7QFOOR.net]: >>606
それはお前の思い込みですね
631 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 09:54:42.20 ID:r/3VlGF9.net]: 思い込みではなく分類
因果関係に逆らえないのはモノや動物のように扱われる
それ以外が人間
632 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 10:16:09.72 ID:rY7QFOOR.net]: 思い込みではなく分類というのは話が噛み合ってない
そういう分類があるという思い込みなんだから

思い込み or 根拠があるという話なんだから、
思い込みじゃないなら根拠を示すべき
633 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 10:19:41.89 ID:zWcMcpmc.net]: >>607
それはお前の思いこみだな

こんな糞レスへの反論なんてこれで十分なんじゃね？
634 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 10:34:48.33 ID:r/3VlGF9.net]: いや、こういうのでいいんだよ
分類に根拠がないという意見と、OOPに根拠がないという意見は似ている
635 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 10:36:56.72 ID:kgyl4Ui4.net]: それでオブジェクト指向にメリットはあるのかい？
636 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 11:23:00.34 ID:rY7QFOOR.net]: >>611
だから分類の話はしてない。

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

↑これが思い込みだって話をしている
637 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 11:23:35.59 ID:rY7QFOOR.net]: どや？話をずらそうとしても、毎回戻されるのって苦痛やろう？ｗｗｗ
638 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 12:12:51.99 ID:Py80K8TM.net]: 半角さんは逃げてこんなスレでも足りない知識でドヤしてるんだwww
639 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 13:57:02.86 ID:HrAB4JNP.net]: GUIみたいに誰もが抽象化のイメージがわきやすいクラスと、Webフレームワークのような、使う人が継承して使えばなんとなく便利なクラスでは、抽象化のやりかたそのものが学問になりそうだよな

一般人はおとなしく継承したクラスの中に、業務ロジックを構造化プログラミングしてなさいってこった
640 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 14:15:51.85 ID:kgyl4Ui4.net]: >>616
抽象化に何のメリットがあるの？
641 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 15:37:04.77 ID:aKFx8hdA.net]: >>617
GUIの座標とか描画とか、共通関数にするよりもスーパークラスに持たせた方が共通処理と分岐処理が別れて、分岐判断の引数とか減るだろ？

別にオブジェクト志向言語じゃなくても構造体でも出来るし、事実、WindowsだってCで書かれてるけどな
642 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 15:55:28.49 ID:kgyl4Ui4.net]: >>618
いや別に分岐が必要な仕様じゃないんだけど
643 名前：デフォルトの名無しさん [2018/10/08(月) 16:12:29.55 ID:HqDSWn9/.net]: >>618
WindowsはC++では？
644 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 16:30:04.70 ID:IMi/szTI.net]: >>619
分岐が必要な仕様じゃないってことは、
分岐が必要な仕様の場合は？
645 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 16:46:43.13 ID:kgyl4Ui4.net]: >>621
switch case
646 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 16:55:14.91 ID:IMi/szTI.net]: >>622
なんで不分岐が必要ない仕様とか言い出したの？
自分が都合がいい例にしたかった？ｗ
647 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:20:09.48 ID:kgyl4Ui4.net]: >>623
いや、テメーで勝手に分岐が必要なブッサイクなクラス作っておいて
それはないなと
それにクラス構造で分岐しないでくんない？
読み辛い
はっきり言ってクソ
仕様書にどんな条件で分岐してるのか書きにくい
控えめに言って死ね
648 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:24:49.00 ID:Tz+BH4lq.net]: >>623
こういう奴がパラダイムの違いを理解しないまま書くからOOPが害悪になるんだよな
649 名前：デフォルトの名無しさん [2018/10/08(月) 17:28:45.60 ID:SHTmPUE+.net]: windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる
650 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:30:28.51 ID:kgyl4Ui4.net]: >>626
それすげーやめてほしい
こっちはテメーが作ったただでさえうんこみたいな設計書に
そう書いてあるから見に行ったのに
そのとおり作ってないとか設計書ゴミ箱に捨てんぞ糞が
651 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:43:41.49 ID:YlFF3Gbm.net]: いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。Windowsの低レベルプログラムは。
652 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:45:55.46 ID:IMi/szTI.net]: >>628
653 名前：> いや、実際にWM_xxxxに対するcase文てんこ盛りだけど。 オブジェクト指向で作らないからそうなる []: [ここ壊れてます]
654 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:48:29.61 ID:lYyho1IC.net]: MFCのメッセージマップは嫌いだった。
switchのほうが100倍分かりやすい。
655 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 17:54:08.00 ID:YlFF3Gbm.net]: MFCが出てくる前は、Cでゴリゴリ書いてたのよ
MFCが曲者っつー話はさておき、
Cでクライアントプログラムを書くわけだが、Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる
656 名前： mailto:sage [2018/10/08(月) 18:53:59.21 ID:Vh0J6/Nb.net]: >>626
＞windowsでは普通にｲﾍﾞﾝﾄ分岐処理でもswitch文使う
pedzold では終始一貫して switch なのは、ちょっとどうかな、と当時でさえ思っていました

＞それを隠蔽化するために仮想関数にして実現するどうかは作るﾔﾂのｾﾝｽで決まる
今思うに、これは悪手なのではないかと
657 名前： mailto:sage [2018/10/08(月) 18:58:32.67 ID:Vh0J6/Nb.net]: >>631
＞Windows自体はOOそのものの思想で作られていて、ウインドウクラスの登録から始まる
それ、今でもよくわからないですね
::RegisterClass() ってコンストラクタに該当するのですか？なぜ ::CreateWindow() とは別に定義したのでしょうか？私はこの二つはラッピングしちゃってます…
658 名前：デフォルトの名無しさん [2018/10/08(月) 19:22:15.46 ID:Tqf3ZL+v.net]: WindowsをCで書くわけにはいまさら中々いかないだろう。
かといってgcのある言語やインタプリタのようにアプリ寄りの言語で書くのは不可能だろ。
そうやってnative codeを出せかつOSの記述も(苦労するが何とか)記述可能な言語は
消去法でC++しかなくなる。DとかRustじゃ無理。

また、Windowsと言う位だから、上位には何らかのOOP GUI IFを提供しなければならない。
別にC++のOOP機能が優れていたからWindowsがC++が記述されたわけではない。
ここ勘違いしないように。
659 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 19:25:35.43 ID:lYyho1IC.net]: WindowsがOOそのものの思想、と言うのはハンドルまみれなAPI群があるので素直に同意できないけど、ウィンドウ周りは多少は頑張った感あるよね。
>>633
ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時にメモリが節約できるというメリットがあるかと。
660 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 19:29:38.91 ID:5naxcKBN.net]: シグナルが何とかならないかと思うけど
atomとかもう使いたくない
661 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 20:24:37.00 ID:Z6PD3tJ3.net]: >>526さんへ

示された所じゃなくて
その下に有ったリンク先を読んで解った事が有った
https://qiita.com/hiruberuto/items/26a813ab2b188ca39019
読んでいて何が自分に難しいのか?

関数型の場合
処理対象全域を考えて関数で並ぶように作らないといけない
副作用やその他の物を一時に頭に入れて整理し無いといけない
(リンク先にはそうではないと書かれているが自分にはそう見える)

けどオブジェクト指向の場合
対象となる処理を分割して個々に作っていく
分割して個々に作っていった物を連携させて
最終的にはその集合体が出来上がれば機能する
という方が自分に向いている

頭が悪い人間と言うのは広く色んな要素が一編に出て来る物の状態を正確に把握して
それを組み立てる
というのが苦手なのよ

関数型プログラミングは間違いなく
使える人が限られる
そういう物になるだろあなぁ

でもc++なんかでも標準ライブラリーに既にそれっぽいのが有るから
使える程度には理解しないといけなくなるんだろうねぇ
その程度ならなんとかなるかなぁ(笑)

何にしても参考になりました
662 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 20:28:18.73 ID:kgyl4Ui4.net]: >>637
バカじゃん
テメー以外の奴が作ったときに
privateにされたらそれでしめーだろーが

そういう当た
663 名前：り前の想像力が欠落してるからテメーは何考えても ダメダメのうんこちゃんなんだよ []: [ここ壊れてます]
664 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 20:31:49.61 ID:kgyl4Ui4.net]: メソッド呼ぶたびにクソクラスの内部のウンコがどうなってるのか
ケツアナほじって掻き出さなきゃいけねーんだよ
665 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 20:35:33.15 ID:IMi/szTI.net]: 標準ライブラリのprivateメソッドとか
もうソースコード読みまくりだからな
666 名前： mailto:sage [2018/10/08(月) 20:52:27.06 ID:Vh0J6/Nb.net]: >>635
＞ウィンドウクラスとウィンドウを別管理にすることで、同じウィンドウクラスを使い回す時に
同じウィンドウクラスを使いまわすっていうのが、そういうことをやる機会があるかどうか、という点でいまいち、なんです
つまり現状のウインドウクラスにてウィンドウプロシージャを設定する、というのが疑問でして、ウィンドウプロシージャが ::CreateWindow() の引数だったら、使いまわす、ってことも検討したかもしれませんが
667 名前：デフォルトの名無しさん [2018/10/08(月) 21:30:56.46 ID:811LgONL.net]: >>637
foreach, map, reduce, filter などを使うことによって、
for ループやif分岐や一時変数を使う助長で古典的な書き方から脱却し
リストの要素間の多対応・変換を宣言的に記述し切っていく、
既存言語に拡張されつつある関数プログラミングパラダイムの
限定的でも美味しいとこ取り的な使い方からはじめても全然いいんジャマイカ
668 名前：デフォルトの名無しさん [2018/10/08(月) 21:35:43.59 ID:811LgONL.net]: あと、詳しく書くと長くなるので一言ずつ書くと
繰り返しではなく末尾再帰を使えるところでは活用する
クラスを設けて多様性をあらわすのではなく、クロージャーや部分適用で簡潔に表現する
遅延評価や関数変換を使って有効なところで使う
とか
669 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:36:52.15 ID:IMi/szTI.net]: 関数型とオブジェクト指向は実は相性がよくて、
オブジェクト指向でオブジェクトとしての構造を
そしてオブジェクト指向の中で使う関数は関数型と
組み合わせて使うのが最強なんだ
670 名前：デフォルトの名無しさん [2018/10/08(月) 21:39:02.72 ID:811LgONL.net]: >>644
だからそれはレイヤやグレインの観点から上手くいかないんじゃないかって
上で書いたのに。
上手くいく方法があったら披露してよ
671 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:43:02.58 ID:IMi/szTI.net]: 末尾再帰の話が出てきたから、知識の浅い人に説明しておくと

関数型は再帰で実装するから手続き型のループを使う方法よりも遅いという常識を
特定の条件を満たしている場合にループに変換することで、遅くならない
というもの。決してループよりも速くなるわけではない
672 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:45:21.28 ID:IMi/szTI.net]: >>645
何ができたらうまくいくってことになるんだ？

俺にとっては開発が楽になることがうまくいくことだ
楽になってるのでうまくいっている
673 名前：デフォルトの名無しさん [2018/10/08(月) 21:45:58.21 ID:811LgONL.net]: >>644
あとcontinuationとかyieldとか使うと幸せになることがたまにあるぜよ
674 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:46:30.31 ID:IMi/szTI.net]: >>648
はい。オブジェクトの内部で使います
675 名前：デフォルトの名無しさん [2018/10/08(月) 21:47:17.86 ID:811LgONL.net]: >>647
何の言語で何をどう作ってんだか知らないが
上手く言っているなら方法論を披露プリーズ
676 名前：デフォルトの名無しさん [2018/10/08(月) 21:48:12.08 ID:811LgONL.net]: >>649
methodの中つまり関数の中でだろ
677 名前：デフォルトの名無しさん [2018/10/08(月) 21:50:45.37 ID:811LgONL.net]: 明日出勤なので寝るぜ
あばよはげどもﾉｼ
678 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:51:32.33 ID:IMi/szTI.net]: >>650
方法論ってなにがほしいのか知らんが、
関数型言語で作ったライブラリは状態を持たないから
汎用的な関数ライブラリになる。
それを便利にオブジェクトで使用する
679 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:53:09.64 ID:kgyl4Ui4.net]: オブジェクト指向のメリットは説明できたかい？

定期的に貼らないと関係ないこと主張する奴がわくからな
これが説明できないならクソ
680 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 21:56:30.02 ID:IMi/szTI.net]: オブジェクト指向のメリットは状態を
簡潔にわかりやすく持たせることができる

アルゴリズムならともかくシステムから
状態をなくすのは不可能なので
それをどれだ�
681 名前：ｯ直感的に扱うか不可欠になる それが関数型に対するオブジェクト指向のメリット []: [ここ壊れてます]
682 名前：デフォルトの名無しさん [2018/10/08(月) 22:00:12.76 ID:811LgONL.net]: >>655
直感ですか…
683 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:01:29.15 ID:r/3VlGF9.net]: OOPのメリットを教えてくれる奴なんていくらでもいたよな
それでOOPが普及して
ふと気付いたらメリットが何だったのか思い出せない

ここでまたメリットを教えられても無限にループするだけだ
684 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:05:17.61 ID:IMi/szTI.net]: >>656
そう。3歳の子供でも、リンゴとミカンの色や形
犬や猫の鳴き声の違いぐらいわかるだろう。
それぐれいオブジェクト指向は人間の思考と一致している
685 名前：デフォルトの名無しさん [2018/10/08(月) 22:05:31.32 ID:811LgONL.net]: 型クラス、クラスscope、オブジェクトscope,
同じ名前の多態(振る舞いの違い)、
継承によるあっちこっちに無難格納したソースファイルの
似たmethon部分の短冊のような共有による依存性のジャングル

これらについて理論的、科学的に有効性を述べないとだめだよ
686 名前：デフォルトの名無しさん [2018/10/08(月) 22:11:45.44 ID:811LgONL.net]: そう、そしてそれらがある程度規模の大きく複雑な
アプリケーションレイヤのソフトウエアの構造表現として
どう有効なのか理論的、科学的に述べないと…
687 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:19:30.00 ID:r/3VlGF9.net]: 確実にメリットがあるなら人には教えないで独占する
それが理論的で合理的

確実ではないギャンブルなら人に教える
688 名前：デフォルトの名無しさん [2018/10/08(月) 22:28:08.41 ID:811LgONL.net]: >>661
つまりメリットは無いとｗ
689 名前：デフォルトの名無しさん [2018/10/08(月) 22:33:36.33 ID:811LgONL.net]: ｵﾌﾞｼﾞｪｸﾄ指向は低学歴にはﾑﾘ
それはあってる

ｵﾏｴも含めてな
690 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:34:58.92 ID:6UIbz9ua.net]: たまに見るけど100%でない=0%の人の思考はどうなってんだろうね
691 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:35:17.30 ID://kQ6Yzy.net]: パニックでも起しちゃってるのかなこの子
692 名前：デフォルトの名無しさん [2018/10/08(月) 22:37:03.95 ID:811LgONL.net]: 低学歴知恵遅れが自分を大きくみせようと
必死なのはわかる
693 名前：デフォルトの名無しさん [2018/10/08(月) 22:38:24.97 ID:811LgONL.net]: だいたいわかる

ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる
694 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 22:44:26.66 ID:YGZFPxYk.net]: まーたお前かいつも必死だな
695 名前：デフォルトの名無しさん [2018/10/08(月) 22:51:37.06 ID:811LgONL.net]: 節子それfake
696 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 23:13:05.52 ID:r/3VlGF9.net]: 1bit思考の中で最悪なのは、需要と供給
買う方が100%自己責任と思ってるから売ってる側は罪悪感0
697 名前：デフォルトの名無しさん [2018/10/08(月) 23:18:57.76 ID:811LgONL.net]: その論点から起こしてだね、
オブジェクト指向の有効性を非論理的、寝技的に布教しようとするのは
いくらなんでももう、無理があるよ
698 名前：デフォルトの名無しさん mailto:sage [2018/10/08(月) 23:40:30.66 ID:C02Vpegg.net]: ここの議論でもそうだけどカプセル化とかインターフェイスに対するプログラミングとか
ここの要素について話すのは意味があるが
「オブジェクト指向」って言葉でまとめると途端にクソ議論になる。
その意味ではやっぱり失敗だろう。
699 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 02:31:35.79 ID:GxJd+3a3.net]: >>672
その辺はポジティブな意味合いが強いからな
ただメリットがあるからってデメリットがどうなるかは別問題として
700 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 06:16:50.45 ID:1H6kld1Z.net]: カプセル化とかは「学習コスト」だから100%ネガティブ
コストを消費する代わりに何かメリットがないとポジティブどころか中立にもならねえ
701 名前：デフォルトの名無しさん [2018/10/09(火) 06:53:21.12 ID:Fv2MSo0/.net]: 今になって思うのは、オブジェクト指向にまつわる説明で特徴的な何々は何々であるだから何々があるはずだ的な事は製作者側の考え方の根本だったんだろうな。
ここに共感してないから触ってても疑問がつきまとう。
それでもってこういう考え方をする奴は布教的な奴が多い。こういう奴らは本当本当に嫌いだわ。人のその後に対する考えなんてみじんも無い。
例えばウェブ上で人気の言語的なランキングで上位に入ってる言語と周りを見渡して実際触られる言語の食い違いがひどい。
他の奴の意見見てると大体同じ感覚で変な笑いがでる。
702 名前：デフォルトの名無しさん [2018/10/09(火) 07:05:27.74 ID:xcSr1k5g.net]: 振り返ると、信仰宗教みたいな流行だった
703 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 10:12:33.99 ID:hleJLyKe.net]: オブジェクト指向の宗教的側面と、Rubyの宗教的側面がかけ合わさって
ドン引きするレベルの狂信者が出現した

もはや言語は死につつあるのに狂信者は毎日板を荒らし回ってる
704 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 10:58:21.87 ID:MhhKJFZu.net]: >>674
学習コストはなんにでも適用できる
一般的すぎて無視できる

プログラムを作るにはカロリーを消費すると
言うようなもの、そらそうだで終わり
705 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 11:01:37.61 ID:MhhKJFZu.net]: カプセル化してしてデータを閉じ込めることこそ
オブジェクト指向の真髄、データに対する責務を
集約する事でプログラムを作りやすく堅牢で
メンテナンスしやすくできる
706 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 11:40:52.35 ID:1H6kld1Z.net]: >>678
コストがあるから見返りにメリットが必要だったんだが
コストを無視するならもうメリットがあってもなくてもいいぞ
707 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:02:03.11 ID:MhhKJFZu.net]: >>680
一般論過ぎてオブジェクト指向の話になってないやん
708 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:02:46.32 ID:MhhKJFZu.net]: 赤信号なら止まると良いぞと言ってるようなもの
当たり前やん
709 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:05:55.31 ID:MhhKJFZu.net]: オブジェクト指向テクニックを使うと外から壊されにくい
堅牢なデータ構造を作ることができてプログラムの
完全性を保証できる、オブジェクトを組み合わせて
より大きなプログラムを作れるっていうのが
オブジェクト指向のメリット
710 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:11:49.02 ID:1H6kld1Z.net]: 当たり前すぎるってあれだよな
反証不可能ってやつ
反証したい勢力と対立煽りするくらいがちょうどいいんだよな
711 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:12:29.16 ID:MhhKJFZu.net]: データ隠蔽が有害っていうのは嘘だ
データは隠してなんぼ、オブジェクトを使う側に
データの存在を意識させないようにする事で堅牢な
プログラムを構築できる
712 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 12:44:03.73 ID:3cHmJpwL.net]: 大規模開発はオブジェクト志向が、
とか喧伝する低偏差値信者もおとなしくなり、
一歩下がって、そんなに良いものだったっけ？と振り帰られる雰囲気がでてきたのは良いこと

いつまでも熱狂信者の思惑通りにはいかないよ
時がたてば、本当にコストペイするものだけが生き残る
713 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 15:34:08.86 ID:s6lFROtd.net]: >>685
テストもできないのが不味い
結局使用する側が状態を意識しなくてもいい造りなら問題はおきない

でもinitメソッド連発で呼ばれると死ぬだろ現実
initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ
ってのが呼ぶ側の主張
714 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 16:17:24.49 ID:MhhKJFZu.net]: >>687
ヌ
715 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 16:51:04.98 ID:DgfNcklC.net]: >>688
ル
716 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 17:11:39.56 ID:UgeI4/Dm.net]: >>687
> でもinitメソッド連発で呼ばれると死ぬだろ現実
> initメソッド呼んだんだからどんな状態であれ初期状態に移行しろよ

どんな場合でも初期状態に移行すればいいだけでは？
717 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 17:18:38.78 ID:n+YH3pNB.net]: 別スレッドでアクセス中でもか？
718 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 17:23:43.77 ID:UgeI4/Dm.net]: >>691
別スレッドでアクセスさせなければいいだけ
719 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 17:54:07.48 ID:MhhKJFZu.net]: スレドセーフじゃないのなら仕方ない
720 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:17:11.30 ID:o83bbsRF.net]: >>690
でも実際はハードに近い部分のinitだったりするとそうはいかないケースがあるよね？
って可能性が想定できないなら君は設計を語るレベルにないんじゃない？
721 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:33:33.36 ID:UgeI4/Dm.net]: >>694
自分の都合がいい条件じゃないと当てはまらないと
認めているようなもんじゃないかｗ
722 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:37:20.67 ID:o83bbsRF.net]: >>695
いやいや、この場合そういうケースがあることを説明できればいいよね
723 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:50:57.71 ID:UgeI4/Dm.net]: >>69
724 名前：6 じゃあそういうケース以外には当てはまらないってことでいいよね 例外中の例外なんてどうでもいいわ []: [ここ壊れてます]
725 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:51:36.15 ID:UgeI4/Dm.net]: それに関数型だとハードに近い部分はさわれないし
726 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 18:52:15.46 ID:jSAcVkU7.net]: メソッド呼ぶほうが呼び出し順にナーバスな設計というのが糞
内部を隠蔽できてねーやんというだけのこと
727 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 19:29:52.46 ID:o83bbsRF.net]: >>697
問題はオブジェクトが状態を内包しちゃってることなんだけど？
728 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 19:31:40.73 ID:o83bbsRF.net]: んでそれを踏まえて
お前のクソクラスは息してんの？
って話
レアケースだから死ぬわってお前
言ってるように聞こえるけど
バカなん？
729 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 20:06:57.87 ID:9OTFAl28.net]: >>689

うるせぇエビフライぶつけんぞ

,.、,､,..,､､.,､,､､..,_　　／i
;’｀;、､:、. .｀ﾞ:.:ﾞ｀’’’:,’.´ -‐i
‘、;: …: ,:. :.、..; .;;.‐’゛￣￣
　　　ヽ(´･ω･)ﾉ
　　　　 |　 /
　　　　 UU
730 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 20:08:18.35 ID:UgeI4/Dm.net]: >>700
オブジェクトが状態を内包するか
オブジェクトの外に状態を置くかの違いでしか無いですね
731 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 21:39:06.76 ID:o83bbsRF.net]: >>703
だからその一点でクソだって言い続けてるじゃん
カプセル化がどうとかバカの妄想だろ
テメーの状態がわからねーのが一番のリスクなんだよ
何がカプセル化だよ
早く死ねよ
732 名前：デフォルトの名無しさん [2018/10/09(火) 21:45:21.47 ID:Z2FoPQmM.net]: localなデータを局所に隠蔽するべきなのはソフトウエア工学上、
当然のことでカプセル化の専売特許ではない。
ほぼすべての最近の言語はlocal scopeを持っている。
だがオブジェクト指向のカプセル化によるデータの内包とアクセサは
他の言語の持つモダンな階層的scopeに管理工学的にはるかに劣る。
ここ勘違いしないように。
733 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 21:51:03.83 ID:9yAlTK3b.net]: >>705
日本語w
734 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 21:54:07.22 ID:Fg4seD6E.net]: テクニカルタームで煙に巻くのも便所の落書き
735 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 21:57:54.52 ID:n+YH3pNB.net]: まあ、forループの回数カウンタなんかローカルで充分だしな。
736 名前：デフォルトの名無しさん [2018/10/09(火) 21:58:49.50 ID:Z2FoPQmM.net]: この程度でテクニカルターム…
737 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 22:30:33.22 ID:UgeI4/Dm.net]: >>704
ようするにテストはプライベート変数を見たいってだけですよね？
テスト以外では必要ないですよね
カプセル化バンザイですよね？
738 名前：デフォルトの名無しさん mailto:sage [2018/10/09(火) 23:05:57.02 ID:5o1aZXWL.net]: どれくらいのアクセス度がいいかはそのクラスのそれぞれによるところはある。
STLのvectorなんて見方によってはかなりオープンだけれどあれはあれで適切な開け方。
739 名前：デフォルトの名無しさん [2018/10/09(火) 23:18:00.29 ID:uKgwXIAC.net]: 内部の状態が心配なら
ちゃんとｸﾗｽに内部の状態を（ｺﾝﾎﾟｼﾞｼｮﾝなら当然再帰的に）ﾀﾞﾝﾌﾟする関数ぐらいつけてんだろうな
つけてないならお話にならない

外部で状態を管理して
外部で構造体を監視するのと
そう変わらない
740 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 00:01:14.01 ID:j7g+1zT7.net]: >>710
テストだけではないな
その関数が同一の結果を返す条件を固定したい
っていうかできねープログラムなんてぶっちゃけクソもいいとこだろ
741 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 00:06:10.55 ID:+GhPUDy2.net]: 仕事関係なく趣味でソフト作ったやつの意見は尊重できる。仕事だけで横文字多様してる奴のはフィルター推奨だな。
742 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 00:10:05.04 ]: [ここ壊れてます]
743 名前： ID:+GhPUDy2.net mailto: 流石にいないか。それは。 []: [ここ壊れてます]
744 名前：デフォルトの名無しさん [2018/10/10(水) 00:54:19.42 ID:T78UR1cm.net]: 本当にそれは状態として動的に管理すべき対象なのか
十分吟味してないだろ
745 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 01:07:23.22 ID:YM9RoEIA.net]: >>716
ん？
じゃあ、クソインスタンスがどんな状態でメソッドを呼んでも絶対同じ結果返すんだな？
その時点でメンバ変数いらねーけど
746 名前：デフォルトの名無しさん [2018/10/10(水) 01:35:56.64 ID:T78UR1cm.net]: >>717
日本語読めるようになってからレスした方が良いよ
747 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 01:48:46.78 ID:s7T/eKYL.net]: >>713
お前は現在時刻を返す関数は一生使うなよ
クソなんだろ？
748 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 02:19:17.93 ID:vuJDL2IF.net]: Haskellでいう副作用なら標準入出力、ファイルio、時間、ランダムなどが副作用なるな
モナド並にリッチなシステムをオブジェクト指向で組んで副作用を過敏排除するなら楽しそうやんけ
749 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 06:36:14.84 ID:az2ldVPt.net]: >>713
> その関数が同一の結果を返す条件を固定したい

引数Aにaを入れる、引数Bにbを入れる、引数Cにcを入れる
引数A、B、Cで関数funcを呼び出す

メソッドAでaを入れる、メソッドBでbを入れる、メソッドCでcを入れる
メソッドfuncを呼び出す

関数の引数に値を入れる代わりにオブジェクトに入れるだけの違いでしか無い
750 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 07:54:35.27 ID:75F81x8u.net]: >>719
現在時刻しか返ってこねーだろ？
テメーのは指定してもいないのにサマータイム返すクソだろ
751 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 07:55:48.71 ID:75F81x8u.net]: >>721
でも入力値は使用する側が意図的に入れるものだけど
メンバ変数は何になっているかわからない

この差がデカイ
752 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 08:08:36.10 ID:WWPIMa8b.net]: >>713
>その関数が同一の結果を返す条件を固定したい
同じ条件で違う結果が返ってくる関数ってハードウェア乱数発生器とかしか思い浮かばないんだけど、具体的にこんな関数ってのある？
753 名前：デフォルトの名無しさん [2018/10/10(水) 08:42:05.46 ID:00uAZtDo.net]: >>714
結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。
簡単な事を冗長的にフレームワークのようにしたコードが多くてただの社内での点数稼ぎなんだろうと伝わってくる。そして少し環境を変えてシステムを構築し直す時に問題が出て来るのって大抵そういうコードだったりする。
754 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 08:49:14.91 ID:az2ldVPt.net]: >>723
> でも入力値は使用する側が意図的に入れるものだけど
> メンバ変数は何になっているかわからない

変数に文字列入れたって、それがどういうフォーマットで入っているかなんてわからんだろ

文字コードは何なのか、内部エンコーディングなのか
文字列の最初に文字列長情報がついているのか
文字の終わりは\0なのか

変数に数値入れたって、それがどういうフォーマットで
入っているかなんてわからんだろ

32bitで保存されているのか、64bitなのか

変数に入れようがメソッド呼び出そうが
ある一定の手順の操作を行えば、それで状態は確定するんだよ
755 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 08:50:44.41 ID:az2ldVPt.net]: >>725
> 結局それも色々賢そうな事書いてるであろう仕事で書いてる人のコードが見てて凄いと思わないんだよ。

あぁ、プロの将棋を素人が見ても、凄さを理解できないのと同じだな
んで、何やってるか理解できないから、直すこともできない
756 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 09:25:59.20 ID:lh7vR7+I.net]: 凄さを理解されなくても半分諦めてるプロって
ラノベ主人公でよくあるやつじゃん
757 名前：デフォルトの名無しさん [2018/10/10(水) 10:18:56.28 ID:00uAZtDo.net]: 素人とプラグラマーに根本的な差を感じてる奴はちょっと怪しいな。
758 名前：デフォルトの名無しさん [2018/10/10(水) 10:58:13.09 ID:00uAZtDo.net]: 素人だからこそ言い切れる。プログラミングって9割はツールを使いこなせるでしか無いよ。
将棋に関してもたぶん君は将棋について詳しくない人だと思うな。
759 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 11:03:52.32 ID:az2ldVPt.net]: 素人が�
760 名前：ｾい切れるわけ無いだろ。常識で物を言えや []: [ここ壊れてます]
761 名前：デフォルトの名無しさん [2018/10/10(水) 11:48:06.40 ID:00uAZtDo.net]: ま、分かったじゃあそう思っとけ。このご時世どんなに賢ぶってもそんなに凄いプログラマーが日本に溢れてないのが透けて見えてるんだけどな。
762 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 12:27:49.69 ID:AVL6Qil2.net]: 俺もオブジェクト指向を中途半端にかじった中途半端な優等生が、
これ見よがしに作った自社製フレームワーク(全然便利ではない)しか
見たことないわ

作ったのは一流大卒の大手ベンダーの開発推進チームなんだが、
日本人ってその程度だと思うよ

Stringクラスって便利ー！ぐらいのほうが幸せになれるぞ
763 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 12:30:14.49 ID:AVL6Qil2.net]: 中途半端な優等生の成果物がその程度なんだから、
三流大卒のおまいらの成果物なんて推して知るべくだよな
764 名前：デフォルトの名無しさん [2018/10/10(水) 12:35:08.25 ID:Vh7YHzSV.net]: べつに透かさんでも直接見えるやろw変なやつw
765 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 12:49:50.06 ID:2nqQsSqL.net]: >>726
でもprivateだとわからないよね
766 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 13:52:34.56 ID:VeUMq7t7.net]: プログラミングセンスと学力ランキングは比例しないんだよなぁ
767 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 13:57:58.08 ID:VeUMq7t7.net]: むしろ個人の性格の方がそのまんま実装に現れて来るからな。
768 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 14:27:07.52 ID:DTkCRDr0.net]: 学力ランキングを批判するだけなら良いぞ
だが、学力の対案は性格っていうのがダメだ
おかしな対案を出すより何も出さない方がマシ
769 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 17:10:39.36 ID:az2ldVPt.net]: >>736
分かる必要がないよね。

どうせ関数型だって内部メモリの構造なんてわからないんだから
770 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 17:55:56.61 ID:DTc0bT+8.net]: >>733
大手企業のフレームワークは派遣さんがアホなことをしないようにあえて機能を制限してる
生産性が多少犠牲になっても非常識な派遣さんがやらかしてしまうリスクを減らすことが重要と考えたんだね
そういう意味ではオブジェクト指向の基本であるカプセル化は非常に役に立っていると言える
771 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 18:01:10.70 ID:az2ldVPt.net]: >>741
なら派遣を使うことがリスクなのでそれをやめればいいと思います。

本当のリスクは・・・無理なコスト削減なのでは？
コスト削減のために、無駄なコストをかける。

うーん、馬鹿なのでしょうね
772 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 18:25:41.34 ID:crjMMeGj.net]: 既存のフレームワークにケチつけたい人は
それ以上のものを作れる人なの？
それとも、作れないし作ったことも無いけどケチつけたい人なの？

煽りじゃなくて純粋な疑問
ぜひ、小学生のような瞳をしてそっと教えて欲しい
773 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 19:14:20.95 ID:DTkCRDr0.net]: それを教えないのが正義っていうのが情報隠蔽、カプセル化
774 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 19:28:47.64 ID:AZXT33MT.net]: ママ役は薄幸そうな石田ゆり子かな

異論は認める
775 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 19:29:51.69 ID:AZXT33MT.net]: すまん、誤爆だ
776 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 20:28:30.09 ID:DTc0bT+8.net]: >>742
派遣さんを切ったら中抜きで稼いでる人達が困る
派遣さんは使う、でもバカな真似はやらせたくない
このバランスが大事
777 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 20:31:47.32 ID:1d6HAJSZ.net]: 最近は中抜きはまだまともな行為だと思えてきた。
バカがクソみたいな意見押し通してくるよりマシだ。
そういう意味でベイシックインカム賛成。
778 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 20:32:00.42 ID:az2ldVPt.net]: >>747
結局、中抜きで困るからっていうのが本当の理由なのね（笑）
779 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 21:57:06.99 ID:YM9RoEIA.net]: >>740
え？グローバル変数使わなければ戻り値か引数が全てだけど？
780 名前：デフォルトの名無しさん mailto:sage [2018/10/10(水) 22:09:31.63 ID:crjMMeGj.net]: >>750
つ[クロージャ]
781 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 06:25:53.98 ID:o+Pj5MkJ.net]: 有識者、燃料投下ヨロ

くだらなくてつまんない
782 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 17:52:18.63 ID:lqVwZR/7.net]: んじゃクロージャ出たから

オブジェクト指向で末端の人、要は上の誰かが作った仕組みやクラス使って自分はそこからオブジェクト弄るだけの人は可能な限りクロージャ使いまくった方がと思うんだよな
よく委譲処理でこのふたつどちらか選ぶ事あると思うんだが末端なら即クロージャ
783 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 19:53:44.01 ID:hrM+9Jlq.net]: >>714
仕事は範囲が限られているからね
その仕事でやらなければならない範囲だけ出来れば
後は何が出来ようが出来まいが関係なくなるからね
一言で言えば視野が狭い
横文字を多用する人は狭い世界で通じてそれでokになっちゃってる
多種ではないし世界が兎に角狭い
実際ゲームなんかでは敵クラスを作って敵が増えるたびにオブジェクトを生成する
ってやると感覚的に凄く簡単
784 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 20:31:48.13 ID:m9vsKwrk.net]: >>752
どんな話題が面白いの？
このスレ的にはオブジェクト指向のメリットが説明できなければ
終わりなんだけど
785 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 20:34:12.11 ID:U1kKB/4M.net]: 逆でしょ？説明されれば終わりなのがいやだから
答えが出てるのに、同じことをくり返し聞く
786 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 20:38:52.62 ID:m9vsKwrk.net]: >>756
え？メリット出てる？
見たことないよ
毎回、バカが長文書くだけで
品質向上なのか工数削減なのか、それが起こるロジックが全くの謎
787 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 21:05:36.68 ID:o+Pj5MkJ.net]: 犬がワン、猫がニャン
→なにそれ美味しいの？

大規模じゃないとメリット説明しにくいよ
→説明できないって、大規模なプログラムを経験して体で覚えろと？

要するに、簡単には説明できないよ
→だったら学習コストとの天秤では？

俺の中ではこんな感じ
788 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 21:06:47.80 ID:U1kKB/4M.net]: 品質向上だし工数削減にもなる

馬鹿はそこでなぜか品質向上と工数削減のために
追加作業が増えるとダメだと話を聞かない
789 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 21:07:43.81 ID:o+Pj5MkJ.net]: ちな俺、初心者プログラマだけど宮廷文系
790 名前：デフォルトの名無しさん [2018/10/11(木) 21:48:27.62 ID:29n02hV2.net]: いわゆる土方候補生か
791 名前：デフォルトの名無しさん mailto:sage [2018/10/11(木) 22:35:19.32 ID:FTrPBrPb.net]: >>753
関数ポインタと汎用のvoidポインタ渡すインターフェイスより明らかに良いとは思うけど、
ガベコレない言語では上手くいかんだろ。
その場合は継承させるしかないっていうc++の選択は間違いじゃない。
792 名前：デフォルトの名無しさん [2018/10/12(金) 00:40:23.27 ID:U1NbXGxJ.net]: >>762
そういう欠点解消するため、
結構前に拡張されたのに何で勉強しないのかねOOP厨はﾎﾝﾄにもう
https://cpprefjp.github.io/lang/cpp11/lambda_expressions.html
793 名前：デフォルトの名無しさん [2018/10/12(金) 00:47:17.48 ID:U1NbXGxJ.net]: ｵﾚぐらいのﾚﾍﾞﾙでないと
ｵﾌﾞｼﾞｪｸﾄ指向は使いこなせない
794 名前：デフォルトの名無しさん [2018/10/12(金) 00:47:48.97 ID:U1NbXGxJ.net]: だいたいわかる

低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる
795 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 00:48:51.77 ID:mmIXjKhu.net]: メリットの挙げられない技術を採用するな
796 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 07:03:34.63 ID:ogDn0rIL.net]: >>762
全く解消されてないだろ。。
キャプチャーしてる変数の寿命を考慮してなきゃならんし、こんなん使わねーわ。
797 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 08:23:50.28 ID:8+F5vpV5.net]: 型の問題と寿命の問題を分離しない
OSとGUIを分離しない
フルスタックな環境を作る密結合指向って感じ
798 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 10:20:48.35 ID:4mK9L0 ]: [ここ壊れてます]
799 名前：RW.net mailto: >>768
それただの設計の問題じゃね？ []: [ここ壊れてます]
800 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 11:04:22.00 ID:8+F5vpV5.net]: >>769
その設計にオブジェクト指向が関与していると疑われている
その問題の解決にオブジェクト指向は全く寄与しない、と宣言すれば疑いは晴れる
801 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 11:12:44.85 ID:4mK9L0RW.net]: >>770
いや、どう見ても設計の機能分けの問題
オブジェクト指向の前にレイヤーってあんだろ？
802 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 17:19:28.65 ID:5jm0P0/q.net]: オブジェクト指向信者もDI信者も同じ臭いがするね

【Java】DIコンテナって本当に便利か？
mevius.5ch.net/test/read.cgi/tech/1219242206/

次は何を担ぐのやら

外国で流行って育っていくのだから、それなりのメリットはあるんだろうけど、なぜか仕事では恩恵にあずかったことはない
803 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 20:33:03.38 ID:4mK9L0RW.net]: 設計のセンスの無い奴はどんな流行が来たって糞な設計しか出来ないんだよなぁ
センスがある奴はなんとなくどんな流行のスタイルでもこなして来るからなぁ
804 名前：デフォルトの名無しさん [2018/10/12(金) 20:41:34.47 ID:CecLyO81.net]: どーでもいーけどコーディングの事設計てゆーのいーかげん恥ずかしくね？w
805 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 20:45:43.93 ID:4mK9L0RW.net]: は？
設計はコーディングじゃねーよw
四角い箱描いて矢印や電線で繋げて遊ぶ奴だぞ。
806 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 20:45:57.27 ID:SyXP90mj.net]: ある一定以下に対して理解できるような教範が出てこない
だから一部の人しか使えないようになってる
結局は出来る人の間で持て囃されるだけになってしまう
この何か新しいやり方を創造するのと一般に使えるようにする
というのは本来両輪なんだけど
普通以下の人達が使えるようになる教範を作る
というのはかなり難しい上に
それをやる人には余りメリットがないから
なかなか出てこない
だから
オブジェクト指向プログラミングにしても
関数型プログラミングにしてもその他の技術にしても
広く(普通程度以下)使われるのは難しいし
このスレのタイトルみたいな感想を持つしかなくなる
後は自分が出来るけど他の人が出来ないままのほうが出来る人には得だから妨害する
みたいなのが居るくらいだろうかねぇ
807 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 20:48:39.65 ID:4mK9L0RW.net]: あー電線繋げては遊ばないわ、危ないしw
点線の間違いだわ。
808 名前：デフォルトの名無しさん [2018/10/12(金) 21:12:49.59 ID:CecLyO81.net]: ガチでわかっとらん奴やったw
809 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 21:17:29.38 ID:mCoAwEvP.net]: >>772
DIはほんと便利
めちゃくちゃ開発が楽になった
810 名前：デフォルトの名無しさん [2018/10/12(金) 21:21:05.43 ID:xVyRtSc0.net]: 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない
811 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 21:27:17.84 ID:d1sPni1g.net]: 少なくともこのｽﾚにいるような低学歴知恵遅れのﾄﾞｶﾀには
ｵﾌﾞｼﾞｪｸﾄ指向言語を適切に使いこなせない
812 名前：デフォルトの名無しさん mailto:sage [2018/10/12(金) 22:41:19.80 ID:F7y/wInK.net]: >>772
テストしたことないのかい？
813 名前：デフォルトの名無しさん [2018/10/12(金) 23:12:30.21 ID:xVyRtSc0.net]: 日銀短観のDIは便利
池沼あげのDIはtraitsなみにｳﾝｺくさい
814 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 10:26:58.14 ID:YNebL+WU.net]: 今時DIも使いこなせない人材とか組織にとってのリスクでしか無いよ
あっちこっち結合しまくったクソコードを社内リポジトリにばらまくとか悪夢そのものじゃん
815 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 10:58:13.65 ID:H4Y+M12v.net]: DI使っても結合しまくったくそコードはくそのままだ
業務分析の時点でコケて役割分担がぐちゃぐちゃなんだからDI導入したって解決しない
816 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 21:25:17.45 ID:YNebL+WU.net]: >>785
DIを使わないから業務分析の時点でコケて役割分担がぐちゃぐちゃになるのでは？
設計者にDIを学習させてDIを使う前提で設計させればそのあたりの分担がキレイになるように意識して設計するようになるよ
817 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:13:29.66 ID:An0DfPZD.net]: >>786
818 名前：
それで成功した例なんてあんの？ []: [ここ壊れてます]
819 名前：デフォルトの名無しさん [2018/10/13(土) 22:15:51.44 ID:L3Dj2/gz.net]: cのたくさんの構造体にいっぱい変数や関数ﾎﾟｲﾝﾀもたせて
それ入力にして処理するのと同じ
820 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:29:25.59 ID:HA3RUpZg.net]: DIはたしかにきれいな設計になるが、めんどくて工数がかかる。
作業者にはYAGNIのほうが優先度高いから勝手に採用できない

だからそういうのはトップエンジニアが最初に管理方針としてきめとくもんだ
末端のプログラマーに責任押し付けるのは酷
821 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:38:19.49 ID:HA3RUpZg.net]: 今のDIはめんどすぎる
既存コードをいじらないで中身をすげかえる
もっと楽な方法はないものか
822 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:42:51.86 ID:An0DfPZD.net]: DIは言語自体に組み込まれるべきもの
高級言語はどんどん高級になるべきだが
ガベコレ搭載あたりで停滞してしまったからね

本来はDIやデザインパターンやユニットテストや
フレームワークまで高級言語の仕様に含めなきゃいけない
823 名前：デフォルトの名無しさん [2018/10/13(土) 22:44:08.09 ID:L3Dj2/gz.net]: ｲﾝﾀｰﾌｪｰｽを決め打ちにしたﾃﾝﾌﾟﾚｰﾄ作る間抜けな作りと
大してかわらないからな
824 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:48:54.83 ID:c+yfSqJ1.net]: 使用者との合意の無いインターフェースほどクソなモンは無い
独りよがりで考えたものは全部クソなので誰にも見られないうちに捨てて欲しい
825 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:54:18.52 ID:An0DfPZD.net]: 逆に言えば使用者との合意のあるインターフェースは問題ない
ということになってしまう。
826 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 22:59:41.42 ID:c+yfSqJ1.net]: >>794
もちろんそうだろ
827 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 23:21:29.03 ID:An0DfPZD.net]: >>795
あ、そうだって認めたねｗ

つまり、お前はインターフェースに問題があるとしようとしていたようだが、
俺はインターフェースには問題ないという話への誘導に成功したわけだ
828 名前：デフォルトの名無しさん [2018/10/13(土) 23:38:37.37 ID:L3Dj2/gz.net]: ｸｿが余計なことをして
余計にｸｿなｺｰﾄﾞを生産するｻｲｸﾙが途絶えることはない
829 名前：デフォルトの名無しさん mailto:sage [2018/10/13(土) 23:45:30.90 ID:An0DfPZD.net]: SEが余計なことをして
クソコードを量産することになるのは
よくある話だな
830 名前：デフォルトの名無しさん mailto:sage [2018/10/14(日) 11:01:28.22 ID:RzJcTIeH.net]: DIを使わないと結合部分に余計なコードが入り乱れて大変なんだよな
831 名前：デフォルトの名無しさん mailto:sage [2018/10/14(日) 12:27:39.55 ID:mBxOrkWE.net]: え？どんなコードが入るの？
ありえないのに
832 名前：デフォルトの名無しさん mailto:sage [2018/10/15(月) 20:24:46.22 ID:vo4hBZ/w.net]: なあ、おまえのクラス内に公開変数作って、そいつをインクルードして関数呼び出し時にポインター参照で指定するなんてインターフェス、誰が言い出したの？
しかも各関数は自前のその公開変数を直接参照して動いてるし。
こんな中途半端なやり方するなら、最初から隠蔽しちゃってくださいよ。
833 名前：デフォルトの名無しさん mailto:sage [2018/10/15(月) 20:30:03.66 ID:1WHouwEf.net]: ごめん自分のデータクラスを全クラスの共通IFにする自信がなかった
834 名前：デフォルトの名無しさん mailto:sage [2018/10/15(月) 21:16:54.08 ID:E6pr56BO.net]: 　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
835 名前：デフォルトの名無しさん [2018/10/16(火) 03:09:47.94 ID:ou8fzFot.net]: この記事拍手の数すげぇな。まだ伸び続けてる
Goodbye, Object Oriented Programming
https://medium.com/@cscalfani/goodbye-object-oriented-programming-a59cda4c0e53
836 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 07:54:43.79 ID:Z3LiiLXa.net]: 誰か和訳してよ
837 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 07:57:35.98 ID:Z3LiiLXa.net]: オブジェクト指向を厚く語るヤツは
お勉強いまいちのヤツが多くて信用できないけど、
さらっとオブジェクト指向で書いたようなライブラリを公開してるヤツが
高学歴というわけでもない不思議な業界だよね
838 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 08:20:25.22 ID:Jp8CUHhN.net]: Banana Monkey Jungle Solution

まで読んだ
839 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 09:47:48.81 ID:hiAtkD1Q.net]: Elm最高まで読んだ
840 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 10:44:44.96 ID:KsONw+2K.net]: 結局関数プログラミングが良い
って書いてある様に見えるけど
オブジェクト指向に対して何がどう良いのかは書いてないように見える
オブジェクト指向の問題点の指摘自体は有ってるように思えるけど
そもそもそういう使い方をするものじゃない
って気がするなぁ
現実世界とどうたらこうたら
こういう書き方をする人は自分からみてほぼ間違えている様に見える
騙された
って書いて有るけど
オブジェクト指向ってそんなに劇的に何かが壮大に変わるわけじゃないんだけど
その辺を誤解しているかオブジェクト指向を宣伝している奴がそもそも捕らえ違いをしている
そう自分には感じる事が多いなぁ
841 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 10:49:18.08 ID:hiAtkD1Q.net]: 現実世界とマッピングさせようとしたらそりゃ上手くいかんし
バナナモンキージャングルになるわな
あほくさ
842 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 11:00:52.85 ID:sVO7hlJ7.net]: アクセス修飾子について分かりやすい説明しているサイトない？
privateからゲッター → セッターの理由がわかんないんだよな。
publicとの違いがなんなのか
843 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 11:06:30.91 ID:HqnwAz6t.net]: >>811
アクセサーを用意すると
ゲトーとセトーのアクセスを個別に制御できる
844 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 11:07:25.98 ID:HqnwAz6t.net]: ゲターもせターもパブリクーにするなら
アクセサーとフィールドの違いはない
845 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 11:39:32.23 ID:8J+M5yKD.net]: あとから処理をフックできるぞ！
846 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 11:40:12.83 ID:Ul6KAhVk.net]: setget時にログ出したいときに一括でできるぐらいか？
847 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 13:06:07.08 ID:GbK/byr7.net]: >>811
わかんないなら使わなくていいよ
用もないのにゲッターセッターを用意しろってのは間違って広まった悪いスタイルだ

多態したいとか、書かれてるようにログを取りたいとか、アクセサがあるとインスペクタで値が見えて便利とか
なんか用事がある時だけでいい
848 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 13:22:26.52 ID:sVO7hlJ7.net]: >>816
色々サイトみてるけど不要論も結構あるんだよな

よくわからないけどありがとう
849 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 14:20:20.47 ID:cFNbEHw0.net]: 言語仕様で何とでもなるものにいちいちゲッターセッター付けるの無駄じゃね？
850 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 14:59:03.86 ID:8J+M5yKD.net]: それがプロパティなわけだが
ゲッターセッターと機能が重複しててほぼシンタックスシュガーで邪魔
851 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 15:33:44.68 ID:pkWZobMJ.net]: 今時まだゲッターセッターなんて無意味なもん書いてる奴いんのか。
852 名前：デフォルトの名無しさん [2018/10/16(火) 16:52:45.97 ID:nQomBRvE.net]: セットなんちゃらって書く場面を考えると
なにかの状態遷移を伴うケースが大抵である
だとしたら、それを具体的に示す関数を書くべきなのでは
初期化が不便だというのもなんか違う

設定するメンバの組み合わせは決めておくべきではないか
それに併せて初期化関数を用意するだけ
853 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 17:08:05.58 ID:JHQMnpCL.net]: >>820
プロパティがない言語ではゲッターセッターが
プロパティの代わりになる
854 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 17:10:16.39 ID:JHQMnpCL.net]: >>821
> セットなんちゃらって書く場面を考えると

セットなんちゃらって書くと思うからいけない。
本当に書きたいことは、属性の変更
855 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 18:13:44.49 ID:AosmVST ]: [ここ壊れてます]
856 名前：K.net mailto: いつもクラスの例にでてくるPersonクラスはNameとAgeを持ってるけどあれ適当だよな
Ageは不変じゃないからいつの時点のAgeなのかもわからん

本来は誕生日を持っておいてAgeが必要なときにいつの時点の年齢が欲しいかを引数で与えて計算すべきなんだよな []: [ここ壊れてます]
857 名前：デフォルトの名無しさん [2018/10/16(火) 18:57:36.52 ID:PnSVhV/K.net]: 言われたらそうだなｗ盲点だった
858 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:03:13.54 ID:JHQMnpCL.net]: そこででてくるのがプロパティだよ
ageは属性かメソッドかといったら属性だろ？

一見属性にアクセスしているようで、内部では
いろんな処理を行って値を返す。
それがプロパティ
859 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:04:22.70 ID:JHQMnpCL.net]: >>825
盲点でも何でも無いよｗ

例えば、Configクラスであっても、いつの時点のConfigかわからんだろ？
一年前の設定がほしいかもしれない。
860 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:12:47.50 ID:AosmVSTK.net]: >>826
引数が渡せるプロパティじゃないとね
c#使いなんだけどｃ#は引数を渡せない
861 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:22:26.29 ID:AzP++FB2.net]: 状態状態ってよく悪者にされるけど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;
}
ログの有効無効なんかをこうやって切り替えるのって
そんなに悪いこと？
862 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:24:41.24 ID:GbK/byr7.net]: Delphiなら配列の構文で引数付きプロパティを扱えたりするが
そんなことするぐらいならpersonからはbirthdayだけ見せて
今何歳かなんて呼び出し側で勝手に計算しやがれって思うわw
863 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:26:14.38 ID:OiVT6sa2.net]: 読み取りのプロパティは冪等であるべきじゃないの？
864 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:27:08.86 ID:JHQMnpCL.net]: Nameも不変じゃないし身長体重性別だって不変じゃない
商品の値段も不変じゃない
不変のものなってまず無いだろう。

つまりは、オブジェクトの状態の過去のスナップショットを
オブジェクト自身に持たせるのが正しい設計かという話
865 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:30:01.71 ID:GbK/byr7.net]: >>831
だから>>824は時刻を引数で与えるよう提案しているわけだ。最初からそういう話
personクラスが中で勝手に現在時刻を取得してたりしたら複数インスタンスのageの基準がずれたりして
使い辛くてかなわんだろう
866 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:33:44.42 ID:JHQMnpCL.net]: >>833
その理屈だと結婚などでNameが変わることもあるから
Nameにも日時を与えるようにしないといけなくなる
867 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:34:54.98 ID:AosmVSTK.net]: 話がずれてる
本質が理解されてないらしい
868 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:35:57.94 ID:JHQMnpCL.net]: 本質は>>832に書いたとおり

> つまりは、オブジェクトの状態の過去のスナップショットを
> オブジェクト自身に持たせるのが正しい設計かという話
869 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:37:46.55 ID:AosmVSTK.net]: 誕生日だけが提供されていたらコードのあちこちで年齢を出すメソッドが別々に書かれるかもしれない
同じ処理が複数で書かれてそれも同じ処理とも限らない

ロジックが散らばるのはよくないからクラスが持つべきではないかと思う
870 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:38:15.60 ID:eMqRZshQ.net]: 大小比較のアルゴリズム自体を引数で渡したり、
オブジェクト指向っぽくてエレガントに見えはするけど、
一般プログラマには可読性低いなー
と思ったり。

一昔前のオブジェクト指向設計が売
871 名前：りの会社たちは、 オナニー会社として、まるで奮わなかったもんな やっぱ適正レベルってもんが大事だよね []: [ここ壊れてます]
872 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:40:14.57 ID:GbK/byr7.net]: >>837
そこは、年齢に限らず単に時刻の差を計算する処理として
dateクラスのメソッドかグローバル関数であるべきでは
873 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:41:53.17 ID:eMqRZshQ.net]: C++はベターCとして、文字列いじるときとか楽できればいいんじゃね？

でもmallocとかメモリ管理が面倒だから、C#やJavaに流れるよね
要員確保できるもの
874 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:43:35.70 ID:AosmVSTK.net]: >>839
間違っても年齢を出す処理はdateクラスに持たせるべきではない

誕生日から年齢を出すのは実は結構めんどくさい
日本での年齢は日本の法律にのっとって決まってる
875 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:43:50.71 ID:eMqRZshQ.net]: だいたいそういうのは業務共通クラスとしてstaticメソッドてんこ盛りで置いておくよね
876 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:46:28.35 ID:JHQMnpCL.net]: つーか簡単だろ？

日付クラス。もしくは日付補助クラスに
2つの日付の差を年で返すメソッドを追加する

Personクラスには、誕生日とageプロパティをもたせ
ageプロパティは、誕生日と今日の日付の差を
さっきの年で返すメソッドを呼び出すだけにする

テストは日付クラスのメソッドはそのまま年計算のメソッドのテストを書けばいいし
Personクラスのテストは、単体テストの観点から日付クラスが
外部モジュールになるので年計算のテストは不要（すでにやってる）
年計算のメソッドを期待したとおりの引数で呼び出していることの確認と
返り値をそのまま戻しているかを確認すればいい

特定の年月日の年齢が知りたいなら、誕生日プロパティと特定の日付から
日付クラスの年計算メソッドを呼び出して差を計算するか、
適切な場所があるならそこにメソッドをおけばいい
877 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:47:01.66 ID:JHQMnpCL.net]: >>841
> 間違っても年齢を出す処理はdateクラスに持たせるべきではない

理由ぐらい書けよな
878 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:47:46.46 ID:JHQMnpCL.net]: dateクラスに持たせるべきではないというのなら
年齢計算クラスに持たせればいいだけだな
879 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:47:59.81 ID:GbK/byr7.net]: >>841
すまん、ならdateクラスは撤回する
国にも依るとなると尚更personにも持たせたくないな
単にグローバル関数にするか、いっそそれ用のクラスツリーをでっち上げて後々多態できるようにするか、かなあ
880 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:48:53.47 ID:tUmXldvA.net]: >>843
じーちゃん132歳とか出るパターンじゃね？
881 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 19:49:01.40 ID:JHQMnpCL.net]: 国によって年齢計算のアルゴリズムを変えたいというのなら
ストラテジーパターンの出番だなｗ
882 名前：デフォルトの名無しさん [2018/10/16(火) 19:54:14.32 ID:nQomBRvE.net]: みんな賢いねぇ
883 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 20:36:04.05 ID:83dvK2wh.net]: 俺やったらageプロパティやageオブジェクト作るんじゃなくて
ageクラス作ってpersonのデリゲートメソッドにageクラスオブジェクト返すものを作る。これで年齢とはそもそもなんぞや定義はの面倒な過程の話にも対応出来る
だが書く途中でゲッターですませやとキレだすと思う
884 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 20:39:51.39 ID:+sj1AQoJ.net]: 普通に考えたら person と基準日を表すオブジェクトから年齢を返す関数を作るってことになると思うんだが。
885 名前：デフォルトの名無しさん [2018/10/16(火) 20:42:25.71 ID:H029zngb.net]: >>850
定義もわからんもの作んなカスwwww
886 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 21:14:56.44 ID:83dvK2wh.net]: >>852
定義がわからんからオブジェクト指向やろう
というか俺はプロパティで済ますわ
887 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 22:05:40.03 ID:t+SGPyRj.net]: もうメンバー変数とメンバー関数が混在するクラスは作るな
関数しかないinterfaceで十分
関数が一つしかないならlambdaでいい
888 名前：デフォルトの名無しさん mailto:sage [2018/10/16(火) 22:35:26.96 ID:uJDDS3c2.net]: それ、区別する必要あるの？
889 名前：デフォルトの名無しさん [2018/10/16(火) 22:42:29.73 ID:H029zngb.net]: 正直必要かどうかはわからない
ただおまえが欲しい
だめか？それだけじゃ？
890 名前：デフォルトの名無しさん [2018/10/16(火) 22:45:36.90 ID:VMcjBADQ.net]: その低学歴知恵遅れが作ったﾒｿｯﾄﾞは
うるう年考慮してなさそうで変なﾊﾞｸﾞが入ってそうだわ

2000年10月20日生まれなら
普通にintで
(20181016-20001020)/1000
でしまいだからな
891 名前：デフォルトの名無しさん [2018/10/16(火) 22:48:30.57 ID:VMcjBADQ.net]: そもそも常識的に
特殊なｹｰｽを除いて日付の引き算で
経過年数がかえってくるという発想はないからな

経過日数はあったとしてもな
892 名前：デフォルトの名無しさん [2018/10/16(火) 22:52:46.85 ID:VMcjBADQ.net]: (20181016-20001020)/10000
こうだな
危ない。。。
893 名前：デフォルトの名無しさん [2018/10/16(火) 22:54:43.61 ID:VMcjBADQ.net]: このとおり、
やっぱりな低学歴知恵遅れが
ｵﾌﾞｼﾞｪｸﾄ指向にふれるのは危険

ｵﾚぐらいのﾚﾍﾞﾙがないとﾑﾘ
894 名前：デフォルトの名無しさん [2018/10/16(火) 23:02:22.64 ID:+0KL0EUx.net]: 俺の周りじゃあ
バカほど大喜びで使っているよ
895 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 08:20:36.48 ID:K4tsdk4L.net]: >>832
勝手に変わるか、と言う意味では、生年月日は不変だけど、年齢は変わるんでは？

>>833
なるほど。そもそもそれはプロパティとは言ってなかったんだな。
それはおっしゃるとおり、関数にすべきだと思う。
896 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 08:22:14.61 ID:K4tsdk4L.net]: >>857
年齢はその前日の満了を持って加算される、のルールで抜けるパターンがあるんじゃね？
半角さんは間抜けなの？
897 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 09:03:37.20 ID:Vm5CNq+z.net]: 半角さんを怒らせたら低学歴知恵遅れにされちゃうよ
898 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 09:56:27.08 ID:18gBK5Xa.net]: 大抵の場合、正しく理解せずに中途半端な実装してる案件にぶち当たって嫌な思いした奴がここに集うんだろ？
899 名前：デフォルトの名無しさん [2018/10/17(水) 10:09:33.91 ID:nljGc94P.net]: 実装レベルの議論してるやつと設計レベルの議論してるやつ
さらにもーちょい上から俯瞰して物を言ってるやつ
全部ごちゃ混ぜになってて面白いね
900 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 12:01:54.30 ID:vk6wOayh.net]: 自分はプログラムの観点からだけで話してる
上にあった英語の奴もプログラムが主だったなぁ
設計は知らない
話題をスレで分けた方が良いのかねぇ?
901 名前：デフォルトの名無しさん [2018/10/17(水) 12:20:31.30 ID:BZlH8+Xm.net]: 設計レベルの話とかでとらんけどw
902 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 14:05:39.44 ID:K4tsdk4L.net]: やっぱ平年の3/1に、うるう年の2/29に生まれた人の年齢が狂うな。
しかしこういう知ったかぶりが、ひどいバグを生んで改修大変になる。
と言うか、これを保存時にやられるとデータ修正ものなので、場合によっては偉いさんが頭下げに行って、出世の道が遠のくパターン。
903 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 14:07:46.09 ID:18gBK5Xa.net]: 設計って、機能ごとに必要な処理をリストアップしたら、そのまんまオブジェクト指向なんじゃね？
904 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 15:04:16.60 ID:fcCyZegY.net]: 「誕生日の前日が終了する瞬間（すなわち誕生日をむかえる午前0時00分の直前）
に1歳を加えることになる」の部分の解釈には
前日に1日加えると解釈される場合と
当日に1日加えると解釈される場合の2種類がある
905 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 15:32:27.26 ID:lTftiJN1.net]: 2/29日生まれの人は4でわらないとね
906 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:00:02.67 ID:K4tsdk4L.net]: >>871
一番問題になる学教法にならうべきじゃないんかな。
前日に歳を取る、ただし前日の24:00を使用する。表記や概念的には、って感じで。
だから、4/1生まれは4/2生まれと学年が違う。4/1生まれは、3月中に歳をとってるから。
907 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:02:31.73 ID:aR4OF1u3.net]: 誕生から１年経過することに１つ年を取るというのが定義であって
誕生日なんて全く関係ありませんよ。人間のクズども。
908 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:08:03.45 ID:DrCNXevb.net]: 学校教育法17条「保護者は、子の満六歳に達した日の翌日以後における最初の学年の初めから・・・」
909 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:09:22.06 ID:t+3zMNmx.net]: 年齢の扱いをどうするかは法律で強制されているわけじゃないので
システムによって異なってもOK

だからどういう実装でも公平な実装であれば問題ないといえる。
例えば20歳おめでとうキャンペーンで、20歳になっていなくても
その月に20歳の誕生日を迎える人を対象にしても良いわけだ

だから何が正解かを議論することに意味はない

仕事の話をするなら
年齢の計算はどうしましょうか？と客に仕様を聞くべきか
年齢の計算はこのようにしますがよろしいですか？と客に仕様の確認するべきか？
そういったことを考えたほうが良い
910 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:10:12.75 ID:t+3zMNmx.net]: ふ、無能共にマジレスしてしまったぜｗ
911 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:11:46.81 ID:4yuTjZOF.net]: 式の間違い云々よりも、皆ageはただの例示であることは前提とした上でOOPでどう表現するかの話をしてたのに
いきなり実装に踏み込んでくる思考が謎い
912 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:15:47.15 ID:DrCNXevb.net]: Personインスタンスのageのゲッターで計算しとく。
Personインスタンスが無い時にも年齢の計算が必要になったら、クラスメソッドにしてPersonのゲッター内部から使う
913 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:18:57.58 ID:t+3zMNmx.net]: プロパティが優れているのは
ageのように、

年齢？そんなものオブジェクトのフィールドにしておけばいいだろ？
え？生年月日から計算するようにしたい？
なら、そのフィールドをプロパティにして計算して返すだけだな

とクラスのインターフェースを変えることなく
実装を関数に変更できるところにある
914 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:32:11.49 ID:DrCNXevb.net]: 年齢じゃなくてBMI値の計算にしようぜ
915 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:33:10.53 ID:t+3zMNmx.net]: >>881
俺もこれ見たよ

肥満の指標・BMIは営利目的で生まれたもので医学的根拠がない？「何を信じれば」と驚愕の声や「そやろな」と納得の声など #初耳学
https://togetter.com/li/1275152
916 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 16:48:54.97 ID:DrCNXevb.net]: >>882
いやw年齢だとシンプルすぎるかなと思っただけw
917 名前：デフォルトの名無しさん [2018/10/17(水) 16:59:07.49 ID:cz0N+1z5.net]: >>882
マジかよ保険会社最低だな
バレンタイン広めた菓子会社と同じくらい最低
918 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 17:15:22.09 ID:K4tsdk4L.net]: >>876
まあ、わかってて公平な実装と、それで良いと思ってるけど漏れがある実装は、仕様と不具合と大きく異なるけどね。

>>878
ほんといつも、半角さんがでしゃばった上に間違うからこんな事になる。

でもAgeはオブジェクトのプロパティとしては俺はおかしいと思うよ。
環境によって刻々と変わったり、恣意的に変えられる値は、オブジェクトとオブジェクトの演算で出るべきだと思う。
環境オブジェクトなり、指定時刻オブジェクトなりの、時刻を表すオブジェクトと、Personを組み合わせて、初めてAgeが出るんだし。
Personを含む生年月日があるオブジェクト.ageAt(時刻オブジェクト point)で年齢オブジェクトが出るなら理解できる。
919 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 18:34:11.00 ID:K4tsdk4L.net]: 言い換えると、オブジェクトのプロパティはそのオブジェクトだけで表現可能なものに縛ったほうが良いと思う。
920 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 18:41:50.33 ID:JdG8Y6gT.net]: 誕生日はプロパティにしてもよく、年齢は日付けに依存するから関数か
921 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 18:58:38.46 ID:DrCNXevb.net]: 特定の日時の年齢が必要になったら
getAgeからgetAgeAt呼べばいいだけやん
言語によっていろいろやり方あるけどね
getAgeAt(Date.Today)しか書かれてないプログラムとかマヌケじゃん

既存クラスにメソッド追加できる言語なら
最終的にはDateにyears_between何ちゃら書く事になりそうだが
922 名前：デフォルトの名無しさん [2018/10/17(水) 19:05:52.01 ID:MwWLHD/k.net]: それで�
923 名前：ｾったらPersonオブジェクトがどういう扱いなのかによってもAgeがプロパティか関数か違いそうだな。 データベース的な一回表示するだけだったら関数でも良いけど、ゲームやSNSのアバター的なのだったら、ステータス表示するたびに計算してたら無駄が多い。 誕生日イベントでもない限り1日くらいは1歳違う程度は許容されるなら、オブジェクト作成時(ログイン時)に計算して結果をAgeに入れるだけとか、誕生日イベント発生時に計算して入れるだけとかした方がよくないか？ モバイルゲームとかなら尚更。 []: [ここ壊れてます]
924 名前：デフォルトの名無しさん [2018/10/17(水) 19:07:22.09 ID:pcmrmHBT.net]: お前らQiitaでも喧嘩してんのかよｗｗｗｗｗ
925 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 19:21:58.46 ID:QBZICbug.net]: くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
それが答えだ
926 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 19:41:36.97 ID:lTftiJN1.net]: バッチが日付またぐけど開始した日で計算したいとなると「当日」をそういう扱いにするようにプログラム書くんだろうがインターフェースを変更する必要は無さそうだな
927 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 19:45:33.46 ID:e5Vejsh/.net]: プログラミング系の文章は長いのが多いｗ
Qiitaも無駄に長いし
928 名前：デフォルトの名無しさん [2018/10/17(水) 19:48:24.97 ID:MwWLHD/k.net]: そらそうよ。
一体何に細かく指示してると思ってんの。
それに比べれば全然短いわ。
929 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 19:49:12.51 ID:PbHb58aB.net]: 保守性、生産性なんてどーでもいいみたいだなw
930 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 20:48:03.60 ID:SmhZ3W9+.net]: 保守性がどーでもいいならスマートUI + 振る舞いレスオブジェクト + トランザクションスクリプト + スパゲティクエリで短期的な生産性を上げることができる
保守性と生産性を同時に上げる方法は残念ながらオブジェクト指向しか知らない
931 名前：デフォルトの名無しさん [2018/10/17(水) 21:11:18.05 ID:MCL000/y.net]: >>893
いわゆる職業病だな
932 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 21:15:15.43 ID:t+3zMNmx.net]: 言語の解説本でもムダに長いからな
ポケットリファレンス程度でいいのに
933 名前：デフォルトの名無しさん [2018/10/17(水) 21:29:59.95 ID:MCL000/y.net]: livedoor.4.blogimg.jp/hatima/imgs/c/d/cdb5756f.gif
934 名前：デフォルトの名無しさん [2018/10/17(水) 22:12:39.18 ID:Ny9Q/0jK.net]: 低学歴知恵遅れは日付ｸﾗｽにそんな頭悪いｺｰﾄﾞを入れると書いてるからな
>>843 ←　このとおり
935 名前：デフォルトの名無しさん [2018/10/17(水) 22:16:19.44 ID:Ny9Q/0jK.net]: 普通に考えてな
日付ｸﾗｽにそんな頭悪いｺｰﾄﾞなんかいれない

低学歴知恵遅れはいろんなもんに利用する日付ｸﾗｽに
年齢求めるｺｰﾄﾞをいれると書いてる

低学歴知恵遅れがｸﾗｽを設計（）すると
こういうﾊﾞｶな作りになるという典型的な例といっていい

この板にいるような低学歴知恵遅れにはやっぱりな
ｵﾌﾞｼﾞｪｸﾄ指向なんかﾑﾘ
936 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 22:18:11.61 ID:vodxAkHQ.net]: >>891
契約時年齢だって
937 名前：デフォルトの名無しさん [2018/10/17(水) 22:21:21.35 ID:Ny9Q/0jK.net]: ただの起算日の違いの問題だからな
計算方法はかわらない

そもそも日付ｸﾗｽ（）なんかやるようなもんじゃない
938 名前：デフォルトの名無しさん [2018/10/17(水) 22:26:45.89 ID:Ny9Q/0jK.net]: ともかくあきれるぐらい頭が悪い
939 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 22:29:57.57 ID:t+3zMNmx.net]: >>901
日付クラスに入れるのは、年の差を計算するロジックやで？
日付同士の差を求める演算。結果の年だけを取得する

誰が年齢の差のはなししてるんだよｗ
940 名前：デフォルトの名無しさん [2018/10/17(水) 22:30:36.34 ID:MwWLHD/k.net]: 確かになー。。。
と言うか、大抵のフレームワークに日付クラスがあるのに、わざわざ改造して年齢計算メソッド付けるって発想が浮かばない。
普通はPersonに付けるだろうし、スマホゲームとかならクライアントに計算させてバッテリー減り過ぎも困るから、場合によっては鯖側に管理クラス作ってそっちに付ける。
941 名前：デフォルトの名無しさん [2018/10/17(水) 22:30:39.23 ID:Ny9Q/0jK.net]: ﾎﾝﾄ頭悪いわ
942 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 22:35:00.27 ID:SmhZ3W9+.net]: アタマが悪いと短いレスすら誤解して読んでしまうらしい
ほんとかな？
943 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 22:35:22.24 ID:t+3zMNmx.net]: >>906
日付クラスに入れるのは
944 名前：日付の計算（もちろんすでに入ってるのならそれを使う） 年齢はPersonクラス、仕様が一致してるなら日付クラスのメソッドを呼ぶだけでいい 日付の計算と年齢の計算は（仮にロジックが一致していたとしても）別物 そういうことを考えるのが抽象化 []: [ここ壊れてます]
945 名前：デフォルトの名無しさん [2018/10/17(水) 22:54:19.67 ID:MwWLHD/k.net]: >>909
入ってるのは今の所見たことないけど、メソッドにする程か？
日付クラス同士の足し算引き算出来るはずで、年数計算って結局ただの引き算やぞ。

別に駄目とは言わんが、Ageメソッド内で「今日の日付－生年月日」するのと、「日付クラス.年数計算(今日の日付,生年月日)」するのと手間は同じ。
むしろ長くなる。
946 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:03:02.79 ID:4yuTjZOF.net]: operator - が日付クラス内で定義されてる例なんていっぱいあるでしょ
947 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:05:08.82 ID:t+3zMNmx.net]: >>910
Personクラスの属性にしていれば、
内部の実装が変わってもインターフェースを
変えなくてすむんだよ。

それにオブジェクト指向の特徴だが人間のメンタルモデルに近いから
理解しやすい。例えば「あなたの年齢は？」みたいに聞くだろう？
年齢を知りたいときに、あなたの生年月日は？って聞いてからわざわざ計算しないだろ？

"あなた"が知っていることは、"あなた"に問い合わせればよい。
というのが人間にとって一番理解しやすいんだよ
948 名前：デフォルトの名無しさん [2018/10/17(水) 23:05:26.01 ID:Ny9Q/0jK.net]: 日付ｸﾗｽの - ｵﾍﾟﾚｰﾀｰで
経過日数ではなく経過年数を返す作りになるのか。。。

さすが低学歴知恵遅れがいうことは斬新だわ
949 名前：デフォルトの名無しさん [2018/10/17(水) 23:07:02.95 ID:Ny9Q/0jK.net]: やっぱり低学歴知恵遅れって感じ
もうすぐに分かってしまう

まともな教育を受けてればでてここないような発想が
ﾎﾟﾝﾎﾟﾝでてくる

低学歴知恵遅れのﾚｽってすぐにわかる
いちいち低学歴知恵遅れですと自白するからな。。。
950 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:09:12.35 ID:t+3zMNmx.net]: 弱い犬ほど？
951 名前：デフォルトの名無しさん [2018/10/17(水) 23:09:52.03 ID:Ny9Q/0jK.net]: ﾊﾞｶはﾊﾞｶであることに気づけない
ﾎﾝﾄになよくわかるわ
952 名前：デフォルトの名無しさん [2018/10/17(水) 23:17:38.65 ID:pcmrmHBT.net]: 関数型論者だったら「人」はDNAだけで表し、生まれた日、場所、その他その瞬間の宇宙の諸環境をすべて引数で与えて最後に経過時間も与えるのかな？
なんだ、関数型論者って決定論者だったんだな。
953 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:30:29.90 ID:4yuTjZOF.net]: >>910が日付の計算が日付クラスのメンバーになっているのを見たことがないと言っているので
それに対して俺は>>911で知らないうちに演算子オーバーロードの恩恵を受けているのではと言っているだけ

「今日の日付－生年月日」は日数で「日付クラス.年数計算」の「年数」とは一致しないが
そんな事は気にせずに単にdateの計算をどこに置くかの話をしているだけ
繰り返すが日付自体がただの例示だから、単位だの閏年だの細部を詰めることに意味はないと皆わかってる

そこから一人実装を始めたり短絡的にoperator -で年数を返すと変な結びつけ方をしたりして
自分が作り上げた架空の敵相手に憤ってしまうのがもうね
954 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:33:06.41 ID:LhMTIXwM.net]: >>917
それは関数型論者でなくて適切な抽象度が理解できないただの抽象馬鹿だろ。
955 名前：デフォルトの名無しさん [2018/10/17(水) 23:48:24.78 ID:MwWLHD/k.net]: >>913
あれ？日付クラス(Date)の中にYaer、Man、Dayって年クラス、月クラス、日クラスって無かったっけ？
すまんね。
だいぶ離れてて、うろ覚え。

>>912
うん？
だからPersonクラスがAgeプロパティだかメソッド持つんだろ？
日付クラスだか時間クラスだかが年数計算メソッド持つ必要は無い。
時間はただ時間、日付はただ日付。
年齢もただ年齢ってのもある意味じゃ正しい。
システム上不都合なら管理クラスに計算させて、結果を受け取るだけでも良い。

オブジェクト指向は、必ずしも現実と同じ区分けでなくて良い。
責任分担をキッチリするための道具でしかない。
保守性に問題なければ、システムの特性に合わせてどちらが管理するのか決めれば良い。
(むしろ現実と離れることが多いから、あんまり現実だとこうだから～とか、こだわり過ぎない方がいい)
956 名前：デフォルトの名無しさん mailto:sage [2018/10/17(水) 23:55:39.80 ID:RzUo3BE1.net]: 生年月日は、属性・インスタンス変数

年齢は、computed・算出プロパティ
957 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 00:04:29.24 ID:/P5hGycw.net]: Ruby で、年齢をクラス化したもの

誕生日から年齢を計算するhappybirthday gemをリリースしました
https://takanamito.hateblo.jp/entry/2018/05/15/091820
958 名前：デフォルトの名無しさん [2018/10/18(木) 00:08:50.77 ID:8YBQxCvu.net]: るびぃ～すとｗｗｗｗｗ
959 名前：デフォルトの名無しさん [2018/10/18(木) 00:19:48.94 ID:qf9NxgCD.net]: >>918
年齢計算や年数計算は大事な場所じゃ無かったし、言う通り日付クラスに年数計算メソッド付けるべき？が話題の中心だったと思う。

年齢計算や年数計算は
_______日付クラスA = 今日の日付－生年月日(または任意の年月日)
return 日付クラスA.Yaer

とかだった気がする。
うろ覚えだが。
960 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 00:25:14.97 ID:855u7n6N.net]: 難しい物なんだから
話が長くなるのは当たり前
既に知っている事を話す以外だと
相手に解る様に話すのに分量が掛かる
当然だろう
961 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 00:35:20.72 ID:/ofNkRJS.net]: >>924
日付（年の差）計算と年齢計算をごっちゃにしてはいけない
日付クラスにつけるのは年の差計算処理
年齢の計算のことは考えてはいけない

Personクラスにつけるのは年齢プロパティ
中で日付クラスを使うかどうかは実装による

年齢計算の方法が複数あるというのなら、ストラテジーパターンを導入し
アルゴリズムを切り替えられるようにしておけばいいだろう
>>843で書いたことの繰り返しだがな
962 名前：デフォルトの名無しさん [2018/10/18(木) 00:36:08.12 ID:THsg9J3q.net]: いや低学歴知恵遅れは
頭ﾜﾙｲという病気

不治のﾔﾏｲ
963 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 00:38:55.28 ID:/ofNkRJS.net]: またワンワンって聞こえる
964 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 00:40:38.70 ID:d31P7rqb.net]: >>927
あなたのその病治らなくて大変ですね
965 名前：デフォルトの名無しさん [2018/10/18(木) 00:56:35.59 ID:qf9NxgCD.net]: >>921
これ言うと元も子もないが、実際にはアカウント作る際に生年月日と年齢を別々に書かされる通り、計算なんて何処もしちゃいない。
気が付いたらユーザーが書き直してねって。

お勉強でもなけりゃ年齢計算はしない。
年計算用途の方が実践で使われてるかもね。
966 名前：デフォルトの名無しさん [2018/10/18(木) 01:06:50.02 ID:qf9NxgCD.net]: >>926
うーん？
誕生日を生年月日にしただけで、同じ意見に見えるが。。。
閏年に誕生日が～とかも含めるって事？
だから、実際のサイトじゃ年齢も入力させる形なのかね？
967 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 06:47:29.90 ID:8rVApEa4.net]: 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) { ...
968 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 08:12:51.70 ID:0Dh4HQ87.net]: >>912
その質問は暗黙に(今の)が入ってるんじゃない？
969 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 08:15:28.19 ID:0Dh4HQ87.net]: 半角さんは設計スキルないんだからもう書き込むなよ。
実際間違った実装を想定して設計の話ししただろ？
970 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 08:19:16.70 ID:0Dh4HQ87.net]: >>930
電子カルテだとまあまず患者マスタに年齢は持たないよ。
いつ時点に、何歳か、って方が大事だから。
どのタイミングで年齢計算するかとなると、入院中に歳を取るパターンがあるので結局毎日計算するハメになる。

それこそ業務によると思うが。
ただ普通のウェブサイトでも、生年月日聞くところで年齢を聞かれる事はあんまり無いんじゃないかな。
971 名前：デフォルトの名無しさん [2018/10/18(木) 08:45:54.88 ID:qf9NxgCD.net]: >>935
なるほど、カルテだったら閏年で何歳ってより、生物として生まれて何年目、的な意味合いの方が重要だし、有りかも。

年齢まで求める場所減ってるか知らないけど、情報的な価値は低いかもね。
統計的に扱うだろうから、生年月日で何年生まれか分かれば十分だし。
972 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 11:41:18.85 ID:ia232fMX.net]: 手術した日から何年経ったか表示してと言われて裏で誕生日クラスが使われる
973 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 12:26:47.14 ID:PmW8gRMT.net]: >>891
＞くだらねー議論してないで業務エキスパートに年齢の扱いを聞いてこい
＞それが答えだ

これで解決する議論をぐだぐだとまあ…
何がしたいんだ？
年齢にまつわる宇宙の真理をクラス化したいのか？
974 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 12:45:03.88 ID:0Dh4HQ87.net]: >>936
何歳って概念も結構大事で、6歳未満にはできない、とか、6歳未満だからいくら、とか結構決まり事があるんよ。
それ守らないと保険組合からお金がもらえない。
暦の上の、いわゆる法律上の年齢も無視できないんよ。
それは、医師の指示を実施した日で計算するとか、日付の取り方も色々ある。

医学的に必要になってくるとすると、何ヶ月早産児の何ヶ月児が、正規産だと何ヶ月児だよ、とか。
こっちは、だいたい週計算する。
975 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 12:45:24.34 ID:b1Fs59oz.net]: 日付クラスを継承して誕生日クラスとか作り出す奴がいるから無駄に複雑になる。
976 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 13:23:27.88 ID:b1Fs59oz.net]: 無駄にクラス化しようとする奴も同罪。だからオブジェクト指向がクソと言われる。
977 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 14:01:33.21 ID:bqWuTIEf.net]: だから業務共通クラスの１メソッドにしとくんだろ、普通

バッチが日跨ぎしても基準日は変えないとか、業務やシステムの要素と切り離しできるなら話も変わるけど
978 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 14:13:24.19 ID:A+ZA0oir.net]: クラスもいいけど、共通処理は単なる関数ライブラリの方がありがたいよな。
979 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 14:59:01.57 ID:6luTq9qj.net]: >>940
継承は間違い
日付型のフィールドを持つだけの誕生日値オブジェクトクラスを作るのが正解だな
980 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 15:25:24.79 ID:3douRw4T.net]: Person.birthday.dateなの？
981 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 16:59:23.38 ID:A+ZA0oir.net]: ２つの日付けを引数にしてその日数を返す関数あれば、それだけでよくね？
変にクラス内に閉じ込めてもメリット無いと思うんだけど？
少なくともpersonクラスには誕生日を返すくちがあればそれでいいと思うよ。
それをどう加工するかは、表示クラスだったり年金計算クラスだったりでやればいいんだよ。
982 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 17:52:04.62 ID:/ofNkRJS.net]: >>946
コンピュータの立場で考えるのではなく
人間の立場になって考えるようにしましょう

Personクラスはどういう属性を持っているか？
それを考えるのが設計。実装のことは一旦忘れましょう
983 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 17:55:05.67 ID:80M+etW5.net]: 関数型や手続きだとこんな議論にならん辺りやっぱオブジェクト指向はアカンな
984 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:03:23.12 ID:b1Fs59oz.net]: 誕生日から年齢導くだけの処理に、幾つのファイルとどの位のコストが必要なのかねぇ。
保守性とはホント真逆だわ。
985 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:12:21 ]: [ここ壊れてます]
986 名前：.82 ID:vIc/Em84.net mailto: >>949
年齢を整数のまま扱うといつか誰かが
Xピクセル=10歳+50kg
みたいな奇妙な演算をやらかす
それは困るからクラス化して保守性をあげよう []: [ここ壊れてます]
987 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:17:11.53 ID:b1Fs59oz.net]: それよりも複雑化によるデメリットの方が計り知れない。
そもそもコード量を減らすためにクラス化とかあるのに逆に増えるってどんな呪いだよ。
988 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:20:48.86 ID:vIc/Em84.net]: >>951
重複コードがほぼ一掃されるので全体のコード量は減る
利用者側は年齢にまつわる詳細なルールを知らなくても使えるようになるから複雑性も解消される
989 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:29:38.57 ID:3douRw4T.net]: 棒グラフにするの大変やな
990 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:32:26.45 ID:3douRw4T.net]: 平均年齢もきつい
991 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:34:20.75 ID:7CPcoAfm.net]: 設計がおかしいとおかしなクラスが乱造される

一クラス一機能をつら抜いてFileRemoverとかFileRenamerクラス作ってる人は死んだほうがいい
MultiFileRemoverとか本当に必要なら作れよと思う
992 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:37:53.29 ID:b1Fs59oz.net]: >>952
だから呪い。実際、出来上がってるものの大半は真逆の事になってるんじゃないかね。
993 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:42:34.52 ID:80M+etW5.net]: オブジェクト指向は書く量と段取りを増やすデメリットをもって
パーツや責任関係の切り分けを行う作業と理解しております
994 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 18:45:45.21 ID:b1Fs59oz.net]: それならわかる。
995 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 19:06:46.96 ID:vIc/Em84.net]: 日付型とかあるじゃん
あれ中身はただの整数値だけどだからってじゃあ整数値のままでいいじゃんとはならない
なぜなら整数値を日付とみなして注意深く扱うよりも
さっさと日付型を作ってしまったほうが間違いが減って問い合わせや演算が楽になり理解しやすくなるから
同じことをドメインでもやりましょうというだけの話なんだけど何をそんなに恐れてるのだろう
996 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 19:25:21.20 ID:7CPcoAfm.net]: 架空言語にて

private Name name=new Name()

public Person(string name){
Name tmpName=new Name(name);
if(tmpName != null){
this.name=tmpName;
}
}
997 名前：デフォルトの名無しさん [2018/10/18(木) 19:26:39.70 ID:qf9NxgCD.net]: >>947
そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。
ある程度はどっちに比重置くか考えて作った方がいい。
そういう所こそ設計の腕の見せ所。
998 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 19:30:01.60 ID:/ofNkRJS.net]: > そう言うのがいるからうちの会社は社用スマホが古いんだから、もっとアプリ軽くしろとか注文入って鯖に処理を移す事になるんだよ。。。

全く無関係の話をされても困るんだが？
999 名前：デフォルトの名無しさん [2018/10/18(木) 19:39:03.88 ID:qf9NxgCD.net]: 理想と現実は違うって事。
人間のこと考えたいけど、仕様変更繰り返すうちにグダグダになる。
出来る事は破綻しない様に事前に想定される事に対処して、その後も破綻しない様に管理することだけ。
1000 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 19:50:43.92 ID:KBtBXMK/.net]: >>963
だからオブジェクト指向が必要なんだよね
1001 名前：デフォルトの名無しさん [2018/10/18(木) 19:54:07.63 ID:qf9NxgCD.net]: >>964
そう。
そのはずだ。
入門書でAnimalクラスを継承してDogクラスとCatクラスが～とか例えた弊害か、人間の事をとかなる。
人間の事を考えるなら顧客の事だ。
1002 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 19:54:59.16 ID:/ofNkRJS.net]: 従業員かもしれんし、何を言ってんだお前は？
1003 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 20:37:26.00 ID:4AdjqlvR.net]: >>938
エキスパートと思われる人にヒアリングしたら
そいつが「年齢にまつわる宇宙の真理」とか求め出すというクソ案件はたくさんある。
1004 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:17:00.48 ID:A+ZA0oir.net]: >>947
だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。
やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。
それじゃ無いと、様々な業務に適用させる度に微妙に違う属性を返さなきゃならんくなるだろ？
1005 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:24:05.33 ID:/ofNkRJS.net]: > だからさ、業務によって年齢の扱いが違うんだから、固有の業務に特化した属性なんて実装は避けるべきなんだよ。

Personクラスはそもそも業務に特化したクラスだろう？

現実世界の人間を完全シミュレートする。それがオブジェクト指向だって
考えてるのはお前だけやで
1006 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:25:37.05 ID:A+ZA0oir.net]: >>969
いや、そもそもオブジェクト指向はパーツの使い回しがテーマだからな。
1007 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:26:42.98 ID:/ofNkRJS.net]: パーツの使い回しはオブジェクト指向じゃなくてもできるんで
それは全然違いますー
1008 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:28:20.39 ID:/ofNkRJS.net]: いやはや驚きだ。これが馬鹿というものか

まさか、どんな業務にでも通用する
Personクラスを想定していたとは

世界にたった一つPersonクラスがあれば
ゲームから業務まで何でも使えるものを想定していたとはな

愚かとしか言いようがない
1009 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:32:01.02 ID:A+ZA0oir.net]: 少なくとも会社や自分の作るアプリで使い回す為にオブジェクト指向で作るんだからな。
おまえみたいに毎回特定業務に特化してフルスクラッチから作るとかバカしかやらんぞ。
1010 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:33:57.36 ID:/ofNkRJS.net]: >>973

え？お前こういったじゃん

> やりたいならpersonクラスじゃなくて業務クラスに持たせるべき。

お前は、使い回すために業務クラス作ってんのか？
どんな業務でも汎用的に使えるもの = 業務クラスだったのか？
1011 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:35:16.82 ID:/ofNkRJS.net]: 使い回さ（せ）ないもの = 業務クラス
Personクラスは使い回せない = 業務クラス

俺はこう言ってるだけなんだが、
こいつは何を言ってるんだろうか？
1012 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:37:02.39 ID:A+ZA0oir.net]: アホに構ってしまった。
personなんて一般的な名前で個別に特化したクラスを作るあほは社会の迷惑だからしんでくれ。
1013 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:38:08.80 ID:/ofNkRJS.net]: >>976
キミはネームスペースというものを知ったほうが良いぞ
多くの言語ではクラスはネームスペースの中に入れるから
一般的な名前が使えるんだよ
1014 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 21:43:24.79 ID:A+ZA0oir.net]: それじゃ解決できねーんだよw
1015 名前：デフォルトの名無しさん [2018/10/18(木) 21:59:23.07 ID:d31P7rqb.net]: マクロ使ってスコープ無視してるんじゃね
1016 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 22:04:29.72 ID:A+ZA0oir.net]: つうか、使いまわせないから却下。
1017 名前：デフォルトの名無しさん [2018/10/18(木) 22:20:46.14 ID:d31P7rqb.net]: 名前空間内に入っていてその業務に特化したpersonという標準クラスはok派。
それを継承して使いまわしてもいいじゃない。
1018 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 22:53:19.65 ID:2FmMLZik.net]: 名前空間のせいで型名が長い
その反動で関数名は短すぎるから型を省略したら情報が少なすぎて読めない

型を宣言する言語としない言語の対立が最も激しくなる仕組み
1019 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:03:48.89 ID:vIc/Em84.net]: personに関わる宇宙の真理を考えてる奴がマジでいてクソワロタwww
1020 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:17:56.72 ID:sfuI0a7S.net]: オブジェクト指向で作った時点で失敗

メンバ変数の状態の数だけパターンが増えていく
これを仕様で固定せず
オブジェクトの状態数×オブジェクトの状態数
の工数爆発を汎用性による品質の向上とか思ってるキチガイばっかで救いようがない

無限の汎用性とは無限のバグ数を持っていることを悟るべき
1021 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:19:33.39 ID:/ofNkRJS.net]: > オブジェクト指向で作った時点で失敗

いきなり結論ありきｗ
1022 名前：デフォルトの名無しさん [2018/10/18(木) 23:19:44.24 ID:THsg9J3q.net]: 人類ｸﾗｽからﾎﾓｸﾗｽを導出するぐらい頭ﾜﾙｲことを平気でするからな
1023 名前：デフォルトの名無しさん [2018/10/18(木) 23:22:42.95 ID:Buojxy+7.net]: オブジェクト指向は愚かな考え。排便メソッドを実装した人間クラスから美少女クラスが作れない
1024 名前：デフォルトの名無しさん [2018/10/18(木) 23:25:00.93 ID:qf9NxgCD.net]: >>973-974
あー。。。
オブジェクト指向は素晴らしいかもしれん。
だがな。
納期に追われた焦った脳で扱うには手が余る。
精々次の一回使い回せたら使えたってのが現実。
(と言うか、そんなんだから継承は悪とか言われるわけで)

上で誰かがライブラリ的な方が嬉しいとか書いてたろ？
あれが真実。(誓って書いたのは俺じゃあない)
流石にまんま関数をライブラリにしなくて、関数とクラスをまとめたライブラリにするが。(むしろ気持ち悪いかこれは)

だから言ったろ？
現実と理想は違うって。

理想を追い求めて納期間に合わなくて、クビになったら元も子もないやろ？
いつかは。。。とか思いつつ、その連続よ。
1025 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:26:14.41 ID:/ofNkRJS.net]: >>988
お前の現実の話なんか
他人には関係ない
1026 名前：デフォルトの名無しさん [2018/10/18(木) 23:28:09.99 ID:qf9NxgCD.net]: そう思うんなら、まだ現実を知らない。
1027 名前：デフォルトの名無しさん [2018/10/18(木) 23:28:24.82 ID:THsg9J3q.net]: 一番頭ﾜﾙｲやつが大量にﾚｽしてるわ。。。
まさに典型的な頭の悪さ
1028 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:28:41.89 ID:/ofNkRJS.net]: お前の現実なんか知らんわｗ
1029 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:33:25.51 ID:/ofNkRJS.net]: >>988
Personのような業務クラスは使いまわしできるわけがないのは常識で
どうせ作る力ないんだから作るな。使え。
オープンソースなんかの汎用クラスを使え
見事にオブジェクト指向で世界中使い回し出来てるんだから。
1030 名前：デフォルトの名無しさん [2018/10/18(木) 23:35:05.22 ID:THsg9J3q.net]: 業務でどこの馬の作ったか分からんような
ちゃんと試験されたかどうかすらわからんようなｺｰﾄﾞを使うとかな
ｺｲﾂは間違いなくﾆｰﾄ
1031 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:43:20.55 ID:/ofNkRJS.net]: ちゃんと試験すればいいだけじゃね？

どうせ自分で作っても試験するんだから
他人が作ったものを試験するほうが
作るコストが節約できる

第一そもそも作る能力がないレベルなんだから
他人のが使えませんと言っても
自分で作ることもできませんっていうのが落ちだろう
1032 名前：デフォルトの名無しさん [2018/10/18(木) 23:45:03.61 ID:THsg9J3q.net]: ｸｿﾆｰﾄの世界では手続きとういもんがないのは分かる
1033 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:46:15.45 ID:/ofNkRJS.net]: ダメな奴は
できる方法を考えるのではなく
できない理由を考える
1034 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:46:31.81 ID:/ofNkRJS.net]: はい、さっき次スレ立てましたよー

オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/
1035 名前：デフォルトの名無しさん [2018/10/18(木) 23:46:57.71 ID:THsg9J3q.net]: ｵﾏｴはこのｽﾚで頭わるいことばっかり書きこむまえに
ﾊﾛﾜへいく必要がある
1036 名前：デフォルトの名無しさん mailto:sage [2018/10/18(木) 23:47:17.33 ID:vIc/Em84.net]: >>984
状態をクラスにカプセル化することによって独立性を保てる境界ができる
すると状態の組み合わせ数が激減するんだよ
1037 名前：1001 [Over 1000 Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 55日 10時間 15分 8秒
1038 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef