サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
www.nulab.co.jp
このサンプルでは管理者のみが利用できる「管理者メニュー」と、一般ユーザが見れる「一般ユーザメニュー」の2つのメニューがあります。 それぞれのメニュー表示用のサーブレットでは、ユーザの権限チェックを行い、画面を表示するかどうかを決定しています。 権限チェックで画面が利用できないのであれば、エラー画面を表示します。 ◎AbstractServlet(リスト1) AbstractServletは全ての業務サーブレットのスーパークラスとなるサーブレットです。 doPost()、doGet()メソッドからexecute()メソッドを呼び出すことで、ブラウザからのリクエストをexecuteメソッドで処理しています。 execute()メソッドでは以下の処理を行っています。 ①doSetup()メソッド(前処理)の呼び出し ②doAuth()メソッド(権限チェック)の呼び出し ③doExecute()メ
イントロダクション ユーティリティクラスはデザインパターンではありませんが、良く使われる基本的な定石なのであえてここでご紹介いたします。 ユーティリティクラスは、staticな共通の処理のメソッドを集めたクラスです。 同じ処理が2箇所以上で出てきた場合は、ユーティリティクラスにまとめることができる可能性があります。 ユーティリティクラスを使うと共通処理を1箇所にまとめることができますので、再利用性の向上ばかりでなく、あとから修正が発生してもユーティリティクラスの修正だけですみ、保守性が向上するというメリットがあります。
◎Element(リスト17) すべての処理の対象となるクラスに適用するインタフェースです。 処理を受け入れることを表します。 リスト17 Element.java /** * 処理を受け入れるインタフェースです。 */ public interface Element { void accept(Visitor visitor); } ◎Order(リスト18) すべての商品のスーパークラスです。 Elementインタフェースを継承しています。 リスト18 Order.java /** * すべての要素の基本となる抽象クラスです。 */ public abstract class Order implements Element { /* * 注文を追加します。 */ public void addOrder(Order order) { } /* * 料金を集計する抽象メソッドです。
イントロダクション 「MVC」という言葉をご存知ですか? MVCとは「Model(モデル)-View(ビュー)-Controller(コントローラ)」の頭文字をとった言葉で、1980年代にSmalltalkという言語で確立されたアプリケーションのアーキテクチャパターンです。 モデルはビジネスロジック(業務処理)、ビューは表示処理、コントローラはモデルとビューの操作を担当します。 J2EEではMVCをお手本に「MVC2」というアーキテクチャを採用しています。 サーブレット/JSPベースのWebアプリケーションの場合、一般的にモデルはJavaBeans (あるいはEJB)、ビューはJSP、Web層のコントローラがサーブレット、ビジネス層のコントローラが先ほどのファサードとして実装されます。 本節ではMVCの「V」の部分、つまりJSPに注目してみます。 JSPはビューですので表示処理のみを行い、
クラス図 クラス図は、クラスやクラス同士の関連を表す図です。 ◎クラス クラスは3つのボックスに区切った四角形で表します(図5)。 一番上のボックスはクラス名を記述します。真ん中のボックスには属性、Java言語で言うところのフィールド名を記述します。 一番下のボックスには操作、Java言語で言うところのメソッド名を記述します。属性と操作のボックスは省略可能です。 また、属性の型やメソッドの戻り値の型は、属性名や操作名のうしろにコロンを付けて記述します。これも省略可能です。 属性や操作の前に「+」「-」記号が付いていますが、これは可視性を表す記号です。「+」はpublic、「-」 はprivate、「#」はprotectedです。何も記号が付いていない場合はJavaと同じでパッケージアクセスを意味 します。
イントロダクション ここまでは今までのJavaの常識からはありえない「実行時例外を使いましょう」という考え方をご紹介します(ちなみにこれは『実践J2EEデザイン』という書籍で紹介されたイディオムで、デザインパターンではありません)。 筆者も「実行時例外を使おう」と初めて聞いたときはたいへん驚きました。今までの常識が崩れ去った気分でした。 しかし、今ではこの方法で、問題なく、以前よりも効率良くアプリケーションを書いています。 パターン解説 例外には大きく分けて検査例外と実行時例外があります。 検査例外はjava.lang.Exceptionを継承した例外です。 検査例外が発生する場所では、必ずcatchブロックで例外をキャッチするか、throws句で例外をメソッドの呼び出し元に投げる宣言をする必要があります。 実行時例外はjava.lang.RuntimeExceptionを継承した例外です
イントロダクション 入出力は同じだけど条件によってアルゴリズムの交換を行いたい場合や、将来的にアルゴリズムが変更される可能性がある処理に遭遇する場面があります。 また、switch文などの条件分岐にアルゴリズムを埋め込むような処理を行うと、変更が発生した場合に他のアルゴリズムへ影響が生じたりコードが冗長になったりし、保守性がよくありません。 ストラテジパターンは、アルゴリズムをクラス化することにより、アルゴリズムの切り替えを使用するクラスとは無関係に簡単に行えるようにするパターンです。 なお、ストラテジは「戦略」という意味です。条件によってアルゴリズムを切り替えるところは、まるで戦略を練っているようですね。 パターン解説 データ処理を例にストラテジパターンを説明します。 図6の左側のように、入力したデータ処理が条件により振り分けられ、最終的に同じ型のデータを出力する処理が存在します。 この
イントロダクション みなさんのサーブレット(Strutsを使用している場合はアクションクラス)の行数は、平均どれくらいでしょうか? データベースアクセスや業務処理など、すべての処理をサーブレットに詰め込もうとして、あっという間に1000行を越すような「太ったサーブレット」を作ってしまったことありませんか? サーブレットを初めて書いたときは筆者もそうでした。 このような「長く」「すべての処理が入った」サーブレットのことをすべてのことを行う魔法のようなサーブレットということで「マジックサーブレット」と呼びます。 マジックサーブレットは保守や機能拡張が難しいのはもちろんのこと、「アプリケーションが提供する機能」を把握することが難しくなるという弊害があります。 機能を把握できないと「あの機能ってどこにあったっけ?」という状況を生み出しがちになります。 そのような状況を避けるためにも、「サービスを提
イントロダクション オブジェクトを生成するnewは非常に負荷のかかる処理ですので、使いまわしが効くオブジェクトを毎回newするのはパフォーマンス上問題です。 たとえば、後述のファクトリメソッドパターンで取り上げるファクトリは毎回newする必要がないため、初めに生成したオブジェクトを再利用すぺきです。 また、データベースのコネクションプール数を制限したい場合、データベースアクセスオブジェクトの生成数を制限する必要があります。 このようにオブジェクトの生成数を制限したいときは、シングルトンパターンの出番です。 このパターンを使えば、オブジェクトを外部から直接生成させることを防ぐことができ、クラス自体に同時に生成できるオブジェクトの数を管理する機能を持たせることができます。 パターン解説 シングルトンパターンの特徴は、シングルトンクラスのオブジェクト生成を、シングルトンクラス自身が提供するオブジ
イントロダクション 私たちが作るアプリケーションのほとんどは、どこかで永続的なデータを扱うことになります。 そのデータの保存先は、リレーショナルデータベースやテキストファイル、他システムなどになるでしょう。 そして保存されたデータへのアクセスで使用するAPIは、保存先によって変わっていきます。 例えば、リレーショナルデータベースだとJDBCを使用します。 ファイルだとjava.ioパッケージあたりを使用したりします。 また、リレーショナルデータベースのみに焦点を当ててみても、ベンダやバージョンによって発行するSQL文を変えなければなりません。 ファイルに永続的なデータを保存していて、その保存先がデータベースに変更されたときのことを想像してください。 ビジネスロジック(業務ロジック)の中にデータアクセスにまつわるコードを書いている場合、保存先の変更が容易ではありません(同様のことが、データベ
継承 すでに定義されたクラスの機能を引き継いで、新しいクラスを定義することを継承と言います。 Java言語ではサブクラスでスーパークラスを「extends」することで継承を実現します。 継承をうまく利用することで、サブクラス間で共通の部分をスーパークラスに引き上げることができます(図1)。 第3章で解説するテンプレートメソッドパターンは、継承の特徴をうまく利用した典型的なパターンです。 ポリモフィズム ポリモフィズムは「多態性」と呼ばれます。 …しかし、多態性という言葉ではまったく意味がわかりません。 少なくとも筆者はそうでした。ポリモフィズムを一言で説明するのはたいへん難しいです。 しかし、多くのデザインパターンではポリモフィズムが多用されていますので、デザインパターンの理解のためにもポリモフィズムは避けては通れません。 Javaでポリモフィズムを実現する方法としては、インタフェースを使
第1章 はじめてのデザインパターン はじめに デザインパターンとは 特集の構成 すぐわかるオブジェクト指向 すぐわかるUML おわりに 第2章 逆引きカタログ ロジック編 Singleton (シングルトン) Factory/Factory Method (ファクトリ/ファクトリメソッド) Strategy (ストラテジ) Composite (コンポジット) Visiter (ビジタ) 第3章 逆引きカタログ J2EE編 Template Method (テンプレートメソッド) Facade (ファサード) ViewHelper (ビューヘルパ) DAO (Data Access Object) 第4章 逆引きカタログ その他 ユーティリティクラス 実行時例外を標準的に使う Nullオブジェクト 第5章 デザインパターン適用の勘所 はじめに アプリケーションの仕様 リファクタリング前のサ
デザインパターンは「良い設計の虎の巻」 デザインパターンとは簡単に言うと「良い設計の虎の巻」です。 プログラミングや設計をしていると、以前経験したことがある、 似たような問題に出くわすことがよくありますよね。 そのような問題の解決法にわかりやすい名前を付けて、 カタログ化(虎の巻化)したものがデザインパターンです。 デザインパターンは虎の巻ですので、 知っているのと知らないのでは設計や効率に大きく差がついてきます。 先人たちの「設計に関する試行錯誤の結果」であるデザインパターンを、 効果的に再利用しない手はありません。 デザインパターンにはいくつか種類があります。 表1 デザインパターンの種類 カタログ名 説明
このページを最初にブックマークしてみませんか?
『株式会社ヌーラボ(Nulab Inc.)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く