シリーズ依存性の問題の対応策の前回書いた内容について。
仕様変更が多かったり、汎用化させたいため、引数を共通化する場合、
１．いくつかの引数を１つのハッシュマップに入れてしまうという方法があります。
この場合、ハッシュマップに入れるときに、クラス化すると、クラスが
変わったことによって、エラーではじくことができます
（あと、ハッシュマップの場合は、キーを変えることでもはじけます）
２．引数を汎用的な型から継承させ、メソッドの引数自体は、その汎用的な型のほうを
書く。
Strutsなどでは、これが利用されています。
画面（フォーム）の値はActionFormという型から継承します。
たとえば、No1ActionFormという画面があったら、
public class No1ActionForm extends ActionForm
{
private String val1;
private String val2;
:
setter/getter続く
}
という形で、ActionFormから継承させて、各画面の値をもつクラスをつくり、
実際に呼び出されるメソッドは
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest req,
HttpServletResponse res)
{
というかんじで、派生させた、ActionFormを引数とします。
そして、executeのメソッドの中で、
No1ActionForm no1form =(No1ActionForm)form;
とキャストして使います。
では、１と２、どのように使い分けるのでしょうか？
■ポイントは、汎用的にやることがあるかと無規則でよいか
世の中の流れ的に言えば、POJO（extendsって書いてない、Javaのオブジェクト、
これでも、オブジェクトからは、継承されてるけど）なんつー言葉が出てくる
くらいですから、あんまり、継承されたくはないということになります。
継承が深いと、「このメソッド、どこのクラスに記述されているの？」なんていう
ことになったり、継承しているものも管理しないといけない（継承元の依存性がかわり、
引数が１個抜ける場合、継承先のものにも影響が出てしまう）など、めんどっちいので。
ただし、以下の２つの場合、あえて継承したのを使うこともあると思います
・汎用的にやることがなにかある
・無規則だとこまる
たぶん、Strutsの場合は前者のような気がします。
システムで、引数に対して、共通に何かしているのでしょう。
この場合は、継承しないとできないので、継承させる必要があります。
無規則だとこまるというケースは、ハッシュマップに入れてしまう場合、
どーにでもいれられるので、それはやだ。なんか、決めておきたいというときです。
まあ、この場合も、将来的に、汎用的に何かやりたい場合が多いんですが
（なので、無規則だと、今はいいけど将来困る）
■逆に、ころころ変わるのは、ハッシュマップに入れちゃうほうがはやい
逆に、継承しないほうがいいのは、引数がころころ変わりそうなとき
（仕様が不安定、あるいはない）。
この場合は、前回のように、クラスにいれてからハッシュマップっていうのもしないほうがいい
単純にキーワードと値の組をputして、ハッシュマップを引数として渡したほうが、
仕様の変更にすばやく対応できる。
てなかんじですかね（＾＾）
ウィリアムのいたずらは、カオル姫方式っぽく、
ハッシュマップになんでも詰め込んでしまうのが
好みです。
アクセス
トータル
ランキング
