jjlehto
jjleh****@users*****
2004年 2月 7日 (土) 13:30:39 JST
Nishinaです。
>■その1
>「ちょろりと使ってみようと思えばさらりと書けて動くこと」
>
>もうちょっと分かりやすくいえば、
>詳しいことを良く知らなくても、Strutsの使い方をある程度知っていれば
>簡単に使えて、T-Strutsの機能がその裏で稼動しているというような。
クラス、メソッド名の付け方、引数の渡し方等、細かい所でもStrutsに合わせた
方がいいでしょうね。
>■その2
>「少しずつ学んでいけること」
>何か一つ新しい機能を使おうと思ったとき、
>それを使うにはあれもこれも同時に知らなくてはならない、という状態にしない。
そうですね。
常に使い手の気持ちで。
>■その3
>「普通の使い方が最も簡単な書き方になるようにすること」
>
>「普通」の判断が難しいところですが、これはみんなで議論しましょう。
>一般的なニーズを満たすための定義・コーディングをするための方法が、
>最も手数が少なくなるようにします。
いいと思います。
>■その4
>「それでいて、凝ろうと思えばどこまでも細かくいろんなことができること」
>
>理解すればするほど
>・細かい調整ができ、
>・細かいニーズを満たすことができ、
>・チューニングをしていける
>こと。
まさにStrutsですね
>その2のあたりもTurbineはいまいちですね。
>使おうと思ったら知らなきゃならないことがたくさん。
そう思った時点で引いてしまいますね。
その辺をサポートするツール等があればまた別なんですが。
>私が入れるか入れないか迷っているのは、
>「システムを作っていくうえで、やっておいたほうがいいことを
> やらないといけないように強制する」
>たとえば、
>・ログはログ文言を直接logメソッドに渡すんじゃなくて、
> IDとメッセージの定義をしておいて、IDをlogメソッドに渡すように
> するべき
>という慣例というか、お作法があったとして、
>それを強制するために、logメソッドにはIDしか渡せないようにしてしまう、
>とか。
>
>「やっておいたほうがいいことを、簡単にやれるようにしておく」
>というのはあるんですが、「強制する」というのはまた別の話ですしね。
>
>黒澤はそれが例え良いことだとしても、何かを人に強制されると
>やりたくなくなっちゃったりするタイプなので、迷うんですねー。
この辺は本家Strutsの設計者さんの思想と違ってくるかと思います。
私自身は強制されるのは嫌ですが、
慣例、お作法を知らない人もいますし、
メンテナンス性が上がったり、利点が多いのであればやってもいいと思います。
それか強制するクラス、強制しないクラス２つ作るとか・・・
┌────────┐
│強制しないクラス│
├────────┤
├────────┤
└────────┘
↑extends
┌────────┐
│ 強制するクラス │
├────────┤
├────────┤
└────────┘
※強制するクラスの使用を推奨させる