05/09/24 16:35:59
全部publicでいいじゃん！ってならないようにするスレです。
2:デフォルトの名無しさん
05/09/24 16:40:14
2
3:デフォルトの名無しさん
05/09/24 16:42:25
∧_∧ ／￣￣￣￣￣
(ω・ )ゝ ＜ なんだって？
ノ/ / ＼＿＿＿＿＿
ノ￣ゝ
4:デフォルトの名無しさん
05/09/24 16:42:29
全部public と OOP限定 の関連がわかりません
5:デフォルトの名無しさん
05/09/24 16:48:11
双方向関連です
6:デフォルトの名無しさん
05/09/24 16:49:03
∧_∧ ／￣￣￣￣￣
(ω・ )ゝ ＜ なんだって？
ノ/ / ＼＿＿＿＿＿
ノ￣ゝ
7:デフォルトの名無しさん
05/09/24 16:51:04
>>4
Java屋やC屋が入り混じると煽りが入りえるので住み分けしました。
OOP限定はスレの利便性のためとお考えください。
8:デフォルトの名無しさん
05/09/24 16:51:41
オープンソース全盛の今設計手法で商売する時代になったので、
無料では教えてあげません
9:デフォルトの名無しさん
05/09/24 16:53:12
へー、javaってOOPLじゃなかったんだ
10:デフォルトの名無しさん
05/09/24 16:54:33
新しいSmalltalkスレはここですか？
11:デフォルトの名無しさん
05/09/24 16:59:33
>>9
Java(OOP)とC(構造化)の煽りあいという意味です。
12:デフォルトの名無しさん
05/09/24 17:02:54
MVCを意識してライブラリを設計しているのですが
とあるメインループを持つController部を切り替えても
Model, Viewは同じものを使う手法を考えています。
この場合メインControllerを切り替える為のControllerを
それらの最上位に実装するのは正しい設計でしょうか？
ControllerController
├Model
├View
└Controller
この図の場合だとControllerがControllerControllerに
自身をあのControllerに切り替えてと頼む形になります。
ControllerControllerは切り替え処理以外の機能は持ちません。
13:デフォルトの名無しさん
05/09/24 17:04:26
デザパタ勉強してください
14:デフォルトの名無しさん
05/09/24 17:06:21
>>13
どのパターンですか？
15:デフォルトの名無しさん
05/09/24 17:19:15
全部publicではないが、数千行あるクラスでprivateなメソッドが1個だけで、
他は全部publicなメソッドってのがあった。
16:デフォルトの名無しさん
05/09/24 17:32:51
CLOS最強!!
17:デフォルトの名無しさん
05/09/24 17:53:32
>>15
コボラーの仕業だな。
最近、似たようなモンみたよ。
18:デフォルトの名無しさん
05/09/24 18:53:42
>>13
はやくはやく
19:デフォルトの名無しさん
05/09/25 02:43:03
>>14
youzyoパターン
20:マイク ◆yrBrqfF1Ew
05/09/25 03:53:27
MVCウザイな。
使いやすくない。
21:デフォルトの名無しさん
05/09/25 12:58:57
MVCはCが如何に無理をするかが焦点だな
22:デフォルトの名無しさん
05/10/02 00:11:03
youzyoパターンってなんぞ？
委譲じゃないよな？
23:デフォルトの名無しさん
05/10/02 01:11:15
＝＝＝＝＝
基地外スレ
＝＝＝＝＝
24:デフォルトの名無しさん
05/10/02 21:44:30
gofのすとらてじい？
25:デフォルトの名無しさん
05/10/21 18:16:26
Mのクラスが、VやCのクラスを引数にとったり、内包したら設計ミスかな？
というか>>21が何気に至言だ
って、なんだ最後の発言が3週間くらい前か
26:デフォルトの名無しさん
05/10/23 21:34:16
Mって早い話が構造体クラスでしょ？
SQLにマッピングするためのゲッタくらいが限界じゃないかな
27:デフォルトの名無しさん
05/10/23 23:20:23
それはＣクラスでやりたいな・・・
28:デフォルトの名無しさん
05/11/04 15:47:55
デザパタは１０回同じのを使うとわかった気になるなあ、おい。
29:デフォルトの名無しさん
05/11/05 00:29:38
デザパタはOOPをプロでやってく上での教養なのかねぇ
実際仕事で汲んでも使う機会無い気がする。
せーぜーシングルトンがあぶ工場くらい。
30:デフォルトの名無しさん
05/11/06 01:10:50
OOPのアルゴリズムテンプレートがあって
それをDBから引っこ抜いてくるように出来たら面白いのにな
プログラムとはそれすなわちアルゴリズムって証明できる
31:デフォルトの名無しさん
05/11/06 01:12:44
アルゴリズムテンプレートってなに？
32:デフォルトの名無しさん
05/11/06 01:14:59
機能じゃないよ。言葉そのままの意味。
ソートとかコレクションとかOOPならどれでも共通化できそうなものを纏めて欲しい。
33:デフォルトの名無しさん
05/11/06 01:15:49
>>32
それとOOPが、どう関係するの？
34:デフォルトの名無しさん
05/11/06 02:27:39
>>29
漏れはComposite使いまくりんぐ
35:デフォルトの名無しさん
05/11/06 18:33:29
だいたいだなぁ、OOP限定なら「プログラム設計」じゃなくっ「てクラス設計」ではないのか？
36:デフォルトの名無しさん
05/11/06 18:54:42
てクラス設計
37:デフォルトの名無しさん
05/12/02 21:54:29
AOPって何ですか？
38:デフォルトの名無しさん
05/12/02 22:16:43
エージェント？
39:デフォルトの名無しさん
05/12/03 00:56:10
スミス？
40:デフォルトの名無しさん
05/12/03 01:05:30
>>37
アルベルト・プロモーテッド・プラゲラメ
41:デフォルトの名無しさん
05/12/03 01:10:27
Oがないじゃん
42:デフォルトの名無しさん
05/12/03 01:19:54
23のパターンを用いてHelloWorldを実装してください。
43:デフォルトの名無しさん
05/12/03 21:15:04
public interface MessageStrategy { public void sendMessage(); }
public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}
public class MessageBody {
Object payload;
public Object getPayload() { return payload; }
public void configure(Object obj) { payload = obj; }
public void send(MessageStrategy ms) { ms.sendMessage(); }
}
public class DefaultFactory extends AbstractStrategyFactory {
private DefaultFactory() {;}
static DefaultFactory instance = new DefaultFactory();
public static AbstractStrategyFactory getInstance() { return instance; }
public MessageStrategy createStrategy(final MessageBody mb) {
return new MessageStrategy() {
MessageBody body = mb;
public void sendMessage() { Object obj = body.getPayload(); System.out.println((String)obj); }
};
}
}
public class HelloWorld {
public static void main(String[] args) {
MessageBody mb = new MessageBody();
mb.configure("Hello World!");
AbstractStrategyFactory asf = DefaultFactory.getInstance();
MessageStrategy strategy = asf.createStrategy(mb);
mb.send(strategy);
}
}
44:デフォルトの名無しさん
05/12/03 22:02:47
>>43
./のパクリはいりません
45:デフォルトの名無しさん
05/12/03 22:07:59
GoF以外のデザパタ集で有名どころってある？
46:デフォルトの名無しさん
05/12/03 22:36:16
マルチスレッドのデザインパターンやら、
GRASPやJ2EEパターンが有名どころか？
47:デフォルトの名無しさん
05/12/03 23:31:49
C++でか書かれてるデザパタ参考本ってないよね
48:デフォルトの名無しさん
05/12/03 23:36:28
>>47
ｴｰ!!!
本家本はC++のはずだが。
49:デフォルトの名無しさん
05/12/03 23:38:49
smelltalkもはいってんじゃん。＞本家
50:デフォルトの名無しさん
05/12/03 23:42:47
>>49
はいってちゃまずいのか？
51:デフォルトの名無しさん
05/12/03 23:43:57
smalltalkは本家じゃん。本家が本家を扱って何が悪い。
52:デフォルトの名無しさん
05/12/03 23:54:19
本家本は確かにSmalltalkとC++だな。
でもC++が多いから>>48みたいな反応でもあながち間違えではないと思う。
そんなわけで、Smalltalkに特化したThe Design Patterns Smalltalk Companionがわけだし。
53:デフォルトの名無しさん
05/12/03 23:55:10
smelltalk
54:デフォルトの名無しさん
05/12/03 23:55:21
なんだかﾜｹﾜｶﾒ
本家本=GoFデザパタ本だよね？
55:デフォルトの名無しさん
05/12/03 23:58:30
smalltalkの特徴って何？
何でもオブジェクトって言う思想はRubyと同じ思想？
56:デフォルトの名無しさん
05/12/04 00:19:08
>>53
ﾜﾛｽ
確かに臭うね
>>55
何でもオブジェクトって考えは近いとは思うよ。
ただ、Smalltalkは徹底的に何でもオブジェクト。
いわゆる制御文（if、whileやforのようなもの)も
各種オブジェクトのメッセージとして定義されてる。
Rubyもそうなのかな？（じぶんはRubyってそれほどしらない）
57:デフォルトの名無しさん
05/12/04 00:28:54
「Smalltalkの思想がRubyの思想と同じ」
っていうのは順序がおかしいと思う
58:デフォルトの名無しさん
05/12/04 00:31:54
すべてのOOはSmalltalkよりはじまるか。
59:デフォルトの名無しさん
05/12/04 00:34:34
>>56
> いわゆる制御文（if、whileやforのようなもの)も
> 各種オブジェクトのメッセージとして定義されてる。
Rubyもそうだよ
URLﾘﾝｸ(ruby.mirror.easynet.be)
RubyはSmalltalkとPerlのハーフってことかな？
60:デフォルトの名無しさん
05/12/04 01:46:02
>>59
違う。Rubyは制御文はメッセージ送信ではない。
ifやwhileなどの制御文はCやPerlと同じモデル。
そのページは間違い。ifメッセージをなんのオブジェクトに送信しとるっちゅーねん。
61:デフォルトの名無しさん
05/12/04 02:25:19
Rubyの制御構造の一部は式ってのを勘違いしている？
62:デフォルトの名無しさん
05/12/04 02:27:01
だとしたら
4. 制御構造までオブジェクト
私はこれで乗り換えました。(ついに！)
ってのはかなり痛いんだけど、Rubyに詳しい人解説お願い。
63:デフォルトの名無しさん
05/12/04 02:29:25
>>61 勘違いしたかも。
>>62 どこらへんが？痛さの解説お願い。
64:デフォルトの名無しさん
05/12/04 02:45:17
1円で海外旅行に行けますと勧誘されて入会金50万円払ってる感じが痛々しい
65:デフォルトの名無しさん
05/12/04 02:47:32
そうか？
void型メソッドをあえて自分への参照を返すようにしているコードって結構好きだし、痛さは感じないが。
66:デフォルトの名無しさん
05/12/04 02:51:47
勘違いして乗り換えしてるのが痛いってだけ
しかも間違えた解説付きときている
言語構造云々について痛いとかは思わない
67:デフォルトの名無しさん
05/12/04 02:53:55
ああ、3項演算子がネストできないと思ってるところかｗ
68:デフォルトの名無しさん
05/12/04 11:18:19
＞4. 制御構造までオブジェクト
これはオブジェクトではなく”式”の勘違いですね。
＞if ～ end.tr("a-z", "A-Z")
この記述が勘違いを助長させた原因でしょう。
ifの結果としてオブジェクトが返却され、.tr～はそのオブジェクトに
対しての操作だということをこの人は誤解しています。
Rubyの構文規則は柔軟に見えますが、こういった誤解を受ける問題があります。
69:デフォルトの名無しさん
05/12/04 11:27:51
イテレータブロックは？
70:デフォルトの名無しさん
05/12/04 11:28:13
だれかそこへメールを送ってみないか？
71:デフォルトの名無しさん
05/12/04 11:36:14
>>69
ありゃあ関数オブジェクトとかクロージャといった類のモノだよ。
起源はLISPのインライン関数とかSmalltalkのブロックだな。
Rubyは動的時にメソッド選択してるからトンデモ構文に見える。
72:デフォルトの名無しさん
05/12/04 11:36:38
s/動的時/動的/
な
73:デフォルトの名無しさん
05/12/04 13:11:05
全てが protected
74:デフォルトの名無しさん
05/12/11 15:08:43
シーケンス図ってホントにプログラム知らないお偉いさんでも読めるの？
75:デフォルトの名無しさん
05/12/11 15:21:18
>>74
プログラムｼﾗﾅｲお偉いさんにシーケンス図見せる時点で間違ってないか？
ユースケースとか配備図とかコラボレーション図とか…
76:デフォルトの名無しさん
05/12/11 15:24:20
UMLの全てがユーザフレンドリーってわけではないのね
77:デフォルトの名無しさん
05/12/11 15:26:46
>>76
えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。
78:デフォルトの名無しさん
05/12/11 15:27:29
じゃあ参考書の書き方がまずかったのかな
79:デフォルトの名無しさん
05/12/11 15:34:43
書くレベル次第だな
厳密な設計書として書いているなら細かすぎて読めないかも
80:デフォルトの名無しさん
05/12/12 00:14:39
日本語だらけの仕様書は曖昧さが目で見て取れるため問題に気づきやすいが
曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
81:デフォルトの名無しさん
05/12/12 20:59:11
いやいや、そんなレベルのUMLは仕様書としないでしょ。
あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ～みたいに。
82:デフォルトの名無しさん
05/12/13 00:53:54
ＵＭＬでは、異常系の記述がやり辛いよな。
・・・はっ！！
83:デフォルトの名無しさん
05/12/17 02:12:04
会計ソフト作ってみたいんだが仕訳モデルのサンプルとか無い？
3級レベルで会計ソフトって作れるのかいな？まあそっちも勉強しながらやってきます
84:デフォルトの名無しさん
05/12/17 13:08:09
自分で分析したら？
85:デフォルトの名無しさん
05/12/17 14:39:32
言ってることはある意味正しいが
そういうレスはこのスレの役を果たさないな
86:デフォルトの名無しさん
05/12/17 15:51:23
javaでアプリ作ったんだけど、関連が全部双方向になったんだけど
これってやっぱ良くないの？
87:デフォルトの名無しさん
05/12/17 15:59:24
> 関連が全部双方向
ここがちょっとわからないが、まぁpublic全開になるのは仕方ないんじゃないかな。
コンポーネント郡はそのまま使わず、派生させてから使えば上手くカプセルにできるかもしれん。
88:デフォルトの名無しさん
05/12/17 16:00:18
まぁ、初心者にありがちなパターンだな。
関連というか、メッセージ送信が双方向になるなら、そのメッセージを一度整理して、分類して、
クラス内のメッセージ受信部分をインタフェースに分離するという観点で構築しなおしたらいいんじゃないの？
89:デフォルトの名無しさん
05/12/17 16:12:25
実はFlashってのはOOPの訓練に役立つ。
90:デフォルトの名無しさん
05/12/17 16:53:09
>>87-88
ｻﾝｸｽｺ
そうです、メッセージ送信が双方向ってことでした。
そういえばインターフェースも抽象クラスも全く使ってない。
というか使いどころもわかんね。
とりあえずそれらの勉強してみます。
ありがとうございました
91:デフォルトの名無しさん
05/12/19 12:54:31
>>15
漏れは何も考えずにとりあえずメソッドはpublicにしてるんだけど…
内部からしか呼ばれないのはprotectedにしてる
まずいのか？
92:デフォルトの名無しさん
05/12/19 16:18:57
>>91
いつの間にかぐちゃぐちゃなソースになるのが弊害かな。
93:デフォルトの名無しさん
05/12/20 00:10:39
アクセス権の指針
public：外から呼ぶ必要がある
protected：外から呼ぶ必要はないが派生クラスから呼ぶ必要がある
private：デフォルト
94:デフォルトの名無しさん
05/12/20 00:17:27
下駄／雪駄なんて書く気しねー。
95:デフォルトの名無しさん
05/12/20 01:25:22
憂鬱本ではメソッドは基本的に全部publicで問題ないって書いてあったが
96:デフォルトの名無しさん
05/12/21 16:07:20
>>95
その本は読んでないが、そこだけ聞いたら焚書モノだな。
97:デフォルトの名無しさん
05/12/22 00:45:27
>>93
その判断を誤るとややこしいことになるからすべてpublicにしておけ
って程度なんだろうね、その本>>95
98:デフォルトの名無しさん
05/12/23 02:03:45
もともとC++やってて、最近仕事でjavaやり始めたんだけど、
javaのprotectedって全然プロテクトじゃないんだね
最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
アクセサメソッド追加してるんだけど、まずいですか？
まともなjava技術者ならどうしてます？
99:デフォルトの名無しさん
05/12/23 09:34:12
>>98
全然プロテクトじゃないってどういうこと？
100:デフォルトの名無しさん
05/12/23 10:50:46
>>98はC++もまともに使えていないと予想する。
101:デフォルトの名無しさん
05/12/23 11:18:14
packageの時の扱いが違うくらいしか思いつかないけど、なんかすごい引っ掛けがあるのかな・・？
102:デフォルトの名無しさん
05/12/23 12:01:36
>>98
早くプロテクトじゃない理由を教えてくれよう。ﾜｸﾜｸ
103:デフォルトの名無しさん
05/12/23 12:20:31
＞最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
＞アクセサメソッド追加してるんだけど、まずいですか？
C++もそうだし、オブジェクト指向もわかってないんじゃないかな
なんか、Cプログラマーみたい
グローバル変数使うなっていわれたから、プライベートにしてみました
みんなが必要とするから悪切磋つけました
そんなところでしょ
104:デフォルトの名無しさん
05/12/23 12:45:22
Lispを使わないなんてバカげてる
105:デフォルトの名無しさん
05/12/23 13:14:14
サブクラスのためにその都度スーパークラスを改変するのはナンセンス
まともなC++技術者ならそんなことやらない
まともなJava技術者もそんなことやらない
まともなSmalltalkerもそんなことやらない
まともなオブジェクト指向言語使用者ならそんなことやらない
106:デフォルトの名無しさん
05/12/23 14:10:15
まともな奴なら継承は使わないってことか
107:98
05/12/23 14:10:15
自分はまともじゃないです（つд`）
プロテクトじゃない云々は、javaのprotectedメンバは派生クラスだけでなく
同じパッケージにいるクラスでもアクセスできるのでC++のより緩いって意味です。
親クラス作るときにはメンバ変数全部に対してprotectedのアクセサ用意しとくものなのかな、と。
で、こういう設計はおかしいですか？
108:デフォルトの名無しさん
05/12/23 14:12:55
親クラスのメンバーにサブクラスがあとあといろいろアクセスしなきゃならなくなるかもぁー。
そういうときにpribvateだと、困るから、protectedにしておいたほうが、いいのかなぁ～。
なんっていう、下らんこと気にしているようでは、そもそもクラス抽出がうまくできているとは思えない。
109:デフォルトの名無しさん
05/12/23 14:15:50
>>106
サブクラスのためにその都度スーパークラスを改変する ってのがナンセンス。
継承前提で設計されたスーパークラスはそんな改変しょっちゅうしない。
110:デフォルトの名無しさん
05/12/23 14:17:48
>>107
？
派生からアクセスが必要になる度にアクセッサを追加してるんじゃないの？
そもそも日本語もだめだったり？
111:デフォルトの名無しさん
05/12/23 14:25:09
俺も勉強したてでよく分からんけど、
メンバ変数全部に対してprotectedのアクセサ用意って
これはカプセル化の意味ないと思うんだが…
多分そのスーパークラスの設計から見直したほうがいいんじゃ
112:デフォルトの名無しさん
05/12/23 14:32:59
継承前提で作るときはこういう悩みはないんですが、
工数削減の関係で仕方なく、継承させるつもりがまったくなかったクラスに
スーパークラスとして、アクセサを追加してました。
まったく継承させるつもりがなくても、あとあとのことを考えて
protectedアクセサを…ってダメダメですよね。
設計が悪かったのが理解できました。みなさんありがとう
113:デフォルトの名無しさん
05/12/24 00:00:27
コンストラクタはオーバーロードできないっぽくて悲しい
デフォコンだけでしょ
114:デフォルトの名無しさん
05/12/24 00:30:10
>>113
？
115:デフォルトの名無しさん
05/12/31 04:53:35
>>113
∧_∧ ／￣￣￣￣￣
(ω・ )ゝ ＜ なんだって？
ノ/ / ＼＿＿＿＿＿
ノ￣ゝ
116:デフォルトの名無しさん
05/12/31 10:26:20
コンストラクタでHoge(String str)とかは継承されないという話
オーバーロードとは違う
117:デフォルトの名無しさん
05/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:デフォルトの名無しさん
05/12/31 13:54:44
俺も2かな。ただしやるならDecoratorパターン。
早い話がラッピングするパターン。
URLﾘﾝｸ(www.techscore.com)
119:デフォルトの名無しさん
05/12/31 18:49:30
>>117
もし俺なら、(共通部分の内容と量にもよるが)もう１層括りだせないか？
と、考えてみる。
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
120:デフォルトの名無しさん
05/12/31 19:11:48
感じとして会社によってはドメインフレームワークって言ってるやつかな？
121:117
05/12/31 20:13:31
ﾚｽｻﾝｸｽ
>>118
Decoratorﾊﾟﾀｰﾝでやったことないから今度実験してみよう
>>119
2の拡張みたいな感じかな
それも検討してみたことがあるけど、サブシステム全体で共通ならいいような気がするけど
サブシステム内のある２機能だけ特別にクラスを作るってのはどうか悩んだ
122:デフォルトの名無しさん
05/12/31 22:41:21
そこまで差が少なければ俺は119のAImplをクラステンプレートにして、
BとCの差異をTraitsクラスにして選択できるようにするだろう。
119のように継承するのと大して差異はないけど。
123:デフォルトの名無しさん
05/12/31 22:54:14
>>122
C++な人？
124:122
06/01/01 13:02:39
>>123
そうだよ。
ついC++スレにいるつもりでだった。
117がC++を使っていなければすまん、使えないな。
125:デフォルトの名無しさん
06/01/03 13:35:23
設計相談って難しいよね
冗談半分でSmalltalkならこうするよ
といったら怒られたｗ
Javaでやろうとするとひどく煩雑になるんだもん・・・
126:デフォルトの名無しさん
06/01/05 08:46:21
設計という分野は言語より上位だと思ったりもするんだが、
実装する言語によって良い設計が変わってしまうしね。
127:デフォルトの名無しさん
06/01/06 00:19:47
>>126
言語で左右されるような実装レベルまで設計するなよ
128:デフォルトの名無しさん
06/01/07 00:38:38
そうなのかなぁ
どんなにすばらしい設計をしたとしても、
それを実現する手段がなければ
意味のない物になってしまうと思うんだけど
129:デフォルトの名無しさん
06/01/07 01:23:02
C++でtemplateで静的に解決できるものが
Javaでやるならクラスで動的解決になるし。
しかも静的動的って言葉すらも言語によって意味違うし。
>>127の思想だと最大公約数的な設計になりそう。
まぁ別にそれでも問題無いことも多い気もするけど。
130:デフォルトの名無しさん
06/01/07 11:47:08
設計は二段階で
131:デフォルトの名無しさん
06/01/07 22:39:23
基本設計
詳細設計
132:デフォルトの名無しさん
06/02/12 12:27:56
デザインパターンっていつ使うの？
133:デフォルトの名無しさん
06/02/12 15:23:02
パターン化したいとき
134:デフォルトの名無しさん
06/02/13 03:39:02
使えるとき（ﾏｼﾞﾚｽ）
135:デフォルトの名無しさん
06/05/18 07:22:23
私もRubyが何故ifをTrueClass/FalseClassのメソッドに
しなかったかなぁ、と思った事はあるね。
Perlとかを意識して妙な仕様にしたんだと思うが。
136:デフォルトの名無しさん
06/05/18 07:24:29
ぐは、誤爆
137:デフォルトの名無しさん
06/07/01 21:50:01
publicばっかのクラスというけれど
7割がたそうなってしまうのが人の世だと思う
138:デフォルトの名無しさん
06/07/01 22:01:48
public といっても、属性と操作がある。
属性は全て private 、
操作はデフォルトで public 必要に応じて private ってのが
実装レベルでは当然と思う。
ぶっちゃけ、7割りがた属性が public なクラスなんてありえない。
139:デフォルトの名無しさん
06/07/01 22:31:20
そら属性は7割がたprivate、残りprotectedだろうね。
140:デフォルトの名無しさん
06/07/04 00:15:15
フィールドは本来10割がprivateだろう。
派生クラスで使用したい場合も、protectedなプロパティとして用意するべき。
141:デフォルトの名無しさん
06/07/04 23:20:03
protected も無印（package） も意外と使わないんだよね。
なんか使うとしても、デバッグとかテストケース動かすためとか、
裏技的な目的が多いような・・・。
142:デフォルトの名無しさん
06/07/17 03:10:02
私はpackageは使いまくってるよ
これがないと(ていうかC++のことだが)
ユーザー公開用のファサードを用意しなきゃならなくてだるすぎる
143:デフォルトの名無しさん
06/07/22 00:37:29
俺もパッケージプライベートは良く使う
無名インナークラスでもない限りは、インナークラスは外に出すのでね
144:デフォルトの名無しさん
06/07/24 23:36:10
今日、とあるプロジェクトに加わることになって、
そのプロジェクトで利用されてるライブラリ(プロジェクトメンバーが開発)
を見たんだけど、やたらと～Managerみたいなクラスばっかりだった。
これって、どうなのかなぁ？
例えば、ファイル入出力を司るクラスが抽象クラスで用意されてて、
そいつを必ず継承して使ってねっていう感じだった。
他の各機能も同じ。
んで、プロジェクトファイル名も～Managerみたいなのばっかり。
(マスタデータを登録するやつだったらDataManagerとか・・)
うまく説明できないんだけど、何か違和感を感じました。
こういうのってOOPで主流(?)なんでしょうか？
ちなみに言語は.NETのC#です。
145:デフォルトの名無しさん
06/07/24 23:55:10
>>144
URLﾘﾝｸ(www.radiumsoftware.com)
146:デフォルトの名無しさん
06/07/24 23:57:43
>144
抽象クラスを継承して使うことが、Managerが多いことの例え、
って部分が理解出来ない。
147:デフォルトの名無しさん
06/07/25 00:03:42
>>145
参考になりました・・・・・
明日から、どうしよ。
なんか、このライブラリを使用することを半強制されてるんだけど・・・・
(；´Д`)
148:デフォルトの名無しさん
06/07/25 00:23:51
使いにくいだけのショボブラリを仕事で使わされると虐待かと思う
149:デフォルトの名無しさん
06/07/25 00:25:50
>>146
説明が悪くて申し訳ないす。
何というか汎用的な各機能毎にManagerがいて、
汎用的な処理を実装する機能をもつクラスが必要になる
場合はそのManagerを継承して、新たなManagerを作ってねという感じなんですよ。
んで、ファイルを読んだり、書いたりする機能がある場合だったら
必ずFileManagerとやらを継承してHogeFileManagerや、
FugaFileManagerみたいなクラスを作ろうという風になってます。
Managerと言う割には、ファイルの読み/書きの機能の為だけに
わざわざ継承するのはどうなのかなぁと。
FileManagerにHogeFileManagerやFugaFileManagerのインスタンスを
渡して処理するような事も無いみたいだし・・・
うまく説明できないけどこんな状態です・・・。
150:デフォルトの名無しさん
06/07/25 00:52:47
>>149
"Manager"という名前がアレだけど、それって単に物理的な何かを
抽象化してるだけでしょ。
良くある話。
151:デフォルトの名無しさん
06/07/25 01:07:55
～erみたいなクラスは確かによく見るんですが、
余りにも～Managerがたくさんいたんで
おかしいなと、自分が考えすぎてただけなのかもしれないすね。
明日あたり、作成者の人にどういう意図で作ったのか
聞いてみます。
お騒がせしました。
152:デフォルトの名無しさん
06/07/25 01:22:49
やめとけ、意図と聞くと切れる。
聞いただけで否定されてる？って切れる。
153:デフォルトの名無しさん
06/07/28 01:10:59
↑こういうプロになりたくないと思ったbyｱﾏﾁｭｱ
154:デフォルトの名無しさん
06/07/28 01:46:47
糸は切れやすい。たしかに。
155:デフォルトの名無しさん
06/07/28 02:10:29
自分の設計が最強と思ってる人間が、
同じプロジェクトに居たりすると困るよなぁ。
やたらと、自作ライブラリを使わせようとしたり、
頼んでも無いのに勝手にこれ使ってくださいとか言ってきたりする奴。
身の回りに一人居るが、
今、新人を洗脳してるw
型って何？、レベルの人間に
懇々と我流オブジェクト指向について熱く薀蓄を語っては、
新人のやる気を萎えさせてる。
おかげで、久しぶりに開発人数が増えそうなのに、
辞めてってしまいそうだ。
156:デフォルトの名無しさん
06/07/28 21:20:14
オブジェクト指向もデザパタも判らない奴>>155
157:デフォルトの名無しさん
06/07/28 21:27:46
>>155
困るなら論破すればいいのに
158:デフォルトの名無しさん
06/07/30 10:03:49
>>155
俺の事言われてるのかと思ったw
まぁ、数千行の関数とかコピペで作る奴よりマシだと思ってるけど。
俺は自作ライブラリ作るときは、シンプル＆単機能な設計でUnitTestとセットで提供しているから問題ないよな。
159:デフォルトの名無しさん
06/07/30 10:10:14
田舎ライブラリ使わされるのは苦痛なだけ
そのまま作らせろ
160:デフォルトの名無しさん
06/07/31 00:34:18
155の新人は、優秀なメンテナンス要員に成長しましたとさ。
めでたしめでたし
161:デフォルトの名無しさん
06/08/01 22:01:01
デザインパターンってどのくらい覚えるのがいいんだろうか
GoF以外のJ2EEとかマルチスレッドとか視点を絞ったパターンまでは手が出ない
162:デフォルトの名無しさん
06/08/01 22:39:28
>>161
必要な時に調べて使え。覚える必要は無い
163:デフォルトの名無しさん
06/08/08 12:54:24
>>119の
AbstractA＜抽象クラス
│
AImpl＜共通実装部分
├SubclassB＜差異
└SubclassC＜差異
のAImpl＜共通実装部分って部分ってテンプレートパターン？
どうも何パターンとかって分類するのが苦手なのよ
164:デフォルトの名無しさん
06/08/08 13:12:16
デザパタとか本当に使ってるの？使っていてもまわり
の人が理解できてる？
Ｃ＋＋やデザパタをつかってプログラムしてもまわりが
理解できず、バグ混入の原因になっているのでは？
オタクなクラス設計やデザパタ使ってるあなたが
結果的にプロジェクトを破壊するテロリストになって
しまっているんじゃないの？
で、実際にトラブルが起きると｢こんなことも理解して
ないなんて一人前のプログラマじゃない！｣とか言って
自分の知識をひけらかしたり、失敗を人のせいにするん
だろ。ラーメン屋の亭主みたいな融通のきかない職人
じゃあるまいし。こういう職人肌みたいな人はＣ＋＋の
テンプレートと共に消えてくれ。頼むから。
｣
165:デフォルトの名無しさん
06/08/08 13:16:31
>>164
と、IQ80の君に言われても・・・。
166:デフォルトの名無しさん
06/08/08 13:30:14
このスレに書かれている愚痴って、
もう2002年当時からずっと一緒。
プログラムのﾌﾟウの字も知らない煽り屋が必死に煽ってるだけなんだろ。
無意味
167:デフォルトの名無しさん
06/08/08 13:32:20
10年経ってもNewbieは必ず誕生するからね。
彼らから議論の場を取り上げるのは、酷というものであろう。
168:デフォルトの名無しさん
06/08/08 16:13:43
2002年なら新しい方だな
C++は1998年の仕様がまだ実装されてないんだから
169:デフォルトの名無しさん
06/08/08 19:43:50
業務でManagerと名の付くクラスは大抵ろくでもないクラスだよな。
DBConnection関係のクラスをキモくラップしただけの奴とか。
これを共通で使ってくださいとか指示されると萎えるｗ
170:デフォルトの名無しさん
06/08/08 19:49:04
>>169
脳内業務乙。
171:デフォルトの名無しさん
06/08/08 23:20:46
みんなクラス抽出ってどうやってんの？
ユースケースから名詞を全部抜き出して一つ一つ吟味したり、
boundary,control,entityって分類分けしたりする？
仕様書が完璧に出来てるならやってもいいけど、
仕様書が完全になるの待ってたらいつまでたっても仕事に取り掛かれないし、
仕様変更のたびにそんなんやってらんないよね。
172:デフォルトの名無しさん
06/08/09 10:15:03
別会社から引き継いだソースを設計チームでレビューしてたときの話。
ソースの中に簡単なFactoryパターンが含まれていたんだが、
一人だけFactoryが分からないやつがいた（年齢だけでいえば中堅）。
まあパターンを知らないってのは別によい、知らなくてもコードを
読めば何やってるか分かるはずだからな。
と、みんな思ってたんだが、いくら説明しても伝わらない。
細かく聞いていったらどうやら継承とインスタンス化の違いが分かっていなかった
ということが判明。
そんな人を設計から外す方法を相談させてください。
173:デフォルトの名無しさん
06/08/09 11:02:33
継承とインスタンス化の違いを説明できないのもﾔﾊﾞｲと思う
174:デフォルトの名無しさん
06/08/09 12:55:40
分かってないポイントが遥か手前だと、そこから全て教育するのがマンドクサい
175:デフォルトの名無しさん
06/08/09 13:16:12
>>172
スレ違い
176:デフォルトの名無しさん
06/08/09 13:46:24
職場の愚痴か、せいぜい教育方法の話だしな。
無理に設計に絡ませると、「馬鹿でも分かる、かつOOを生かす方法とは？」になるか。
最近流行のDIが近い回答か？
177:デフォルトの名無しさん
06/08/19 10:58:06
本人、解ってない事は判ってるんだろうか？
178:デフォルトの名無しさん
06/08/19 12:07:22
>>175
というか、板違い。どう考えてもマ板の話題。
>>172
オブジェクト指向が理解できないPG
ｽﾚﾘﾝｸ(prog板)
179:デフォルトの名無しさん
06/10/05 13:05:29
( ﾟдﾟ )
180:デフォルトの名無しさん
06/10/06 22:17:05
Javaなんだが、フレームワークが乱立してる昨今。
フレームワークそのものはOOしないで高速にして欲しいと思う。
Hibernateとかは内部はMapで公開するときだけBeanらしいし
何は無くともちょっぱやってのをコンセプトにしたフレームワークが欲しい。
181:デフォルトの名無しさん
06/10/07 04:02:33
( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ )
182:デフォルトの名無しさん
06/10/10 09:52:51
>OOしないで高速に
な、なんだってー(AA略
183:デフォルトの名無しさん
06/10/10 19:12:27
package privateとかfriendとか使えば
公開部だけをOOにしたnew最小限ロジックが描けるけど
世間ではこういうのってタブーなのかね
184:デフォルトの名無しさん
06/10/11 08:19:28
( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ ) ( ﾟдﾟ )
185:デフォルトの名無しさん
06/10/12 22:11:57
>>180
Javaって時点で速度犠牲にしてんだから
C言語のフレームワークとかｗ
186:デフォルトの名無しさん
06/10/12 23:52:58
おまえら
フレームワーク
って何？
187:デフォルトの名無しさん
06/10/12 23:58:53
frameとworkを組み合わせたまんまの意味だよ。
枠組みの中での仕事。その作業が出来る環境が用意された中で仕事する。
188:デフォルトの名無しさん
06/10/13 01:35:53
プレハブ住宅のイメージだにょ
189:デフォルトの名無しさん
06/10/14 13:20:59
>>187
逆じゃね？
190:デフォルトの名無しさん
06/10/14 13:42:31
ワークフレーム？
191:デフォルトの名無しさん
06/10/14 23:50:33
>190
逆なのは和訳の方だろｗ
192:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/10/28 00:13:11
テーブルとある程度等価なJavaBeansと
DBへの問い合わせメソッドを記述したインタフェースを
用意するのがDAOパターンじゃなかったっけ？
こうしておくと分業体制のときにスタブが作れるし
レイヤーを分けることによる保守性の向上にも役立つ利点があったはず。
194:デフォルトの名無しさん
06/10/28 16:36:01
>>193
関連を考慮しないのであれば、それだけでよいのですが。
Member が Group に所属する、というような構造があった場合に、
その関連をどの部分で扱うかということです。
テーブルと等価な JavaBeans を DAO で get した場合、
例えば、
Group group = dao.get();
としても、得られるのは Group の情報だけだとすると、
Member のリストを得るような処理は、どこにどのように入れるのが妥当なのか、
という問題です。
195:デフォルトの名無しさん
06/11/17 21:57:43
ﾄﾞﾄﾈﾄの話なんだけどさぁ。OOPのはどれ読んでもﾃﾞｻﾞﾊﾟﾀ使ってﾎﾟﾘﾓすればｸﾗｽの拡張も楽チンだよぅって
書いてあるけど、ｸﾗｽのDLLだけ増やして済むならその通りだけどさぁ。
実際はｸﾗｽが増えれば結局参照の追加やﾋﾞﾙﾄﾞのし直しが発生するじゃん？
そこらへんまで書いて説明してないよね。ｸﾗｽと実ﾌｧｲﾙの構成まで説明してくれよ。ﾋﾞﾙﾄﾞやり直すんなら
単一ﾌｧｲﾙのでっかいｸﾗｽでもいいじゃん、てならね？
196:デフォルトの名無しさん
06/11/17 22:49:26
>>195
えーと、それはモデルと実装がゴッチャになってるだけなのではないかと思いますが？
197:195
06/11/18 11:07:44
>>196
ゴッチャというか、でも実装を考えないでﾓﾃﾞﾘﾝｸﾞしたって意味ないじゃん？
例えばﾌｧｸﾄﾘﾊﾟﾀﾝでｸﾗｽ生成のｸﾗｽをFactory.dllとして機能ｸﾗｽがbuhin1.dll、buhin2.dll
ってあったとしてbuhin3.dllを増やしたら関係ないbuhin1.dllとｸﾗｲｱﾝﾄもﾋﾞﾙﾄﾞし直しじゃん？
そんならclass.dllにまとめて放り込んでこいつのﾋﾞﾙﾄﾞだけでってのもアリなんじゃって
気がするけどこれは実装のﾃﾞｻﾞﾊﾟﾀ？みたいのからは外れちゃうんだしょ？
こういった場合の良設計ﾊﾟﾀｰﾝを教えてくださいまし。
198:デフォルトの名無しさん
06/11/18 23:45:24
ようしらんけど、怒涛熱湯って、必ず、１クラス１DLL なの？
自分は Java しかしらんけど、Product 抽象クラスなり、
インターフェイスを作れば、具象クラスがいくら増えようが、
利用側は再コンパイルはいらんと思うのだが、
怒涛熱湯はそういうことはできないの？
つうか、Product を抽象化できないなら、 Factory のありがたみは半減のような・・・。
199:195
06/11/19 18:53:40
>>197の訂正
>関係ないbuhin1.dllとｸﾗｲｱﾝﾄも
↓
関係ないFactory.dllとｸﾗｲｱﾝﾄも
>>198
> ようしらんけど、怒涛熱湯って、必ず、１クラス１DLL なの？
いや、一個のdllにまとめてもよいけど、そうすると一箇所のｸﾗｽの修正だけで
ｱｾﾝﾌﾞﾘ(dll）のﾊﾞｰｼﾞｮﾝが上がってしまうからどのｸﾗｽが修正されたか管理上
わかりにくいよね。
> 自分は Java しかしらんけど、Product 抽象クラスなり、
> インターフェイスを作れば、具象クラスがいくら増えようが、
> 利用側は再コンパイルはいらんと思うのだが、
> 怒涛熱湯はそういうことはできないの？
逆に俺はJava知らんけど、ﾄﾞﾄﾈﾄはﾍﾞｰｽｸﾗｽで変数を定義してても実際にｲﾝｽﾀﾝｽ化
される実態のｸﾗｽが含まれるdllを事前に参照しておかないと無理。
つまり言葉のまま参照設定が必要。遅延ﾊﾞｲﾝﾃﾞｨﾝｸﾞでできなくはないけど普通やらない。
VS2005からは複数のdllとかのﾌｧｲﾙを一個にまとめる機能が付いたみたいだけど、それは
提供上の管理性とかが主眼でこれの問題とは別箇だからなぁ・・
200:デフォルトの名無しさん
07/01/08 20:47:55
っていうか、ファクトリパターン使うなら遅延バインディングにしないと意味ねーじゃん
201:デフォルトの名無しさん
07/01/15 01:10:51
シナリオ制御をうまいことやんのはどうすんの？
202:デフォルトの名無しさん
07/01/15 01:12:36
も少し具体的にいったほうがいんじゃね？
203:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/01/30 23:26:34
>>203 の言わんとしていることが
分かった奴、いるか？
205:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/01/30 23:55:21
>>203
駄文で読むの疲れるから、流し読みしたんだが言ってることはわかる
つまり彼はRDBを否定する考えの持ち主
>>202
文章もプログラムもセンスないね
この小学生の文章はなに？新入社員？
読ませる気がなくてあれを書いたのなら君は大物だ
>DBに、n:nの関係
n:nじゃなくてUMLに則って*対*のほうがいいと思う
207:デフォルトの名無しさん
07/01/31 00:00:58
以降、何の罪も無い
>>202 を哀れむスレとなりますた。
208:デフォルトの名無しさん
07/01/31 00:12:00
>>203
DBを使う場合、プログラムで何度もSELECTするよりも結合を使って
一回でやったほうが速いと普通思うので、配列に一度いれてからSELECTする
のはあまりやらないかも。
あと、クラスは、テーブルをベースにするのではなくて、検索結果をベースに
したほうよさそうですね。
その例だと、shopの配列を持つクラスとして、メソッドで検索条件を渡す感じで
よいか思いますが。
209:デフォルトの名無しさん
07/01/31 00:14:42
副問い合わせって今でも遅いの？
見やすいからテーブル結合よりそっちのがメインなんだよね
210:デフォルトの名無しさん
07/01/31 00:25:57
>>209
ｽﾚ違いな気もするが
DBと流すQUERYにもよると思うが、そんなに変わらないと思うけどね
211:203
07/01/31 08:51:59
>>205
>>206
>>208
レスありがとうございます。
ちょっとすれ違いな話になってきちゃいましたが
例えば商品Xを扱っている店とその店が扱っている全ての商品、
店1（商品X・商品Y）
店3（商品X）
店6（商品X・商品S・商品Y・商品Z）
↑こういうの取り出したい時って一回のSQLでいけるんでしょうか？
だとしたらSQLの勉強不足と言うことで、悩みは一気に解消なのですが。
DB版行った方がよさげですか？
212:デフォルトの名無しさん
07/01/31 10:25:47
>>211
副問い合わせやGROUP_CONCAT()を使えばできますが
ここよりはSQL関連の質問ｽﾚへほうがいいかも
213:211
07/01/31 12:36:44
>>212
ありがとうございます
GROUP_CONCAT()というのは知りませんでした。
というか、使ってるのがpostgreSQLなんですけど、
ちょっと調べてみたらpostgreにはないっぽいですね。
自作関数を実装しなきゃならないようです。
どっちにしてもすれ違いなので、SQLの方に行ってみます。
皆さんお世話になりました。
214:デフォルトの名無しさん
07/01/31 23:56:42
>>213
>自作関数を実装しなきゃならないようです。
せっかく >>212 が指摘してくれた
「副問い合わせ」の件は無視かよ・・・
ま、ご自由に(w
215:デフォルトの名無しさん
07/02/01 00:14:33
しょしんしゃって
おもしろいよね
おれもそんなじきがあったのかなぁ
216:デフォルトの名無しさん
07/02/02 15:36:07
どんな要素技術についても、全ての人は初心者であった時期はあるだろう。
世の中の要素技術全てについて初心者を脱却した人なぞおらん。
ということはもう新たな要素技術を知る必要のない立場／ポジションにいるわけだ。
217:デフォルトの名無しさん
07/03/07 09:06:47
>>214
うぬぼれすぎじゃねw
218:デフォルトの名無しさん
07/03/09 00:06:58
delegate event modelとobserver patternの違いがわかりません＞＜
219:デフォルトの名無しさん
07/03/10 02:32:49
呼び方が違うだけじゃねーの？
220:デフォルトの名無しさん
07/03/10 07:43:59
俺、オブザーバーパターンはsubjectとobserver、２つの要素があって、
observerがイベントを監視し、subjectに対しイベントに変更があったこと通知、
そして、subjectが他のobserverに通知。
なんて教えられたんだけど
このぐらいの変更なら許容範囲？
221:デフォルトの名無しさん
07/03/10 10:48:54
subjectが、自分が変更されたことをobserverにつうちするんだぞー
observerがsubjectへ変更を加える事があっても、subjectに
何かを通知する事はない
もっともobserverが別のobserverのsubjectなら話は別だが
222:デフォルトの名無しさん
07/03/28 01:38:17
ふむむむ・・・・・・・・・
223:デフォルトの名無しさん
07/05/13 22:19:14
Swingアプリの設計って一般的にはどうなってるんでしょうか？
Observerパターン使ってViewがイベントを受け取ったらControllerに渡して、ControllerからServiceを用いてデータ操作→Modelに加工して保存→通知してViewのリペイントって感じですか？
単純なSwingアプリでModelとかServiceってどういう役割になるのか分かりません。Modelの役割ってどういうものなのか、実例を見てみたいのですが。。。経験が全く無いので困ってます。どなたか設計の勉強になる本とか教えて下さい。。。
224:デフォルトの名無しさん
07/05/13 23:58:46
一時期デスクトップでも自作よりショップブランドとかDELLの方が安く付いた時期あったけど、
最近は明らかに自作の方が安いよね。とC2Dマシンを組終えてMemtest中の俺が流れを無視して言ってみる。
E6600、メモリ1GBx4、HDD320GBx4、GF7900GS、電源550W、ケースだけ古いSongcheerを使い回し。
最近アキバはキモいのでツクモで一括通販。
この組み合わせで16万ちょいなんてDELLじゃ絶対ムリ。
ま、確かに超ローエンドだとキーボードとか他のパーツが占める割合が増えるから結果として安いけどね。
特にハイスペックでなくとも容量なんかが欲しければ自作の方が安い。
嫁もIntelMacになってMacに見切り付けたみたいだから次は安く上がるなｗ
元がMac G5だからお下がりのP4 3Ghzでも速く感じるだろうｗｗｗ
225:デフォルトの名無しさん
07/05/14 00:01:11
誤爆か？
226:デフォルトの名無しさん
07/05/14 00:08:33
次はどんな自作嫁を投下してくれるのか楽しみだ
227:デフォルトの名無しさん
07/05/15 16:01:49
大きなおっぱい
228:デフォルトの名無しさん
07/05/18 12:24:33
プラガブル MVC を Java で説明してくれません？
229:デフォルトの名無しさん
07/05/21 02:41:10
interface
230:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/06/16 00:05:11
なんに使うんだそんなもん
232:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/07/05 15:58:39
>>233
ありがとうございます。
235:デフォルトの名無しさん
07/07/09 23:47:14
どういたばしく
236:デフォルトの名無しさん
07/10/30 21:18:52
ここで質問するのが適切かどうかはわからないのですが、
よくいうビジネスロジックってどういうものを言うのでしょうか。
staticで提供されているユーティリティメソッドなどはビジネスロジックではないのなら、
どういう観点で見てどういうくくりでこの処理を行うビジネスロジッククラスと設計すればいいのでしょうか。
なんとなくはわかっているんですが、なんかしっくりこないんです。
また、ビジネスロジッククラスに作成するメソッドをどのビジネスロジッククラスにコーディングするかは
どのように決めればいいでしょうか。ユーザーに関連する処理だからこのクラスとか、分け方が理解できません｡
237:デフォルトの名無しさん
07/10/31 04:02:07
>>236
まずここ嫁
URLﾘﾝｸ(ja.wikipedia.org)
全くの初心者の場合、自分で設計しようとしないで
既存のフレームワークやアーキテクチャの流儀に従うと良い
238:デフォルトの名無しさん
07/10/31 21:25:45
>>237
レスありがとうございます。
読んでみると意味はわかるのです。ですが、それを実際にかたちにすることができません。
こんなレベルでも実際に仕事をしています。私の会社ではこれらを全て同じクラス内にコーディングするのです。
実際に要件から設計、コーディング、クラス設計を学ぶことができる書籍などはないでしょうか。
書籍を読んでも疎結合だとかビジネスロジックは分離だとか、いろいろ書いてあるのですが
自分の仕事でうまくやることができないのです。
239:デフォルトの名無しさん
07/10/31 21:48:49
> 実際に要件から設計、コーディング、クラス設計を学ぶことができる書籍などはないでしょうか。
どうしても自分で設計したければ、
大き目の本屋に行ってオブジェクト指向
に関係ありそうな本を片端から買って読む。
多分100冊も無いと思う。
その上で、実戦を10回くらい経験すれば
なんとか人並に設計できるようになると思う。
240:デフォルトの名無しさん
07/11/01 21:38:01
AOPなどを使えない環境で、DBコネクション管理、コミット／ロールバックを制御したいのですが、
どういった方法が最善なのでしょうか。メソッドを細分化するのはいいのですが、引数にDBコネクションを必要とする場合が多くなってしまいます。
241:デフォルトの名無しさん
07/11/02 01:33:17
springのトランザクションマネージャ使えば？
それも使えないならスレッドローカル変数をつかって
トランザクションマネージャを自作
242:デフォルトの名無しさん
07/11/08 22:48:52
ビジネスロジッククラスのインターフェースを考える場合に
業務フローからメソッドの定義を考えるのはおかしいでしょうか。
インターフェースを人に書いてもらえば実装はいくらでもできるのですが、
いまいちこのレベルまで落とし込む方法がわからずこまっております。
243:デフォルトの名無しさん
07/11/09 00:37:07
>>242
PofEAAとかURLﾘﾝｸ(d.hatena.ne.jp)
読んで自分でいろいろ工夫したらいいよ
244:デフォルトの名無しさん
07/11/10 20:04:09
>>243
ありがとうございます。書籍を購入して勉強はします、が、、、
ほかにもいろいろ調べたりしなければならないので時間がとれなそうです。
ひがさんのblogは書いてあることの意味はなんとなくわかるのですが、
実践にもっていくには私には少し？難しいようです。
245:デフォルトの名無しさん
07/11/12 22:36:59
Http通信で、レスポンスがcsvだったりxmlでURIごとにいろいろなパターンを返すのですが、
この場合、View用の抽象クラスを用意してそれをパターンごとにsetterを用意しようと考えています。
もっとよいアイデアがあれば教えてください。
246:デフォルトの名無しさん
07/11/13 00:38:46
Http通信ﾜﾛｽ
247:デフォルトの名無しさん
07/11/13 00:47:02
おかしくもなんともないな。
>>245
同じデータを複数のフォーマットで返せるサービスなのか、
システムで使われるレスポンスデータが複数あるのかどっち？
後者なら設計のコンセプトを知りたい。
248:デフォルトの名無しさん
07/11/13 01:40:34
それ、HotJava (α)時代から提供されてる機能だから。
249:デフォルトの名無しさん
07/11/15 23:16:14
JavaなんだけどService Provider Interfaceスタイルをとる為に
特定の引数を持つコンストラクタをリフレクションで探すのってダメかな？
ようはBuilderだけで完結させて、BuilderFactoryは作らない方法。
250:デフォルトの名無しさん
07/11/16 00:08:41
>>243
>ドメインロジックを()で囲っているのは、ドメインロジックを
>ドメインモデルに持たせた場合、ドメインロジックは、ビジネスロジック
この文のカタカナ率を計算せよ。
チラット見ただけでどんな人なのか全然知らないけど、
日本語をマトモに話せない(話そうとしない)ヤツは、
ろくでもないことが多い。
251:デフォルトの名無しさん
07/11/16 16:53:20
グラフライブラリィーを作りたいんだけど
C++で書かれていて、デザインパターンを用いたお手本になるライブラリィソースって
ないっすか？
252:デフォルトの名無しさん
07/11/16 19:01:29
boost
253:デフォルトの名無しさん
07/11/20 18:04:51
>>250
そいつの人間性はさておき、全然知らないってのは業界人としてどうなのよ・・・
254:デフォルトの名無しさん
07/12/30 13:03:50
Rubyを使用しています。
OOPの設計でとっても悩んでいます。
例えば、
壁にボールを当てる事を考えます。
壁クラス
ボールクラス
投げる人クラスが
あるとします。
壁にボールが当たって跳ね返ってくるのは
どのクラスで実装しますか？
Mediatorクラスを作るべきですか？
あと、
メソッドのaugumentには
他の独自のクラスをとってよいのでしょうか？
メソッドのaugumentには、
operandはおkで、optionはNO
だというのがHeuristicだそうですが、
という事は、他のクラス
例えばこういう書き方をするか知りませんが
method(MyClass object)
のようなメソッドを実装してもいいのですか？
あまりにも汎用性が失われるような気がします。
255:デフォルトの名無しさん
07/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:デフォルトの名無しさん
08/03/08 19:27:46
質問です。
設計者は開発者に対してpublicなAPIだけを
仕様として渡して、
開発者はそれをprivateなメソッドに
分解して最終的にpublicなメソッドのテストに通ればいいという事ですか？
257:デフォルトの名無しさん
08/03/16 23:55:02
データ形式が以下のようなブロック集合の組み合わせの場合
DATA( A or B or C or D)
このようなデータを汎用的に書き出したいのですが
どのように設計すればいいでしょうか。
[A,B,D]の場合もあるし[C,D]の場合もあるし
かといってちまちまケース文で書き出すのは愚の骨頂だし
解らない。
258:デフォルトの名無しさん
08/03/17 02:08:14
というよりどういう用途・用法で扱われるのかわからないので想像しづらいんだが．
単純にビットフィールドってことでおｋ？
259:デフォルトの名無しさん
08/03/17 10:01:59
>>257
A ～ D を自由に組み合わせて出力したいという程度ならまず、A ～ D に
共通な「書き出し可能データ」というインタフェースを定義する。そして
A ～ D がこれを継承する。
次に「データを書き出す人」という抽象を作り、「書き出し可能データ」の
集合(配列、リストなど)を受け取って、ひたすら書き出すようにする。
「書き出し可能データ」の集合を生成するために、制御役の抽象が必要に
なるかもしれない。
260:デフォルトの名無しさん
08/03/17 17:32:42
>>256
いいんじゃね？
設計者の設計粒度がどの程度かわからんけど
仕様としては外部からみた振る舞いが正しければいいわけだし
261:デフォルトの名無しさん
08/03/25 16:07:35
SRPについて質問です。
「クラスの変更理由を一つにしなさい」
という事は逆にいうと、
「もしクラスが変更される時はそのクラスの仕様をすべて変更しなさい。
もし変更されない仕様が混在するならばそれは変更理由が一つではない」
という意味ですか？
262:デフォルトの名無しさん
08/03/25 22:18:55
>>261
違います。変更理由が一つであることとクラス仕様全てを変更することに
相関はありません。
SRP は「クラスは単一の概念を表現すべし」というルールです。単一の
概念を表現するために複数のデータとメソッドが定義されるのだから、
部分的な変更をかけていく行為自体は、何ら SRP に反しません。
例えば、ある抽象概念を表現してみたものの、あとから足りないものに
気付いてメソッドを追加する、というごくありふれたケースを考えてみても、
クラスの既存仕様を壊さずに部分的な変更をかけていることが実感できる
でしょう。
あるクラスが SRP に反しているかどうか判断するには、異なる概念が
混在していないかどうかを常識的にチェックすれば良いのです。もし
混在しているのなら、それは二つのクラスに分離するべきなのです。
ただ、SRP に違反しているクラスが一概に悪とは言えないことも意識して
おくことは大切です。何事も行きすぎた原理主義はよくない。
263:デフォルトの名無しさん
08/03/25 23:21:24
>>262
あとから足りないものに
気付いてメソッドを追加する、というごくありふれたケース
といいますが、これはOCPが違反しませんか？
今、Head Firstのオブジェクト指向設計とかいう本を読んでいます。
そこにはSRPの例として、車のクラスを定義する場合に
そこにwashなどのメソッドを組み込んではいけないという事になっていますが、
例えば外部で
CarWasher#wash(AutoMobile)を定義した場合、
このCarWasherクラスはAutoMobileの例えばdirtというフィールドが存在している事を知っていないければなりません。
（例えばwashというメソッドがdirtを0にするものだとすると）
これは情報の隠蔽に失敗していませんか？
それに無闇にAutoMobile#setDirtを設定してこれを受け入れれば、
他でどんな悪用をされるか分かりません。
失敗した設計だと思います。
カプセル化についてどう考えていますか？
setterはなるべく実装しない方が良いように思うので、
データについてクラスを分離するのがいいと思うのですが、
この本には振る舞いについて分離せよと書いてあります。
264:デフォルトの名無しさん
08/03/26 01:09:50
>>263
拡張と一口に言っても、類似概念の追加と、メソッドの追加では意味合いが
違います。OCP を守るためにメソッドの追加ではなく継承で対応するの
では本末転倒でしょう。原則は絶対ではないのだから、柔軟に対応すれば
いいと思いますよ。
その本は読んでいないので状況が良くわかりませんが、車クラスが wash
を提供するべきではない理由が書いてあるのではありませんか? 車の主要な
責務は「人を乗せて移動する」であるとかなんとか。
まあ、いずれにしてもいい例ではない気がしますが、クラスでは概念を
完全に表現することができない以上、どこかに軸足を置く必要がある
わけです。それが「洗う」なのか「走る」なのかは目的によって変わって
くるでしょう。
カプセル化は言うまでもなくとても重要ですね。
大切なのは、自分が表現したいものをはっきりさせることです。そうすれば
自然と必要なデータや振る舞いが備わっていきますよ。
265:デフォルトの名無しさん
08/05/14 12:54:34
>>263
CarWasherクラスがAutoMobileクラスのdirtフィールドを知ってなければならない
のは当たり前。
そもそも、洗車機は車の存在を前提に作られるし、皿洗浄器は皿の存在を前提
に作れる。何を？どうする？の２つを知ってないと「する側」は作れない。
てか、洗車は例えとして分かり難いぞｗ
266:デフォルトの名無しさん
08/05/14 15:08:00
そもそも「汚れ具合」が定義されていなければ「洗う」ことも「汚れる」ことも定義できない．
267:デフォルトの名無しさん
08/05/22 06:02:42
OOPに最近参入した新参者です。
設計（特にクラスの設計）に関するオススメの書籍何かないでしょうか？
例えばショッピングサイト、レンタルビデオショップなどわかりやすそうなものから考えていこうとしたものの
OOPへの理解が浅いせいかどうにも戸惑ってしまっています
よろしくお願いします
268:デフォルトの名無しさん
08/05/22 12:13:26
>>267
デザインパターンとともに学ぶオブジェクト指向のこころ
269:デフォルトの名無しさん
08/05/25 20:58:00
MVC分割したときにUndoのロジックってModelの実装領域になると思うんですが、
大抵このUndoってコマンドパターンとかで実装されますよね？
このとき、Modelに対する変更命令が全てコマンドで実行されることをコードレベルで保障するには、
Modelに対する変更命令を受け取ってコマンドを発行するクラスを作って、
更にModel内部のデータ構造に対するアクセスを制限するための
読み取り専用ラッパークラスを作って外に公開する、という感じになるのでしょうか？
実際このようなことって業務レベルの開発では行っていたりしますか？
270:デフォルトの名無しさん
08/05/26 00:23:07
>>267
個人的に、リファクタリングの実践が一番身に付きやすいと思う。
フリーソフトとかのソース落としてきてやりまくるといい。
ということで
・リファクタリング
271:デフォルトの名無しさん
08/06/19 22:55:43
実験で使用するシリアルポートから遠隔操作できる
温度調節機能付きの水質モニターを管理するプログラムを作りたいと思っています
1分毎に水質データと水温を取得する
PCから温度の管理値を変更できる
という機能を実現したいのですがこの場合
ポートの開閉やデータの送受信を管理するCommクラス
水質データの受信要求や管理値の変更命令をCommｵﾌﾞｼﾞｪｸﾄに送る、水質モニターの機能を実現するMonitorクラス
Monitorｵﾌﾞｼﾞｪｸﾄから値を受け取り実際に表示するGUIクラス
GUIがMonitorの参照を保持して
MonitorがCommの参照を保持する
このような構造でよいのでしょうか？
272:271
08/06/20 00:31:37
それとも
Monitorクラスの定期測定と管理値の変更は別のクラスの振る舞いにしたほうが良いのでしょうか
273:デフォルトの名無しさん
08/06/20 20:41:49
>>271
いいと思います。あとは、水質モニターのマルチベンダー化や多重化等が
確実なら、事前に拡張性を考慮するのもあり。
274:デフォルトの名無しさん
08/06/20 22:07:46
>>273
ありがとうございます
あと、新型のモニターを使用する場合も考えると
拡張機能を実装しやすいようにデコレータにしておいた方がいいですかね
275:デフォルトの名無しさん
08/06/21 00:04:07
>>274
数ヶ月以内に新型が導入されるならね。さもなくば、シンプルに徹する。
276:デフォルトの名無しさん
08/06/21 00:47:55
肝心なこと聞き忘れてました
二つの値を一つの文字列に合成してシリアル通信するのですが
この命令の合成と返答の翻訳はMonitorとCommクラスどちらに実装するべきでしょうか
質問続きで申し訳ありません
277:デフォルトの名無しさん
08/06/21 06:02:48
>>276
"二つの値Constructor"に任せればいいんじゃない？
もしくはMul/Demultiplexerとか？
278:デフォルトの名無しさん
08/06/21 10:29:05
>>276
Comm クラスは汎用的なシリアル通信だけを行うユーティリティクラスで
いいんじゃないかな。制御プロトコルの知識は Monitor に持たせる。
279:デフォルトの名無しさん
08/06/21 12:11:06
>>276
おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
280:デフォルトの名無しさん
08/08/05 22:06:37
>>279
>おれだったら、合成と返答の翻訳を行うクラスを別途作るかな。
メッセージI/FとパーサーI/F又はどれか一つ用意して
メッセージの詳細はベンダー毎に実装するのが一般的かと思う。
281:デフォルトの名無しさん
08/08/08 03:31:53
>>271
ちょっとOO分析っぽいことやってみたかった．
# [実験]で[使用する][シリアルポート]から[遠隔操作できる]
# [温度][調節][機能]付きの[水質モニター]を[管理する]
# [1分毎]に[水質データ]と[水温]を[取得する]
# [PC]から[温度]の[管理値]を[変更できる]
必要な名詞(オブジェクト)
シリアルポート，温度，水質モニター，1分毎，水質データ，水温，温度，管理値
足りない名詞
タイマー
必要な動詞(メソッド)
操作，調節，管理，取得，変更
ここまでやったけど別に何を作ろうというわけではない
282:デフォルトの名無しさん
08/08/10 12:13:24
温度がオブジェクトかよー
1分毎もかよー
水温・温度もかよー。
283:デフォルトの名無しさん
08/08/10 13:31:40
当たり前すぎますよねー＾＾
284:デフォルトの名無しさん
08/08/20 20:05:43
クラスの設計に関して悩み中です。
例えば以下のような必要とされる要素が有ったとします。
(要素内容はでたらめです。)
・コード/名称/メッセージ/結果/色/高さ/幅
/追加日/更新日/削除日/…(全部で20要素ぐらい)
処理1 … コード/名称/メッセージ/結果
処理2 … コード/結果/色/高さ/幅
処理3 … 結果/色/更新日
処理4 … 削除日
各処理は、クラスに個別分類できる処理になり、各処理に少しずつ上記要素が
絡んでくる状態になります。
このような場合、どのようなクラス設計が適していますか？
現在は、コード/名称～などの20要素ぐらいをBaseクラスにして、
処理1～4までを継承させています。
ただ、こうすると必要の無い要素まで入ってしまい、もっとすっきり
させたいなと思っています。
285:デフォルトの名無しさん
08/08/21 02:24:17
>>284
> ただ、こうすると必要の無い要素まで入ってしまい
この時点で継承を選ぶのがおかしい。意味のある単位に切り分けよう。
問題の切り分けじゃなくて、登場人物の切り分けを意識した方がいい。
例えば色／高さ／幅ってGUI上の属性情報なんじゃないの？
処理1と処理4でそれらの情報を使用しないってのなら、
ぱっと聞いただけでも処理１～４は継承関係上の兄弟とは思えない。
> このような場合、どのようなクラス設計が適していますか？
適切な切り分けの単位は要件仕様やその他の背景によって異なるよ。
とっかかりがないなら、それらのデータモデルを構造体化して、
処理の引数に渡してしまえばいい。
286:デフォルトの名無しさん
08/08/21 15:48:42
>>285
どうもです。
いえ、GUIの属性とかではありません。
サーバーへコマンドを投げると上記の値が返ってくるイメージです。
処理1なら
1.「コマンド処理1」をサーバへ送信
2.「コード/名称/メッセージ/結果」がサーバより返ってくる。
3．処理1の処理を行う。
処理2なら … と同じ様な処理が複数あります。
287:デフォルトの名無しさん
08/08/21 23:32:47
サーバーにコマンドを投げるとかいつ説明したよ。
それで相手に適切なクラスの分け方を聞いたわけ？
一応必要なアドバイスは>>285に入ってるから、熟読して悩め。
>>286の情報だけで何を悩めばいいかを挙げるなら以下くらいかな
・全ての処理で共通する送受信データの基本情報（必須情報）って何なの
・送受信データ全体を木構造に表すとどうなるの（構造体のメンバに構造体を持つかなど）
・送受信データに対して、それを継承するって適切なの
（データモデルとビジネスロジックは普通分けるがね）
恐らくだが、以下みたいな感じに落ち着くんじゃないか
・処理1,2,3,4ってのは、データモデルを引数に受ける関数ポインタ（Javaでいうリスナ）になる
・コマンド処理1,2,3,4と関数ポインタ（Javaならコマンド名のgetterとリスナをセットにしたクラス）と
送信データを引数とし、受信データを戻り値とする通信クライアントクラスが必要（C++なら受信データも引数で受ける）
・送受信データ中、基本情報以外の情報（構造体メンバの構造体）で使用しないものはNULLを入れる
基本情報以外が後からいろいろ増えるなら拡張情報をMapで持つ手もある。シリアライズ（デシリアライズ）がいるが。
最近の流儀だとXMLを使うのも悪い手ではない。（個人的にはJavaやC#ならこれにするな）
あなたのプロジェクトの答えを書いたつもりはないので、参考になるなら参考にして、後は悩め。
288:デフォルトの名無しさん
08/08/21 23:34:15
訂正
×受信データを戻り値とする
○受信データを関数ポインタの引数にしてその関数を実行する
289:デフォルトの名無しさん
08/08/31 16:08:07
ちょっとここの主題とずれるかもしれませんが、
ブラウザ - Webサーバー - APサーバー - DB
という一般的な構成でのエラーチェックで質問です。
入力データのチェックをするときに、未入力や不正文字はMVCのCで
チェックして、DBに問い合わせないとわからないチェックはMでいいですよね。
注文入力をするときに、数量の未入力は前者、在庫チェックは後者です。
でですね、「数量の上限」や「不可能な注文の組み合わせ」みたいに
「ビジネスロジックだけどDBに問い合わせる必要はない」というチェックは
APになげると余計な通信が発生するのでWebサーバーでやろうと思ってます。
Webサーバー側のpackageには原則Actionクラスしかないのですが、
このpackage配下にチェッカークラスを置くのに違和感を感じます。
注文形態が複雑でActionがいっぱいあるので、注文BaseActionを
作ってTemplateMethodパターンでフローを決めてるのですが、
だらだらとバリデートを書くのもフローがわかりにくくなって嫌です。
注文クラスそのものに書くべき？
290:デフォルトの名無しさん
08/08/31 16:34:20
TemplateMethod 使ってるなら、BaseAction に空の Validate メソッド
用意してフローに組み込み、具体的なチェック内容は派生クラスで実装
すればいいんでないの?
なぜ「だらだら」になるかが知りたいところ。
291:デフォルトの名無しさん
08/08/31 16:49:46
そこまではやってるんだけど、さらにその中で「注文条件がこれだったら
これは不可で」「数量をparseして文字列だったらこのエラーメッセージで」
みたいな処理が10以上あって、ロジックは共通なので、その個別のValidateを
BaseActionに書いてたんです。個別Validateのどれを呼ぶかは
Actionによって異なります。で、このチェッカーって切り出すべきだと
思うんだけど、actionパッケージの下にチェッカークラス置くのって
変だよなーと思って相談したわけです。
292:デフォルトの名無しさん
08/08/31 16:50:33
だらだらなのはBaseActionに個別のValidate処理がいっぱい並んでたから。
わかりにくかったですね。すいません。
293:デフォルトの名無しさん
08/08/31 21:00:05
なんとなく状況は把握できた。俺なら BaseAction には単一の Validate
メソッドだけ用意し、チェックメソッドは別クラスにまとめる。たぶん、
このチェッカークラスは stateless になるんじゃないかな。
派生クラスではこのチェッカーを使って個々の Validate メソッドを実装
すれば良い。チェッカークラスの置き場所はまあ、プロジェクト的な決め事
でしょう。
294:デフォルトの名無しさん
08/09/01 00:26:21
そうなんだよね。
今は各Actionクラスの処理の切り出しのイメージだったから
個別ValidatorでsetFieldError()してるんだけど、チェック処理の
多さからいって全public staticなクラスに切り出すべきだと思ってる。
すでにリリースされてるプロジェクトの機能追加なのであまり
リファクタリングしたくないんだけど。
で、最初の質問に戻るんだってば。actionパッケージの下には
actionクラスしかなく、serviceパッケージの下にはリモート呼び出しを
前提としたクラスとそのドメインオブジェクトしかない。
今後のプロジェクトではserviceクラスのメソッドにアノテーションつけて
ローカル実行とリモート呼び出しを分けられるようにしようかと思っていた。
そうするとやっぱ今回もあるべき論的にはserviceパッケージの下に
ローカル実行用のサービスクラスをつくるのかな。でも単純な未入力チェック
みたいのはコントローラーでやるべきだと思うし、うーん。
295:デフォルトの名無しさん
08/09/01 00:42:31
やっぱり、どの個別Validatorを呼び出すかみたいなロジックが
Actionに入ってることがそもそもおかしい気がしてきた。
あ、いやでも注文形態によって入力パラメータの数が違うから
未入力チェックを行うならActionか。
もしかしてstrutsみたいに各フィールドのセッターでvalidationしよう
っていうのが間違っているのか？
Action -> 個別注文クラス生成 -> 個別注文クラス#Validate()呼び出し
→ OKならリモート注文ServiceのValidate()呼び出し
こうするとすごくスッキリする。略してスッキる。ActionはModelの
生成だけでロジックにはノータッチになるし。チェッカークラスが
複雑で外だしにするとしても、個別注文クラスと同じpackageに
いれればしっくりくる。略してしっくる。ドメインオブジェクトがアクセッサしか
持っていないようなドメインモデル貧血症なつくりにはしてないからね。
296:デフォルトの名無しさん
08/11/13 18:02:24
あげ
297:デフォルトの名無しさん
08/11/27 14:40:57
パブリックヘッダファイルとプライベートヘッダファイルの違いが分かりません、
パブリックヘッダファイルで提供する関数と内部で使う関数の分け方すらわかりません。
298:デフォルトの名無しさん
08/11/28 00:16:46
OOP以前の問題だな
299:デフォルトの名無しさん
08/11/28 00:39:31
パブリック複合
300:デフォルトの名無しさん
08/12/06 00:00:34
テンプレート・メソッド パターンの多階層継承はマジ勘弁。
追いづらい。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
BaseCollectLogic ← テンプレート・メソッド パターン
↑
FileBaseCollectLogic ← テンプレート・メソッド パターン
↑
DomainLogic
カスが
301:デフォルトの名無しさん
08/12/06 01:58:35
それはやりすぎというより、なんか設計がおかしい気がする。
302:デフォルトの名無しさん
08/12/06 06:03:41
エントリーポイントを増やすのが目的なんだろうけど、
うざったいってのはよく分かる。
IService ← テンプレート・メソッド パターン
↑
AbstractLogic ← テンプレート・メソッド パターン
↑
DomainLogic
としてBaseCollectとやらはコンポジションでもっとけと。
303:デフォルトの名無しさん
08/12/06 09:36:21
問題ない。次
304:デフォルトの名無しさん
08/12/06 19:23:37
IService はインターフェースで Run メソッドが定義されてる。
クライアントは、
DomainLogic dl = new DomainLogic();
dl.Run();
あれ？スーパークラス使わないの？
IService はどうした？
IService は？
カスが
305:デフォルトの名無しさん
08/12/06 19:26:08
>>304 は >>300 の続きね
306:デフォルトの名無しさん
08/12/06 19:33:02
で、お前ならどうしたいのよ
307:デフォルトの名無しさん
08/12/06 19:36:49
黙れカスが
308:デフォルトの名無しさん
08/12/06 19:48:28
で、お前ならどうしたいのよ