ソフトウェア設計パターン

ソフトウェア工学において、ソフトウェア設計パターンまたはデザインパターンは、ソフトウェア設計の多くのコンテキストで一般的に発生する問題に対する一般的で再利用可能なソリューションです。^{[1]デザインパターンは、}ソースコードに直接移植される厳格な構造ではありません。むしろ、さまざまな状況で展開できる特定のタイプの問題を解決するための説明またはテンプレートです。^[2]デザインパターンは、プログラマがソフトウェアアプリケーションまたはシステムを設計するときに一般的な問題を解決するために使用できる 形式化されたベストプラクティスと見なすことができます。

オブジェクト指向設計パターンは、通常、クラスまたはオブジェクト間の関係と相互作用を示しますが、関係する最終的なアプリケーション クラスまたはオブジェクトは指定しません。 ^{[引用が必要]}可変状態を暗示するパターンは、関数型プログラミング言語には適さない場合があります。一部のパターンは、解決しようとしている問題を解決するためのサポートが組み込まれている言語では不要になる可能性があり、オブジェクト指向パターンは必ずしも非オブジェクト指向言語に適しているわけではありません。^{[引用が必要]}

デザインパターンは、プログラミングパラダイムのレベルと具体的なアルゴリズムの中間に位置する、コンピュータプログラミングに対する構造化されたアプローチと見なすことができます。^[要出典]

パターンは、1977 年にChristopher AlexanderがA Pattern Languageで建築概念として提唱した(彼の論文「The Pattern of Streets」、JOURNAL OF THE AIP、1966 年 9 月、第 32 巻、第 5 号、273 ～ 278 ページを参照)。1987 年、Kent BeckとWard Cunningham は、パターンをプログラミング (具体的にはパターン言語)に適用するアイデアの実験を開始し、その年のOOPSLAカンファレンスでその結果を発表しました。^{[3] [4]}その後数年間、Beck、Cunningham らがこの研究を続行しました。

デザイン パターンは、1994 年にいわゆる「Gang of Four」(Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides) によって出版された『Design Patterns: Elements of Reusable Object-Oriented Software』という書籍の後、コンピューターサイエンスで人気を博しました。この書籍は、しばしば「GoF」と略されます。同じ年に、最初のPattern Languages of Programming Conference が開催され、翌年には、デザイン パターンのドキュメント化のためにPortland Pattern Repositoryが設立されました。この用語の範囲は、依然として議論の的となっています。デザイン パターンのジャンルで注目すべき書籍には、 次のものがあります。

• ガンマ、エリック、ヘルム、リチャード、ジョンソン、ラルフ、ブリシデス、ジョン( 1994)。デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの要素。Addison - Wesley。ISBN 978-0-201-63361-0。
• Brinch Hansen, Per (1995)。計算科学の研究: 並列プログラミングパラダイム。Prentice Hall。ISBN 978-0-13-439324-7。
• ブッシュマン、フランク。ムニエ、レジーヌ。ローナート、ハンス。サマーラッド、ピーター (1996)。パターン指向ソフトウェア アーキテクチャ、第 1 巻: パターンのシステム。ジョン・ワイリー＆サンズ。ISBN 978-0-471-95869-7。
• Beck, Kent (1997)。Smalltalkベストプラクティスパターン。Prentice Hall。ISBN 978-0134769042。
• Schmidt, Douglas C. ; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000)。パターン指向ソフトウェアアーキテクチャ、第 2 巻: 並行オブジェクトとネットワークオブジェクトのパターン。John Wiley & Sons。ISBN 978-0-471-60695-6。
• Fowler, Martin (2002)。『エンタープライズ アプリケーション アーキテクチャのパターン』。Addison - Wesley。ISBN 978-0-321-12742-6。
• Hohpe, Gregor; Woolf, Bobby (2003)。 『エンタープライズ統合パターン: メッセージング ソリューションの設計、構築、展開』。Addison - Wesley。ISBN 978-0-321-20068-6。
• フリーマン、エリック T.、ロブソン、エリザベス、ベイツ、キャシー・シエラ(2004)。『Head First Design Patterns 』。オライリー メディア。ISBN 978-0-596-00712-6。
• ラーマン、クレイグ(2004)。UMLとパターンの適用 (第 3 版、第 1 版 1995)。ピアソン。ISBN 978-0131489066。

デザインパターンは長い間実用化されてきましたが、デザインパターンの概念の形式化は数年間停滞していました。^[5]

デザインパターンは、実証済みの開発パラダイムを提供することで、開発プロセスをスピードアップすることができます。^[6]効果的なソフトウェア設計には、実装の後半まで明らかにならない可能性のある問題を考慮する必要があります。書きたてのコードには、検出に時間のかかる隠れた微妙な問題が潜んでいることがよくあります。これらの問題は、後々大きな問題を引き起こすことがあります。デザインパターンを再利用すると、このような問題を防ぐことができ、^[7]パターンに精通している人にとってはコードの読みやすさが向上します。

ソフトウェア設計手法は、広範囲の問題に適用するのが困難です。^[要出典]設計パターンは、特定の問題に結び付けられた詳細を必要としない形式で 文書化された一般的なソリューションを提供します。

1996 年、Christopher Alexander は 1996 OOPSLA コンベンションに基調講演を行うよう招待されました。ここで彼は、アーキテクチャにおけるパターンに関する研究がどのように発展してきたかを振り返り、ソフトウェア デザイン コミュニティがアーキテクチャでパターンを拡張して、コンピューター コードに似た生成スキームを使用する生きた構造を作成するのにどのように役立つかについての希望を述べました。

パターンは、設計モチーフ、つまりプロトタイプのマイクロアーキテクチャを、プログラム構成要素 (クラス、メソッドなど) とその関係のセットとして記述します。開発者は、パターンで記述された問題を解決するために、モチーフをコードベースに適合させます。結果として得られるコードは、選択したモチーフに似た構造と構成を持ちます。

既存のデザインパターンやドメイン固有のデザインパターンの使用など、特定のドメインでデザインパターンを体系化する取り組みも行われてきました。例としては、ユーザーインターフェイスデザインパターン、^[8] 情報視覚化、^[9]セキュアデザイン、^[10]「セキュアユーザビリティ」、^[11] Webデザイン^[12]、ビジネスモデルデザインなどがあります。^[13]

毎年開催されるプログラミングパターン言語会議の議事録^[14]には、ドメイン固有のパターンの例が数多く含まれています。

オブジェクト指向設計パターンは、通常、クラスまたはオブジェクト間の関係と相互作用を示しますが、関係する最終的なアプリケーション クラスまたはオブジェクトは指定しません。可変状態を暗示するパターンは、関数型プログラミング言語には適さない場合があります。一部のパターンは、解決しようとしている問題を解決するためのサポートが組み込まれている言語では不要になる可能性があり、オブジェクト指向パターンは必ずしも非オブジェクト指向言語に適しているわけではありません。

デザイン パターンは、解決する問題の種類に基づいてグループ分けできます。作成パターンはオブジェクトを作成します。構造パターンはクラスとオブジェクトを整理して、新しい機能を提供するより大きな構造を形成します。動作パターンは、オブジェクト間の通信を提供し、これらのパターンを実現します。

デザインパターンのドキュメントでは、パターンが使用されるコンテキスト、そのコンテキスト内でパターンが解決しようとする力、および提案される解決策について説明します。^[27]デザインパターンをドキュメント化する単一の標準形式はありません。むしろ、さまざまなパターン作成者によってさまざまな形式が使用されてきました。ただし、Martin Fowlerによると、特定のパターン形式が他の形式よりもよく知られるようになり、その結果、新しいパターン作成作業の一般的な出発点になっています。^[28]よく使用されるドキュメント形式の 1 つの例は、Erich Gamma、Richard Helm、Ralph Johnson、およびJohn Vlissidesが著書Design Patternsで使用した形式です。次のセクションが含まれています。

• パターン名と分類:パターンを識別および参照するのに役立つ説明的で一意の名前。
• 意図:パターンの背後にある目標とそれを使用する理由の説明。
• 別名:パターンの別名。
• 動機 (力):問題と、このパターンを使用できるコンテキストで構成されるシナリオ。
• 適用性:このパターンが使用可能な状況、パターンのコンテキスト。
• 構造:パターンのグラフィカルな表現。クラス図や相互作用図がこの目的に使用される場合があります。
• 参加者:パターンで使用されるクラスとオブジェクト、および設計におけるそれらの役割のリスト。
• コラボレーション:パターン内で使用されるクラスとオブジェクトが相互に作用する方法の説明。
• 結果:パターンの使用によって生じる結果、副作用、トレードオフの説明。
• 実装:パターンの実装の説明。パターンのソリューション部分。
• サンプル コード:パターンをプログラミング言語でどのように使用できるかを示す図。
• 既知の使用法:パターンの実際の使用例。
• 関連パターン:パターンと何らかの関係がある他のパターン。パターンと類似のパターンの違いについての説明。

デザインパターンは、特定のプログラミング言語（たとえばJavaやC++ ）に機能が欠けていることの兆候かもしれないと示唆する人もいます。Peter Norvig は、デザインパターンの本（主に C++ に焦点を当てています）の 23 のパターンのうち 16 がLispまたはDylanでは（直接言語サポートによって）簡素化または削除されていることを示しています。^[29]関連する観察は、Hannemann と Kiczales によってなされました。彼らは、23 のデザインパターンのいくつかをアスペクト指向プログラミング言語（AspectJ）を使用して実装し、23 のデザインパターンのうち 17 の実装からコードレベルの依存関係が削除され、アスペクト指向プログラミングによってデザインパターンの実装が簡素化できることを示しました。^[30] Paul Graham のエッセイ「Revenge of the Nerds」 も参照してください。 ^[31]

パターンを不適切に使用すると、不必要に複雑さが増す可能性があります。^[32] FizzBu​​zzEnterpriseEditionは、デザインパターンによってもたらされる過度の複雑さの面白い例を示しています。^[33]

定義上、パターンはそれを使用する各アプリケーションに新たにプログラムされなければならない。一部の著者はこれをコンポーネントによって提供されるソフトウェアの再利用からの後退と見なしているため、研究者はパターンをコンポーネント化する作業を行ってきた。マイヤーとアーノウトは、試みたパターンの3分の2を完全にまたは部分的にコンポーネント化することができた。^[34]

柔軟性を実現するために、デザイン パターンでは間接レベルが追加されることがあります。これにより、結果として得られるデザインが複雑になり、実行時のパフォーマンスが低下する可能性があります。

ソフトウェア設計パターンは、ソフトウェアアーキテクチャパターンやソフトウェアアーキテクチャスタイルと比較して、より細かい粒度を提供します。これは、設計パターンが個々のコンポーネントまたはサブシステム内の詳細な低レベルの設計問題を解決することに重点を置いているためです。例としては、シングルトン、ファクトリーメソッド、オブザーバーなどがあります。^{[35] [36] [37]}

ソフトウェアアーキテクチャパターンとは、システムレベルで繰り返し発生する問題に対する再利用可能で実証済みのソリューションを指し、システムの全体的な構造、コンポーネントの相互作用、および品質特性に関連する懸念に対処します。^[要出典]ソフトウェアアーキテクチャパターンは、デザインパターンよりも高い抽象レベルで動作し、より広範なシステムレベルの課題を解決します。これらのパターンは通常、システムレベルの懸念に影響しますが、アーキテクチャパターンとアーキテクチャスタイルの区別が曖昧になることがあります。例としては、サーキットブレーカーなどがあります。^{[35] [36] [37]}

ソフトウェアアーキテクチャスタイルとは、システム全体の構成を定義する高レベルの構造組織を指し、コンポーネントの構成方法、相互作用の方法、相互作用の制約を指定します。^[要出典]アーキテクチャスタイルには通常、コンポーネントとコネクタの種類の語彙、およびシステムのプロパティを解釈するためのセマンティックモデルが含まれます。これらのスタイルは、システム構成の最も粗いレベルを表します。例としては、階層化アーキテクチャ、マイクロサービス、イベント駆動型アーキテクチャなどがあります。^{[35] [36] [37]}