目次 †
デザインパターン †
- パターンを使用する最良の方法は、パターンを頭の中にロードし、設計しているアプリケーションに対してそれらのパターンを適用できる箇所を認識することである。
- パターンではコードを再利用するのではなく、経験を再利用するのである。
- 矛盾しているようだが、直接変更することなくコードを拡張できるテクニックがある。
- すべての部分に解放・閉鎖原則を適用するのは無駄で不要なことであり、結果的に複雑で理解しにくいコードになってしまう可能性がある。
- コードは変更に対しては閉じており、拡張に対しては開いているべき。
- newを使うと、具象クラスをインスタンス化していることになる。
- インタフェースに対してコーディングすると将来システムに起こり得る多数の変更を分離できる。
- インタフェースに対してコードを記述すると、多態性によってそのコードはそのインタフェースを実装した任意の新しいクラスに対しても動作するからである。
- newを見たら、具象と考える。
- newを使うと、具象クラスをインスタンス化している。
- コードを具象クラスに結びつけると、より脆弱で柔軟でなくなる可能性があることに注意。
- 「MyInterface myClass = new MyClass();」のように型はインタフェースとなっているが、そこに格納されるのは具象クラスのインスタンスになる。
- アプリケーション内の変化する部分を特定し、不変な部分と分離する。
- 変化する部分を取り出し、それをカプセル化する。すると、その部分はコードのほかの部分に影響を及ぼさない。その結果、コード変更による予期せぬ結果が少なくなり、システムの柔軟性が向上する。
- 開発完了の前後のうちコードに対して多くの時間が費やされるのは、開発後である。
- 初期開発よりもソフトウェアの保守と変更の方が時間がかかる。
- パターンの根底にはいくつかのオブジェクト指向の原則があり、それらを知っていると問題に対応するパターンが見つからないときに役立つ。
- デザインパターンの多くはポリモフィズムの応用したものが多いため、ポリモフィズムの概念がしっかり理解しておく必要がある。
デザインパターンの意義 †
- より機能的かつスマートにシステムを構築できる可能性がある。
- オブジェクト（クラス）を効率よく再利用することができる。
- 個々のオブジェクトの再利用性だけを考えるのではなく、いくつかのオブジェクトを組み合わせた複合部品としての再利用性を考える。
- どのデザインパターンに当てはまるのかを検討し、適切なパターンをうまく応用することでシステムの設計・開発にかかることを削減できる。
- 複数人の開発者の間での意思疎通が楽になる。
- GoFのデザインパターンは、既存のパターンの中から代表的なものを選び出したものである。よって、GoFのデザインパターンという言葉が存在する前から、そのパターンは存在していた。しかし、その頃はパターンに名前がついていなかっため、漠然とした概念であったり、複数人の開発者の間でその概念を共有するのが難しかった。
パターンボキャブラリの効果 †
パターン用語は単なる専門用語以上の次のような効果がある。
- 共有されたパターンボキャブラリは強力である。
- パターン名だけでなく、そのパターンを表す特性・特徴・制約などの全体を伝えていることになる。
- パターンを使うと、より少ない言葉でより多くのことを言い表すことができる。
- 説明の際にパターンを使用すると、他の開発者はあなたの考えている設計を迅速かつ正確に理解できる。
- パターンレベルで話をすると、会話を設計レベルに長く留めることができる。
- すぐに実装の詳細レベルに話が落ちてしまうことを防ぐことができる。
- 共有ボキャブラリは開発チームの変化を促進することができる。
- デザインパターンによく精通したチームは誤解の余地を減らし、より迅速に変化できる。
- チームが設計の構想やパターンに関する経験を共有し始めると、パターンのユーザコミュニティを構築することになる。
- 共有ボキャブラリは初級開発者の上達を促進する。
- 初級開発者は経験のある開発者を尊敬する。上級開発者がデザインパターンを利用すると、初級開発者もデザインパターンを学習する気になる。
各デザインパターン †
- 生成に関するパターン：色々な用途にあったオブジェクトを生成してくれるパターン
- 構造に関するパターン：様々な問題を解決するべく考え出されたシステムを構成するためのパターン
- 振る舞いに関するパターン
その他のパターン †
- 建築パターン
- アプリケーションパターン
- システムレベルのアーキテクチャを作成するためのパターン。
- 多くの多層アーキテクチャはこのカテゴリに属する。
- 3層アーキテクチャ、クライアント・サーバーシステム、MVCなど
- ドメイン固有パターン
- 並列システムやリアルタイムシステムなどの特定ドメインの問題に関するパターン。
- J2EE
- ビジネスプロセスパターン
- 企業・顧客・データ間の相互関係を説明するもの。
- 意思決定とその伝達をいかに効率よく行うかといった問題に適用できる。
- 組織パターン
- ユーザインタフェースデザインパターン
- 対話的なソフトウェアプログラムをどのように設計するかという問題を解決する。
- レベルによる分類
- アーキテクチャパターン
- 最高レベル。
- アーキテクチャパターンとアーキテクチャスタイルはほぼ同義。
- デザインパターン（設計パターン）
- イディオム
パターン vs. アンチパターン †
- パターンがあってアンチパターンがないのでは完成しない。
- アンチパターンは常によい解決策に見えるが、それを適用すると悪い解決策になってしまう。
- アンチパターンは悪い解決策がなせ魅力的なのかを教えてくれる。
- アンチパターンはなぜその解決策が長期的にまずいかを示す。
- アンチパターンはよい解決策を提供する適用可能なほかのパターンを提案する。
| デザインパターン | 特定の状況で繰り返し起こる問題に対する一般的な解決策を提供する。 |
| アンチパターン | 問題に対する悪い解決策を導く方法を示す。 |
参考文献 †
