オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。
偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。
一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。
オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。
https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 >>1
ケイちゃんの言うレシーバオブジェクトは
ネットワーク越しにアクセスできるコンピュータだから
プライベートのキーワードはなくても
必然的にプライベートになるんじゃないかな 砂糖(シンタックスシュガー)を加えて関数型言語っぽくしているが、臭いまではごまかせない オブジェクト指向が無くなった場合
メソッドは全部グローバル関数になるの？
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(); 訂正
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(); 文系がこねくり回して、結果的に無駄にコード量増やすようなイメージしかない。 カプセル化が原因で開発ができなくなるとするならオブジェクトの分け方が不適切なのだろ、開発が進むに連れてオブジェクトの役割が変遷したのだろ、設計やり直せないなら地獄だな 設計のないスタティックおじさん方式は柔軟かもわからんね↓ >>61
正しく組めば重複が減ってコード量は減る
>>64
普通はカプセル化しないことで
開発できなくなることの方が多い
グローバル変数を使うとか オブジェクト指向で描くロバストネス図なんてのは
構造化プログラミングの前のフローチャートそのものじゃないか
オブジェクト指向は現代のGOTO文なんだろ？ >>67
https://thinkit.co.jp/article/13487
> ロバストネス図を書くにあたっては、以下のルールを遵守する必要があります。
>
> ・アクターはバウンダリのみ関連線（矢印）が引ける
> ・バウンダリはコントロールとアクターのみ関連線が引ける
> ・エンティティはコントロールのみ関連線が引ける
> ・コントロールはコントロール同士とバウンダリのみ関連線が引ける
残念ながらフロー（流れ）を示す線は書けないので
フローチャートにはならない。特に条件分岐やループなどがない >>67
どちらかというとロバストネス図は
ユースケース図の方が近くて
フローチャートと同じってのはおかしい /** リストの要素をゼロで置き換える **/
private void clearList() {
for (Integer el : someList) {
el = new Integer(0);
}
}
なかなかファンキーなロケンロールだぜ >>68
条件分岐はあるで
ループもあるで
GOTOだからわかりにくいけど
線はフローを表すんやで
ロバストネスエアプか？ >>69
ユースケース図はユースケースを並べたものですよね
ロバストネスはユースケースごとに処理フローを
書くわけでフローチャートそのものですよ 構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ >>75
違うけど、意味がわからないから例をあげてみて
「簡単な処理」とは何かライブラリを使えば難しい処理は簡単な処理とみなせるのか？ インターフェースを切って実装を分離することを言ってるんじゃないか？ そもそも、継承関係で隠蔽しちゃい合うのが問題なだけで、
インスタンス握り合うだけの仲なら、相手の陰部まで見に行く必要性なんて無いだろ。 >>70
そのサイトには賛成できる部分と反対の部分がある
「クラスとはデータ構造」で
「責務はクラスではない」というのには大反対
クラスは責務そのものという方が
オブジェクト指向の主流の教え方 >>75
当たってる部分がなくもないけど
たんに関数に分割するんじゃなくて
抽象化するのがオブジェクト指向 >>79
ゴトーが主流の時代もあったわけで
主流じゃないからという理由で反対するのは
いけないことだと思います！ 責務ごとにクラスを作るのがどうして主流だよね？ってことですよ >>81
それもそうか
>>82
変更コストが下がるから
>>83
いやむしろ凝集度は上がるよ？
凝集度を上げるっていうのは
でかいクラスを作ることじゃないよ？ ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？
どうもUI部の設計は苦手だ。 >>84
データに関わる処理を一箇所に集められますよ
凝集度は高くなります ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです >>85
肥大化するのが設計が甘いと言われればその通りでしょ
ただ最初から一発で分からないことも多いので
リファクタリングするのも大事だと思う >>86
＞データに関わる処理を一箇所に
複数のデータの処理を一箇所でやるという意味なら
凝集度は下がる
>>87
ドメインオブジェクトの数が増えていくのは普通だが
1オブジェクトの行数が増えていくのは肥大化 >>89
そんなバカな
行数でオブジェクトを捉えるべきじゃない
振る舞いがどこにあるべきかで考えないと
行数が増えたからオブジェクト分けましょうなんてのは
オブジェクト指向の理念に反する
データをカプセル化してデータに対する責務を持つのが
オブジェクトなんだよ データに対する振る舞いが集まるんだから凝集度は高まるんです オブジェクトが何かを考えないと行数で判断するという
前世紀のような事が起こるわけです
行数が多いからこのオブジェクトは頑張ってるんだな
と思ってしまうわけです
大きな間違いです、オブジェクト指向の根幹はカプセル化です
次に多態性、オブジェクトに適切なフルマがあって初めて
多態性を実現できます 皆が言ってることはもちろん分かる。
分かった上でViewのコートが大きくなりすぎて例えばC#ならついついpartial使ってファイル分けちゃう。
MVVMでも結局はViewか大きくなっちゃう。
いや、分かるよ。俺がViewの設計が下手っぴなのは認める。 >>93
ごめん、間違えた。
肥大化するのはViewじゃなくってViewModelだわ。 >>90
もちろん行数は目安でしかない
責務ごとにクラスを作るのが本筋
>>91
>>83
別人の発言かもしれないがこの発言の関係に疑問が残る
責務ごとにクラスを作ることで凝集度が上がるのであって
複数の責務をひとつのクラスに混ぜたら凝集度は下がるよ >>92
もちろん行数は目安でしかないが
行数が増えすぎたときに
リファクタリングするのは実践的には大事
>>93
大きくなったら分割するのは何も悪くない
全体の規模が大きくなっていく時に
ひとつのクラスの行数が増えるのが肥大化
クラス数を増やしていくのが正しいOOP つか、ワンオブジェクトワンファイルなんてルールは無いから。 このｽﾚにいるような池沼が作らなければ
ｸﾗｽﾗｲﾌﾞﾗﾘも階層や種類で作るからな
低い階層に行けばいくほど単純な簡単な機能を提供するｸﾗｽになる
階層は完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
そして明確に種類の異なるﾌﾟﾘﾐﾃｨﾌﾞがある場合は
ﾗｲﾌﾞﾗﾘを完全に分離させて独立したﾗｲﾌﾞﾗﾘにする
その上にｱﾌﾟﾘｹｰｼｮﾝを実現するｸﾗｽ群がのっかる
低学歴知恵遅れが作るとすべて同じ階層で同じ種類になる クラスに階層があるなんて寝言は寝て言うべきだと思うの このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ 当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘと
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群は
ｼﾛｳﾄでもないかぎり完全に分離するからな
低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘは
当然、中間層のｸﾗｽﾗｲﾌﾞﾗﾘやｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を
参照することはまずない
ｱﾌﾟﾘｹｰｼｮﾝが主に利用する中間層のｸﾗｽﾗｲﾌﾞﾗﾘは
ｱﾌﾟﾘｹｰｼｮﾝ自体を記述するｸﾗｽ群を参照することはまずない
低学歴知恵遅れが作ると酷い依存関係ができる
ｺﾚはｵﾌﾞｼﾞｪｸﾄ指向関係なくﾗｲﾌﾞﾗﾘの基本だからな >>99
継承はクラス間の階層構造だろ？
>>100
行数だけの問題じゃないけど
プログラムを単純化するために
間接的なクラスを作ることはあるぞ？ × このクラスの責務は行数を減らす事です
○ fooクラスに別のクラスに責務を分離できる処理を見つけたので分離しました。
その結果fooクラスの行数が減りました。
「行数を減らす」は「責務」ではない。「責務」を分離することで
得られる結果（メリット）の一つだ >70のサイト読んでると
プログラミングでどの様にしてプログラミングするか
というのと
実際のシステム要件なんかからどうやって設計するか
というのがごっちゃに書かれている感じがする 責務とｱﾎみたいなこといってるわ
組織でたとえるならこうなるからな
経営者ｸﾗｽ 社員をこき使う
↓
社員ｸﾗｽ ← 派遣をこき使う（職階ごとの複数の中間層）
↓
派遣ｸﾗｽ ← ｷﾐﾗが担当するような低ﾚﾍﾞﾙな部分の単純作業（つまりｷﾐﾗ）
派遣は社員の作業も役員の作業もしない
社員は役員の作業はしない
行数が多いのは
作業を整理して作業を手順化して
派遣にうまく単純作業を割り当てれてないのと同じだからな
つまり、人に仕事させないと自分の作業が増える
ｷﾐﾗは派遣だからな、そういう作業はできないのは分かる
作業ﾐｽ（例外）が発生してｽﾙｰし続けてたら上までいくからな 例えば扱うﾋﾞｼﾞﾈｽの領域が違えば
部門を分けることになる
会社に複数の部門があっても一つの会社だからな
種類で分けるというのはそういうことになる
ｷﾐﾗみたいな一種類の単純作業しかしてないﾔﾂﾗには関係ない ■ このスレッドは過去ログ倉庫に格納されています
