――Beanはsetしてexecuteしてgetして活用する――
 |
外部プログラムとBeanのオブジェクト指向的な関係 |
ではなぜ、先にデータをセットしてしまうのか？ その答えは外部プログラムとBeaｎとの間にJavaを使ったオブジェクトの考え方を利用したデザインが採用されているところにあります。
オブジェクトの考え方では、情報と処理は１つの意味あるまとまりとして存在します。例えば人間を例に挙げてみましょう。人の名前が決まれば、その人の年齢、性別、住所、学歴など関連する情報が一瞬に決まります。
これをコンピュータ処理で考えれば、名前というキーをもとにして個人情報データベースを検索するという処理を行うことになります。いくら人の名前が分かっても、その後にある処理が行われなければそれ以外の情報を知る由はありません。
しかしオブジェクトの考え方では、このような人の情報が決まれば、そのほかの情報もすでに自動的に決まるという考え方をします。そういう意味で、データが決まれば実行される処理も自動的に決まり、両方合わせて１つという立場をとるのがオブジェクト思考的な考え方になるわけです。
このような考え方はJavaのいろいろなところで生かされています。例えば上のような事例はオブジェクト指向データベースという処理に生かされています。それをBeanで実現したのがEJBのEntityBeanというものです（EntityBeanの説明については、この@ITサイトのほかの記事をぜひ参照してみてください）。
EntityBeanでは、外部プログラムがEntityBeanにキーをセットすれば、直ちに関連する情報がプロパティで参照できます。EntityBeanの中ではDB処理が行われているのですが、外部プログラムではそんな処理など知ることなく、すべての情報をたちどころに手に入れることができます。これは情報と処理が一緒になっている良い例といえます。
 |
| 図７ EntityBeanはキーが決まればすべてのプロパティの内容が決まる |
|
業務処理は必ず失敗なく実行されないといけない |
このようなオブジェクトの考え方は業務ロジックで利用される情報にも応用されます。例えばお酒の購入を処理する業務ロジックがあるとしましょう。このロジックには20歳未満の購入者が入ってきてはいけません。
オブジェクトの考え方では業務処理自体を始めたら、その業務で使う情報には20歳未満の情報は、すでに排除されているものと理解して処理を行います。なぜならお酒を購入することが前提となっている情報は、すでに何らかの処理が行われて不正なデータは排除されるという前提に立つからです。
もし業務ロジックで不正情報が入る可能性があるとするなら、処理の中で正しい情報かどうか判別する作業を入れないといけません。そうなると本来の業務処理以外の処理を記述しなくてはならなくなり、とても複雑な処理になってしまいます。
ですからオブジェクトで使われる業務ロジックでは渡されたデータが意味のないものであったり、本来の処理の実行を妨げるエラーデータであってはいけないことになります。では業務ロジックに渡されるデータはどこで精査されるの？ ということになりますが、ここで効いてくるのがアクセッサという存在です。
外部プログラムは業務メソッドを呼び出す前に、必ずアクセッサを使い処理に必要な引数をBeanに渡します。リスト2にあるアクセッサは、変数の内容をゲットしたりセットしたりする非常に簡単な内容ですが、通常はこのアクセッサに、データに問題がないかどうかチェックするロジックが埋め込まれます。そうするとアクセッサを呼び出したときに不正なDB名やテーブル名、キーが渡されてきてないかどうかチェックできます。また先ほどの例にとれば20未満の人がお酒を買おうとしているかどうかも判別できるわけです。
業務プログラムは必ず業務ロジックを呼び出す前にアクセッサでデータをセットするので、アクセッサのチェックに引っかかれば、外部プログラムはデータに不正があることを直ちに知ることができます。これで外部プログラムは、不正なデータで業務ロジックを実行しなくても済むわけです。
 |
| 図8 外部プログラムはアクセッサの例外を受け取り、処理を制御する |
|
setterとgetterが対で作成される理由は? |
外部プログラムが引数をBeanに渡すときは、アクセッサのsetterメソッドを使います。かといってプロパティにはsetterメソッドだけを用意すればいいかというとそうではなく、情報を入手するためのgetterメソッドも必要です。
再度、リスト1の業務ロジックを見てください。ここで必要な引数はデータベース名を表すDBプロパティ、テーブル名を表すTABLEプロパティ、そして検索するときのキーになるKEYプロパティの3つです。
外部プログラムは、この3つのプロパティに対してsetDBメソッド、setTABLEメソッド、setKEYメソッドの3つのアクセッサを使いますが、実はBeanの業務ロジックではこの引数を取り込まないと処理ができません。このとき使われるのがアクセッサでありgetterメソッドになります。リスト1のソースコードの一番最初にgetDBメソッド、getTABLEメソッド、getKEYメソッドを使って、外部プログラムがセットしてくれた引数を業務ロジックの中に取り込んでいることが分かります。
 |
| 図9 外部プログラムがsetしたら、業務ロジックがgetする |
当然、業務ロジックの処理が終了する直前に、処理結果をプロパティに格納する場合もアクセッサが使われます。リスト1のサンプルでは、検索結果をRESULTSというプロパティに格納しています。このとき使われているアクセッサは外部プログラムがBeanに引数をセットするのと同様にsetterメソッドが使われます。RESULTSプロパティに値をセットするのはsetRESULTSメソッドです。セットされた処理結果は、外部プログラムからgetterメソッドを経由して参照されます。
 |
| 図10 業務ロジックがsetしたら、外部プログラムがgetする |
このように、プロパティにはsetterとgetterがそれぞれ対で作成されて、それが外部プログラムとBeanの両方で使われます。Beanを使うのはとてもややこしいように見えますが、オブジェクトの考え方に基づいて、情報のチェックを行って業務ロジックが失敗なく実行するのを保証したり、不正な値が業務ロジックに入ってこないようセキュリティの確保をすることを目的にしています。
これが結果的にBeanを問題なく稼働させることになり、多くの外部プログラムから共有して使う場合の安全性や有効性も保障することになります。当然この手順は、外部プログラムが活用するBeanの形態がローカルであろうとリモートであろうと関係なく、オブジェクトの考え方に遵守した部品を作成する限り、変わることなく守られた方が良い手順といえます。
 |
3/5 |  |
 |
連載記事一覧 |
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
