デザインパターン

デザインパターン:
再利用可能な要素オブジェクト指向ソフトウェア

著者	エーリッヒ・ガンマ リチャード・ヘルム ラルフ・ジョンソン ジョン・ブリシデス
主題	デザインパターン、ソフトウェアエンジニアリング、オブジェクト指向プログラミング
出版社	アディソン・ウェズリー
発行日	1994
出版地	アメリカ合衆国
ページ	395
番号	0-201-63361-2
OCLC	31171684
デューイ十進分類法	005.1/2 20
LCクラス	QA76.64 .D47 1995

『デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの要素』 (1994) は、ソフトウェア設計パターンについて説明したソフトウェアエンジニアリングの本です。この本は、 Erich Gamma、 Richard Helm、 Ralph Johnson、 John Vlissidesによって書かれ、 Grady Boochが序文を書いています。この本は 2 つの部分に分かれており、最初の 2 つの章ではオブジェクト指向プログラミングの機能と落とし穴について説明し、残りの章では 23 の典型的なソフトウェア設計パターンについて説明しています。この本には、 C++とSmalltalkの例が含まれています。

ソフトウェア工学の分野に影響を与えており、オブジェクト指向設計の理論と実践の重要な情報源とみなされています。英語と他の13の言語で50万部以上が販売されています。^{[1]著者はしばしば}Gang of Four（GoF）と呼ばれます。 ^{[2] [3] [4] [5]}

この本は、1990 年のOOPSLA会議「アーキテクチャ ハンドブックに向けて」の同類セッションで始まりました。このセッションで、エリック ガンマとリチャード ヘルムが出会って、共通の関心事を発見しました。後にラルフ ジョンソンとジョン ブリシデスが加わりました。 ^[6]この本は、1994 年 10 月 21 日に 1995 年の著作権で最初に出版され、1994 年の OOPSLA 会議で一般に公開されました。

第 1 章では、著者の経験に基づいて、優れたオブジェクト指向ソフトウェア設計につながると考えられる オブジェクト指向設計手法について説明します。

• 「実装ではなくインターフェースに合わせてプログラムする。」(Gang of Four 1995:18)
• 継承よりも構成を優先する: 「クラス継承よりもオブジェクト構成を優先する」(Gang of Four 1995:20)

著者らは、実装に対する インターフェースの利点として以下を主張しています。

• オブジェクトがインターフェースに準拠している限り、クライアントは使用するオブジェクトの特定のタイプを意識する必要はありません。
• クライアントはこれらのオブジェクトを実装するクラスを認識しません。クライアントはインターフェースを定義する抽象クラスのみを認識します。

インターフェースを使用すると、オブジェクト指向プログラミングの中心的な機能である 動的バインディングとポリモーフィズムも実現されます。

著者らは継承をホワイトボックス再利用と呼んでいます。ホワイトボックスは可視性を意味します。親クラスの内部はサブクラスから見えることが多いためです。対照的に、著者らはオブジェクト合成(明確に定義されたインターフェースを持つオブジェクトが、他のオブジェクトへの参照を取得するオブジェクトによって実行時に動的に使用される) をブラックボックス再利用と呼んでいます。合成されたオブジェクトの内部詳細は、それらを使用するコード内で見える必要がないためです。

著者らは継承とカプセル化の間の緊張関係について長々と議論し、経験上、設計者は継承を過度に使用していると述べています (Gang of Four 1995:20)。危険性は次のように述べられています。

「継承によってサブクラスが親の実装の詳細にさらされるため、継承によってカプセル化が破壊されると言われることがよくあります。」(Gang of Four 1995:19)

彼らは、サブクラスの実装が親クラスの実装と非常に密接に結びついているため、親の実装が変更されるとサブクラスも変更を余儀なくされると警告しています。さらに、これを回避するには抽象クラスのみを継承すればよいと主張していますが、コードの再利用は最小限にとどまると指摘しています。

継承の使用は、既存のコンポーネントの機能を追加し、古いコードの大部分を再利用し、比較的少量の新しいコードを追加する場合に主に推奨されます。

著者にとって、「委任」は継承の代わりにいつでも使用できるオブジェクト構成の極端な形式です。委任には 2 つのオブジェクトが関係します。「送信者」は自分自身を「委任者」に渡し、委任者が送信者を参照できるようにします。したがって、システムの 2 つの部分間のリンクは、コンパイル時ではなく実行時にのみ確立されます。委任の詳細については、 コールバックの記事を参照してください。

著者らは、ジェネリック( Ada、Eiffel、Java、C#、Visual Basic (.NET)、Delphi ) またはテンプレート ( C++ ) としても知られる、いわゆるパラメータ化された型についても説明しています。これらを使用すると、使用する他のすべての型を指定せずに任意の型を定義できます。指定されていない型は、使用時に「パラメータ」として提供されます。

著者らは委任とパラメータ化が非常に強力であることを認めていますが、次のような警告を加えています。

「動的で高度にパラメータ化されたソフトウェアは、静的なソフトウェアよりも理解し構築するのが難しい。」 (Gang of Four 1995:21)

著者らはさらに、「集約」と「知り合い」を区別しています。「知り合い」とは、あるオブジェクトが別のオブジェクトを「持っている」または「その一部である」(集約オブジェクトとその所有者の存続期間が同じであることを意味します) ことです。また、「知り合い」とは、あるオブジェクトが別のオブジェクトを単に「知っている」だけのことです。知り合いは「関連」または「使用」関係と呼ばれることもあります。知り合いオブジェクトは、お互いに操作を要求することはできますが、お互いに責任を負うことはありません。知り合いは集約よりも弱い関係であり、オブジェクト間の結合がはるかに緩いことを示唆しています。これは、設計における保守性を最大限に高めるには望ましいことがよくあります。

著者らは、今日では C# や Java のように「クラス ライブラリ」という用語が使われるところを「ツールキット」という用語で表現しています。彼らの用語では、ツールキットはサブルーチン ライブラリのオブジェクト指向版であり、「フレームワーク」は特定のクラスのソフトウェアの再利用可能な設計を構成する一連の連携クラスです。彼らは、アプリケーションの設計は難しく、ツールキットはもっと難しく、フレームワークは最も設計が難しいと述べています。

作成パターンは、オブジェクトを直接インスタンス化するのではなく、オブジェクトを作成するパターンです。これにより、プログラムは、特定のケースでどのオブジェクトを作成する必要があるかをより柔軟に判断できるようになります。

• 抽象ファクトリは、共通のテーマを持つオブジェクト ファクトリをグループ化します。
• ビルダーは、構築と表現を分離することで複雑なオブジェクトを構築します。
• ファクトリ メソッドは、作成するクラスを正確に指定せずにオブジェクトを作成します。
• プロトタイプは既存のオブジェクトを複製してオブジェクトを作成します。
• シングルトンは、クラスのオブジェクト作成を 1 つのインスタンスのみに制限します。

構造パターンはクラスとオブジェクトの構成に関係します。継承を使用してインターフェースを構成し、新しい機能を取得するためにオブジェクトを構成する方法を定義します。

• アダプタを使用すると、既存のクラスのインターフェースを独自のインターフェースでラップすることで、互換性のないインターフェースを持つクラスを連携させることができます。
• Bridge は抽象化とその実装を切り離し、2 つを独立して変更できるようにします。
• Composite は、0 個以上の類似オブジェクトを 1 つのオブジェクトとして操作できるように合成します。
• デコレータは、オブジェクトの既存のメソッドの動作を動的に追加/オーバーライドします。
• Facade は、大量のコードに対する簡素化されたインターフェースを提供します。
• Flyweight は、多数の類似オブジェクトの作成と操作にかかるコストを削減します。
• プロキシは、アクセスを制御し、コストを削減し、複雑さを軽減するための別のオブジェクトのプレースホルダーを提供します。

ほとんどの動作設計パターンは、オブジェクト間の通信に特に関係しています。

• 責任の連鎖は、処理オブジェクトのチェーンにコマンドを委任します。
• コマンドは、アクションとパラメータをカプセル化するオブジェクトを作成します。
• インタプリタは特殊な言語を実装します。
• イテレータは、基礎となる表現を公開せずに、オブジェクトの要素に順番にアクセスします。
• Mediator は、メソッドの詳細な知識を持つ唯一のクラスとなることで、クラス間の疎結合を可能にします。
• Memento は、オブジェクトを以前の状態に戻す機能 (元に戻す) を提供します。
• オブザーバーはパブリッシュ/サブスクライブ パターンであり、複数のオブザーバー オブジェクトがイベントを確認できるようにします。
• 状態により、オブジェクトは内部状態が変化したときにその動作を変更できます。
• 戦略により、実行時にアルゴリズム ファミリの 1 つをオンザフライで選択できるようになります。
• テンプレート メソッドは、アルゴリズムのスケルトンを抽象クラスとして定義し、そのサブクラスが具体的な動作を提供できるようにします。
• Visitor は、メソッドの階層を 1 つのオブジェクトに移動することで、アルゴリズムをオブジェクト構造から分離します。

2005年、ACM SIGPLANは、著者らの研究が「プログラミング実践とプログラミング言語設計」に与えた影響を評価し、その年のプログラミング言語功績賞を著者らに授与した。 ^[7]

ソフトウェア設計パターンの概念全般、特にデザインパターンに対して批判が向けられてきました。デザインパターンに対する主な批判は、そのパターンが単に C++ に欠けている機能の回避策に過ぎず、エレガントな抽象機能を長い具体的なパターンに置き換え、本質的に「人間コンパイラ」になっているというものです。ポール・グラハムは次のように書いています: ^[8]

プログラムにパターンが見られると、私はそれが問題の兆候であると考えます。プログラムの形状は、解決する必要のある問題のみを反映するべきです。コード内のその他の規則性は、少なくとも私にとっては、十分に強力でない抽象化を使用していることの兆候です。多くの場合、記述する必要のあるマクロの展開を手動で生成していることを示しています。

Peter Norvigは、デザインパターンの23のパターンのうち16がLispやDylanの言語機能によって簡略化または削除されていることを示しています。^[9]関連する観察は、HannemannとKiczalesによってなされました。彼らは23のデザインパターンのいくつかをアスペクト指向プログラミング言語（AspectJ）を使用して実装し、23のデザインパターンのうち17の実装からコードレベルの依存関係が削除され、アスペクト指向プログラミングによってデザインパターンの実装が簡略化できることを示しました。^[10]

2009年のInformITとのインタビューで、Erich Gammaは、本の著者らが2005年にこの本をどのようにリファクタリングするかについて議論し、いくつかのパターンを再分類し、拡張オブジェクト/インターフェイス、依存性注入、型オブジェクト、およびnullオブジェクトなどのパターンをいくつか追加するという結論に達したと述べています。Gammaはシングルトンパターンを削除したいと考えていましたが、著者らの間でそうすることについての合意はありませんでした。^[11]

• ソフトウェア設計パターン
• エンタープライズ統合パターン
• GRASP（オブジェクト指向設計）
• 教育パターン