-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590154デフォルトの名無しさん
2006/07/28(金) 01:46:470155デフォルトの名無しさん
2006/07/28(金) 02:10:29同じプロジェクトに居たりすると困るよなぁ。
やたらと、自作ライブラリを使わせようとしたり、
頼んでも無いのに勝手にこれ使ってくださいとか言ってきたりする奴。
身の回りに一人居るが、
今、新人を洗脳してるw
型って何？、レベルの人間に
懇々と我流オブジェクト指向について熱く薀蓄を語っては、
新人のやる気を萎えさせてる。
おかげで、久しぶりに開発人数が増えそうなのに、
辞めてってしまいそうだ。
0156デフォルトの名無しさん
2006/07/28(金) 21:20:140157デフォルトの名無しさん
2006/07/28(金) 21:27:46困るなら論破すればいいのに
0158デフォルトの名無しさん
2006/07/30(日) 10:03:49俺の事言われてるのかと思ったw
まぁ、数千行の関数とかコピペで作る奴よりマシだと思ってるけど。
俺は自作ライブラリ作るときは、シンプル＆単機能な設計でUnitTestとセットで提供しているから問題ないよな。
0159デフォルトの名無しさん
2006/07/30(日) 10:10:14そのまま作らせろ
0160デフォルトの名無しさん
2006/07/31(月) 00:34:18めでたしめでたし
0161デフォルトの名無しさん
2006/08/01(火) 22:01:01GoF以外のJ2EEとかマルチスレッドとか視点を絞ったパターンまでは手が出ない
0162デフォルトの名無しさん
2006/08/01(火) 22:39:28必要な時に調べて使え。覚える必要は無い
0163デフォルトの名無しさん
2006/08/08(火) 12:54:24AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
のAImpl＜共通実装部分って部分ってテンプレートパターン？
どうも何パターンとかって分類するのが苦手なのよ
0164デフォルトの名無しさん
2006/08/08(火) 13:12:16の人が理解できてる？
Ｃ＋＋やデザパタをつかってプログラムしてもまわりが
理解できず、バグ混入の原因になっているのでは？
オタクなクラス設計やデザパタ使ってるあなたが
結果的にプロジェクトを破壊するテロリストになって
しまっているんじゃないの？
で、実際にトラブルが起きると｢こんなことも理解して
ないなんて一人前のプログラマじゃない！｣とか言って
自分の知識をひけらかしたり、失敗を人のせいにするん
だろ。ラーメン屋の亭主みたいな融通のきかない職人
じゃあるまいし。こういう職人肌みたいな人はＣ＋＋の
テンプレートと共に消えてくれ。頼むから。
｣
0165デフォルトの名無しさん
2006/08/08(火) 13:16:31と、IQ80の君に言われても・・・。
0166デフォルトの名無しさん
2006/08/08(火) 13:30:14もう2002年当時からずっと一緒。
プログラムのﾌﾟウの字も知らない煽り屋が必死に煽ってるだけなんだろ。
無意味
0167デフォルトの名無しさん
2006/08/08(火) 13:32:20彼らから議論の場を取り上げるのは、酷というものであろう。
0168デフォルトの名無しさん
2006/08/08(火) 16:13:43C++は1998年の仕様がまだ実装されてないんだから
0169デフォルトの名無しさん
2006/08/08(火) 19:43:50DBConnection関係のクラスをキモくラップしただけの奴とか。
これを共通で使ってくださいとか指示されると萎えるｗ
0170デフォルトの名無しさん
2006/08/08(火) 19:49:04脳内業務乙。
0171デフォルトの名無しさん
2006/08/08(火) 23:20:46ユースケースから名詞を全部抜き出して一つ一つ吟味したり、
boundary,control,entityって分類分けしたりする？
仕様書が完璧に出来てるならやってもいいけど、
仕様書が完全になるの待ってたらいつまでたっても仕事に取り掛かれないし、
仕様変更のたびにそんなんやってらんないよね。
0172デフォルトの名無しさん
2006/08/09(水) 10:15:03ソースの中に簡単なFactoryパターンが含まれていたんだが、
一人だけFactoryが分からないやつがいた（年齢だけでいえば中堅）。
まあパターンを知らないってのは別によい、知らなくてもコードを
読めば何やってるか分かるはずだからな。
と、みんな思ってたんだが、いくら説明しても伝わらない。
細かく聞いていったらどうやら継承とインスタンス化の違いが分かっていなかった
ということが判明。
そんな人を設計から外す方法を相談させてください。
0173デフォルトの名無しさん
2006/08/09(水) 11:02:330174デフォルトの名無しさん
2006/08/09(水) 12:55:400175デフォルトの名無しさん
2006/08/09(水) 13:16:12スレ違い
0176デフォルトの名無しさん
2006/08/09(水) 13:46:24無理に設計に絡ませると、「馬鹿でも分かる、かつOOを生かす方法とは？」になるか。
最近流行のDIが近い回答か？
0177デフォルトの名無しさん
2006/08/19(土) 10:58:060178デフォルトの名無しさん
2006/08/19(土) 12:07:22というか、板違い。どう考えてもマ板の話題。
>>172
オブジェクト指向が理解できないPG
http://pc8.2ch.net/test/read.cgi/prog/1103581270/
0179デフォルトの名無しさん
2006/10/05(木) 13:05:290180デフォルトの名無しさん
2006/10/06(金) 22:17:05フレームワークそのものはOOしないで高速にして欲しいと思う。
Hibernateとかは内部はMapで公開するときだけBeanらしいし
何は無くともちょっぱやってのをコンセプトにしたフレームワークが欲しい。
0181デフォルトの名無しさん
2006/10/07(土) 04:02:330182デフォルトの名無しさん
2006/10/10(火) 09:52:51な、なんだってー(AA略
0183デフォルトの名無しさん
2006/10/10(火) 19:12:27公開部だけをOOにしたnew最小限ロジックが描けるけど
世間ではこういうのってタブーなのかね
0184デフォルトの名無しさん
2006/10/11(水) 08:19:280185デフォルトの名無しさん
2006/10/12(木) 22:11:57Javaって時点で速度犠牲にしてんだから
C言語のフレームワークとかｗ
0186デフォルトの名無しさん
2006/10/12(木) 23:52:58フレームワーク
って何？
0187デフォルトの名無しさん
2006/10/12(木) 23:58:53枠組みの中での仕事。その作業が出来る環境が用意された中で仕事する。
0188デフォルトの名無しさん
2006/10/13(金) 01:35:530189デフォルトの名無しさん
2006/10/14(土) 13:20:59逆じゃね？
0190デフォルトの名無しさん
2006/10/14(土) 13:42:310191デフォルトの名無しさん
2006/10/14(土) 23:50:33逆なのは和訳の方だろｗ
0192デフォルトの名無しさん
2006/10/28(土) 00:05:34ビジネス層の記述としてどの設計が一番合理的ですかね？
/*
データオブジェクトにはいかなるロジックも載せないぞ、と
*/
public Member addMember( String groupname, String membername ) {
Group group = this.integration.getGroup( groupname );
this.integration.assignMember( group, membername );
return group.getMember( membername );
}
/*
データオブジェクトがなんでもやっちゃうぞ、と
*/
public Member addMember( String groupname, String membername ) {
Group group = this.integration.getGroup( groupname );
group.addMember( membername );
return group.getMember( membername );
}
/*
データオブジェクトはデータソースにはアクセスしないぞ、と
*/
public Member addMember( String groupname, String membername ) {
Group group = this.integration.getGroup( groupname );
group.addMember( membername );
integration.updateGroup( group );
return group.getMember( membername );
}
0193デフォルトの名無しさん
2006/10/28(土) 00:13:11DBへの問い合わせメソッドを記述したインタフェースを
用意するのがDAOパターンじゃなかったっけ？
こうしておくと分業体制のときにスタブが作れるし
レイヤーを分けることによる保守性の向上にも役立つ利点があったはず。
0194デフォルトの名無しさん
2006/10/28(土) 16:36:01関連を考慮しないのであれば、それだけでよいのですが。
Member が Group に所属する、というような構造があった場合に、
その関連をどの部分で扱うかということです。
テーブルと等価な JavaBeans を DAO で get した場合、
例えば、
Group group = dao.get();
としても、得られるのは Group の情報だけだとすると、
Member のリストを得るような処理は、どこにどのように入れるのが妥当なのか、
という問題です。
0195デフォルトの名無しさん
2006/11/17(金) 21:57:43書いてあるけど、ｸﾗｽのDLLだけ増やして済むならその通りだけどさぁ。
実際はｸﾗｽが増えれば結局参照の追加やﾋﾞﾙﾄﾞのし直しが発生するじゃん？
そこらへんまで書いて説明してないよね。ｸﾗｽと実ﾌｧｲﾙの構成まで説明してくれよ。ﾋﾞﾙﾄﾞやり直すんなら
単一ﾌｧｲﾙのでっかいｸﾗｽでもいいじゃん、てならね？
0196デフォルトの名無しさん
2006/11/17(金) 22:49:26えーと、それはモデルと実装がゴッチャになってるだけなのではないかと思いますが？
0197195
2006/11/18(土) 11:07:44ゴッチャというか、でも実装を考えないでﾓﾃﾞﾘﾝｸﾞしたって意味ないじゃん？
例えばﾌｧｸﾄﾘﾊﾟﾀﾝでｸﾗｽ生成のｸﾗｽをFactory.dllとして機能ｸﾗｽがbuhin1.dll、buhin2.dll
ってあったとしてbuhin3.dllを増やしたら関係ないbuhin1.dllとｸﾗｲｱﾝﾄもﾋﾞﾙﾄﾞし直しじゃん？
そんならclass.dllにまとめて放り込んでこいつのﾋﾞﾙﾄﾞだけでってのもアリなんじゃって
気がするけどこれは実装のﾃﾞｻﾞﾊﾟﾀ？みたいのからは外れちゃうんだしょ？
こういった場合の良設計ﾊﾟﾀｰﾝを教えてくださいまし。
0198デフォルトの名無しさん
2006/11/18(土) 23:45:24自分は Java しかしらんけど、Product 抽象クラスなり、
インターフェイスを作れば、具象クラスがいくら増えようが、
利用側は再コンパイルはいらんと思うのだが、
怒涛熱湯はそういうことはできないの？
つうか、Product を抽象化できないなら、 Factory のありがたみは半減のような・・・。
0199195
2006/11/19(日) 18:53:40>関係ないbuhin1.dllとｸﾗｲｱﾝﾄも
↓
関係ないFactory.dllとｸﾗｲｱﾝﾄも
>>198
> ようしらんけど、怒涛熱湯って、必ず、１クラス１DLL なの？
いや、一個のdllにまとめてもよいけど、そうすると一箇所のｸﾗｽの修正だけで
ｱｾﾝﾌﾞﾘ(dll）のﾊﾞｰｼﾞｮﾝが上がってしまうからどのｸﾗｽが修正されたか管理上
わかりにくいよね。
> 自分は Java しかしらんけど、Product 抽象クラスなり、
> インターフェイスを作れば、具象クラスがいくら増えようが、
> 利用側は再コンパイルはいらんと思うのだが、
> 怒涛熱湯はそういうことはできないの？
逆に俺はJava知らんけど、ﾄﾞﾄﾈﾄはﾍﾞｰｽｸﾗｽで変数を定義してても実際にｲﾝｽﾀﾝｽ化
される実態のｸﾗｽが含まれるdllを事前に参照しておかないと無理。
つまり言葉のまま参照設定が必要。遅延ﾊﾞｲﾝﾃﾞｨﾝｸﾞでできなくはないけど普通やらない。
VS2005からは複数のdllとかのﾌｧｲﾙを一個にまとめる機能が付いたみたいだけど、それは
提供上の管理性とかが主眼でこれの問題とは別箇だからなぁ・・
0200デフォルトの名無しさん
2007/01/08(月) 20:47:550201デフォルトの名無しさん
2007/01/15(月) 01:10:510202デフォルトの名無しさん
2007/01/15(月) 01:12:360203デフォルトの名無しさん
2007/01/30(火) 23:09:50悩んでるんでアドバイス頂けませんでしょうか？
良くあるケースだと思うのですが
DBに、n:nの関係の2つのテーブル（AとB）があって、
間に、お互いのIDの主キーにした関連付け用テーブルCがあるとして
Bのテーブルの、あるIDとあるIDを持っているAの列（カラムは全部）取得した時、
結果を配列（又は配列オブジェクト）で取得するじゃないですか？
で、しかもCにある情報も使いたい時って取得した配列を回して、
また、DBにCの情報を要求しなきゃならないじゃないですか？
例えば食べ物屋（テーブルA）をメニュー（テーブルB）で検索して、
メニューそれぞれの値段（テーブルC）も取得する時、などをイメージしてもらえると良いと思います。
この時shop_classに色々な条件で検索して配列を返すメソッドを実装するのが良いのでしょうか？
私が思いついたのはshop_classには一件分の店データ（店データと複数のメニューデータ）
を取得するメソッドのみを実装して、別のクラス（例えばshop_search_class）で関連付けテーブルから
条件にあった店のIDのみを取得して、その配列を回してshop_classのメソッドを実行して最終的な
データを得るのは方法なのですが、変でしょうか？
なんか無駄なDBへの問い合わせが一回多いようにも思われるし、
すごい感覚的な物なのですが、
一件分のデータを得るクラスと複数の店を検索してリストを得るクラスを
同じクラスにするのになんか抵抗があった物で。
ご意見ありましたらお願い致します。
長文すいません。
0204デフォルトの名無しさん
2007/01/30(火) 23:26:34分かった奴、いるか？
0205デフォルトの名無しさん
2007/01/30(火) 23:33:10A=店マスタ、B=商品マスタ、C=ラインナップテーブルで
A：Cが１：N、C：Bが１：Nに見えるけど、認識違い？
基本はCに対してSELECTかけてAのIDのリストを得ると思うし
詳細検索ならBを絞り込んでから、検索条件としてのCのリストを得て、そこからAのIDリストを得る。
内部的なSELECT回数は別として、SQLだけならひとつだけでいけると思うが。
0206デフォルトの名無しさん
2007/01/30(火) 23:55:21駄文で読むの疲れるから、流し読みしたんだが言ってることはわかる
つまり彼はRDBを否定する考えの持ち主
>>202
文章もプログラムもセンスないね
この小学生の文章はなに？新入社員？
読ませる気がなくてあれを書いたのなら君は大物だ
>DBに、n:nの関係
n:nじゃなくてUMLに則って*対*のほうがいいと思う
0207デフォルトの名無しさん
2007/01/31(水) 00:00:58>>202 を哀れむスレとなりますた。
0208デフォルトの名無しさん
2007/01/31(水) 00:12:00DBを使う場合、プログラムで何度もSELECTするよりも結合を使って
一回でやったほうが速いと普通思うので、配列に一度いれてからSELECTする
のはあまりやらないかも。
あと、クラスは、テーブルをベースにするのではなくて、検索結果をベースに
したほうよさそうですね。
その例だと、shopの配列を持つクラスとして、メソッドで検索条件を渡す感じで
よいか思いますが。
0209デフォルトの名無しさん
2007/01/31(水) 00:14:42見やすいからテーブル結合よりそっちのがメインなんだよね
0210デフォルトの名無しさん
2007/01/31(水) 00:25:57ｽﾚ違いな気もするが
DBと流すQUERYにもよると思うが、そんなに変わらないと思うけどね
0211203
2007/01/31(水) 08:51:59>>206
>>208
レスありがとうございます。
ちょっとすれ違いな話になってきちゃいましたが
例えば商品Xを扱っている店とその店が扱っている全ての商品、
店1（商品X・商品Y）
店3（商品X）
店6（商品X・商品S・商品Y・商品Z）
↑こういうの取り出したい時って一回のSQLでいけるんでしょうか？
だとしたらSQLの勉強不足と言うことで、悩みは一気に解消なのですが。
DB版行った方がよさげですか？
0212デフォルトの名無しさん
2007/01/31(水) 10:25:47副問い合わせやGROUP_CONCAT()を使えばできますが
ここよりはSQL関連の質問ｽﾚへほうがいいかも
0213211
2007/01/31(水) 12:36:44ありがとうございます
GROUP_CONCAT()というのは知りませんでした。
というか、使ってるのがpostgreSQLなんですけど、
ちょっと調べてみたらpostgreにはないっぽいですね。
自作関数を実装しなきゃならないようです。
どっちにしてもすれ違いなので、SQLの方に行ってみます。
皆さんお世話になりました。
0214デフォルトの名無しさん
2007/01/31(水) 23:56:42>自作関数を実装しなきゃならないようです。
せっかく >>212 が指摘してくれた
「副問い合わせ」の件は無視かよ・・・
ま、ご自由に(w
0215デフォルトの名無しさん
2007/02/01(木) 00:14:33おもしろいよね
おれもそんなじきがあったのかなぁ
0216デフォルトの名無しさん
2007/02/02(金) 15:36:07世の中の要素技術全てについて初心者を脱却した人なぞおらん。
ということはもう新たな要素技術を知る必要のない立場／ポジションにいるわけだ。
0217デフォルトの名無しさん
2007/03/07(水) 09:06:47うぬぼれすぎじゃねw
0218デフォルトの名無しさん
2007/03/09(金) 00:06:580219デフォルトの名無しさん
2007/03/10(土) 02:32:490220デフォルトの名無しさん
2007/03/10(土) 07:43:59observerがイベントを監視し、subjectに対しイベントに変更があったこと通知、
そして、subjectが他のobserverに通知。
なんて教えられたんだけど
このぐらいの変更なら許容範囲？
0221デフォルトの名無しさん
2007/03/10(土) 10:48:54observerがsubjectへ変更を加える事があっても、subjectに
何かを通知する事はない
もっともobserverが別のobserverのsubjectなら話は別だが
0222デフォルトの名無しさん
2007/03/28(水) 01:38:170223デフォルトの名無しさん
2007/05/13(日) 22:19:14Observerパターン使ってViewがイベントを受け取ったらControllerに渡して、ControllerからServiceを用いてデータ操作→Modelに加工して保存→通知してViewのリペイントって感じですか？
単純なSwingアプリでModelとかServiceってどういう役割になるのか分かりません。Modelの役割ってどういうものなのか、実例を見てみたいのですが。。。経験が全く無いので困ってます。どなたか設計の勉強になる本とか教えて下さい。。。
0224デフォルトの名無しさん
2007/05/13(日) 23:58:46最近は明らかに自作の方が安いよね。とC2Dマシンを組終えてMemtest中の俺が流れを無視して言ってみる。
E6600、メモリ1GBx4、HDD320GBx4、GF7900GS、電源550W、ケースだけ古いSongcheerを使い回し。
最近アキバはキモいのでツクモで一括通販。
この組み合わせで16万ちょいなんてDELLじゃ絶対ムリ。
ま、確かに超ローエンドだとキーボードとか他のパーツが占める割合が増えるから結果として安いけどね。
特にハイスペックでなくとも容量なんかが欲しければ自作の方が安い。
嫁もIntelMacになってMacに見切り付けたみたいだから次は安く上がるなｗ
元がMac G5だからお下がりのP4 3Ghzでも速く感じるだろうｗｗｗ
0225デフォルトの名無しさん
2007/05/14(月) 00:01:110226デフォルトの名無しさん
2007/05/14(月) 00:08:330227デフォルトの名無しさん
2007/05/15(火) 16:01:490228デフォルトの名無しさん
2007/05/18(金) 12:24:330229デフォルトの名無しさん
2007/05/21(月) 02:41:100230デフォルトの名無しさん
2007/06/15(金) 08:33:51なかなかいいアイデアがまとまりません。どこか良いサイトや何かよいアイデアありましたらお願いします。
ちなみに今考えているのは、
CState 状態S。次の遷移先を教える。CEpsilonとCDeltaの派生CDeltaMultiple、CDeltaRangeを複数保持。
CEpsilon イプシロン遷移。複数の遷移先(CState*)を保持する。
CDeltaMultiple 複数の遷移条件で一つの遷移先(CState*)を保持する。
CDeltaRange ある範囲の遷移条件で一つの遷移先(CState*)を保持する。
CStateChart 複数のCState*を保持管理する。最初の状態S0を教える。
CAutomaton 一つのCState*を保持する。
CAutomata 複数のCAutomatonを管理する。CStateChart*を持ち、入力(シグマ)に応じて適切な状態を持つCAutomatonを生成する。
このような感じになっています。
しかし、これだと入力(シグマ)の型によってテンプレートにしてソースを晒したりしなければいけません。
よろしくお願いします。
0231デフォルトの名無しさん
2007/06/16(土) 00:05:110232デフォルトの名無しさん
2007/07/04(水) 07:05:40管理されるクライアントクラスはnewで動的に生成されるという物です。
また、マルチスレッド環境での使用も考えています。
class client{
client_management *cmgmt_;
public:
client( client_management *cmgmt ):cmgmt_( cmgmt ){
cmgmt_->add( this ); // 排他処理はcmgmt内で
}
void haandle(){
//クライアントとの通信とか、いくつかの処理
//処理終了で、クライアントと切断後、
cmgmt_->remove( this );
delete this;
}
};
これをserver側で
class server{
client_management cmgmt_;
void listen(){
socket sock = accept();//clientクラスのオブジェクトを返す
new client( &cmgmt_ );
}
};
こんな設計しか思い浮かばなかったのですが、特に
new client( &cmgmt_ )の部分とかdelete thisな部分が嫌な感じがします。
よりベストな設計を伺いたいです。よろしくお願いします。
0233デフォルトの名無しさん
2007/07/04(水) 23:17:11とりあえず設計に関して。
clientがclient_managementを参照するのは良くない。
（少なくとも非constのポインタを持つのは良くない）
clientがclient_managementを知っている必要を感じない。
clientのインスタンスをclient_managementに追加するのは、
今回の例ではserverクラスで行うのが妥当か。
例えば、
client* ptr = new client;
cmgmt_.add(ptr);
clientの削除を行うのも、client_managementに行わせる。
そうじゃなければ何のためにaddしたのかわからん。
複数のclientの管理を統括するためでしょ？
delete this;は色んな意味でありえない。というか最悪。
大体、ptr->haandle();の後、ptrが使えなくなるとは絶対誰も考えないから。
その他
socket sock = accept();//clientクラスのオブジェクトを返す → socketが返っているようにみえる
new client(&cmgmt_); →思いっきりメモリリーク
haandle()メソッドが長い。複数のメソッドに分割すること。
haandle()というメソッド名を見ても何をするメソッドかわからない。
命名が気に入らない
→cmgmtを見て、client_managementだとわかったらエスパー。
→メソッド名、クラス名、一時オブジェクト名の区別がつかない。
0234デフォルトの名無しさん
2007/07/05(木) 15:58:39ありがとうございます。
0235デフォルトの名無しさん
2007/07/09(月) 23:47:140236デフォルトの名無しさん
2007/10/30(火) 21:18:52よくいうビジネスロジックってどういうものを言うのでしょうか。
staticで提供されているユーティリティメソッドなどはビジネスロジックではないのなら、
どういう観点で見てどういうくくりでこの処理を行うビジネスロジッククラスと設計すればいいのでしょうか。
なんとなくはわかっているんですが、なんかしっくりこないんです。
また、ビジネスロジッククラスに作成するメソッドをどのビジネスロジッククラスにコーディングするかは
どのように決めればいいでしょうか。ユーザーに関連する処理だからこのクラスとか、分け方が理解できません｡
0237デフォルトの名無しさん
2007/10/31(水) 04:02:07まずここ嫁
http://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%83%AD%E3%82%B8%E3%83%83%E3%82%AF
全くの初心者の場合、自分で設計しようとしないで
既存のフレームワークやアーキテクチャの流儀に従うと良い
0238デフォルトの名無しさん
2007/10/31(水) 21:25:45レスありがとうございます。
読んでみると意味はわかるのです。ですが、それを実際にかたちにすることができません。
こんなレベルでも実際に仕事をしています。私の会社ではこれらを全て同じクラス内にコーディングするのです。
実際に要件から設計、コーディング、クラス設計を学ぶことができる書籍などはないでしょうか。
書籍を読んでも疎結合だとかビジネスロジックは分離だとか、いろいろ書いてあるのですが
自分の仕事でうまくやることができないのです。
0239デフォルトの名無しさん
2007/10/31(水) 21:48:49どうしても自分で設計したければ、
大き目の本屋に行ってオブジェクト指向
に関係ありそうな本を片端から買って読む。
多分100冊も無いと思う。
その上で、実戦を10回くらい経験すれば
なんとか人並に設計できるようになると思う。
0240デフォルトの名無しさん
2007/11/01(木) 21:38:01どういった方法が最善なのでしょうか。メソッドを細分化するのはいいのですが、引数にDBコネクションを必要とする場合が多くなってしまいます。
0241デフォルトの名無しさん
2007/11/02(金) 01:33:17それも使えないならスレッドローカル変数をつかって
トランザクションマネージャを自作
0242デフォルトの名無しさん
2007/11/08(木) 22:48:52業務フローからメソッドの定義を考えるのはおかしいでしょうか。
インターフェースを人に書いてもらえば実装はいくらでもできるのですが、
いまいちこのレベルまで落とし込む方法がわからずこまっております。
0243デフォルトの名無しさん
2007/11/09(金) 00:37:07PofEAAとかttp://d.hatena.ne.jp/higayasuo/20050818
読んで自分でいろいろ工夫したらいいよ
0244デフォルトの名無しさん
2007/11/10(土) 20:04:09ありがとうございます。書籍を購入して勉強はします、が、、、
ほかにもいろいろ調べたりしなければならないので時間がとれなそうです。
ひがさんのblogは書いてあることの意味はなんとなくわかるのですが、
実践にもっていくには私には少し？難しいようです。
0245デフォルトの名無しさん
2007/11/12(月) 22:36:59この場合、View用の抽象クラスを用意してそれをパターンごとにsetterを用意しようと考えています。
もっとよいアイデアがあれば教えてください。
0246デフォルトの名無しさん
2007/11/13(火) 00:38:460247デフォルトの名無しさん
2007/11/13(火) 00:47:02>>245
同じデータを複数のフォーマットで返せるサービスなのか、
システムで使われるレスポンスデータが複数あるのかどっち？
後者なら設計のコンセプトを知りたい。
0248デフォルトの名無しさん
2007/11/13(火) 01:40:340249デフォルトの名無しさん
2007/11/15(木) 23:16:14特定の引数を持つコンストラクタをリフレクションで探すのってダメかな？
ようはBuilderだけで完結させて、BuilderFactoryは作らない方法。
0250デフォルトの名無しさん
2007/11/16(金) 00:08:41>ドメインロジックを()で囲っているのは、ドメインロジックを
>ドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック
この文のカタカナ率を計算せよ。
チラット見ただけでどんな人なのか全然知らないけど、
日本語をマトモに話せない(話そうとしない)ヤツは、
ろくでもないことが多い。
0251デフォルトの名無しさん
2007/11/16(金) 16:53:20C++で書かれていて、デザインパターンを用いたお手本になるライブラリィソースって
ないっすか？
0252デフォルトの名無しさん
2007/11/16(金) 19:01:290253デフォルトの名無しさん
2007/11/20(火) 18:04:51そいつの人間性はさておき、全然知らないってのは業界人としてどうなのよ・・・
■ このスレッドは過去ログ倉庫に格納されています