-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 ：

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

28 ：

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

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項演算子がネストできないと思ってるところかｗ

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 ：

ＵＭＬでは、異常系の記述がやり辛いよな。
・・・はっ！！

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元 削除依頼 ▲

OpenGL 2.0 専用スレ (703)
Lisp Scheme Part34 (659)
C++/TemplateMetaProgramming (466)
ACM/ICPC 国際大学対抗プログラミングコンテスト2 (306)
結局DelphiとVC++ってどっちの方がいいんだ？ (282)
Mozillaでプログラミング(XUL) その3 (545)
--log9.info------------------
◆◆◆２Ｆ？『逸楽』３Ｆ？ミナミの新星 (903)
【新宿】Ｊワールド〜スマイルエンジェル Part.5 (935)
【美少女系】アロママンダリンリゾート2【出張】 (794)
大阪　せせらぎ　野田駅前 (707)
ラフィネ●１３店舗 (944)
洗脳不可能インチキ苫米地英人２０ (854)
大阪・難波【楽楽】 (222)
【ひざまくら耳かき】和み屋【新人入替戦】其の陸 (742)
【池袋】アロマニア　３ (738)
【五反田】Ｇーｓｔｙｌｅ【透けＴバック最高！】 (368)
【渋谷】R STUDIO(アールスタジオ)【本日オープン】 (269)
【大阪・西大橋】アロマローズ【すすむと提携】 (861)
気功ヒーリング・パワーストーン ヒーリング (739)
【新宿】ぷちふる〜る【メイドリフレ】 (415)
AJK★15 (312)
大阪市内、出張マッサージ　パート8 (467)
--log55.com------------------
†† 小公女セーラ 136話 ††
超時空要塞マクロスTV＆劇場版　Part64
うっすらぱー！【魔法の妖精ペルシャ】ですの！
ダーティペアを語れ　vol.14
ドラえもん のび太の宇宙開拓史
†† 小公女セーラ 133話 ††
蒼き流星SPTレイズナー レンジ15
†† 小公女セーラ 132話 ††