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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>81
それもそうか

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ

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

当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群は
ｼﾛｳﾄでもないかぎり完全に分離するからな

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

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

低学歴知恵遅れが作ると酷い依存関係ができる
ｺﾚはｵﾌﾞｼﾞｪｸﾄ指向関係なくﾗｲﾌﾞﾗﾘの基本だからな

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

>>99
継承はクラス間の階層構造だろ？

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

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

× このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。

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

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

>70のサイト読んでると

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

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

>>103
鋭い

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

責務とｱﾎみたいなこといってるわ
組織でたとえるならこうなるからな

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

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

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

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

作業ﾐｽ（例外）が発生してｽﾙｰし続けてたら上までいくからな

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

例えば扱うﾋﾞｼﾞﾈｽの領域が違えば
部門を分けることになる

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

ｷﾐﾗみたいな一種類の単純作業しかしてないﾔﾂﾗには関係ない

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

というわけでな
ｷﾐﾗは刺身にﾀﾝﾎﾟﾎﾟのせる作業に戻りなさい
ｷﾐﾗにはﾑﾘ

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

ｷﾐﾗには・・・ｷﾐﾗには・・・

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

あ、ｵﾏｴは刺身の醤油入れに醤油つめる作業だったか
いや、醤油入れのｷｬｯﾌﾟをしめる作業だったか

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

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

分かった？

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

キミラは下で俺が上だ・・・上なんだ・・・

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

>>106
それだと上位が下位に依存して
組織が硬直化する
インタフェスを挟んで依存関係を逆転させる

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

これがInversion Of Control

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

>>112
それどこの定義？
それと同じような説明をしてる場所教えて

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

Inversion of Controlパターンでコンポーネント間の結びつきを弱める：CodeZine（コードジン）
https://codezine.jp/article/detail/60

こことか

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

ただのﾘﾌﾚｸｼｮﾝやんけ
昔のｳﾝｺMFCのｺﾝﾄﾛｰﾙのﾘﾌﾚｸｼｮﾝとほとんど同じ
結局親のｺﾝﾄﾛｰﾙに大量のﾘﾌﾚｸｼｮﾝのｺｰﾄﾞを埋め込むことになる

ｺﾝﾄﾛｰﾙごとに処理記述するほうがはるかに分かりやすい

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

×結びつきを弱める
○もともと末端ではなにもしない処理にする

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

何もしないだと・・・
じゃあたんぽぽ担当は何のために

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

いちいちﾀﾝﾎﾟﾎﾟ載せてる作業経過報告はいらない
作業の補助とか、いちいち次になにをするかとかとか指示はしないからな

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

ﾀﾝﾎﾟﾎﾟが足りなくなりそうになったら
この台帳に書いときなさい
ｺﾚだけはたまに見といてやるからな

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

台帳によって疎結合になるわけですね

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

台帳オブジェクトの発見、これがドメイン分析

**デフォルトの名無しさん** · 2018/09/09(日) 00:27:26.13

タンポポの弾幕

**デフォルトの名無しさん** · 2018/09/09(日) 01:14:12.52

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

**デフォルトの名無しさん** · 2018/09/09(日) 02:14:14.22

今北産業

**デフォルトの名無しさん** · 2018/09/09(日) 06:49:20.59

>>122
簡単に言うと短期間しか使わないシステムなら
構造化＋DBで組むのも良いと思うけど
長期間使う大規模なシステムは
オブジェクト指向で組んだ方が
保守まで含めた全体のコストは下がる
だから企業もOOを採用している

**デフォルトの名無しさん** · 2018/09/09(日) 07:29:49.35

>>122
それオブジェクト指向の問題じゃなく、システムの基本設計が破綻してるだけ。

**デフォルトの名無しさん** · 2018/09/09(日) 07:53:15.67

>オブジェクト指向ってファイル間の関連性追ったり、
>ファイル構造を含んだデバッグの苦痛は無視してんのか？って思う。

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

**デフォルトの名無しさん** · 2018/09/10(月) 23:59:27.90

オブジェクト指向がよくわからんド素人俺にはlinqは感動した。
web系フレームワークの真似事+継承だらけのコードのメンテは地獄だった。素人が手をだしたらアカン代物だわ。

**デフォルトの名無しさん** · 2018/09/17(月) 13:28:16.75

ヤフーのブログのサイトで初心者にはわかりやすいブログを発見したよ。
https://blogs.yahoo.co.jp/kamyu_2010/35417803.html

**デフォルトの名無しさん** · 2018/09/17(月) 13:30:49.79

>>128
なんか気持ち悪い、アスペっぽい

**デフォルトの名無しさん** · 2018/09/17(月) 13:30:59.69

またお前か

**デフォルトの名無しさん** · 2018/09/17(月) 22:41:39.72

>>130
なんか気持ち悪い、糖質っぽい

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

>>128
そのブログ前も見たけど説明が下手だなあ……

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

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

>>125
そらーオブジェクト指向はオブジェクト使うからオブジェクトの構造をちゃんと綺麗に作れば問題は起きないな
オブジェクトの構造と言えばオブジェクト同士の繋がり方関連性も含まれるだろうからそのまま全体像にも繋がるから個々のオブジェクトさえちゃんと作れば全部が良くなるとも言えるはず

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

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

>>133
知ったかツマラン。

**デフォルトの名無しさん** · 2018/09/20(木) 00:25:31.99

>>134
そやな。俺が知ってる唯一の情報がオブジェクト指向はシステムの基本設計が破綻するってだけだからな。

**デフォルトの名無しさん** · 2018/09/20(木) 08:07:35.90

俺が知ってる情報は次の２つだ
1.バカが使うとどんな言語でも破綻する
2.>>133-135はそのバカに属する

**デフォルトの名無しさん** · 2018/09/20(木) 17:06:26.63

>>136
問題はそこからやな
バカが使わなければ破錠しないのか、隠蔽のコスパが手続き型や関数型で作るコスパを本当に上回ってんのか

**デフォルトの名無しさん** · 2018/09/20(木) 19:40:11.95

>>137
隠蔽のコスパとか言うバカ乙 w

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

オブジェクト指向は複雑な構造を構築するわけだから
別に破綻はしないだろう
むしろ見た目は良い

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

オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと

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

小規模ならいいが大規模だと設計必須
とりあえず書き始めると最後に詰まるのがオブジェクト指向

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

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

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

クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく
インターフェイスを考えた上の設計がないと後で詰まる
当たり前に思ってるけどそれはオブジェクト指向の限界というか弊害

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

つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな

**デフォルトの名無しさん** · 2018/09/22(土) 09:44:45.27

>>140
境界定義なんて、モノリシックアプリでも必須なんだが？
その認識もないままオブジェクト指向とかマイクロサービスに手を出すとグダる。

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

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

>>142
限界？弊害？

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

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

>>145
あんまりそこにしっかり書かれていないから語弊ありきで言うんだが
その抽象的間接的に作らなきゃいけないてことやな
作ってもいい、じゃなくて作らなきゃいけないという

**デフォルトの名無しさん** · 2018/09/22(土) 15:20:24.84

>>146
そりゃ大規模プログラムをメンテナンス性あげて作ろうとしたら
オブジェクト指向に限らず、考えなきゃいけないことだろな。

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

**デフォルトの名無しさん** · 2018/09/23(日) 01:13:41.68

>>147
いや俺の言う破綻てのは別にオブジェクトオンリーにこだわって
細かいとこをクロージャで逃げたり、その場しのぎ的に小さいオブジェクトで茶を濁すのもダメって意味じゃないんよ
小さいオブジェクトならオブジェクト同士やシステムが密結合になりえないだろうしな

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

**デフォルトの名無しさん** · 2018/09/23(日) 04:48:40.07

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

因果関係が逆

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 10:01:28.60

普通に組めばいいじゃん

**デフォルトの名無しさん** · 2018/09/23(日) 11:37:45.64

>>149
おまえめちゃめちゃバカやなw

**デフォルトの名無しさん** · 2018/09/23(日) 12:09:34.69

まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。
〜指向全般に言えるけれど、結局は一つの指標みたいなもんで
指標上げることが目的になったらクソになるのは当たり前だよね。

**デフォルトの名無しさん** · 2018/09/23(日) 12:29:12.02

バカすぎて意味がつながっとらんw

**デフォルトの名無しさん** · 2018/09/23(日) 15:43:38.58

オブジェクト指向に継承って要る？
もともとのオブジェクト指向の発想からすれば、別に無くてもいいっていうか、むしろ邪魔じゃね？

**デフォルトの名無しさん** · 2018/09/23(日) 16:17:15.71

>>154
継承でコードを書く量を減らせるってのはあるが、他の仕組みで代わりになるなら無くても良い

**デフォルトの名無しさん** · 2018/09/23(日) 16:31:30.62

ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ

**デフォルトの名無しさん** · 2018/09/23(日) 16:37:33.42

>>149
ちゃうねん

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 16:50:39.86

> 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。
前提が間違っているから話にならん。

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 17:11:55.75

>>158
オブジェクト指向言語の標準ライブラリとか1番破綻しないオブジェクト指向のパターンじゃないか？
そりゃ全てのオブジェクト指向で作った物が全て破綻することはないだろう

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 17:22:45.03

>>159
だからオブジェクト指向で小規模なものを作る例あげたじゃん。
馬鹿なの？

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

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 17:45:57.32

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

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

ｺﾝﾎﾟｼﾞｼｮﾝとﾒｯｾｰｼﾞｼｰｹﾝｽ、ｸﾗｽの階層(ここでの階層は>>101>>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ
ﾄﾞｷｭﾒﾝﾄで適切におさえることができる状態になっていれば
問題やｴﾝﾊﾝｽが発生しても持続可能対応できる

**デフォルトの名無しさん** · 2018/09/23(日) 19:29:44.09

オブジェクト指向にメリットなんて無いからね

**デフォルトの名無しさん** · 2018/09/23(日) 20:20:35.62

>>160
そりゃ作れないなんて言ってないがな。
「オブジェクト指向は大規模なモノを作る為だけにある」って話であって「オブジェクト指向は小規模なモノは絶対に作れない」とはならんからな

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 21:48:23.69

>>163
あー、わかったわかった、つまりこういうことだろ？

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 21:50:15.95

そう主張することで、飛行機の何を否定しているのかわからんのと
どうように、オブジェクト指向の何を否定しているのかわからんがなｗ

**デフォルトの名無しさん** · 2018/09/23(日) 21:51:15.19

おまえら破綻しすぎじゃね？w
どうやったらそんなに破綻を量産できんねんw

**デフォルトの名無しさん** · 2018/09/23(日) 22:02:41.85

>>164
オブジェクト指向の話で悪い例え話したら1番イカンやろ。抽象的なもんの取り扱いなんだから。しかも何言ってるかわからんけど多分それは違うしな

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

**デフォルトの名無しさん** · 2018/09/23(日) 22:26:37.81

>>167
> オブジェクト指向の話で悪い例え話したら1番イカンやろ。

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

**デフォルトの名無しさん** · 2018/09/23(日) 22:28:04.83

> しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する

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

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 22:42:45.15

>>169
>オブジェクト指向的破綻をするのはオブジェクト指向だけと
そういう事や。楽をするためにそれをするメリットが上回ってデメリットのが下回らなきゃいけないのはオブジェクト指向の完全必須項目なんだが
大規模複雑はこの完全必須項目がどんどん難易度が上がってくる。
途中の間違い失敗のリカバリのコストは確実にオブジェクト指向のが上

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

**デフォルトの名無しさん** · 2018/09/23(日) 23:17:04.84

>>170
ほらな。

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

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

**デフォルトの名無しさん** · 2018/09/23(日) 23:18:16.29

結局、小規模アプリでも大規模アプリでも
オブジェクト指向のほうが良いって結論なわけだよ。

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