- 1 名前：デフォルトの名無しさん [2005/09/24(土) 16:35:59 ]
- 全部publicでいいじゃん！ってならないようにするスレです。
- 110 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:17:48 ]
- >>107
？
派生からアクセスが必要になる度にアクセッサを追加してるんじゃないの？
そもそも日本語もだめだったり？
- 111 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:25:09 ]
- 俺も勉強したてでよく分からんけど、
メンバ変数全部に対してprotectedのアクセサ用意って
これはカプセル化の意味ないと思うんだが…
多分そのスーパークラスの設計から見直したほうがいいんじゃ
- 112 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:32:59 ]
- 継承前提で作るときはこういう悩みはないんですが、
工数削減の関係で仕方なく、継承させるつもりがまったくなかったクラスに
スーパークラスとして、アクセサを追加してました。
まったく継承させるつもりがなくても、あとあとのことを考えて
protectedアクセサを…ってダメダメですよね。
設計が悪かったのが理解できました。みなさんありがとう
- 113 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 00:00:27 ]
- コンストラクタはオーバーロードできないっぽくて悲しい
デフォコンだけでしょ
- 114 名前：デフォルトの名無しさん mailto:sage [2005/12/24(土) 00:30:10 ]
- >>113
？
- 115 名前：デフォルトの名無しさん [2005/12/31(土) 04:53:35 ]
- >>113
∧_∧ ／￣￣￣￣￣
(ω・ )ゝ ＜ なんだって？
ノ/ / ＼＿＿＿＿＿
ノ￣ゝ
- 116 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 10:26:20 ]
- コンストラクタでHoge(String str)とかは継承されないという話
オーバーロードとは違う
- 117 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:39:08 ]
- StrutsのActionみたいなリクエストを処理するクラスで、思想の問題と思われるが
Aという共通抽象クラスがあって、業務Bと業務Cがあり、BとCは機能がほとんど同じ
この場合、どっちがよい？
1)A<Bと継承して、更にB<Cと継承して違うところだけは追加・オーバーライドする
2)A<B, A<Cと別々に継承する
1だと違う部分だけ書けばそれだけでいいけど、もしBの共通部分が変更になるとCにも影響する恐れがある
2だとBの共通部分が変更になってもCには影響しないが、多少かぶってしまう箇所が出てくる
個人的には2かなと思ってるけど、今の現場では1が多い
2は共通化できそうな部分だけは別クラスに作るってので対処できるし
- 118 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 13:54:44 ]
- 俺も2かな。ただしやるならDecoratorパターン。
早い話がラッピングするパターン。
www.techscore.com/tech/DesignPattern/Decorator.html
- 119 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 18:49:30 ]
- >>117
もし俺なら、(共通部分の内容と量にもよるが)もう１層括りだせないか？
と、考えてみる。
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
- 120 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 19:11:48 ]
- 感じとして会社によってはドメインフレームワークって言ってるやつかな？
- 121 名前：117 mailto:sage [2005/12/31(土) 20:13:31 ]
- ﾚｽｻﾝｸｽ
>>118
Decoratorﾊﾟﾀｰﾝでやったことないから今度実験してみよう
>>119
2の拡張みたいな感じかな
それも検討してみたことがあるけど、サブシステム全体で共通ならいいような気がするけど
サブシステム内のある２機能だけ特別にクラスを作るってのはどうか悩んだ
- 122 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:41:21 ]
- そこまで差が少なければ俺は119のAImplをクラステンプレートにして、
BとCの差異をTraitsクラスにして選択できるようにするだろう。
119のように継承するのと大して差異はないけど。
- 123 名前：デフォルトの名無しさん mailto:sage [2005/12/31(土) 22:54:14 ]
- >>122
C++な人？
- 124 名前：122 mailto:sage [2006/01/01(日) 13:02:39 ]
- >>123
そうだよ。
ついC++スレにいるつもりでだった。
117がC++を使っていなければすまん、使えないな。
- 125 名前：デフォルトの名無しさん mailto:sage [2006/01/03(火) 13:35:23 ]
- 設計相談って難しいよね
冗談半分でSmalltalkならこうするよ
といったら怒られたｗ
Javaでやろうとするとひどく煩雑になるんだもん・・・
- 126 名前：デフォルトの名無しさん mailto:sage [2006/01/05(木) 08:46:21 ]
- 設計という分野は言語より上位だと思ったりもするんだが、
実装する言語によって良い設計が変わってしまうしね。
- 127 名前：デフォルトの名無しさん mailto:sage [2006/01/06(金) 00:19:47 ]
- >>126
言語で左右されるような実装レベルまで設計するなよ
- 128 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 00:38:38 ]
- そうなのかなぁ
どんなにすばらしい設計をしたとしても、
それを実現する手段がなければ
意味のない物になってしまうと思うんだけど
- 129 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 01:23:02 ]
- C++でtemplateで静的に解決できるものが
Javaでやるならクラスで動的解決になるし。
しかも静的動的って言葉すらも言語によって意味違うし。
>>127の思想だと最大公約数的な設計になりそう。
まぁ別にそれでも問題無いことも多い気もするけど。
- 130 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 11:47:08 ]
- 設計は二段階で
- 131 名前：デフォルトの名無しさん mailto:sage [2006/01/07(土) 22:39:23 ]
- 基本設計
詳細設計
- 132 名前：デフォルトの名無しさん [2006/02/12(日) 12:27:56 ]
- デザインパターンっていつ使うの？
- 133 名前：デフォルトの名無しさん mailto:sage [2006/02/12(日) 15:23:02 ]
- パターン化したいとき
- 134 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 03:39:02 ]
- 使えるとき（ﾏｼﾞﾚｽ）
- 135 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 07:22:23 ]
- 私もRubyが何故ifをTrueClass/FalseClassのメソッドに
しなかったかなぁ、と思った事はあるね。
Perlとかを意識して妙な仕様にしたんだと思うが。
- 136 名前：デフォルトの名無しさん mailto:sage [2006/05/18(木) 07:24:29 ]
- ぐは、誤爆
- 137 名前：デフォルトの名無しさん [2006/07/01(土) 21:50:01 ]
- publicばっかのクラスというけれど
7割がたそうなってしまうのが人の世だと思う
- 138 名前：デフォルトの名無しさん mailto:sage [2006/07/01(土) 22:01:48 ]
- public といっても、属性と操作がある。
属性は全て private 、
操作はデフォルトで public 必要に応じて private ってのが
実装レベルでは当然と思う。
ぶっちゃけ、7割りがた属性が public なクラスなんてありえない。
- 139 名前：デフォルトの名無しさん [2006/07/01(土) 22:31:20 ]
- そら属性は7割がたprivate、残りprotectedだろうね。
- 140 名前：デフォルトの名無しさん [2006/07/04(火) 00:15:15 ]
- フィールドは本来10割がprivateだろう。
派生クラスで使用したい場合も、protectedなプロパティとして用意するべき。
- 141 名前：デフォルトの名無しさん mailto:sage [2006/07/04(火) 23:20:03 ]
- protected も無印（package） も意外と使わないんだよね。
なんか使うとしても、デバッグとかテストケース動かすためとか、
裏技的な目的が多いような・・・。
- 142 名前：デフォルトの名無しさん mailto:sage [2006/07/17(月) 03:10:02 ]
- 私はpackageは使いまくってるよ
これがないと(ていうかC++のことだが)
ユーザー公開用のファサードを用意しなきゃならなくてだるすぎる
- 143 名前：デフォルトの名無しさん mailto:sage [2006/07/22(土) 00:37:29 ]
- 俺もパッケージプライベートは良く使う
無名インナークラスでもない限りは、インナークラスは外に出すのでね
- 144 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:36:10 ]
- 今日、とあるプロジェクトに加わることになって、
そのプロジェクトで利用されてるライブラリ(プロジェクトメンバーが開発)
を見たんだけど、やたらと〜Managerみたいなクラスばっかりだった。
これって、どうなのかなぁ？
例えば、ファイル入出力を司るクラスが抽象クラスで用意されてて、
そいつを必ず継承して使ってねっていう感じだった。
他の各機能も同じ。
んで、プロジェクトファイル名も〜Managerみたいなのばっかり。
(マスタデータを登録するやつだったらDataManagerとか・・)
うまく説明できないんだけど、何か違和感を感じました。
こういうのってOOPで主流(?)なんでしょうか？
ちなみに言語は.NETのC#です。
- 145 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:55:10 ]
- >>144
www.radiumsoftware.com/0603.html#060330
- 146 名前：デフォルトの名無しさん mailto:sage [2006/07/24(月) 23:57:43 ]
- >144
抽象クラスを継承して使うことが、Managerが多いことの例え、
って部分が理解出来ない。
- 147 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:03:42 ]
- >>145
参考になりました・・・・・
明日から、どうしよ。
なんか、このライブラリを使用することを半強制されてるんだけど・・・・
(；´Д`)
- 148 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:23:51 ]
- 使いにくいだけのショボブラリを仕事で使わされると虐待かと思う
- 149 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:25:50 ]
- >>146
説明が悪くて申し訳ないす。
何というか汎用的な各機能毎にManagerがいて、
汎用的な処理を実装する機能をもつクラスが必要になる
場合はそのManagerを継承して、新たなManagerを作ってねという感じなんですよ。
んで、ファイルを読んだり、書いたりする機能がある場合だったら
必ずFileManagerとやらを継承してHogeFileManagerや、
FugaFileManagerみたいなクラスを作ろうという風になってます。
Managerと言う割には、ファイルの読み/書きの機能の為だけに
わざわざ継承するのはどうなのかなぁと。
FileManagerにHogeFileManagerやFugaFileManagerのインスタンスを
渡して処理するような事も無いみたいだし・・・
うまく説明できないけどこんな状態です・・・。
- 150 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 00:52:47 ]
- >>149
"Manager"という名前がアレだけど、それって単に物理的な何かを
抽象化してるだけでしょ。
良くある話。
- 151 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 01:07:55 ]
-
〜erみたいなクラスは確かによく見るんですが、
余りにも〜Managerがたくさんいたんで
おかしいなと、自分が考えすぎてただけなのかもしれないすね。
明日あたり、作成者の人にどういう意図で作ったのか
聞いてみます。
お騒がせしました。
- 152 名前：デフォルトの名無しさん mailto:sage [2006/07/25(火) 01:22:49 ]
- やめとけ、意図と聞くと切れる。
聞いただけで否定されてる？って切れる。
- 153 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 01:10:59 ]
- ↑こういうプロになりたくないと思ったbyｱﾏﾁｭｱ
- 154 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 01:46:47 ]
- 糸は切れやすい。たしかに。
- 155 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 02:10:29 ]
- 自分の設計が最強と思ってる人間が、
同じプロジェクトに居たりすると困るよなぁ。
やたらと、自作ライブラリを使わせようとしたり、
頼んでも無いのに勝手にこれ使ってくださいとか言ってきたりする奴。
身の回りに一人居るが、
今、新人を洗脳してるw
型って何？、レベルの人間に
懇々と我流オブジェクト指向について熱く薀蓄を語っては、
新人のやる気を萎えさせてる。
おかげで、久しぶりに開発人数が増えそうなのに、
辞めてってしまいそうだ。
- 156 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:20:14 ]
- オブジェクト指向もデザパタも判らない奴>>155
- 157 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:27:46 ]
- >>155
困るなら論破すればいいのに
- 158 名前：デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:03:49 ]
- >>155
俺の事言われてるのかと思ったw
まぁ、数千行の関数とかコピペで作る奴よりマシだと思ってるけど。
俺は自作ライブラリ作るときは、シンプル＆単機能な設計でUnitTestとセットで提供しているから問題ないよな。
- 159 名前：デフォルトの名無しさん mailto:sage [2006/07/30(日) 10:10:14 ]
- 田舎ライブラリ使わされるのは苦痛なだけ
そのまま作らせろ
- 160 名前：デフォルトの名無しさん mailto:sage [2006/07/31(月) 00:34:18 ]
- 155の新人は、優秀なメンテナンス要員に成長しましたとさ。
めでたしめでたし
- 161 名前：デフォルトの名無しさん [2006/08/01(火) 22:01:01 ]
- デザインパターンってどのくらい覚えるのがいいんだろうか
GoF以外のJ2EEとかマルチスレッドとか視点を絞ったパターンまでは手が出ない
- 162 名前：デフォルトの名無しさん mailto:sage [2006/08/01(火) 22:39:28 ]
- >>161
必要な時に調べて使え。覚える必要は無い
- 163 名前：デフォルトの名無しさん [2006/08/08(火) 12:54:24 ]
- >>119の
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
のAImpl＜共通実装部分って部分ってテンプレートパターン？
どうも何パターンとかって分類するのが苦手なのよ
- 164 名前：デフォルトの名無しさん [2006/08/08(火) 13:12:16 ]
- デザパタとか本当に使ってるの？使っていてもまわり
の人が理解できてる？
Ｃ＋＋やデザパタをつかってプログラムしてもまわりが
理解できず、バグ混入の原因になっているのでは？
オタクなクラス設計やデザパタ使ってるあなたが
結果的にプロジェクトを破壊するテロリストになって
しまっているんじゃないの？
で、実際にトラブルが起きると｢こんなことも理解して
ないなんて一人前のプログラマじゃない！｣とか言って
自分の知識をひけらかしたり、失敗を人のせいにするん
だろ。ラーメン屋の亭主みたいな融通のきかない職人
じゃあるまいし。こういう職人肌みたいな人はＣ＋＋の
テンプレートと共に消えてくれ。頼むから。
｣
- 165 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 13:16:31 ]
- >>164
と、IQ80の君に言われても・・・。
- 166 名前：デフォルトの名無しさん [2006/08/08(火) 13:30:14 ]
- このスレに書かれている愚痴って、
もう2002年当時からずっと一緒。
プログラムのﾌﾟウの字も知らない煽り屋が必死に煽ってるだけなんだろ。
無意味
- 167 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 13:32:20 ]
- 10年経ってもNewbieは必ず誕生するからね。
彼らから議論の場を取り上げるのは、酷というものであろう。
- 168 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 16:13:43 ]
- 2002年なら新しい方だな
C++は1998年の仕様がまだ実装されてないんだから
- 169 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 19:43:50 ]
- 業務でManagerと名の付くクラスは大抵ろくでもないクラスだよな。
DBConnection関係のクラスをキモくラップしただけの奴とか。
これを共通で使ってくださいとか指示されると萎えるｗ
- 170 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 19:49:04 ]
- >>169
脳内業務乙。
- 171 名前：デフォルトの名無しさん [2006/08/08(火) 23:20:46 ]
- みんなクラス抽出ってどうやってんの？
ユースケースから名詞を全部抜き出して一つ一つ吟味したり、
boundary,control,entityって分類分けしたりする？
仕様書が完璧に出来てるならやってもいいけど、
仕様書が完全になるの待ってたらいつまでたっても仕事に取り掛かれないし、
仕様変更のたびにそんなんやってらんないよね。
- 172 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 10:15:03 ]
- 別会社から引き継いだソースを設計チームでレビューしてたときの話。
ソースの中に簡単なFactoryパターンが含まれていたんだが、
一人だけFactoryが分からないやつがいた（年齢だけでいえば中堅）。
まあパターンを知らないってのは別によい、知らなくてもコードを
読めば何やってるか分かるはずだからな。
と、みんな思ってたんだが、いくら説明しても伝わらない。
細かく聞いていったらどうやら継承とインスタンス化の違いが分かっていなかった
ということが判明。
そんな人を設計から外す方法を相談させてください。
- 173 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 11:02:33 ]
- 継承とインスタンス化の違いを説明できないのもﾔﾊﾞｲと思う
- 174 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 12:55:40 ]
- 分かってないポイントが遥か手前だと、そこから全て教育するのがマンドクサい
- 175 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 13:16:12 ]
- >>172
スレ違い
- 176 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 13:46:24 ]
- 職場の愚痴か、せいぜい教育方法の話だしな。
無理に設計に絡ませると、「馬鹿でも分かる、かつOOを生かす方法とは？」になるか。
最近流行のDIが近い回答か？
- 177 名前：デフォルトの名無しさん mailto:sage [2006/08/19(土) 10:58:06 ]
- 本人、解ってない事は判ってるんだろうか？
- 178 名前：デフォルトの名無しさん mailto:sage [2006/08/19(土) 12:07:22 ]
- >>175
というか、板違い。どう考えてもマ板の話題。
>>172
オブジェクト指向が理解できないPG
pc8.2ch.net/test/read.cgi/prog/1103581270/
- 179 名前：デフォルトの名無しさん [2006/10/05(木) 13:05:29 ]
- ( ﾟдﾟ )
- 180 名前：デフォルトの名無しさん [2006/10/06(金) 22:17:05 ]
- Javaなんだが、フレームワークが乱立してる昨今。
フレームワークそのものはOOしないで高速にして欲しいと思う。
Hibernateとかは内部はMapで公開するときだけBeanらしいし
何は無くともちょっぱやってのをコンセプトにしたフレームワークが欲しい。
- 181 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 04:02:33 ]
- ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ )
- 182 名前：デフォルトの名無しさん mailto:sage [2006/10/10(火) 09:52:51 ]
- >OOしないで高速に
な、なんだってー(AA略
- 183 名前：デフォルトの名無しさん [2006/10/10(火) 19:12:27 ]
- package privateとかfriendとか使えば
公開部だけをOOにしたnew最小限ロジックが描けるけど
世間ではこういうのってタブーなのかね
- 184 名前：デフォルトの名無しさん mailto:sage [2006/10/11(水) 08:19:28 ]
- ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ )
- 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にもよると思うが、そんなに変わらないと思うけどね
|
 |
