2007/03/24

[Java]Code Value Type

とあるコード値を受け取るとき、そのフォーマットが正しいかどうかをチェックする必要が出てきて、コードが無駄に増えるし、チェック内容にぶれがある。それに、パフォーマンスが悪くなる。
という相談を受けた。適当に、顧客コードというものを仮定して、形式を考えてみる。
顧客コードの形式
名前桁数意味と形式
法人/個人10,1のどちらか
番号80~99999999までを、ゼロ埋めしたもの
チェックサム1妥当性検査用。0~9のどれか

単純にStringとして使っていた場合の問題点を挙げてみる。
#上で相談してきた内容そのものなんだけど
適当な文字列も渡せるので 桁数、各桁の文字がとりうる値、チェックサム のそれぞれをチェックする必要がある。そうすると、メソッドやコンストラクタは受け取った顧客コードを常にチェックを行う必要がある。妥当性チェックの内容を"数字としてパースできるか?"のように中途半端な上に体系の変更に対応できない形で勝手に実装する人が出てくる。チェックにかかるコストが無駄になる。

んで、対応はというと、顧客コード型 というクラスを作ってしまうこと。そして、そのインスタンスを生成する段階で、文字列の妥当性チェックを行う。内部で使うときは、Stringではなく、顧客コード型で使用する。これで、間違ったものを渡そうとした時点でコンパイルエラーになるし、チェックは外部(画面とか、ファイルとか、DBとか)から文字列として受け取る箇所だけでいい。体系変更があった場合、一箇所を直せばいい。あと、toStringメソッドが文字列表現を返すようにしておくと、出力が楽になるのでオススメ。

そのほかのメリットとしては、法人/個人の区別を知りたい というような内容を、顧客コード型のメソッドに実装できること。この手のユーティリティがstaticメソッドとして大量に作成されているプロジェクトでは、同じユーティリティがいくつも作成されているのを見かけることが多い。

ラベル:

2007/03/18

PASMO & Suica on Mobile

PASMOのサービスが始まって、Suicaでも私鉄に乗れるようになった。

今住んでいる所が東西線とJRがかぶっているあたりなので料金の体系には要注意。高くなるところがあるらしい。
ただ、定期も含めての計算がどうなるのかよく分からない。定期区間外→区間内→区間外と移動して、かつ私鉄とJRの改札がかぶっていて…なんてのはどう計算すればいいんだ?それぞれの区間について、定期区間内/区間外、路線がJR/私鉄、カードがPASMO/Suica、定期が連絡/普通 のパターンがあるけど、それをまとめたサイトが見当たらない。

それにしても、休日なんかの行動範囲はJRでモバイルSuica、通勤は私鉄のみの区間でパスネット という状態になっているので、一つにまとめられるのはうれしい。
それに、通勤を定期にしてしまいたいというのもある。いま定期にしていないのは面倒だからというだけなんだけど。ケータイの画面から買えるならそうしたい。
ただ、私鉄オンリーの定期はSuicaに入らないらしい。休日に使っているJRの区間との連絡定期という形にするかなぁ。ちょうど反対方向に使ってるから問題はないハズ。(同じ方向だと、JRの定期で東西線使ってることになる…のかな?)でも、現状と比べると利便性と料金のトレードオフが難しいな。

あと、気になるのはモバイル対応。対応することになったとして、同じケータイにPASMOとモバイルSuicaが入れられるのかということ。どっかのコンビニで、一つのリーダでお財布ケータイを使うために、客がどの機能(Suica/Edy/iDかな?)を使うか選択させていた気がする。コレでいくと、改札でPASMO/Suicaをいちいち選択することになる。…ありえないよなぁ。どちらを優先させるのか設定するか、一方しかインストールできなくするか。
優先順位を付けるってできるのか?>Sony&DoCoMo

因みに、FeliCaチップの容量という面では大丈夫だと思う。Suicaはチップの容量喰いすぎといわれることが多いけど、あれは領域を論理分割してるせいで一般のアプリから使えなくなってるだけのはず。Suicaが入っている側の領域にはPASMOを入れるだけの容量は残っているはず。中の人じゃないから仮定だけど。