前回書いた、オブジェクト指向で、修正による影響をうけにくくする方策の続き。
オブジェクト指向はもともと局所差異があるから、修正しやすいはずなんだけど、局所性ゆえに、周りが見えにくくなる。そこで、適切な局所性をするには、
・業務プロセスとエンティティを明確に分けて、
・エンティティは１事実１箇所で
という話になってくると・・で、「エンティティは１事実１箇所」っていうのは、ER図を作るときのDBとおなじで、これを実現するには、独立性と一貫性を持つ必要があると・・
で、前回は、独立性の話で、これは
・正規化によりエンティティを分離し、
・業務プロセスで利用するときには、DBのビューのように、使いやすいクラスをつくれば、
業務プロセス部分の修正に影響を受けない
という話でした。
今回は、おかしくなるのを防ぐというより、おかしくなったら、すぐ気づくようにする話
つまり、おかしなデータが入らないようにチェックする話。
DBだと、一貫性の話です。
■一貫性を担保する－チェック
DBで、一貫性は、参照制約とかつけているけど、オブジェクト指向のクラスの場合
・参照制約同様、複数のクラス間に関するもの（親が存在しないといけないとか）
・属性値の問題（受注金額＝負の数は不可など）
の大きく２通りが考えられる気がする（もっとある？）
で、この場合、Javaなら、setterでチェックすれば良いように思うかもしれないけど、
setterは、ふつうvoidで返すので、チェック結果を返せない（まあ、クラス内の属性にerrno
ってとっておいて、それでチェックしてもいいけど・・ま、それはめんどっちい）
■どこで何をチェックするか
そこで、普通は、追加、削除、編集する際にチェックするということになる。
なお、検索するときには、エンティティを書き換えていないので、検索できないだけで問題はない・・・はずだが、SQLインジェクションされてしまえば終わりなので、SQLインジェクション対策は必要になる。
追加、編集は、値チェックと、関連性チェック、削除は関連性チェックになります。
値チェックは、範囲内か？とか、それこそ、ある１つの値を、正規表現使ってチェックみたいなかんじ。
関連性チェックは、親が存在するかとか、この値だと、他のオブジェクトがある値のはずだけど
（受注キャンセルできるのは、出荷前のはずで、それ以降は返品処理のはずだけど・・とか）・・
とか、２つ以上（場合によってはそのオブジェクトだけでは、チェックできないことも）のもの
に関してのチェック。
ってことになる。
■インターフェース部分でチェックするのが、効率的かも・・
じゃあ、なんでもチェックすればいいか？っていうと、
チェックだらけになってしまう。
一方、チェックしないと、そのメソッドやクラスの中身を知らないと、
変な値を入れてしまって、おかしな動作させてしまうかもしれない。
どこでちぇっくするのがいいか・・・
というと、インターフェースとして、公開しているところ
ということになる。
人とコンピューターのインターフェースは、
ビューであり、これは、JavaScriptで、画面チェックということになる
サーバーとクライアントというか、業務プロセス（サービス）提供部分は、
コントローラーのサーブレットでチェック。
業務プロセスとエンティティの関係は、
エンティティのクラスのところの追加、編集、削除関連メソッド（上記）
って感じになると思う。
とりあえず、ここまで。
アクセス
トータル
ランキング
