このサンプルでは管理者のみが利用できる「管理者メニュー」と、一般ユーザが見れる「一般ユーザメニュー」の2つのメニューがあります。 それぞれのメニュー表示用のサーブレットでは、ユーザの権限チェックを行い、画面を表示するかどうかを決定しています。 権限チェックで画面が利用できないのであれば、エラー画面を表示します。 ◎AbstractServlet（リスト1） AbstractServletは全ての業務サーブレットのスーパークラスとなるサーブレットです。 doPost()、doGet()メソッドからexecute()メソッドを呼び出すことで、ブラウザからのリクエストをexecuteメソッドで処理しています。 execute()メソッドでは以下の処理を行っています。 ①doSetup()メソッド（前処理）の呼び出し ②doAuth()メソッド（権限チェック）の呼び出し ③doExecute()メ

イントロダクション アプリケーションで扱うデータをモデル化してみると、オブジェクト同士の関係を単純な1対1の関係だけで管理できることはほとんどありません。 多くのオブジェクトは、他のいくつかのオブジェクトへの関わりを持つことで構造を作っています。 この構造が単純なうちはよいのですが、また別のオブジェクトへと次々に関わりを持っていくことで、構造はどんどん複雑になっていき、直感的に実装したり使ったりすることが難しくなります。 そんなときはコンポジットパターンが威力を発揮します。 コンポジットパターンは、要素であるオブジェクトと、複数の要素からなる複合オブジェクトを区別なく扱えるという特徴を持ちます。 この特徴を利用することで、構造を再帰的に組み立て、クライアントからの見た目をシンプルに保つことができます。 パターン解説 コンポジットパターンは、ディレクトリ構造のような再帰的な構造を解決すること

イントロダクション 入出力は同じだけど条件によってアルゴリズムの交換を行いたい場合や、将来的にアルゴリズムが変更される可能性がある処理に遭遇する場面があります。 また、switch文などの条件分岐にアルゴリズムを埋め込むような処理を行うと、変更が発生した場合に他のアルゴリズムへ影響が生じたりコードが冗長になったりし、保守性がよくありません。 ストラテジパターンは、アルゴリズムをクラス化することにより、アルゴリズムの切り替えを使用するクラスとは無関係に簡単に行えるようにするパターンです。 なお、ストラテジは「戦略」という意味です。条件によってアルゴリズムを切り替えるところは、まるで戦略を練っているようですね。 パターン解説 データ処理を例にストラテジパターンを説明します。 図6の左側のように、入力したデータ処理が条件により振り分けられ、最終的に同じ型のデータを出力する処理が存在します。 この

イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ

イントロダクション オブジェクトを生成するnewは非常に負荷のかかる処理ですので、使いまわしが効くオブジェクトを毎回newするのはパフォーマンス上問題です。 たとえば、後述のファクトリメソッドパターンで取り上げるファクトリは毎回newする必要がないため、初めに生成したオブジェクトを再利用すぺきです。 また、データベースのコネクションプール数を制限したい場合、データベースアクセスオブジェクトの生成数を制限する必要があります。 このようにオブジェクトの生成数を制限したいときは、シングルトンパターンの出番です。 このパターンを使えば、オブジェクトを外部から直接生成させることを防ぐことができ、クラス自体に同時に生成できるオブジェクトの数を管理する機能を持たせることができます。 パターン解説 シングルトンパターンの特徴は、シングルトンクラスのオブジェクト生成を、シングルトンクラス自身が提供するオブジ