きしださんのブログに、ソフトウェア技術者は自分たちが哲学を行っているということを自覚すべきという記事があります。
この記事は、そのとおりに思います(ただし、最後のほうの「メシ食わせろ」の意味は通じていませんが。。元がわからないので)。なんたって、「開発思想」なんていう言葉があるくらいで、昔のドキュメントには、延々と、それがかかれてましたから・・
で、最近は、哲学通り越して、神学論争、さらには、宗教まで発展していると思います。
そんな具体例をひとつ。
このブログで、データベースのテストのお話を書いたとき、(1,2は省略)
3.入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
4.入出力用のハッシュマップを使い、1つのクラスで行う
で、3について説明し、4はあまりないと書きました。
つまり、現在の主流の考え方は、3の、テーブルごとに、クラスを作るという方法です(ハッシュマップにするか、データ受け渡しのクラスにするかの差はありますが)。
こうすると、ばりゅーおぶじぇくととかPOJOとかの話が出てきて、かっこいいです。
そいから、O/Rマッピングの話におとしこめて、Hibernateとか知ってるよ!使ってるよ!っていうと、かっこいいです。先端っぽいです。だから、みんな、こっちを使ってますよね。
ウィリアムのいたずらも、こちらの自動化の話しかきません。
でも、きっと、みんな、知っていると思います。
しってるけど、いえないんだと思います。
匿名(ウィリアムのいたずらというハンドル名しか、皆さんはしらない)ということで、この際言ってしまいましょう。
「多くのプログラムでは、DBアクセスクラスは1つですみます。さらにそれは、ファイルやEJB,SOAで、リモート先にアクセスでも、全部、そのクラスがかぶることができます。」
こうつくります。
さっき出した、ここのブログのメソッドに、テーブル(selectの場合From句、insertの場合into句など)を指定する引数を追加してください。そうすると、できます。
Where句の作り方は、そのあとの説明「入出力用のハッシュマップを使い、テーブルごとにクラスを作成する」プログラムの中身のはじめのほう(もしくはの前まで)のやり方でできます。つまり、ハッシュマップで型がわかるので、それをもとに作ります。
項目指定は、ならべればいいだけだし。。。
ということで、From句の問題です。
ここは、AccessとほかのDBで異なります。ほかのDBなら、テーブル名だけを並べておけば、自然結合してくれます。Where句の内容とかみて。。でもAccessは、Join-on指定が必要です。
したがって、String MakeLeftJoinState(String imamadeNoState,String tbl,HashMap onKu)のようなメソッドを作って、on句の条件と、Joinするテーブルと、その前までのステートメントを引数として渡して、LeftJoinしたステートメントを返す(あるいはRightJoinしたステートメントを返す)メソッドをつくる必要があります。
なんですけど、とにかく、そんなこんなで、クラスは1つにまとめられます。
しかし、宗教上の理由から、このようにクラスを1つにまとめて使うという開発には、「私は、大きい仕事では」やったことないです。いつも、上の形です。(私が、大きい仕事でやったことないというだけで、ほかの人はあるんじゃないかな?また、自分で勝手にできる場合は、こっちを使っちゃうかな。。)
その宗教上の理由とは。。。
ひえー、こんな時間だ。。覚えていたら、今度書きます。