06/11/30 00:02:12
>>851です、こんばんは。
Mayaaに１票はいりましたので、評価したいと思います。
が、アーキ的にJSP+Strutsよりコスト安になるとは思えないの
ですが。
コストが高くなるが、メンテしやすさが上がる感じになるのでしょうか？
>Mayaa導入済みの皆様。
.mayaaファイルのジェネレータとか落ちて無いかな。。。
863:デフォルトの名無しさん
06/11/30 00:08:07
JSP+Strutsは高いと思うぞ～～
864:デフォルトの名無しさん
06/11/30 09:34:38
>>864
S2Struts +JSP2.0 + JSTLであれば
それ程高いとは思わないな
教育コストを考えたら、そう簡単にJSPは切れないよ
865:デフォルトの名無しさん
06/11/30 10:04:55
このスレ、死んだと思って見てなかったら
随分盛況になってる！！！
シーサーって人気あるんでつね！？
866:デフォルトの名無しさん
06/11/30 10:13:20
>>862
Mayaa マタタビ
でぐぐってみよう
867:デフォルトの名無しさん
06/11/30 14:29:06
URLﾘﾝｸ(teeda.seasar.org)
見えないよ ＞＜
868:デフォルトの名無しさん
06/11/30 14:32:19
>>867
なにが？
おまいの会社のプロクシでアク禁とかだったら爆笑だな！
869:デフォルトの名無しさん
06/11/30 15:26:14
>>868
今見えた♪
書き込み乙ｗ
870:デフォルトの名無しさん
06/12/01 04:34:42
SeasarConのビデオ配信って12/6,7のやつを見逃したらもう見れないの？
Ｗｅｂで公開するのに時間に縛られるって何打それって感じなんだけど。
だれかyoutubeにうｐして。まじで。
871:デフォルトの名無しさん
06/12/01 11:45:06
Teedaのexampleで遊んでるんだけど、
入力チェックエラー時のメッセージってどこに登録されてるの？
Teeda Hackerな人教えてん。
872:デフォルトの名無しさん
06/12/01 12:17:19
>>871
javax.facesのMessage.properties。
873:デフォルトの名無しさん
06/12/01 13:33:14
>>872
ありがとう。
まだファイル見つけられないんだけど(汗)、
jarの中に入ってるのかな？
もうちょっとがんばってみるｗ
874:デフォルトの名無しさん
06/12/01 13:48:49
~/teeda-html-example/src/main/resources/appMessages_ja.properties
このファイルｼﾞｬﾏｲｶ？
875:デフォルトの名無しさん
06/12/01 14:24:26
>>874
そのファイルかと思ったんだけど、
入力チェックエラー時に表示されるメッセージは
登録されてないんだよね。
JSFの知識がないから、見つからないのかな？(汗)
shotたんのブログで質問してみようかしらｗ
それにしてもTeedaでの開発すごく簡単そうでつ。
876:デフォルトの名無しさん
06/12/01 14:56:07
>>登録されてないんだよね。
いや、>>874のファイルには最初から記述されてないのは当然で、
自分でkeyとvalueの形式で書くんｼﾞｬﾏｲｶ?
877:デフォルトの名無しさん
06/12/01 15:05:16
そもそも、デフォルトのメッセージのファイルを探してどうするつもりなのか。
自分でカスタマイズしたいのなら自分で適当な場所に適当に作って
faces-config.xmlに登録すればいいのだけれど。
878:デフォルトの名無しさん
06/12/01 15:21:28
>>876, 877
どの入力チェックでどのkeyを指定するのか知りたかったのさ（恥）。
この辺はJSFの知識が関係してくるの？
低レベルな質問なので出直してくるｗ
879:デフォルトの名無しさん
06/12/01 15:30:29
>>878
後に続く者の為に解ったらココに結果を書くのだ。
880:デフォルトの名無しさん
06/12/01 15:37:06
>>878
JSF仕様だよ。Spacificationを読むのが一番手っ取り早い。
881:デフォルトの名無しさん
06/12/01 15:43:42
>>880
JSFの概要をまず理解してみる。
ありがとう。
882:デフォルトの名無しさん
06/12/01 18:57:58
>>875
teeda-core-xxx.jarのjavax.facesにあるよ。
JSFの知識とかなくても気軽に質問しておｋ。
883:デフォルトの名無しさん
06/12/01 20:01:50
>>882
ありがとーーー！
このファイルにやっと出会えたでつ(おそっ)。
もしかして あなたはshotたんでつか？ｗ
Converter, Validatorの細かい仕様とかソース見て分からなかったら、
また質問しまつので、その時はよろしくですっ！
884:デフォルトの名無しさん
06/12/02 00:35:00
>>875
コードと仕様書を読め。
わからなければ、Springを使え。
以上。
885:デフォルトの名無しさん
06/12/02 02:11:28
そういう杓子定規的なこと言う香具師はキライです
886:デフォルトの名無しさん
06/12/02 02:18:23
>>885
同意。マンネリつかワンパターンで工夫がないよね。
リアルでも笑い取れないタイプなんだろうな…
ｶﾜｲｿｽ
887:デフォルトの名無しさん
06/12/02 03:56:41
>>886
ここでは>>884は
横山ホットブラザーズの「お前はあほか」
みたいなもんだよ。
888:デフォルトの名無しさん
06/12/02 07:49:46
ここでは887は
お年寄りがわけのわからない例えを出して意味がわかってない若者を見て
最近の若者は・・・とほくそえむようなもんか。
889:887
06/12/02 10:42:17
こないだとんねるずの番組に出てたから
少しは通りがいいかなと思って。
本当は玉川カルテットの
「あたしゃもすこしセガ欲しい」
にしようかと思った。
これだから最近の若者は・・・
890:デフォルトの名無しさん
06/12/02 16:08:13
くだらない事言ってないで
休日くらい家族サービスしてください。
おじさん♪
１人家族なら好きなようにしてokです。
891:887
06/12/02 16:13:24
最近冷戦中なもんで
家にいると息苦しいんだもん。
無理くり仕事作って会社にプチ家出。
これだから最近の・・・
892:デフォルトの名無しさん
06/12/02 16:29:50
インポってこと？？？
893:887
06/12/02 17:57:11
インポだったらどんだけ気が楽か・・・
894:デフォルトの名無しさん
06/12/02 19:06:00
妻の不倫ｷﾀｰ！
895:デフォルトの名無しさん
06/12/02 19:48:42
インポってエロイ事考えてもたたないの？
それともエロイ事考える気も起きないの？
896:デフォルトの名無しさん
06/12/02 22:43:36
別の女が相手なら勃つ！
897:デフォルトの名無しさん
06/12/03 00:43:27
S2DxoとかTeedaみてると
コントローラの部分はPageクラスすら作らず(もしくは.javaで定義せず)
スクリプトっぽいのだけで済ませられるといいなーってよく思うんだけど、
そーいうプロジェクトねーかな。
PHPみたいな感じでドカドカ書きたいんだけど(あんまりコードかけない人でも使える表記法で)、
Serviceから先はJavaでしっかり書きたいみたいなニーズってあると思うんだけどなあ。
898:デフォルトの名無しさん
06/12/03 02:25:33
JSPだな
899:デフォルトの名無しさん
06/12/03 17:04:07
jspじゃ色々かけすぎて記述量が多いからなあ
コンテナに登録済みのどのサービス呼んで正常時はこれを表示って言う程度の事を簡単に書けない
900:デフォルトの名無しさん
06/12/03 17:39:26
そのサービスを呼ぶところが突き詰めるとまともな言語並の自由度を保証せざるを得ないんじゃないかなぁ～。
パターン化してJavaで書くのが速いと思う。
901:デフォルトの名無しさん
06/12/03 18:10:23
MayaaはjavascriptからS2のコンポーネント呼べるから、
部品だけjavaで書いて呼び出すとか・・・？
902:デフォルトの名無しさん
06/12/03 18:54:35
ServiceとのやりとりはTeeda-Ajax使って
UIは全部Ajaxで作るとか
Ajaxの部分はFlexでもSwingでもいいと思うけど
903:899
06/12/03 19:14:15
なるほど色々やりかたあるんだなあ。ありがとう。
俺が単純なのしか思いつかないからイメージが合わないっぽいなあ。
>>902
Teeda-Ajaxってそんなことできたのかあ。
904:デフォルトの名無しさん
06/12/03 19:45:26
>>903
あくまで、JavaScriptからS2に登録したコンポーネントを呼べる機能のみ
戻り値はJSONで渡してくれる。
905:デフォルトの名無しさん
06/12/04 14:33:11
>>904
戻り値は、Objectを返せばJSON形式に自動で変換するし
XMLやHTMLの文字列を返す事も出来る。
S2に登録したPOJOのメソッドを呼び出す事はかなり容易に出来ますな。
906:デフォルトの名無しさん
06/12/05 13:39:16
s2containerがチマチマとバージョンアップされていってますが、
Ver2.5の計画はあるのかな。あるとしたら何が実装されるの。
なんていうかな、今後どういった方向にSeasar2は進んでいくのか
マイルストーンとか、どっかに情報ないですか？
907:デフォルトの名無しさん
06/12/05 14:14:39
さて、どう出る？
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(blog.goo.ne.jp)
URLﾘﾝｸ(www.saisse.jp)
908:デフォルトの名無しさん
06/12/05 14:22:24
S2Maiキター
909:906
06/12/05 14:47:27
素早いお返事ありがと
910:デフォルトの名無しさん
06/12/05 14:47:42
>>907
DIしてAOPとか、クラスローダーでごちゃごちゃとかをやろうとすると、Javaの仕組み上インタフェースが必要になるんだから仕方ない。
911:デフォルトの名無しさん
06/12/05 15:12:05
つまり、DIやAOPで便利になるのを犠牲にしても
いちいちinterface作りたくねぇ、兎に角めんどくせぇ
って話になるのか。
912:デフォルトの名無しさん
06/12/05 15:29:46
Hogeってクラスは、setHogeでオートインジェクションされるから、
インターフェース使いたくないやつは使わなければいいし、
ポイントカットの指定も*って書けばいいんじゃね？
913:デフォルトの名無しさん
06/12/05 15:33:50
実装クラスの場合、diconにname書いて
その通りの名前のプロパティにしてやんないと
オートインジェクションされないんじゃなかった？
914:デフォルトの名無しさん
06/12/05 15:37:06
インターフェイスがないと、クラスレベルの拡張手段に
委譲を使いづらくなってしまうぞ
915:デフォルトの名無しさん
06/12/05 15:42:12
>>914
否定派は何が何でもinterfaceやだってんでなくて
業務システムのただのService層とかで
実装が一個なのに無批判に分離するのがやだって話で
そういう設計にinterfaceの有用性が関わる所はOKなんだと思うよ。
多分。
916:デフォルトの名無しさん
06/12/05 16:45:04
何でも最初の実装は一個なわけで
そしてリリース後に継承やコピペでパスタ化していくんだろうな
917:デフォルトの名無しさん
06/12/05 16:47:03
でもその確率って業務システムだと
そうそう高くないと思う。
ドカタ仕事と揶揄される所以。
YAGNIだといいたいんだろうな。
俺はinterface書きたいけどね、
長い物に巻かれるの好きだから。
918:デフォルトの名無しさん
06/12/05 17:42:04
特定のDIコンテナとは無関係ですって、つけたしてるけど
でも特定の設計手法とは関係大ありだよねー
処世術なんだろうけど
見物客としては
もっと堂々としてほしいねー
919:デフォルトの名無しさん
06/12/05 17:50:18
Implって名前作るのはダサいと思うが
interfaceと実装に分けるのは当然だろう？
一個しかなくても分けるよ。
実装が一個なのは当初の予定であり、
予定通りに行かないのは世の常。
と言うか、Mockを継承で作るって・・・モックにならんだろ？
920:デフォルトの名無しさん
06/12/05 18:21:38
seasarに限っていえば
モックを自分で作らないで済むんで
インタフェースは必ず作りたいねえ。
継承してモックって、実装をオーバーライドするんでしょ。
なんか気持ち悪いよね。必ずしもAPIが保証されない。
ま、気をつけて作れって事なんだろうけど。
921:デフォルトの名無しさん
06/12/05 18:32:38
つまり、ただの感情論？
922:デフォルトの名無しさん
06/12/05 19:07:48
モックも作らないなら、不要じゃないの？
923:デフォルトの名無しさん
06/12/05 21:14:57
実装クラスを継承してMockを作ったとして
テストのときにどーやって本物のクラスをMockに切り替えるの？
924:デフォルトの名無しさん
06/12/05 22:54:40
ユニットテストの時はコンテナにインスタンスを作らせないで
テストケースの中でインスタンスを作っちゃうことが多くない？
925:デフォルトの名無しさん
06/12/05 23:15:48
俺は[業務システムに Impl はダサい]という感覚がサッパリ分からないが、
どっちかというと
インタフェイス：IHogehogeManager
実装：HogehogeManager
という命名規則にして欲しかったな。
あと、愚民プログラマをどのプロジェクトでも排除できるって訳ではないので、
カスが紛れ込んでそうなプロジェクトでは実装とインタフェイスの分離を規約で
縛っておいて糞コードを発見した際には比較的安全に新しいコードと差し替える
ってのは有効だと思うんよな。
もちろん、ある程度インテリジェンスな奴のみの
プロジェクトでは自由にやっても構わないと思う。
文句言ってる奴らって、多分 守・破・離 でいう破の段階のやつらじゃねぇ？
愚民プログラマはとにかく守れ！
天才になったら Ruby や Lisp など別の強力な言語に行く。それが 離。
926:デフォルトの名無しさん
06/12/05 23:17:03
>>924
ありえない。テスト用の設定を準備する。
927:デフォルトの名無しさん
06/12/05 23:32:20
>>926
それで複数人のチームでテストファーストできる？
テスト用の設定に変える場合はどこかを書き換える作業が発生するでしょ？
928:デフォルトの名無しさん
06/12/05 23:36:06
>>927
その為のDIじゃないのか？ｗ
929:デフォルトの名無しさん
06/12/05 23:39:09
>>927
ふつーはテスト用のダイコンを準備して、テストクラスではそれを読むんじゃないのか？
まぁ、1テスト1ダイコンとかなったら流石に泣けるだろうけど。
Seasarまだ使ったことがないんでSpringの手法で回答してるんだが。
930:デフォルトの名無しさん
06/12/05 23:48:41
>>929
テスト用の設定ファイルはPGが各自に作るの？
それとも共通のファイルをみんなでいじるの？
>>928
kwsk。
931:デフォルトの名無しさん
06/12/06 00:17:56
>>929
そりゃ各自だろ。
各テストに必要なオブジェクトなんてたかが知れてるから、
そのために巨大なダイコン読み込んだって意味が無い。
テスト毎に多量にインスタンス生成したらサクサク感(ﾌﾟｹﾞﾗ)も減っちゃうし。
モック時計とかモックDBとかスゲー基本的なことは共通にしといて、
各パッケージ毎のテストは、それをインポートしたダイコンを使えばいいんじゃね？
932:デフォルトの名無しさん
06/12/06 00:20:44
>925 と同じく、おれにもダサさがわかんね。
インターフェース強制導出して実装１コだったとして、
それでどれほど複雑度が上がるというのか。
933:デフォルトの名無しさん
06/12/06 02:20:12
とりあえずモック作る時に実装にひきずられてたら
(継承して作るとか言っちゃってるし)
それはもうモックでもなんでもないと思うんだ。
934:デフォルトの名無しさん
06/12/06 02:25:21
まー普通継承してモック作るくらいだったら、インターフェイス切るわな
今更議論するようなことでもないと思っていたが
そんなにインターフェイス作るごときが嫌なら、今すぐにJavaやめてLLに行くべきだな
935:デフォルトの名無しさん
06/12/06 05:13:51
全部のクラスでモックを作るわけじゃないと思うが。
936:デフォルトの名無しさん
06/12/06 07:10:38
インターフェイス「切る」って？
937:デフォルトの名無しさん
06/12/06 09:49:22
I～はダサと思う。～Implもイマイチだけど、やむなくこっちにしてる。
１：１インタフェースが無駄だという主張は↓とか。
URLﾘﾝｸ(capsctrl.que.jp)
まぁ、SeasarとかSpringみたいなJavaのDIではインタフェースを作る方がいいと思う。
>>934
日本語でおk
938:デフォルトの名無しさん
06/12/06 10:06:52
Implがいやなら、diconいじって好きな名前にすりゃいいんじゃね？
なんでこんなつまらん感情論に振り回されるのさ？
939:デフォルトの名無しさん
06/12/06 10:43:48
論点はそこではなくて、interface なんて飾りですよ、な部分。
940:デフォルトの名無しさん
06/12/06 11:12:55
切る
とはあらゆる事象に使用できる万能用語である
なお、乱用しすぎると意味不明になるので注意
941:デフォルトの名無しさん
06/12/06 11:55:59
この場合切るは文脈で切り出すという意味なのは明らか。
執拗に本質でない部分をネタにする時点で分離嫌だよ派が合理的な説明を展開できてない気がする。
942:デフォルトの名無しさん
06/12/06 12:13:51
>>941
俺はマジでわからんかったよ。
943:デフォルトの名無しさん
06/12/06 12:44:41
>>918
処世術とか決め付けて書くのは自由ですが心外です。
私は悪いものは具体的に悪いと書くタイプの人間ですから私の認識していない
その設計手法とやらをリンク頂くなりして私に教授してくれませんか？
それが気に入らなければこの日記で遠慮なく叩きますよ。
944:デフォルトの名無しさん
06/12/06 13:08:27
結局、計画的設計か進化的設計かって事だろ。
インタフェース不要派は進化的設計で、
「必要なものは必要になってから作ればいい。事前に用意しても複雑になるだけ。」
って考えてる。
インタフェース必要派は計画的設計で、
「将来発生し得る、様々な拡張に備えておく必要がある。」
って考えてる。
アジャイルの精神では進化的設計であるべきだけど、
そもそもDIってものが計画的設計の産物なんだと思う。
945:デフォルトの名無しさん
06/12/06 13:15:27
>>941
本質でない部分だからネタにしてんだろうがよｗ
946:デフォルトの名無しさん
06/12/06 13:52:17
>>945
ごまかし乙ｗ
947:デフォルトの名無しさん
06/12/06 16:16:21
[Seasar-user:5402]
なんか噛みあってないんだよなｗ
948:デフォルトの名無しさん
06/12/06 16:29:42
>>944
逆だと思う、
インタフェース必要派は、
「将来発生し得る、様々な拡張に備えて」
あるインタフェースに対する実装を進化的に発展し得るが、
実装とインタフェースが同一な場合、
最初から全部計画的に設計を作っていかないと、
後から必要なものを付けたしつつ実装というのは難しい気がする。
動的言語(たとえばRuby)の場合も結局、
インタフェースは宣言しないだけで、暗黙的には存在するし、
Javaの場合はインタフェースを明示的に宣言しなければいけないから、
(本当なら暗黙的にできたものを)わざわざ書かなくてはいけなくて、
煩雑に感じるとか。
949:デフォルトの名無しさん
06/12/06 16:40:37
>>944と>>948、
どっちも気持ちはよくわかるけど
設計と実装でどっちを進化的とするかの
話ですれちがってる気がする。
950:949
06/12/06 16:45:34
ちょっとはしょりすぎた。
>>948って
実装を進化的に行えるようにするために
計画的に設計する、って読めたのです。
>>944の不要論の方は、
設計段階では実装を進化的に行ううんぬん
考えないで、必要になったら設計変えちゃえばいいじゃん
って話。
でもさ、インタフェース作るくらいで計画的も何もないよな。
951:944
06/12/06 16:47:48
いや、事前にインタフェースを準備した時点で計画的設計だろ。
計画的…将来の拡張に備えて、実装の前に入念に設計する。
例えば、インタフェースを用意しておくなど。
進化的…将来の拡張は、拡張が必要なタイミングで設計からやり直す。
例えば、リファクタリングやリストラクチャリング、インタフェースの抽出など。
952:944
06/12/06 16:52:28
あ、間にレス入ってた。
>>951にリファクタリングって書いたけど、「リファクタリングは設計じゃないだろ」とか突っ込まないでねｗ
>>950
その認識。
>でもさ、インタフェース作るくらいで計画的も何もないよな。
すまねぇ。ファウラーかぶれなんだ。
953:950
06/12/06 17:01:16
ああごめんごめん、計画的も何もないよなって
944を揶揄したわけじゃないんです。
悩むくらいなら作っちゃえばいいじゃんってのが
本音なので、そんな感じの意味です。
954:948
06/12/06 17:07:53
> でもさ、インタフェース作るくらいで計画的も何もないよな。
たしかに…。
どっちも拡張するときのやり方の問題って事ですか。
なんか、計画的と進化的という単語の意味の定義にずれがあるだけの気がしてきた。
ただ、この話が出てきたインタフェースを作るかどうかという話とはあまり関係ないような。
別にインタフェースから始めて、
拡張が必要なタイミングでインタフェースをリファクタリングしても良いわけですよね？
要するにインタフェースを書くのがめんどいか、めんどくさくないか？
(インタフェースだけじ動かないけど実装なら書けば動くしね。)
955:944
06/12/06 17:09:43
>>953
把握。
漏れも、
「インタフェースが実装と1：1で対応してるのは、
無駄なものは作らないっていう本来のアジャイルの精神じゃないだろ？」
って一石を投じたかっただけだ。
インタフェースを事前に用意するのはたいした労力じゃないと思うし、
DIコンテナ使う上では用意するのが当たり前と受け入れてるお。
DIっていう機構に不信感が募り始めてるのは確かだけど。
従来のドメインモデルとは相性が悪いから、シンドメインモデルで！っていわれてもな…
956:デフォルトの名無しさん
06/12/06 17:43:39
しんどいモデルかと思った
957:デフォルトの名無しさん
06/12/06 19:06:32
DIコンテナ使うならとりあえずinterface作った方が良いよね、じゃダメなのかな。
実装・メンテのデメリットよりも得られるメリットの方が遥かに大きいし。
DIコンテナ使わないならまた話は別だが。
958:デフォルトの名無しさん
06/12/06 21:37:05
>>945
だから、本質では太刀打ちできないからそういう小ざかしいことするんだろ？
959:デフォルトの名無しさん
06/12/06 21:39:46
2chで本質ﾌﾟｹﾞﾗ
960:デフォルトの名無しさん
06/12/06 22:40:18
(^∀^)ｹﾞﾗｹﾞﾗ、ｼﾈﾔ
961:デフォルトの名無しさん
06/12/07 01:12:30
いや、ていうか、小ざかしいことて…
切るって出てきたから、
切るは云々て下らんことを書いてみただけのただの通りすがりだ。
議論にも入ってねえ。
962:デフォルトの名無しさん
06/12/07 06:09:53
プライドだけ一人前乙
963:デフォルトの名無しさん
06/12/07 09:27:12
最近ただのつまらん書き込みに粘着するやつが多いな。
プライドって笑わせんな
964:デフォルトの名無しさん
06/12/07 12:36:23
最近ただのつまらん書き込みするだけの粘着も多いな。
965:デフォルトの名無しさん
06/12/07 15:24:51
それ粘着か？
確かに粘着もいるが
966:デフォルトの名無しさん
06/12/07 15:31:19
なんとなく語感が良かっただけ。気にしないで。
967:デフォルトの名無しさん
06/12/07 15:56:30
2ちゃん用語使いたがりかよ
↑
こういうのだよね、粘着って
968:デフォルトの名無しさん
06/12/07 19:15:13
ひがたんの美声をボリューム大で聞きたいでつ。
969:デフォルトの名無しさん
06/12/07 22:18:25
うーみゅのブランド品を目の前で燃やしてみたい
970:デフォルトの名無しさん
06/12/07 23:03:27
インタフェース切るのって、ただ、
AOPの適用ポイント明確にするぐらいにしか使わなくね？
Action - Logic - Dao構成なら、
どーせActionなんてテストしないんだから、
Logicのインタフェースは作成不要じゃね？
971:デフォルトの名無しさん
06/12/07 23:13:31
声がもっとしっかり聞こえればよかったけど、
Web放送勉強になりました。
972:デフォルトの名無しさん
06/12/07 23:25:49
>>970
とりあえず動くけどパフォーマンス的に問題があるロジッククラスがある場合に、
新しいロジッククラスに差し替えたいって要求が場合が他社と連携しての
開発ではあったりする。糞クラスを納品されたって訳だ。
そーゆー時に、俺らはチューニングされた新しいロジッククラスを設定ファイルを
書き換えるだけで投入できる。便利じゃないか？
俺らのチューニングしたロジッククラスは確かに早かった。
だが！ある特定の条件で発生する例外的な処理に対応しきれていなかった！！
修正するには根本的過ぎてかなり難しい！
クラスに実装してたら、元ののバージョンを取得しようにも
他のクラスに手が入ってて入っている部分と切り出して
チェックアウトするのがかなり難しいかもしれない！！
そんな時、設定ファイルを書き換えるだけで、すばやくもとの実装に戻し、難を逃れる。
便利じゃないか？
973:デフォルトの名無しさん
06/12/07 23:32:49
便利！！！
974:デフォルトの名無しさん
06/12/07 23:37:37
>>973
分かってくれたか！！！！
975:デフォルトの名無しさん
06/12/07 23:52:47
テレビショッピングか何かを思い出したが、まさにそんな感じだな。
interface 作る・メンテするコストなんてたかが知れてる。
もともと実装クラスに存在する public なメソッドのいくつかを切り出すだけ。
修正する時の手間も本来の修正分(=実装クラスの修正)に
interface のメソッドが増えるとか、シグネチャが変わる程度。
得られる効果は972氏のケースとか、
障害調査用実装とスイッチさせたりとか
モック作ったりとか、そりゃもう夢は広がりんぐ。
もちろん、そういうことする必要に迫られない時も多々あるだろうけど、
せいぜい第二段落の作業が無駄になった程度。
僅かな手間をケチって何がそんなに嬉しいのか。
DIコンテナ使わなければそりゃ得るものは少ないだろうけど
DIコンテナ使ってるなら問答無用でかけるべき手間。
定数が必要になった時、一箇所からしか使わないからって
リテラルにマジックナンバー埋め込むかって話だ。
976:デフォルトの名無しさん
06/12/08 00:26:35
最後の例がちょっと分かりやすいと感じた。
977:デフォルトの名無しさん
06/12/08 00:34:54
超適当なインターフェイスの作り方
１．実装クラス～Implを先に作る。
２．Eclipseでクラスを右クリック→リファクタリング→インターフェースの抽出を選択
３．インターフェイスに定義したいpublicメソッドを選んで、クラス名からImplを外して実行
４．パッケージが～.implだった場合は、パッケージ名を修正して出来上がり
だいたい15秒くらいでできるよｗ
978:wildcats
06/12/08 00:39:36
>>975
別に手間をケチってる訳じゃないよ？
インタフェイス抽出なんて僅かな手間だよね。
979:デフォルトの名無しさん
06/12/08 00:54:55
そもそも、この議論の起点になった奴が必要なときには
インターフェイスの抽出で済むじゃんって言ってるが、
多分、大体のときに必要になるのはインターフェイスを抽出する作業じゃなくて、
インターフェイスを残して、実装を退避させる作業なんだと思うけどなぁ。
それに、実クラスだとどうしても直接インスタンスを生成できちゃうから、
面倒なときにはDI使わずに自分で new しちゃったりするんよねぇ。
そーゆーのを後から抽出したインタフェイスに置き換えていくのって面倒じゃない？
「ぎょぎょ、業務で固有なロジック限定って言ったでしょ！！誤読厳禁！」
つってるけど、週次処理をこの場合には特別に実行するだとか、
そーゆー風に利用箇所が分散する観点がすっぽり抜け落ちてる。
多分Seasar全般に言えるんだろうけど、作り捨ての雰囲気が強いよな。
自分らの作ったシステムをしっかり保守していける体勢を作ろうという観点が
非常に欠けてる。
最近の迷走ぶりは今日早く家に帰れることを重視するあまり
将来困ろうが知っちゃこった無いって発想に近いと思う。
980:デフォルトの名無しさん
06/12/08 01:26:49
改めて >>907 を読み返すと、
最後の意見はかなりの電波だな。
最初の意見は信仰する宗教の違いと思えなくも無いが。
二番目の意見は・・・Implって名前が嫌いなだけなのか？主張が分からん。
981:970
06/12/08 02:01:32
うーん、漏れは972みたいな状況になったことって一度もないんだが。
自分は、小さな開発規模しか経験してないってことなのかな。
だってさー、問題あったら、直接ロジックいじるじゃん？
別に協力会社が作ったソースであっても。
982:デフォルトの名無しさん
06/12/08 02:04:48
>>975
俺は一箇所しか使わない & 直接書いた方が判りやすい場合はわざわざ定数化するよりマジックナンバー書いちゃうけど、だめかな？
なんでも定数だとかえって読みづらくなる気がするんだけど・・・。
983:972
06/12/08 02:26:15
>>981
おまいは、俺の発言をちゃんと理解したのか？（誤字が多すぎて読みにくかったと思うが）
現在正常に動いているものを変更すると変更後のものが動作の正常性を保障できないだろ？
テストクラスが準備されていたとしてもそれが本当に十分に記述されてるのか分からない。
そーゆー場合には、実績として動くことが保障されているクラスはそのまま残しておいて、
そのクラスをコピペしてから内部実装に手を入れていくべきだと思う。
そして、コピペ元は新しいクラスが十分な動作実績を持ったと判断したときに削除する。
俺が書いてるのはあくまで開発だけで閉じた話ではなくて、
障害発生時の一次対応の迅速さまで考えた話だから
「ばぐっすか？はいはい～、なおしました。これでどうすか？オッケーすよね」
っていうアジャイルな流れとは相容れないかもしれない。
年間システム停止時間1時間以内とか、そういう目標を課せられたプロジェクトに
密に関わってる人間じゃないとそーゆー視点は育たないのかなーとも思う。
984:デフォルトの名無しさん
06/12/08 02:26:58
直接書いた方が判りやすい場合はそれで良いでしょ。
985:デフォルトの名無しさん
06/12/08 02:43:17
>>983
まぁ熱くならずに。
字面を追っただけで利点を実感できたら、そいつは多分天才。
一度でも「あの時 interface 作っとけば・・・」な経験した後じゃないと、
事例挙げられても「ふーん？」で終わりですよ。
986:デフォルトの名無しさん
06/12/08 03:53:49
>>972
＞クラスに実装してたら、元ののバージョンを取得しようにも
＞他のクラスに手が入ってて入っている部分と切り出して
＞チェックアウトするのがかなり難しいかもしれない！！
これって単にインターフェイスを定義するかどうかだけじゃなく、
ロジックを整理してクラス分割した上で、そのクラス同士を疎結合にできているかどうかまで
問われるよね？
まぁ結局そこまで考えると、インターフェイスを使わずにクラス結合なんて考えられなくなるから
結果としては同じことになるんだけど
ようするに、そもそもなんでインターフェイスを挟んでクラス間を疎結合にしようとしているのか
大元からしっかり考えないと、メリットを掴むのは難しいと思う。
単にインターフェイスを定義しても、そこで作ったロジッククラスが
一つだけのメソッドに1000行書いてるような巨大なトランザクションスクリプトだったりしたら
「設定ファイル一つで簡単に置き換える」とかいうわけにもいかないわけで・・・
987:デフォルトの名無しさん
06/12/08 07:49:14
次スレ
国産DIコンテナSeasar その8
ｽﾚﾘﾝｸ(tech板)
988:デフォルトの名無しさん
06/12/08 10:35:00
>>970
>Action - Logic - Dao
ここでのLogicってなに？
トランザクションスクリプト？ドメイン？サービス？
多分、層が1つ足りないぜよ。
>>977
いいけど、そうなるとTDDじゃなくね？
>>986
例えば、もともとトランザクションスクリプトなクラスAがあったら、
コピーして修正を加えたA'クラス(もちろんトランザクションスクリプトだけど)をつくって、
差し替えるだけだろ。
トランザクションスクリプト＞ドメインモデルの切り替えは、DI云々以前に高コスト＆高リスクな作業だと思う。
>>987
乙
989:デフォルトの名無しさん
06/12/08 12:57:04
結局、
>>985
これが真理
990:デフォルトの名無しさん
06/12/08 20:37:10
>>987
乙
なんでファウンデーションスレをテンプレに貼ってないのかと思ったら、
変なのの隔離場所になってるのね。
991:デフォルトの名無しさん
06/12/08 22:19:02
やることがいちいち姑息だよな
992:981
06/12/08 22:52:51
>>983
なるほどねー。
やはり、今までになかったですねー、そういうのは。
>>988
サービスですね。
Action - Logic - Daoは、S2JSFのEmployeeサンプルに倣って書きました。
993:デフォルトの名無しさん
06/12/09 00:28:21
そろそろ埋めるか
994:デフォルトの名無しさん
06/12/09 00:40:58
埋める？S2Containerを？楽しそうだぜ！！
995:デフォルトの名無しさん
06/12/09 00:44:06
沖縄の守り神の獣肉(ﾟдﾟ)ｳﾏｰ
996:デフォルトの名無しさん
06/12/09 01:05:36
食ったんかいw
997:デフォルトの名無しさん
06/12/09 01:06:55
URLﾘﾝｸ(cap.from.tv)
998:デフォルトの名無しさん
06/12/09 01:55:49
ume
999:デフォルトの名無しさん
06/12/09 02:43:00
1000だったらS2Spring作る
1000:デフォルトの名無しさん
06/12/09 02:54:13
日テレはルパンにひどいことをしたよね(´･ω･｀)
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。