XMLからJava自動生成その４:XMLの内容をHashMapに入れるクラス、まとめました

　ちょっと前のブログ「XMLからJava（以外もOK)自動生成その３:DOMで、属性・テキスト・タグ名取り出し（２）」のプログラムをすこし変えて、

ＸＭＬファイル名を指定して、メソッドを呼び出すと、
　　その構造を解析して、HashMapに入れるクラス、

つくっておきました。

　やっぱ、ＨａｓｈＭａｐとかＶｅｃｔｏｒになってないと、使いにくいですよね。

---

　Javaのソースプログラムは、こちら

　そこで、staticになっている、fromXmlToHashmapメソッドを

// XMLファイルをハッシュマップに変換する // inFnameは、ＸＭＬファイル名 　　　 HashMap mp = XmlHashMap.fromXmlToHashmap(inFname);

の形で、使います（mpに結果が返ってくる）

　帰ってくるHashMapの中身などについて、書いてあるのはこちら

---

　もちろん、勝手に使ってかまいませんが、まったくの無保証です。修正して使っていただいても、ＯＫっす（というか、たぶん、パッケージとかは変えるだろう）
　現在は、最後のノード（つまり葉）にしかテキストデータがない場合について対応していますが、そのうち、どこにテキストがあってもＯＫというようにしたいと思ってます。
　あと、将来的には、書き出しもいれるかも。。。

　ということで、今、公開しましたけど、今後、もっと増えていくと思います。

単体テストの議論では、世代間のシステム設計法（思考法）の違いを考慮しないと。。

ちょっと、最近のブログの単体テストの議論で、
　・システムの共通部分と
　・実際の業務開発と
　・テスト部分と
　・若手（２８歳くらいまでをさしましょうか）への指示を出している
人が分業されているせいか、話が？？？と思うことが多くあります。

　なんで、ちょっと、「ウィリアムのいたずら」が思うことをかいときます。（最後にも書いてありますが、ウィリアムのいたずらが思うことであって、ブログを引用している人の考えとは違ったりしている可能性もおおいです。あくまで、それらのブログを見て，ウィリアムのいたずらが、感じたこと、思いついたことを書いています）

---

単体テストの議論で

・単体テストをしなくてもいいようなプログラムがある。 　　　マスタメンテナンス的な業務ロジックが存在しないようなシステムなら

　という議論を認めた場合、
　最近の若手が設計するシステムって（本来業務ロジックが存在するようなものでも、存在しないように書いてしまうから）、マスタメンテみたいなかんじのばっかりになっちゃて、単体できないっていうことが、あるんです。

　で、この議論が間違いだとすると、「じゃあ、どういうふうにテストしろというの！」って聞かれちゃうと思います（プログラムが切れないので、単体テストのしようがない）

---

　たぶん、これらのブログを書いている人が、自分の立場を特定されないため、あまりにも抽象論で書いているので、話が見えなくなっていると思います。具体論でいきましょう（まあ、この程度なら、ばれないだろう。身元は ^^;)

在庫管理システムをＷｅｂでつくる

としますよね。

たぶん、若くないＳＥさん（ここでは、３３歳以上をさします。語弊ある？？）だと
（１）ＭＶＣにもとづき、画面系とモデルをわけ、
（２）在庫数は、棚卸数と入出庫業務からもとめるモデルを作成し
　　　（あるいは現在商品数を書き換える方法もあるけどね）
（３）ＤＢ部分、画面部分を切り分ける
っていうふうに書きますよね。

---

ところがね、若いＳＥさん（２８歳以下、語弊ある？）はちがうのよ。
（１）ＵＭＬにもとづき、業務分析をおこなう
（２）そうすると、システム入ってない会社の在庫って、たいてい商品台帳を直してますよね
（３）なので、商品台帳テーブルを作成し（商品と倉庫ごとに、現在数を持つ形）
（４）Strutsでやるとすると、Actionメソッドに、SQL文を直接書いて、商品台帳テーブルを更新するプログラムを書くのよ(@_@)!

　まるで、商品台帳テーブルをマスタテーブルとして、画面の文字をＳＱＬ文に入れて更新、検索するだけのマスタメンテ的プログラムが乱立しちゃうのよ(@_@!)
（複雑な検索は、あらかじめViewを作成しておく。結果として、Viewの乱立になるが。。。）

　そこで、「マスタメンテのような業務ロジックがいらないプログラムは単体テストがいらない」とすると。。ね、単体テストがいらなくなっちゃうでしょ!（つーか、できないでしょ）
　でも、Actionメソッドにすべて埋め込み、ＤＢをいきなり更新するプログラムが一杯できて。。。
　わけわかんねえーっていうか、ロジック合わなくなっちゃって！
　（なぜ、合わなくなるかは、後日書きます。これだけでは、ロジックを合わせられるのですが、仕様変更が入ると、おかしくなってしまうのです）
　おかしなはなしになっちゃうわけ。

　単体テストができない！っていう話で、ロジック部分が分かれていない場合、この考えで進んで、仕様変更がおきて、おかしくなったっていう話が結構あると思う。

---

　若くない人は、この構図を頭に入れて、「納期を守るために、ドライバやスタブは作ってられない」って言う言葉を読みましょう。
　そうしないと、この文、意味通じませんよね。

　若くないＳＥさんのやり方だと、モデル部分とＤＢ部分、画面部分は分けて開発するので、テストどころか、ＰＧのかなり早い段階で、ドライバやスタブは出来ている（そうしないと、eclipseで赤いＸがついて、リンクできないじゃん！）言い換えると、「納期を守るために、ドライバやスタブは作ってよ！」ってなるのに？？？

　ただ、若い人のやり方だと、Actionメソッドにいきなりデータ操作を書く話になるので、これだと、スタブの作りようが無いのよ。せいぜい、Ｏ／Ｒマッピングみたいにして、ＤＢ部分を分離して、そこにスタブをかくだけ。。。でも、もう、ＳＱＬ直接発行してたら、それも、意味ないでしょ。ってなっちゃうわけ。

（したがって、「ホワイトボックスレベルの単体テストをやるべき」と「納期を守るために、ドライバやスタブは作ってられない」っていうのは、対立している話でなく、どちらも、初めに採用したアーキテクチャの失敗（＝アーキが汎用フレームワーク(Strutsなど）をプロジェクトのリソースに合うようにカスタマイズする時点の失敗）の傍証をしている可能性が高い）

---

　そこで、単体テストをやるとすると、　 「このつくりで業務ロジック部の単体テストはできますか？」と書いてある人がいるように、システム設計部分から業務ロジック部分をわけて、（単体テストができるような設計）にしないと、いけないんだけど、若手の人は、「なぜ、そういう設計をしないといけないのか？、どうしてActionメソッドにすべてを書いてはいけないんだ（コントロールにすべてをかいてはいけないんだ！）」という、明確な答えが無いから、？？？なわけよ。

　なんで、そこを説明しないといけないわけよ。

　で、そこ説明しようと思ったんだけど、書くと長くなりそうなんで、またいつか（たぶん、次回ではない。次回は違う話の予定）。

＊今日の話で、いろんな人のブログから引用しています。
　それぞれの引用箇所には、リンクを張っておきました。
ただし、リンク先の人が、ウィリアムのいたずらと同じ文意で、この言葉を書いているかどうかは疑問です（というか、ちがう気がかなりする）。

＊ブログの文字の大きさ実験中。今日は、おおきくなってるかも？？