トップページ⇒tech
1001コメント438KB

-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
イテレータブロックは？
0070デフォルトの名無しさん2005/12/04(日) 11:28:13
だれかそこへメールを送ってみないか？
0071デフォルトの名無しさん2005/12/04(日) 11:36:14
>>69
ありゃあ関数オブジェクトとかクロージャといった類のモノだよ。
起源はLISPのインライン関数とかSmalltalkのブロックだな。
Rubyは動的時にメソッド選択してるからトンデモ構文に見える。
0072デフォルトの名無しさん2005/12/04(日) 11:36:38
s/動的時/動的/
な
0073デフォルトの名無しさん2005/12/04(日) 13:11:05
全てが protected
0074デフォルトの名無しさん2005/12/11(日) 15:08:43
シーケンス図ってホントにプログラム知らないお偉いさんでも読めるの？
0075デフォルトの名無しさん2005/12/11(日) 15:21:18
>>74
プログラムｼﾗﾅｲお偉いさんにシーケンス図見せる時点で間違ってないか？
ユースケースとか配備図とかコラボレーション図とか…
0076デフォルトの名無しさん2005/12/11(日) 15:24:20
UMLの全てがユーザフレンドリーってわけではないのね
0077デフォルトの名無しさん2005/12/11(日) 15:26:46
>>76
えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。

0078デフォルトの名無しさん2005/12/11(日) 15:27:29
じゃあ参考書の書き方がまずかったのかな
0079デフォルトの名無しさん2005/12/11(日) 15:34:43
書くレベル次第だな
厳密な設計書として書いているなら細かすぎて読めないかも
0080デフォルトの名無しさん2005/12/12(月) 00:14:39
日本語だらけの仕様書は曖昧さが目で見て取れるため問題に気づきやすいが
曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
0081デフォルトの名無しさん2005/12/12(月) 20:59:11
いやいや、そんなレベルのUMLは仕様書としないでしょ。
あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ〜みたいに。
0082デフォルトの名無しさん2005/12/13(火) 00:53:54
ＵＭＬでは、異常系の記述がやり辛いよな。

・・・はっ！！
0083デフォルトの名無しさん2005/12/17(土) 02:12:04
会計ソフト作ってみたいんだが仕訳モデルのサンプルとか無い？

3級レベルで会計ソフトって作れるのかいな？まあそっちも勉強しながらやってきます
0084デフォルトの名無しさん2005/12/17(土) 13:08:09
自分で分析したら？
0085デフォルトの名無しさん2005/12/17(土) 14:39:32
言ってることはある意味正しいが
そういうレスはこのスレの役を果たさないな
0086デフォルトの名無しさん2005/12/17(土) 15:51:23
javaでアプリ作ったんだけど、関連が全部双方向になったんだけど
これってやっぱ良くないの？
0087デフォルトの名無しさん2005/12/17(土) 15:59:24
> 関連が全部双方向
ここがちょっとわからないが、まぁpublic全開になるのは仕方ないんじゃないかな。
コンポーネント郡はそのまま使わず、派生させてから使えば上手くカプセルにできるかもしれん。
0088デフォルトの名無しさん2005/12/17(土) 16:00:18
まぁ、初心者にありがちなパターンだな。
関連というか、メッセージ送信が双方向になるなら、そのメッセージを一度整理して、分類して、
クラス内のメッセージ受信部分をインタフェースに分離するという観点で構築しなおしたらいいんじゃないの？
0089デフォルトの名無しさん2005/12/17(土) 16:12:25
実はFlashってのはOOPの訓練に役立つ。
0090デフォルトの名無しさん2005/12/17(土) 16:53:09
>>87-88
ｻﾝｸｽｺ
そうです、メッセージ送信が双方向ってことでした。
そういえばインターフェースも抽象クラスも全く使ってない。
というか使いどころもわかんね。
とりあえずそれらの勉強してみます。
ありがとうございました
0091デフォルトの名無しさん2005/12/19(月) 12:54:31
>>15
漏れは何も考えずにとりあえずメソッドはpublicにしてるんだけど…
内部からしか呼ばれないのはprotectedにしてる
まずいのか？
0092デフォルトの名無しさん2005/12/19(月) 16:18:57
>>91
いつの間にかぐちゃぐちゃなソースになるのが弊害かな。
0093デフォルトの名無しさん2005/12/20(火) 00:10:39
アクセス権の指針
public：外から呼ぶ必要がある
protected：外から呼ぶ必要はないが派生クラスから呼ぶ必要がある
private：デフォルト
0094デフォルトの名無しさん2005/12/20(火) 00:17:27
下駄／雪駄なんて書く気しねー。
0095デフォルトの名無しさん2005/12/20(火) 01:25:22
憂鬱本ではメソッドは基本的に全部publicで問題ないって書いてあったが
0096デフォルトの名無しさん2005/12/21(水) 16:07:20
>>95
その本は読んでないが、そこだけ聞いたら焚書モノだな。
0097デフォルトの名無しさん2005/12/22(木) 00:45:27
>>93
その判断を誤るとややこしいことになるからすべてpublicにしておけ
って程度なんだろうね、その本>>95
0098デフォルトの名無しさん2005/12/23(金) 02:03:45
もともとC++やってて、最近仕事でjavaやり始めたんだけど、
javaのprotectedって全然プロテクトじゃないんだね
最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
アクセサメソッド追加してるんだけど、まずいですか？
まともなjava技術者ならどうしてます？
0099デフォルトの名無しさん2005/12/23(金) 09:34:12
>>98
全然プロテクトじゃないってどういうこと？
0100デフォルトの名無しさん2005/12/23(金) 10:50:46
>>98はC++もまともに使えていないと予想する。
0101デフォルトの名無しさん2005/12/23(金) 11:18:14
packageの時の扱いが違うくらいしか思いつかないけど、なんかすごい引っ掛けがあるのかな・・？
■ このスレッドは過去ログ倉庫に格納されています