オブジェクト指向ってクソじゃね？
■ このスレッドは過去ログ倉庫に格納されています
カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、 https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96 /** リストの要素をゼロで置き換える **/ >>68 >>69 構造化プログラムでゴトーが滅亡したようにオブジェクト指向にも構造化のブレイクスルーが生まれていい頃合いだと思うの オブジェクト指向って簡単な処理先に書いて難しい処理は後回しにする考え方でしょ >>75 インターフェースを切って実装を分離することを言ってるんじゃないか？ そもそも、継承関係で隠蔽しちゃい合うのが問題なだけで、 >>70 >>75 >>79 責務ごとにクラスを作るのがどうして主流だよね？ってことですよ >>81 >>82 >>83 ボトムアップで設計したら結局最上位クラスが神クラス化しちゃうのは、アプリ層の設計が甘いんかな？ >>84 ドメインオブジェクトがドメインとしての振る舞いを持つのですから肥大化とは言いません、データと関わりのない振る舞いを持つわけではないんです >>85 >>86 >>87 >>89 データに対する振る舞いが集まるんだから凝集度は高まるんです オブジェクトが何かを考えないと行数で判断するという 皆が言ってることはもちろん分かる。 >>93 >>90 >>91 >>83 >>92 >>93 つか、ワンオブジェクトワンファイルなんてルールは無いから。 このｽﾚにいるような池沼が作らなければ クラスに階層があるなんて寝言は寝て言うべきだと思うの このクラスの責務は行数を減らす事ですとか上記の沙汰じゃないやろ 当然、低ﾚﾍﾞﾙな部分を実現するｸﾗｽﾗｲﾌﾞﾗﾘと >>99 >>100 × このクラスの責務は行数を減らす事です >70のサイト読んでると 責務とｱﾎみたいなこといってるわ 例えば扱うﾋﾞｼﾞﾈｽの領域が違えば というわけでな あ、ｵﾏｴは刺身の醤油入れに醤油つめる作業だったか >>106 >>112 Inversion of Controlパターンでコンポーネント間の結びつきを弱める：CodeZine（コードジン） https://codezine.jp/article/detail/60 ただのﾘﾌﾚｸｼｮﾝやんけ ×結びつきを弱める 何もしないだと・・・ いちいちﾀﾝﾎﾟﾎﾟ載せてる作業経過報告はいらない DBのテーブル数や列数が少なくて >>122 >>122 >オブジェクト指向ってファイル間の関連性追ったり、 オブジェクト指向がよくわからんド素人俺にはlinqは感動した。 >>128 >>125 >>134 俺が知ってる情報は次の２つだ >>133-135 はそのバカに属する >>136 オブジェクト指向は複雑な構造を構築するわけだから オブジェクト指向の弱点はクラスとクラス間の関係を設計しないといけないこと 小規模ならいいが大規模だと設計必須 クラスの関係の設計を軽減するためにクラスには最低限の機能しか実装しないようになっていく つまりクラス間の関係を排除して、Mix-inだけできるようになればいいのかな >>140 https://techracho.bpsinc.jp/hachi8833/2018_01_29/51135 >>142 >>142 のどこに限界や弊害が書いてあるの？ >>145 >>146 >>147 > オブジェクト指向の問題や破綻てのはやはし密結合の時にだけ起こるな まあオブジェクト指向は密結合を観察する際の一つの指針にはなるかな。 オブジェクト指向に継承って要る？ >>154 ああでもルートクラスのメソッドを全部で使えるってのはでかいかなあ >>149 > 何故ならオブジェクト指向そのものが大規模で複雑なモノを作るため”だけ”の物だからよ。 >>158 >>159 この原則さえ守れば破綻は回避できる >>101 >>106の意味)のｸﾗｽが上位階層のｸﾗｽのｲﾝﾀｰﾌｪｰｽに絶対に直接ｱｸｾｽしてはいけない >>101 >>106の意味)、ｲﾝｽﾀﾝｽの生存期間さえ >>160 >>163 そう主張することで、飛行機の何を否定しているのかわからんのと おまえら破綻しすぎじゃね？w >>164 >>166 >>167 > しかも間違い失敗のリカバリーはオブジェクト指向のメリットの規制隠蔽が裏目に出てより悪化する >>169 ■ このスレッドは過去ログ倉庫に格納されています
