■[デザインパターン][Grand]Object Pool

Object Pool [Grand98]

概要

オブジェクトの生成に多くの資源を必要とする場合や、オブジェクトの個数に制限がある場合にオブジェクトの使い回しを行う。

背景

例えば、データベースのコネクションを必要な都度作成していると、以下のような不具合が生じる。

• データベースへの接続に、数秒かかることがある。
• データベースに多くの接続がされていると、新しい接続にさらに長い時間がかかる。
• 各データベース接続は、1つのネットワーク接続を使用する。
  • プラットフォームによっては、ネットワーク接続できる数を制限するものもある。

適用可能性

• 特定のクラスに対して上限数を超えるインスタンスを生成しないことがある。
• 特定のクラスのインスタンスを生成するコストが多大な場合は、そのクラスのインスタンスを新しく生成すべきでない。
• オブジェクトを使い終えたときにそれを廃棄せずに再利用することで、オブジェクト再生成を避けることができる。

解

クラスのインスタンスが再利用できれば、クラスの新しいインスタンス生成は避ける。

• Reusable
  • 限定した期間のみ他のオブジェクトと協調して働き、その後不要になる。
• Client
  • 使い回し可能なオブジェクトを使用する。
• ReusablePool
  • Clientオブジェクトから使われるReusableオブジェクトを管理する。
  • Reusableを取得、解放するメソッドを持つ。
  • Reusableオブジェクト数を管理することもできる。
  • 全体で整合性を取るため、Singletonとして設計されることが多い。

結果

• オブジェクト生成の必要性を減らすことができる。

トレードオフ

• オブジェクトの需要が大きく変化する状況では、実行効率の問題が生じることがある。
  • 1000個の内、常に使っているのはほぼ10個とか。
  • 10個しかプールしていないのに、急に1000個の要求がきたりとか。

関連

• Cache Management
  • Cache Managementパターンはクラスの特定のインスタンスの再利用を管理する。
  • Object Poolパターンは交換して使用できるクラスのインスタンスを管理・生成する。
• Factory Method
  • Factory Methodパターンはオブジェクトの生成ロジックをカプセル化するために使用できる。
  • しかし、このパターンはオブジェクト生成後の管理は行わない。
• Singleton
  • Object Poolを管理するオブジェクトは、通常Singletonである。

参考

GoF以外のパターンで、この本の中で唯一紹介されていた。第2版で追加された模様。第22章。

Permalink | コメント(0) | トラックバック(1) | 11:43