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

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2005/09/24(土) 16:35:59
全部publicでいいじゃん！ってならないようにするスレです。
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の時の扱いが違うくらいしか思いつかないけど、なんかすごい引っ掛けがあるのかな・・？
0102デフォルトの名無しさん2005/12/23(金) 12:01:36
>>98
早くプロテクトじゃない理由を教えてくれよう。ﾜｸﾜｸ
0103デフォルトの名無しさん2005/12/23(金) 12:20:31
＞最初はprivateで作ってて派生クラスからメンバ変数へのアクセスが必要になる度に
＞アクセサメソッド追加してるんだけど、まずいですか？

C++もそうだし、オブジェクト指向もわかってないんじゃないかな
なんか、Cプログラマーみたい
グローバル変数使うなっていわれたから、プライベートにしてみました
みんなが必要とするから悪切磋つけました

そんなところでしょ
0104デフォルトの名無しさん2005/12/23(金) 12:45:22
Lispを使わないなんてバカげてる
0105デフォルトの名無しさん2005/12/23(金) 13:14:14
サブクラスのためにその都度スーパークラスを改変するのはナンセンス

まともなC++技術者ならそんなことやらない
まともなJava技術者もそんなことやらない
まともなSmalltalkerもそんなことやらない
まともなオブジェクト指向言語使用者ならそんなことやらない

0106デフォルトの名無しさん2005/12/23(金) 14:10:15
まともな奴なら継承は使わないってことか
0107982005/12/23(金) 14:10:15
自分はまともじゃないです（つд`）
プロテクトじゃない云々は、javaのprotectedメンバは派生クラスだけでなく
同じパッケージにいるクラスでもアクセスできるのでC++のより緩いって意味です。
親クラス作るときにはメンバ変数全部に対してprotectedのアクセサ用意しとくものなのかな、と。
で、こういう設計はおかしいですか？
0108デフォルトの名無しさん2005/12/23(金) 14:12:55
親クラスのメンバーにサブクラスがあとあといろいろアクセスしなきゃならなくなるかもぁー。
そういうときにpribvateだと、困るから、protectedにしておいたほうが、いいのかなぁ〜。


なんっていう、下らんこと気にしているようでは、そもそもクラス抽出がうまくできているとは思えない。
0109デフォルトの名無しさん2005/12/23(金) 14:15:50
>>106
サブクラスのためにその都度スーパークラスを改変する　ってのがナンセンス。
継承前提で設計されたスーパークラスはそんな改変しょっちゅうしない。
0110デフォルトの名無しさん2005/12/23(金) 14:17:48
>>107
？
派生からアクセスが必要になる度にアクセッサを追加してるんじゃないの？
そもそも日本語もだめだったり？
0111デフォルトの名無しさん2005/12/23(金) 14:25:09
俺も勉強したてでよく分からんけど、
メンバ変数全部に対してprotectedのアクセサ用意って
これはカプセル化の意味ないと思うんだが…

多分そのスーパークラスの設計から見直したほうがいいんじゃ
0112デフォルトの名無しさん2005/12/23(金) 14:32:59
継承前提で作るときはこういう悩みはないんですが、
工数削減の関係で仕方なく、継承させるつもりがまったくなかったクラスに
スーパークラスとして、アクセサを追加してました。
まったく継承させるつもりがなくても、あとあとのことを考えて
protectedアクセサを…ってダメダメですよね。
設計が悪かったのが理解できました。みなさんありがとう
0113デフォルトの名無しさん2005/12/24(土) 00:00:27
コンストラクタはオーバーロードできないっぽくて悲しい
デフォコンだけでしょ
0114デフォルトの名無しさん2005/12/24(土) 00:30:10
>>113
？
0115デフォルトの名無しさん2005/12/31(土) 04:53:35
>>113
　　　∧_∧　　　　／￣￣￣￣￣
　 　 (ω・　)ゝ　＜　なんだって？
　 ノ/　 /　　　　　＼＿＿＿＿＿
　　ノ￣ゝ
0116デフォルトの名無しさん2005/12/31(土) 10:26:20
コンストラクタでHoge(String str)とかは継承されないという話
オーバーロードとは違う
0117デフォルトの名無しさん2005/12/31(土) 13:39:08
StrutsのActionみたいなリクエストを処理するクラスで、思想の問題と思われるが
Aという共通抽象クラスがあって、業務Bと業務Cがあり、BとCは機能がほとんど同じ
この場合、どっちがよい？

1)A<Bと継承して、更にB<Cと継承して違うところだけは追加・オーバーライドする
2)A<B, A<Cと別々に継承する

1だと違う部分だけ書けばそれだけでいいけど、もしBの共通部分が変更になるとCにも影響する恐れがある
2だとBの共通部分が変更になってもCには影響しないが、多少かぶってしまう箇所が出てくる

個人的には2かなと思ってるけど、今の現場では1が多い
2は共通化できそうな部分だけは別クラスに作るってので対処できるし
0118デフォルトの名無しさん2005/12/31(土) 13:54:44
俺も2かな。ただしやるならDecoratorパターン。
早い話がラッピングするパターン。

http://www.techscore.com/tech/DesignPattern/Decorator.html
0119デフォルトの名無しさん2005/12/31(土) 18:49:30
>>117
もし俺なら、(共通部分の内容と量にもよるが)もう１層括りだせないか？
と、考えてみる。
AbstractA＜抽象クラス
　│
AImpl＜共通実装部分
　├SubclassB＜差異
　└SubclassC＜差異
0120デフォルトの名無しさん2005/12/31(土) 19:11:48
感じとして会社によってはドメインフレームワークって言ってるやつかな？
01211172005/12/31(土) 20:13:31
ﾚｽｻﾝｸｽ
>>118
Decoratorﾊﾟﾀｰﾝでやったことないから今度実験してみよう

>>119
2の拡張みたいな感じかな
それも検討してみたことがあるけど、サブシステム全体で共通ならいいような気がするけど
サブシステム内のある２機能だけ特別にクラスを作るってのはどうか悩んだ
0122デフォルトの名無しさん2005/12/31(土) 22:41:21
そこまで差が少なければ俺は119のAImplをクラステンプレートにして、
BとCの差異をTraitsクラスにして選択できるようにするだろう。
119のように継承するのと大して差異はないけど。
0123デフォルトの名無しさん2005/12/31(土) 22:54:14
>>122
C++な人？
01241222006/01/01(日) 13:02:39
>>123
そうだよ。
ついC++スレにいるつもりでだった。
117がC++を使っていなければすまん、使えないな。
0125デフォルトの名無しさん2006/01/03(火) 13:35:23
設計相談って難しいよね

冗談半分でSmalltalkならこうするよ
といったら怒られたｗ
Javaでやろうとするとひどく煩雑になるんだもん・・・
0126デフォルトの名無しさん2006/01/05(木) 08:46:21
設計という分野は言語より上位だと思ったりもするんだが、
実装する言語によって良い設計が変わってしまうしね。
0127デフォルトの名無しさん2006/01/06(金) 00:19:47
>>126
言語で左右されるような実装レベルまで設計するなよ
0128デフォルトの名無しさん2006/01/07(土) 00:38:38
そうなのかなぁ
どんなにすばらしい設計をしたとしても、
それを実現する手段がなければ
意味のない物になってしまうと思うんだけど
0129デフォルトの名無しさん2006/01/07(土) 01:23:02
C++でtemplateで静的に解決できるものが
Javaでやるならクラスで動的解決になるし。
しかも静的動的って言葉すらも言語によって意味違うし。

>>127の思想だと最大公約数的な設計になりそう。
まぁ別にそれでも問題無いことも多い気もするけど。
0130デフォルトの名無しさん2006/01/07(土) 11:47:08
設計は二段階で
0131デフォルトの名無しさん2006/01/07(土) 22:39:23
基本設計
詳細設計
0132デフォルトの名無しさん2006/02/12(日) 12:27:56
デザインパターンっていつ使うの？
0133デフォルトの名無しさん2006/02/12(日) 15:23:02
パターン化したいとき
0134デフォルトの名無しさん2006/02/13(月) 03:39:02
使えるとき（ﾏｼﾞﾚｽ）
0135デフォルトの名無しさん2006/05/18(木) 07:22:23
私もRubyが何故ifをTrueClass/FalseClassのメソッドに
しなかったかなぁ、と思った事はあるね。
Perlとかを意識して妙な仕様にしたんだと思うが。
0136デフォルトの名無しさん2006/05/18(木) 07:24:29
ぐは、誤爆
0137デフォルトの名無しさん2006/07/01(土) 21:50:01
publicばっかのクラスというけれど
7割がたそうなってしまうのが人の世だと思う
0138デフォルトの名無しさん2006/07/01(土) 22:01:48
public といっても、属性と操作がある。
属性は全て private 、
操作はデフォルトで public 必要に応じて private ってのが
実装レベルでは当然と思う。

ぶっちゃけ、7割りがた属性が public なクラスなんてありえない。
0139デフォルトの名無しさん2006/07/01(土) 22:31:20
そら属性は7割がたprivate、残りprotectedだろうね。
0140デフォルトの名無しさん2006/07/04(火) 00:15:15
フィールドは本来10割がprivateだろう。
派生クラスで使用したい場合も、protectedなプロパティとして用意するべき。
0141デフォルトの名無しさん2006/07/04(火) 23:20:03
protected も無印（package） も意外と使わないんだよね。
なんか使うとしても、デバッグとかテストケース動かすためとか、
裏技的な目的が多いような・・・。
0142デフォルトの名無しさん2006/07/17(月) 03:10:02
私はpackageは使いまくってるよ

これがないと(ていうかC++のことだが)
ユーザー公開用のファサードを用意しなきゃならなくてだるすぎる
0143デフォルトの名無しさん2006/07/22(土) 00:37:29
俺もパッケージプライベートは良く使う
無名インナークラスでもない限りは、インナークラスは外に出すのでね
0144デフォルトの名無しさん2006/07/24(月) 23:36:10
今日、とあるプロジェクトに加わることになって、
そのプロジェクトで利用されてるライブラリ(プロジェクトメンバーが開発)
を見たんだけど、やたらと〜Managerみたいなクラスばっかりだった。
これって、どうなのかなぁ？
例えば、ファイル入出力を司るクラスが抽象クラスで用意されてて、
そいつを必ず継承して使ってねっていう感じだった。
他の各機能も同じ。
んで、プロジェクトファイル名も〜Managerみたいなのばっかり。
(マスタデータを登録するやつだったらDataManagerとか・・)
うまく説明できないんだけど、何か違和感を感じました。
こういうのってOOPで主流(?)なんでしょうか？

ちなみに言語は.NETのC#です。
0145デフォルトの名無しさん2006/07/24(月) 23:55:10
>>144
http://www.radiumsoftware.com/0603.html#060330
0146デフォルトの名無しさん2006/07/24(月) 23:57:43
>144
抽象クラスを継承して使うことが、Managerが多いことの例え、
って部分が理解出来ない。
0147デフォルトの名無しさん2006/07/25(火) 00:03:42
>>145
参考になりました・・・・・

明日から、どうしよ。
なんか、このライブラリを使用することを半強制されてるんだけど・・・・
(；´Д`)
0148デフォルトの名無しさん2006/07/25(火) 00:23:51
使いにくいだけのショボブラリを仕事で使わされると虐待かと思う
0149デフォルトの名無しさん2006/07/25(火) 00:25:50
>>146
説明が悪くて申し訳ないす。

何というか汎用的な各機能毎にManagerがいて、
汎用的な処理を実装する機能をもつクラスが必要になる
場合はそのManagerを継承して、新たなManagerを作ってねという感じなんですよ。
んで、ファイルを読んだり、書いたりする機能がある場合だったら
必ずFileManagerとやらを継承してHogeFileManagerや、
FugaFileManagerみたいなクラスを作ろうという風になってます。
Managerと言う割には、ファイルの読み/書きの機能の為だけに
わざわざ継承するのはどうなのかなぁと。
FileManagerにHogeFileManagerやFugaFileManagerのインスタンスを
渡して処理するような事も無いみたいだし・・・

うまく説明できないけどこんな状態です・・・。
0150デフォルトの名無しさん2006/07/25(火) 00:52:47
>>149
"Manager"という名前がアレだけど、それって単に物理的な何かを
抽象化してるだけでしょ。
良くある話。
0151デフォルトの名無しさん2006/07/25(火) 01:07:55

〜erみたいなクラスは確かによく見るんですが、
余りにも〜Managerがたくさんいたんで
おかしいなと、自分が考えすぎてただけなのかもしれないすね。
明日あたり、作成者の人にどういう意図で作ったのか
聞いてみます。
お騒がせしました。
0152デフォルトの名無しさん2006/07/25(火) 01:22:49
やめとけ、意図と聞くと切れる。
聞いただけで否定されてる？って切れる。
0153デフォルトの名無しさん2006/07/28(金) 01:10:59
↑こういうプロになりたくないと思ったbyｱﾏﾁｭｱ
0154デフォルトの名無しさん2006/07/28(金) 01:46:47
糸は切れやすい。たしかに。
0155デフォルトの名無しさん2006/07/28(金) 02:10:29
自分の設計が最強と思ってる人間が、
同じプロジェクトに居たりすると困るよなぁ。
やたらと、自作ライブラリを使わせようとしたり、
頼んでも無いのに勝手にこれ使ってくださいとか言ってきたりする奴。
身の回りに一人居るが、
今、新人を洗脳してるw
型って何？、レベルの人間に
懇々と我流オブジェクト指向について熱く薀蓄を語っては、
新人のやる気を萎えさせてる。
おかげで、久しぶりに開発人数が増えそうなのに、
辞めてってしまいそうだ。
0156デフォルトの名無しさん2006/07/28(金) 21:20:14
オブジェクト指向もデザパタも判らない奴>>155
0157デフォルトの名無しさん2006/07/28(金) 21:27:46
>>155
困るなら論破すればいいのに
0158デフォルトの名無しさん2006/07/30(日) 10:03:49
>>155
俺の事言われてるのかと思ったw

まぁ、数千行の関数とかコピペで作る奴よりマシだと思ってるけど。
俺は自作ライブラリ作るときは、シンプル＆単機能な設計でUnitTestとセットで提供しているから問題ないよな。
0159デフォルトの名無しさん2006/07/30(日) 10:10:14
田舎ライブラリ使わされるのは苦痛なだけ
そのまま作らせろ
■ このスレッドは過去ログ倉庫に格納されています