- 1 名前：デフォルトの名無しさん mailto:sage [04/08/09 18:36]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
それではスタート！
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
pc5.2ch.net/test/read.cgi/tech/1090653286/
- 762 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:55:38]
- ・・・普通の集計にしか見えんのですが。
- 763 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:11:53]
- その普通の集計をわざわざコードでやるがいいと
おっしゃっておるのでつよ。
これがリッチSQLなのでつ。リッチクライアントも決して
普通のVBの画面にしか見えんのですが。
などといってはいかんのでつ。
- 764 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:25:34]
- しょぼいSQLで済むことにあれだけコード書くようだと
複雑なクエリーが必要な場合にどれだけコードを書くんだ？
いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ
あるかないかわからない移植のことを考えるよりもさっさと作って
リリースするほうが重要なんじゃないか。いるものだけ作るという
原則に反している気がする
- 765 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:39:18]
- つまりあれだ。
S2Daoﾏﾝｾｰってことだな。
- 766 名前：デフォルトの名無しさん mailto:sage [04/10/22 17:14:54]
- だな！
- 767 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:55:24]
- >>763
> リッチクライアントも決して
> 普通のVBの画面にしか見えんのですが。
> などといってはいかんのでつ。
比較対象がHTMLフォームだから。
- 768 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:58:01]
- あのドキュメントは社員さんが書いたのか。
サイトの運営も社員さんにやってもらったほうがいいね。
なんにしろ、組織的なサポートは心強い。
- 769 名前：デフォルトの名無しさん mailto:sage [04/10/22 23:55:07]
- >ビジネスロジックとは
意味わかんね。
だれかかいつまんで説明して
- 770 名前：デフォルトの名無しさん [04/10/23 00:39:25]
- >>764
問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。
とくに問題になる点は
・更新性「EAはこれからめちゃくちゃ変わる」
・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
だろう。
まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。
- 771 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:50:40]
- 結局規模が違えば考え方も違うってことだね。
もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。
- 772 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:57:52]
- >>770
EAはむちゃくちゃ変わるってのは
日本で業務系に携わってても
正直そこまで実感が湧いてこないんですが
それは私の経験不足と言う事でさておいて
大体リッチなSQLを使う所って、経営分析データだとか
会計帳票とかになりますよね。
そういう所はEAとかいう部分と関係なくて
逆に安定しまくっとる所なわけで、
そこにSQL一発ですむものを複雑なコーディングに
置き換えるのはやはり気がひけます。
やっぱりいいとこどりが一番って事でしょう。
議論としちゃつまらん結論ですけどのう。
- 773 名前：デフォルトの名無しさん mailto:sage [04/10/23 01:35:27]
- 全体を捉えた議論の結論としては
「やるべきことをやる、使うべきところで使うべきものを使う」
ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？
つまり、その手法のメリットデメリットはなにか、と。
マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？
- 774 名前：デフォルトの名無しさん [04/10/23 02:33:35]
-
殺伐としたスレに救世主が！！
無職
ヽ|・∀・|ノ ＜人殺しマン参上
|=◎=|
| |
headlines.yahoo.co.jp/hl?a=20041022-00000505-yom-soci
- 775 名前：デフォルトの名無しさん mailto:age [04/10/23 03:05:17]
- S2JSF間近aga!!!
- 776 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:07:08]
- >>770
> ・更新性「EAはこれからめちゃくちゃ変わる」
だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？
> ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？
云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。
- 777 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:51:27]
- ファウラーのblikiを翻訳してる方によると
やはり日本とアメリカの事情の違いってのがあるそうで、
日本にくらべてあっちはアプリ開発とDB開発の分業が
相当徹底されているらしいですね。
で、
> ・カプセル化「ビジネスロジックを担当するコードが
>データベース設計変更時に影響を与えられることはない」
ってのは、776の言う通り、設計変更っていや
ビジネスロジックの変更の事だろう、って気分に私もなりましたが
もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ
と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。
あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら
うそつけバーカとか書いちゃって下さい。
あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、
やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。
- 778 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:00:15]
- 773の意見にまったく同意です。
でもまあ、総論みたいな所も、答えは「いいとこどり」に
落ち着く事は判っていても、喧々諤々やっといた方が
いいと思うんですよ。
その事で、双方の「いいとこ」の範囲が、
前より広く感じられて来たりしたら良いと思うし。
ここ、読んでて大変面白いですよあたしゃ。
2ちゃんのOO関連スレじゃ一番じゃないですか？
- 779 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:13:28]
- 関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。
結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。
- 780 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:49:47]
- 言語とRDBMSと、どちらが変更される可能性が高いか。
どちらとも言えんと思う。
言語が変わる場合：
C/S からWEB系への移行
Unixに乗り換えで、ASPからJavaへ移行
RDBMSが変わる場合：
パッケージもの。お客様によってRDBMSが異なる
辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。
他にどんな場合があるかな？
- 781 名前：デフォルトの名無しさん mailto:sage [04/10/23 05:18:03]
- 言語は変わる場合より併用の方が多いんじゃないかな。
たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
# 実際はサーブレット呼び出すようにしてJavaで処理させたりするが。James？なにそれ。ｗ
部分的にPHPで組むことも考えられる。
RDBMSで言えば、最初はPostgreSQLで運営してたけどサービスが成長したからOracleに移行とか。
Windows上のSQLServerで運用していたけど、大人の事情でUNIX使うことになって、Oracleへ、とか。
PostgreSQL→Oracleのようなスケールアップはありがちなんじゃないかと。
逆に、移行しやすいように作っておくことを前提に当初はPostgreSQLで運用開始とか。
- 782 名前：デフォルトの名無しさん [04/10/23 09:23:30]
- >>781
> たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
いろんな言語を組み合わせるのはどうにも気持ち悪い。メンテナンスしづらいでしょ。
開発環境そろえるのに時間かかりそう。環境によってあーだこーだ言うのは最悪。
バージョンがこうだとか、ディレクトリ構成がこうだとか。ウザい。
シンプルが一番。
アプリケーション毎に常駐プログラム作ってそこでデータベースなりメールの処理するとかするでしょ普通。
ポータビリティが重要だと思う。
CVSのモジュールを引っ張り出すだけで自前の環境でシステムの自動テストができるような単純さが開発では重要。
加えると、Javaって面倒だ。
全部スクリプトで作ってしまえばいいと思うのだが。
- 783 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:13:19]
- >>777
だからコミュニケーションの重要性が
日本以上に言われるのかな＞分業の徹底
- 784 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:40:46]
- >>783
うん、そうみたいですね。
blikiの翻訳者さん、こんなのも翻訳してまして
tp://capsctrl.que.jp/kdmsnr/wiki/agiledata/
ここみると、「なぜ一緒に働くことが現在困難なのか」とか
なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、
日米の文化の違いはかなりのもんの様です。
でもアメリカさんだから、ジョークというか
比喩かも知れないですけどね。
- 785 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:47:58]
- seasarの良いところがいまいち分からんなー。
インターフェース書いて、ダイコンファイル書いて
ってめんどくせーって思っちゃう。
サービスに新しい機能付けようと思ったら、インターフェース
とImplクラスの２つを変更しなきゃいけないし。
インターフェースはImpl挿げ替えるだけで、動きを変えられるって
メリット（多態性）で使うんであれば良いし、よく使うんだけど
seasarのためにインターフェースガンガン書くって気にはどうも慣れん。
ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。
漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？
なので私はseasar使うようになったよ」って意見を聞きたいです。
あとEJBはseasarよりさらにダルイっておもっとる。
- 786 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:59:55]
- 別に無理してまでインターフェース用意することも無いでしょう。
必要に迫られたときにインターフェースを抽出することは
IDEなんかのツール使えば一瞬で出来るんだし。
- 787 名前：786 mailto:sage [04/10/23 12:01:40]
- ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。
不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。
- 788 名前：785 mailto:sage [04/10/23 12:21:54]
- レスありがとう。
>別に無理してまでインターフェース用意することも無いでしょう。
seasarってインターフェース必須ではないんだー。誤解してました。
>不必要なメソッド呼び出しを隠蔽できたり、
これは、漏れのやる仕事のに依存してるのかもしれないけど
APIのようなクラスを作るときは、隠蔽って重要だと思います。
でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に
出くわさないんですね。
>Mock使ったテストが容易になったり。
これはもう少し詳しく聞きたいです。seasarのドキュメントにも
テストが容易って書いてありますが、EJBに比べてって事ですか？
struts+Hibernateでテストしにくいって感じた事無いんですよね。
- 789 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:28:07]
- >>785
seasarというより、インターフェースと実装を分離するということは、
OOの重要な部分だと思うけど、分業するときに、
インターフェースを先に決めておけば、実装が追いつかなくても、
Mockとかを使って作業を並行して進められるというメリットがあるね。
実装クラス同士が直接依存しあうことが少なくなるから、
個々のクラスの個々のメソッドを単独で実装・テストしやすい。
直接依存してると、依存しあっている部分を全部コーディングしないと
テストできないから。
- 790 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:32:00]
- >>788
ふだん、どんなテストしてるの。
- 791 名前：785 mailto:sage [04/10/23 13:10:24]
- >>789
>Mockとかを使って作業を並行して進められるというメリットがあるね。
でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも
同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら
インターフェースがある方ですが。。。
>依存しあっている部分を全部コーディングしないと
>テストできないから。
うーんseasarもダミーの実装をダイコンファイルに書いてるだけ
なんだよなと。Implクラスにダミーの戻り値を書いておく方が
楽と感じてます。
>>790
普段は下層のDAOから実装していくって感じなんで
（階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。
サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。
相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。
他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。
- 792 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:34:02]
- >>791
それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。
でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。
あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。
ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。
- 793 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:57:33]
- まさか、自動テストの一括実行をやってないとか。
- 794 名前：785 mailto:sage [04/10/23 14:32:12]
- >>792
ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。
その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。
>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。
上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。
- 795 名前：デフォルトの名無しさん mailto:sage [04/10/23 14:38:34]
- >自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？
- 796 名前：デフォルトの名無しさん mailto:sage [04/10/23 16:59:16]
- デバックってゆうな〜
- 797 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:00:15]
- >おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。
モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。
ちなみにdebugなんでデバッ"グ"
- 798 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:24:12]
- OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。
新参者は空気を読め、空気をという話である。
- 799 名前：785 mailto:sage [04/10/23 18:58:14]
- デバッグですね。お恥ずかしい。。。
>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。
逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ
- 800 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:10:45]
- >>798
何のコピペ？
- 801 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:36:39]
- はぶ氏もひが氏もここの話題に反応してくれてますな
っと、話ふり逃げに思われると残念なので書いとこう
- 802 名前：デフォルトの名無しさん mailto:sage [04/10/23 21:45:01]
- >>800
これだろうな。
ttp://d.hatena.ne.jp/hyoshiok/20041022
- 803 名前：デフォルトの名無しさん mailto:sage [04/10/23 22:08:24]
- ttp://d.hatena.ne.jp/akon/20041023#p2
こんな未来は嫌だ。
- 804 名前：デフォルトの名無しさん [04/10/23 23:03:29]
- どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
- 805 名前：デフォルトの名無しさん [04/10/23 23:05:49]
- > Stateless BusinessLogicパターンのメリット
> ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617
上記サイトの内容で疑問点がありまして。
ひがさんは
「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」
と仰っています。
ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。
このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
- 806 名前：デフォルトの名無しさん [04/10/23 23:27:38]
- >>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
- 807 名前：785 mailto:sage [04/10/23 23:35:51]
- >>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。
よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。
でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
- 808 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:44:01]
- statelessって「実装に依存しない」って意味なんじゃないですか？
依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。
stateless
【形-1】 国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっか とうち けん｝］のない
【形-2】 《コ》処理状態｛しょり じょうたい｝を把握｛はあく｝しない〜◆【対】stateful
って辞書にあるそのまんまの意味だとばっかり思ってました。
- 809 名前：デフォルトの名無しさん [04/10/23 23:48:50]
- d.hatena.ne.jp/higayasuo/20040805#1091664617
- 810 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:51:34]
- >>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？
> 処理状態｛しょり じょうたい｝を把握｛はあく｝しない
そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
- 811 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:52:33]
- >>808
かなり根本から間違ってるな。State が lessなんだぞ。
- 812 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:57:32]
- >>808
SLSB/SFSBの違いを思い出せ。
- 813 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:58:14]
- オブジェクトが状態をもたない。
- 814 名前：デフォルトの名無しさん [04/10/23 23:59:14]
- class Foo {
int s;
int method(int x);
}
があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく
sの値にも依存すればstatefulで、
xの値のみに依存すればstatelessなんじゃね？
だから
＞Statelessといっても、すべてスタティックメソッドにすれば良いという
っていうことになるんだと思ったけど
- 815 名前：デフォルトの名無しさん [04/10/24 00:01:29]
- >>814
statelessでもポリモフィズムは使いたい。
- 816 名前：デフォルトの名無しさん [04/10/24 00:03:16]
- >>814
>すべてスタティックメソッドにすれば良いという
ポリモーフィズムが使えるところが違うっていうところだな。
システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。
これやるとプログラマのシステムの意図の理解に役に立つし。
- 817 名前：805 [04/10/24 00:07:34]
- >>807
> >>805
> ステートSがオブジェクト変数だとMaかMbからのみ変更される
> って事だからだと思うよ。
> ステートSをクラスの外に出すと、MaやMbはステートSに依存
> はするけれど、MaとMbの依存関係は無くなるんだね。
そうかな?
「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」
なら
「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」
と言えると思うんだよね。
- 818 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:09:28]
- >>804
ポインタ希望
- 819 名前：785 mailto:sage [04/10/24 00:33:53]
- >>817
じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
いないのに、MbはMaに依存しているっているって言える？
あくまでステートSに依存しているだけだよね。
あとは、ステートSの場所についてだけどこれは >>813
って事だね。
- 820 名前：805 [04/10/24 00:37:11]
- メソッドの処理がステートに依存するクラスの例として
以下のクラスがあったとする。
class File
void open();
void close();
int read();
}
これが以下のようにStatelessになったところで
open、close、readの依存関係がなくなったとは言えないと思うんだよね。
例が悪いのかな?
class File {
void open(FileState state);
void close(FileState state);
int read(FileState state);
}
- 821 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:37]
- だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。
810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。
状態を持たないだと判りにくいか、
状態の変化を管理しない。
S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。
結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
- 822 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:53]
- ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。
この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
- 823 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:50:36]
- ああでもよくわかんねぇ
- 824 名前：デフォルトの名無しさん [04/10/24 00:50:40]
- class File {
static int read(String filename, int position);
}
これは？
- 825 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:52:15]
- なんか俺も混乱してきたのでひがさんきぼんぬ
- 826 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:09]
- ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。
あ、821=823です、
まぎらわしくなっちゃってすみません>822
- 827 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:10]
- >>820
オブジェクトをステートレスにしろって事じゃないの？
下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。
上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
- 828 名前：785 mailto:sage [04/10/24 00:58:40]
- >>820
何に対して、誰から見るとStatelessなのか、Statefullなのか
って事だよー。
上のFileクラスは、使う側から見るとopen、close、readのメソッドが
Statefullなんだけど、下のFileクラスは、引数のstateに対して
statefullであって、open、close、readの関係はStatelessだよ。
ようは、stateだけ考えてれば、良いって事。
ん？漏れはコアなseasar利用者じゃないんだが。。。
モンキーターン見てくる
- 829 名前：805 [04/10/24 01:00:19]
- >>819
> >>817
> じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
> Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
> いないのに、MbはMaに依存しているっているって言える？
> あくまでステートSに依存しているだけだよね。
今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。
Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。
へんなこと言ってるかな?
> あとは、ステートSの場所についてだけどこれは >>813
> って事だね。
そうです。
- 830 名前：805 mailto:sage [04/10/24 01:05:18]
- >>828
> >>820
> 何に対して、誰から見るとStatelessなのか、Statefullなのか
> って事だよー。
> 上のFileクラスは、使う側から見るとopen、close、readのメソッドが
> Statefullなんだけど、下のFileクラスは、引数のstateに対して
> statefullであって、open、close、readの関係はStatelessだよ。
>
> ようは、stateだけ考えてれば、良いって事。
>
> ん？漏れはコアなseasar利用者じゃないんだが。。。
> モンキーターン見てくる
混乱させてごめんなさい。
レスは、今日はもう寝ちゃうので、また明日以降に。
- 831 名前：デフォルトの名無しさん mailto:sage [04/10/24 02:51:26]
- ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
- 832 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:14:28]
- ドメインモデル->実世界の構造のウツシミ
- 833 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:17:11]
- 結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
- 834 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:20:59]
- モデリングの本とかで問題領域とかいわれてる部分。
簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
- 835 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:23:09]
- あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
- 836 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:44:42]
- なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
- 837 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:01:43]
- 児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。
釈然としない所もあるけどさー。
- 838 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:08:57]
- > 釈然としない所もあるけどさー。
どういうところ？
- 839 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:19:41]
- 2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。
でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。
こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
- 840 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:30:49]
- >>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。
その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
- 841 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:32:09]
- >>839
マジカの出番かな？
- 842 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:59:47]
- マジカ？
- 843 名前：デフォルトの名無しさん mailto:sage [04/10/24 05:01:25]
- >>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
- 844 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:31:16]
- 結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
- 845 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:48:45]
- Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。
ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。
S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。
>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。
この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
- 846 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:58:45]
- >>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。
- 847 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:00:29]
- >>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。
- 848 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:04:19]
- >>846
俺は>>845じゃないけど
「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した
っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。
- 849 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:11:58]
- ttp://nekop.programmers.jp/diary/?date=20041024
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz
- 850 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:12:46]
- >>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。
- 851 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:18:07]
- >>849
うちの会社の競争相手は中国人 orz..
- 852 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:25:51]
- >>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。
- 853 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:26:46]
- 先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz
- 854 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:47:18]
- >794
>>漏れ的には、迷ったらメンバーで相談する。
これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。
そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。
- 855 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:53:57]
- 段々と下請の悲哀を語るスレと化してきたな
- 856 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:56:26]
- 結局、ソフトウェア開発の本質的で構造的な問題だからな。
- 857 名前：デフォルトの名無しさん [04/10/24 12:09:28]
- 要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。
- 858 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:20:20]
- >>857が投資していいチームを作って漏れをやとってくれYO
- 859 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:29:31]
- 問題は>>858が良いメンバーか、ということだが…
- 860 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:51:24]
- >>857
その投資の原資はどこからもってくれば良いのでしょうか？
- 861 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:57:45]
- 資本金。
- 862 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:09:16]
- >>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁
|
 |
