ひがやすを技術ブログ

電通国際情報サービスのプログラマ

ダイコン時代の設計手法 - モデリング

モデリングは、

に分けられると思ってます。
振る舞いのモデリングは、ユースケース

  • ユースケース固有のロジック
  • 共通のロジック
  • データアクセスのロジック

にブレークダウンしていくものです。
今回のテーマはデータモデリング


データモデリングは、

の2つのアプローチが考えられます。
どちらを選択するのかは好みの問題なのですが、
DOAの方をお勧めします。
DOAはER分析という確立した方法があるのに対し、
OOAによるモデリングは、いまだ確立したものがなく、
試行錯誤しなければならないためです。


OO原理主義に陥ることなく、常に現実的であれ
ER分析した結果は、テーブルとテーブル間のリレーションで
表現されます。
最初は、テーブルのレイアウトをほぼ一対一にPOJO(JavaBeans)に
マッピングします。
次にリレーションを追加していきます。


リレーションは大きく分けて

  • N:1(自分から見て相手が一意に決まる)
  • 1:N(自分から見て相手が複数存在する)

になると思ってます。
リレーションを追加するのは、N:1のほうです。
1:Nは

  • リレーションが連鎖している場合、どこまでリレーションを自動で解決するかの制御が難しい(状況によって変わる可能性がある)。(リレーションを最初に解決する場合)
  • getterメソッドでリレーションを解決する場合、永続化層以外でSQL文が発行される可能性がある。
  • ソート順が状況によって変わる場合がある。

など、難しい問題があるので、魅力的に見えるかもしれませんが、
使わないことをお勧めします。
1:Nをコーディングしてもたいした手間ではありません。


List employees = dao_.getEmployees(dept.getDeptno());
JavaBeansではなく、Mapを使いたいという誘惑にかられるかもしれません。
型を失うペナルティは予想以上に大きいものです。
コンパイラは怒らないし、コードアシストも効かなくなる。

でも、O/Rマッピングフレームワークって状況によっては必要のないデータも
全部とってくるジャン。効率悪いんだよね。
状況に応じて、JavaBeans作るのも保守が大変だし。
だったらMapが楽でいいジャン。
そんな声が聞こえてきそうです。
ダイコン時代のO/Rマッピングフレームワークは、1つのJavaBeansに
必要なカラムだけをマッピングする機能も必要なのです。


後は、設計が進むに連れて見つかってくる導出属性を追加していくと良いでしょう。


追記:ダイコン時代の設計手法について、気になるテーマがあれば
コメントください。いっしょに考えましょう。

仮面をかぶる

潜在意識は無意識に行動を規制する。逆に言えば、こいつによいイメージをたたき込んでおくとそのイメージのままオートパイロットのように行動できる。これがスポーツ選手のやるイメージトレーニングってやつだ。

私はこれを高2の時からやっている。
イメトレのつもりでも成功哲学の影響でもない。
そう、ガラスの仮面の影響だ。(笑)
1000の仮面を持つ少女、北島まやは時々こうつぶやく


私は仮面をかぶる
そうして、仮面をかぶり役になりきるわけだ。
高2のころの単純な私は、直ぐに影響された。

俺も仮面をかぶろう
かぶった仮面は速水真澄(紫のバラの人)のものだ。
それからいろんな仮面をかぶってきたけど、速水真澄の仮面は
はずしたことがない。
私がもしクールに見えることがあるなら、それは私自身のものではない。
きっと、私から見た速水真澄のイメージだろう。

私に何かあったら(笑)

ひがさんに何かあったときは、たかいさんが、対応する事で決定なのかな?(w
ほとんど、ひがさんがやってるって、考えてみると(考えなくても)かなり、リスクあるよね。。。

No problem。S2のソースなんて誰でも修正できる。
修正が必要になるケースもそんなにないと思うけど。
ほとんどの機能がJUnitでテストされてるから修正した後の
デグレの心配もあまりないと思う。
Undocumentedな機能もないしね。