-OOP限定-プログラム設計相談室

0001デフォルトの名無しさん

2005/09/24(土) 16:35:59

全部publicでいいじゃん！ってならないようにするスレです。

0002デフォルトの名無しさん

2005/09/24(土) 16:40:14

2

0003デフォルトの名無しさん

2005/09/24(土) 16:42:25

　　　∧_∧　　　　／￣￣￣￣￣
　　 (ω・　)ゝ　＜　なんだって？
　ノ/　 /　　　　　＼＿＿＿＿＿
　　ノ￣ゝ

0004デフォルトの名無しさん

2005/09/24(土) 16:42:29

全部public と OOP限定の関連がわかりません

0005デフォルトの名無しさん

2005/09/24(土) 16:48:11

双方向関連です

0006デフォルトの名無しさん

2005/09/24(土) 16:49:03

　　　∧_∧　　　　／￣￣￣￣￣
　　 (ω・　)ゝ　＜　なんだって？
　ノ/　 /　　　　　＼＿＿＿＿＿
　　ノ￣ゝ

0007デフォルトの名無しさん

2005/09/24(土) 16:51:04

>>4
Java屋やC屋が入り混じると煽りが入りえるので住み分けしました。
OOP限定はスレの利便性のためとお考えください。

0008デフォルトの名無しさん

2005/09/24(土) 16:51:41

オープンソース全盛の今設計手法で商売する時代になったので、
無料では教えてあげません

0009デフォルトの名無しさん

2005/09/24(土) 16:53:12

へー、javaってOOPLじゃなかったんだ

0010デフォルトの名無しさん

2005/09/24(土) 16:54:33

新しいSmalltalkスレはここですか？

0011デフォルトの名無しさん

2005/09/24(土) 16:59:33

>>9
Java(OOP)とC(構造化)の煽りあいという意味です。

0012デフォルトの名無しさん

2005/09/24(土) 17:02:54

MVCを意識してライブラリを設計しているのですが
とあるメインループを持つController部を切り替えても
Model, Viewは同じものを使う手法を考えています。

この場合メインControllerを切り替える為のControllerを
それらの最上位に実装するのは正しい設計でしょうか？

ControllerController
├Model
├View
└Controller

この図の場合だとControllerがControllerControllerに
自身をあのControllerに切り替えてと頼む形になります。
ControllerControllerは切り替え処理以外の機能は持ちません。

0013デフォルトの名無しさん

2005/09/24(土) 17:04:26

デザパタ勉強してください

0014デフォルトの名無しさん

2005/09/24(土) 17:06:21

>>13
どのパターンですか？

0015デフォルトの名無しさん

2005/09/24(土) 17:19:15

全部publicではないが、数千行あるクラスでprivateなメソッドが1個だけで、
他は全部publicなメソッドってのがあった。

0016デフォルトの名無しさん

2005/09/24(土) 17:32:51

CLOS最強!!

0017デフォルトの名無しさん

2005/09/24(土) 17:53:32

>>15
コボラーの仕業だな。
最近、似たようなモンみたよ。

0018デフォルトの名無しさん

2005/09/24(土) 18:53:42

>>13
はやくはやく

0019デフォルトの名無しさん

2005/09/25(日) 02:43:03

>>14
youzyoパターン

0020マイク ◆yrBrqfF1Ew

2005/09/25(日) 03:53:27

MVCウザイな。
使いやすくない。

0021デフォルトの名無しさん

2005/09/25(日) 12:58:57

MVCはCが如何に無理をするかが焦点だな

0022デフォルトの名無しさん

2005/10/02(日) 00:11:03

youzyoパターンってなんぞ？
委譲じゃないよな？

0023デフォルトの名無しさん

2005/10/02(日) 01:11:15

＝＝＝＝＝
基地外スレ
＝＝＝＝＝

0024デフォルトの名無しさん

2005/10/02(日) 21:44:30

gofのすとらてじい？

0025デフォルトの名無しさん

2005/10/21(金) 18:16:26

Mのクラスが、VやCのクラスを引数にとったり、内包したら設計ミスかな？
というか>>21が何気に至言だ

って、なんだ最後の発言が3週間くらい前か

0026デフォルトの名無しさん

2005/10/23(日) 21:34:16

Mって早い話が構造体クラスでしょ？
SQLにマッピングするためのゲッタくらいが限界じゃないかな

0027デフォルトの名無しさん

2005/10/23(日) 23:20:23

それはＣクラスでやりたいな・・・

0028デフォルトの名無しさん

2005/11/04(金) 15:47:55

デザパタは１０回同じのを使うとわかった気になるなあ、おい。

0029デフォルトの名無しさん

2005/11/05(土) 00:29:38

デザパタはOOPをプロでやってく上での教養なのかねぇ
実際仕事で汲んでも使う機会無い気がする。
せーぜーシングルトンがあぶ工場くらい。

0030デフォルトの名無しさん

2005/11/06(日) 01:10:50

OOPのアルゴリズムテンプレートがあって
それをDBから引っこ抜いてくるように出来たら面白いのにな
プログラムとはそれすなわちアルゴリズムって証明できる

0031デフォルトの名無しさん

2005/11/06(日) 01:12:44

アルゴリズムテンプレートってなに？

0032デフォルトの名無しさん

2005/11/06(日) 01:14:59

機能じゃないよ。言葉そのままの意味。
ソートとかコレクションとかOOPならどれでも共通化できそうなものを纏めて欲しい。

0033デフォルトの名無しさん

2005/11/06(日) 01:15:49

>>32
それとOOPが、どう関係するの？

0034デフォルトの名無しさん

2005/11/06(日) 02:27:39

>>29
漏れはComposite使いまくりんぐ

0035デフォルトの名無しさん

2005/11/06(日) 18:33:29

だいたいだなぁ、OOP限定なら「プログラム設計」じゃなくっ「てクラス設計」ではないのか？

0036デフォルトの名無しさん

2005/11/06(日) 18:54:42

てクラス設計

0037デフォルトの名無しさん

2005/12/02(金) 21:54:29

AOPって何ですか？

0038デフォルトの名無しさん

2005/12/02(金) 22:16:43

エージェント？

0039デフォルトの名無しさん

2005/12/03(土) 00:56:10

スミス？

0040デフォルトの名無しさん

2005/12/03(土) 01:05:30

>>37
アルベルト・プロモーテッド・プラゲラメ

0041デフォルトの名無しさん

2005/12/03(土) 01:10:27

Oがないじゃん

0042デフォルトの名無しさん

2005/12/03(土) 01:19:54

23のパターンを用いてHelloWorldを実装してください。

0043デフォルトの名無しさん

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);
　}
}

0044デフォルトの名無しさん

2005/12/03(土) 22:02:47

>>43
./のパクリはいりません

0045デフォルトの名無しさん

2005/12/03(土) 22:07:59

GoF以外のデザパタ集で有名どころってある？

0046デフォルトの名無しさん

2005/12/03(土) 22:36:16

マルチスレッドのデザインパターンやら、
GRASPやJ2EEパターンが有名どころか？

0047デフォルトの名無しさん

2005/12/03(土) 23:31:49

C++でか書かれてるデザパタ参考本ってないよね

0048デフォルトの名無しさん

2005/12/03(土) 23:36:28

>>47
ｴｰ!!!
本家本はC++のはずだが。

0049デフォルトの名無しさん

2005/12/03(土) 23:38:49

smelltalkもはいってんじゃん。＞本家

0050デフォルトの名無しさん

2005/12/03(土) 23:42:47

>>49
はいってちゃまずいのか？

0051デフォルトの名無しさん

2005/12/03(土) 23:43:57

smalltalkは本家じゃん。本家が本家を扱って何が悪い。

0052デフォルトの名無しさん

2005/12/03(土) 23:54:19

本家本は確かにSmalltalkとC++だな。
でもC++が多いから>>48みたいな反応でもあながち間違えではないと思う。
そんなわけで、Smalltalkに特化したThe Design Patterns Smalltalk Companionがわけだし。

0053デフォルトの名無しさん

2005/12/03(土) 23:55:10

smelltalk

0054デフォルトの名無しさん

2005/12/03(土) 23:55:21

なんだかﾜｹﾜｶﾒ

本家本=GoFデザパタ本だよね？

0055デフォルトの名無しさん

2005/12/03(土) 23:58:30

smalltalkの特徴って何？
何でもオブジェクトって言う思想はRubyと同じ思想？

0056デフォルトの名無しさん

2005/12/04(日) 00:19:08

>>53
ﾜﾛｽ
確かに臭うね

>>55
何でもオブジェクトって考えは近いとは思うよ。
ただ、Smalltalkは徹底的に何でもオブジェクト。
いわゆる制御文（if、whileやforのようなもの)も
各種オブジェクトのメッセージとして定義されてる。
Rubyもそうなのかな？（じぶんはRubyってそれほどしらない）

0057デフォルトの名無しさん

2005/12/04(日) 00:28:54

「Smalltalkの思想がRubyの思想と同じ」

っていうのは順序がおかしいと思う

0058デフォルトの名無しさん

2005/12/04(日) 00:31:54

すべてのOOはSmalltalkよりはじまるか。

0059デフォルトの名無しさん

2005/12/04(日) 00:34:34

>>56
> いわゆる制御文（if、whileやforのようなもの)も
> 各種オブジェクトのメッセージとして定義されてる。

Rubyもそうだよ
ttp://ruby.mirror.easynet.be/ja/column/v0004.html

RubyはSmalltalkとPerlのハーフってことかな？

0060デフォルトの名無しさん

2005/12/04(日) 01:46:02

>>59
違う。Rubyは制御文はメッセージ送信ではない。
ifやwhileなどの制御文はCやPerlと同じモデル。

そのページは間違い。ifメッセージをなんのオブジェクトに送信しとるっちゅーねん。

0061デフォルトの名無しさん

2005/12/04(日) 02:25:19

Rubyの制御構造の一部は式ってのを勘違いしている？

0062デフォルトの名無しさん

2005/12/04(日) 02:27:01

だとしたら

4. 制御構造までオブジェクト
私はこれで乗り換えました。(ついに！)

ってのはかなり痛いんだけど、Rubyに詳しい人解説お願い。

0063デフォルトの名無しさん

2005/12/04(日) 02:29:25

>>61　勘違いしたかも。
>>62　どこらへんが？痛さの解説お願い。

0064デフォルトの名無しさん

2005/12/04(日) 02:45:17

1円で海外旅行に行けますと勧誘されて入会金50万円払ってる感じが痛々しい

0065デフォルトの名無しさん

2005/12/04(日) 02:47:32

そうか？

void型メソッドをあえて自分への参照を返すようにしているコードって結構好きだし、痛さは感じないが。

0066デフォルトの名無しさん

2005/12/04(日) 02:51:47

勘違いして乗り換えしてるのが痛いってだけ
しかも間違えた解説付きときている

言語構造云々について痛いとかは思わない

0067デフォルトの名無しさん

2005/12/04(日) 02:53:55

ああ、3項演算子がネストできないと思ってるところかｗ

0068デフォルトの名無しさん

2005/12/04(日) 11:18:19

＞4. 制御構造までオブジェクト

これはオブジェクトではなく”式”の勘違いですね。

＞if ～ end.tr("a-z", "A-Z")

この記述が勘違いを助長させた原因でしょう。
ifの結果としてオブジェクトが返却され、.tr～はそのオブジェクトに
対しての操作だということをこの人は誤解しています。
Rubyの構文規則は柔軟に見えますが、こういった誤解を受ける問題があります。

0069デフォルトの名無しさん

2005/12/04(日) 11:27:51

イテレータブロックは？