- 1 名前：デフォルトの名無しさん [04/10/27 22:54:13]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
d.hatena.ne.jp/higayasuo/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
- 876 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:33:52]
- >>875
抽象的杉。説得力皆無。
- 877 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:42:31]
- >>876
開発環境ぐらい、フリーのものを使いたいぞな。
- 878 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:03:28]
- そこで vi + gcc + gdb ですよ。
- 879 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:14:44]
- お金払うものでも、自由であればいいよ。
金払って開発環境使い始めたが最後、あとはすべてそこの製品で賄わなければ元がとれない、というものじゃなければ。
- 880 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:41:39]
- >>874
いんや、Javaはなかなかよいと漏れは思ってるよ。
SwingはなかなかいいAPI構成だと思うし、Eclipseは神だしね。
ただ、ここで議論しているようなデータベースのインターフェースとなる
業務アプリを作るときには、Javaは向いてないなってなことだ。
- 881 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:35:07]
- Swingのフォームとバリューオブジェクトのビーンが相互にやりとりできる仕組みさえできればいいと思うんだけどね。
- 882 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:41:54]
- だれかが言ってたようにSeasarが失敗だとするならば、その理由は、ヒガさんに全体的なモデルがなかったことだと思う。
くーすはベストプラクティスの積み上げで、全体的なモデルを構築できてないように思える。
ベストプラクティスは既知の問題には対応できるけど、未知の問題に対応するにはモデルの構築が不可欠だから。
だれかが言ってた、Seasarが失敗だというのが誤りであれば、３行目を除いては正しいとはいえなくなるわけだが。
- 883 名前：デフォルトの名無しさん mailto:sage [04/12/09 03:09:05]
- くーすという方法論とSeasarというプロダクトは別なのだが
- 884 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:41:55]
- くーすって方法論なの？
- 885 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:42:54]
- Seasarは方法論なしにやってるってこと？
- 886 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:27:44]
- Seasarの開発手法はXPのひが版
Seasarでの開発手法はくーす
- 887 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:36:00]
- ttp://d.hatena.ne.jp/higayasuo/20041209#1102556567
（ ´_ゝ`） ﾌｰﾝ
- 888 名前：デフォルトの名無しさん mailto:sage [04/12/09 16:49:05]
-
ちょっと聞きたいんだけど、振る舞いを持たないDTOって
例えば、伝票ってエンティティがあって、こいつの赤伝が欲しいって時に
ステートレスなサービスオブジェクトで、わざわざ伝票の全ての金額項目を×-1していくってこと？
エンティティ自体にtoDebitNote()とか作って、それ呼べば済む話だろうに。
複数のエンティティから特定のエンティティを生成する場合とか、似たような例は
あると思うけど、普通そういうロジックはエンティティ自身に持たせるんじゃないの？
サービス層がステートレスである必要性はわかるんだが、振る舞いを持たないDTOって
いくらなんでもバカすぎじゃね？
ValueObjectにすら振る舞いは持たせるだろ、普通。
- 889 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:08:33]
- 伝票エンティティ自体に自分自身の赤伝を作らせるのは
あまり趣味ではないですな。
伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
それは趣味なのでさておき、エンティティ自体に
赤伝生成責務を置くと、金額に-1をかけるコストに
何か変化はあるのでしょうか？
振る舞いをデータから分離するってのは
普通業務はデータは安定していて
ロジックは変化しやすいものだからってのが理由だそうです。
赤伝ってのはかなり安定した業務ロジックだから
ちょっと例えが悪いかも知れませんね。
- 890 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:17:05]
- >>889
> 伝票エンティティ自体に自分自身の赤伝を作らせるのは
> あまり趣味ではないですな。
> 伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
だからサービスがtoDebitNote()を呼ぶんでしょ
>
> それは趣味なのでさておき、エンティティ自体に
> 赤伝生成責務を置くと、金額に-1をかけるコストに
> 何か変化はあるのでしょうか？
だたでさえ肥大しがちなサービスからコードが減るよね。
金額なプロパティがいくつもある場合は特に。
>
> 振る舞いをデータから分離するってのは
> 普通業務はデータは安定していて
> ロジックは変化しやすいものだからってのが理由だそうです。
> 赤伝ってのはかなり安定した業務ロジックだから
> ちょっと例えが悪いかも知れませんね。
変化しやすいものを分離する理由はとはなんでしょう？
- 891 名前：デフォルトの名無しさん mailto:sage [04/12/09 21:14:15]
- >>888
＞＞サービス層がステートレスである必要性はわかるんだが
俺にはその必要性がわからない。
教えてくれ！
- 892 名前：890 mailto:sage [04/12/09 21:26:33]
- >>891
> >>888
> ＞＞サービス層がステートレスである必要性はわかるんだが
> 俺にはその必要性がわからない。
> 教えてくれ！
ステートフルで一度作ってみれ。難しいと思うが。
まぁ、なんちゅうか、リクエスト単位での処理を同期とか
ややこしいこと考えずに作ろうとすると、必然的にステートレスになるわけだ。
StrutsのActionクラスが典型だろう。
ステートフルにしちゃうと、ややこしい同期処理を考えなきゃいけない上に
結果的にサービスオブジェクトのインスタンスを、リクエストの数だけ
生成しなきゃいけなくなるわけだ。
こんなんでよろしい？
- 893 名前：デフォルトの名無しさん mailto:sage [04/12/09 22:19:32]
- サービスオブジェクトのインスタンスを、リクエストの数だけ生成したらいいんじゃない？
- 894 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:31:05]
- >>892
同期処理の問題だけ？
「同期処理とか」
の「とか」の部分について説明して欲しいな。
>>888に
「ValueObjectにすら振る舞いは持たせるだろ、普通。 」
って書いてあるけど、
ValueObjectはリクエストの数だけインスタンス作るからステートフルでもOKということ？
そもそも、くーすって状態に依存しないメソッドを使用すればテストも楽になるし、
他のメソッドなどに依存しないから再利用性も高まるし、
とか他のメリットもあったんじゃなかったっけ？
- 895 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:34:14]
- >>892
振る舞いを持たないDTOっていくらなんでもバカすぎじゃね？
と書きながら
必然的にステートレスになるわけだ。
というところは矛盾してないか？
振る舞いを持ったDTOはステートフルじゃねーのか？
- 896 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:36:22]
- >>894-895
粘着に粘着するなよｗ
- 897 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:51:17]
- >>895
DTOに持たせる振る舞いはテストが面倒でもいいんだよ！
- 898 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:56:31]
- ∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ >>897。
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
- 899 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:23:47]
- >>896
888は粘着じゃないだろ。
まっとうな質問だと思うけど?
- 900 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:36:16]
- >>894も粘着してるようには思えないがな。
>>895は粘着っぽいけど
- 901 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:50:54]
- >>895も素朴な疑問といえば素朴な疑問だがな
- 902 名前：888 mailto:sage [04/12/10 00:56:21]
- >>893
もちろん、そうしたいならそうすればいいんでないの？
ファサードとして使えるステートレスなサービス層が無いってことで、
ロジックの見通しが悪くなるとか、透過的なトランザクション処理が
やりづらくなっちゃうとかいう可能性はあるわけだけど。
>>894
「とか」の部分って何だろうね。自分で書きながらもよく解ってないかも。ｽﾏｿ
ところでValueObjectの定義はわかってる？
通貨とか税率とかそういう小さな単位のオブジェクトのことだよ？
テストはファサードになってるサービス毎に作ればいいよね。
ま、DTOっちゅうかエンティティに振る舞い持たせたからって、
テストがやりづらくなることは無いんだけど。
「状態に依存するメソッド」の状態の定義が曖昧だな。俺も、もちょっと考えてみる。
>>895
ステートレスなのはサービスで、そのステートレスなサービスがDTOに対して
支持をするわけだ。お前、今から赤伝になれ、みたいな。
同じことをサービスでやるよりは、よっぽど可読性もいいと思うんだけどなぁ。
サービスが何やってるのか一目瞭然だし。
- 903 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:57:34]
- 粘着に見える程度が、ここではまともなのです。
- 904 名前：デフォルトの名無しさん mailto:sage [04/12/10 01:28:15]
- >>888
正直、その問題に対してはくーす関係者は誰もまともに答えてないと思う。
ひが君はそっち方面の思考をすっかり停止しているし、こんの君は撹乱するだけだ。
唯一正面切って答えてるのは↓だと思うが、いまいち。
ttp://d.hatena.ne.jp/koichik/20041022#1098468196
- 905 名前：888 mailto:sage [04/12/10 01:41:48]
- >>>904
確かに難しい問題だとは思うけど、
これから世界に向けて発信して行こうっていうプロジェクトの思想としては、
ちょっとお粗末な気がするんだよ。
俺、１０年以上OOな思考にどっぷり浸かってるから、今更悪夢みたいな
手続き型の世界には戻りたくないっていう意識があるからかも知れんが、
ちょっと...なぁ。
だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
- 906 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:04:06]
- ちょっと振る舞い無し&ステートレス問題からは外れるけど、
そもそもOOな思考がばっちり出来る人ならくーすとかいらないんじゃないかな。
くーすは手続き型どっぷりな人でも、OOの恩恵が受けやすいって話だと
いう事なんじゃないかなーと。
「思想」としては後ろ向きではあるよね。
どっちかというと商売寄りな発想、でも俺はそれでいいと思う。
- 907 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:05:36]
- あ、ごめん、思想がお粗末なんじゃなくて、
きちんと説明しないって事がお粗末なのか。
読み違えました。
- 908 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:20:57]
- >>837
うむ、だからそのgetEntityManager().findObject()を使うには、AbstractDaoのサブクラスを作らないといけない。
AbstractDaoをimplementsした実装クラスを作ると、insertやらgetXXやらのメソッドを実装しなくちゃいけ
なくなるので、今度はSQL自動生成ができなくなる。自動生成したいメソッドもあるけど、findObjectも使いたい、
というジレンマだったわけだ。
インターフェースにメソッド名だけ定義すると、自動的に実装クラスが生成される。でもEntityManagerを
使うには実装クラスを作らないと行けない、と困ってたんだが。
でもS2DaoIntercepterのソースコードを読んで、単に実装クラスの方で、SQL自動生成したいメソッドを
abstractにしとけば問題ないということに気がついた。まだ試してないけど。
- 909 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:21:51]
- >>905
> だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
「現場」だの「お客様」だのを盾にして逃げる擁護厨が出現して終わりなﾖｶｰﾝ。
- 910 名前：デフォルトの名無しさん mailto:sage [04/12/10 07:10:23]
- >>905
そんなことは、既に答えてる気がする。
www.wikiroom.com/tpircs/?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1
量が多くて大変だけど。
- 911 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:15:51]
- >>888
例えば、あるDTOを文字列に変換する必要がある場合を考えてみると、
a) dto.toString()
b) service.convertToString(dto)
のふたつのパターンで悩んでるってことだよね？
a)のメリットはdtoについてカプセル化することができることで、
b)のメリットはAOPなんかをはさめるってこと。
で、どっちがいいのかってのは、実のところ擬似問題なんだよね。
a)はオブジェクトのふるまいに関することで、
b)はシステムのふるまいに関すること。
888は、この両者を混同しているような気がする。
だから、きちんと答えるとすると、
「エンティティ自体にtoDebitNote()を実装してもいいけど、
それを行なう一連の手続きは、きちんとサービス層のオブジェクトの責任にしてね」
って感じになるのかな。
- 912 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:38:13]
- >>908
というより、これまでと同じようにインターフェースを作って、
Daoの実装は、abstract classにして必要なメソッドだけを実装すればOK。
- 913 名前：デフォルトの名無しさん mailto:sage [04/12/10 10:27:34]
- ひが日記を読んで、こりゃやっぱり構造化分析で、
だからくーす（古酒）なんだよなーと思った。
ところで赤伝生成とtoDebitNoteってメソッド名が
どうも結びつかんのでさっぱりイメージが湧かないなー
とか思ってたら、はぶ氏が答えてますね。
- 914 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:26:51]
- OO大好きで啓蒙好きな人は、なぜだか会計に弱い事が多い
以上、極私的な経験則に基づく極端な偏見を述べてみました
- 915 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:59:55]
-
>>はぶ氏
「赤伝になる」ではなく「赤伝にする」です。
ついでにdebitnoteってそのまま「赤伝」のことなんだけど、最近の辞書には
借方票ってのってますな。なんだそれって感じ。
イメージとしては自分自身のインスタンス、またはコピーインスタンスを返すような
メソッドをイメージしてたんだけど、ま、単なる思い付きだったんで例えとしては最悪ですな。
結論には納得です。俺も似たような方向性なので。
>>ひが氏
保守のコストについて語りだすと泥沼になりそうなので(俺が)、一点だけ。
一番危惧しているのは、何でもかんでもサービスオブジェクトに突っ込んでしまって
その結果、肥大したサービスオブジェクトが保守性を下げてしまう事なんだけども、
その辺りはどう考えてるんですか？
適切に分割っていっても、その指針もまた、DTOにどこまで振る舞いを持たせるかっていう
命題と同じで、曖昧になりがちだし、複雑な業務になればなるほど、分割も難しいと思うんだけど。
俺の場合は、サービスオブジェクトの見通しをよくするためにエンティティに振る舞いを
持たせて、基本的にサービスオブジェクトは分割しない方針です。
一つの、一連の業務の流れの中で閉じておきたいと考えるので。
>>911
できれば、もちょっとよく読んでくれ。
一連の手続をサービスオブジェクトの責務とすることは↑で何度かそれとなく言ってる。
- 916 名前：デフォルトの名無しさん mailto:sage [04/12/10 13:05:23]
- >>914
OOは大好きだけど、啓蒙しようって気は無いよ。
寧ろ啓蒙されたいかも。
俺、そんなに偉いポストにいるわけじゃないから、
毎回アーキテクトやれるってわけじゃないし、
最近は人が作ったものを治してばっかりだし、
はぁ..
- 917 名前：913 mailto:sage [04/12/10 13:20:38]
- 赤伝の事をDebitNoteというのかー。知らなかった・・・。
前に海外拠点向けのシステム作ったときは
Revised、Adjustなんて言葉使ってたけど
考えてみればそれは販売側の業務用語だったんだな。
会計用語じゃなかったんだ。勉強になります。
- 918 名前：デフォルトの名無しさん mailto:sage [04/12/10 15:14:35]
- 俺がやった貿易システムじゃ
Debit Note は請求書の事だったけどな。
専門用語英語は難しい。
ひが氏のもわかるし、915のもわかる、
いいとこどりとかバランスって事なんだろうけど
それだとあいまいだしね、難しい。
俺は全部サービスに突っ込んじゃいたいかな。
肥大化しても、サービス分割はしない。
ステップ数大きいクラスが出来たら、すまん、と謝る。
うーん、気持ち悪いな。ダメか。
- 919 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:35:52]
- >>918
なぜ全部サービスに突っ込みたいの?
- 920 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:38:20]
- >>912
なるほどあったまい〜。
ついでに一つ聞いてもいい？
hsqlでIDENTITYとかデフォルト値使う時って、insert/update SQL書かなきゃだめ？
どうもいくらためしてもだめだったんだけど、何か良い方法はあるかな。
- 921 名前：デフォルトの名無しさん mailto:sage [04/12/10 18:06:02]
- d.hatena.ne.jp/koichik/20041209#1102615228
ここのkoichik氏の意見読んで思ったけど、
「振る舞い」って言葉の定義もあやふやなんだな。
俺が言ってる「振る舞い」ってのは単純なgetter/setterを除いた
一般的なメソッドも含んでるんだけど、くーすの中の人たちは
一連の業務ロジックと同列に捕らえているってこと？
さすがにメインストリームになる業務ロジックはサービスオブジェクトに
きっちりとまとめるわけだけど、その中で各エンティティに振り分けられる処理は
振り分けたいってのが、そもそもやりたい事なわけですよ。
サービスオブジェクトの可読性を上げるためにってのと、
OO設計原則(くーすではdeprecatedなんだっけ?)に従うって意味でね。
で、現状どんな場合に振分けてるかっていうと、
１．各エンティティに閉じた振る舞い
(合計値の算出とか、プロパティAとプロパティBの状態からプロパティCを設定するとか)
２．1個以上のエンティティとの関連から各プロパティを設定する場合
(エンティティAとエンティティBからエンティティCの各プロパティを設定する、とか)
「請求書オブジェクト」に「今週の通貨レート情報」を渡して請求額を算出する場合も同じかな
この場合、業務ロジック、というかビジネスルールがドメインオブジェクトに存在する事になるわけだな。
ざっと見たところこんなところ。まだまだありそうな気がするけど、今忙しいし。
- 922 名前：デフォルトの名無しさん [04/12/10 23:48:29]
- 結論
やっぱエンティティBeanだね。EJB万歳。
- 923 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:01:13]
- >>920
IDENTITYに関しては、そのうち対応してくれるっぽい。
主キー値の自動採番機能つけるっつってたから。
デフォルト値はムリぽかなぁ。
- 924 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:05:26]
- ＤＢ側で自動採番してた場合に、キーをinsert文から外すために
いちいちSQLを書かないといけないという話題だとおもわれ。
別にS2Daoが採番しなくても、DBがやってくれるんだからいい。
- 925 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:08:25]
- 赤伝の話は、Repositry と Entity のどちらを界面とするかだね。
レイヤーを隔てた協調動作かどうかが、これを分ける。
検索：
[A]
Entity entity = Repository.findEntity(id);
[B]
Entity entity = Entity.find(id);
保存：
[A]
Repository.store(entity);
[B]
entity.store();
[B]のように記述しても、その裏ではたいてい[A]のようなコードが記述される。
それは、レイヤー(ドメインと言ってもよい)が違うオブジェクト同士のコラボレーションだから。
同じレイヤーに存在できるオブジェクト同士なら、[B]のように書くのが自然。
[A]
FooProcessor fooProcessor;
fooProcessor.process(foo, bar);
[B]
Foo foo;
foo.process(bar);
- 926 名前：デフォルトの名無しさん mailto:sage [04/12/11 01:51:22]
- >>921
一般的なメソッドと一連の業務ロジックの違いを定義しないと曖昧なままだと思われ
- 927 名前：デフォルトの名無しさん mailto:sage [04/12/11 08:07:26]
- >>925
staticメソッドやエンティティに永続化メソッドを持たせるのはもう古いよ。
Torqueが否定されて、エンティティ(POJO)とDAOを分けるようになったわけだからね。
絶対的なものなどないのですよ。
データと振る舞いを1つにカプセル化するのが、
OOの絶対的な原則だと思っているならたぶんそれも間違い。
- 928 名前：デフォルトの名無しさん mailto:sage [04/12/11 10:13:54]
- >>927
レイヤーに重きをおいてみてほしいんだが。
POJOとDAOを分けるのは、それぞれ明確にレイヤーが違うからだと思うよ。
自分も、Entity.store()なんてコードは書いたことないし。
- 929 名前：デフォルトの名無しさん mailto:sage [04/12/11 10:18:41]
- ついでに書くと、
下の例で[A]のように書くのは、大いなる手続き型。
レコードの件数を数えるのに、集約関数を使わずにフェッチしてカウントアップするようなもの。
- 930 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:02:22]
- >>929
自然とか関係ないんだって。
その自然というのは個人的主観なんだから。
別に否定しているわけではないけど。
1.processor.process(foo, bar);
2.foo.process(bar);
3.bar.process(foo);
のどれがきれいかなんてことは、どうでも良い。
人を集めてきて、いっせいにコードを書かせたときに、
1でいくと決めたほうが、誰も迷わないし、レビューもしやすいってこと。
processという振る舞いが、fooに属するのかbarに属するのか
どちらにも属さないのかを適切に判断できるのは、
誰でも簡単にできることではない。
自分がプロジェクトをまかされたときに、コストをかけずに
一定の品質の物を作り出すにはどうしたら良いかという
のが、たぶん、くーすの視点。
- 931 名前：デフォルトの名無しさん mailto:sage [04/12/11 11:27:20]
- つまり、やっぱ構造化＆データと処理の分離こそが正しい道だった、と。
- 932 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:34:32]
- > 1でいくと決めたほうが、誰も迷わないし、レビューもしやすいってこと。
1〜3のどれで書いてもコードの複雑さが同じならそうだけど、
実際には異なるだろう。
困難な決定を先送りにしているだけではないか?
- 933 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:36:16]
- >>924
そうそう、それです！現状はそれができないってことですね。
ではひがたんに要望。
insert/updateのアノテーションで、使用する(もしくは使用しない)プロパティを指定できたりすると嬉しいです。
publis static final String insert_IGNORECOLS = "id";
みたいな形で。
- 934 名前：デフォルトの名無しさん mailto:sage [04/12/11 12:41:04]
- うおっ、いいねそのアノテーション！
update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。
- 935 名前：デフォルトの名無しさん mailto:sage [04/12/11 15:03:56]
- >>930
1も2も3とれが最適かは、状況によって違うから、限定する意味無いんでない？
モジュール化、依存度の低い、ポリモーフィズムを活用した表現力の高さとかバランス見て。
だから、どれで行くと決めること自体が害悪。
- 936 名前：888 mailto:sage [04/12/11 16:32:34]
- そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪ってことで Final answer ?
ま、そりゃ1/3冗談だとして、限定する意味はあると思うよ。もちろんその状況毎で。
デザインパターンがそうであるようにね。
それを放棄してしまっているくーすの思想には、>>932も触れてるように、かなり危惧してる。
このままメジャーになっていったとして、ほんとにそんなんでいいのか？っていう不安が拭いきれない感じ。
まず、>>926の言うとおり、一般的なメソッドと業務ロジックの
違いをはっきりと定義することが重要だと思うね。俺自身、はっきり区別できてないわけだけど。
その定義がぼんやりとでも見えてきたら、一歩前進だと思う。
- 937 名前：デフォルトの名無しさん mailto:sage [04/12/11 18:08:55]
- わざわざ早く寝たと不自然に断りながら
このスレ向けを日記で回答をする人は
実は早く寝てなんかおらず、
このスレに夢中になって書きんでいた
ことをひた隠しにしているだけという理解でよいでしょうか？
- 938 名前：デフォルトの名無しさん mailto:sage [04/12/11 19:14:23]
-
> そいじゃ、DTOには振舞い持たせない って言い切ってるくーすは害悪
うむ。大抵はそれでいいだろ。データ扱うときゃMapでいい。
ちょっとした四則演算で求まるもので、そんな重い処理じゃなくて、
ポリモーフィズムが生きるようなものだったらデータに振る舞い持たせてもよいと思う。
- 939 名前：デフォルトの名無しさん mailto:sage [04/12/11 19:42:08]
- そういやCOBOLでやってたときはふつーのおばちゃんが仕様書をコードに変換してた。
あれはデータと処理が分離していればこそ、だったんだろうな。
もちろん業務の相応に細かな仕様書も必要だけど。
くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。
- 940 名前：デフォルトの名無しさん mailto:sage [04/12/11 21:41:54]
- >>939
> くーすって、コーディングをそのへんまで単純にすることを期待してるんかな。
ひが氏とか壺売り氏とかは盛んにそんなことを言ってるね。
↓みたいな立場とは対極だな。
ttp://www.freeml.com/message/patterns@freeml.com/0002755
- 941 名前：デフォルトの名無しさん mailto:sage [04/12/11 22:40:01]
- ん？
基本的にOOを深く理解した賢い人が能率良く仕事するツールだろ？
- 942 名前：デフォルトの名無しさん mailto:sage [04/12/12 02:31:21]
- >>941
少なくともくーすの中の人の意識は>>939と同じ。
>>932の言う「困難な決定」を下っ端(もしくは中国)に
spell awayするための方法論。
- 943 名前：デフォルトの名無しさん mailto:sage [04/12/12 11:48:23]
- ふつーのおばちゃんにやらせるぐらいなら、素直に機械にやらせればいいのに。
- 944 名前：デフォルトの名無しさん mailto:sage [04/12/12 11:49:29]
- >>942
だとしたら、COBOL 85 >>>>>>>>> くーす だな。
- 945 名前：デフォルトの名無しさん mailto:sage [04/12/12 12:32:31]
- >>942
困難な決定をさせないのがくーす。
>>936
業務ロジックとは、ユーザに対するサービス。
業務ロジックでないメソッドとは、ユーザに対するものではなく、
クラスの都合で必要なメソッド。
- 946 名前：デフォルトの名無しさん mailto:sage [04/12/12 16:00:33]
- なるほど。
くーすはXPとは対照的に、人間のコミュニケーションの感性を信じてないんだな。
そういう人みたことあるけど、
どうせ分かり合えないから話してもムダなんだよという空気をドバドバ吐き出しちゃってて、
ちょっと痛々しいね。
オープンソースに逃げないで現実の人間のことを考えつづけたほうがいいと思うよ。
- 947 名前：デフォルトの名無しさん mailto:sage [04/12/12 16:47:39]
- >>946
仕事なんか定型的にやるのが一番。
相手のことなんかより、自分の私生活のほうが大事。
- 948 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:22:09]
- >>947の華麗な私生活に乾杯。
- 949 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:29:20]
- つまり、ブランドの服を買いまくりってことかと。
- 950 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:35:42]
- >>946
> ちょっと痛々しいね。
おぬしの書き込みのほうが痛々しいなり。
>>288がいいことを書いているので参考にするなり。
人を信じないおぬしには、他人も人を信じないように見えるということなり。
- 951 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:57:42]
- >>936
まあ、そんなにくーすが嫌いならあんたが採用しなけりゃいいだけだと思うがね。
くーすをよりよいものにしようと考えていろいろ書き込んでるんじゃなく、
くーすそのものの考え方を否定しているみたいだけど、
人それぞれ考えかたがあるんだから採用する人しない人いていいんじゃない？
くーすの考え方に対して賛否あると思うけど、
２ちゃんで関係ない人たちと議論するより比嘉氏の日記にコメントでもして
一度議論したほうがいいんじゃないの？
ここで盛り上がって「やっぱくーすはだめだね」って結論になっても
くーす本は出るだろうし、あんたが危惧してるように
くーすがこのままの形でメジャーになるかもしれないでしょ。
- 952 名前：デフォルトの名無しさん mailto:sage [04/12/12 17:58:14]
- >>936
＞＞一般的なメソッドと業務ロジックの違いをはっきりと定義することが重要だと思うね。
それができるぐらい技術力のある人材が豊富であれば
くーすなんて必要ないと思う。
できないから、全部DTOからはずしてしまうと決めることで
余計なあいまいさを省くという考え方もでてくるのではないかな？
豊富な技術力を有する高価なエンジニアを集めて
綺麗な設計、綺麗な実装でシステムを作るのもいいけど、
ビジネスとしてシステム開発をやるときには、
まず利益を上げられなければ話にならないから
生産性向上、コスト削減を考慮しなければならないと思う。
形式を決めてしまってあいまいさを省くことで
生産性を上げることができるかもしれないし、
単価の安い派遣会社に任せることでコストを削減できるかもしれないし
社内でくすぶっている技術力の低い人材を使うことで
社内で無駄になりがちなコストを有効活用できるかもしれない。
あんたのようなスキルの高い人材だけでシステム作るのであれば簡単だろうけど
スキルの低い人材を使わざるを得ない自分のような立場の人間としては
くーすのような考え方もありだと思う。
個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを
ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような
危機感を感じているよ。我が社では。
- 953 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:09:50]
- 今回のスレはくーすﾈﾀで盛り上がってるね。
- 954 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:14:20]
- > 個人的には技術力の高い人材に対して数倍の「その他大勢」のプログラマを
> ぶら下げて開発するような形にしていかなければ会社自体が衰退していくような
> 危機感を感じているよ。我が社では。
とっとと潰れろボーケー
- 955 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:25:01]
- >>952
高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。
あんたの会社で現実的に高スキル人員集約型が採用できるかは別問題。
>>954
いいツッコミだ。
- 956 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:27:54]
- なんだかなぁ
もっとね、漏れはソフトウェア開発ってのはカネがいいとかどうとか
そういうのを超えて、もっと使命感というか、スピリチュアルな
エネルギーに満ちた仕事だと思うわけ。キカイ的に安い人集めて
自動的にうまくいく、なんてそんな工業的なもんじゃない。
そういう場は、コミュニケーション、フィードバック、信頼関係を
保つことが必要で、それをやらなきゃどうせまともなソフトウェアが
作れるはずもない。
漏れ的にはそんなことも分からん死んでもそんなクソな会社のために働きたくない。
だから漏れは今無職なのだが！ いや、しかし分かる会社もそれなりにあるはずだと信じたい。
- 957 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:32:16]
- >>955
> 高スキル人員集約型と比べてくーすのコストは本当に低くなるのか。
少なくとも取替えは出来るようになるんじゃないかな。
スキルの高い奴が集まっていても健康な奴ばかりとは限らん。
少数精鋭って言葉に幻想を抱いている奴が多いが
ひとりに何かの事情が発生したら大変だぞ。
- 958 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:33:14]
- 銀の弾丸探しの種は尽きまじ
- 959 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:33:35]
- >>956
藻前がそういう会社を作って人材を募集したらいいんだよ。
- 960 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:38:39]
- >>957
むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて
その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。
- 961 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:42:53]
- >>956
ある漫画家が言うてました。
最高を求めて筆を入れ続けたいなら趣味か同人でやるべきで
それを職業とするなら金と納期によって品質を決めるべきだと
- 962 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:47:19]
- >>961
いいソフト作るには趣味しか無いと？
何いってんの。
趣味じゃフルタイム開発に費やせないじゃん。
そんなんでソフトウェア作れるかよ。
- 963 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:47:42]
- >>960
役割を階層化すると教育は容易くなるよ。それは上も下も関係ない。
図面ひく人、釘打つ人と分けたからって図面をひくという行為そのも
のの難易度が上がるわけじゃない。
寧ろ階層辺りの必要能力が限定される分、難易度は下がる。
- 964 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:48:28]
- >>949
ぐはぁっ．(;_;)
と騙ってみるテスト。
- 965 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:50:17]
- >>962
予算と納期に応じて要求を満たす動くものを作れと言ってる。
良い悪いなんて話はしてない。
敢えて良い悪いで語るなら、当初の予算を超えたり、納期に
遅れたり、そもそも要求を満たさなかったり、ましてや動かな
かったりするソフトウェアは悪いソフトウェアだｗ
- 966 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:53:20]
- >>946
XPが人を信じてるなら何でペアプロなんてやらせるんだ。俺のコードを信じてないからだろ。
何で毎日ミーティングさせるんだ。3ヵ月後にちゃんと持ってくるんだからほっとけよ。
なんてことを言ってるのと似たような発言だな。
お前の言うコミュニケーションの感性って具体的に何よ？
それよりお前XPやってるのか？
- 967 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:54:02]
- >>962
キミの趣味にフルタイムの給料を出せと？
- 968 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:55:19]
- >>965
わかった。
とにかく急いで作らなきゃいけなくて、
まともなコード書ける人数がいないというのが現実なら、
そもそもその仕事を引き受けるべきではなかったのだ。
現実的な解はくーすを使うことではなく、客に謝りにいくことである。
そうしないと被害大きくするだけ。
- 969 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:56:44]
- 休日にも関わらず盛り上がってますねー！
今日の ﾈﾀ 師は >>946 に ｹﾃｰｲ ！
- 970 名前：デフォルトの名無しさん mailto:sage [04/12/12 18:58:42]
- >>946=>>969
という認識でよろしいでしょうか。
- 971 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:01:46]
- >>956はﾈﾀだ、気をつけろ!!
…って遅かったか。
- 972 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:16:14]
- >>968
「まともなコード書ける人数がいない」などという条件は何処から引っ張って来た？
勝手に条件加えて手前勝手な結論に至って満足か？
- 973 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:21:09]
- ﾈﾀﾆ ｾｷｽﾞｲﾊﾝｼｬ ｶｺﾜﾙｲ
- 974 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:33:25]
- >>972
もちろん満足です！
釣れたから（藁
- 975 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:33:34]
- まぁ、Seaser自体がネタだからな
- 976 名前：デフォルトの名無しさん mailto:sage [04/12/12 19:35:47]
- そうでつね。Seaserはﾈﾀでつね。
Seasarはﾈﾀじゃないでつけどね。
|
 |
