依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
インターフェイス分離の原則（ISP） - Strategic Choice
インターフェイス分離の原則（ISP:the Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない。どういうこと？クライアントは複数のインターフェイスを利用するけど、そのすべてが互いに強い関連を持っているわけではない。すべてのインターフェイスを１つのクラスに押し込めてしまうことはやめ、関連性持ったインターフェイスはグループ化して、抽象基本クラスとして分けて利用すべき。なんで？「太った」（多機能な）インターフェイスがある。 あるクライアントはそのインターフェイスのすべてのメソッドを利用するわけではない。 クライアントが、そのような利用しないメソッドを含むインターフェイスに依存すると、クライアントはその自分に関係のないメソッドの変更の影響をうけていしまう。 他のクライアントがクラスに強いる変更によって、それ
リスコフの置換原則（LSP） - Strategic Choice
リスコフの置換原則（LSP:the Liskov Substitution Principle）派生型はその基本型と置換可能でなければならない。どういうこと？使う側から言うと、基本型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基本クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで？使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば？ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v
オープン・クローズドの原則（OCP） - Strategic Choice
オープン・クローズドの原則（OCP:the Open-Closed Principle）（開放−閉鎖原則） ソフトウェアの構成要素は、拡張に対して開いていて、修正に対して閉じていなければならない。どういうこと？オープン（開いている）とは？ モジュールの振る舞いを拡張できる。 クローズ（閉じている）とは？ モジュールの振る舞いを変更しても、そのソースやバイナリはまたく影響を受けない。 なんで？この原則はオブジェクト指向設計の核心。なぜなら、この原則に従えば、オブジェクト指向の最大のメリットを享受できる！ 柔軟性再利用性保守性たとえば？具体例として、よくある図形の例 。switch/caseで図形の種類ごとに処理を行う。 こうすると、図形の種類が追加になるたびにこの処理が変更になる。 ここで大事なのは、switch/caseがおそらく一箇所ではないところ。 至る所に図形の種類ごとの色々な処理が
単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
オブジェクト指向設計原則 - Strategic Choice
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則（SRP）オープン・クローズドの原則（OCP）リスコフの置換原則（LSP）依存関係逆転の原則（DIP）インターフェイス分離の原則（ISP）参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計＠Syboos.jpオブジェクト指向設計の原則＠それはBooksオブジェクト指向設計原則＠ディノオープンラボラトリオブジェクト指向の法則
イマドキのオブジェクト指向 (arclamp.jp アークランプ)
最近、改めてオブジェクト指向の説明というものを見直すことがあったのですが、出てきた結論としては「イマドキのオブジェクト指向」という形で再編集しても良いのではないかと。 先週の丸山先生レクチャーシリーズ2007-2008 第3回「SOAの現在」で発表した「メッセージ指向によるシステム開発の変化の兆し ～遍在するメッセージ指向～」は、その表れ。ウルの河村さんと話しているときに盛り上がって、そのまま形にしたものです。 では、「イマドキのオブジェクト指向」とは何か。それはメッセージ指向という解釈です。オブジェクト指向は「メッセージによる処理の分割」であり、「分離された処理をオブジェクトと呼ぶ」と定義します。これまではオブジェクト指向とは「オブジェクトによる処理の分離」であったわけです。 背景 現在、ソフトウェアを作る時に重要なのは「処理をいかに分離し、作業を分担するのか」ということです。これはプ
【レポート】Gavin King氏が語る"見えてきたWeb Beans" - JBoss COMPASS Tokyo (1) Web Beansとは? | エンタープライズ | マイコミジャーナル
Hibernateのファウンダーとして知られるGavin King氏。現在はRed HatにてJBossフェローを務める 18日、レッドハット主催による開発者向けイベント「JBoss COMPASS Tokyo」が開催された。同イベントの目玉は、HibernateやSeamといった"超メジャー"フレームワークの創設者であるGavin King氏によるテクニカルセッションである。同氏は基調講演にも登壇し、自身がスペックリードを務める「JSR 299 Web Beans」の紹介を行った。本稿では基調講演で同氏が語った情報をもとに、Web Beansの概要やメリットを簡単に説明したい。 Web Beansとは、Gavin King氏が開発を主導するアプリケーションフレームワーク「JBoss Seam」から着想を得て、現在JCP内で標準化が進められている仕様だ。Java EEの次期メジャーバージョ
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない！：selfup
オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IOS/Androidアプリの３つの大事な設計方針
大抵のシステムは、ドメインモデルになっている？？ - inabatchの日記