タグ

designとoopに関するa2ikmのブックマーク (6)

  • 俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - 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

    俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
  • デメテルの法則 - Wikipedia

    デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向プログラムにデメテルの法則を適用する場

  • インターフェイス志向設計を読んだメモ - voidy21の日記

    積読消化したい インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践 作者: Ken Pugh,角谷信太郎(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2008/05/24メディア: 大型購入: 16人 クリック: 337回この商品を含むブログ (66件) を見る 契約しようよ! 契約とは、 インターフェイスを実装するモジュールが守らなければならない(守るべき)約束 インターフェイスのユーザーと実装の間に成立する約束事 インターフェイスの三原則 1. インターフェイス実装は、そのメソッド名が示す通りの処理をしなければならない メソッド名から実装が行う処理が想像できるか メソッドの目的と意味合いがその名前と実装場所だけでは明確に連想できない場合、しっかりと文書化されてないといけない(テストにも言及した方がよい) 「インターフェイスの文書化はとても大切

    インターフェイス志向設計を読んだメモ - voidy21の日記
    a2ikm
    a2ikm 2011/04/30
    「インターフェイスのテストが困難→そのインターフェイスはとても使いづらい、設計し直すべき。一度決定すると変更しづらいから早めにテスト書かないと死ねる」
  • Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくか - 出町ミスド攻防記

    jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性 jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。 しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう? 大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVC」デザインパターンです。 MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られ

    Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくか - 出町ミスド攻防記
  • Martin Fowler's Bliki in Japanese - ドメインモデル貧血症

    http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基的な症状は、一見、それが物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな

    a2ikm
    a2ikm 2009/10/13
    アプリケーション層はビジネスのルールや状態に関しては関知しないが、処理の流れを制御する。ビジネスのルールや状態はドメイン層(モデル?)によって管理される。
  • 矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH(クロステック)

    今回は、パターンを1つだけ紹介します。「Mediatorパターン」です。GoFでは、それぞれのパターンの「目的]「背景」「効果」などが明示されています。私も、ちょっと真似をしてみましょう。複数のオブジェクトを組み合わせてプログラムの機能を実現するという目的において、オブジェクト間の関連がゴチャゴチャになってしまうという背景(問題)があり、Mediatorパターンの採用によって関連をキレイに整理できるという効果があります。説明だけでは、何のことだかわからないと思いますので、具体例をお見せしましょう。 図1[拡大表示](1)をご覧ください。これは、UML(Unified Modeling Language、ユーエムエル)と呼ばれる表記法で記述されたプログラムの設計図です。UMLでは、四角形の中に下線付きで名前を書いてオブジェクトを表し、関連のあるオブジェクトを矢印で結んで示します。ここで関連

    矢沢久雄の早わかりGoFデザインパターン(1) | 日経 xTECH(クロステック)
  • 1