仕様決めがしやすく、テストファーストにしやすいメソッド、関数の引数の決め方

　伝票指向アプリケーション・アーキテクチャというのがあるそうですね。
　日経システム構築２００５年１２月号Ｐ１２９によると。。
　そこでは、各コンポーネント間でのデータ流通を、伝票という概念に統一させているそうです。

　この考えが、はやるかどうかはさておき、たしかに、（ＪＡＶＡなどでは）メソッド間（Ｃだと関数間）で、受け渡す変数と、返り値を統一すると、仕様決めがしやすく、すぐにテストでき（スタブも、テストドライバもすぐに作れる）、構成管理における、リンクできない問題（引数が違ってリンクできない問題）も解決されます。

---

　具体的にいうと、
　Javaの場合、メソッドの引数をハッシュマップ、返り値もハッシュマップにします。
　perlやPHPの場合、連想配列にします
　Ｃ＋＋やＣでは、
　typedef struct
　{
　　　　char **key;
　　　　void **val;
　} VO;
　というかんじの構造体（Ｃ＋＋の場合は、クラス）をつくり、そのVOとします。

　そうすると、結局、メソッドはすべて
HashMap VOret = methodXX(HashMap VO);
　（methodXXは、どんなもんでもＯＫ（任意のメソッド））
　のカタチになってしまいます。

　で、実際に受け渡したい引数の内容は、そのハッシュマップVOにセットします。
　そして、処理内容は、受け取ったVOにセットし、返します。
　（受け取ったＶＯに、そのままセットし、返します。そのため、このメソッドに関係ない値がＶＯに入っていて、受け取った場合、その値を削除することが、仕様になければ、そのまま返します）。

---

　例を示します。
　今、本来だと、月日をセットし、今年の曜日を数値で返すメソッド、dateToYobiというメソッドがあったとします。そうすると、こんな感じになります。

int yobi = dateToYobi(int tuki,int hi);

　でも、この形式だと、こんな感じになります
　HashMap VO;
// 月(tuki)日(hi)の設定
VO.put("tuki",new Integer(tuki));
　VO.put("hi",new Integer("hi"));

// メソッドは、こんなかんじ
　VO = dateToYobi(VO);

// 結果はVOに入ってる
Integer result = (Integer)VO.get("result");
Integer yobi = (Integger)VO.get("yobi");

　これだけなら、呼び出しが、めんどくさくなっただけです。

　ところが、dateToYobiの仕様が変更になり、年の指定も必要になった場合（そして求める結果は、その指定した年月日の曜日を求める）
　上記の方法だと、
　int yobi = dateToYobi(int nen,int tuki,int yobi);
　に変えないといけません。これを変えるには、引数が変わっているため、すべて、このメソッドを使っているところを変えなければいけません。

　さらに、構成管理の立場から見れば、この関数を、今すぐ変えてしまうと、連絡がまだ行っていない担当者のところは、昔の関数のままなので、新旧の違った引数をもったメソッドが混在し、おかしな動きになったりします。

　ところが、上記のHashMapにいれる方法であれば、
　HashMap VO;
// 月(tuki)日(hi)の設定
　VO.put("version","1.1");
　VO.put("nen",new Integer("nen"));
VO.put("tuki",new Integer(tuki));
　VO.put("hi",new Integer("hi"));

// メソッドは、こんなかんじ
　VO = dateToYobi(VO);

とすればいいだけなので、引数、返り値ともに、ＶＯでかわらず、構成管理上も、新旧のメソッドが混在しても問題ありません。とくにversionがはいっているので、1.1なら、最新のものとして処理し、入ってない場合（本来は1.0とか入れておいたほうがいいけど）だったら、前のバージョンのものとして処理すれば（そのときちゃんと処理するか、エラー表示するかは、実装者がどうしたいかによる））ＯＫです。問題ありません。

---

　この場合、引数が変更になっても対応できるので、とりあえず、メソッド名だけをきめておいて、コーディングしておいてもらい、後から、詳細に引数と返り値を決めることもできます。変更も容易です。

　さらに、引数の形式が決まっているので、すぐに、テストドライバが作れます。
　モジュール名がabcなら、そのテストドライバの呼び方は
HashMap VO = new HashMap();
// ここに、引数がはいるが、あとからきめればよい。
VO = abc(VO);
　なのに、きまっています。

　スタブもとりあえず作る場合は
　public HashMap abc(HashMap VO)
　{
　　　　return VO;
　}
　と、すぐ作れます。引数については、あとから決まったときに追加すればいいです。

　そして、テスト結果表示も、呼び出し前のＶＯの値と、呼出し後のＶＯの値を表示するだけでＯＫです。

---

　上記の説明では、引数の個数が変わったケースですが、型が変わったケースでもＯＫです。
　たとえば、上記の場合、年月日を String YYYYMMDD;のカタチであらわすことになった場合、
int yobi = dateToYobi(String YYYYMMDD);
　だと、新旧の物が混じると、リンクできなくなるかもしれませんが、HashMap VOを使うケースだと

HashMap VO = new HashMap();
VO.put("version","1.2");
VO.put("ymd",YYYYMMDD);
VO = dateToYobi(VO);

　となるだけなので、まったく問題ありません。

---

　上記の説明は、Javaでしたけど、perlやPHPなら、HashMapの代わりに連想配列を使っていただければ、同じことができます。Ｃの場合は、上記にあげた構造体で、keyの文字列の配列と、値(val)のvoid*の配列に、値をセットしていれることになります（put,get,freeの関数は作っておくべきでしょうけど）

　で、これらのことは、特別な技術を導入する必要もなく、ただ、コーディング規約を、このように決めてしまえばいいだけです。

　現状では、アーキによっては、こういう仕様がくるのですが、
　（ただし、本人が、このようなことを理解してやっているかどうかは疑問）

　普通は、こういう仕様にならず、
　int yobi = dateToYobi(int nen,int tuki,int hi);
　のような仕様になるので、とーぜんのことながら、構成管理に失敗し（新旧のモジュールが混じってしまったり、前のに戻せ！（新しいのが間に合わないため）とかで、現場混乱、テストモジュールもすぐに作れず。。。とかで、えらい開発が大変になったりします。

　大きなシステムになればなるほど、仕様は決まらないので、この差は大きいですね。

　つまり、アーキの読み、ないしは、ウィリアムのいたずらのブログを見ているかどうかで、多くの人が残業になるかどうかがきまるということです（うん、前者はそのとおりだが、後者はそうなのか？？）

---

　なお、HashMapでなく、これをＸＭＬのDomでやってもＯＫではあるのですが、Ｄｏｍの場合話が複雑になる（入れ子が容易にできるため、複雑な引数にされてしまう）ことがあるので、HashMapのほうが、仕様を切りやすかったりします。

　とはいえ、どっちでもいいんですけどね。。。