-OOP限定-プログラム設計相談室
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/09/24(土) 16:35:590002デフォルトの名無しさん
2005/09/24(土) 16:40:140003デフォルトの名無しさん
2005/09/24(土) 16:42:25(ω・ )ゝ < なんだって?
ノ/ / \_____
ノ ̄ゝ
0004デフォルトの名無しさん
2005/09/24(土) 16:42:290005デフォルトの名無しさん
2005/09/24(土) 16:48:110006デフォルトの名無しさん
2005/09/24(土) 16:49:03(ω・ )ゝ < なんだって?
ノ/ / \_____
ノ ̄ゝ
0007デフォルトの名無しさん
2005/09/24(土) 16:51:04Java屋やC屋が入り混じると煽りが入りえるので住み分けしました。
OOP限定はスレの利便性のためとお考えください。
0008デフォルトの名無しさん
2005/09/24(土) 16:51:41無料では教えてあげません
0009デフォルトの名無しさん
2005/09/24(土) 16:53:120010デフォルトの名無しさん
2005/09/24(土) 16:54:330011デフォルトの名無しさん
2005/09/24(土) 16:59:33Java(OOP)とC(構造化)の煽りあいという意味です。
0012デフォルトの名無しさん
2005/09/24(土) 17:02:54とあるメインループを持つController部を切り替えても
Model, Viewは同じものを使う手法を考えています。
この場合メインControllerを切り替える為のControllerを
それらの最上位に実装するのは正しい設計でしょうか?
ControllerController
├Model
├View
└Controller
この図の場合だとControllerがControllerControllerに
自身をあのControllerに切り替えてと頼む形になります。
ControllerControllerは切り替え処理以外の機能は持ちません。
0013デフォルトの名無しさん
2005/09/24(土) 17:04:260014デフォルトの名無しさん
2005/09/24(土) 17:06:21どのパターンですか?
0015デフォルトの名無しさん
2005/09/24(土) 17:19:15他は全部publicなメソッドってのがあった。
0016デフォルトの名無しさん
2005/09/24(土) 17:32:510017デフォルトの名無しさん
2005/09/24(土) 17:53:32コボラーの仕業だな。
最近、似たようなモンみたよ。
0018デフォルトの名無しさん
2005/09/24(土) 18:53:42はやくはやく
0019デフォルトの名無しさん
2005/09/25(日) 02:43:03youzyoパターン
0020マイク ◆yrBrqfF1Ew
2005/09/25(日) 03:53:27使いやすくない。
0021デフォルトの名無しさん
2005/09/25(日) 12:58:570022デフォルトの名無しさん
2005/10/02(日) 00:11:03委譲じゃないよな?
0023デフォルトの名無しさん
2005/10/02(日) 01:11:15基地外スレ
=====
0024デフォルトの名無しさん
2005/10/02(日) 21:44:300025デフォルトの名無しさん
2005/10/21(金) 18:16:26というか>>21が何気に至言だ
って、なんだ最後の発言が3週間くらい前か
0026デフォルトの名無しさん
2005/10/23(日) 21:34:16SQLにマッピングするためのゲッタくらいが限界じゃないかな
0027デフォルトの名無しさん
2005/10/23(日) 23:20:230028デフォルトの名無しさん
2005/11/04(金) 15:47:550029デフォルトの名無しさん
2005/11/05(土) 00:29:38実際仕事で汲んでも使う機会無い気がする。
せーぜーシングルトンがあぶ工場くらい。
0030デフォルトの名無しさん
2005/11/06(日) 01:10:50それをDBから引っこ抜いてくるように出来たら面白いのにな
プログラムとはそれすなわちアルゴリズムって証明できる
0031デフォルトの名無しさん
2005/11/06(日) 01:12:440032デフォルトの名無しさん
2005/11/06(日) 01:14:59ソートとかコレクションとかOOPならどれでも共通化できそうなものを纏めて欲しい。
0033デフォルトの名無しさん
2005/11/06(日) 01:15:49それとOOPが、どう関係するの?
0034デフォルトの名無しさん
2005/11/06(日) 02:27:39漏れはComposite使いまくりんぐ
0035デフォルトの名無しさん
2005/11/06(日) 18:33:290036デフォルトの名無しさん
2005/11/06(日) 18:54:420037デフォルトの名無しさん
2005/12/02(金) 21:54:290038デフォルトの名無しさん
2005/12/02(金) 22:16:430039デフォルトの名無しさん
2005/12/03(土) 00:56:100040デフォルトの名無しさん
2005/12/03(土) 01:05:30アルベルト・プロモーテッド・プラゲラメ
0041デフォルトの名無しさん
2005/12/03(土) 01:10:270042デフォルトの名無しさん
2005/12/03(土) 01:19:540043デフォルトの名無しさん
2005/12/03(土) 21:15:04public 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);
}
}
0044デフォルトの名無しさん
2005/12/03(土) 22:02:47./のパクリはいりません
0045デフォルトの名無しさん
2005/12/03(土) 22:07:590046デフォルトの名無しさん
2005/12/03(土) 22:36:16GRASPやJ2EEパターンが有名どころか?
0047デフォルトの名無しさん
2005/12/03(土) 23:31:490048デフォルトの名無しさん
2005/12/03(土) 23:36:28エー!!!
本家本はC++のはずだが。
0049デフォルトの名無しさん
2005/12/03(土) 23:38:490050デフォルトの名無しさん
2005/12/03(土) 23:42:47はいってちゃまずいのか?
0051デフォルトの名無しさん
2005/12/03(土) 23:43:570052デフォルトの名無しさん
2005/12/03(土) 23:54:19でもC++が多いから>>48みたいな反応でもあながち間違えではないと思う。
そんなわけで、Smalltalkに特化したThe Design Patterns Smalltalk Companionがわけだし。
0053デフォルトの名無しさん
2005/12/03(土) 23:55:100054デフォルトの名無しさん
2005/12/03(土) 23:55:21本家本=GoFデザパタ本だよね?
0055デフォルトの名無しさん
2005/12/03(土) 23:58:30何でもオブジェクトって言う思想はRubyと同じ思想?
0056デフォルトの名無しさん
2005/12/04(日) 00:19:08ワロス
確かに臭うね
>>55
何でもオブジェクトって考えは近いとは思うよ。
ただ、Smalltalkは徹底的に何でもオブジェクト。
いわゆる制御文(if、whileやforのようなもの)も
各種オブジェクトのメッセージとして定義されてる。
Rubyもそうなのかな?(じぶんはRubyってそれほどしらない)
0057デフォルトの名無しさん
2005/12/04(日) 00:28:54っていうのは順序がおかしいと思う
0058デフォルトの名無しさん
2005/12/04(日) 00:31:540059デフォルトの名無しさん
2005/12/04(日) 00:34:34> いわゆる制御文(if、whileやforのようなもの)も
> 各種オブジェクトのメッセージとして定義されてる。
Rubyもそうだよ
ttp://ruby.mirror.easynet.be/ja/column/v0004.html
RubyはSmalltalkとPerlのハーフってことかな?
0060デフォルトの名無しさん
2005/12/04(日) 01:46:02違う。Rubyは制御文はメッセージ送信ではない。
ifやwhileなどの制御文はCやPerlと同じモデル。
そのページは間違い。ifメッセージをなんのオブジェクトに送信しとるっちゅーねん。
0061デフォルトの名無しさん
2005/12/04(日) 02:25:190062デフォルトの名無しさん
2005/12/04(日) 02:27:014. 制御構造までオブジェクト
私はこれで乗り換えました。(ついに!)
ってのはかなり痛いんだけど、Rubyに詳しい人解説お願い。
0063デフォルトの名無しさん
2005/12/04(日) 02:29:25>>62 どこらへんが?痛さの解説お願い。
0064デフォルトの名無しさん
2005/12/04(日) 02:45:170065デフォルトの名無しさん
2005/12/04(日) 02:47:32void型メソッドをあえて自分への参照を返すようにしているコードって結構好きだし、痛さは感じないが。
0066デフォルトの名無しさん
2005/12/04(日) 02:51:47しかも間違えた解説付きときている
言語構造云々について痛いとかは思わない
0067デフォルトの名無しさん
2005/12/04(日) 02:53:550068デフォルトの名無しさん
2005/12/04(日) 11:18:19これはオブジェクトではなく”式”の勘違いですね。
>if 〜 end.tr("a-z", "A-Z")
この記述が勘違いを助長させた原因でしょう。
ifの結果としてオブジェクトが返却され、.tr〜はそのオブジェクトに
対しての操作だということをこの人は誤解しています。
Rubyの構文規則は柔軟に見えますが、こういった誤解を受ける問題があります。
0069デフォルトの名無しさん
2005/12/04(日) 11:27:510070デフォルトの名無しさん
2005/12/04(日) 11:28:130071デフォルトの名無しさん
2005/12/04(日) 11:36:14ありゃあ関数オブジェクトとかクロージャといった類のモノだよ。
起源はLISPのインライン関数とかSmalltalkのブロックだな。
Rubyは動的時にメソッド選択してるからトンデモ構文に見える。
0072デフォルトの名無しさん
2005/12/04(日) 11:36:38な
0073デフォルトの名無しさん
2005/12/04(日) 13:11:050074デフォルトの名無しさん
2005/12/11(日) 15:08:430075デフォルトの名無しさん
2005/12/11(日) 15:21:18プログラムシラナイお偉いさんにシーケンス図見せる時点で間違ってないか?
ユースケースとか配備図とかコラボレーション図とか…
0076デフォルトの名無しさん
2005/12/11(日) 15:24:200077デフォルトの名無しさん
2005/12/11(日) 15:26:46えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。
0078デフォルトの名無しさん
2005/12/11(日) 15:27:290079デフォルトの名無しさん
2005/12/11(日) 15:34:43厳密な設計書として書いているなら細かすぎて読めないかも
0080デフォルトの名無しさん
2005/12/12(月) 00:14:39曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
0081デフォルトの名無しさん
2005/12/12(月) 20:59:11あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ〜みたいに。
0082デフォルトの名無しさん
2005/12/13(火) 00:53:54・・・はっ!!
0083デフォルトの名無しさん
2005/12/17(土) 02:12:043級レベルで会計ソフトって作れるのかいな?まあそっちも勉強しながらやってきます
■ このスレッドは過去ログ倉庫に格納されています