4.1 ビルダー
ビルダーは、複合オブジェクトを作成する方法を提供するジェネレーティブ デザイン パターンです。
複雑なオブジェクトの構築をその表現から分離し、同じ構築プロセスで異なる表現が得られるようにします。
強み:
- 製品の内部表現を変更できます。
- 構築とプレゼンテーションを実装するコードを分離します。
- 設計プロセスをより細かく制御できます。
弱点:
- 複雑なオブジェクトを作成するアルゴリズムは、オブジェクトがどの部分で構成されているか、およびそれらがどのように組み合わされているかに依存すべきではありません。
- 構築プロセスでは、構築されるオブジェクトのさまざまな表現を提供する必要があります。
良い例は、HttpRequest クラスです。このクラスには、HttpRequest クラスのインスタンスを作成し、それらが有効であることを確認するために使用できるサブクラス HttpRequest.Builder があります。
4.2 遅延初期化
遅延初期化は、リソースを大量に消費する操作 (オブジェクトの作成、値の計算) がその結果が使用される直前に実行されるプログラミング手法です。
したがって、初期化は事前ではなく「オンデマンド」で実行されます。同様のアイデアは、たとえば、オンザフライ コンパイルやジャストインタイム ロジスティクスの概念など、さまざまな分野で応用できます。
遅延初期化の特殊なケース (アクセス時にオブジェクトを作成する) は、ジェネレーティブ デザイン パターンの 1 つです。通常、Factory Method、Loner、Proxy などのパターンと組み合わせて使用されます。
強み:
- 初期化は、本当に必要な場合にのみ実行されます。
- アプリケーションの初期化が加速され、延期できるものはすべて延期されます。
弱点:
- オブジェクトが初期化される順序を明示的に設定することはできません。
- オブジェクトへの最初のアクセス時に遅延が発生します。これは、リソースを大量に消費する別の操作が並行して実行される場合に重大になる可能性があります。このため、マルチスレッド ソフトウェア システムで遅延初期化を使用することが適切かどうかを慎重に検討する必要があります。
web.xml を記述するときに、そこでサーブレットの開始順序を指定する方法を覚えていますか? これはまさに遅延読み込みの結果です。Tomcat は、初めてアクセスされたときにサーブレット オブジェクトを作成します。
4.3 オブジェクトプール
オブジェクト プールは親デザイン パターンであり、初期化されてすぐに使用できるオブジェクトのセットです。システムがオブジェクトを必要とする場合、オブジェクトは作成されず、プールから取得されます。オブジェクトが不要になった場合、そのオブジェクトは破棄されずにプールに戻されます。
オブジェクト プーリングは、ジョブの開始時にオブジェクトを作成し、終了時にそれを破棄するのにコストがかかる場合に、パフォーマンスを向上させるために使用されます。パフォーマンスの向上は、オブジェクトが頻繁に作成および破棄されるが、同時に存在するオブジェクトの数が少ない場合に特に顕著です。
オブジェクト プールは、オブジェクトがネットワーク ソケットなどのメモリ以外のリソースを所有している場合に役立ちます。または、オブジェクトのコレクションがコンピュータのメモリの重要な部分を占め、大量の「ゴミ」が作成される場合。
ご存知のとおり、Tomcat は各リクエストを別のスレッドで実行します。ただし、スレッドは毎回新たに作成されるのではなく、スレッド プールに保存されます。これにより、リクエストの実行が高速化されます。スレッドが必要な場合、スレッドはプールから取得されるだけです。ところで、問題は、実行中のスレッドをどのようにプールに入れ、プールから取り出すかということです。
GO TO FULL VERSION