- 1 名前：デフォルトの名無しさん [2005/09/24(土) 16:35:59 ]
- 全部publicでいいじゃん！ってならないようにするスレです。
- 12 名前：デフォルトの名無しさん mailto:sage [2005/09/24(土) 17:02:54 ]
- MVCを意識してライブラリを設計しているのですが
とあるメインループを持つController部を切り替えても
Model, Viewは同じものを使う手法を考えています。
この場合メインControllerを切り替える為のControllerを
それらの最上位に実装するのは正しい設計でしょうか？
ControllerController
├Model
├View
└Controller
この図の場合だとControllerがControllerControllerに
自身をあのControllerに切り替えてと頼む形になります。
ControllerControllerは切り替え処理以外の機能は持ちません。
- 13 名前：デフォルトの名無しさん mailto:sage [2005/09/24(土) 17:04:26 ]
- デザパタ勉強してください
- 14 名前：デフォルトの名無しさん mailto:sage [2005/09/24(土) 17:06:21 ]
- >>13
どのパターンですか？
- 15 名前：デフォルトの名無しさん [2005/09/24(土) 17:19:15 ]
- 全部publicではないが、数千行あるクラスでprivateなメソッドが1個だけで、
他は全部publicなメソッドってのがあった。
- 16 名前：デフォルトの名無しさん mailto:sage [2005/09/24(土) 17:32:51 ]
- CLOS最強!!
- 17 名前：デフォルトの名無しさん [2005/09/24(土) 17:53:32 ]
- >>15
コボラーの仕業だな。
最近、似たようなモンみたよ。
- 18 名前：デフォルトの名無しさん [2005/09/24(土) 18:53:42 ]
- >>13
はやくはやく
- 19 名前：デフォルトの名無しさん [2005/09/25(日) 02:43:03 ]
- >>14
youzyoパターン
- 20 名前：マイク ◆yrBrqfF1Ew [2005/09/25(日) 03:53:27 ]
- MVCウザイな。
使いやすくない。
- 21 名前：デフォルトの名無しさん mailto:sage [2005/09/25(日) 12:58:57 ]
- MVCはCが如何に無理をするかが焦点だな
- 22 名前：デフォルトの名無しさん [2005/10/02(日) 00:11:03 ]
- youzyoパターンってなんぞ？
委譲じゃないよな？
- 23 名前：デフォルトの名無しさん [2005/10/02(日) 01:11:15 ]
- ＝＝＝＝＝
基地外スレ
＝＝＝＝＝
- 24 名前：デフォルトの名無しさん mailto:sage [2005/10/02(日) 21:44:30 ]
- gofのすとらてじい？
- 25 名前：デフォルトの名無しさん [2005/10/21(金) 18:16:26 ]
- Mのクラスが、VやCのクラスを引数にとったり、内包したら設計ミスかな？
というか>>21が何気に至言だ
って、なんだ最後の発言が3週間くらい前か
- 26 名前：デフォルトの名無しさん [2005/10/23(日) 21:34:16 ]
- Mって早い話が構造体クラスでしょ？
SQLにマッピングするためのゲッタくらいが限界じゃないかな
- 27 名前：デフォルトの名無しさん mailto:sage [2005/10/23(日) 23:20:23 ]
- それはＣクラスでやりたいな・・・
- 28 名前：デフォルトの名無しさん [2005/11/04(金) 15:47:55 ]
- デザパタは１０回同じのを使うとわかった気になるなあ、おい。
- 29 名前：デフォルトの名無しさん mailto:sage [2005/11/05(土) 00:29:38 ]
- デザパタはOOPをプロでやってく上での教養なのかねぇ
実際仕事で汲んでも使う機会無い気がする。
せーぜーシングルトンがあぶ工場くらい。
- 30 名前：デフォルトの名無しさん [2005/11/06(日) 01:10:50 ]
- OOPのアルゴリズムテンプレートがあって
それをDBから引っこ抜いてくるように出来たら面白いのにな
プログラムとはそれすなわちアルゴリズムって証明できる
- 31 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 01:12:44 ]
- アルゴリズムテンプレートってなに？
- 32 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 01:14:59 ]
- 機能じゃないよ。言葉そのままの意味。
ソートとかコレクションとかOOPならどれでも共通化できそうなものを纏めて欲しい。
- 33 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 01:15:49 ]
- >>32
それとOOPが、どう関係するの？
- 34 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 02:27:39 ]
- >>29
漏れはComposite使いまくりんぐ
- 35 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 18:33:29 ]
- だいたいだなぁ、OOP限定なら「プログラム設計」じゃなくっ「てクラス設計」ではないのか？
- 36 名前：デフォルトの名無しさん mailto:sage [2005/11/06(日) 18:54:42 ]
- てクラス設計
- 37 名前：デフォルトの名無しさん [2005/12/02(金) 21:54:29 ]
- AOPって何ですか？
- 38 名前：デフォルトの名無しさん mailto:sage [2005/12/02(金) 22:16:43 ]
- エージェント？
- 39 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 00:56:10 ]
- スミス？
- 40 名前：デフォルトの名無しさん [2005/12/03(土) 01:05:30 ]
- >>37
アルベルト・プロモーテッド・プラゲラメ
- 41 名前：デフォルトの名無しさん [2005/12/03(土) 01:10:27 ]
- Oがないじゃん
- 42 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 01:19:54 ]
- 23のパターンを用いてHelloWorldを実装してください。
- 43 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 22:02:47 ]
- >>43
./のパクリはいりません
- 45 名前：デフォルトの名無しさん [2005/12/03(土) 22:07:59 ]
- GoF以外のデザパタ集で有名どころってある？
- 46 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 22:36:16 ]
- マルチスレッドのデザインパターンやら、
GRASPやJ2EEパターンが有名どころか？
- 47 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:31:49 ]
- C++でか書かれてるデザパタ参考本ってないよね
- 48 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:36:28 ]
- >>47
ｴｰ!!!
本家本はC++のはずだが。
- 49 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:38:49 ]
- smelltalkもはいってんじゃん。＞本家
- 50 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:42:47 ]
- >>49
はいってちゃまずいのか？
- 51 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:43:57 ]
- smalltalkは本家じゃん。本家が本家を扱って何が悪い。
- 52 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:54:19 ]
- 本家本は確かにSmalltalkとC++だな。
でもC++が多いから>>48みたいな反応でもあながち間違えではないと思う。
そんなわけで、Smalltalkに特化したThe Design Patterns Smalltalk Companionがわけだし。
- 53 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:55:10 ]
- smelltalk
- 54 名前：デフォルトの名無しさん [2005/12/03(土) 23:55:21 ]
- なんだかﾜｹﾜｶﾒ
本家本=GoFデザパタ本だよね？
- 55 名前：デフォルトの名無しさん mailto:sage [2005/12/03(土) 23:58:30 ]
- smalltalkの特徴って何？
何でもオブジェクトって言う思想はRubyと同じ思想？
- 56 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 00:19:08 ]
- >>53
ﾜﾛｽ
確かに臭うね
>>55
何でもオブジェクトって考えは近いとは思うよ。
ただ、Smalltalkは徹底的に何でもオブジェクト。
いわゆる制御文（if、whileやforのようなもの)も
各種オブジェクトのメッセージとして定義されてる。
Rubyもそうなのかな？（じぶんはRubyってそれほどしらない）
- 57 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 00:28:54 ]
- 「Smalltalkの思想がRubyの思想と同じ」
っていうのは順序がおかしいと思う
- 58 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 00:31:54 ]
- すべてのOOはSmalltalkよりはじまるか。
- 59 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 00:34:34 ]
- >>56
> いわゆる制御文（if、whileやforのようなもの)も
> 各種オブジェクトのメッセージとして定義されてる。
Rubyもそうだよ
ttp://ruby.mirror.easynet.be/ja/column/v0004.html
RubyはSmalltalkとPerlのハーフってことかな？
- 60 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 01:46:02 ]
- >>59
違う。Rubyは制御文はメッセージ送信ではない。
ifやwhileなどの制御文はCやPerlと同じモデル。
そのページは間違い。ifメッセージをなんのオブジェクトに送信しとるっちゅーねん。
- 61 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:25:19 ]
- Rubyの制御構造の一部は式ってのを勘違いしている？
- 62 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:27:01 ]
- だとしたら
4. 制御構造までオブジェクト
私はこれで乗り換えました。(ついに！)
ってのはかなり痛いんだけど、Rubyに詳しい人解説お願い。
- 63 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:29:25 ]
- >>61 勘違いしたかも。
>>62 どこらへんが？痛さの解説お願い。
- 64 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:45:17 ]
- 1円で海外旅行に行けますと勧誘されて入会金50万円払ってる感じが痛々しい
- 65 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:47:32 ]
- そうか？
void型メソッドをあえて自分への参照を返すようにしているコードって結構好きだし、痛さは感じないが。
- 66 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:51:47 ]
- 勘違いして乗り換えしてるのが痛いってだけ
しかも間違えた解説付きときている
言語構造云々について痛いとかは思わない
- 67 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 02:53:55 ]
- ああ、3項演算子がネストできないと思ってるところかｗ
- 68 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:18:19 ]
- ＞4. 制御構造までオブジェクト
これはオブジェクトではなく”式”の勘違いですね。
＞if 〜 end.tr("a-z", "A-Z")
この記述が勘違いを助長させた原因でしょう。
ifの結果としてオブジェクトが返却され、.tr〜はそのオブジェクトに
対しての操作だということをこの人は誤解しています。
Rubyの構文規則は柔軟に見えますが、こういった誤解を受ける問題があります。
- 69 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:27:51 ]
- イテレータブロックは？
- 70 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:28:13 ]
- だれかそこへメールを送ってみないか？
- 71 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:36:14 ]
- >>69
ありゃあ関数オブジェクトとかクロージャといった類のモノだよ。
起源はLISPのインライン関数とかSmalltalkのブロックだな。
Rubyは動的時にメソッド選択してるからトンデモ構文に見える。
- 72 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 11:36:38 ]
- s/動的時/動的/
な
- 73 名前：デフォルトの名無しさん mailto:sage [2005/12/04(日) 13:11:05 ]
- 全てが protected
- 74 名前：デフォルトの名無しさん [2005/12/11(日) 15:08:43 ]
- シーケンス図ってホントにプログラム知らないお偉いさんでも読めるの？
- 75 名前：デフォルトの名無しさん [2005/12/11(日) 15:21:18 ]
- >>74
プログラムｼﾗﾅｲお偉いさんにシーケンス図見せる時点で間違ってないか？
ユースケースとか配備図とかコラボレーション図とか…
- 76 名前：デフォルトの名無しさん [2005/12/11(日) 15:24:20 ]
- UMLの全てがユーザフレンドリーってわけではないのね
- 77 名前：デフォルトの名無しさん [2005/12/11(日) 15:26:46 ]
- >>76
えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。
- 78 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 15:27:29 ]
- じゃあ参考書の書き方がまずかったのかな
- 79 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 15:34:43 ]
- 書くレベル次第だな
厳密な設計書として書いているなら細かすぎて読めないかも
- 80 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 00:14:39 ]
- 日本語だらけの仕様書は曖昧さが目で見て取れるため問題に気づきやすいが
曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
- 81 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 20:59:11 ]
- いやいや、そんなレベルのUMLは仕様書としないでしょ。
あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ〜みたいに。
- 82 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 00:53:54 ]
- ＵＭＬでは、異常系の記述がやり辛いよな。
・・・はっ！！
- 83 名前：デフォルトの名無しさん [2005/12/17(土) 02:12:04 ]
- 会計ソフト作ってみたいんだが仕訳モデルのサンプルとか無い？
3級レベルで会計ソフトって作れるのかいな？まあそっちも勉強しながらやってきます
- 84 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:08:09 ]
- 自分で分析したら？
- 85 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 14:39:32 ]
- 言ってることはある意味正しいが
そういうレスはこのスレの役を果たさないな
- 86 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 15:51:23 ]
- javaでアプリ作ったんだけど、関連が全部双方向になったんだけど
これってやっぱ良くないの？
- 87 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 15:59:24 ]
- > 関連が全部双方向
ここがちょっとわからないが、まぁpublic全開になるのは仕方ないんじゃないかな。
コンポーネント郡はそのまま使わず、派生させてから使えば上手くカプセルにできるかもしれん。
- 88 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:00:18 ]
- まぁ、初心者にありがちなパターンだな。
関連というか、メッセージ送信が双方向になるなら、そのメッセージを一度整理して、分類して、
クラス内のメッセージ受信部分をインタフェースに分離するという観点で構築しなおしたらいいんじゃないの？
- 89 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:12:25 ]
- 実はFlashってのはOOPの訓練に役立つ。
- 90 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 16:53:09 ]
- >>87-88
ｻﾝｸｽｺ
そうです、メッセージ送信が双方向ってことでした。
そういえばインターフェースも抽象クラスも全く使ってない。
というか使いどころもわかんね。
とりあえずそれらの勉強してみます。
ありがとうございました
- 91 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 12:54:31 ]
- >>15
漏れは何も考えずにとりあえずメソッドはpublicにしてるんだけど…
内部からしか呼ばれないのはprotectedにしてる
まずいのか？
- 92 名前：デフォルトの名無しさん mailto:sage [2005/12/19(月) 16:18:57 ]
- >>91
いつの間にかぐちゃぐちゃなソースになるのが弊害かな。
- 93 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:10:39 ]
- アクセス権の指針
public：外から呼ぶ必要がある
protected：外から呼ぶ必要はないが派生クラスから呼ぶ必要がある
private：デフォルト
- 94 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 00:17:27 ]
- 下駄／雪駄なんて書く気しねー。
- 95 名前：デフォルトの名無しさん mailto:sage [2005/12/20(火) 01:25:22 ]
- 憂鬱本ではメソッドは基本的に全部publicで問題ないって書いてあったが
- 96 名前：デフォルトの名無しさん mailto:sage [2005/12/21(水) 16:07:20 ]
- >>95
その本は読んでないが、そこだけ聞いたら焚書モノだな。
- 97 名前：デフォルトの名無しさん mailto:sage [2005/12/22(木) 00:45:27 ]
- >>93
その判断を誤るとややこしいことになるからすべてpublicにしておけ
って程度なんだろうね、その本>>95
- 98 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 02:03:45 ]
- もともとC++やってて、最近仕事でjavaやり始めたんだけど、
javaのprotectedって全然プロテクトじゃないんだね
最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
アクセサメソッド追加してるんだけど、まずいですか？
まともなjava技術者ならどうしてます？
- 99 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 09:34:12 ]
- >>98
全然プロテクトじゃないってどういうこと？
- 100 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 10:50:46 ]
- >>98はC++もまともに使えていないと予想する。
- 101 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 11:18:14 ]
- packageの時の扱いが違うくらいしか思いつかないけど、なんかすごい引っ掛けがあるのかな・・？
- 102 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:01:36 ]
- >>98
早くプロテクトじゃない理由を教えてくれよう。ﾜｸﾜｸ
- 103 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:20:31 ]
- ＞最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
＞アクセサメソッド追加してるんだけど、まずいですか？
C++もそうだし、オブジェクト指向もわかってないんじゃないかな
なんか、Cプログラマーみたい
グローバル変数使うなっていわれたから、プライベートにしてみました
みんなが必要とするから悪切磋つけました
そんなところでしょ
- 104 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 12:45:22 ]
- Lispを使わないなんてバカげてる
- 105 名前：デフォルトの名無しさん [2005/12/23(金) 13:14:14 ]
- サブクラスのためにその都度スーパークラスを改変するのはナンセンス
まともなC++技術者ならそんなことやらない
まともなJava技術者もそんなことやらない
まともなSmalltalkerもそんなことやらない
まともなオブジェクト指向言語使用者ならそんなことやらない
- 106 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:10:15 ]
- まともな奴なら継承は使わないってことか
- 107 名前：98 mailto:sage [2005/12/23(金) 14:10:15 ]
- 自分はまともじゃないです（つд`）
プロテクトじゃない云々は、javaのprotectedメンバは派生クラスだけでなく
同じパッケージにいるクラスでもアクセスできるのでC++のより緩いって意味です。
親クラス作るときにはメンバ変数全部に対してprotectedのアクセサ用意しとくものなのかな、と。
で、こういう設計はおかしいですか？
- 108 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:12:55 ]
- 親クラスのメンバーにサブクラスがあとあといろいろアクセスしなきゃならなくなるかもぁー。
そういうときにpribvateだと、困るから、protectedにしておいたほうが、いいのかなぁ〜。
なんっていう、下らんこと気にしているようでは、そもそもクラス抽出がうまくできているとは思えない。
- 109 名前：デフォルトの名無しさん mailto:sage [2005/12/23(金) 14:15:50 ]
- >>106
サブクラスのためにその都度スーパークラスを改変する ってのがナンセンス。
継承前提で設計されたスーパークラスはそんな改変しょっちゅうしない。
- 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アクセサを…ってダメダメですよね。
設計が悪かったのが理解できました。みなさんありがとう
|
 |
