2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
オブジェクト指向は必要なのか / Is object-oriented needed?
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
オブジェクト指向の欠点をカバーする努力 - Qiita
オブジェクト指向の問題点 インターネッツを良くするポエムというのは、「こういう問題に対して、こういうソリューションでカバーしてきたよ」をみんなでシェアすることだと思うので、ここに挙げられていることの一部に対して、オブジェクト指向界隈が今までこんな工夫をしてきたよとか、僕の目から見えている「技術発展の流れ」について書いてみようと思います。まあ僕も全ジャンルをまんべんなくやっているわけじゃないし、一部想像で補っている部分もあります。他にもあればぜひシェアしてください！ 上記のサイトで書かれている内容のうち、 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 関係性が表現できない ユーザレベルでの部品化再利用に全然なっていない について取り扱います。 オブジェクトのつながり具合が手続きでしか表現できない/知識表現が手続き側に偏っている 元は2項目ですが、内容的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向のその前に-凝集度と結合度/Coheision-Coupling