- 1 名前：デフォルトの名無しさん [2005/09/24(土) 16:35:59 ]
- 全部publicでいいじゃん！ってならないようにするスレです。
- 185 名前：デフォルトの名無しさん mailto:sage [2006/10/12(木) 22:11:57 ]
- >>180
Javaって時点で速度犠牲にしてんだから
C言語のフレームワークとかｗ
- 186 名前：デフォルトの名無しさん mailto:sage [2006/10/12(木) 23:52:58 ]
- おまえら
フレームワーク
って何？
- 187 名前：デフォルトの名無しさん mailto:sage [2006/10/12(木) 23:58:53 ]
- frameとworkを組み合わせたまんまの意味だよ。
枠組みの中での仕事。その作業が出来る環境が用意された中で仕事する。
- 188 名前：デフォルトの名無しさん mailto:sage [2006/10/13(金) 01:35:53 ]
- プレハブ住宅のイメージだにょ
- 189 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 13:20:59 ]
- >>187
逆じゃね？
- 190 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 13:42:31 ]
- ワークフレーム？
- 191 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 23:50:33 ]
- >190
逆なのは和訳の方だろｗ
- 192 名前：デフォルトの名無しさん [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 );
}
- 193 名前：デフォルトの名無しさん mailto:sage [2006/10/28(土) 00:13:11 ]
- テーブルとある程度等価なJavaBeansと
DBへの問い合わせメソッドを記述したインタフェースを
用意するのがDAOパターンじゃなかったっけ？
こうしておくと分業体制のときにスタブが作れるし
レイヤーを分けることによる保守性の向上にも役立つ利点があったはず。
- 194 名前：デフォルトの名無しさん [2006/10/28(土) 16:36:01 ]
- >>193
関連を考慮しないのであれば、それだけでよいのですが。
Member が Group に所属する、というような構造があった場合に、
その関連をどの部分で扱うかということです。
テーブルと等価な JavaBeans を DAO で get した場合、
例えば、
Group group = dao.get();
としても、得られるのは Group の情報だけだとすると、
Member のリストを得るような処理は、どこにどのように入れるのが妥当なのか、
という問題です。
- 195 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 21:57:43 ]
- ﾄﾞﾄﾈﾄの話なんだけどさぁ。OOPのはどれ読んでもﾃﾞｻﾞﾊﾟﾀ使ってﾎﾟﾘﾓすればｸﾗｽの拡張も楽チンだよぅって
書いてあるけど、ｸﾗｽのDLLだけ増やして済むならその通りだけどさぁ。
実際はｸﾗｽが増えれば結局参照の追加やﾋﾞﾙﾄﾞのし直しが発生するじゃん？
そこらへんまで書いて説明してないよね。ｸﾗｽと実ﾌｧｲﾙの構成まで説明してくれよ。ﾋﾞﾙﾄﾞやり直すんなら
単一ﾌｧｲﾙのでっかいｸﾗｽでもいいじゃん、てならね？
- 196 名前：デフォルトの名無しさん mailto:sage [2006/11/17(金) 22:49:26 ]
- >>195
えーと、それはモデルと実装がゴッチャになってるだけなのではないかと思いますが？
- 197 名前：195 mailto:sage [2006/11/18(土) 11:07:44 ]
- >>196
ゴッチャというか、でも実装を考えないでﾓﾃﾞﾘﾝｸﾞしたって意味ないじゃん？
例えばﾌｧｸﾄﾘﾊﾟﾀﾝでｸﾗｽ生成のｸﾗｽをFactory.dllとして機能ｸﾗｽがbuhin1.dll、buhin2.dll
ってあったとしてbuhin3.dllを増やしたら関係ないbuhin1.dllとｸﾗｲｱﾝﾄもﾋﾞﾙﾄﾞし直しじゃん？
そんならclass.dllにまとめて放り込んでこいつのﾋﾞﾙﾄﾞだけでってのもアリなんじゃって
気がするけどこれは実装のﾃﾞｻﾞﾊﾟﾀ？みたいのからは外れちゃうんだしょ？
こういった場合の良設計ﾊﾟﾀｰﾝを教えてくださいまし。
- 198 名前：デフォルトの名無しさん mailto:sage [2006/11/18(土) 23:45:24 ]
- ようしらんけど、怒涛熱湯って、必ず、１クラス１DLL なの？
自分は Java しかしらんけど、Product 抽象クラスなり、
インターフェイスを作れば、具象クラスがいくら増えようが、
利用側は再コンパイルはいらんと思うのだが、
怒涛熱湯はそういうことはできないの？
つうか、Product を抽象化できないなら、 Factory のありがたみは半減のような・・・。
- 199 名前：195 mailto:sage [2006/11/19(日) 18:53:40 ]
- >>197の訂正
>関係ないbuhin1.dllとｸﾗｲｱﾝﾄも
↓
関係ないFactory.dllとｸﾗｲｱﾝﾄも
>>198
> ようしらんけど、怒涛熱湯って、必ず、１クラス１DLL なの？
いや、一個のdllにまとめてもよいけど、そうすると一箇所のｸﾗｽの修正だけで
ｱｾﾝﾌﾞﾘ(dll）のﾊﾞｰｼﾞｮﾝが上がってしまうからどのｸﾗｽが修正されたか管理上
わかりにくいよね。
> 自分は Java しかしらんけど、Product 抽象クラスなり、
> インターフェイスを作れば、具象クラスがいくら増えようが、
> 利用側は再コンパイルはいらんと思うのだが、
> 怒涛熱湯はそういうことはできないの？
逆に俺はJava知らんけど、ﾄﾞﾄﾈﾄはﾍﾞｰｽｸﾗｽで変数を定義してても実際にｲﾝｽﾀﾝｽ化
される実態のｸﾗｽが含まれるdllを事前に参照しておかないと無理。
つまり言葉のまま参照設定が必要。遅延ﾊﾞｲﾝﾃﾞｨﾝｸﾞでできなくはないけど普通やらない。
VS2005からは複数のdllとかのﾌｧｲﾙを一個にまとめる機能が付いたみたいだけど、それは
提供上の管理性とかが主眼でこれの問題とは別箇だからなぁ・・
- 200 名前：デフォルトの名無しさん mailto:sage [2007/01/08(月) 20:47:55 ]
- っていうか、ファクトリパターン使うなら遅延バインディングにしないと意味ねーじゃん
- 201 名前：デフォルトの名無しさん [2007/01/15(月) 01:10:51 ]
- シナリオ制御をうまいことやんのはどうすんの？
- 202 名前：デフォルトの名無しさん mailto:sage [2007/01/15(月) 01:12:36 ]
- も少し具体的にいったほうがいんじゃね？
- 203 名前：デフォルトの名無しさん [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への問い合わせが一回多いようにも思われるし、
すごい感覚的な物なのですが、
一件分のデータを得るクラスと複数の店を検索してリストを得るクラスを
同じクラスにするのになんか抵抗があった物で。
ご意見ありましたらお願い致します。
長文すいません。
- 204 名前：デフォルトの名無しさん [2007/01/30(火) 23:26:34 ]
- >>203 の言わんとしていることが
分かった奴、いるか？
- 205 名前：デフォルトの名無しさん mailto:sage [2007/01/30(火) 23:33:10 ]
- >>203
A=店マスタ、B=商品マスタ、C=ラインナップテーブルで
A：Cが１：N、C：Bが１：Nに見えるけど、認識違い？
基本はCに対してSELECTかけてAのIDのリストを得ると思うし
詳細検索ならBを絞り込んでから、検索条件としてのCのリストを得て、そこからAのIDリストを得る。
内部的なSELECT回数は別として、SQLだけならひとつだけでいけると思うが。
- 206 名前：デフォルトの名無しさん mailto:sage [2007/01/30(火) 23:55:21 ]
- >>203
駄文で読むの疲れるから、流し読みしたんだが言ってることはわかる
つまり彼はRDBを否定する考えの持ち主
>>202
文章もプログラムもセンスないね
この小学生の文章はなに？新入社員？
読ませる気がなくてあれを書いたのなら君は大物だ
>DBに、n:nの関係
n:nじゃなくてUMLに則って*対*のほうがいいと思う
- 207 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 00:00:58 ]
- 以降、何の罪も無い
>>202 を哀れむスレとなりますた。
- 208 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 00:12:00 ]
- >>203
DBを使う場合、プログラムで何度もSELECTするよりも結合を使って
一回でやったほうが速いと普通思うので、配列に一度いれてからSELECTする
のはあまりやらないかも。
あと、クラスは、テーブルをベースにするのではなくて、検索結果をベースに
したほうよさそうですね。
その例だと、shopの配列を持つクラスとして、メソッドで検索条件を渡す感じで
よいか思いますが。
- 209 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 00:14:42 ]
- 副問い合わせって今でも遅いの？
見やすいからテーブル結合よりそっちのがメインなんだよね
- 210 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 00:25:57 ]
- >>209
ｽﾚ違いな気もするが
DBと流すQUERYにもよると思うが、そんなに変わらないと思うけどね
- 211 名前：203 [2007/01/31(水) 08:51:59 ]
- >>205
>>206
>>208
レスありがとうございます。
ちょっとすれ違いな話になってきちゃいましたが
例えば商品Xを扱っている店とその店が扱っている全ての商品、
店1（商品X・商品Y）
店3（商品X）
店6（商品X・商品S・商品Y・商品Z）
↑こういうの取り出したい時って一回のSQLでいけるんでしょうか？
だとしたらSQLの勉強不足と言うことで、悩みは一気に解消なのですが。
DB版行った方がよさげですか？
- 212 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 10:25:47 ]
- >>211
副問い合わせやGROUP_CONCAT()を使えばできますが
ここよりはSQL関連の質問ｽﾚへほうがいいかも
- 213 名前：211 mailto:sage [2007/01/31(水) 12:36:44 ]
- >>212
ありがとうございます
GROUP_CONCAT()というのは知りませんでした。
というか、使ってるのがpostgreSQLなんですけど、
ちょっと調べてみたらpostgreにはないっぽいですね。
自作関数を実装しなきゃならないようです。
どっちにしてもすれ違いなので、SQLの方に行ってみます。
皆さんお世話になりました。
- 214 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 23:56:42 ]
- >>213
>自作関数を実装しなきゃならないようです。
せっかく >>212 が指摘してくれた
「副問い合わせ」の件は無視かよ・・・
ま、ご自由に(w
- 215 名前：デフォルトの名無しさん mailto:sage [2007/02/01(木) 00:14:33 ]
- しょしんしゃって
おもしろいよね
おれもそんなじきがあったのかなぁ
- 216 名前：デフォルトの名無しさん mailto:sage [2007/02/02(金) 15:36:07 ]
- どんな要素技術についても、全ての人は初心者であった時期はあるだろう。
世の中の要素技術全てについて初心者を脱却した人なぞおらん。
ということはもう新たな要素技術を知る必要のない立場／ポジションにいるわけだ。
- 217 名前：デフォルトの名無しさん mailto:sage [2007/03/07(水) 09:06:47 ]
- >>214
うぬぼれすぎじゃねw
- 218 名前：デフォルトの名無しさん mailto:sage [2007/03/09(金) 00:06:58 ]
- delegate event modelとobserver patternの違いがわかりません＞＜
- 219 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 02:32:49 ]
- 呼び方が違うだけじゃねーの？
- 220 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 07:43:59 ]
- 俺、オブザーバーパターンはsubjectとobserver、２つの要素があって、
observerがイベントを監視し、subjectに対しイベントに変更があったこと通知、
そして、subjectが他のobserverに通知。
なんて教えられたんだけど
このぐらいの変更なら許容範囲？
- 221 名前：デフォルトの名無しさん mailto:sage [2007/03/10(土) 10:48:54 ]
- subjectが、自分が変更されたことをobserverにつうちするんだぞー
observerがsubjectへ変更を加える事があっても、subjectに
何かを通知する事はない
もっともobserverが別のobserverのsubjectなら話は別だが
- 222 名前：デフォルトの名無しさん mailto:sage [2007/03/28(水) 01:38:17 ]
- ふむむむ・・・・・・・・・
- 223 名前：デフォルトの名無しさん [2007/05/13(日) 22:19:14 ]
- Swingアプリの設計って一般的にはどうなってるんでしょうか？
Observerパターン使ってViewがイベントを受け取ったらControllerに渡して、ControllerからServiceを用いてデータ操作→Modelに加工して保存→通知してViewのリペイントって感じですか？
単純なSwingアプリでModelとかServiceってどういう役割になるのか分かりません。Modelの役割ってどういうものなのか、実例を見てみたいのですが。。。経験が全く無いので困ってます。どなたか設計の勉強になる本とか教えて下さい。。。
- 224 名前：デフォルトの名無しさん [2007/05/13(日) 23:58:46 ]
- 一時期デスクトップでも自作よりショップブランドとかDELLの方が安く付いた時期あったけど、
最近は明らかに自作の方が安いよね。とC2Dマシンを組終えてMemtest中の俺が流れを無視して言ってみる。
E6600、メモリ1GBx4、HDD320GBx4、GF7900GS、電源550W、ケースだけ古いSongcheerを使い回し。
最近アキバはキモいのでツクモで一括通販。
この組み合わせで16万ちょいなんてDELLじゃ絶対ムリ。
ま、確かに超ローエンドだとキーボードとか他のパーツが占める割合が増えるから結果として安いけどね。
特にハイスペックでなくとも容量なんかが欲しければ自作の方が安い。
嫁もIntelMacになってMacに見切り付けたみたいだから次は安く上がるなｗ
元がMac G5だからお下がりのP4 3Ghzでも速く感じるだろうｗｗｗ
- 225 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 00:01:11 ]
- 誤爆か？
- 226 名前：デフォルトの名無しさん mailto:sage [2007/05/14(月) 00:08:33 ]
- 次はどんな自作嫁を投下してくれるのか楽しみだ
- 227 名前：デフォルトの名無しさん mailto:sage [2007/05/15(火) 16:01:49 ]
- 大きなおっぱい
- 228 名前：デフォルトの名無しさん [2007/05/18(金) 12:24:33 ]
- プラガブル MVC を Java で説明してくれません？
- 229 名前：デフォルトの名無しさん mailto:sage [2007/05/21(月) 02:41:10 ]
- interface
- 230 名前：デフォルトの名無しさん [2007/06/15(金) 08:33:51 ]
- C++で非決定性有限オートマトン(NFA)のクラスを作りたいと思っているのですが、
なかなかいいアイデアがまとまりません。どこか良いサイトや何かよいアイデアありましたらお願いします。
ちなみに今考えているのは、
CState 状態S。次の遷移先を教える。CEpsilonとCDeltaの派生CDeltaMultiple、CDeltaRangeを複数保持。
CEpsilon イプシロン遷移。複数の遷移先(CState*)を保持する。
CDeltaMultiple 複数の遷移条件で一つの遷移先(CState*)を保持する。
CDeltaRange ある範囲の遷移条件で一つの遷移先(CState*)を保持する。
CStateChart 複数のCState*を保持管理する。最初の状態S0を教える。
CAutomaton 一つのCState*を保持する。
CAutomata 複数のCAutomatonを管理する。CStateChart*を持ち、入力(シグマ)に応じて適切な状態を持つCAutomatonを生成する。
このような感じになっています。
しかし、これだと入力(シグマ)の型によってテンプレートにしてソースを晒したりしなければいけません。
よろしくお願いします。
- 231 名前：デフォルトの名無しさん mailto:sage [2007/06/16(土) 00:05:11 ]
- なんに使うんだそんなもん
- 232 名前：デフォルトの名無しさん mailto:sage [2007/07/04(水) 07:05:40 ]
- C++で書いてます。クライアントクラスの管理をしたいのですが、
管理されるクライアントクラスは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な部分が嫌な感じがします。
よりベストな設計を伺いたいです。よろしくお願いします。
- 233 名前：デフォルトの名無しさん mailto:sage [2007/07/04(水) 23:17:11 ]
- >>232
とりあえず設計に関して。
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だとわかったらエスパー。
→メソッド名、クラス名、一時オブジェクト名の区別がつかない。
- 234 名前：デフォルトの名無しさん mailto:sage [2007/07/05(木) 15:58:39 ]
- >>233
ありがとうございます。
- 235 名前：デフォルトの名無しさん mailto:sage [2007/07/09(月) 23:47:14 ]
- どういたばしく
- 236 名前：デフォルトの名無しさん mailto:sage [2007/10/30(火) 21:18:52 ]
- ここで質問するのが適切かどうかはわからないのですが、
よくいうビジネスロジックってどういうものを言うのでしょうか。
staticで提供されているユーティリティメソッドなどはビジネスロジックではないのなら、
どういう観点で見てどういうくくりでこの処理を行うビジネスロジッククラスと設計すればいいのでしょうか。
なんとなくはわかっているんですが、なんかしっくりこないんです。
また、ビジネスロジッククラスに作成するメソッドをどのビジネスロジッククラスにコーディングするかは
どのように決めればいいでしょうか。ユーザーに関連する処理だからこのクラスとか、分け方が理解できません｡
- 237 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 04:02:07 ]
- >>236
まずここ嫁
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
全くの初心者の場合、自分で設計しようとしないで
既存のフレームワークやアーキテクチャの流儀に従うと良い
- 238 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:25:45 ]
- >>237
レスありがとうございます。
読んでみると意味はわかるのです。ですが、それを実際にかたちにすることができません。
こんなレベルでも実際に仕事をしています。私の会社ではこれらを全て同じクラス内にコーディングするのです。
実際に要件から設計、コーディング、クラス設計を学ぶことができる書籍などはないでしょうか。
書籍を読んでも疎結合だとかビジネスロジックは分離だとか、いろいろ書いてあるのですが
自分の仕事でうまくやることができないのです。
- 239 名前：デフォルトの名無しさん mailto:sage [2007/10/31(水) 21:48:49 ]
- > 実際に要件から設計、コーディング、クラス設計を学ぶことができる書籍などはないでしょうか。
どうしても自分で設計したければ、
大き目の本屋に行ってオブジェクト指向
に関係ありそうな本を片端から買って読む。
多分100冊も無いと思う。
その上で、実戦を10回くらい経験すれば
なんとか人並に設計できるようになると思う。
- 240 名前：デフォルトの名無しさん [2007/11/01(木) 21:38:01 ]
- AOPなどを使えない環境で、DBコネクション管理、コミット／ロールバックを制御したいのですが、
どういった方法が最善なのでしょうか。メソッドを細分化するのはいいのですが、引数にDBコネクションを必要とする場合が多くなってしまいます。
- 241 名前：デフォルトの名無しさん mailto:sage [2007/11/02(金) 01:33:17 ]
- springのトランザクションマネージャ使えば？
それも使えないならスレッドローカル変数をつかって
トランザクションマネージャを自作
- 242 名前：デフォルトの名無しさん [2007/11/08(木) 22:48:52 ]
- ビジネスロジッククラスのインターフェースを考える場合に
業務フローからメソッドの定義を考えるのはおかしいでしょうか。
インターフェースを人に書いてもらえば実装はいくらでもできるのですが、
いまいちこのレベルまで落とし込む方法がわからずこまっております。
- 243 名前：デフォルトの名無しさん mailto:sage [2007/11/09(金) 00:37:07 ]
- >>242
PofEAAとかttp://d.hatena.ne.jp/higayasuo/20050818
読んで自分でいろいろ工夫したらいいよ
- 244 名前：デフォルトの名無しさん mailto:sage [2007/11/10(土) 20:04:09 ]
- >>243
ありがとうございます。書籍を購入して勉強はします、が、、、
ほかにもいろいろ調べたりしなければならないので時間がとれなそうです。
ひがさんのblogは書いてあることの意味はなんとなくわかるのですが、
実践にもっていくには私には少し？難しいようです。
- 245 名前：デフォルトの名無しさん [2007/11/12(月) 22:36:59 ]
- Http通信で、レスポンスがcsvだったりxmlでURIごとにいろいろなパターンを返すのですが、
この場合、View用の抽象クラスを用意してそれをパターンごとにsetterを用意しようと考えています。
もっとよいアイデアがあれば教えてください。
- 246 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:38:46 ]
- Http通信ﾜﾛｽ
- 247 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 00:47:02 ]
- おかしくもなんともないな。
>>245
同じデータを複数のフォーマットで返せるサービスなのか、
システムで使われるレスポンスデータが複数あるのかどっち？
後者なら設計のコンセプトを知りたい。
- 248 名前：デフォルトの名無しさん mailto:sage [2007/11/13(火) 01:40:34 ]
- それ、HotJava (α)時代から提供されてる機能だから。
- 249 名前：デフォルトの名無しさん [2007/11/15(木) 23:16:14 ]
- JavaなんだけどService Provider Interfaceスタイルをとる為に
特定の引数を持つコンストラクタをリフレクションで探すのってダメかな？
ようはBuilderだけで完結させて、BuilderFactoryは作らない方法。
- 250 名前：デフォルトの名無しさん [2007/11/16(金) 00:08:41 ]
- >>243
>ドメインロジックを()で囲っているのは、ドメインロジックを
>ドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック
この文のカタカナ率を計算せよ。
チラット見ただけでどんな人なのか全然知らないけど、
日本語をマトモに話せない(話そうとしない)ヤツは、
ろくでもないことが多い。
- 251 名前：デフォルトの名無しさん mailto:sage [2007/11/16(金) 16:53:20 ]
- グラフライブラリィーを作りたいんだけど
C++で書かれていて、デザインパターンを用いたお手本になるライブラリィソースって
ないっすか？
- 252 名前：デフォルトの名無しさん mailto:sage [2007/11/16(金) 19:01:29 ]
- boost
- 253 名前：デフォルトの名無しさん mailto:sage [2007/11/20(火) 18:04:51 ]
- >>250
そいつの人間性はさておき、全然知らないってのは業界人としてどうなのよ・・・
- 254 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 13:03:50 ]
- Rubyを使用しています。
OOPの設計でとっても悩んでいます。
例えば、
壁にボールを当てる事を考えます。
壁クラス
ボールクラス
投げる人クラスが
あるとします。
壁にボールが当たって跳ね返ってくるのは
どのクラスで実装しますか？
Mediatorクラスを作るべきですか？
あと、
メソッドのaugumentには
他の独自のクラスをとってよいのでしょうか？
メソッドのaugumentには、
operandはおkで、optionはNO
だというのがHeuristicだそうですが、
という事は、他のクラス
例えばこういう書き方をするか知りませんが
method(MyClass object)
のようなメソッドを実装してもいいのですか？
あまりにも汎用性が失われるような気がします。
- 255 名前：デフォルトの名無しさん mailto:sage [2007/12/30(日) 15:16:33 ]
- >>254
投げるという動詞が存在する以上、ThrowerとThrowableの関係はあっていい。
また、壁、玉、人らは、それぞれに衝突可能なObject（俗に言うMob）とする。
よって、おいらなら以下を土台とする。
GameField field = GameField.getInstance(); // ゲームマスター
field.add(new ConcreteWall(0,0,0,768);
field.add(new ConcreteWall(0,0,1024,0);
field.add(new ConcreteWall(1024,0,1024,768));
Thrower thrower = new ConcreteThrower();
thrower.set(new ConcreteBall());
field.startGame(thrower); // ゲームループの開始
また、以下の依存性も必要と思われる
Throwable extends Mob
Mob.collision(Mob) // ベクトルの変更のみ
この例だとGameFiledが進行を務めるから、Mediatorとは逆。
collisionの網羅前にMobにMediatorを渡すのはあり。
- 256 名前：デフォルトの名無しさん [2008/03/08(土) 19:27:46 ]
- 質問です。
設計者は開発者に対してpublicなAPIだけを
仕様として渡して、
開発者はそれをprivateなメソッドに
分解して最終的にpublicなメソッドのテストに通ればいいという事ですか？
- 257 名前：デフォルトの名無しさん [2008/03/16(日) 23:55:02 ]
- データ形式が以下のようなブロック集合の組み合わせの場合
DATA( A or B or C or D)
このようなデータを汎用的に書き出したいのですが
どのように設計すればいいでしょうか。
[A,B,D]の場合もあるし[C,D]の場合もあるし
かといってちまちまケース文で書き出すのは愚の骨頂だし
解らない。
- 258 名前：デフォルトの名無しさん mailto:sage [2008/03/17(月) 02:08:14 ]
- というよりどういう用途・用法で扱われるのかわからないので想像しづらいんだが．
単純にビットフィールドってことでおｋ？
- 259 名前：デフォルトの名無しさん [2008/03/17(月) 10:01:59 ]
- >>257
A 〜 D を自由に組み合わせて出力したいという程度ならまず、A 〜 D に
共通な「書き出し可能データ」というインタフェースを定義する。そして
A 〜 D がこれを継承する。
次に「データを書き出す人」という抽象を作り、「書き出し可能データ」の
集合(配列、リストなど)を受け取って、ひたすら書き出すようにする。
「書き出し可能データ」の集合を生成するために、制御役の抽象が必要に
なるかもしれない。
- 260 名前：デフォルトの名無しさん mailto:sage [2008/03/17(月) 17:32:42 ]
- >>256
いいんじゃね？
設計者の設計粒度がどの程度かわからんけど
仕様としては外部からみた振る舞いが正しければいいわけだし
- 261 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 16:07:35 ]
- SRPについて質問です。
「クラスの変更理由を一つにしなさい」
という事は逆にいうと、
「もしクラスが変更される時はそのクラスの仕様をすべて変更しなさい。
もし変更されない仕様が混在するならばそれは変更理由が一つではない」
という意味ですか？
- 262 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 22:18:55 ]
- >>261
違います。変更理由が一つであることとクラス仕様全てを変更することに
相関はありません。
SRP は「クラスは単一の概念を表現すべし」というルールです。単一の
概念を表現するために複数のデータとメソッドが定義されるのだから、
部分的な変更をかけていく行為自体は、何ら SRP に反しません。
例えば、ある抽象概念を表現してみたものの、あとから足りないものに
気付いてメソッドを追加する、というごくありふれたケースを考えてみても、
クラスの既存仕様を壊さずに部分的な変更をかけていることが実感できる
でしょう。
あるクラスが SRP に反しているかどうか判断するには、異なる概念が
混在していないかどうかを常識的にチェックすれば良いのです。もし
混在しているのなら、それは二つのクラスに分離するべきなのです。
ただ、SRP に違反しているクラスが一概に悪とは言えないことも意識して
おくことは大切です。何事も行きすぎた原理主義はよくない。
- 263 名前：デフォルトの名無しさん mailto:sage [2008/03/25(火) 23:21:24 ]
- >>262
あとから足りないものに
気付いてメソッドを追加する、というごくありふれたケース
といいますが、これはOCPが違反しませんか？
今、Head Firstのオブジェクト指向設計とかいう本を読んでいます。
そこにはSRPの例として、車のクラスを定義する場合に
そこにwashなどのメソッドを組み込んではいけないという事になっていますが、
例えば外部で
CarWasher#wash(AutoMobile)を定義した場合、
このCarWasherクラスはAutoMobileの例えばdirtというフィールドが存在している事を知っていないければなりません。
（例えばwashというメソッドがdirtを0にするものだとすると）
これは情報の隠蔽に失敗していませんか？
それに無闇にAutoMobile#setDirtを設定してこれを受け入れれば、
他でどんな悪用をされるか分かりません。
失敗した設計だと思います。
カプセル化についてどう考えていますか？
setterはなるべく実装しない方が良いように思うので、
データについてクラスを分離するのがいいと思うのですが、
この本には振る舞いについて分離せよと書いてあります。
- 264 名前：デフォルトの名無しさん mailto:sage [2008/03/26(水) 01:09:50 ]
- >>263
拡張と一口に言っても、類似概念の追加と、メソッドの追加では意味合いが
違います。OCP を守るためにメソッドの追加ではなく継承で対応するの
では本末転倒でしょう。原則は絶対ではないのだから、柔軟に対応すれば
いいと思いますよ。
その本は読んでいないので状況が良くわかりませんが、車クラスが wash
を提供するべきではない理由が書いてあるのではありませんか? 車の主要な
責務は「人を乗せて移動する」であるとかなんとか。
まあ、いずれにしてもいい例ではない気がしますが、クラスでは概念を
完全に表現することができない以上、どこかに軸足を置く必要がある
わけです。それが「洗う」なのか「走る」なのかは目的によって変わって
くるでしょう。
カプセル化は言うまでもなくとても重要ですね。
大切なのは、自分が表現したいものをはっきりさせることです。そうすれば
自然と必要なデータや振る舞いが備わっていきますよ。
- 265 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 12:54:34 ]
- >>263
CarWasherクラスがAutoMobileクラスのdirtフィールドを知ってなければならない
のは当たり前。
そもそも、洗車機は車の存在を前提に作られるし、皿洗浄器は皿の存在を前提
に作れる。何を？どうする？の２つを知ってないと「する側」は作れない。
てか、洗車は例えとして分かり難いぞｗ
- 266 名前：デフォルトの名無しさん mailto:sage [2008/05/14(水) 15:08:00 ]
- そもそも「汚れ具合」が定義されていなければ「洗う」ことも「汚れる」ことも定義できない．
- 267 名前：デフォルトの名無しさん [2008/05/22(木) 06:02:42 ]
- OOPに最近参入した新参者です。
設計（特にクラスの設計）に関するオススメの書籍何かないでしょうか？
例えばショッピングサイト、レンタルビデオショップなどわかりやすそうなものから考えていこうとしたものの
OOPへの理解が浅いせいかどうにも戸惑ってしまっています
よろしくお願いします
- 268 名前：デフォルトの名無しさん mailto:sage [2008/05/22(木) 12:13:26 ]
- >>267
デザインパターンとともに学ぶオブジェクト指向のこころ
- 269 名前：デフォルトの名無しさん mailto:sage [2008/05/25(日) 20:58:00 ]
- MVC分割したときにUndoのロジックってModelの実装領域になると思うんですが、
大抵このUndoってコマンドパターンとかで実装されますよね？
このとき、Modelに対する変更命令が全てコマンドで実行されることをコードレベルで保障するには、
Modelに対する変更命令を受け取ってコマンドを発行するクラスを作って、
更にModel内部のデータ構造に対するアクセスを制限するための
読み取り専用ラッパークラスを作って外に公開する、という感じになるのでしょうか？
実際このようなことって業務レベルの開発では行っていたりしますか？
- 270 名前：デフォルトの名無しさん mailto:sage [2008/05/26(月) 00:23:07 ]
- >>267
個人的に、リファクタリングの実践が一番身に付きやすいと思う。
フリーソフトとかのソース落としてきてやりまくるといい。
ということで
・リファクタリング
- 271 名前：デフォルトの名無しさん mailto:sage [2008/06/19(木) 22:55:43 ]
- 実験で使用するシリアルポートから遠隔操作できる
温度調節機能付きの水質モニターを管理するプログラムを作りたいと思っています
1分毎に水質データと水温を取得する
PCから温度の管理値を変更できる
という機能を実現したいのですがこの場合
ポートの開閉やデータの送受信を管理するCommクラス
水質データの受信要求や管理値の変更命令をCommｵﾌﾞｼﾞｪｸﾄに送る、水質モニターの機能を実現するMonitorクラス
Monitorｵﾌﾞｼﾞｪｸﾄから値を受け取り実際に表示するGUIクラス
GUIがMonitorの参照を保持して
MonitorがCommの参照を保持する
このような構造でよいのでしょうか？
- 272 名前：271 mailto:sage [2008/06/20(金) 00:31:37 ]
- それとも
Monitorクラスの定期測定と管理値の変更は別のクラスの振る舞いにしたほうが良いのでしょうか
- 273 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 20:41:49 ]
- >>271
いいと思います。あとは、水質モニターのマルチベンダー化や多重化等が
確実なら、事前に拡張性を考慮するのもあり。
- 274 名前：デフォルトの名無しさん mailto:sage [2008/06/20(金) 22:07:46 ]
- >>273
ありがとうございます
あと、新型のモニターを使用する場合も考えると
拡張機能を実装しやすいようにデコレータにしておいた方がいいですかね
- 275 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 00:04:07 ]
- >>274
数ヶ月以内に新型が導入されるならね。さもなくば、シンプルに徹する。
- 276 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 00:47:55 ]
- 肝心なこと聞き忘れてました
二つの値を一つの文字列に合成してシリアル通信するのですが
この命令の合成と返答の翻訳はMonitorとCommクラスどちらに実装するべきでしょうか
質問続きで申し訳ありません
- 277 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 06:02:48 ]
- >>276
"二つの値Constructor"に任せればいいんじゃない？
もしくはMul/Demultiplexerとか？
- 278 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 10:29:05 ]
- >>276
Comm クラスは汎用的なシリアル通信だけを行うユーティリティクラスで
いいんじゃないかな。制御プロトコルの知識は Monitor に持たせる。
- 279 名前：デフォルトの名無しさん mailto:sage [2008/06/21(土) 12:11:06 ]
- >>276
おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
- 280 名前：デフォルトの名無しさん mailto:sage [2008/08/05(火) 22:06:37 ]
- >>279
>おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
メッセージI/FとパーサーI/F又はどれか一つ用意して
メッセージの詳細はベンダー毎に実装するのが一般的かと思う。
- 281 名前：デフォルトの名無しさん [2008/08/08(金) 03:31:53 ]
- >>271
ちょっとOO分析っぽいことやってみたかった．
# [実験]で[使用する][シリアルポート]から[遠隔操作できる]
# [温度][調節][機能]付きの[水質モニター]を[管理する]
# [1分毎]に[水質データ]と[水温]を[取得する]
# [PC]から[温度]の[管理値]を[変更できる]
必要な名詞(オブジェクト)
シリアルポート，温度，水質モニター，1分毎，水質データ，水温，温度，管理値
足りない名詞
タイマー
必要な動詞(メソッド)
操作，調節，管理，取得，変更
ここまでやったけど別に何を作ろうというわけではない
- 282 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 12:13:24 ]
- 温度がオブジェクトかよー
1分毎もかよー
水温・温度もかよー。
- 283 名前：デフォルトの名無しさん mailto:sage [2008/08/10(日) 13:31:40 ]
- 当たり前すぎますよねー＾＾
- 284 名前：デフォルトの名無しさん [2008/08/20(水) 20:05:43 ]
- クラスの設計に関して悩み中です。
例えば以下のような必要とされる要素が有ったとします。
(要素内容はでたらめです。)
・コード/名称/メッセージ/結果/色/高さ/幅
/追加日/更新日/削除日/…(全部で20要素ぐらい)
処理1 … コード/名称/メッセージ/結果
処理2 … コード/結果/色/高さ/幅
処理3 … 結果/色/更新日
処理4 … 削除日
各処理は、クラスに個別分類できる処理になり、各処理に少しずつ上記要素が
絡んでくる状態になります。
このような場合、どのようなクラス設計が適していますか？
現在は、コード/名称〜などの20要素ぐらいをBaseクラスにして、
処理1〜4までを継承させています。
ただ、こうすると必要の無い要素まで入ってしまい、もっとすっきり
させたいなと思っています。
- 285 名前：デフォルトの名無しさん mailto:sage [2008/08/21(木) 02:24:17 ]
- >>284
> ただ、こうすると必要の無い要素まで入ってしまい
この時点で継承を選ぶのがおかしい。意味のある単位に切り分けよう。
問題の切り分けじゃなくて、登場人物の切り分けを意識した方がいい。
例えば色／高さ／幅ってGUI上の属性情報なんじゃないの？
処理1と処理4でそれらの情報を使用しないってのなら、
ぱっと聞いただけでも処理１〜４は継承関係上の兄弟とは思えない。
> このような場合、どのようなクラス設計が適していますか？
適切な切り分けの単位は要件仕様やその他の背景によって異なるよ。
とっかかりがないなら、それらのデータモデルを構造体化して、
処理の引数に渡してしまえばいい。
|
 |
