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

ソフトウェア設計パターンは、ソフトウェアにおいて一般的に必要とされる動作に対する再利用可能なソリューションを記述するものです。[ 1 ]設計パターンは、ソースコードに直接コピーできるような厳格な構造ではありません。むしろ、特定の種類の問題を解決するための記述であり、テンプレートであり、様々なプログラミング言語やコンピューティングプラットフォームを含む、様々なコンテキストで使用できます。[ 2 ]設計パターンは、プログラマがソフトウェア設計時に一般的な問題を解決するために使用できる、形式化されたベストプラクティスと見なすことができます。

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

歴史

パターンは、1977年にクリストファー・アレキサンダーが『パターン・ランゲージ』の中で建築概念として提唱した概念です（彼の論文「街路のパターン」、JOURNAL OF THE AIP、1966年9月、第32巻第5号、273～278ページ参照）。1987年、ケント・ベックとウォード・カニンガムは、プログラミング、特にパターン言語にパターンを適用するというアイデアの実験を始め、その年のOOPSLAカンファレンスでその成果を発表しました。[ 3 ] [ 4 ]その後も、ベック、カニンガムをはじめとする研究者たちがこの研究を継続しました。

デザインパターンは、1994年にいわゆる「Gang of Four」（エリック・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシデス）によって『デザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素』が出版された後、コンピュータサイエンスの分野で人気を博しました。このグループはしばしば「GoF」と略されます。同年、最初のPattern Languages of Programming Conferenceが開催され、翌年にはデザインパターンのドキュメント化のためにPortland Pattern Repositoryが設立されました。

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

練習する

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

ソフトウェア設計技術は、より広範な問題に適用することが困難です。デザインパターンは、特定の問題に結び付けられた詳細な情報を必要としない形式で文書化された、一般的な解決策を提供します。

1996年、クリストファー・アレクサンダーは1996年OOPSLA大会の基調講演に招かれました。彼はここで、建築におけるパターンに関する研究の発展を振り返り、ソフトウェアデザインコミュニティが建築におけるパターンの拡張を支援し、コンピュータコードのような生成スキームを用いた生きた構造を生み出すことへの期待を語りました。

モチーフ

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

ドメイン固有のパターン

特定の分野におけるデザインパターンの体系化も進められており、既存のデザインパターンの利用だけでなく、分野固有のデザインパターンも活用されています。例としては、ユーザーインターフェースデザインパターン、[ 8 ]情報視覚化、[ 9 ]セキュアデザイン、[ 10 ]「セキュアユーザビリティ」、[ 11 ]ウェブデザイン[ 12 ]、ビジネスモデルデザイン[ 13 ]などが挙げられます。

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

オブジェクト指向プログラミング

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

例

デザインパターンは、解決する問題の種類に基づいてグループ分けできます。

創造的

作成パターンはオブジェクトを作成します。

名前 説明 デザインパターンコードコンプリート[ 15 ]他の
抽象ファクトリー具体的なクラスを指定せずに、関連オブジェクトまたは依存オブジェクトの ファミリを作成するためのインターフェイスを提供します。はい はい 該当なし
ビルダー複雑なオブジェクトの構築とその表現を分離し、同じ構築プロセスでさまざまな表現を作成できるようにします。 はい はい 該当なし
依存性注入クラスは、オブジェクトを直接作成するのではなく、インジェクターから必要なオブジェクトを受け入れます。 該当なしはい 該当なし
ファクトリーメソッド単一のオブジェクトを作成するためのインターフェースを定義しますが、どのクラスをインスタンス化するかはサブクラスが決定します。ファクトリーメソッドを使用すると、クラスのインスタンス化をサブクラスに委ねることができます。 はい はい 該当なし
遅延初期化オブジェクトの作成、値の計算、その他の高負荷な処理を、実際に必要になるまで遅延させる戦略。このパターンは、GoFカタログでは「仮想プロキシ」として記載されており、Proxyパターンの実装戦略の一つです。 はい はい インド洋沿岸警備隊[ 16 ]
マルチトンクラスには名前付きインスタンスのみが含まれるようにし、それらへのグローバル アクセス ポイントを提供します。 はい はい はい
オブジェクトプール使用されなくなったオブジェクトをリサイクルすることで、コストのかかるリソースの取得と解放を回避します。これは、接続プールとスレッドプールのパターンを一般化したものと考えることができます。 はい はい はい
プロトタイププロトタイプインスタンスを使用して作成するオブジェクトの種類を指定し、既存のオブジェクトの「スケルトン」から新しいオブジェクトを作成することで、パフォーマンスを向上させ、メモリフットプリントを最小限に抑えます。 はい はい はい
リソース取得は初期化です（RAII） リソースを適切なオブジェクトの有効期間に結び付けて、リソースが適切に解放されるようにします。 はい はい はい
シングルトンクラスにインスタンスが 1 つだけあることを確認し、そのインスタンスへのグローバル アクセス ポイントを提供します。 はい はい はい

構造的

構造パターンは、クラスとオブジェクトを整理して、新しい機能を提供するより大きな構造を形成します。

名前 説明 デザインパターンコードコンプリート[ 15 ]他の
アダプタ、ラッパー、またはトランスレータ クラスのインターフェースを、クライアントが期待する別のインターフェースに変換します。アダプターは、インターフェースの互換性がないために連携できなかったクラス間の連携を可能にします。エンタープライズ統合パターンにおける同等の機能は、トランスレーターです。 はい はい はい
橋抽象化とその実装を分離して、2 つが独立して変化できるようにします。 はい はい はい
複合オブジェクトをツリー構造に構成し、部分と全体の階層構造を表現します。Composite により、クライアントは個々のオブジェクトとオブジェクトの組み合わせを統一的に扱うことができます。 はい はい はい
デコレーターインターフェースを維持しながら、オブジェクトに動的に追加の責任を付与します。デコレータは、サブクラス化に代わる柔軟な機能拡張方法を提供します。 はい はい はい
委任クラスをサブクラス化するのではなく、コンポジションによって拡張します。オブジェクトは、リクエストを別のオブジェクト（デリゲート）に委譲することで処理します。 はい はい はい
拡張オブジェクト 階層を変更せずに階層に機能を追加します。 はい はい はい
ファサードサブシステム内のインターフェースセットに統一されたインターフェースを提供します。Facade は、サブシステムを使いやすくする高レベルのインターフェースを定義します。 はい はい はい
フライ級共有を使用して、多数の類似オブジェクトを効率的にサポートします。 はい はい はい
フロントコントローラーこのパターンはWebアプリケーションの設計に関連し、リクエストを処理するための集中化されたエントリポイントを提供します。 はい はい

J2EEパターン[ 17 ] PoEAA [ 18 ]

マーカーメタデータをクラスに関連付ける空のインターフェース。 はい はい 効果的なJava [ 19 ]
モジュールグローバルに使用されるクラス、シングルトン、メソッドなどの複数の関連要素を 1 つの概念エンティティにグループ化します。 はい はい はい
プロキシ別のオブジェクトの代理またはプレースホルダーを提供して、そのオブジェクトへのアクセスを制御します。 はい はい はい
双子[ 20 ]Twin を使用すると、この機能をサポートしていないプログラミング言語で多重継承をモデル化できます。 はい はい はい

行動

動作パターンは、オブジェクト間のコラボレーションを記述します。

名前 説明 デザインパターンコードコンプリート[ 15 ]他の
黒板異なるデータソースを組み合わせるための人工知能パターン（黒板システムを参照） はい はい はい
責任の連鎖リクエストの送信者と受信者の結合を避けるため、複数のオブジェクトにリクエストを処理する機会を与えます。受信側オブジェクトをチェーン化し、いずれかのオブジェクトがリクエストを処理するまで、チェーンに沿ってリクエストを渡します。 はい はい はい
指示リクエストをオブジェクトとしてカプセル化することで、異なるリクエストを持つクライアントのパラメータ化、リクエストのキューイングやログ記録が可能になります。また、元に戻す操作のサポートも可能になります。 はい はい はい
流暢なインターフェースAPIをメソッドチェーンで連結し、DSLのように読めるように設計します。各メソッド呼び出しはコンテキストを返し、それを通じて次の論理メソッド呼び出しが可能になります。 はい はい はい
通訳者言語が与えられた場合、その言語の文法の表現と、その表現を使用してその言語の文を解釈するインタープリターを定義します。 はい はい はい
イテレータ基礎となる表現を公開せずに、 集約オブジェクトの要素に順番にアクセスする方法を提供します。はい はい はい
調停者一連のオブジェクトがどのように相互作用するかをカプセル化するオブジェクトを定義します。メディエーターは、オブジェクトが互いに明示的に参照しないようにすることで 疎結合を促進し、それらの相互作用が独立して変化することを可能にします。はい はい はい
メメントカプセル化に違反することなく、オブジェクトの内部状態をキャプチャして外部化し、後でオブジェクトをこの状態に復元できるようにします。 はい はい はい
ヌルオブジェクトデフォルトのオブジェクトを提供することで null 参照を回避します。 はい はい はい
オブザーバーまたはパブリッシュ/サブスクライブオブジェクト間の 1 対多の依存関係を定義します。これにより、1 つのオブジェクトの状態が変化すると、その依存関係にあるすべてのオブジェクトに通知され、自動的に更新されます。 はい はい はい
サーバント複数のクラスに共通の機能を定義します。サーバントパターンは、特定のクラス群に対するヘルパークラスまたはユーティリティクラスの実装とも呼ばれます。ヘルパークラスは通常、オブジェクトを持たないため、異なる種類のクラスオブジェクトに対して動作する静的メソッドのみを持ちます。 はい はい はい
仕様ブール形式で再結合可能なビジネス ロジック。 はい はい はい
州オブジェクトの内部状態の変化に応じて、オブジェクトの動作を変更できるようにします。オブジェクトのクラスが変更されたように見えます。 はい はい はい
戦略アルゴリズムのファミリーを定義し、それぞれをカプセル化して互換性を持たせます。Strategy により、アルゴリズムはそれを使用するクライアントとは独立して変化します。 はい はい はい
テンプレート方式アルゴリズムの骨組みを操作で定義し、一部のステップをサブクラスに委譲します。テンプレートメソッドを使用すると、サブクラスはアルゴリズムの構造を変更することなく、アルゴリズムの特定のステップを再定義できます。 はい はい はい
ビジター一連のクラスのインスタンスに対して実行される操作を表します。Visitorを使用すると、操作対象となる要素のクラスを変更することなく、新しい操作を定義できます。 はい はい はい

同時実行性

並行性パターンは並行処理をサポートします。

名前 説明 POSA2では[ 21 ]他の
アクティブオブジェクトメソッド実行と、それぞれの制御スレッドにあるメソッド呼び出しを分離します。非同期メソッド呼び出しとリクエスト処理用のスケジューラを使用することで、並行処理を導入することが目的です。 はい 該当なし
躊躇オブジェクトが特定の状態にある場合にのみ、オブジェクトに対してアクションを実行します。 いいえ 該当なし
結合特性複数のオブザーバーを組み合わせて、異なるオブジェクトのプロパティを何らかの方法で同期または調整するように強制します。[ 22 ]いいえ 該当なし
計算カーネルGPU に最適化された行列乗算や畳み込みニューラル ネットワークなど、共有配列への非分岐ポインタ演算で使用される整数パラメータが異なる、同じ計算を何度も並列に実行します。 いいえ 該当なし
二重チェックのロック最初にロック基準 (「ロック ヒント」) を安全でない方法でテストすることにより、ロック取得のオーバーヘッドを削減します。それが成功した場合にのみ、実際のロック ロジックが続行されます。

一部の言語とハードウェアの組み合わせでは実装が安全でない場合があります。そのため、アンチパターンと見なされる場合もあります。

はい 該当なし
イベントベースの非同期マルチスレッドプログラムで発生する非同期パターンの問題を解決します。[ 23 ]いいえ 該当なし
ガードサスペンション操作を実行する前にロックを取得し、前提条件を満たす必要がある操作を管理します。 いいえ 該当なし
参加するJoinパターンは、メッセージパッシングによって並行、並列、分散プログラムを作成する方法を提供します。スレッドやロックの使用と比較すると、これはより高水準なプログラミングモデルです。 いいえ 該当なし
ロック一つのスレッドがリソースに「ロック」をかけ、他のスレッドがそのリソースにアクセスしたり変更したりするのを防ぎます。[ 24 ]いいえ インド洋沿岸警備隊[ 16 ]
メッセージング設計パターン（MDP）コンポーネントとアプリケーション間での情報 (メッセージなど) の交換を可能にします。 いいえ 該当なし
モニターオブジェクトメソッドが相互排他制御の対象となるオブジェクト。これにより、複数のオブジェクトが誤って同時にそのオブジェクトを使用することが防止されます。 はい 該当なし
原子炉リアクター オブジェクトは、同期的に処理する必要があるリソースへの非同期インターフェイスを提供します。 はい 該当なし
読み書きロックオブジェクトへの同時読み取りアクセスは許可されますが、書き込み操作には排他アクセスが必要です。書き込みには基盤となるセマフォが使用される場合があり、コピーオンライト機構が使用される場合と使用されない場合があります。 いいえ 該当なし
スケジューラスレッドがシングルスレッド コードを実行できるタイミングを明示的に制御します。 いいえ 該当なし
サービスハンドラーパターン 各リクエストに対して、サーバーはリクエストを処理するための専用のクライアントハンドラーを生成します。[ 25 ]これはセッションごとのスレッドとも呼ばれます。[ 26 ]いいえ 該当なし
スレッドプール複数のタスクを実行するために複数のスレッドが作成され、通常はキューにまとめられます。通常、タスクの数はスレッドの数よりもはるかに多くなります。これはオブジェクトプールパターンの特殊なケースと考えることができます。 いいえ 該当なし
スレッド固有のストレージスレッドにローカルな静的または「グローバル」メモリ。 はい 該当なし
排他的所有権による安全な並行性 排他的所有権が証明できるため、実行時の並行処理メカニズムの必要性を回避できます。これはRust言語の注目すべき機能ですが、コンパイル時のチェックだけが唯一の手段ではありません。プログラマーは、特定の変数が並行アクセスされることはないと判断し、ロックメカニズムの使用を省略するなど、このようなパターンをコードに手動で設計することがよくあります。 いいえ 該当なし
CPUアトミック操作 x86およびその他のCPUアーキテクチャは、プリミティブ値（整数）の変更とアクセスにおけるメモリ安全性を保証する様々なアトミック命令をサポートしています。例えば、2つのスレッドが両方ともカウンタを安全にインクリメントできます。これらの機能は、上記のような他の同時実行パターンのメカニズムを実装するためにも使用できます。C #言語では、これらの機能のためにInterlockedクラスを使用します。 いいえ 該当なし

ドキュメント

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

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

批判

デザインパターンの必要性は、プログラミング言語に機能が欠けている兆候である可能性があるという意見もある。ピーター・ノーヴィグは、『デザインパターン』（主にC++に焦点を当てている）に掲載されている23のパターンのうち16が、LispまたはDylanでは（直接的な言語サポートによって）簡素化または削除されていることを実証している。[ 29 ]ハンネマンとキツァレスは、23のデザインパターンのいくつかをアスペクト指向プログラミング言語（AspectJ）を用いて実装し、23のデザインパターンのうち17の実装からコードレベルの依存性が除去され、アスペクト指向プログラミングによってデザインパターンの実装が簡素化できることを示した。[ 30 ]ポール・グラハムのエッセイ「Revenge of the Nerds」 も参照のこと。 [ 31 ]

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

定義上、パターンはそれを使用するアプリケーションごとに新たにプログラムする必要があります。一部の研究者はこれをコンポーネントによるソフトウェア再利用からの後退と見なしているため、研究者たちはパターンをコンポーネント化する取り組みを行ってきました。MeyerとArnoutは、試みたパターンの3分の2を完全または部分的にコンポーネント化することに成功しました。[ 34 ]

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

以下の概念は、一般的な性質は似ていますが、ソフトウェア設計パターンとは異なります。[ 35 ] [ 36 ] [ 37 ]

ソフトウェアアーキテクチャパターン
システムレベルで繰り返し発生する問題に対する、再利用可能で実証済みのソリューション。システム全体の構造、コンポーネント間の相互作用、品質特性に関する懸念事項に対処します。ソフトウェアアーキテクチャパターンは、デザインパターンよりも高い抽象度で動作し、より広範なシステムレベルの課題を解決します。これらのパターンは通常、システムレベルの懸念事項に影響を与えますが、アーキテクチャパターンとアーキテクチャスタイルの区別は曖昧になる場合があります。例としては、サーキットブレーカーが挙げられます。[ 35 ] [ 36 ] [ 37 ]
ソフトウェアアーキテクチャスタイル
システム全体の構成を定義する高レベルの構造的構成。コンポーネントの構成方法、相互作用の方法、そして相互作用における制約を指定します。アーキテクチャスタイルには通常、コンポーネントとコネクタの種類の語彙、およびシステムのプロパティを解釈するためのセマンティックモデルが含まれます。これらのスタイルは、システム構成の最も粗いレベルを表します。例としては、階層化アーキテクチャ、マイクロサービス、イベント駆動型アーキテクチャなどがあります。[ 35 ] [ 36 ] [ 37 ]

参照

参考文献

  1. ^ Alexandrescu, Andrei (2001). Modern C++ Design: Generic Programming and Design Patterns Applied . Addison-Wesley. p. xviii. ISBN 978-0-201-70431-0。
  2. ^ Horner, Mark (2005). "9". Pro .NET 2.0 C#コードおよび設計標準. Apress. p. 171. ISBN 978-1-59059-560-2。
  3. ^ Smith, Reid (1987年10月).設計方法論に関するパネル. OOPSLA '87 議事録補遺. doi : 10.1145/62138.62151 . Ward氏は、いわゆる「ウィザードレベルの高レベル」のプログラミングを過度に要求することに対して警告を発した。彼は、文書化された「パターン言語」によって抽象化の選択と適用が大幅に改善されると指摘した。彼は、Christopher Alexander氏のパターン言語に関する研究を改変した新しい方法論に基づく「設計と実装の負担の根本的な転換」を提案し、Tektronix社で開発されたプログラミング指向のパターン言語が同社のソフトウェア開発に大きな貢献を果たしたと述べた。
  4. ^ Beck, Kent ; Cunningham, Ward (1987年9月). 「オブジェクト指向プログラミングのためのパターン言語の使用」 . OOPSLA '87ワークショップ「オブジェクト指向プログラミングの仕様と設計」 . 2006年5月26日閲覧。
  5. ^バローニ、アリーヌ・ルシア;ゲエヌーク、ヤン＝ガエル。アルビン＝アミオ、エルヴェ（2003 年 6 月）。デザイン パターンの形式化(レポート)。 EMNテクニカルレポート。ナント: ナント国立高等技術産業技術センター。CiteSeerX 10.1.1.62.6466。S2CID 624834 – ResearchGate 経由。  
  6. ^ビショップ、ジュディス著。「C# 3.0 デザインパターン：C# 3.0 のパワーを活用して現実世界の問題を解決する」。O'Reilly Media 発行の C# 書籍。2012年5月15日閲覧。.NETアプリケーションの開発をスピードアップしたいなら、C# デザインパターンが最適です。これは、一般的なプログラミング問題に対処するための、洗練された、広く認められた、実証済みの方法です。
  7. ^ Tiako, Pierre F. (2009年3月31日). 「RTPAを用いたデザインパターンの形式的モデリングと仕様化」 . Tiako, Pierre F. (編).ソフトウェアアプリケーション：概念、方法論、ツール、およびアプリケーション. p. 636. doi : 10.4018/978-1-60566-060-8 . ISBN 9781605660615。
  8. ^ Laakso, Sari A. (2003-09-16). 「ユーザーインターフェースデザインパターン集」 . ヘルシンキ大学、コンピュータサイエンス学部. 2008年1月31日閲覧。
  9. ^ Heer, J.; Agrawala, M. (2006). 「情報可視化のためのソフトウェア設計パターン」 . IEEE Transactions on Visualization and Computer Graphics . 12 (5): 853–60 . CiteSeerX 10.1.1.121.4534 . doi : 10.1109 / TVCG.2006.178 . PMID 17080809. S2CID 11634997 .   
  10. ^ Dougherty, Chad; Sayre, Kirk; Seacord, Robert C.; Svoboda, David; Togashi, Kazuya (2009).セキュアデザインパターン(PDF) . Software Engineering Institute.
  11. ^ Garfinkel, Simson L. (2005).安全かつ使いやすいコンピュータシステムの設計原則とパターン(博士論文).
  12. ^ 「Yahoo!デザインパターンライブラリ」 。 2008年2月29日時点のオリジナルよりアーカイブ。2008年1月31日閲覧。
  13. ^ 「リーンスタートアップとしてビジネスモデルを設計するには？」 2010年1月6日。 2010年1月6日閲覧。
  14. ^プログラミングのパターン言語、会議論文集（年次、1994年—） [1]
  15. ^ a b cマッコーネル、スティーブ（2004年6月）「Design in Construction」Code Complete（第2版）Microsoft Press 、 104ページ 、ISBN 978-0-7356-1967-8表5.1 一般的なデザインパターン
  16. ^ a b Fowler, Martin (2002). 『エンタープライズ・アプリケーション・アーキテクチャのパターン』 . Addison-Wesley . ISBN 978-0-321-12742-6。
  17. ^ Alur, Deepak; Crupi, John; Malks, Dan (2003). Core J2EE Patterns: Best Practices and Design Strategies . Prentice Hall . p. 166. ISBN 978-0-13-142246-9。
  18. ^ Fowler, Martin (2002). 『エンタープライズ・アプリケーション・アーキテクチャのパターン』 Addison -Wesley . p. 344. ISBN 978-0-321-12742-6。
  19. ^ Bloch, Joshua (2008). 「項目37: マーカーインターフェースを使って型を定義する」. Effective Java (第2版). Addison-Wesley. p.  179. ISBN 978-0-321-35668-0。
  20. ^ 「Twin – 多重継承をモデル化するデザインパターン」(PDF)。
  21. ^ Schmidt, Douglas C.; Stal, Michael; Rohnert, Hans; Buschmann, Frank (2000). 『パターン指向ソフトウェアアーキテクチャ 第2巻：並行オブジェクトとネットワークオブジェクトのパターン』 John Wiley & Sons. ISBN 978-0-471-60695-6。
  22. ^結合特性
  23. ^ Nagel, Christian; Evjen, Bill; Glynn, Jay; Watson, Karli; Skinner, Morgan (2008). 「イベントベースの非同期パターン」. Professional C# 2008. Wiley. pp.  570– 571. ISBN 978-0-470-19137-8。
  24. ^ロックパターン
  25. ^ Francalanza, Adrian; Tabone, Gerard (2023年10月). 「ElixirST: Elixirモジュールのためのセッションベースの型システム」. Journal of Logical and Algebraic Methods in Programming . 135 . doi : 10.1016/j.jlamp.2023.100891 . S2CID 251442539 . 
  26. ^ Schmidt, Douglas C.; Vinoski, Steve (1996年7～8月). 「オブジェクト相互接続：マルチスレッドCORBAサーバー向け代替プログラミング手法の比較（コラム7）」(PDF) . SIGS C++レポート. S2CID 2654843 . 
  27. ^ Gabriel, Dick . 「パターン定義」 . 2007年2月9日時点のオリジナルよりアーカイブ。2007年3月6日閲覧。
  28. ^ Fowler, Martin (2006年8月1日). 「Writing Software Patterns」 . 2007年3月6日閲覧。
  29. ^ Norvig, Peter (1998).動的言語におけるデザインパターン.
  30. ^ Hannemann, Jan; Kiczales, Gregor (2002). 「JavaとAspectJにおけるデザインパターンの実装」.第17回ACM SIGPLAN会議「オブジェクト指向プログラミング、システム、言語、アプリケーション」議事録 - OOPSLA '02 . OOPSLA '02. p. 161. doi : 10.1145/582419.582436 . ISBN 1581134711。
  31. ^グレアム、ポール(2002). 「オタクの復讐」 . 2012年8月11日閲覧。
  32. ^ McConnell , Steve (2004). Code Complete: A Practical Handbook of Software Construction, 2nd Edition . Pearson Education. p.  105. ISBN 9780735619678。
  33. ^クラグベク、ミカエル。「FizzBu​​zzEnterpriseEdition」。2024 年 11 月 19 日に取得。
  34. ^ Meyer, Bertrand ; Arnout, Karine (2006年7月). 「コンポーネント化：ビジターの例」(PDF) . IEEE Computer . 39 (7): 23– 30. CiteSeerX 10.1.1.62.6082 . doi : 10.1109/MC.2006.227 . S2CID 15328522 .  
  35. ^ a b cソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。2020年。ISBN 978-1492043454。
  36. ^ a b cデザインパターン：再利用可能なオブジェクト指向ソフトウェアの要素. ISBN 978-0201633610。
  37. ^ a b cエンタープライズアプリケーションアーキテクチャのパターン。ISBN 978-0321127426。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Software_design_pattern&oldid=1328311217」より取得