さとまも談義|テクノロジーと体験とアートと

テクノロジーとビジネスと人の関係性にずっと興味があります。アートやダイバーシティのキーワードも含めて、世界がどう変わっていくか、変えていけるかをお酒を飲みつつ考えるブログ

サーブレット実装における注意点

アンチパターンについて肝に命じること

doPOSTとdoGETをコピペしない

ちょっとした修正が必要な場合でも、2カ所のコードを直さなければならず、メンテナンス性が低い。
のプログラムを改善するには、例えばdoTaskといったメソッドを用意し、共通のロジックをそこにまとめて記述する。そのうえで、以下に示すように、メソッドdoPostとdoGetから、このdoTaskを呼び出すようにすればよい。

メソッドdoGet
public void doGet(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
doTask(req, resp);
}
メソッドdoPost
public void doPost(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
doTask(req, resp);
}
メソッドdoTask
public void doTask(HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
// ここで実際の処理を行う
…略…
}

サーブレッドへのロジックの詰め込みすぎ → BLOB

1つのクラスが多くの処理を担当して肥大化していくアンチ・パターンを、「BLOB(肥満児)」と言う

今回の開発は、最初はそんなことになりそうだったので、少しは回避するようにしたんだけど。
これもアンチ/パターンですね。

ビジネスロジック→ 〜〜BL
データアクセス → 〜〜DAO
データ保持クラス → 〜〜VO

というネーミングは分かりやすい。次回から採用しよう。

パラメーターのハードコーディング

DBへのアクセス情報とか、これは時間がないという意味の分からない理由で、ハードコーディングしていた部分で、誠にお恥ずかしい。いますぐにリファクタリングします……。

もっと早くこの記事読んでおくんだったな。
http://www.itarchitect.jp/enterprise/-/10220-1.html


htmlからの人的入力値のValidationなんかも注意点ではありますが、今回はデモシステムなので実装は省くことに……。
すいませんが。