Iterator（反復）は、ありふれたコンピューティング処理の1つです。簡潔で、なおかつ一貫性と表現力のある実装方法が求められる状況には、反復はうってつけです。本稿では、Iteratorパターンのさまざまな使用例を紹介します。

　多くのデザインパターンと同様、Abstract FactoryパターンとBuilderパターンは、クラス構造という点で見ると非常によく似ています。本稿では、Abstract FactoryとBuilderの違いを際立たせるため、「デザインパターンの使い方：Builder」で紹介した例を再び使って、パターンの実装・適用について解説していきます。

　Prototypeパターンは、優れたオブジェクト指向デザインの持つその他の基本的な考え方にのっとって、ポリモーフィックであり、依存性逆転の原則と単一責務の原則に合致しています。本稿では、図書館などで使われる所蔵目録（カタログ）システムの実装を例に取り、解説していきます。

　ファサードとは複雑なAPIをシンプルにするためのインターフェースのことです。ファサードを導入すると、システム内部の概念を単純化して理解でき、保守費用も抑えることができます。また、APIをファサードの向こう側に隠蔽することで柔軟性も向上します。本稿では、ProcessBuilder APIを例にとり、ファサードデザインパターンを解説していきます。

　Mediatorパターンは多数のオブジェクトの間の調整を行いながら処理をすすめるためのデザインパターンです。本稿では、スーパーなどでセルフレジを利用する際のユースケースを例にとり、Mediatorパターンを解説していきます。

　アプリケーションを作成する上で条件ロジックを欠くことはできません。しかし、あまりに多用すると入り組んできて分かりにくくなります。このような事態をできるだけ避けるために、私はStateデザインパターンを使ってコードをすっきりさせています。本稿では、Stateデザインパターンの利用方法を例を示しながら説明します。

　Interpreterパターンは、言語の文法をオブジェクトで表現し、そのオブジェクトを用いて言語の文を解釈するためのデザインパターンです。本稿では、単純なブール言語をサポートするインタープリタの作成を例に、Interpreterパターンを解説していきます。

　Chain of Responsibilityは、要求を処理できる可能性のあるハンドラが複数存在するような状況に適用されるデザインパターンです。これは、業務の「命令系統」によく似ています。本稿では、Chain of Responsibilityの構造を社内で経費報告書の承認を得るときに、権限が受領されていく様子を例にとり、解説していきます。

　Builderパターンは、Template Methodパターンによく似ています。Template Methodパターンとの大きな違いは、その目的がオブジェクトを生成することであり、アルゴリズムを実行することではないという点です。Builderパターンは、役割分担を明確にするだけでなく、インターフェイスと実装の分離を実現する代表的な事例であり、パターンを使用しない場合に起こりうる重複をかなりの程度防ぐことができます。

テスト駆動型のアプローチに基づいた、ソースコードのリファクタリングを題材にして、非常に便利で有名なデザインパターン「Commandパターン」を紹介します。

　Strategyパターンを利用すると、アルゴリズムをクライアントから切り離して個別に変更できるようになります。本稿では、SQLジェネレータの一部を作成する過程を通して、段階的にパターンの実装方法を解説していきます。

GoFのデザインパターンの中にはごく限られた場面でしか使えそうにないパターンがいくつかあり、その一例がFlyweightです。しかし、Flyweightは、Stringオブジェクトの管理に使われるなど、Java自体が大きく依存しているデザインパターンです。本稿では、Flyweightパターンの特徴や利用方法を解説します。

「Template Methodパターン」は、アルゴリズムの途中で必要な処理を抽象メソッドに委ね、その実装を変えることで処理が変えられるようにするデザインパターンです。本稿では、実際にリファクタリングを行う具体的な例を見ながら、「Template Methodパターン」の使用方法を説明していきます。

本稿ではデザインパターンのうちの1つ、「Compositeパターン」について解説します。Compositeパターンを利用することで、クライアントコードは複合オブジェクトを非複合オブジェクトと同じように扱うことができます。

本稿ではデザインパターンのうちの1つ、「Adapterパターン」について解説します。すでに用意されているインターフェースをアプリケーションで使いやすい形に「変換」し、違いを吸収するデザインパターンです。

Singletonはおそらく最も非難されているソフトウェアデザインパターンでしょう。本稿では、Singleton構造が抱える問題点、およびその対処方法について考えていきます。