1read 100read
2012年6月プログラム8: -OOP限定-プログラム設計相談室 (842)
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▼
Androidアプリ制作依頼スレ (348)
どうせ暇だしFirefoxのアドオン作るわ (482)
プログラムできないやつが適当に話を合わせるスレ (753)
MFC、Win32++を超えるライブラリを作るスレ (907)
ファイルの重複検出ツールを作ろうぜ (340)
【PureVideo】DirectX Video Acceleration【AVIVO】 (219)
-OOP限定-プログラム設計相談室
- 1 :05/09/24 〜 最終レス :12/07/05
- 全部publicでいいじゃん!ってならないようにするスレです。
- 2 :
- 2
- 3 :
- ∧_∧ / ̄ ̄ ̄ ̄ ̄
(ω・ )ゝ < なんだって?
ノ/ / \_____
ノ ̄ゝ
- 4 :
- 全部public と OOP限定 の関連がわかりません
- 5 :
- 双方向関連です
- 6 :
- ∧_∧ / ̄ ̄ ̄ ̄ ̄
(ω・ )ゝ < なんだって?
ノ/ / \_____
ノ ̄ゝ
- 7 :
- >>4
Java屋やC屋が入り混じると煽りが入りえるので住み分けしました。
OOP限定はスレの利便性のためとお考えください。
- 8 :
- オープンソース全盛の今設計手法で商売する時代になったので、
無料では教えてあげません
- 9 :
- へー、javaってOOPLじゃなかったんだ
- 10 :
- 新しいSmalltalkスレはここですか?
- 11 :
- >>9
Java(OOP)とC(構造化)の煽りあいという意味です。
- 12 :
- MVCを意識してライブラリを設計しているのですが
とあるメインループを持つController部を切り替えても
Model, Viewは同じものを使う手法を考えています。
この場合メインControllerを切り替える為のControllerを
それらの最上位に実装するのは正しい設計でしょうか?
ControllerController
├Model
├View
└Controller
この図の場合だとControllerがControllerControllerに
自身をあのControllerに切り替えてと頼む形になります。
ControllerControllerは切り替え処理以外の機能は持ちません。
- 13 :
- デザパタ勉強してください
- 14 :
- >>13
どのパターンですか?
- 15 :
- 全部publicではないが、数千行あるクラスでprivateなメソッドが1個だけで、
他は全部publicなメソッドってのがあった。
- 16 :
- CLOS最強!!
- 17 :
- >>15
コボラーの仕業だな。
最近、似たようなモンみたよ。
- 18 :
- >>13
はやくはやく
- 19 :
- >>14
youzyoパターン
- 20 :
- MVCウザイな。
使いやすくない。
- 21 :
- MVCはCが如何に無理をするかが焦点だな
- 22 :
- youzyoパターンってなんぞ?
委譲じゃないよな?
- 23 :
- =====
基地外スレ
=====
- 24 :
- gofのすとらてじい?
- 25 :
- Mのクラスが、VやCのクラスを引数にとったり、内包したら設計ミスかな?
というか>>21が何気に至言だ
って、なんだ最後の発言が3週間くらい前か
- 26 :
- Mって早い話が構造体クラスでしょ?
SQLにマッピングするためのゲッタくらいが限界じゃないかな
- 27 :
- それはCクラスでやりたいな・・・
- 28 :
- デザパタは10回同じのを使うとわかった気になるなあ、おい。
- 29 :
- デザパタはOOPをプロでやってく上での教養なのかねぇ
実際仕事で汲んでも使う機会無い気がする。
せーぜーシングルトンがあぶ工場くらい。
- 30 :
- OOPのアルゴリズムテンプレートがあって
それをDBから引っこ抜いてくるように出来たら面白いのにな
プログラムとはそれすなわちアルゴリズムって証明できる
- 31 :
- アルゴリズムテンプレートってなに?
- 32 :
- 機能じゃないよ。言葉そのままの意味。
ソートとかコレクションとかOOPならどれでも共通化できそうなものを纏めて欲しい。
- 33 :
- >>32
それとOOPが、どう関係するの?
- 34 :
- >>29
漏れはComposite使いまくりんぐ
- 35 :
- だいたいだなぁ、OOP限定なら「プログラム設計」じゃなくっ「てクラス設計」ではないのか?
- 36 :
- てクラス設計
- 37 :
- AOPって何ですか?
- 38 :
- エージェント?
- 39 :
- スミス?
- 40 :
- >>37
アルベルト・プロモーテッド・プラゲラメ
- 41 :
- Oがないじゃん
- 42 :
- 23のパターンを用いてHelloWorldを実装してください。
- 43 :
- 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 :
- >>43
./のパクリはいりません
- 45 :
- GoF以外のデザパタ集で有名どころってある?
- 46 :
- マルチスレッドのデザインパターンやら、
GRASPやJ2EEパターンが有名どころか?
- 47 :
- C++でか書かれてるデザパタ参考本ってないよね
- 48 :
- >>47
エー!!!
本家本はC++のはずだが。
- 49 :
- smelltalkもはいってんじゃん。>本家
- 50 :
- >>49
はいってちゃまずいのか?
- 51 :
- smalltalkは本家じゃん。本家が本家を扱って何が悪い。
- 52 :
- 本家本は確かにSmalltalkとC++だな。
でもC++が多いから>>48みたいな反応でもあながち間違えではないと思う。
そんなわけで、Smalltalkに特化したThe Design Patterns Smalltalk Companionがわけだし。
- 53 :
- smelltalk
- 54 :
- なんだかワケワカメ
本家本=GoFデザパタ本だよね?
- 55 :
- smalltalkの特徴って何?
何でもオブジェクトって言う思想はRubyと同じ思想?
- 56 :
- >>53
ワロス
確かに臭うね
>>55
何でもオブジェクトって考えは近いとは思うよ。
ただ、Smalltalkは徹底的に何でもオブジェクト。
いわゆる制御文(if、whileやforのようなもの)も
各種オブジェクトのメッセージとして定義されてる。
Rubyもそうなのかな?(じぶんはRubyってそれほどしらない)
- 57 :
- 「Smalltalkの思想がRubyの思想と同じ」
っていうのは順序がおかしいと思う
- 58 :
- すべてのOOはSmalltalkよりはじまるか。
- 59 :
- >>56
> いわゆる制御文(if、whileやforのようなもの)も
> 各種オブジェクトのメッセージとして定義されてる。
Rubyもそうだよ
ttp://ruby.mirror.easynet.be/ja/column/v0004.html
RubyはSmalltalkとPerlのハーフってことかな?
- 60 :
- >>59
違う。Rubyは制御文はメッセージ送信ではない。
ifやwhileなどの制御文はCやPerlと同じモデル。
そのページは間違い。ifメッセージをなんのオブジェクトに送信しとるっちゅーねん。
- 61 :
- Rubyの制御構造の一部は式ってのを勘違いしている?
- 62 :
- だとしたら
4. 制御構造までオブジェクト
私はこれで乗り換えました。(ついに!)
ってのはかなり痛いんだけど、Rubyに詳しい人解説お願い。
- 63 :
- >>61 勘違いしたかも。
>>62 どこらへんが?痛さの解説お願い。
- 64 :
- 1円で海外旅行に行けますと勧誘されて入会金50万円払ってる感じが痛々しい
- 65 :
- そうか?
void型メソッドをあえて自分への参照を返すようにしているコードって結構好きだし、痛さは感じないが。
- 66 :
- 勘違いして乗り換えしてるのが痛いってだけ
しかも間違えた解説付きときている
言語構造云々について痛いとかは思わない
- 67 :
- ああ、3項演算子がネストできないと思ってるところかw
- 68 :
- >4. 制御構造までオブジェクト
これはオブジェクトではなく”式”の勘違いですね。
>if 〜 end.tr("a-z", "A-Z")
この記述が勘違いを助長させた原因でしょう。
ifの結果としてオブジェクトが返却され、.tr〜はそのオブジェクトに
対しての操作だということをこの人は誤解しています。
Rubyの構文規則は柔軟に見えますが、こういった誤解を受ける問題があります。
- 69 :
- イテレータブロックは?
- 70 :
- だれかそこへメールを送ってみないか?
- 71 :
- >>69
ありゃあ関数オブジェクトとかクロージャといった類のモノだよ。
起源はLISPのインライン関数とかSmalltalkのブロックだな。
Rubyは動的時にメソッド選択してるからトンデモ構文に見える。
- 72 :
- s/動的時/動的/
な
- 73 :
- 全てが protected
- 74 :
- シーケンス図ってホントにプログラム知らないお偉いさんでも読めるの?
- 75 :
- >>74
プログラムシラナイお偉いさんにシーケンス図見せる時点で間違ってないか?
ユースケースとか配備図とかコラボレーション図とか…
- 76 :
- UMLの全てがユーザフレンドリーってわけではないのね
- 77 :
- >>76
えーと、UMLって単に開発で使う図に統一規格を持ち込んだだけの
話で、それ以上のものじゃないですよ。
- 78 :
- じゃあ参考書の書き方がまずかったのかな
- 79 :
- 書くレベル次第だな
厳密な設計書として書いているなら細かすぎて読めないかも
- 80 :
- 日本語だらけの仕様書は曖昧さが目で見て取れるため問題に気づきやすいが
曖昧なまま書き起こされたUMLは、一見する分には完全な仕様書に見えるため問題が分かりにくい。
UMLが客が読める仕様書としてしまうのはある意味とても危険。
- 81 :
- いやいや、そんなレベルのUMLは仕様書としないでしょ。
あくまでコミュニケーションツールの一つ。
処理の流れはこんな感じですよ〜みたいに。
- 82 :
- UMLでは、異常系の記述がやり辛いよな。
・・・はっ!!
- 83 :
- 会計ソフト作ってみたいんだが仕訳モデルのサンプルとか無い?
3級レベルで会計ソフトって作れるのかいな?まあそっちも勉強しながらやってきます
- 84 :
- 自分で分析したら?
- 85 :
- 言ってることはある意味正しいが
そういうレスはこのスレの役を果たさないな
- 86 :
- javaでアプリ作ったんだけど、関連が全部双方向になったんだけど
これってやっぱ良くないの?
- 87 :
- > 関連が全部双方向
ここがちょっとわからないが、まぁpublic全開になるのは仕方ないんじゃないかな。
コンポーネント郡はそのまま使わず、派生させてから使えば上手くカプセルにできるかもしれん。
- 88 :
- まぁ、初心者にありがちなパターンだな。
関連というか、メッセージ送信が双方向になるなら、そのメッセージを一度整理して、分類して、
クラス内のメッセージ受信部分をインタフェースに分離するという観点で構築しなおしたらいいんじゃないの?
- 89 :
- 実はFlashってのはOOPの訓練に役立つ。
- 90 :
- >>87-88
サンクスコ
そうです、メッセージ送信が双方向ってことでした。
そういえばインターフェースも抽象クラスも全く使ってない。
というか使いどころもわかんね。
とりあえずそれらの勉強してみます。
ありがとうございました
- 91 :
- >>15
漏れは何も考えずにとりあえずメソッドはpublicにしてるんだけど…
内部からしか呼ばれないのはprotectedにしてる
まずいのか?
- 92 :
- >>91
いつの間にかぐちゃぐちゃなソースになるのが弊害かな。
- 93 :
- アクセス権の指針
public:外から呼ぶ必要がある
protected:外から呼ぶ必要はないが派生クラスから呼ぶ必要がある
private:デフォルト
- 94 :
- 下駄/雪駄なんて書く気しねー。
- 95 :
- 憂鬱本ではメソッドは基本的に全部publicで問題ないって書いてあったが
- 96 :
- >>95
その本は読んでないが、そこだけ聞いたら焚書モノだな。
- 97 :
- >>93
その判断を誤るとややこしいことになるからすべてpublicにしておけ
って程度なんだろうね、その本>>95
- 98 :
- もともとC++やってて、最近仕事でjavaやり始めたんだけど、
javaのprotectedって全然プロテクトじゃないんだね
最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
アクセサメソッド追加してるんだけど、まずいですか?
まともなjava技術者ならどうしてます?
- 99 :
- >>98
全然プロテクトじゃないってどういうこと?
- 100read 1read
1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part13 (628)
プログラムできないやつが適当に話を合わせるスレ (753)
UnicodeとUTF-8の違いは? その2 (898)
【Java】Wicket【HTML】 (580)
OpenGL 2.0 専用スレ (703)
「OS自作入門」 (313)
--log9.info------------------
【DrMOS】MSI友の会 その53【Military Class】 (954)
■ 2Dが速いビデオカード Part10【GDI/DD】■ (606)
Shuttle友の会 16台目 (268)
●●新潟のPCショップ 39●● (221)
省スペース・スリムケース 14台目 (890)
BIOS総合質問スレ Part7 (373)
ビデオカード(GPU/VGA)総合 part4 (507)
【AMD】 HD5xxxシリーズ Part32【RADEON】 (898)
('A`)もう絶対知人に組んでやらねぇ 235人目 (260)
KEIAN/恵安 友の会 (798)
佐賀の自作関連情報 (607)
【LFB無】 TA780G M2+ Part 2 【鉄板?】 (929)
AMD-760MPX総合スレッド Part25 (506)
('(゚∀゚∩なおるよ!ろくねんほしょう!(にかいめ (925)
ASUS M2V/A8V/K8Vシリーズ総合スレ Rev1.14 (548)
【自作PC】第4回全板トナメ38票目【次回まで不貞寝】 (745)
--log55.com------------------
【ラブライブ!】曜「アノ日の歌?」千歌「それって」梨子「千歌ちゃん!!」 [495285805]
【悲報】自民議員「自衛隊がコンビニ商品を輸送は史上初!安倍総理のリーダーシップのおかげです!」 [725713791]
もうやめてくれ…!(涙)男が悲しむ「最悪R」とは? [372215213]
100人中90人くらいが嫌いそうな食べ物が「ようかん」 [173238122]
【悲報】安倍支持者さん、教祖様を馬鹿にされパヨク連呼で大発狂中 [434596658]
【画像】安倍晋三さん、脚の付け根が本当に痛そうだが我慢している、これ見ても叩けるのか? [155869954]
中年だけどお金がなくても外で楽しめることないか?家にいたらなんか憂鬱になってくる。友達彼女ナッシング。 [682111245]
【悲報】被災者、なりふり構わず道路脇に分別してないゴミを山積みにしていく [483862913]