デザインパターン
GoFのデザインパターン
俯瞰してわかりやすい
http://d.hatena.ne.jp/language_and_engineering/20120330/p1
コード例がある
http://www.happiese.com/system/dpattern.html
矢沢久雄 - 簡単に説明コードも乗っている
http://itpro.nikkeibp.co.jp/article/COLUMN/20051123/225074/
デザインパターン一覧
名前 | 問題 | 解決策 | メリット |
Layers | 関心の分離。変更範囲の局所化。システム要素の交換、再利用。作業範囲の明確化。 | システムを階層化された複数のレイヤに分割する。 | |
Layers | 関心の分離。変更範囲の局所化。システム要素の交換、再利用。作業範囲の明確化。 | システムを階層化された複数のレイヤに分割する。 | |
MVC(Model-View-Controller) | ユーザインターフェースの仕様変更による影響を局所化する。ひとつのデータを複数の形式で表示、データに対する変更を即時に画面に反映する。 | システムをModel、View、Controllerに分割。ModelからViewへの更新伝搬メカニズム | |
DTO(Data Transfer Object) | リモート呼び出しの回数の削減。 | データ転送専用のオブジェクトを用意する。 | |
Page Controller | 動的にHTMLページを生成するために、シンプルなコントローラが必要。 | リクエストを処理するコントローラをページごとに用意する。 | |
Template View | HTMLページ中に静的な部分と動的に変更したい部分が混在している。 | HTMLページに特別なマークを埋め込み、マーク部分を動的に置換する。 | |
Front Controller | 複数のリクエストに共通する処理が分散してしまう。 | 全てのリクエストの入り口となるコントローラ。 | |
Application Controller | 処理の実行や画面遷移制御が複雑なためFront Controllerが肥大化する。 | 処理実行や画面遷移制御を担当するコントローラ。 | 集中して管理ができる。すべてのリクエストをFront Controllerに受け取っているため、認証、セッション管理などの共通処理を一元管理することができます。 保守性と拡張性の向上。 |
Intercepter Filter | リクエストやレスポンスに対して前処理や後処理が必要。前処理、後処理を簡単に追加、削除したい | プラガブルなフィルタをチェインできるメカニズム。 | ・再利用性の向上。個々のフィルタは完全に独立しているので、再利用をしやすくなります。 ・拡張性の向上。各機能の変更がそれに関連するフィルタだけを修正すればよい、他のリソースを修正する必要がありません。また、機能の追加にも新しいフィルタを追加するだけで済みことになります。 ・保守性の向上。設定ファイルの設定により、簡単にフィルタを追加したり、削除したりすることができますので、保守しやすくなります。 |
View Helper | JSPのようなテンプレートベースのビューに処理ロジックが混入する。 | 処理ロジックを隠蔽するためのヘルパークラスを導入する。 | ・役割の分離。 ・システムのモジュール化。 |
Session Facade | たくさんの小さなコンポーネントによって、性能ネック、複雑化、重複コード、トランザクション管理の分散が発生してしまう。 | 窓口（facade）となるSession Beanを配置する。また、ビジネスオブジェクトを管理し、クライアントに対して一貫した粗粒度のサービス単位を提供する。 | ・低結合度。クライアントとの依存関係を低くなり、低結合度を実現できます。 ・簡素化。クライアントに対して一貫した粗粒度のサービス単位を提供するため、容易に利用できるようになります。 ・性能向上。クライアントからのEJB呼び出し回数が減り、性能ネックとなるネットワークのトラフィックを減少することで、性能向上します。 ・トランザクションの一元管理。粗粒度のSession Façadeにトランザクションを集中して管理できます。 |
Data Access Object | ・永続的なデータへの依存。各コンポーネントは、永続的なデータのAPI実装戦略に依存してしまいます。結果として、複数の永続的なデータをサポートするには、非常に困難であり、変更にもほぼ不可能になります。 ・重複コード。重複コードが発生してしまいます。 ・複雑化。永続的なデータへのアクセスは、統一したインタフェースがなく、使いづらくなります。 | データソースへのアクセスをData Access Object (DAO)によって抽象化及びカプセル化します。DAOクラスはデータソースへの接続やデータの保存などを管理します。 | ・データソースの隠蔽。統一したインタフェースを提供することで、ビジネスオブジェクトはデータソースを透過的に扱うことができます。 ・複数のデータソースをサポートすることが可能になります。 ・簡素化。ビジネスオブジェクトは、統一したインタフェースを利用して簡単にデータソースを利用可能になります。 ・データソースへのアクセスの集中管理。 |
Business Delegate | ・密な結合度。ビジネス層のインタフェースを多くのプレゼンテーション層に見えてしまい、密な結合度になってしまいます。 ※結合度が低いほどモジュールの安定性が強い ・性能低下。リモートコールによるビジネスロジック層の多くのコンポーネントとのやり取りでネットワークに加担してしまい、性能に低下する恐れがあります。 ・複雑化。一つの業務を遂行するのに、大量な呼び出しをしてしまい、その結果システムが複雑になってしまいます。 ・重複コード。ビジネスロジック層のコンポーネントとのやり取りを各プレゼンテーションのコンポーネントに分散してしまうため、コードの重複が発生します。 | Business Delegateを利用し、プレゼンテーション層とビジネスサービス間の結合度を減らします。Business Delegateはビジネスサービスの実装の詳細、例えばEJBアーキテクチャの詳細や、それにlookup／アクセスするための具体的な方法などを隠蔽します。 | ・疎結合度の実現。Business Delegateはビジネスサービスの実装の詳細を隠蔽し、プレゼンテーション層はBusiness Delegateを経由でビジネスサービスを透過的にアクセスできます。 ・集中管理。プレゼンテーション層はビジネスサービスへの呼び出しはBusiness Delegateに集中して管理できます。ロジックが変化しても、Delegate Businessを修正するだけでよい。 ・エラー・異常の検知・管理。Delegate Businessはビジネスサービスの異常を検知（catch）し、プレゼンテーション層に容易に理解できるビジネス異常を変換することができます。・共通する処理の行う。Delegate Businessはアクセスの集中管理することで、キャッシュなどの共通する処理を行うことができます。 ・インタフェースの簡素化。プレゼンテーション層に簡単なインタフェースを提供することが可能です。 |
Dispatcher View | Front ControllerパターンとView Helperパターンを用いたWEBアプリケーションでは、Front Controllerはリクエストを集中管理する役割を果たし、ビューのナビゲーション、認証、セッション管理などの共通処理を行います。 | コントローラ、ディスパッチャとビューや、ヘルパーを組み合わせてクライアントからのリクエストを処理し、ダイナミックなプレゼンテーションをレスポンスします。 ・コンテンツの取得はビューを処理するまで遅延されますので、コントローラは、コンテンツの取得をヘルパーに委譲しません。 ・ディスパッチャはビューの管理やナビゲーションなどの責務を持ちます。 ・ディスパッチャはコントローラや、ビューの内部で実装するか、独立なコンポーネントとして実装することができます。 | |
Service to Worker | Front ControllerパターンとView Helperパターンを用いたWEBアプリケーションでは、Front Controllerはリクエストを集中管理する役割を果たし、ビューのナビゲーション、認証、セッション管理などの共通処理を行います。 | コントローラ、ディスパッチャとビューや、ヘルパーを組み合わせてクライアントからのリクエストを処理し、ダイナミックなプレゼンテーションをレスポンスします。 ・コントローラはコンテンツの取得（content retrieval）をビューの表示用データを保持するためのヘルパーに委譲します。 ※この点について、Dispatcher Viewと異なりますので、ご注意ください。Dispatcher Viewでは、コンテンツの取得はビューを処理するまで遅延されますので、コントローラは、コンテンツの取得をヘルパーに委譲しません。 ・ディスパッチャはビューの管理やナビゲーションなどの責務を持ちます。 ・ディスパッチャはコントローラの内部で実装するか、独立なコンポーネントとして実装することができます。 | |
Composite View（複合ビュー） | 多くのWEBアプリケーションでは、すべてのページ対しても例えばヘッダ（ナビゲーション、メニューなど）、フッタなどの変わらない部分を持つことが一般的です。 ・重複コードの発生。全く同じである「変わらない部分」のコードを各ページに重複して記述しなければなりません。 ・保守・拡張しにくい。例えば一つを修正しても、すべてのページへの修正を加えなければなりません。 | 複数の原子的なサブビューから構成された複合ビューを使用します。各サブビューは、一つのページに動的に含まれ、また、ページレイアウトはコンテンツと別に管理します。 |
http://www.syboos.jp/sysdesign/category/20080607212022699.html
アーキテクチャ・パターン
Layers
Pipes and Filters
Blackboard
Broker
MVC (Model-View-Controller)
PAC (Presentation-Abstraction-Control)
Microkernel
Reflection
Layersの例
ネットワークプロトコルのOSI 参照モデル
項目 | 説明 |
アプリケーション | アプリケーションプログラム間の通信 |
プレゼンテーション | 圧縮やデータフォーマットの変換 |
セッション | セッションの確立 |
トランスポート | ホスト間の信頼性のある通信 |
ネットワーク | 経路制御 |
データリンク | 物理レイヤにおけるデータ転送の信頼性保証 |
物理 | 電気信号の変換 |
クライアント/サーバ
項目 | 説明 |
クライアント | ユーザインターフェースとアプリケーション |
サーバ | データベース |
J2EEの基本3レイヤ
項目 | 説明 |
プレゼンテーション | 表示やユーザ入力 |
ドメイン | システムの中核ロジック |
データソース | データベースや他システムとのコミュニケーション |
Core J2EEパターンのレイヤ
項目 | 対応 |
クライアント（Webブラウザ、アプレット） | プレゼンテーション |
プレゼンテーション（サーブレット、JSP） | プレゼンテーション |
ビジネス（EJB、Business Object） | サービス |
ビジネス（EJB、Business Object） | ドメイン |
インテグレーション（JDBC、JMS） | データソース |
リソース（データベース、外部システム） |
EJBパターンのレイヤ
項目 | 対応 |
プレゼンテーション（JSP、HTML、JavaScript） | プレゼンテーション |
アプリケーション（サーブレット） | プレゼンテーション |
サービス（Session Bean） | サービス |
ドメイン（Entity Bean、POJO） | ドメイン |
永続化（Entity Bean、O/R Mapper） | データソース |
DTOのバリエーション
• Domain Data Transfer Object
ドメインオブジェクトのコピー。
• Custom Data Transfer Object
ドメインオブジェクトのデータを必要に応じ再構成。
• Data Transfer HashMap
HashMapを使いデータを転送
• Data Transfer RowSet
RowSetを使いデータを転送。
Last updated
