オブジェクト指向システムの設計 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/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

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

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

>>441
C#なら素直に.resx使う
少なくとも存在しないIDを使った場合に
コンパイルエラーになる仕組みを使う

種類ごとにグループ化(階層化)して管理しやすくする

メジャーなフレームワーク参照したら分かると思うがMSG_0123みたいな命名自体も悪手
もうどうしようもないのかもしれんが

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

>>456
もう数からいってメッセージのうちのどれ？って判別できる量で終わらんと思うし
IDの命名規則なんて些細なことよｗ
俺の経験で言うと

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

コードジェネレータがいいよ

メッセージID, メッセージテキスト, パラメータ数
Hoge, ほげ, 0
Fuga, {0}はふがです, 1

これをエクセルで管理してメッセージ管理クラスを出力

class MessageManager {
public static string Hoge() => "ほげ";
public static string Fuga(object p0) => string.Format("{0}はふがです", p0);
}

んでデータ数が増えてきたらエクセルをやめてデータベースで管理
エクセルを使えばお客様もお喜びになられるので一石二鳥

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

>>457
メンテナンス性を犠牲にしても
命名負荷を下げたいという意思決定をしてるんならいいんじゃないの

神クラス・神テーブルと同じアプローチだけど
物によってはそれが適切な選択の場合もあるんだろうから

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

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

メッセージリソースなんてものを作らない。

view.AddMessage("あーがこーでどうなりました")

って日本語で書けばいい。

多言語化したいなら、gettextなどの言語やフレームワーク標準の
多言語化ライブラリを使えばいい話。

その場合は、英語でメッセージを書いて、日本語化するってことが
よく行われるが逆でもいいだろう。

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

>>373
責務指向良いね

ゲームはオブジェクト指向でしっくり来るかも知れんけど業務システムだとピンと来ない

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

ゲームをオブジェクト指向で作ると作りにくいよ
相互作用の処理が多過ぎてオブジェクトに閉じない

**デフォルトの名無しさん** · 2017/10/10(火) 12:08:00.54

それは設計どころかゲームそのものとしての落とし込みが不十分
ゲームとか一定のルールに則った動作をするだよ

**デフォルトの名無しさん** · 2017/10/10(火) 12:15:07.34

>>462
メッセージ&イベントだらけになって死ぬな
ゲームは関数型が至高

**デフォルトの名無しさん** · 2017/10/10(火) 23:46:15.72

「オブジェクト指向だからステージの俳優が全員なんか言ってきて
カントクは一人一人対応なんかしてたら死ぬな！！www」

…いや、間違った理解をした奴はまあそういうドマヌケやらかしがちだが
普通はステージステータスに集約されて、ディレクターは
そのステータスを見て上から必要な個々に指示が送られるように作るからね…

**デフォルトの名無しさん** · 2017/10/11(水) 00:09:15.15

ゲームは油断するとすぐにキャストや型判定だらけになってしまう
特定のクラス同士の時だけ発生する相互作用とか

**デフォルトの名無しさん** · 2017/10/12(木) 12:26:13.92

ゲームとか業務とかピンキリだろ

**デフォルトの名無しさん** · 2017/10/12(木) 21:48:31.48

お客さんが属性バリデーションも他のバリデーションフレームワークも使っちゃダメって言うんだけど
どうすれば楽にバリデーションできる？
言語はC#
テキストリソースは全てDBで管理されている
ロケールによってエラーテキストを変えなければならいとする

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

>>468
普通に作る以外にない
ちなみにダメって言う理由は何なの？

あとバリデーション自体と
バリデーション結果に応じたエラーテキストの選択は
分けて考えたほうがいいよ

**デフォルトの名無しさん** · 2017/10/12(木) 22:34:53.95

>>469
属性やフレームワークは設定方法がよくわからないのでメンテナンスの時に困るから

ひたすら単調にif文をズラズラと書いてるんだけどシンドイ
項目数が100近いPageもあってそれぞれが何種類かのバリデーションを行うからバリデーションだけで数百行のメソッドになることもある

**デフォルトの名無しさん** · 2017/10/12(木) 23:00:42.84

>>470
xmlでルール書くやつは敬遠されるのは理解できなくもないが
単純な属性ベースは分かりやすいしメンテしやすいのにね

楽しようとすれば結局自前で簡易的なフレームワーク風のものを作ることになる
あまりにも数が多いならコード生成という選択肢も

**デフォルトの名無しさん** · 2017/10/12(木) 23:06:26.57

>>470
ライセンス的に問題がないものをコピーすればいい

あ · 2017/10/13(金) 00:23:50.41

>>468
フレームワーク書いたらだめなの？

**デフォルトの名無しさん** · 2017/10/13(金) 01:47:19.56

>>470
Frameworkを使わないc#ってどんだけマゾなの？ランタイム自分で書いてんの？

**デフォルトの名無しさん** · 2017/10/13(金) 01:48:05.83

>>470
そんな理由にならない理由に従おうとする方がバカ

**デフォルトの名無しさん** · 2017/10/13(金) 02:48:12.40

今回みたいな例だとライブラリを使わないで自作するとしたら
使った場合に比べて何倍ぐらいの金額を請求する？

**デフォルトの名無しさん** · 2017/10/13(金) 02:56:05.56

バリデーションが全体の工数に占める割合がわからないとなんともいえないけど、数倍なんてなるわけないだろアホ
どんだけバリデーションばっかやってるプロダクトを想定してんだよ

客に費用の話をするとき、「通常この規模だと20人月ですが、バリデーションライブラリが使えないので+50人月かかります」とでも言うのか

**デフォルトの名無しさん** · 2017/10/13(金) 03:43:57.20

はぁ？増えた分の請求は当然するだろ。当たり前のことを当たり前にするだけだぞ

**デフォルトの名無しさん** · 2017/10/13(金) 04:33:13.10

>>476
なんでいきなりフレームワークじゃなくてライブラリの話になってんの？

**デフォルトの名無しさん** · 2017/10/13(金) 04:36:24.84

>>476
既存のフレームワーク使わずに自作する方が工数膨らむに決まってんだろ
カプコンレベルじゃないとスキル的にも厳しい

**デフォルトの名無しさん** · 2017/10/13(金) 04:37:49.67

ごめん勘違い
工数の膨らみ方が半端なさ過ぎて非現実的ってのが言いたかった

**デフォルトの名無しさん** · 2017/10/13(金) 04:40:34.82

ひとまず使って組んで元の処理コピーして置き換えちゃえばいいんちゃう？
バリデーションのソースってあんでしょ？

**デフォルトの名無しさん** · 2017/10/13(金) 05:21:13.13

>>479
バリデーションのフレームワークなんてないでしょｗ

**デフォルトの名無しさん** · 2017/10/13(金) 07:46:49.24

>>483
フレームワークの一部としてバリデーションがあるやろ

**デフォルトの名無しさん** · 2017/10/13(金) 14:51:54.32

バリデーションのフレームワーク普通にあるだろw

**デフォルトの名無しさん** · 2017/10/13(金) 16:33:32.34

ごめん、何言ってんだかよくわかんないんだけど、
まず、>>468のバリデーションって、一体何に対するバリデーションの話してるの？

**デフォルトの名無しさん** · 2017/10/13(金) 23:02:45.05

if (!validateRequired("#foo")) {
var msgFormat = getResource("error.required");
var label = getLabel("#foo");
addMessage(msgFormat, label);
addCss("#foo", "input-error");
}
以下100項目繰り返し

これ以上簡潔で保守性の高いバリデーションが存在しない件
OOPは物事を無駄に複雑化するばかりで役に立たん

**デフォルトの名無しさん** · 2017/10/13(金) 23:14:22.48

>>487
バリデーションとメッセージとUIを一緒くたにするな
どこが保守性高いんだか、見づらいだけだろ

**デフォルトの名無しさん** · 2017/10/13(金) 23:14:50.38

>>487
それは普通に抽象化できるだろ
そんなん100個も繰り封ﾔしてたらサブャCボ出るわ

**ャfフォルトの名末ｳしさん** · 2017/10/13(金) 23:16:05.73

だよなー
判定と表示は分けようって最初に教わる

**デフォルトの名無しさん** · 2017/10/13(金) 23:18:48.84

バリデーションはYAMLで定義するのが一番だって最近気づいた

**デフォルトの名無しさん** · 2017/10/13(金) 23:31:13.18

御託はいいからコード書いてみれば？
俺のコードより明確で保守性の高いコードをかけるとは思えんが

**デフォルトの名無しさん** · 2017/10/13(金) 23:36:42.10

こーゆー上から目線なやつは自分の思い描くもの以外は全部クソって発想なのでめんどくさい

**デフォルトの名無しさん** · 2017/10/13(金) 23:38:06.15

そもそも俺のコードは判定と表示が綺麗に分かれてるし

**デフォルトの名無しさん** · 2017/10/14(土) 00:25:45.56

煽って教えてもらうスタイルに転向した？

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

きも

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

バリデーション処理はexcel表から生成するものだよ
素人は手書きするらしいけどね
プロはこんなめんどくさいコードは書かない

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

>>497
マジで！？どういう仕組み？

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

**デフォルトの名無しさん** · 2017/10/14(土) 11:22:11.10

コピペプログラマは余計なコードを増やしてくれるな

foreach(validate as entry){
if (!validateRequired(entry.name)) {
var msgFormat = getResource(entry.resource);
var label = getLabel(entry.name);
addMessage(msgFormat, label);
addCss(entry.name, entry.clazz);
}
}

簡単に100分の1になるだろ
validateもプログラムからデータにしたら保守性あがるだろ
Modelからvalidateを収集するようにしてビジネスロジックを集約してもいいけど
今更そこまで設計変えるのは愚策か

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

>>500
これじゃ何やってるかお客様がわからないだろ
素直にエクセルにしろって

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

お客様がソース読むのかよ w
条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ

**デフォルトの名無しさん** · 2017/10/14(土) 11:47:29.29

結局コード生成するんじゃないかwww
なら最初からコード生成する前提で余計な手書きコードは書かない方がいい
プログラミングの基本すらわかってないのかよ

**デフォルトの名無しさん** · 2017/10/14(土) 12:02:38.48

でた、いつもの自称プロさんw

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

自称プロってwww
ここは学生専用だったか？

**デフォルトの名無しさん** · 2017/10/14(土) 12:51:39.31

>>502
> 条件をお客様が決めるならExcelでもらって>>500のentryを生成するツールを作ればいいだけ

発想が逆。YAML形式などで条件を書いて
必要ならばExcelに変換する。
Excelなんてサイズが無駄に多すぎて差分の比較もできないから
バージョン管理は事実上無理だろ

**デフォルトの名無しさん** · 2017/10/14(土) 12:56:11.86

YAML形式の何が良いかというとシンプルで見やすいから
お客様が直接読み書きできるってことだな
下手なCSVファイルよりもメンテナンス性が良い

**デフォルトの名無しさん** · 2017/10/14(土) 13:15:41.53

まあそのデータなら差分出したきゃ
CSVで出して比較できそうだけどな