18/08/24 13:32:09.36 ifygL6bT.net
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
URLﾘﾝｸ(monobook.org)
2:デフォルトの名無しさん
18/08/24 13:35:00.08 vJMsvnBL.net
なにをいまさら
3:デフォルトの名無しさん
18/08/24 13:35:14.51 ZAZ1bDZG.net
よくある
4:デフォルトの名無しさん
18/08/24 13:44:30.12 dWZiPnfz.net
アホだな
5:デフォルトの名無しさん
18/08/24 13:44:39.27 GnRKIAsQ.net
マジかよ
6:♨デフォルトの名無しさん
18/08/24 13:48:32.20 JNQXY3hm.net
>>696-701
ハロワ！
7:♨デフォルトの名無しさん
18/08/24 13:48:49.10 JNQXY3hm.net
>>188-193
ハロワ！
8:♨デフォルトの名無しさん
18/08/24 13:48:49.93 JNQXY3hm.net
>>188-193
ハロワ！
9:♨デフォルトの名無しさん
18/08/24 13:49:06.65 JNQXY3hm.net
>>936-941
ハロワ！
10:♨デフォルトの名無しさん
18/08/24 13:49:07.52 JNQXY3hm.net
>>936-941
ハロワ！
11:♨デフォルトの名無しさん
18/08/24 13:49:24.49 JNQXY3hm.net
>>475-480
ハロワ！
12:♨デフォルトの名無しさん
18/08/24 13:49:25.25 JNQXY3hm.net
>>475-480
ハロワ！
13:♨デフォルトの名無しさん
18/08/24 13:49:42.00 JNQXY3hm.net
>>504-509
ハロワ！
14:♨デフォルトの名無しさん
18/08/24 13:49:42.66 JNQXY3hm.net
>>504-509
ハロワ！
15:♨デフォルトの名無しさん
18/08/24 13:49:59.43 JNQXY3hm.net
>>10-15
ハロワ！
16:♨デフォルトの名無しさん
18/08/24 13:50:00.16 JNQXY3hm.net
>>10-15
ハロワ！
17:♨デフォルトの名無しさん
18/08/24 13:50:17.05 JNQXY3hm.net
>>846-851
ハロワ！
18:♨デフォルトの名無しさん
18/08/24 13:50:17.68 JNQXY3hm.net
>>846-851
ハロワ！
19:♨デフォルトの名無しさん
18/08/24 13:50:34.99 JNQXY3hm.net
>>794-799
ハロワ！
20:♨デフォルトの名無しさん
18/08/24 13:50:35.59 JNQXY3hm.net
>>794-799
ハロワ！
21:♨デフォルトの名無しさん
18/08/24 13:50:52.74 JNQXY3hm.net
>>594-599
ハロワ！
22:♨デフォルトの名無しさん
18/08/24 13:50:53.52 JNQXY3hm.net
>>594-599
ハロワ！
23:♨デフォルトの名無しさん
18/08/24 13:51:10.36 JNQXY3hm.net
>>74-79
ハロワ！
24:♨デフォルトの名無しさん
18/08/24 13:51:10.98 JNQXY3hm.net
>>74-79
ハロワ！
25:♨デフォルトの名無しさん
18/08/24 13:51:27.73 JNQXY3hm.net
>>865-870
ハロワ！
26:♨デフォルトの名無しさん
18/08/24 13:51:28.57 JNQXY3hm.net
>>865-870
ハロワ！
27:♨デフォルトの名無しさん
18/08/24 13:51:46.63 JNQXY3hm.net
>>193-198
ハロワ！
28:♨デフォルトの名無しさん
18/08/24 13:51:47.62 JNQXY3hm.net
>>193-198
ハロワ！
29:♨デフォルトの名無しさん
18/08/24 13:52:04.41 JNQXY3hm.net
>>639-644
ハロワ！
30:♨デフォルトの名無しさん
18/08/24 13:52:05.28 JNQXY3hm.net
>>639-644
ハロワ！
31:♨デフォルトの名無しさん
18/08/24 13:52:22.20 JNQXY3hm.net
>>743-748
ハロワ！
32:♨デフォルトの名無しさん
18/08/24 13:52:22.85 JNQXY3hm.net
>>743-748
ハロワ！
33:♨デフォルトの名無しさん
18/08/24 13:52:39.73 JNQXY3hm.net
>>2-7
ハロワ！
34:♨デフォルトの名無しさん
18/08/24 13:52:40.36 JNQXY3hm.net
>>2-7
ハロワ！
35:♨デフォルトの名無しさん
18/08/24 13:52:57.00 JNQXY3hm.net
>>300-305
ハロワ！
36:♨デフォルトの名無しさん
18/08/24 13:52:57.69 JNQXY3hm.net
>>300-305
ハロワ！
37:♨デフォルトの名無しさん
18/08/24 13:53:14.69 JNQXY3hm.net
>>423-428
ハロワ！
38:♨デフォルトの名無しさん
18/08/24 13:53:15.30 JNQXY3hm.net
>>423-428
ハロワ！
39:♨デフォルトの名無しさん
18/08/24 13:53:32.47 JNQXY3hm.net
>>227-232
ハロワ！
40:♨デフォルトの名無しさん
18/08/24 13:53:33.30 JNQXY3hm.net
>>227-232
ハロワ！
41:♨デフォルトの名無しさん
18/08/24 13:53:50.36 JNQXY3hm.net
>>150-155
ハロワ！
42:♨デフォルトの名無しさん
18/08/24 13:53:51.27 JNQXY3hm.net
>>150-155
ハロワ！
43:♨デフォルトの名無しさん
18/08/24 13:54:07.98 JNQXY3hm.net
>>715-720
ハロワ！
44:♨デフォルトの名無しさん
18/08/24 13:54:08.57 JNQXY3hm.net
>>715-720
ハロワ！
45:♨デフォルトの名無しさん
18/08/24 13:54:25.45 JNQXY3hm.net
>>57-62
ハロワ！
46:♨デフォルトの名無しさん
18/08/24 13:54:26.08 JNQXY3hm.net
>>57-62
ハロワ！
47:♨デフォルトの名無しさん
18/08/24 13:54:42.76 JNQXY3hm.net
>>856-861
ハロワ！
48:♨デフォルトの名無しさん
18/08/24 13:54:43.68 JNQXY3hm.net
>>856-861
ハロワ！
49:♨デフォルトの名無しさん
18/08/24 13:55:00.44 JNQXY3hm.net
>>595-600
ハロワ！
50:♨デフォルトの名無しさん
18/08/24 13:55:01.09 JNQXY3hm.net
>>595-600
ハロワ！
51:♨デフォルトの名無しさん
18/08/24 13:55:17.72 JNQXY3hm.net
>>314-319
ハロワ！
52:♨デフォルトの名無しさん
18/08/24 13:55:18.39 JNQXY3hm.net
>>314-319
ハロワ！
53:♨デフォルトの名無しさん
18/08/24 13:55:36.07 JNQXY3hm.net
>>632-637
ハロワ！
54:♨デフォルトの名無しさん
18/08/24 13:55:36.71 JNQXY3hm.net
>>632-637
ハロワ！
55:デフォルトの名無しさん
18/08/24 14:27:45.99 0hzqlpOd.net
>>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな
56:デフォルトの名無しさん
18/08/25 00:54:02.71 6mB8j9/9.net
オブジェクト指向は、ウンコのようにニガい
57:デフォルトの名無しさん
18/08/25 13:13:07.84 00w/RGH3.net
砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない
58:デフォルトの名無しさん
18/08/25 13:25:46.59 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:デフォルトの名無しさん
18/08/25 13:27:10.91 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:デフォルトの名無しさん
18/08/27 19:47:07.71 y3uHC3Z/.net
クソはオブジェクトやぞ
61:デフォルトの名無しさん
18/08/31 19:34:28.84 lHXkvQer.net
文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。
62:デフォルトの名無しさん
18/09/05 05:14:03.10 UEpkpswy.net
>>1
オブジェクト指向で組めない君らがクソ
63:デフォルトの名無しさん
18/09/05 05:21
64::15.30 ID:w7O3HrXU.net
65:デフォルトの名無しさん
18/09/05 09:21:08.12 BLSFUWnl.net
カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな
66:デフォルトの名無しさん
18/09/05 09:22:22.65 BLSFUWnl.net
設計のないスタティックおじさん方式は柔軟かもわからんね↓
67:デフォルトの名無しさん
18/09/05 15:30:35.02 UEpkpswy.net
>>61
正しく組めば重複が減ってコード量は減る
>>64
普通はカプセル化しないことで
開発できなくなることの方が多い
グローバル変数を使うとか
68:デフォルトの名無しさん
18/09/05 23:23:20.11 BuNkH2Jq.net
オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ？
69:デフォルトの名無しさん
18/09/06 01:28:19.10 uUC4mFDs.net
>>67
URLﾘﾝｸ(thinkit.co.jp)
> ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
>
> ・アクターはバウンダリのみ関連線（矢印）が引ける
> ・バウンダリはコントロールとアクターのみ関連線が引ける
> ・エンティティはコントロールのみ関連線が引ける
> ・コントロールはコントロール同士とバウンダリのみ関連線が引ける
残念ながらフロー（流れ）を示す線は書けないので
フローチャートにはならない。特に条件分岐やループなどがない
70:デフォルトの名無しさん
18/09/06 03:27:30.57 OdtAawkS.net
>>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい
71:デフォルトの名無しさん
18/09/06 07:33:26.04 ndioKak8.net
本には書いてないオブジェクト指向
URLﾘﾝｸ(www.arksystems.co.jp)
こいつを見てくれ、こいつをどう思う？
72:デフォルトの名無しさん
18/09/06 07:42:10.81 ndioKak8.net
/** リストの要素をゼロで置き換える **/
private void clearList() {
for (Integer el : someList) {
el = new Integer(0);
}
}
なかなかファンキーなロケンロールだぜ
73:デフォルトの名無しさん
18/09/06 08:26:13.84 abjuqq+M.net
>>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか？
74:デフォルトの名無しさん
18/09/06 08:28:15.97 abjuqq+M.net
>>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ
75:デフォルトの名無しさん
18/09/06 08:31:32.42 abjuqq+M.net
構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの
76:デフォルトの名無しさん
18/09/06 12:51:58.13 ntAiYVJq.net
オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ
77:デフォルトの名無しさん
18/09/06 13:33:23.77 uUC4mFDs.net
>>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか？
78:デフォルトの名無しさん
18/09/06 13:46:11.74 abjuqq+M.net
インターフェースを切って実装を分離することを言ってるんじゃないか？
79:デフォルトの名無しさん
18/09/06 13:50:58.27 BY1c9tpo.net
そもそも、継承関係で隠蔽しちゃい合うのが問題なだ�
80:ｯで、 インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。
81:デフォルトの名無しさん
18/09/06 23:36:20.94 OdtAawkS.net
>>70
そのサイトには賛成できる部分と反対の部分がある
「クラスとはデータ構造」で
「責務はクラスではない」というのには大反対
クラスは責務そのものという方が
オブジェクト指向の主流の教え方
82:デフォルトの名無しさん
18/09/06 23:37:17.79 OdtAawkS.net
>>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向
83:デフォルトの名無しさん
18/09/07 08:35:51.18 avaKv6NM.net
>>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います！
84:デフォルトの名無しさん
18/09/07 08:40:25.09 avaKv6NM.net
責務ごとにクラスを作るのがどうして主流だよね？ってことですよ
85:デフォルトの名無しさん
18/09/07 09:19:04.85 avaKv6NM.net
責務ごとに分離したら凝集度が低下します
86:デフォルトの名無しさん
18/09/07 19:25:29.09 ZCXZkOYn.net
>>81
それもそうか
>>82
変更コストが下がるから
>>83
いやむしろ凝集度は上がるよ？
凝集度を上げるっていうのは
でかいクラスを作ることじゃないよ？
87:デフォルトの名無しさん
18/09/07 19:40:40.77 Nc+ifFiB.net
ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？
どうもUI部の設計は苦手だ。
88:デフォルトの名無しさん
18/09/07 20:33:13.60 avaKv6NM.net
>>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります
89:デフォルトの名無しさん
18/09/07 20:36:30.67 avaKv6NM.net
ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです
90:デフォルトの名無しさん
18/09/07 20:48:57.91 ZCXZkOYn.net
>>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う
91:デフォルトの名無しさん
18/09/07 20:49:13.32 ZCXZkOYn.net
>>86
＞データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる
>>87
ドメインオブジェクトの数が増えていくのは普通だが
1オブジェクトの行数が増えていくのは肥大化
92:デフォルトの名無しさん
18/09/07 21:07:16.42 0j44DGgx.net
>>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと
行数が増えたからオブジェクト分けましょうなんてのは
オブジェクト指向の理念に反する
データをカプセル化してデータに対する責務を持つのが
オブジェクトなんだよ
93:デフォルトの名無しさん
18/09/07 21:09:02.84 0j44DGgx.net
データに対する振る舞いが集まるんだから凝集度は高まるんです
94:デフォルトの名無しさん
18/09/07 21:12:47.16 0j44DGgx.net
オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます
95:デフォルトの名無しさん
18/09/07 21:15:03.24 Nc+ifFiB.net
皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。
いや、分かるよ。俺がViewの設計が下手っぴなのは認める。
96:デフォルトの名無しさん
18/09/07 21:16:51.88 lg5TGvmQ.net
>>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。
97:デフォルトの名無しさん
18/09/07 22:12:16.23 ZCXZkOYn.net
>>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋
>>91
>>83
別人の発言かもしれないがこの発言の関係に疑問が残る
責務ごとにクラスを作ることで凝集度が上がるのであって
複数の責務をひとつのクラスに混ぜたら凝集度は下がるよ
98:デフォルトの名無しさん
18/09/07 22:14:41.41 ZCXZkOYn.net
>>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事
>>93
大きくなったら分割するのは何も悪くない
全体の規模が大きくなっていく時に
ひとつのクラスの行数が増えるのが肥大化
クラス数を増やしていくのが正しいOOP
99:デフォルトの名無しさん
18/09/07 22:15:21.48 JescaW/f.net
つか、ワンオブジェクトワンファイルなんてルールは無いから。
100:デフォルトの名無しさん
18/09/07 22:58:43.86 B/yxkRYZ.net
このｽﾚにいるような池沼が作らなければ
ｸﾗｽﾗｲﾌﾞﾗﾘも階層や種類で作るからな
低い階層に行けばいくほど単純な簡単な機能を提供するｸﾗｽになる
階層は完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
そして明確に種類の異なるﾌﾟﾘﾐﾃｨﾌﾞがある場合は
ﾗｲﾌﾞﾗﾘを完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
その上にｱﾌﾟﾘｹｰｼｮﾝを実現するｸﾗｽ群がのっかる
低学歴知恵遅れが作るとすべて同じ階層で同じ種類になる
101:デフォルトの名無しさん
18/09/08 02:09:56.99 WAR6v8yR.net
クラスに階層があるなんて寝言は寝て言うべきだと思うの
102:デフォルトの名無しさん
18/09/08 02:15:00.94 WAR6v8yR.net
このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ
103:デフォルトの名無しさん
18/09/08 02:18:28.54 j/6nk0eH.net
当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群は
ｼﾛｳﾄでもないかぎり完全に分離するからな
低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘは
当然、中間層のｸﾗｽﾗｲﾌﾞﾗﾘやｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を
参照することはまずない
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘは
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を参照することはまずない
低学歴知恵遅れが作ると酷い依存関係ができる
ｺﾚはｵﾌﾞｼﾞｪｸﾄ指向関係なくﾗｲﾌﾞﾗﾘの基本だからな
104:デフォルトの名無しさん
18/09/08 04:34:33.80 xpw/+eIi.net
>>99
継承はクラス間の階層構造だろ？
>>100
行数だけの問題じゃないけど
プログラムを単純化するために
間接的なクラスを作ることはあるぞ？
105:デフォルトの名無しさん
18/09/08 09:24:01.98 t/+GvP7Y.net
× このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。
「行数を減らす」は「責務」ではない。「責務」を分離することで
得られる結果（メリット）の一つだ
106:デフォルトの名無しさん
18/09/08 12:06:19.78 GaM457i+.net
>70のサイト読んでると
プログラミングでどの様にしてプログラミングするか
というのと
実際のシステム要件なんかからどうやって設計するか
というのがごっちゃに書かれている感じがする
107:デフォルトの名無しさん
18/09/08 12:33:05.14 1I6Cu01I.net
>>103
鋭い
108:デフォルトの名無しさん
18/09/08 12:41:12.60 j/6nk0eH.net
責務とｱﾎみたいなこといってるわ
組織でたとえるならこうなるからな
経営者ｸﾗｽ 社員をこき使う
↓
社員ｸﾗｽ ← 派遣をこき使う（職階ごとの複数の中間層）
↓
派遣ｸﾗｽ ← ｷﾐﾗが担当するような低ﾚﾍﾞﾙな部分の単純作業（つまりｷﾐﾗ）
派遣は社員の作業も役員の作業もしない
社員は役員の作業はしない
行数が多いのは
作業を整理して作業を手順化して
派遣にうまく単純作業を割り当てれてないのと同じだからな
つまり、人に仕事させないと自分の作業が増える
ｷﾐﾗは派遣だからな、そういう作業はできないのは分かる
作業ﾐｽ（例外）が発生してｽﾙｰし続けてたら上までいくからな
109:デフォルトの名無しさん
18/09/08 12:52:36.37 j/6nk0eH.net
例えば扱うﾋﾞｼﾞﾈｽの領域が違えば
部門を分けることになる
会社に複数の部門があっても一つの会社だからな
種類で分けるというのはそういうことになる
ｷﾐﾗみたいな一種類の単純作業しかしてないﾔﾂﾗには関係ない
110:デフォルトの名無しさん
18/09/08 13:03:07.35 j/6nk0eH.net
というわけでな
ｷﾐﾗは刺身にﾀﾝﾎﾟﾎﾟのせる作業に戻りなさい
ｷﾐﾗにはﾑﾘ
111:デフォルトの名無しさん
18/09/08 13:03:32.85 t/+GvP7Y.net
ｷﾐﾗには・・・ｷﾐﾗには・・・
112:デフォルトの名無しさん
18/09/08 13:11:07.86 j/6nk0eH.net
あ、ｵﾏｴは刺身の醤油入れに醤油つめる作業だったか
いや、醤油入れのｷｬｯﾌﾟをしめる作業だったか
ともかく、ｷﾐの細かい作業なんかｵﾚは知らないからな
作業ﾐｽが発生したらちゃんと報告するようにな
まずｷﾐの直属の上長にだ
分かった？
113:デフォルトの名無しさん
18/09/08 13:22:45.36 t/+GvP7Y.net
キミラは下で俺が上だ・・・上なんだ・・・
114:デフォルトの名無しさん
18/09/08 14:59:23.20 1I6Cu01I.net
>>106
それだと上位が下位に依存して
組織が硬直化する
インタフェスを挟んで依存関係を逆転させる
(経営者クラス → 社員インタフェス) ← (社員クラス → 派遣インタフェス) ← 派遣クラス
これがInversion Of Control
115:デフォルトの名無しさん
18/09/08 15:00:32.82 t/+GvP7Y.net
>>112
それどこの定義？
それと同じような説明をしてる場所教えて
116:デフォルトの名無しさん
18/09/08 15:11:58.88 1I6Cu01I.net
Inversion of Controlパターンでコンポーネント間の結びつきを弱める：CodeZine（コードジン）
URLﾘﾝｸ(codezine.jp)
こことか
117:デフォルトの名無しさん
18/09/08 15:40:47.46 j/6nk0eH.net
ただのﾘﾌﾚｸｼｮﾝやんけ
昔のｳﾝｺMFCのｺﾝﾄﾛｰﾙのﾘﾌﾚｸｼｮﾝとほとんど同じ
結局親のｺﾝﾄﾛｰﾙに大量のﾘﾌﾚｸｼｮﾝのｺｰﾄﾞを埋め込むことになる
ｺﾝﾄﾛｰﾙごとに処理記述するほうがはるかに分かりやすい
118:デフォルトの名無しさん
18/09/08 15:43:54.64 j/6nk0eH.net
×結びつきを弱める
○もともと末端ではなにもしない処理にする
119:デフォルトの名無しさん
18/09/08 15:51:53.40 1I6Cu01I.net
何もしないだと・・・
じゃあたんぽぽ担当は何のために
120:デフォルトの名無しさん
18/09/08 16:07:40.80 j/6nk0eH.net
いちいちﾀﾝﾎﾟﾎﾟ載せてる作業経過報告はいらない
作業の補助とか、いちいち次になにをするかとかとか指示はしないからな
ﾀﾝﾎﾟﾎﾟが地面に落ちたとかこのﾀﾝﾎﾟﾎﾟのﾊﾅ小さいとか
そういう報告もいらない
捨てときなさい
それぐらい分かるだろう
ﾀﾝﾎﾟﾎﾟが足りなくなりそうになったら
この台帳に書いときなさい
ｺﾚだけはたまに見といてやるからな
121:デフォルトの名無しさん
18/09/08 16:11:08.60 1I6Cu01I.net
台帳によって疎結合になるわけですね
122:デフォルトの名無しさん
18/09/08 16:11:29.17 1I6Cu01I.net
台帳オブジェクトの発見、これがドメイン分析
123:デフォルトの名無しさん
18/09/09 00:27:26.13 fJdKrV9d.net
タンポポの弾幕
124:デフォルトの名無しさん
18/09/09 01:14:12.52 0bXk8YdS.net
DBのテーブル数や列数が少なくて
テーブル設計が洗練されているならオブジェクト指向っていいんだろうね。
でも現実のシステム考えるとアホみたいにテーブルの数が多くて
アホみたいに列の数が多くて、整理もされていないわけじゃん。
そしてアホみたいに文言の定数定義とかも多い。
そうすると、階層構造作ってレイヤの数を増やして
結果的1つの機能を達成するのに作るファイルの数が増えるほど、
それらのアホみたいに多くて長い列名をレイヤの数だけ書きまくる
みたいな苦行が待っているわけじゃん。
少しでも項目名の変更があったらそれらのファイル部書き換えたり
クラス名に変更がありでもしたらファイル名やフォルダ名とか、
テーブル名、import文とか全部書き換えになるわけじゃん。
それにオブジェクト指向でどう頑張っても最終的に値を
埋め込む画面が汚くなるのは避けることができない。
そうするとオブジェクト指向設計で無理にファイルを分けて
構造化するリスクってやばいと思う。
そうなると少ないファイルオブジェクト指向クソ喰らえみたいな勢いで
構造化プログラミングだけでゴリッと書くほうが早いと思うんだよね。
命名規則もいちいち気を使わないで勢いで書くんだよ。
ファイルの中関数定義だらけになるが、
その中で似たような処理の関数見つけてきて、複製して、
今必要な処理ができるように改変して新たな関数を作る。これで十分だ。
1ファイルの中で完結しているんだから不具合は波及しない。
ファイルをまたいでimportして無理にファイルの昨日使う必要性なんて
どこにも有りはしないだろ。ファイルの頭からimportやextend inplementだらけ
とか吐き気がするよ。
オブジェクト指向ってファイル間の関連性追ったり、
ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。
125:デフォルトの名無しさん
18/09/09 02:14:14.22 rd2vglUK.net
今北産業
126:デフォルトの名無しさん
18/09/09 06:49:20.59 O317ycPa.net
>>122
簡単に言うと短期間しか使わないシステムなら
構造化＋DBで組むのも良いと思うけど
長期間使う大規模なシステムは
オブジェクト指向で組んだ方が
保守まで含めた全体のコストは下がる
だから企業もOOを採用している
127:デフォルトの名無しさん
18/09/09 07:29:49.35 QdIWFdtA.net
>>122
それオブジェクト指向の問題じゃなく、システムの基本設計が破綻してるだけ。
128:デフォルトの名無しさん
18/09/09 07:53:15.67 B5kEXEZS.net
>オブジェクト指向ってファイル間の関連性追ったり、
>ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。
それはその通りだと思う
ただ関連性はプログラムではなくてクラス構造図やオブジェクト生成手順図みたいなので判断するもので所謂上から下に辿って見て行く物でも辿って出きる物でも無い
オブジェクト指向プログラミングをすると設計図をちゃんと描いてから作ってる
って感じがするし
ただまともに且つ効果的に作るのは難しくて解っていない人が無理やり作ってしまうと反って酷くなる
そういう風にしか作れなかったりそういう風な人しか居ないならオブジェクト指向プログラミングは止めておいた方が良いそういう風な所はcobolみたいなのが一番向いていると思う
ただしオブジェクト指向プログラミングに効果的な使い方が有り実際に行われているのでオブジェクト指向プログラミングその物がおかしいというのは間違い
多くの人が
使えるか?
使うべきか?
となるとそれは無理なのかなぁ
とは思う
どっちかって言うと解らないなら無理して使うなという物だと思う
解らない人が有る程度居る?沢山居る?ということならプロジェクトで使わないという判断する
というのが重要なんだと思う
解らない人には苦痛でしかないし解らない人が作った物は本人にも他に人にも迷惑でしかないだろうなぁ
129:デフォルトの名無しさん
18/09/10 23:59:27.90 R+xXPRjE.net
オブジェクト指向がよくわからんド素人俺にはlinqは感動した。
web系フレームワークの真似事+継承だらけのコードのメンテは地獄だった。素人が手をだしたらアカン代物だわ。
130:デフォルトの名無しさん
18/09/17 13:28:16.75 hCpxPlj7.net
ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
URLﾘﾝｸ(blogs.yahoo.co.jp)
131:デフォルトの名無しさん
18/09/17 13:30:49.79 27GPeyCI.net
>>128
なんか気持ち悪い、アスペっぽい
132:デフォルトの名無しさん
18/09/17 13:30:59.69 6+Wt0ENU.net
またお前か
133:デフォルトの名無しさん
18/09/17 22:41:39.72 AYOVQ736.net
>>130
なんか気持ち悪い、糖質っぽい
134:デフォルトの名無しさん
18/09/19 05:57:49.26 zGAoAQgA.net
>>128
そのブログ前も見たけど説明が下手だなあ……
何でデザインパターンが必要なのかとか
自分の言葉でほとんど説明できてないじゃん
分かりやすさ以前に分かる説明をしていない
135:デフォルトの名無しさん
18/09/19 19:25:49.89 3+BPTz35.net
>>125
そらーオブジェクト指向はオブジェクト使うからオブジェクトの構造をちゃんと綺麗に作れば問題は起きないな
オブジェクトの構造と言えばオブジェクト同士の繋がり方関連性も含まれるだろうからそのまま全体像にも繋がるから個々のオブジェクトさえちゃんと作れば全部が良くなるとも言えるはず
問題はシステムの基本設計が破錠しないように作ればいい、ということではなくて破錠しやすいという所にあるような
136:デフォルトの名無しさん
18/09/19 23:52:24.34 YoDbSZZU.net
>>133
知ったかツマラン。
137:デフォルトの名無しさん
18/09/20 00:25:31.99 UYyYb6vq.net
>>134
そやな。俺が知ってる唯一の情報がオブジェクト指向はシステムの基本設計が破綻するってだけだからな。
138:デフォルトの名無しさん
18/09/20 08:07:35.90 v1EqyHAs.net
俺が知ってる情報は次の２つだ
1.バカが使うとどんな言語でも破綻する
2.>>133-135はそのバカに属する
139:デフォルトの名無しさん
18/09/20 17:06:26.63 UYyYb6vq.net
>>136
問題はそこからやな
バカが使わなければ破錠しないのか、隠蔽のコスパが手続き型や関数型で作るコスパを本当に上回ってんのか
140:デフォルトの名無しさん
18/09/20 19:40:11.95 v1EqyHAs.net
>>137
隠蔽のコスパとか言うバカ乙 w
141:デフォルトの名無しさん
18/09/21 19:22:25.43 +zpU6K4O.net
オブジェクト指向は複雑な構造を構築するわけだから
別に破綻はしないだろう
むしろ見た目は良い
142:デフォルトの名無しさん
18/09/21 20:28:00.82 qgyq16h9.net
オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと
143:デフォルトの名無しさん
18/09/21 20:46:48.28 qgyq16h9.net
小規模ならいいが大規模だと設計必須
とりあえず書き始めると最後に詰まるのがオブジェクト指向
小っちゃいパーツを作ってって最後に組み合わせるとき全然組み合わなかったり
つなぎ目の形が合わないのがオブジェクト指向
普通は小さいパーツが出来てるならある程度楽できるはずなのに逆に苦しくなる
本当におかしい
144:デフォルトの名無しさん
18/09/21 20:51:36.57 qgyq16h9.net
クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく
インターフェイスを考えた上の設計がないと後で詰まる
当たり前に思ってるけどそれはオブジェクト指向の限界というか弊害
145:デフォルトの名無しさん
18/09/22 08:52:06.62 seN9Vjts.net
つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな
146:デフォルトの名無しさん
18/09/22 09:44:45.27 jtQ8570T.net
>>140
境界定義なんて、モノリシックアプリでも必須なんだが？
その認識もないままオブジェクト指向とかマイクロサービスに手を出すとグダる。
開発チームを苦しめるマイクロサービス（翻訳）
URLﾘﾝｸ(techracho.bpsinc.jp)
147:デフォルトの名無しさん
18/09/22 09:58:06.00 LHC7cNdc.net
>>142
限界？ 弊害？
>>142のどこに限界や弊害が書いてあるの？
148:デフォルトの名無しさん
18/09/22 14:09:59.67 ycLOp2uz.net
>>145
あんまりそこにしっかり書かれていないから語弊ありきで言うんだが
その抽象的間接的に作らなきゃいけないてことやな
作ってもいい、じゃなくて作らなきゃいけないという
149:デフォルトの名無しさん
18/09/22 15:20:24.84 LHC7cNdc.net
>>146
そりゃ大規模プログラムをメンテナンス性あげて作ろうとしたら
オブジェクト指向に限らず、考えなきゃいけないことだろな。
でも破綻していいなら、別に抽象的間接的に作らなくていい。
小さなツール程度ならゴットクラスで破綻状態でもなんとかできるだろうさ
そういう点で、オブジェクト指向の限界でも弊害でも何でも無い
150:デフォルトの名無しさん
18/09/23 01:13:41.68 MlhnYRcx.net
>>147
いや俺の言う破綻てのは別にオブジェクトオンリーにこだわって
細かいとこをクロージャで逃げたり、その場しのぎ的に小さいオブジェクトで茶を濁すのもダメって意味じゃないんよ
小さいオブジェクトならオブジェクト同士やシステムが密結合になりえないだろうしな
オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな
151:デフォルトの名無しさん
18/09/23 04:48:40.07 N8r2Gw6d.net
> オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな
因果関係が逆
密結合の時・・・問題や破綻が起きる（オブジェクト指向に限らない）
話はこれだけだろう？単純だろうが
152:デフォルトの名無しさん
18/09/23 10:01:28.60 y+eZw7HP.net
普通に組めばいいじゃん
153:デフォルトの名無しさん
18/09/23 11:37:45.64 0vXeudiz.net
>>149
おまえめちゃめちゃバカやなw
154:デフォルトの名無しさん
18/09/23 12:09:34.69 loi8GnJQ.net
まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。
〜指向全般に言えるけれど、結局は一つの指標みたいなもんで
指標上げることが目的になったらクソになるのは当たり前だよね。
155:デフォルトの名無しさん
18/09/23 12:29:12.02 0vXeudiz.net
バカすぎて意味がつながっとらんw
156:デフォルトの名無しさん
18/09/23 15:43:38.58 w6QfJYdi.net
オブジェクト指向に継承って要る？
もともとのオブジェクト指向の発想からすれば、別に無くてもいいっていうか、むしろ邪魔じゃね？
157:デフォルトの名無しさん
18/09/23 16:17:15.71 NWkg7eaT.net
>>154
継承でコードを書く量を減らせるってのはあるが、他の仕組みで代わりになるなら無くても良い
158:デフォルトの名無しさん
18/09/23 16:31:30.62 NWkg7eaT.net
ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ
159:デフォルトの名無しさん
18/09/23 16:37:33.42 MlhnYRcx.net
>>149
ちゃうねん
複雑で大規模なモノは何で組もうが問題や破綻が起きやすくなる、って話と
オブジェクト指向は複雑で 大規模なモノを作ると破綻する、ってのは意味が違う
何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。話の流れで言うと前者により後者が悪質な形で発動する
ただ当然理想論言えば問題を元々起こさなきゃいいっちゃいい話よ理想を言えば
160:デフォルトの名無しさん
18/09/23 16:50:39.86 N8r2Gw6d.net
> 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。
前提が間違っているから話にならん。
まず標準ライブラリの時点ですでに大規模で複雑
それが隠蔽されてるから単純に見えるってことに気づいていない
大規模で複雑なものを作るためだけのものだからというのなら、
ほとんどのものが大規模で複雑なんだから、オブジェクト指向を
使うのは当然ということになる
そして隠蔽されている部分は無視するという話なら、（オブジェクト指向の）
標準ライブラリを使うだけの簡単なコードは作れる
例えば、Rubyでprint "hello world"と書いただけでもオブジェクト指向が使われてる
オブジェクト指向であっても、小規模で単純なものを作れるものである証拠
161:デフォルトの名無しさん
18/09/23 17:11:55.75 MlhnYRcx.net
>>158
オブジェクト指向言語の標準ライブラリとか1番破綻しないオブジェクト指向のパターンじゃないか？
そりゃ全てのオブジェクト指向で作った物が全て破綻することはないだろう
大規模に向いてるオブジェクト指向をあえて小規模なもの作るに都合いいから流用するのはいい事だろう。個人的には自分で作ったクラスを多数のところで使い回してるならそれぞれ小規模でも全体でみたら中、大規模じゃんってなる所はあるけども
とわいえ、それでもやっぱりオブジェクト指向は大規模なものの為”だけ”にあって、そのため”だけ”の機能があって、そのせいで破綻するってのが俺の考えよ
162:デフォルトの名無しさん
18/09/23 17:22:45.03 N8r2Gw6d.net
>>159
だからオブジェクト指向で小規模なものを作る例あげたじゃん。
馬鹿なの？
大規模なら破綻するのは、オブジェクト指向で無くても同じ
163: つまりお前の理屈は オブジェクト指向・・・小規模は作れない、大規模は作れる ？？？指向・・・小規模は作れる、大規模も作れる って言ってるだけでしょ で大規模であれば、破綻するのはどちらも同じなんだから 大規模に置いてはオブジェクト指向も？？？指向も変わらない だからオブジェクト指向で、小規模は作れないと言ってるだけだよね？ （実際にはオブジェクト指向で小規模なものが作れる）
164:デフォルトの名無しさん
18/09/23 17:45:57.32 cRG95Xcq.net
この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる
①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止
ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる
165:デフォルトの名無しさん
18/09/23 19:29:44.09 y+eZw7HP.net
オブジェクト指向にメリットなんて無いからね
166:デフォルトの名無しさん
18/09/23 20:20:35.62 MlhnYRcx.net
>>160
そりゃ作れないなんて言ってないがな。
「オブジェクト指向は大規模なモノを作る為だけにある」って話であって「オブジェクト指向は小規模なモノは絶対に作れない」とはならんからな
ただオブジェクト指向で小規模なモノ作ったらデータをオブジェクトでラッピングしやすいてのがあるけど
あれ完全に全くの偶然でデータをオブジェクトにまとめるのがオブジェクト指向の本丸じゃないように、オブジェクト指向の本丸ではないサブシステムが運良くそこにハマったってだけで
特にそこもオブジェクト指向は大規模なモノを作る為”だけ”にあるってのは意味は変わってないからな
俺が言ってるのは一般的にモノが複雑になれば破綻しやすいという話ではなくて
、”その上で更に”オブジェクト指向は独特の破綻を招くって話であって
167:デフォルトの名無しさん
18/09/23 21:48:23.69 N8r2Gw6d.net
>>163
あー、わかったわかった、つまりこういうことだろ？
墜落事故は飛行機特有の問題だ
自動車は飛べないから墜落自体ありえない
自動車で遠くにいくなら時間はかかるし
距離も長いから事故の確率も上がるし大変だが
飛べないから墜落事故は起きないのだ
168:デフォルトの名無しさん
18/09/23 21:50:15.95 N8r2Gw6d.net
そう主張することで、飛行機の何を否定しているのかわからんのと
どうように、オブジェクト指向の何を否定しているのかわからんがなｗ
169:デフォルトの名無しさん
18/09/23 21:51:15.19 0vXeudiz.net
おまえら破綻しすぎじゃね？w
どうやったらそんなに破綻を量産できんねんw
170:デフォルトの名無しさん
18/09/23 22:02:41.85 MlhnYRcx.net
>>164
オブジェクト指向の話で悪い例え話したら1番イカンやろ。抽象的なもんの取り扱いなんだから。しかも何言ってるかわからんけど多分それは違うしな
>>166
いやまさにそういう事よ。多人数が動く大規模で抽象的な流れは上手くいくはずがないわ。しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する
171:デフォルトの名無しさん
18/09/23 22:26:37.81 N8r2Gw6d.net
>>167
> オブジェクト指向の話で悪い例え話したら1番イカンやろ。
は？なんで？
反論できない言い訳にもほどがあるわ
172:デフォルトの名無しさん
18/09/23 22:28:04.83 N8r2Gw6d.net
> しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する
しない。
オブジェクト指向を使わないほうが破綻するし、
破綻した後
173:のリカバリーはオブジェクト指向よりも大変 お前は単に両方とも破綻するが オブジェクト指向的破綻をするのはオブジェクト指向だけと言ってるだけだろ 破綻する時点で問題なんだよ。オブジェクト指向の方が破綻しない
174:デフォルトの名無しさん
18/09/23 22:42:45.15 MlhnYRcx.net
>>169
>オブジェクト指向的破綻をするのはオブジェクト指向だけと
そういう事や。楽をするためにそれをするメリットが上回ってデメリットのが下回らなきゃいけないのはオブジェクト指向の完全必須項目なんだが
大規模複雑はこの完全必須項目がどんどん難易度が上がってくる。
途中の間違い失敗のリカバリのコストは確実にオブジェクト指向のが上
理想論一般論で言えば間違えなくちゃんと作ればいい、どの作り方でも大きいのは大変は大変、以上！て言えばそりゃそうだが
その問題を防ぐための記法が裏目に出て逆効果なら理想論一般論で片付けたらいかんでしょ
175:デフォルトの名無しさん
18/09/23 23:17:04.84 N8r2Gw6d.net
>>170
ほらな。
> >オブジェクト指向的破綻をするのはオブジェクト指向だけと
> そういう事や。
墜落事故を起すのは飛行機だけだと言ってるのと同じ
だからなの？状態なんだよｗｗｗ
176:デフォルトの名無しさん
18/09/23 23:18:16.29 N8r2Gw6d.net
結局、小規模アプリでも大規模アプリでも
オブジェクト指向のほうが良いって結論なわけだよ。
そして、大規模で破綻するのはオブジェクト指向じゃなくても同じこと
177:デフォルトの名無しさん
18/09/23 23:18:37.66 N8r2Gw6d.net
ただの言葉遊びだったな
178:デフォルトの名無しさん
18/09/23 23:26:41.71 loi8GnJQ.net
そうなりやすいのがオブジェクト指向論争
179:デフォルトの名無しさん
18/09/23 23:28:46.55 cRG95Xcq.net
ﾊﾞｶに限って抽象化とかいって
ｻﾙみたいにうれしがって継承するからな
破綻はそこから始まる
しばらくたつと
ﾃﾞｰﾀ受け渡しするために
無秩序に相互参照しはじめる
こうなったら終わりの始まり
180:デフォルトの名無しさん
18/09/23 23:33:26.91 N8r2Gw6d.net
同じものを作る時、オブジェクト指向はオブジェク手と指向破綻をしやすいが
オブジェクト指向じゃないものを使うと、オブジェクト指向じゃない破綻をする
って言ってるだけ。
オブジェクト指向だと大規模なものを作れる。
オブジェクト指向じゃないと大規模なものは作れない
181:デフォルトの名無しさん
18/09/24 00:03:50.44 +ob6DU4m.net
オブジェクト指向じゃなくしたから
大規模なシステムを作れるようになった
って話はあまり聞かない
182:デフォルトの名無しさん
18/09/24 01:12:57.64 oYzwCf5A.net
オブジェクト指向にメリットなんて無いからね
183:デフォルトの名無しさん
18/09/24 09:54:20.13 dKKNaNpJ.net
ただモジュール境界を明確にしただけなのをオブジェクト指向って言い張ってるだけだろうな。
「オブジェクト指向じゃないと大規模なものは作れない」
この結論ありきで論法を組み立てるとそうなる。
184:デフォルトの名無しさん
18/09/24 16:52:34.59 JEGqIfby.net
>>171
そのアカン例えを使うなと
事故が多発しないはずのシステムでそのシステム特有の事故が多発したって話やな
まぁ、その、悪い例えにあえて乗っかるなら自動車で事故りそうだから飛行機に乗ったら墜落事故起こしたって、だからなんだよって言ったらそりゃダメだよってなるような話で
いややっぱアカンやろこの例え、設計を抽象的な部分から見直せ
185:デフォルトの名無しさん
18/09/24 18:34:58.60 jnbiRGGY.net
まぁオブジェクト指向は「銀の弾丸」じゃないですからね
オブジェクト指向の採用による成功事例は数多く存在する一方で、
オブジェクト指向を採用したにもかかわらず失敗した事例も
少数とはいえ存在するのも事実
たとえば、以下は「一貫性」という設計哲学が無視されてしまったため、
標準ライブラリ設計に失敗した言語の例
ｽﾚﾘﾝｸ(tech板:44-45番)
ｽﾚﾘﾝｸ(tech板:527番)
スレタイに沿って返すとすれば：
・あらゆる言語においてオブジェクト指向ってクソじゃね？
=> いいや、そんなことはない
・Pythonにおいてオブジェクト指向ってクソじゃね？
=> たしかに、Pythonではクソかもしれない
186:デフォルトの名無しさん
18/09/24 18:36:05.95 csv6kfNU.net
>>180
とりあえずお前が馬鹿だっていうのはわかった
大規模なものはどちらにしろ問題が発生する。
オブジェクト指向的問題か
非オブジェクト指向的問題かの
どちらかだ。
オブジェクト指向を使わなかったら
今度は非オブジェクト指向問題が発生するだろ
187:デフォルトの名無しさん
18/09/24 18:37:21.47 csv6kfNU.net
>>181
Pythonで大規模アプリ作って失敗したら
Python的問題が発生したということさ
C言語で失敗したらC言語的問題が発生したということさ
188:デフォルトの名無しさん
18/09/24 18:42:13.65 csv6kfNU.net
仮にオブジェクト指向設計を採用せずに
構造化設計を採用したとしよう。
大規模プログラムで密結合になってると失敗する
そうすると構造化設計特有の問題が発生したということで
それはオブジェクト指向よりもリカバリーが大変
189:デフォルトの名無しさん
18/09/24 18:42:49.46 FEoaRsa5.net
どうでもいい話だな
190:デフォルトの名無しさん
18/09/24 18:43:48.46 JEGqIfby.net
>>182
んなもん当たり前だろ別のやり方すれば別の問題があるに決まってやろ
そんな何にでも通ずる一般論じゃないの
オブジェクト指向がそれ専用なのに逆効果だから色々言ってるの
これは何にでも通ずるフラットな一般論じゃないぞ？何故ならオブジェクト指向はそれ専用なのに逆効果だからな、いわばイレギュラーで根本的な問題
191:デフォルトの名無しさん
18/09/24 18:44:29.97 csv6kfNU.net
そう。ただの言葉遊びしてるだけだからどうでもいいこと
結局は構造化設計を選んで失敗したから
構造化設計に問題があると言ってるだけなんだから
自分の非を認めたくないからそういことをしてる
あ、オブジェクト指向が使えないんだっけか？ｗ
192:デフォルトの名無しさん
18/09/24 18:45:02.09 csv6kfNU.net
>>186
いつからオブジェクト指向がそれ専用になったんでーすかーｗ
おかしいですねｗｗｗ
193:デフォルトの名無しさん
18/09/24 18:46:46.24 csv6kfNU.net
構造化設計は大規模に向かないのである
構造化設計で大規模をやると
失敗する確率が大幅に上がる
構造化設計＋大規模でなんども経験している
そしてオブジェクト指向で設計すると
失敗する確率は大幅に下がるわけだが
それでも失敗してしまったら文句を言おう
オブジェクト指向が問題だったんだー！
194:デフォルトの名無しさん
18/09/24 18:54:12.30 JEGqIfby.net
>>188
>いつからか
そらー最初からやな。そのため”だけ”やしな
195:デフォルトの名無しさん
18/09/24 18:55:45.99 JEGqIfby.net
>>189
おっ？そうだなオブジェクト指向が問題が問題だったんだ。なんだかんだ同意見やったんやな
196:デフォルトの名無しさん
18/09/24 19:07:39.30 jnbiRGGY.net
>>189
>そしてオブジェクト指向で設計すると
>失敗する確率は大幅に下がるわけだが
ここは同意しますけど、
>それでも失敗してしまったら文句を言おう
>
>オブジェクト指向が問題だったんだー！
勘弁してください
数ある言語の中でも失敗してるのはPythonだけなんですから(>>181)、
失敗をオブジェクト指向のせいにしようとしても
それに納得するのはPython信者だけですよ
>>183でもご自分で「Python的問題」と語っていますから、矛盾してます
197:デフォルトの名無しさん
18/09/24 19:08:50.83 csv6kfNU.net
>>190
> そらー最初からやな。そのため”だけ”やしな
そのためって、オブジェクト指向は大規模のときに使うってこと？
ってことは、大規模で問題が起きたら、
それはオブジェクト指向が原因ではないってことだね
だって、単に大規模だからオブジェクト指向を使ったってだけで
大規模で失敗するのは構造化であっても同じだから
>>191
皮肉もわからんのかーｗｗｗ
198:デフォルトの名無しさん
18/09/24 19:13:55.57 csv6kfNU.net
まとめ
構造化・・・大規模に適していない
オブジェクト指向・・・大規模に適している
構造化で小規模・・・失敗しにくい（所詮小規模なので）
オブジェクト指向で小規模・・・失敗しにくい（小規模に使えないとは誰も言ってない）
構造化で大規模・・・適していないので失敗しやすい
オブジェクト指向で大規模・・・適しているので失敗しにくい
構造化で大規模で失敗・・・失敗して当然。構造化に問題があった
オブジェクト指向で大規模で失敗・・・適した道具を使っても失敗した
使ってるやつの能力に問題がある
責任転嫁としてオブジェクト指向使ったから失敗したんやーと叫ぶｗ
199:デフォルトの名無しさん
18/09/24 19:14:23.90 Kxio7RVg.net
Cで書かれたOSはくさるほどある
C++で書かれたOSなんかあんの
200:デフォルトの名無しさん
18/09/24 19:18:02.09 JEGqIfby.net
>>192
もう謎のテンション上げで冷静な会話無理やろ、
1レス目の冷静そうな語り口調急にが帰ってきたらそれはそれでキモイけど、、
201:デフォルトの名無しさん
18/09/24 19:21:50.21 Kxio7RVg.net
超大規模なMS WindowsもCで書かれてる
202:デフォルトの名無しさん
18/09/24 19:21:52.45 csv6kfNU.net
>>196
お前の会話が非論理的だからしょうがない。
オブジェクト指向に問題があったんじゃなくて
大規模で密結合にしたから失敗があっただけだろ？
構造化であっても密結合にしたら失敗するんだから
で、構造化使って密結合にして失敗したら構造化のせいにせずに
オブジェクト指向を使って密結合にして失敗したら
オブジェクト指向のせいにしてるんだろ？
203:デフォルトの名無しさん
18/09/24 19:23:43.41 csv6kfNU.net
どちらにしろ
構造化よりもオブジェクト指向のほうが大規模に強いのは変わらん
オブジェクト指向が大規模のために作られたと言っても
小規模で使えないことにもならない
実際に小規模でも使える
オブジェクト指向で失敗するようなら構造化でも失敗する。
能力不足が原因だからな。
で、能力不足を認めたくないから、
オブジェクト指向のせいにしてるんだろ？
204:デフォルトの名無しさん
18/09/24 19:23:52.69 0XIVTMWe.net
そもそも破綻している、と言える状態はどんな場合だろうか
205:デフォルトの名無しさん
18/09/24 19:24:42.73 Kxio7RVg.net
だいたいわかる
ｳﾝｺｽｸﾘﾌﾟﾄしか使えないような低学歴知恵遅れが
ﾑﾀﾞにｵﾌﾞｼﾞｪｸﾄ指向あげしてる
206:デフォルトの名無しさん
18/09/24 19:26:39.65 csv6kfNU.net
馬鹿「オブジェクト指向で失敗したら、オブジェクト指向特有の・・・」
じゃあ、構造化で失敗したら構造化特有のやり方が原因なんやな？
馬鹿「ぐぬぬ」
↑イマココ
207:デフォルトの名無しさん
18/09/24 19:27:16.94 Kxio7RVg.net
で、ｳﾝｺｽｸﾘﾌﾟﾄで
山盛りのｳﾝｺをつくる
rubyとpython作ってるような
ｳﾝｺｽｸﾘﾌﾟﾀｰ
208:デフォルトの名無しさん
18/09/24 19:30:25.06 Kxio7RVg.net
ｺｲﾂﾗの場合
ｳﾝｺｽｸﾘﾌﾟﾄﾌﾚｰﾑﾜｰｸ（）使っても
破たんさせるほどの特殊能力がある
だいたいこういうの使ってるﾔﾂﾗは
そういうﾔﾂﾗだ
209:デフォルトの名無しさん
18/09/24 19:34:16.94 JEGqIfby.net
>>198
皮肉もわからんのかーwwwとか言うやつが急に非論理的だ、とか笑わせに来てんのか貴様は
なんだろうなお前の言い分は都合が悪いと全部一般論にして逃げてる感あるな、大規模なモノが破綻するのはオブジェクト指向に限らずみんな一緒とか。
それを言うならオブジェクト指向使わず手続き型で組んでも破綻しないように組めばいいじゃんってなるんだよな。
その先が見えないわけよな。もはや何の為にオブジェクト指向使ってるんという
210:デフォルトの名無しさん
18/09/24 19:36:53.39 JEGqIfby.net
>>200
オブジェクト指向の破綻はルール守る為に手続き型のコストを超えた時やろな
211:デフォルトの名無しさん
18/09/24 19:40:51.50 Kxio7RVg.net
ﾉｰﾀﾘﾝ言語の開発現場には
ﾉｰﾀﾘﾝが集まる
ｺﾚは宿命
212:デフォルトの名無しさん
18/09/24 19:42:38.68 JEGqIfby.net
>>207
上でな、オブジェクト指向は壊れると言ったら壊れないように作ればいいという身も蓋も事を言われたんや
言語はそういう人のために作らないといけないかもしれん
213:デフォルトの名無しさん
18/09/24 19:45:46.24 BNNY8GPf.net
いつまで自演しとんねん
214:デフォルトの名無しさん
18/09/24 19:47:43.48 csv6kfNU.net
>>208
当たり前だろ
どんなものでも壊れるというのは大前提
どれだけ壊れにくいか？という壊れにくさの話をしてるのに、
お前は「オブジェクト指向は銀の弾丸でなければならないが
銀の弾丸でないことが判明したらどうする？」と言ってるだけだろ？
誰もオブジェクト指向が銀の弾丸なんていってない
だが強力な武器なんだよ。
215:デフォルトの名無しさん
18/09/24 19:48:10.66 dKKNaNpJ.net
とりあえずオブジェクト指向で作るってことがなんなのかから判別しようか。
例えばlinux kernelはオブジェクト指向でバリバリ作ってると思われてんのかね？
216:デフォルトの名無しさん
18/09/24 19:49:06.45 Kxio7RVg.net
ﾊｰﾄﾞが壊れるのと
低学歴知恵遅れのｵﾂﾑが壊れてるのは
別問題
217:デフォルトの名無しさん
18/09/24 19:50:21.60 BNNY8GPf.net
まだ自演を続けんのかよ
いい加減にしろ
218:デフォルトの名無しさん
18/09/24 19:57:16.26 Kxio7RVg.net
ｼｽﾃﾑが壊れてるﾜｹじゃない
壊れてるのは低学歴知恵遅れのｵﾂﾑ
ｵﾂﾑが壊れてないﾔﾂが作れば
壊れたｼｽﾃﾑはできあがらない
ｵﾌﾞｼﾞｪｸﾄ指向はｷﾁｶﾞｲに刃物
ﾉｰﾀﾘﾝにｵﾌﾞｼﾞｪｸﾄ指向を促すこと自体が常軌を逸してる
ﾉｰﾀﾘﾝがｵﾌﾞｼﾞｪｸﾄ指向で開発しようとすること自体が銃刀法違反並の重罪
219:デフォルトの名無しさん
18/09/24 20:01:34.39 H/ciA4Rj.net
オブジェクト指向って何ですか？
C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
220:デフォルトの名無しさん
18/09/24 20:07:21.20 Kxio7RVg.net
X11やMS Windowsもｵﾌﾞｼﾞｪｸﾄ指向で設計されてる
ただ、低学歴知恵遅れでは、C言語でそれを実現することはできない
そしてそれを簡単に実現できる言語を使うと
なにが便利であるか核心的な部分が理解できずに使って
別のろくでもない問題をおこすわけ
221:デフォルトの名無しさん
18/09/24 20:10:52.64 Kxio7RVg.net
ﾊﾝﾄﾞﾗやｺﾝﾃｷｽﾄつかって
ｵﾌﾞｼﾞｪｸﾄを操作するのはまさしくｵﾌﾞｼﾞｪｸﾄ指向の便利な部分だからな
UNIXのi/oなんかもﾊｰﾄﾞｳｪｱがうま�
222:ｭ抽象化されてる ﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀ使って簡単に読み書きができるからな
223:デフォルトの名無しさん
18/09/24 20:13:11.48 oYzwCf5A.net
オブジェクト指向にメリットなんて無いからね
224:デフォルトの名無しさん
18/09/24 20:17:40.60 csv6kfNU.net
>>215
> C言語ではオブジェクト指向に従ってプログラムを作ることはできないのですか？
大変だけどできるよ
作りやすいかどうか、失敗しやすいかどうかだから
225:デフォルトの名無しさん
18/09/24 20:22:15.20 csv6kfNU.net
結局の所、小規模なものはオブジェクト指向使っても失敗しない
大規模なものは、オブジェクト指向を使うと失敗しにくくなる
って所が重要なんじゃないですかね？
失敗したときにそれがオブジェクト指向的な原因か
構造化的な原因か、なんてことよりよりも
226:デフォルトの名無しさん
18/09/24 20:30:44.15 Kxio7RVg.net
低学歴知恵遅れにｵﾌﾞｼﾞｪｸﾄ指向はまずﾑﾘ
日本では、ITﾄﾞｶﾀは低学歴底辺がなる職業だからな
だいたい程度がしれたﾔﾂﾗが群がってくる
この板みれば分かるとおり
227:デフォルトの名無しさん
18/09/24 20:31:28.52 e4NBE4Fp.net
う～ん、ここ見てるとオブジェクト指向はクソと言いたくなるね。
何らかの問題を解決したい、もっと便利で問題の発生しない手法は無いだろうかというような要望があって、
それを実現するためにオブジェクト指向なるものが発明されたとすれば、
同じ考えでオブジェクト指向を採用するのも良いだろうけど、
最初からオブジェクト指向ありきはダメなんじゃないの?
なんかさ、なんでも右ならえで無理に採用してるような気がするんだよなあ。
オブジェクト指向に限った話じゃ無いけど、特に日本では。
228:デフォルトの名無しさん
18/09/24 20:32:33.20 csv6kfNU.net
>>222
お前の書き込みは、オブジェクト指向がクソだということが目的になっていて、
その他の何かが、オブジェクト指向よりも優れているという話になってない
229:デフォルトの名無しさん
18/09/24 20:35:08.38 csv6kfNU.net
>>221
優れた人が優れた道具を使う
それに対抗するために、もっと優れた道具ができたとしても
それだって優れた人が使ったほうがもっと効果が高いわけで
優れてない人が、優れてない道具を使って勝つには
人海戦術しかないんだよね
230:デフォルトの名無しさん
18/09/24 20:38:06.78 Kxio7RVg.net
ぜんぜん分かってないわ
刃物は道具でもあるし
人を殺すこともできる
231:デフォルトの名無しさん
18/09/24 20:38:44.95 Kxio7RVg.net
あやまった使い方をすれば
簡単にｹｶﾞをする
232:デフォルトの名無しさん
18/09/24 20:42:45.07 e4NBE4Fp.net
>>223
いや、オブジェクト指向をクソだなんて思ってないよ。
むしろ好きな方なんで。
でも、肯定派の人ってありきでしょ。
それは違うかなって。
233:デフォルトの名無しさん
18/09/24 20:50:20.68 Kxio7RVg.net
教育ｺｽﾄはものすごいかかるが
手続き型言語でｵﾌﾞｼﾞｪｸﾄ指向をみっちり体験してから
ｵﾌﾞｼﾞｪｸﾄ指向の教育に移行したほうがいい
この手順踏んだほうが間違いが少ない
そうでないと
ID:csv6kfNU ← ｺｲﾂ
みたいに頭悪いのが大量に量産され続ける
234:デフォルトの名無しさん
18/09/24 21:03:48.14 u7Hms91/.net
>>228
バカにコストかけて教育するのもなんだかなー
バカとハサミは使いよう、というけれど、なかなか良い使いようが見つからんね。
235:デフォルトの名無しさん
18/09/24 21:19:43.39 AdxflhqI.net
オブジェクト指向のメリットって何？
この問いに今だかつて一人も答えてくれた事は無い
どっか他の文献指差して丸投げとか
逃げと食い下がりを駆使して結局答えないとか
236:デフォルトの名無しさん
18/09/24 21:47:42.62 oYzwCf5A.net
>>230
困ったことにどっかの文献ですら
ちゃんと理詰めで仕組みを解説してるものは皆無
完全なオカルトテクノロジー
237:デフォルトの名無しさん
18/09/24 21:48:43.99 FEoaRsa5.net
低学歴は無理せずにＩＴ土方やってなさい
238:デフォルトの名無しさん
18/09/24 23:07:18.05 Kxio7RVg.net
転ばぬ先の杖
STOP ｵﾌﾞｼﾞｪｸﾄ指向
239:デフォルトの名無しさん
18/09/24 23:31:05.04 JEGqIfby.net
>>230
いびつな答え方するんだがそりゃ間違いなくパーツや責任関係の切り分けからーの作りやすくなるってことやろな
俺は嘘だと思う
240:デフォルトの名無しさん
18/09/25 08:11:13.05 ffbXNZny.net
色んなサイトでオブジェクト指向の説明してるけど説明が下手すぎねえか？
設計図とか野菜や動物に例えるとか理解してんのかと思うわ
雛形作ってからそこに入力規格を統一したデータをぶち込むって例えでいいだろ
241:デフォルトの名無しさん
18/09/25 08:46:47.22 Eix7hoc3.net
>>235
意味不明すぎてふいた
242:デフォルトの名無しさん
18/09/25 08:48:25.26 Eix7hoc3.net
オブジェクト指向とは雛形作ってそこに入力規格統一したデータをぶち込むってことだぞ
243:デフォルトの名無しさん
18/09/25 08:48:47.92 Eix7hoc3.net
わかってんのかお前ら
244:デフォルトの名無しさん
18/09/25 11:00:50.48 bhDxFTjN.net
さっぱりわからない
オブジェクト指向のメリットとか特に
245:デフォルトの名無しさん
18/09/25 12:27:26.16 6l+mHu1d.net
ぶち込んだ経験ないやつには難しいやろな
246:デフォルトの名無しさん
18/09/25 12:30:49.14 Ti214GxU.net
オブジェクト指向とは関数仕様があってそこに仕様通りの引数渡すことなのね。
すごい、ようやく俺でもオブジェクト指向が理解できた！
247:デフォルトの名無しさん
18/09/25 15:04:59.78 GnoTTlW7.net
>>215
＞オブジェクト指向って何ですか？
オブジェクトを中心に組むこと
クラスベースの言語ならクラス
Cは関数で組むけどC#はクラスで組む
＞C言語では
できる
けどCは向いてない
C#とかJavaとか
最初からOOをサポートしてる言語の方がやりやすい
248:デフォルトの名無しさん
18/09/25 15:05:47.22 GnoTTlW7.net
>>230
＞オブジェクト指向のメリット
プログラムの変更コストが下がること
249:デフォルトの名無しさん
18/09/25 17:07:50.15 bhDxFTjN.net
>>243
どういう理由で？
オブジェクト単位に分けると仕様が消えるの？
250:デフォルトの名無しさん
18/09/25 18:10:21.54 GnoTTlW7.net
>>244
疎結合になるから
251:デフォルトの名無しさん
18/09/25 18:52:32.16 bhDxFTjN.net
>>245
それって君が想定した変更のときだけだよね？
252:デフォルトの名無しさん
18/09/25 18:58:18.78 bhDxFTjN.net
そうでなければむしろ最強レベルの苦痛を伴う変更になるんだよね？
無意味じゃない？
253:デフォルトの名無しさん
18/09/25 19:02:25.86 GnoTTlW7.net
>>246
想定外の変更があったとしても
オブジェクト単位の方が変更しやすい
254:デフォルトの名無しさん
18/09/25 19:05:45.05 bhDxFTjN.net
>>248
別れてるからこそ変更しにくいって状況になったことがない？
経験不足じゃない？
255:デフォルトの名無しさん
18/09/25 19:10:47.09 bhDxFTjN.net
例えばさヘッダーと内容と記述者と更新日時がある条件を満たしたときに
ヘッダーにある文字列を入れて欲しいと
でもヘッダーは他の全てを知らないので関連するオブジェクト全てに手を入れなければならないと
こういうの想像できないの？
レベル低くね？
256:デフォルトの名無しさん
18/09/25 19:16:48.81 GnoTTlW7.net
>>249
いやいやそれこそ
オブジェクト指向開発での経験不足
257:デフォルトの名無しさん
18/09/25 19:22:34.13 GnoTTlW7.net
>>250
＞ヘッダーと内容と記述者と更新日時
たとえばブログのエントリのように
それらの情報に関連性があるのであれば
ひとつのオブジェクト（クラス）にする
そのオブジェクトは当然関連するデータを知っているので
変更もスムーズにできる
一方オブジェクト指向でない場合には
それらのデータがバラバラになっているから変更しにくい
この場合は疎結合というより高凝集の側面が出ている
オブジェクト指向で正しく組むと高凝集疎結合になる
258:デフォルトの名無しさん
18/09/25 19:28:22.29 bhDxFTjN.net
>>252
って変更を各オブジェクトに入れないとできないよね？
c言語だと普通に処理書くだけやで
259:デフォルトの名無しさん
18/09/25 19:40:26.69 du+nhKJd.net
オブジェクト指向は設計思想として好きだけど
オブジェクト思考的パラドックスに陥っている気がする
260:デフォルトの名無しさん
18/09/25 19:54:06.59 o8KZiItl.net
これだけ前もって言っといた方がええやろ
データとメソッドをオブジェクトで綺麗にまとめることを自慢する輩はオブジェクト指向ですらないと
261:デフォルトの名無しさん
18/09/25 20:13:12.32 BMMTvniR.net
データとメソッドをオブジェクトで綺麗にまとめられるのは事実
別に自慢はしてない
オブジェクト指向を勘違いしている人はオブジェクト指向を、
不可能なことを可能にする技術だと勘違いしておいて
不可能なことを可能にしてないと（自分の勘違いを）批判してる
オブジェクト指向は従来
262:のやり方でも可能ではあるが 大変なことをより分かりやすく簡単に実現するための技術
263:デフォルトの名無しさん
18/09/25 20:53:51.26 GnoTTlW7.net
>>253
＞c言語だと普通に処理書くだけ
大規模になると「普通に」って言っても
関連のある変数を探すのが大変になってくる
だからオブジェクト指向の方が変更しやすい
264:デフォルトの名無しさん
18/09/25 21:06:16.95 BMMTvniR.net
オブジェクト指向は大規模開発のために作られた
だが小規模開発で使用しても問題ない
265:デフォルトの名無しさん
18/09/25 21:51:35.20 CZcrESgD.net
強制的にOOに慣れるためのプログラミングスタイル、ってありませんか？
266:デフォルトの名無しさん
18/09/25 21:56:25.48 GnoTTlW7.net
>>259
OOコード養成ギブス
URLﾘﾝｸ(d.hatena.ne.jp)
267:デフォルトの名無しさん
18/09/25 22:15:26.66 CZcrESgD.net
>>260
thx a lot !!!
268:デフォルトの名無しさん
18/09/25 22:46:19.22 FLKmzsJJ.net
>>256
> オブジェクト指向を勘違いしている人はオブジェクト指向を、
> 不可能なことを可能にする技術だと勘違いしておいて
> 不可能なことを可能にしてないと（自分の勘違いを）批判してる
こういう意見おなかいっぱい
「OOPのメリットはXXXです」
以外の文章はもういい
269:デフォルトの名無しさん
18/09/25 22:57:23.11 BRabQ1iT.net
流れを追っていくとOOPのメリットはリファクタリングにかかるコストが安いって読めるけど
これじゃあダメなのか？
270:デフォルトの名無しさん
18/09/26 00:31:24.02 bs5egenN.net
オブジェクト指向のデメリットが単純にコードの段取りや量が増えて鈍臭いんだから
メリットは必然的にその分作りやすくなるって事に消去法でなるやろ
まあ嘘である
271:デフォルトの名無しさん
18/09/26 00:44:41.52 bs5egenN.net
>>260
適当に読んだけどええ事書いてるな
そうそう抽象化っていうのはこの位しないとダメよな
272:デフォルトの名無しさん
18/09/26 04:39:27.51 8XNtqdsN.net
セッター、ゲッター、プロパティを使わない。
これはカプセル化を強いる抜本的なアプローチだ。
これはDependency Injectionアプローチの実装も必要になるし、
"言え、訊くな"という格言の遵守も必要となる。
おれの居るところ真逆のプロジェクトだ使いまくりでワロタ
273:デフォルトの名無しさん
18/09/26 06:02:50.00 Jt0rVGX1.net
セッター、ゲッター、プロパティを使うなってのはクラスは全て操作だけで実装しろってことなのかな？
274:デフォルトの名無しさん
18/09/26 08:59:38.32 cdctReAr.net
>267
イメージ的にはそうだと思う
ただ操作対象を設定する必要は有るから全く使わないという事では無い
ゲッターセッターの一番の問題点は
それを不用意に使ってしまうとグローバル変数をただ面倒な手順を増やして使うだけになってしまい易いから
不用意に使わないようにする
という訓練の為に
使うな
と言っているのだろう
あくまでオブジェクト指向プログラミングが全くと言って出来ない人向けなんだろう
というよりそう書いて有るけど
オブジェクト指向プログラミングの最大の問題点は
標準教範が存在していない事なんだよなぁ
そのギプスなんたらは教範の一部に成れる可能性が有るかもしれない
275:デフォルトの名無しさん
18/09/26 21:23:07.74 2wWeimMK.net
>>268
納得できる説明なのにおかしな改行で台無し・・・
276:デフォルトの名無しさん
18/09/26 22:10:14.19 Ye0laooE.net
メタプログラミングが不要な用途だけなら、オブジェクト指向知らなくても組める。
まあいつまでももそれだと、大規模システムの仕事は無理だが。
277:デフォルトの名無しさん
18/09/26 22:27:48.39 xMAwDWlb.net
ゲッターセッターの悪いのは
インタフェースありきの設計の中に
実装上の変数がうっすら見えてきちゃうこと
そんなもんを前提に設計してはならない
実装に対してプログラミングするのではなく
インタフェースに対してプログラミングするのだ
同じ理由で、それを書き易くしたC#のプロパティみたいなもんは糞
池沼の要望に迎合した�
278:謔､な糞
279:デフォルトの名無しさん
18/09/26 22:42:34.06 yzZF1GUc.net
>>271
メソッドとプロパティ (setter, getter) は本質的に同じものだよ
オブジェクトのメソッドの大半はオブジェクトの状態を取得または変化させる
（状態を参照しないならそのオブジェクトに持たせる必要はないわけで）
オブジェクトのメソッドのうち、一つの変数を変更するものがsetterで
一つの変数を取得するものがgetter・・・になってることが多いが別にそうする必要はない。
例えば内部変数が配列で要素の0番目を読み書きするsetter/getter
要素の1番目を読み書きするsetter/getterを作っても良い
もちろんsetter/getterではなくメソッドでやっても良い
どちらでも同じことができる。
言い換えると、システムを作るのに、メソッドだけでも実現できるし
プロパティ (setter/getter) だけでも実現できるということ
メソッドとプロパティ (setter/getter) の違いは
UMLのクラス図を書いたことがあればわかる。
UMLのクラス図には操作と属性の両方が存在するんだよ。
なぜか？ それは人間の思考を反映させた結果だから
実装段階の思考ではなくて設計段階の思考ですでに操作と属性が別れてる。
メソッドとプロパティは本質的には同じものでコンピュータから
見れば同じものとして扱えるが、我々は人間なんだ。
人間がそれは操作、それは属性って分類して考えてるから、
それをコードに反映させられる記述能力の高さを求めた結果
メソッドとプロパティができたんだよ
しかたないね。人間だもの
280:デフォルトの名無しさん
18/09/26 23:05:14.04 xMAwDWlb.net
> メソッドとプロパティ (setter, getter) は本質的に同じものだよ
> （以下ポエム略）
？？
なぜそれを俺にレスしたのか不明
281:デフォルトの名無しさん
18/09/26 23:25:48.93 +un+mAjX.net
むしろおまえ以外の誰にレスしろというのか不明w
282:デフォルトの名無しさん
18/09/27 00:13:38.88 oacq4Bqj.net
だが実際にはクラスを半グローバル変数の格納構造体みたいに使って
setter/getterでアクセスして外側から中の実装を多角的に覗くような記述をし
そこに更に継承を使って依存でスパゲティー状態になっちゃうから
ソフトウエアの表現方法としての有効性に疑問を持ち始めた人が現れてきたんじゃないかな
283:デフォルトの名無しさん
18/09/27 00:30:43.91 Fk1HpByz.net
>>275
つまり、
× getter/setterが悪い
○ getter/setterの間違った使い方が悪い
284:デフォルトの名無しさん
18/09/27 00:35:00.12 pq96CSzd.net
刺身にﾀﾝﾎﾟﾎﾟのせてるﾔﾂが
ちゃんとｷﾘｷﾘ働いてるか
その働きぶりをたまに覗きたいことはある
こっちからなにをするということはない
285:デフォルトの名無しさん
18/09/27 00:42:24.43 oacq4Bqj.net
>>276
確かに悪い使い方が都市伝説みたいに普及しすぎて、ろくろくまともな開発したことの
無い輩まで頓珍漢なｵﾚｵﾚオブジェクト指向論を吹聴するにいたったブームには参ったが、、
使い方の問題のみならず、そういう表しにくい構造がソフトウエアそのものにあるじゃないかと思う。
非常に表しにくい場合が少なからずあり、小さいサンプルコードの断片で説かれるOOの美しいはずの
メリットは実践で適用の場が乏しいということ
286:デフォルトの名無しさん
18/09/27 00:54:06.21 oacq4Bqj.net
>>260
このギプスのサイトに書いてある方法は
すごく制約した方法であり、
いろいろ大変かも知れないけど
守れば副作用の少ないモジュラリティーと
深すぎない階層設計が可能になるかもしれないのはよく分かる。
でも、守るためには強い規律とメンバのスキルと
工数のゆとりが必要だと思った。
つまり、現実にはなかなか難しい話だろうなと。
287:デフォルトの名無しさん
18/09/27 01:41:53.45 DSKWvsHE.net
いや、単純に�
288:Iブジェクト指向なんてやったって地獄に落ちるだけ クラスっていうゴミ箱に突っ込んで臭いものに蓋してる状態じゃいつまでたってもバグなんて取れないんだよ 単純にプログラムを 入力→処理→出力 という繰り返しの塊にしなければならない メソッドを呼ぶたびに状態が変化 するようなもん誰も管理できない
289:デフォルトの名無しさん
18/09/27 01:45:45.45 oacq4Bqj.net
オブジェクト指向の解釈が多彩なので、あれだけど
オブジェクトscopeは有効な場面は多々あるんだよな
closureとか部分適用とか
290:デフォルトの名無しさん
18/09/27 01:46:43.86 pq96CSzd.net
ｵﾌﾞｼﾞｪｸﾄ指向でも
詳細化したらﾃﾞｰﾀﾌﾛｰ図に落とせる設計でないと
お話にならない
291:デフォルトの名無しさん
18/09/27 01:47:55.67 DSKWvsHE.net
状態を持ってしまうのがまずい
いや、持つだけなら好きにすればいい
内包してしまうのがまずいと言うのが正確か？
292:デフォルトの名無しさん
18/09/27 01:50:10.34 pq96CSzd.net
以前(>>161)にも書いたとおり
ｺﾚ以外方法はない
この原則さえ守れば破綻は回避できる
大体の大きな問題は起きなくなる
①公開ｲﾝﾀﾌｪｰｽは可能な限り少なくする
②原則として、よほど適切な理由がないかぎり、可能な限り継承よりｺﾝﾎﾟｼﾞｼｮﾝ使う
③下位階層(ここでの階層は>>101>>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない
※ 当然、下位ｸﾗｽが上位ｸﾗｽのｲﾝﾀｰﾌｪｰｽを直接呼びだすようなﾘﾌﾚｸｼｮﾝは禁止
④下位階層のｲﾝｽﾀﾝｽが非同期で上位のｲﾝｽﾀﾝｽに処理を依頼したい状況が発生した場合（可能な限りこんな状況が起きる設計は当然避けるべき）、
処理のやりとりはﾒｯｾｰｼﾞｷｭｰで行い、可能な限り少ない回数で簡潔なﾒｯｾｰｼﾞを用いて簡単に完結できるようにする、複雑なﾒｯｾｰｼﾞｼｰｹﾝｽも禁止
（ｺﾚは並立するｲﾝｽﾀﾝｽ間でも同じ）
⑤同じ階層に並立するｲﾝｽﾀﾝｽをﾑﾀﾞに乱立させるのは当然禁止
ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる
293:デフォルトの名無しさん
18/09/27 01:52:11.89 DSKWvsHE.net
単純にメソッドの成功条件に内部で持たれているメンバの見えない奴が関わってたりすると最悪
プログラムのどこでそいつが変更されるのかわからん
こういう問題が起きるたびに途方も無い労力を支払うのが単純に無駄
オブジェクト指向を考えた奴はわざと技術者の仕事を作るためにこれを考えたのではないか？
というぐらい一切メリットがない
294:デフォルトの名無しさん
18/09/27 01:54:14.64 DSKWvsHE.net
>>284
だからな
お行儀のよいクラス作るほど
その実開発者は地獄を見るんだよ
オブジェクト指向がクソな原因は
簡単で内部に状態を保持することなんだよ
295:デフォルトの名無しさん
18/09/27 01:58:10.12 oacq4Bqj.net
もう今日は寝ろよﾊｹﾞども
ﾉｼ
296:デフォルトの名無しさん
18/09/27 02:02:11.90 oacq4Bqj.net
単純な入れ子構造になっているか分かりにくい
ランダムに依存しうるネットワーク構造は管理しにくい
しかもノードインスタンスごとに状態を持っていたり
何の×ゲームだよ
297:デフォルトの名無しさん
18/09/27 02:41:53.03 y/NaeiDF.net
割と真面目にオブジェクト指向は将来的に絶対破滅するという想定で作るといい気がしてきた
上で出てる上手くいく方法とかは「延命措置」とみなして
そう考えたら何かすっきりする
298:デフォルトの名無しさん
18/09/27 02:47:01.34 Fk1HpByz.net
そう。1000年後には絶対破滅するという想定で、
今の仕事を全力でやればいい。
今必要なら、必要ってこと�
299:ｳ、AHAHAHAHA～
300:デフォルトの名無しさん
18/09/27 03:51:07.23 fvjtmZUM.net
>>260
部分的に構造化プログラミング養成ギプスのような気がする
301:デフォルトの名無しさん
18/09/27 03:53:07.34 fvjtmZUM.net
メソッドを呼び出す順番に依存してはならない
302:デフォルトの名無しさん
18/09/27 07:40:33.24 zZL/tnLy.net
>>283
公開されてるメソッドの呼ばれ方による状態繊維が簡易なレベルならば問題ない
といったところ。
通信ソケットの実装みたいなものはどうしても状態を持つのは仕方ないけど、
でもそれもできる限り小さく持つってのが最近の感覚じゃないかね。
内部に巨大で複雑なオブジェクトをガツガツ作る様なメソッドがある場合は
なんか問題ある気がする。
303:デフォルトの名無しさん
18/09/27 08:19:49.02 emgF57xx.net
状態を持つなって言ってるのは関数型の考えから？
常にオブジェクト指向言語の方がメジャーなんだが
304:デフォルトの名無しさん
18/09/27 08:20:57.92 BciEc+9A.net
昔はgetter/setterを使うべきと言ってたような気がする。
でもその時にそれに疑問を持っていた人達もいたと思うんだ。
結局、クソなのはこういう手法が良いですよという言を真に受けて無理に採用する所じゃね?
このなんとかキブスが自分にぴったりくるなら採用すれば良いし、おかしいと思うなら採用しなくて良い。
オブジェクト指向も一緒でぴったり来てねえのに採用するのは良くないと思う。
305:デフォルトの名無しさん
18/09/27 08:24:56.86 emgF57xx.net
グローバル変数をそのまま使うよりは
ゲッターセッターをかぶせた方がマシだけど
使わないにこしたことはないってこと