国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0297デフォルトの名無しさん
NGNG間違ってないよ。
なんか構造化は悪いものだとか、オブジェクト指向とはかみ合わないとか
勘違いしているやつが多いのか。
0298デフォルトの名無しさん
NGNG実際、ここにはドメインモデルがいいとは書いてあるけど、トランザクションスクリプトがダメな理由は書いてないね。
だから、どっちも疑問といえば疑問なんだけど。
ただ、モデル化は視点の問題だと思ってるので、片方のモデルで適切に分割できないのに片方のモデルでは適切に分割できる、というのが、にわかに信じれない。
複雑なものを細切れにすると、単純なものが複雑に散らばるだけなんじゃないかと。
それよりは、大きな複雑なものがあったほうが、見通しも良くていいんじゃないかと思うわけです。
そのとき、それぞれの部品の単純さを主張しても、意味のある主張になるのかなぁと。
実際に上記のサイトのグラフで線が入れ替わるところのような複雑なものは、単純に例示できないだろうから、難しい話だとは思うんだけど。
0299デフォルトの名無しさん
NGNGそう。
だから、なんでヒガさんが構造化だと言われたことを誤解だと斬って捨ててるのか、疑問。
0300デフォルトの名無しさん
NGNG適切って言葉をどう捉えるか。くーす的なのは「いかに維持しやすいか」が視点だろう。
そのかわりドメインモデルの明快な美しさは失われるが、それはビジネスだから諦める。
理屈ではドメインモデルってみんな好きなんだよ。でも仕事で使ってみると
世の中明快に割り切れるものなんてないし、たとえうまく設計できたとしても
システムは完成した瞬間から陳腐化するから維持運営に結構苦労する。
サービス分割って考えは希望が持てる。業務とコードが対応してるから直すときに躊躇がいらない。
将来一部業務に大変更が発生しても、ほかへの影響なしにそこだけ手を入れられるってのはステキだ。
0301デフォルトの名無しさん
NGNGそれはそれでかまわないと思ってる。でも実際には、そのモデルＡの役割というよりは、モデルＡ
とBとCをつかってほにゃららする、という機能が結構あるんだよ。
結果としてＡがB、Cを保持したりして実現するわけだ。
それがＡというモデルの機能なのか？という疑問というのが１点ある。B、Cでないとどうして
いえるのか？ またＡでもBでもCでもなく、ＡＢＣと取りまとめる別のモデルの機能ではないか？
さらに、その機能のためにＡはB、Cを保持してるわけで、結局は「複雑に散らばってる」わけだ。
大きな複雑なモデルってのは、「大きなものがひとつあって、そこだけ見ればなんとかなる」んじゃ
なくて、細切れのモデルが一つのモデルの中で絡み合ってごちゃごちゃになってて、結局全部の
モデルを理解していないと「大きな複雑なモデル」を理解できない。だから「ドメインモデルは全体を
理解してないと使えない」と言われるわけ。さらにモデルが永続化も担うので、役割過剰と言われ
ても仕方がないと思う。
サービス分割も同じ問題ははらんでるよ（あるサービスが別のサービスと絡み合うとかね）。
ただサービスが一つのビジネスロジック上の役割で分割されているので、触るときに影響範囲が
見えやすいし、「あ、これは別の業務だな」と思ったら躊躇なく分割できる。結果として細切れの
サービスができかねないのは事実なんだけど、細切れのものが業務単位でまとまってるので、
多少はまし、といったところか。
0302デフォルトの名無しさん
NGNG0303デフォルトの名無しさん
NGNGとりあえず前提条件おさらい。
どうやって計ったかはしらないけど、トランザクションスクリプトだと天井つきぬけるくらいコストがかかるとファウラーが主張するくらいビジネスロジックが複雑なときの話。
で大きいまま分割できないドメインのモデルがある。
そのとき、そのドメインのモデルは、その大きさのままが維持しやすいことになるんじゃないのかなぁ。
将来そのモデルのかかわる一部業務に大変更が発生しても、いろいろなところを追わずに、そのモデルだけ修正すれば済むわけで。
もちろん、分割できないモデルだから、そのモデル全般に影響が及んでるだろうけど。
縁がありそうな程度の複雑さのビジネスロジックでは、>>300に賛成。
0304デフォルトの名無しさん
NGNGうーん、なんか逆な気がするな。
大きく複雑なモデルは仕事をいろんなモデルに移譲しまくってるので、「業務」単位でみると、
一つの業務追加・変更で複数のモデルに影響がでるよ。
モデルの分割単位はあくまで「なんらかのビジネス上の概念」であって、業務ではないからね。
で、たいていの業務では、「なんらかのビジネス上の概念」が複数絡まってるもんだ。この複数
絡まってる機能をどこにおく？という話じゃないか。
0305デフォルトの名無しさん
NGNGいや、そのとき、ドメインモデルだと細切れのモデルが絡み合っててごちゃごちゃになってて結局全部のモデルを理解してないくらい複雑なのに、サービス分割だと影響範囲が見えやすく業務単位でまとまってるってことはないんじゃないのかな、と。
サービスを、躊躇なく分割したり業務単位でまとめれるなら、ドメインモデルも同じように分割して業務単位でまとめれる可能性が高いんじゃなかろうか。
0306デフォルトの名無しさん
NGNGもちろん、複雑じゃない業務ロジックの話で、ドメインモデルよりサービスでの分割がいいというのは、同意できる。
0307デフォルトの名無しさん
NGNGそうだね。でもそのようにドメインモデルを分割したら、それはドメインモデルじゃないんじゃない？
ドメインモデルはそのモノが担うべきものだけを提供すべきで、業務的な必要性から関係ない機能を
追加するもんじゃないからさ。理想としては、もし業務要件が複数のモデルが絡み合うものなら、
複数のモデルを直すべきなんだよね。
業務要件で勝手にまとめてどっかのモデルに押し込んじゃったりしたら、ドメインモデル特有のオブジェ
クト指向的美しさは台無しじゃないか？ でもビジネスはそんな美しさは関係ない訳で、そこに軋轢があ
るんじゃないか。
サービスだと、そもそも業務単位でまとめるもんなんだし、分割しやすいしまとめやすいってことじゃ
ないかと。まあ業務要件があって仕事があるという現実に即した分割方法じゃないかな？
0308デフォルトの名無しさん
NGNGまずどういうシステムを対象にどのように測定したのか知りたい。
同じシステムをそれぞれのパタンで作って比較したのか、
それとも色んなシステムを比較したのか。どこかにどのように
調査したのか書いてるのある？
0309デフォルトの名無しさん
NGNGその意見が、非常に複雑な業務ロジックで成り立つのかが疑問なんです。
まあ、その解を得ることに、「>>308の図が読み解ける」という以上の意味はないんだけど。
というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
もちろん長い年月ソフトウェアに関わって、いろいろな開発をみてきて、実際の測定もしてきたわけだから、それなりの根拠があることは間違いないんだけど。
0310デフォルトの名無しさん
NGNGありがちなのは飛行機工場の生産管理とかかな？
0311デフォルトの名無しさん
NGNG0312デフォルトの名無しさん
NGNG0313デフォルトの名無しさん
NGNGトランザクションスクリプトは、任意の単位に分けられるから
機能単位に分ければ良いが、
ドメインモデルは、意味のあるデータ単位に振る舞いを持たせるから
機能単位に分割できないという話でしょ。
0314デフォルトの名無しさん
NGNG> というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
禿胴
0315デフォルトの名無しさん
NGNGファウラーのいっているトランザクションスクリプトは、
1つのクラスでメソッド分割するイメージなんだと思うな。
それだったら、複雑になればなるほどクラスが大きくなるから
その維持は大変になる。
ドメインモデルは、複雑とはいっても複数のクラスに処理が
分散されているからましということなんじゃないだろうか。
そういう前提なら、http://www.nri-aitd.com/tips/image/g-patern_4.gifも
まぁ、そうかなという気もする。
くーすでいっている役割分担によるコンポーネント分割方式なら、
複雑になっても、それぞれのコンポーネントの役割は明確で、
小さいから維持は、ドメインモデルよりしやすいだろう。
0316デフォルトの名無しさん
NGNGいや、それで、トランザクションを分けたときに、業務単位にまとめれたり、影響範囲がみえやすかったりするのだろうか、と。
ドメインモデルでは、複雑でごちゃごちゃに絡み合ってそれ以上分割できず、全体をみないといけないのにだよ？
0317デフォルトの名無しさん
NGNGなんで、単純比較してしまうとなあ。
0318デフォルトの名無しさん
NGNG業務単位に最初からクラスを作れば良いんだから分けられるに決まってる。
影響範囲が見やすいといっているのは、本来独立した複数の業務が
交差することはないためでしょう。
0319デフォルトの名無しさん
NGNGうん、だから、単純な業務ではドメインモデルじゃないほうがいいというのは共通認識になってると思う。
>>318
いちおう、>>303あたりの前提条件みてください。
0320デフォルトの名無しさん
NGNGだから、複雑で分割できないと思っているのは、
データを中心に見ているからでしょう。
データに関連する振る舞いを全部持たせようとするとそうなる。
複数のモデルに関連する振る舞いをどれかのモデルに持たせればそうなる。
機能を中心に見ればそんなことはない。
どんな複雑な機能だって、シンプルな機能に分解できる。
0321デフォルトの名無しさん
NGNG0322デフォルトの名無しさん
NGNG0323デフォルトの名無しさん
NGNGなくて、データの管理と永続化は外に出しちゃって、ビジネスロジックは機能で
分割しましょう」って話じゃないのか？
0324デフォルトの名無しさん
NGNG>というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
PofEAAによるとそれは「nonscientific graphs」らしいよ。
ファウラーたんの感覚的なものに過ぎないんじゃないかな。
0325デフォルトの名無しさん
NGNGだから、機能がシンプルなものに分割できることはわかってるんだけど、そのつながりが複雑になるんじゃないの？と。
で、そういう話をしているときに、単体のシンプルさを主張しても、あまり意味がないんじゃない？
って、だいぶ前に書いた気がする。
0326デフォルトの名無しさん
NGNG萎えた
0327デフォルトの名無しさん
NGNGま、そんなもんなんだろう。
とりあえず、ファウラーたんを信用ことにするよ。
感覚的なものを極端に書いてると思っておく。
ただ、いつもどおり目の青い人の国でのお話だから、日本で鵜呑みにはできんけど。
0328デフォルトの名無しさん
NGNGそういうことか。
どんなに複雑な組み合わせでできたコンポーネント群でも
特定のコンポーネントを見れば、自分と直接関連のある
コンポーネントだけとしか関係を持たないから
つながりも複雑になることはない。
0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNGMartin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50
0331デフォルトの名無しさん
NGNG0332デフォルトの名無しさん
NGNG業務機能とソースコードのバランスをどうとるか、って噺はあんまり聞かないから。
0333デフォルトの名無しさん
NGNGDomain Model＝DOA的OO
ってことでいいのか？
http://www.nri-aitd.com/tips/g-patern.htmlの
それぞれの特徴を見てるとそんな気がしてきた。
0334デフォルトの名無しさん
NGNG話が、ファウラーたんもびっくりレベルの複雑な業務ロジックだったときに、果たしてそういえるのか。
特定のコンポーネントだけをみて、自分と直接関係のあるコンポーネントだけをみて、用が足せるのか。
甚だ疑問。
0335デフォルトの名無しさん
NGNGまたまたスレ違いの質問なんだけど、DOAの原典的な本とか、始祖的な人ってどこらへんになるんだろう？
一度中途半端に調べてみたんだけど、わからなかった。
0336デフォルトの名無しさん
NGNG疑問に思うのは自由だけど、それで用は足せる。
DIでは、自分の直接の知り合いとしか話しないから。
相手を探しにいくことはないんですよ。
コンテナが必要な人をDIしてくれるんだから。
0337デフォルトの名無しさん
NGNG0338デフォルトの名無しさん
NGNGべつにここでDIを出してくる必要はないと思うんだけど。
それと、DIでオブジェクトが組み立てられて、個々のオブジェクトが単純で、少ない数のオブジェクトとしかやりとりしないからといっても、本質的な複雑さが解消できるものではないと思うよ。
本質的な複雑さというのは、系が閉じているときは一定なので、モデリングのやりかたで複雑さがかわるものでもないし。
0339デフォルトの名無しさん
NGNG業務サービスベースで考えるので、そもそもの実装が「なんらかの特定業務に
関連した情報を返す」ということがモデリングのスタート地点になってる。
ドメインモデルは「おれのモデルでできることはここまでだよ。他の処理はほかの
モデルがやるんだろ？ おれは知らんよ」という構成になっているので、各モデルの
位置づけを理解した上で、さらにそれがどうつながってるか理解しないと、何を
やろうとしているのか（何の業務を解決しようとしているのか）分からなくなる。
サービスベースでもサービスが増えればややこしいのは事実。DAOも含めると、３０
近いクラスが絡み合ってることもあるよ。
でもこの複雑さは、おれたちが普通に関数なりメソッドを呼ぶときに「あ、ここはちょっと
別のprivateなメソッドにでも分けるか」とかやってメソッド一つずつをシンプルにして、
１メソッド3000行とかならないようにするのと似てる。つまり機能が複雑になってきたし、
重複しそうだから、一部機能を＿機能として＿分割してるわけで。
おなじ絡み合っているのでも、つながりが追いやすいんじゃないかな。
0340デフォルトの名無しさん
NGNG業務が複雑になったときには、ドメインモデルを構築してないと、「なんらかの特定業務」すらどこで行っていいかわからなくなると思う。
でも、ドメインモデル構築自体の複雑さが問題にならなくなるような複雑なシステムはそれほどない、と。
たぶんシステムの多くを占めてる、流通系とかお店のシステムだと業務がそれほど複雑じゃなくて、商品・サービスの移動と「なんらかの特定業務」がリンクしやすいしね。
0341デフォルトの名無しさん
NGNGでも悪くない気分
0342デフォルトの名無しさん
NGNG0343デフォルトの名無しさん
NGNG0344デフォルトの名無しさん
NGNG変えるのが先だと思う。それとも英語で書く時と日本語で書く時に
使い分けるつもりなんだろうか？
ほんと気分悪い。
0346デフォルトの名無しさん
NGNG誰もファウラータンを禿なんてよんでないよー。
0347デフォルトの名無しさん
NGNG,-､二、 ｰク / 7_／////////^
`ー‐‐' `ｰ' ///////し
_l^l_ i^i i^i ///////
/ ,--┘ Ｕ ﾉ | //////^
!__ニｺ lﾆ.ノ 7/// _,,.. . __
__l^l__へ i^i i^i //^ ．． ＿ ｀ヽ
ﾞ┐r┐Tﾞ ∪ ﾉ | |/ /：：／.┬".) l
く,ﾉr'_,ﾉ lﾆ.ノ ７ _iゞ/ｲ｡_ﾉ _r'''､
| ,へ ,ﾍ / / ﾆ-''^＼¨ ∠.} l
| `ﾞ / / |. ｜l､ヾ⌒-| u r_ﾉﾉ "
| ヾ二ノ | ヽ |`´_,--| i､ﾆイ
| /,ﾆ^＼. | ＼ｌ<-ﾆﾌ ,ノ ,. ＼、'
| | | | | しリj | ＼ ＼￣ ,／ノ/ , | Z
ﾟ ﾟ ﾟ ﾟ `ｰ" ｰ' 〔 /￣／ '", //／ ,.
0348デフォルトの名無しさん
NGNG学級会的道徳観の持ち主の方がすんごい気持ち悪い。
おえー。
0349デフォルトの名無しさん
NGNG本人の前で言わないようなことしてたら同じ穴の狢
他人に腹が立つのは大抵そこに自分を見るかららしいぞｗ
0350デフォルトの名無しさん
NGNGドメインモデルってMVCモデルのMを具現化したものだろ。でもくーすってMVCじゃなくて、
ヤコブソンのBCEを具現化したものだろ。Boundary-Control-Entityって用語を使ってる
ところからして。
BCEってMVCの問題点を解決するものとしてあげられてるんだし、MVCなドメインモデル
から見て矛盾があるのはいわば当然じゃないかな。
0351デフォルトの名無しさん
NGNGファウラーのMVCモデルは、ウェブプレゼンテーション層の中だけの話。
アプリケーション全体をMVCにして、UI以外を全てMに押し付けるモデルは、EJBが重すぎて崩壊してしまったのを見ればわかるように、実際には使い物にならない。
0352デフォルトの名無しさん
NGNGあとEJBが重すぎるのはリモートコールを多用するからじゃないか？
ローカルコールで動かすと、悪名高いEntityBeanですらそれなりの速度で動くぞ。
0353デフォルトの名無しさん
NGNGそれと、蒸し返すといっても、少なくともこのスレでMVCという言葉は出てきたことがないのだが。
0354デフォルトの名無しさん
NGNGじゃあ、蒸し返すのでなく次の話題ってコトでどうだろうか.....
0355デフォルトの名無しさん
NGNG0356デフォルトの名無しさん
NGNGでも、ファウラーのMVCでは、Vはドメインモデルとやりとりしない。
MVCmodel2とファウラーのモデルは対応しない。
というか、MVCmodel2で、やんちゃなV(JSP)と、たよりないC(Servlet)を与えられて、「あとはMです。ご自由に」と広大な空き地をおしつけられても、ねぇ。
0357デフォルトの名無しさん
NGNGMVCmodel2としてVに渡されるMは、ドメインモデルとは別のものでVが必要とするM。
ドメインモデルのMからMVCmodel2としてのMへの翻訳が必要。
おれはかならずこの翻訳を意識している。
翻訳しないケースがあれば、それはたまたま両者が一致しているという特殊ケースと位置付ける。
0358デフォルトの名無しさん
NGNGそのMVC Model2のモデルとドメインモデルの変換コストの話が
http://d.hatena.ne.jp/higayasuo/20041207#1102379088
http://d.hatena.ne.jp/higayasuo/20041220#1103516338
で、ドメインモデルが工数がかかるという根拠になってるみたい。
結局話題がリンクしてる?
0359デフォルトの名無しさん
NGNGkusuが対象とする開発は20-50人の中規模と思うのだけど、
開発者にDIについての認識を強要するのは酷な話。
少なくとも、開発者全員が一読するという代物ではない。
であれば、kusuって開発の方法論であって開発標準ではないよね。
この規模の方法論って他にもあるのに、なんであえて提唱したのか
よくわからないんだよなぁ。
0360デフォルトの名無しさん
NGNG翻訳といっても、その幅は広いよね。
インスタンスへのリンクを渡すだけのファサードな場合もあれば、ドメインモデルの全プロパティをコピーするDTOな場合もある。
357の意図してるのはどちら?
0361デフォルトの名無しさん
NGNG同じ規模のものが他にあっても、提唱しない理由にはならないでしょ。
ほとんど同じものが他にあるなら別だけど。
0362デフォルトの名無しさん
NGNGhttp://www.google.co.jp/search?hl=ja&q=%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%8C%E9%A0%91%E5%BC%B5%E3%82%8B+mvc
とかBuschmann本とか。
くーすと「レガシーなオブジェクト指向」との距離は、
Webアプリへの最適化によるものだ、と言ってみるテスト。
0363デフォルトの名無しさん
NGNGDIスレと分けた意味はあるんだろうか？
0364デフォルトの名無しさん
NGNGWebじゃなくても、基本的には変わらんと思うが。
0365デフォルトの名無しさん
NGNG他のものとどこが違うか、よくわからない。
Seasarに依存するってとこ？
0366デフォルトの名無しさん
NGNGPofEAAの解説にしかみえないのは、俺だけ？
0367デフォルトの名無しさん
NGNGいや、比嘉氏は既存の中規模システム開発用の開発標準にでは
満足いかなかったのではないかと思う。つまり、RUPを軽くした
国内開発者向けの標準を作らなければならないという危機感が
あったのではないか、と、そんな気がする。
kusu本を出すなら、その辺の経緯も記してもらいたい。
0368デフォルトの名無しさん
NGNG0369デフォルトの名無しさん
NGNG自分の技術レベルが低いと思ったら使えばいいんじゃないの。
037044
NGNG>話を簡単にするために常にデータと振る舞いを一緒にするというのは、
>それはそれでOK。
>
>ただし、機能が増えるにしたがって役割多すぎなクラスになる
>危険性があるということです。最初は、データと構造を一緒に
>しておいて、機能が増えてきたらリファクタリングすればいい
>という考えもあるかもしれません。しかし、それは、
>リファクタリングではありません。利用する側から見て
>インターフェースが変わってしまうからです。
インターフェース/クラスの内部でExtract Classしたクラスへ対して委譲すればいいだけでは?
そうすればインターフェースは変わりませんよね。
037144
NGNG>「データ構造を公開することによる疎結合性を妨害」という点では、
>永続化されるようなデータの構造は、もともとpublicですから特に
>問題にはならないと思います。
何に対してpublicなのでしょうか?
また、データ構造をクラスの外へ公開することによるデメリットとして、修正箇所がアプリケーション中に分散してしまうことなどがあると思いますが、publicであることはこのことに何か解決策をもたらしているのでしょうか?
037244
NGNG0373デフォルトの名無しさん
NGNG>修正箇所がアプリケーション中に分散してしまうことなどがあると
あっちこっち直すことになるかもしれないが、
どの業務機能から使われてるかが分かるから影響範囲が明確になる、とも言える。
これは高度に抽象化をおこなわないことによるメリットかな。
修正が難しいのはデータを「変更」する処理だろうが、それって分散して存在することは稀。
SeasarならS2Daoでエンティティ単位の管理ができるから、そんなに大変ではないだろう。
主として影響を受けるのは大抵は入力・表示関係。そしてそれはUI層の問題だから別の話になる。
0374デフォルトの名無しさん
NGNGだれか分析してくれ。
0375デフォルトの名無しさん
NGNGバウンダリはなんだ？
0376デフォルトの名無しさん
NGNGパンダに熱くなったほうがいいのにね。
0377デフォルトの名無しさん
NGNGひがたん
0378デフォルトの名無しさん
NGNGとりあえず、以後、他人に意見するのは止めることですね。
0379デフォルトの名無しさん
NGNGパンダに意見するのはOKですか？
0380デフォルトの名無しさん
NGNG「易しさと優しさ」とか言ってたのに、あとは、自分でやれってことか？
0381デフォルトの名無しさん
NGNGとりあえず前半部分は技術者の意見とは思えない。
後半は俺が読み違えてるのかもしれないので確認したいんだけど、
public属性の影響を受けるのは、値を設定するところじゃなくて
むしろ単純読込の方が量が多くて問題になる。
たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
という変更があったときに、アクセッサ経由で統一されている方が楽。
そのモデルのサブクラスを作って変数をオーバーライドしちゃうと
ベースクラス側でのメソッドの中でアクセスしてる変数と別物になっちゃうので
スマートな形でサブクラス化できないこともある。
膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
ソースにコメントをつけながらやることであって、できるだけ基本は
守っていた方がいい事が多い。
ひがさんはOOPのメリットをあまり理解できなかった側の人だと思うので、
44さんはもう突っ込まないであげればいいと思う。DI自体は悪くない技術だし、
彼らのモチベーションが高い方がseasarがいい方に行くと思うから。
逆にseasarが好きで変な方向に行って欲しくないからこそ、ひがさんにいろいろ
突っ込みを入れてるのかもしれないけど
0382デフォルトの名無しさん
NGNGそこはスローガンなんだからそんな言い方するこたあないだろ。
「削除も作ってほしいなあ」とか言えば気分良く作ってくれる人が
いるかもしれないのに。
0383デフォルトの名無しさん
NGNG0384デフォルトの名無しさん
NGNGうーん、何が言いたいのかよくわからんわ。
> たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
> という変更があったときに、アクセッサ経由で統一されている方が楽。
だったらそうすりゃいいじゃん。
>>381はフィールドをpublic属性にする話をしているように読めるのだけど...
永続化データがpublicだという話をそう読んだわけ？
永続化されるようなデータはそもそも構造が公開されてるもんだと
いう意味で、publicだと言ってるだけだと思うけど。
S2Dao使ったって結局各データにはアクセッサ使ってアクセスするんだし、
プロパティとして扱ってるから、アクセッサ経由だし。
0385デフォルトの名無しさん
NGNG何だくれくれクンか
0386デフォルトの名無しさん
NGNG何でパンダなんだ？
0387デフォルトの名無しさん
NGNG> 膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
> あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
> ソースにコメントをつけながらやることであって、できるだけ基本は
> 守っていた方がいい事が多い。
すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
想像できんので教えてくれ。
0388デフォルトの名無しさん
NGNG>>381に伝わらなかったってだけじゃないの。
ttp://www.martinfowler.com/bliki/PublishedInterface.html
まあﾏﾀｰﾘ行こうや。>>387
0389デフォルトの名無しさん
NGNGNHKみてなかったの？かわいかったのに。
「NHKスペシャル地球大進化 生命の巨大化」の枠でやってたから、巨大化ってパンダのことかーっ、と思いながらみてますた。
0390デフォルトの名無しさん
NGNG0391デフォルトの名無しさん
NGNGmethod.getReturnType().isAssignableFrom(List.class)
↓
List.class.isAssignableFrom(method.getReturnType())
じゃないか？
0392デフォルトの名無しさん
NGNG比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても影響ないってことだろ。
039344
NGNG>もともと永続化されるデータ、テーブルで管理されるようなデータ
>というのは、その構造は、ER図などで外部に対して公開されています。
>
>一般的に言われるようなカプセル化の話は当てはまりません。
外部の意味が曖昧なので推測で。
ここでい言う「外部」が
>>392
>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。
また、「外部」が外部システム等であったとしても、若干の不自由は強いられるかもしれませんが、それでもなお上記の理由でカプセル化する利点は存在すると考えます。
0394デフォルトの名無しさん
NGNGこのスレ荒らしてあげて下さい。
ウイルス貼りまくっていいですよ。
歓迎します。
039544
NGNG>補足しておくと、ドメインモデルは、もともとデータを持ってる
>クラスに振る舞いを持たせたほうが良いという観点なはずです。それが、
>
>public class Employee {
> private PayCaluculator calculator;
> ...
> public BigDecimal caluculatePay() {
> return calculator.calculatePay(this);
> }
>}
>
>という形だということは、役割でクラス分割するのと実質同じです。
Extract Classは以下のように行うので
http://www.refactoring.com/catalog/extractClass.html
PayCaluculatorクラスができることはありませんです。
0396デフォルトの名無しさん
NGNG> すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ？
> 想像できんので教えてくれ。
業務ロジックかどうかは微妙だけど java.awt.Point数万個を使うようなグラフィック処理。
あと、石油埋蔵量予測システム。(どっかで読んだ)
0397デフォルトの名無しさん
NGNGサンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。
■ このスレッドは過去ログ倉庫に格納されています