俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - 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
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
権限管理を実装するときの地味な話 - ✘╹◡╹✘
「あるユーザがXをYできるかどうか」というメソッドを定義したいとき、Userに実装するよりも、Xに実装した方がうまくいくことが多かった。例えば「ユーザが投稿を編集できるか」という、ブログの共同編集のような機能で使うやつで考える。つまり、User#can_edit?(entry) みたいなやつにするか Entry#editable_by?(user) みたいなやつにするかという話になる。 後者の方でうまくいった理由は、Webアプリだとログイン中のユーザが存在しない場合というのがあるが、後者ではuserがnilの場合でも対応できたというのと、Userクラスが長大にならなかったという点 (Abilityクラスとかを全ての場所で統一して使えている場合はそれで良いので各自適当にやっていってほしい)。あとメソッドの命名規則の問題があって、名詞形 (例:User#name) か、xxx?で終わるメソッド
（あなたの周りでも見かけるかもしれない）インスタンス変数の間違った使い方 - Qiita
（2021-8-28追記） この記事の改訂版を書いてみました。改訂版の方が易しい内容になっているので、プログラミング初心者の方はこちらを参考にしてみてください。 はじめに：「引数があるよりは、ない方が良い」？ 先日、同僚の西見さん（@mah_lab）がこんな技術ブログを書いていました。 インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） 同じ内容を僕だったらどういうふうに書くかな～？と思って、ちょっと書き始めてみたんですが、わかりやすく実践的な説明をするのは意外と難しく、内容も西見さんのブログとほぼ同じになりそうだったので、途中で断念しました。 というわけで、インスタンスメソッドとクラスメソッドの使い分けが未だにあやふやだという方は、ぜひ西見さんのブログを読んでみてください！ ・・・なんですが、1点だけ気になる点がありました。 それはインスタンスメソッ
オブジェクト指向プログラミング再入門
論文紹介：Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
- Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化，継
ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家（ドメインエキスパート）ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJava、C++、C#、Visual Basicといっ
オブジェクト指向分析/設計概論
1 はじめに Javaプログラミングを行っていくうえで、大きな関門となるのはオブジェクト指向分析/設計でしょう。「クラスとオブジェクトの違いは」といった初歩的なものから、「再利用性を高めるためのフレームワークとコンポーネントの責任の配分の度合」といった高度なものまで、Javaプログラミングの要諦(ようてい)はオブジェクト指向分析/設計との関係の中にあるに違いありません。 Javaプログラマという立場からオブジェクト指向分析/設計を取り巻く状況を整理してみるのが本稿の目的です。 業界標準のオブジェクト指向モデリング言語であるUMLと、代表的なオブジェクト指向分析/設計プロセスであるユニファイドプロセス、そして最近発展が著しいパターン技術をベースにJavaプログラマに取ってのオブジェクト指向分析・設計の枠組みを総括してみました。 2 オブジェクト指向とは何か オブジェクト指向といえばクラスやイ
インターフェイス分離の原則（ISP） - Strategic Choice
インターフェイス分離の原則（ISP:the Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。どういうこと？クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っているわけではない。すべてのインターフェイスを１つのクラスに押し込めてしまうことはやめ、関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。なんで？「太った」（多機能な）インターフェイスがある。 あるクライアントはそのインターフェイスのすべてのメソッドを利用するわけではない。 クライアントが、そのような利用しないメソッドを含むインターフェイスに依存すると、クライアントはその自分に関係のないメソッドの変更の影響をうけていしまう。 他のクライアントがクラスに強いる変更によって、それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
