タグ

designpatternとjavaに関するshimookaのブックマーク (3)

  • サルでもわかる 逆引きデザインパターン 第4章 逆引きカタログ その他 実行時例外を標準的に使う

    イントロダクション ここまでは今までのJavaの常識からはありえない「実行時例外を使いましょう」という考え方をご紹介します(ちなみにこれは『実践J2EEデザイン』という書籍で紹介されたイディオムで、デザインパターンではありません)。 筆者も「実行時例外を使おう」と初めて聞いたときはたいへん驚きました。今までの常識が崩れ去った気分でした。 しかし、今ではこの方法で、問題なく、以前よりも効率良くアプリケーションを書いています。 パターン解説 例外には大きく分けて検査例外と実行時例外があります。 検査例外はjava.lang.Exceptionを継承した例外です。 検査例外が発生する場所では、必ずcatchブロックで例外をキャッチするか、throws句で例外をメソッドの呼び出し元に投げる宣言をする必要があります。 実行時例外はjava.lang.RuntimeExceptionを継承した例外です

    shimooka
    shimooka 2013/08/28
    まあ、こういう考え方もあるよ、ということで。
  • フロントコントローラ - Strategic Choice

    フロントコントローラ@Webプレゼンテーションパターンリクエストすべてを受け付けるコントローラ。どういうこと?フロントコントローラは、一旦全てのリクエストを1つの「ハンドラ」オブジェクトが受けて、それらを「コマンド」オブジェクトに振り分ける仕組みです。どうすれば?フロントコントローラは、「ハンドラ」と「コマンド」から構成します。ハンドラは、URLとリクエストから必要な情報を抽出します。どのようなアクションを実行するかを判断し、アクションを実行するコマンドに委譲します。ハンドラは、レスポンスを返さないため、サーバベージとしてではなくクラス*1として実装されます。ハンドラ自体は極めてシンプルなプログラムであり、実行するコマンドを判断する以外は何も行いません。コマンドは、アクションの実処理を行うクラスです。最終的なビューの決定も、コマンドクラスで行います。コマンドもサーバページではなく、クラス*

  • 数多くのコンストラクタパラメータに直面した時にはビルダーを検討する - Strategic Choice

    package asakichy.第02章オブジェクトの生成と消滅; import static org.hamcrest.Matchers.*; import static org.junit.Assert.*; import org.junit.After; import org.junit.Before; import org.junit.Test; @SuppressWarnings("unused") public class 項目02数多くのコンストラクタパラメータに直面した時にはビルダーを検討する { @Test public void 問題点_コンストラクタパラメータの数が多いと使いにくい() throws Exception { /** 【詳細】 */ description.append(1).append("何番目が何のパラメータかわかりにくい。"); descrip

  • 1