実際には、非効率的でも、新しいものをやりたい上の若手の人やお客さんの意見にきまってしまう。

　さっきのブログでは、ＤＢアクセスなどで、
３．入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
４．入出力用のハッシュマップを使い、１つのクラスで行う

　だと、宗教上の理由で３になると書きました。
　その意味と、説明を書きます。

---

　実際に、どのように作るかという場合、工数的に楽とか、効率的とか、リスキーでないというよりも、

・現在の流行の人たちが、主張している意見とか、
・トレンドの流れから、そっちのほうがおしゃれな場合、

　そっちのほうの意見になります。

　ひどい場合なんかだと、本やネットで読んだくらいで、プロトも、てきとーに本にでているものを応用したくらいのものを作った状態のものでも、そっちがトレンドだと、やってみようと言い出す人がいます。
　コンピューター関係者以外だったら、ありえない！と思うでしょう。
　自分で、徹底的に使いこなして会得していないやつ、そんなリスキーなものを、平気で使うなんてと。。でも、今のコンピューター業界は、この流れが多いです。

　そのカラクリは、こんなかんじです。

---

　最近、オフコンを使ってＣＯＢＯＬで開発するっていう話、聞かないですよねえ。。。あんまり
　（まあ、売っていないということもあるが。。。）
　ＣＯＢＯＬでの新規案件って、かなり少ないと思います。

　でも、ＣＯＢＯＬとＪａｖａでは、どっちが生産性が高いかっていうこと、自分で書いて比べている、若い人は少ないと思います。最近の若い人の中には、ＣＯＢＯＬを馬鹿にするわりに、自分で書いてなかったりします。

　ＣＯＢＯＬでも、オフコンの富士通Ｋシリーズの場合には、画面もＤＢも、まったく同じレコード構造に入ってくる上、それらはツールで作成でき、画面側でエラーチェックしてくれるし、画面操作をレコード内の値を設定することでできる（レコードのある箇所に値を入れるとプロテクトになる）ので、生産性は高いです。

　でも、今ＣＯＢＯＬの、そういうものを使うという意見はありえないし、それどころか、その考え方をJavaにとりいれ、画面から、ＤＢから、すべての情報を１レコード、HashMapの中に入れるというような考え方をする人もいません。絶対いません。ただみんな、やってないけどばかにするだけです。人を馬鹿にするくらいだから、昔の技術なんていうことを、聞かれることもありません。

　２００７年問題とは、ＣＯＢＯＬを継承することではなく、それを言葉をネタに、新しくリプレースするためのセールストークです

---

　そんな感じで、この業界は、まったく新しいものが常に出てきて（といっても、昔の焼き直し＋あるふぁだったりするんだが）、それが妄信的に信じられ、宗教的になり、若手のプロジェクトマネージャーやアーキテクトクラス、プロジェクトリーダークラスのひとが、「絶対とりいれるんだ！」といいはります。なぜいいはるか、おしゃれでかっこいいから、今の仕事が面白くないから。

　で、営業はそれに乗ります。なぜなら、新しい考えのほうが、「売れるから！」

　なぜ、売れるか。。。お客さんが、新しい考えのほうが、先進的でかっこいいから、
　新しい、先進的技術を導入すると、売り上げ、生産性あーっぷと思って買っちゃうんですねー
　（実は、儲かるかどうかというのは、お客さん自体も、わからないし、検証してないことが多い）

　そのため、この業界は、宗教的にその考えを取り入れる（＝事前に批判的に検証していないで、盲目的に、その意見は正しいと思い込む）ことになり、神学論争に発展します。
　はたからみると、「それって、どーでもいーじゃん！」っていうことを、熱心に議論したり、やたら、難しい言葉をとりいれるのです。。。

　「どーでもいいじゃん！」などと、言ってはいけません。
　かれらは、それを主張することにより、先端をやっているというプライドと居場所を確保するのですから。

　そのような考えが出てきたら、営業といっしょに、「すばらしい！」といっておきましょう
　（営業はそのような考え、大歓迎です。なぜなら、「売れるから」）

---

　で、じゃあ、ウィリアムのいたずらのような、こっぱワーカーさんたち（末端の作業する人たち）は、どーするかというと、

　上の若手のえらーい人たち（でも、えらーいといっても、２次請けとか３次請けクラスなんだけどね）がいう技法で、本当にできるかどうか検証し、その考え方が、受け入れられない（明らかに破綻する）ときだけ、反対します。

　それ以外は、反対してもあんまり、意味ないので（反対すると、すげー、若手の上のほうの人から文句言われる割には、メリットがない。なぜなら、どんなやり方をしても、たいして、かわんないから、つーか、どんなやり方、どんな言語でも作れないと、いま、お仕事つづかない）はんたいはせず、対処法だけ考えます。

---

　つまり、３のやり方が多い理由は、今、それが、トレンドだからです。
　それ以上でも、それ以下でもない（おれは、ぷっちゃんか。。。極上生徒会を見てない人には、わからないと思うけど）

　で、さらに、この宗教には、宗教改革があるんだな（＾＾）ｖ

ＲＤＢで１００個テーブルがあると、１００個のクラスを作るが、実は１個のクラスだけでいい方法がある

　きしださんのブログに、ソフトウェア技術者は自分たちが哲学を行っているということを自覚すべきという記事があります。
　この記事は、そのとおりに思います（ただし、最後のほうの「メシ食わせろ」の意味は通じていませんが。。元がわからないので）。なんたって、「開発思想」なんていう言葉があるくらいで、昔のドキュメントには、延々と、それがかかれてましたから・・

　で、最近は、哲学通り越して、神学論争、さらには、宗教まで発展していると思います。
　そんな具体例をひとつ。

---

　このブログで、データベースのテストのお話を書いたとき、（１，２は省略）

３．入出力用のハッシュマップを使い、テーブルごとにクラスを作成する
４．入出力用のハッシュマップを使い、１つのクラスで行う

で、３について説明し、４はあまりないと書きました。

　つまり、現在の主流の考え方は、３の、テーブルごとに、クラスを作るという方法です（ハッシュマップにするか、データ受け渡しのクラスにするかの差はありますが）。
　こうすると、ばりゅーおぶじぇくととかＰＯＪＯとかの話が出てきて、かっこいいです。
　そいから、O/Rマッピングの話におとしこめて、Hibernateとか知ってるよ！使ってるよ！っていうと、かっこいいです。先端っぽいです。だから、みんな、こっちを使ってますよね。

　ウィリアムのいたずらも、こちらの自動化の話しかきません。

---

　でも、きっと、みんな、知っていると思います。
　しってるけど、いえないんだと思います。

　匿名（ウィリアムのいたずらというハンドル名しか、皆さんはしらない）ということで、この際言ってしまいましょう。

　「多くのプログラムでは、ＤＢアクセスクラスは１つですみます。さらにそれは、ファイルやEJB,SOAで、リモート先にアクセスでも、全部、そのクラスがかぶることができます。」

　こうつくります。

　さっき出した、ここのブログのメソッドに、テーブル(selectの場合From句、insertの場合into句など）を指定する引数を追加してください。そうすると、できます。
　Where句の作り方は、そのあとの説明「入出力用のハッシュマップを使い、テーブルごとにクラスを作成する」プログラムの中身のはじめのほう（もしくはの前まで）のやり方でできます。つまり、ハッシュマップで型がわかるので、それをもとに作ります。

　項目指定は、ならべればいいだけだし。。。

　ということで、From句の問題です。

　ここは、AccessとほかのＤＢで異なります。ほかのＤＢなら、テーブル名だけを並べておけば、自然結合してくれます。Where句の内容とかみて。。でもAccessは、Join－on指定が必要です。
　したがって、String MakeLeftJoinState(String imamadeNoState,String tbl,HashMap onKu)のようなメソッドを作って、on句の条件と、Joinするテーブルと、その前までのステートメントを引数として渡して、LeftJoinしたステートメントを返す（あるいはRightJoinしたステートメントを返す）メソッドをつくる必要があります。

　なんですけど、とにかく、そんなこんなで、クラスは１つにまとめられます。

---

　しかし、宗教上の理由から、このようにクラスを１つにまとめて使うという開発には、「私は、大きい仕事では」やったことないです。いつも、上の形です。（私が、大きい仕事でやったことないというだけで、ほかの人はあるんじゃないかな？また、自分で勝手にできる場合は、こっちを使っちゃうかな。。）

　その宗教上の理由とは。。。

　ひえー、こんな時間だ。。覚えていたら、今度書きます。