国産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/
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サンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。
0398デフォルトの名無しさん
NGNGMAIN─Seasar─dicon
│
├クラスＡ
├クラスＢ
├クラスＣ
└クラスＤ
「SeasarとはクラスＡ−Ｄの纏め役で、どれを使うかdiconに
書いておけば、そのクラスを返してくれるもの。」
という理解で合ってる？ドキュメントを１ヶ月ほど読み耽って
やっとこ辿り着いた答えがコレだったんだけど・・・・・・
0399デフォルトの名無しさん
NGNG0400デフォルトの名無しさん
NGNGひがさんが問題としていることは、OOSEでも取り上げられているから。
0401デフォルトの名無しさん
NGNG0402デフォルトの名無しさん
NGNG0403デフォルトの名無しさん
NGNG>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。
OOSEのP120~P129はその答えとなりませんか?
0404デフォルトの名無しさん
NGNGちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。
0405デフォルトの名無しさん
NGNG>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。
そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。
>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。
複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?
0406デフォルトの名無しさん
NGNG読む人のせいにする筆者
0407401
NGNG最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
（もしかすると若干記述が古くてハマるかもしれん）。
俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。
0408デフォルトの名無しさん
NGNGそうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽﾋｯｸﾋｯｸ
>>404
ぶっちゃけその通りです＞ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ？」という明後日な視点でドキュメントを読み続けてました。
髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ？」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが＿|￣|○|||
最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたｗ
0409デフォルトの名無しさん
NGNG>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが
余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。
RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて
「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
と言ってるのだが。
0410デフォルトの名無しさん
NGNGS2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。
0411デフォルトの名無しさん
NGNG>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」
原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな？
0412デフォルトの名無しさん
NGNG0413デフォルトの名無しさん
NGNG0414デフォルトの名無しさん
NGNG0415デフォルトの名無しさん
NGNG> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。
「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言．今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い．自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか．
0416デフォルトの名無しさん
NGNGOO厨ｷﾀｰ！
0417デフォルトの名無しさん
NGNG同じコトをファウラーﾀｿにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか？
SQLのあまりにもな例といい結構ファウラーﾀｿも危ういと感じる。
0418デフォルトの名無しさん
NGNGいいんだけど、ファイル名が怪しい
0419デフォルトの名無しさん
NGNGムリだってことがハッキリしたと思う。
これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。
0420デフォルトの名無しさん
NGNG0421デフォルトの名無しさん
NGNGわからん
前提があるからどうなんだ？
0422デフォルトの名無しさん
NGNGDI + II まだー？
0423デフォルトの名無しさん
NGNGフレームワークやパターンや開発手法を共有するしかない、ということ
0424デフォルトの名無しさん
NGNGPhotoshopやEclipseはどうなんだ？
プラグイン毎にソフト作り直すのが現実的なのだろうか
業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う
0425デフォルトの名無しさん
NGNG未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。
0426デフォルトの名無しさん
NGNG原文読め
自分がネタにマジレスってことに気付くから
0427デフォルトの名無しさん
NGNGベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。
0428デフォルトの名無しさん
NGNG> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。
■ このスレッドは過去ログ倉庫に格納されています