オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/26(火) 07:20:38.98

前スレ
オブジェクト指向システムの設計 172
http://mevius.2ch.net/test/read.cgi/tech/1467992113
オブジェクト指向システムの設計 173
http://mevius.2ch.net/test/read.cgi/tech/1502182334/

類似スレ
手続き型システムの設計 1
http://mevius.2ch.net/test/read.cgi/tech/1500282714

**デフォルトの名無しさん** · 2017/10/05(木) 07:17:31.37

寿司クラスのプロパティはシャリネタワサビだろ

スシローに関して言えばワサビのプロパティは不要

**デフォルトの名無しさん** · 2017/10/05(木) 07:18:38.24

>>355
ワサビの状態は複雑だから真偽で取るなんてナンセンス

**デフォルトの名無しさん** · 2017/10/05(木) 08:10:53.17

各プロパティは読み取り専用だろ

**デフォルトの名無しさん** · 2017/10/05(木) 08:16:20.73

わさびの量を調整したい場合はどう拡張すればいいの？
例えば罰ゲームで使うような山盛りわさび寿司
外国人向けの程よくわさび増量

あと、わさび巻の場合はわさびプロパティの内容はどう持つべきか？

**デフォルトの名無しさん** · 2017/10/05(木) 08:22:39.12

>>359
寿司.putワサビ(量)
じゃないの

**デフォルトの名無しさん** · 2017/10/05(木) 08:23:16.92

またそれ系の話か
荒れそう

**デフォルトの名無しさん** · 2017/10/05(木) 08:27:51.49

というかあれか
寿司職人.putワサビ(寿司,量,状態)
かな

**デフォルトの名無しさん** · 2017/10/05(木) 20:38:04.24

またキャットドアｗ

**デフォルトの名無しさん** · 2017/10/05(木) 20:41:30.98

大漁大漁!

**デフォルトの名無しさん** · 2017/10/05(木) 23:44:16.07

>>363
キャットドアはやめろ
オブジェクト指向云々とは別のところに問題がある
またこの手の話するならちゃんと要件定義してからやれよ

**デフォルトの名無しさん** · 2017/10/06(金) 00:35:25.91

>>365
１つ賢い意見が出たな

要件定義をしないとキャットドアは作れない!

他のものもそうでないかな？

**デフォルトの名無しさん** · 2017/10/06(金) 00:59:27.12

どういう用途のソフトウェアかに関係なく
オブジェクト指向でモデリングできると思ってるやつが多々いるのはオブジェクト指向に密接に関係した問題

**デフォルトの名無しさん** · 2017/10/06(金) 06:35:11.92

>>367
できないの?

**デフォルトの名無しさん** · 2017/10/06(金) 08:14:28.44

>>366
寿司屋はわかりやすくね？
キャットドアやるならまずドアを作ってから継承するなりで基礎がないと

**デフォルトの名無しさん** · 2017/10/06(金) 08:16:59.53

物理的な形あるものを題材にするのはアホ

**デフォルトの名無しさん** · 2017/10/06(金) 08:28:32.38

そんなモデリングは天才に任せるわ

**デフォルトの名無しさん** · 2017/10/06(金) 09:35:10.87

>>370
オブジェクト指向が間違っているのでは？（笑）

**デフォルトの名無しさん** · 2017/10/06(金) 12:09:15.03

オブジェクトという名前が悪い
責務指向とか役割指向の方が適切

**デフォルトの名無しさん** · 2017/10/06(金) 14:21:58.68

>>359
enum ワサビ量 {なし, ちょっぴり, 少なめ, やや少ない, 普通, やや多め, 多め, メガ盛り, ギガ盛り, テラ盛り, ペタ盛り, ワサビのみ};

**デフォルトの名無しさん** · 2017/10/06(金) 15:07:25.77

キャットドアで味を占めちゃってまぁ…

**デフォルトの名無しさん** · 2017/10/06(金) 15:43:29.32

簡単に篩にかけられてホントいいねこれ

**デフォルトの名無しさん** · 2017/10/06(金) 21:48:40.87

処理の流れがあちこちに飛ぶし
あちこちから飛んでくるし
「これ誰が保守するんだ？」って気分になってる。
ちょっとした修正が今までならピンポイントでテスト合わせて30分位のところが
全体見るために3時間かかる感じ。
能力高くないと無理だと思うけど人手不足だし集められるかな？
もっと緩いオブジェクト指向でいいと思う。
こんなガチガチで上手くいったプロジェクトってあるの？

**デフォルトの名無しさん** · 2017/10/06(金) 22:04:02.02

>>377
犬のしょんべんに当たっちまったな
自分以外の奴がソースコードを読めないようにする工夫だそれ

元凶がインターフェースで
継承してあるすべてのクラスのインスタンス作成箇所全部をチェックしないと処理がわからない

**デフォルトの名無しさん** · 2017/10/06(金) 22:05:57.94

チンポについて教えてください。
チンポをインスタンス化して、引き数にマンコを持つキンタマメソッドの戻り値
ザーメンを取得したいのですが、コンパイル結果がフニャチンになります。
どうしたらいいですか。

**デフォルトの名無しさん** · 2017/10/06(金) 22:27:28.80

はい

**デフォルトの名無しさん** · 2017/10/06(金) 22:47:26.17

>>377
それガチガチなんじゃなくて設計や実装が下手なだけ

**デフォルトの名無しさん** · 2017/10/06(金) 23:17:58.09

>>377
ほんとにガチガチならそのクラスを作ったやつの後任者～お前の前任者までの間で間違ったクラスの使い方が広まったんだろうよ

**デフォルトの名無しさん** · 2017/10/07(土) 00:17:06.44

>>379
それガチガチなんじゃない。

**デフォルトの名無しさん** · 2017/10/07(土) 05:03:01.30

“これはこれをする奴”と一目でわかって
処理飛ばした後はそいつがよしなにやるから
細かいことは考えなくていい。
というのがオブジェクト指向の売りだから
「コイツはなにやってんだよ！」と処理追うのに混乱するようなのは
基本を履き違えてる気はする。
変なとこから流れてきた自称プログラムのプロがやりがちな
暗号みたいなクラス名とか

**デフォルトの名無しさん** · 2017/10/07(土) 06:51:50.71

だいたいインターフェースが元凶だって
実行してみないとわかんねーし

**デフォルトの名無しさん** · 2017/10/07(土) 07:09:22.30

インターフェースが現況って言ったってクラス名とメソッド名である程度目的はわかるようになってるんじゃねえの
それができてないなら単なる設計ミスじゃん

**デフォルトの名無しさん** · 2017/10/07(土) 07:23:39.11

>>386
バカの作るインターフェースは思いつきで入れた汎用性を実現するものだからそもそも設計書に書かれない

**デフォルトの名無しさん** · 2017/10/07(土) 07:43:58.72

>>387
そういうもんか
そういう用途で使うべきではないわな

**デフォルトの名無しさん** · 2017/10/07(土) 08:28:19.15

>>384
手続き型みたいなのでバグ探すと、大体1ファイルの中見て
処理の流れもその中だけ追えば良くて
シンプルな流れだからチョイチョイってできるけど
完全なオブジェクト指向だと、
｢この値を設定してるのは、ここ、
…、
じゃなくて、コイツ他のとこで設定してるのか～、
ここ？
あ、もっと上か～｣
みたいにあちこち辿っていくから
あんまり良いことに感じないけど。
影響範囲も広いし。
考えなくていいのは、製造するときに何が何をすると
ハッキリと決められてる時で
どこにバグあるかとか見るときは
｢ここだろう｣と最初に思ったとこではなかったりしなくね？
設計が難しいなら、
バカでもできる簡単な設計で済む手続き型最強な気がする。

**デフォルトの名無しさん** · 2017/10/07(土) 08:32:25.87

>>389は詳細設計書位しかなくて、クラス図とかもろもろないケースの話で。

**デフォルトの名無しさん** · 2017/10/07(土) 08:45:17.84

>>389
ガチガチのオブジェクト指向ならその値がどこで設定されたなんか関係ないよ
今受け取った値に対しての動きをするだけ

**デフォルトの名無しさん** · 2017/10/07(土) 08:56:39.98

ワンインスタンス内ではメンバはグローバル変数みたいに振る舞うから
継承多くなるとっていうかある時点でクソ言語になるんだよね

**デフォルトの名無しさん** · 2017/10/07(土) 08:59:42.95

>>389
＞>>384
＞手続き型みたいなのでバグ探すと、大体1ファイルの中見て
＞処理の流れもその中だけ追えば良くて
＞シンプルな流れだからチョイチョイってできるけど

これはむしろオブジェクト指向の特徴だね

＞完全なオブジェクト指向だと、
＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか～、
＞ここ？
＞あ、もっと上か～｣

これは典型的な手続き型のデバッグだよね

もしかしてスレ加速を狙ってわざと間違えてる？

**デフォルトの名無しさん** · 2017/10/07(土) 09:01:52.28

>>393
それ明らかに俺から見て逆だわ
処理に対して一旦オブジェクトで纏めるオブジェクト指向がそこの辺シンプルになるわけねーだろチンカス

**デフォルトの名無しさん** · 2017/10/07(土) 09:07:01.43

>>394
あ～
うん
まあそういう人も居るよね
存在を否定はしないよ
民主主義国家の人民は自由であるべきだ

**デフォルトの名無しさん** · 2017/10/07(土) 09:13:58.30

>>395
393で言いたいことはまぁわかる
けど自分が多数派であると思い込んでるのはおかしい
おまえの中の「～べき」って論は他人に通じないので押しつけないで

**デフォルトの名無しさん** · 2017/10/07(土) 09:33:31.18

>>396
いろんなコミュニティに顔だしてみなよ
リアルが無理ならネットコミュニティだけでもいい
>>393が常識的な認識だよ

**デフォルトの名無しさん** · 2017/10/07(土) 09:45:04.94

>>397
どこにそんなの書いてあるんだよ

**デフォルトの名無しさん** · 2017/10/07(土) 09:45:43.21

呼び出し階層が深いだけで可読性が低いなら抽象化が下手なだけで、オブジェクト指向に限った話じゃない

呼び出し元や定義にジャンプする機能のないエディタ使ってると辛いとか
DIでコンフィグから実装を注入してると追うのが面倒くさいとかなら分かる

**デフォルトの名無しさん** · 2017/10/07(土) 09:55:17.34

>>397
おまえの中ではそうなんだろうな
繰り返すが393で言いたいことはまぁわかる

**デフォルトの名無しさん** · 2017/10/07(土) 10:08:41.11

>>398
> どこにそんなの書いてあるんだよ

いろんなコミュニティ

**デフォルトの名無しさん** · 2017/10/07(土) 10:17:47.53

いろんな考えかたの人がいる
それは認めるべきだ
オブジェクト指向が好きなやつも手続き型が好きなやつもみんな自由と権利を持っている

でもここはオブジェクト指向のスレなので
手続き型に興味があるなら手続き型スレで議論を深めればいいんじゃないかな？

手続き型システムの設計 1 [無断転載禁止]©2ch.net･
http://mevius.2ch.net/test/read.cgi/tech/1500282714/

オブジェクト指向がわかりにくくて嫌いだからといってもオブジェクト指向のコミュニティを荒らしてもいい理由にはならないだろう
住み分けは大事だ

**デフォルトの名無しさん** · 2017/10/07(土) 10:24:12.14

>>401
なんだそのキチガイコミュニティ

2～3個リンク貼ってみろ
潰してくる

**デフォルトの名無しさん** · 2017/10/07(土) 10:24:39.29

>>403
スタックオーバーフロー潰してくれ

**デフォルトの名無しさん** · 2017/10/07(土) 10:32:38.68

>>404
どのレスだよ

**デフォルトの名無しさん** · 2017/10/07(土) 10:33:11.71

ガチガチに手続き型で組んだプログラムなんて見とうないわ
あちこちに飛ぶから云々ってマジでいってんのか

**デフォルトの名無しさん** · 2017/10/07(土) 10:44:43.23

あちこち飛ぶからいいんじゃねえか
飛ばなかったら全ての処理が一箇所に集まってパンクするだろw

**デフォルトの名無しさん** · 2017/10/07(土) 11:50:23.50

飛び方がキレイな木の枝のようになっていればよい
枝から枝へモモンガのように飛ぶ処理が入っていたら地獄だ

**デフォルトの名無しさん** · 2017/10/07(土) 14:53:33.77

というか、オブジェクト指向はクラスに責任を持たせることで
責任が遡ったり他へ波及するのを防ぎデバッグも局所化して容易にする思想なので
どこかで一目でわかるように「この値を設定する一意の責任を持つのはおまえ」と
責任を持った誰かがいて、正しく作ってればそこから周りにゴミが飛び散るはずがないので

＞｢この値を設定してるのは、ここ、
＞…、
＞じゃなくて、コイツ他のとこで設定してるのか～、
＞ここ？
＞あ、もっと上か～｣

とか、それのどこがオブジェクト指向だ。>>393と同じ感想

**デフォルトの名無しさん** · 2017/10/07(土) 15:00:30.34

>>409
だからインターフェースだって

**デフォルトの名無しさん** · 2017/10/07(土) 16:02:05.40

>>410
意味わからんけど
どんな使い方してんねん

**デフォルトの名無しさん** · 2017/10/07(土) 16:08:52.04

素人がインターフェースを使うと実装に強く依存してしまうことがある
実装クラスの内部的な挙動を前提にするとかね

**デフォルトの名無しさん** · 2017/10/07(土) 16:19:22.15

おまえらおしゃべりしたいだけだろ
リアルで交流しろや

**デフォルトの名無しさん** · 2017/10/07(土) 17:51:59.67

>>408

なに？　お前、モモンガ先輩の事ディスってるの？

**デフォルトの名無しさん** · 2017/10/07(土) 19:44:56.82

>>412
Javaのデフォルトメソッドとか

**デフォルトの名無しさん** · 2017/10/07(土) 20:05:29.97

しっかり役割を分担しないとオブジェクト指向の利点をいかせないと言うことか

**デフォルトの名無しさん** · 2017/10/07(土) 21:05:16.73

>>416
利点も何も役割分担できてないならそもそもオブジェクト指向じゃないよ

**デフォルトの名無しさん** · 2017/10/07(土) 21:37:16.03

一言でクラスの役割を言えなければ設計ミス

**デフォルトの名無しさん** · 2017/10/07(土) 21:55:08.92

>>418
神クラス

**デフォルトの名無しさん** · 2017/10/07(土) 22:17:55.42

>>418
いやだから、インターフェイスってそういうもんじゃん

**デフォルトの名無しさん** · 2017/10/08(日) 09:02:57.57

オブジェクト指向の設計の話をしてると
このクラスはこのことを知ってるべきだ、イヤ知らないべきだ
なんて話がよくあるが
アスペの代表的な特徴として自分の視点でしか考えられない
ということかあるのでアスペにOOは無理

**デフォルトの名無しさん** · 2017/10/08(日) 09:11:34.28

>>421
確かにアスペに取り扱いは難しいな
だが言うなればオブジェクト指向はアスペクラスの集合体だからアスペ視点は大切

**デフォルトの名無しさん** · 2017/10/08(日) 09:24:12.05

アスペルガー指向

**デフォルトの名無しさん** · 2017/10/08(日) 09:24:39.06

>>422
1人1クラスずつ作るのか
他の人のクラスを利用することがないからゴッドクラスが乱立するな
最悪だ

**デフォルトの名無しさん** · 2017/10/08(日) 09:27:10.43

そういう現場は多いよ
見積もりしやすいとかいう頭が悪い理由で、画面を作業単位にして割り振るから
神画面クラスがいくつも出来上がる

挙げ句の果てにその見積もりも根拠なしの適当な数字ときたもんだ

**デフォルトの名無しさん** · 2017/10/08(日) 09:31:28.00

>>424
お前がアスペだったか

**デフォルトの名無しさん** · 2017/10/08(日) 09:39:58.73

>>426
説明できないと何の論拠も無く相手をアスペで片付けるんだね

**デフォルトの名無しさん** · 2017/10/08(日) 09:51:49.98

>>425
あるな
メンテの費用たくさん取れるからいいんだよとか言い出す始末
勉強してるのがバカバカしくなる

**デフォルトの名無しさん** · 2017/10/08(日) 10:04:06.91

でも見積り出せない作業じゃお金もらえないから

**デフォルトの名無しさん** · 2017/10/08(日) 10:17:02.42

単価を品質に見合ったものにしろ

**デフォルトの名無しさん** · 2017/10/08(日) 10:58:52.79

おまえらアスペとかADHDとか言ってるけど
せめてググってwikipediaや解説サイトぐらい見れば話が合うような言葉を選んでくれ
10人にADHDの説明させたら10通りの回答が出てくる現状では
技術的な議論に使う言葉じゃないと思うんだわ

**デフォルトの名無しさん** · 2017/10/08(日) 11:01:13.46

見積もりは出したふりでいい
客も見積もりに意味ないことは分かってるから上司への説明など適当にうまくやってくれる
その辺は阿吽の呼吸ですよ

**デフォルトの名無しさん** · 2017/10/08(日) 11:04:17.48

関わるのも面倒だからそういうのはメンバーにいない方がマシ

**デフォルトの名無しさん** · 2017/10/08(日) 11:16:34.14

>>427
自分が誰よりも上位にあることを見せかける上で便利だからねアスペ認定は

**デフォルトの名無しさん** · 2017/10/08(日) 11:18:28.86

ここオブジェクト指向スレなんですが？
アスペがアスペを叩いていて笑う

**デフォルトの名無しさん** · 2017/10/08(日) 11:25:19.20

アスペクト指向ってどうなったの

**デフォルトの名無しさん** · 2017/10/08(日) 11:36:48.97

>>436
オブジェクト指向にフックを仕込めれば十分であることがわかった
アスペクト指向は「指向」ではなく、オブジェクト指向設計に
組み込む一種のパターン

**デフォルトの名無しさん** · 2017/10/08(日) 15:55:36.81

>>436
DIで若干使われてなかったっけ？

**デフォルトの名無しさん** · 2017/10/08(日) 20:27:37.02

そういや一時期流行ったな
実装のまずさを誤魔化す手段という認識しかなかった

**デフォルトの名無しさん** · 2017/10/08(日) 22:01:40.54

デコレーター
属性バリデーション
シリアライズ
apiプロキシ
…

aopは意識しないだけで結構使ってるな

**デフォルトの名無しさん** · 2017/10/09(月) 08:04:01.64

メッセージリソース管理クラスの素晴らしい設計を教えてください

void SomeAppMethod() {
// do something
view.AddMessage("MSG_0123")
// do something
}

こんな感じでリソースIDがシステム中にばら撒かれて制御不能状態になっています
メッセージリソースを管理するクラスを作って解消したいのですが良いAPIが決まりません

**デフォルトの名無しさん** · 2017/10/09(月) 08:13:01.79

>>441
何が困ってるの？

**デフォルトの名無しさん** · 2017/10/09(月) 08:52:42.35

>>441
OOPではリソースIDのような物理的な情報は隠蔽しなければならない

public interface ILowLevelMsgManager {
string GetMsg(string msgId, params object[] placeHolderArgs);
}

public interface IMsgManager {
string GetHogeMsg(); // ほげええええ
string GetFugaMsg(int num); // ふがふが{num}ふがふが
}

public class MsgManager : IMsgManager {
private ILowLevelMsgManager llmm;
public MsgManager(ILowLevelMsgManager pllmm) { llmm = pllmm; }
public string GetHogeMsg() { return llmm.GetMsg("MSG_0001"); }
public string GetFugaMsg(int num) { return llmm.GetMsg("MSG_0002", num); }
}

**デフォルトの名無しさん** · 2017/10/09(月) 09:16:54.02

>>443
それになんの意味があるのかさっぱりわからんな
メッセージなんてでかいプロジェクトだと500個とか行っちゃって
詳細なんかわかんなくていいんじゃないの？
もうメッセージ一覧で確認することは諦めろよ的な

**デフォルトの名無しさん** · 2017/10/09(月) 09:24:41.04

メッセージでこれまで見た中で一番多いのは3000だった
そこまで構えろとはいわんけどそういう性質のものではある

ソースの該当箇所に一つ一つ置いていく手間は省略できない
メッセージリソースIDとメッセージが照合できればそれでその作業は終わりじゃねーのか？
後、何を管理してもらいたい？

**デフォルトの名無しさん** · 2017/10/09(月) 10:08:03.54

>>444-445
ハードコードされた人間可読性ゼロの3000個のIDはそう簡単には管理しきれないと思うが
まあ君の人生だしどう時間を使おうと君の自由だね
私はしっかり管理して時間を節約するよ

**デフォルトの名無しさん** · 2017/10/09(月) 10:21:29.30

客の都合でID体系変更になってリテラル全部調べて置き換えて再テストしたトラウマ
する価値ないと思ってもとりあえずでいいから抽象化しておいて損はない

**デフォルトの名無しさん** · 2017/10/09(月) 10:22:07.29

別ファイルに切り出して読み込めばいいと思う

**デフォルトの名無しさん** · 2017/10/09(月) 10:44:55.28

>>446
いやぁ、だからさ
ソースのエラー箇所に自動配置なんかできないんだからそこは300だろうが3000だろうが30000だろうが手動じゃん
IDとエラーメッセージが組にさえなってたらどういう構造にしようがやることかわんねーよ的な

**デフォルトの名無しさん** · 2017/10/09(月) 10:48:47.25

visualstudioのjaファイルとかその辺の仕組み使えばいいんじゃないの？
ローカライズするならやっとかないと死ぬよ

**デフォルトの名無しさん** · 2017/10/09(月) 10:50:11.84

rm = new ResourceManager(locale)
un = rm.get("property.name.user-name")
msg = rm.get("validation.error.max-length", un, 10)
print msg # ユーザー名は10文字以下で入力してください

スッキリ

**デフォルトの名無しさん** · 2017/10/09(月) 10:55:11.14

>>449
それじゃ可読性が低すぎるって言ってるの
暗号みたいにIDばらまかれても保守できないよ
それに>>447のようにIDとメッセージの対応が変わることもある
手間が変わらないなら1つ抽象化層を設けてコードを保護すべき

**デフォルトの名無しさん** · 2017/10/09(月) 11:29:45.24

>>452
いやぁでもこの数やる気にはなんないなぁ

**デフォルトの名無しさん** · 2017/10/09(月) 11:31:53.98

>>452
体系が変わるのはまた別の話かな
もう完全に仕様変更なわけで落ち着いて対応できる

**デフォルトの名無しさん** · 2017/10/09(月) 11:34:13.65

このケースで余計に一層設けるのはメリット薄いんじゃない？
って言いたい