国産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/
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> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。
0429デフォルトの名無しさん
NGNG確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。
0430デフォルトの名無しさん
NGNG>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・
0431デフォルトの名無しさん
NGNG何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。
Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。
0432デフォルトの名無しさん
NGNGプラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。
まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。
0433デフォルトの名無しさん
NGNG0434デフォルトの名無しさん
NGNG皆さんネタ厨に餌を与えないでください。
0435デフォルトの名無しさん
NGNG多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。
0436デフォルトの名無しさん
NGNG規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。
0437デフォルトの名無しさん
NGNG0438デフォルトの名無しさん
NGNG0439デフォルトの名無しさん
NGNG感じだったような。今はどうであれ、先の事はわからない。
0440デフォルトの名無しさん
NGNG0441デフォルトの名無しさん
NGNG>440
だから、それはなぜかを示してほしい
0442デフォルトの名無しさん
NGNGJavaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。
0443デフォルトの名無しさん
NGNG二番目が根拠無し
0444デフォルトの名無しさん
NGNG別のとこでやってくれ。
0445デフォルトの名無しさん
NGNG0446デフォルトの名無しさん
NGNG均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか？
それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。
0447デフォルトの名無しさん
NGNG実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。
O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。
0448デフォルトの名無しさん
NGNGしかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。
それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。
0449デフォルトの名無しさん
NGNG0450デフォルトの名無しさん
NGNGプラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。
0451デフォルトの名無しさん
NGNGS2は特にそうだ。
■ このスレッドは過去ログ倉庫に格納されています