『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
The Dependency Inversion Principle この記事は The C++ Report に寄稿した私の Engineering Notebook の 3 つ目のコラムです。 このコラムでは C++と OOD の利用法に焦点を絞り、ソフトウェアエンジニアリングに
The Dependency Inversion Principle この記事は The C++ Report に寄稿した私の Engineering Notebook の 3 つ目のコラムです。 このコラムでは C++と OOD の利用法に焦点を絞り、ソフトウェアエンジニアリングにつ いて取り組んでいきます。記事は、できるだけ実用的で、すぐ役立つものになるよう努力 しようと思います。これらの記事の中では、 Booch と Rumbaugh の統一記法 (unified notation version 0.8)を使用します。下図はこの記法の簡単な例です。 導入 前回の記事では、Liskov Substitution Principle について紹介しました。この原則は C++ に適用したとき、 public な継承の使用方法の規範を与えるものでした。 この原則に従えば、 基本クラスの
依存関係逆転の原則（DIP） - Strategic Choice
依存関係逆転の原則（DIP:the Dependency Inversion Principle）上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきである。「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである。どういうこと？手続き型は「方針」が実装の「詳細」に依存する構造になってしまう。 方針が詳細の変更に影響されてしまう好ましくない構造。 OOプログラミングでは「方針」「詳細」とも抽象に依存させることで、悪しき依存関係を逆転できる。 なんで？アプリケーションの方針を決めていて、他に対して影響を与えるモジュール(＝言うなれば「偉い」ヒト)は上位。 上位が下位に依存してしまうと、上位が、下位の影響を受けてしまう。手続き型でよく見られた悪い依存関係。 筋的にはアプリケーションの存在理由である上位が下位に対して影響力を持つ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
