オブジェクト指向システムの設計 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/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で出して比較できそうだけどな

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

Excelでも管理できてるなら別にいいと思うぞ
客や開発メンバーのリテラシーレベルに合ってるなら
無理に違うフォーマットを強要する必要はない
openxmlとか使えば差分比較だけならできる

むしろルールと処理を密結合させても平気な神経のほうが理解できない
そのうえプロを自称してドヤるww

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

>>509
客にExcelを "ルール通りに" 使わせるという
リテラシーレベルをもとめるな

勝手にフォーマットを変える、勝手にセルを結合する。
どこからかコピペした結果おかしくなって直さない
追加分とかいって差分を送りました。そっちで結合してください
とか、毎回人手で対応しなきゃならない作業が発生するぞ。
こっちで決めた使い方のルールを守ってくれやしない

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

> openxmlとか使えば差分比較だけならできる
むり、見た目同じように見えても、
レイアウト属性など関係ない情報の
大量の差分までできて管理できない

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

>>511
属性情報は無視してdiff出せるよ
色変えたとか罫線追加したとかそのレベルの差分確認したいとなると
専用ツール入れないと実用レベルでは使えない

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

ヴァリデーションフレームワークってどれも中途半端だよな
ちょっと複雑なヴァリデーションをしようとすると適用不能になる
しょうがないからカスタムコードを書くことになるんだけどフレームワークとケンカし始めるからフレームワークは規約で禁止って流れになる
日本の厳しい要件についてこれる柔軟性の高いフレームワークは無いものか

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

>>510
その辺は上の自称プロさんならVBA使ってルール守らせるExcel作るだろ
俺は別にExcel推奨したいわけじゃないぞ

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

>>506
意味わからん
YAMLで書ける客がどれだけいるんだよ w
そもそも客がYAMLで書けるならExcelに変換なんて要らん、そのままソースに変換するなりすればいい
要件によっては実行時にそのまま読み込んでもいいかも知れんし
まあ>>500程度ならcsvとかで充分だと思うが

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

>>510
> とか、毎回人手で対応しなきゃならない作業が発生するぞ。
どんだけ低レベルの客と付き合ってるんだよ w

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

>>512
例えばこの例だと行を一行追加して、A2にあったWorldが
A3に変わった時の差分はこんなふうに表示される
http://blog.modd.com/entry/2016/01/26/125206

diff -u a.txt b.txt
--- a.txt 2017-10-14 14:16:59.481494825 +0900
+++ b.txt 2017-10-14 14:17:20.601528128 +0900
@@ -5,6 +5,12 @@
</row>
<row r="2">
<c r="A2" t="str">
+ <v>OOXML</v>
+ </c>
+</row>
+<row r="3">
+ <c r="A3" t="str">
<v>World</v>
</c>
</row>

Worldがもともとrow r="2"、c r="A3" だったわけだが、たった一行挿入することで、
2行目以下の、"全ての行データに対して" このようにrowとcが変化するわけだよ。
それで差分を管理できるわけ無いだろ。

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

>>515
> YAMLで書ける客がどれだけいるんだよ w

こっちでこんな感じで書いてくださいっていうだけ。
それはExcelと同じ。

違うのは、Excelでは条件を指定した所で
見えない情報（フォーマット情報など）が
大量に埋め込まれるということ。
そしてその見えない情報を正しく修正するのが大変だということ

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

>>516
> どんだけ低レベルの客と付き合ってるんだよ w

逆。客のレベルがExcelを無駄に使えるから
セルの結合とか色を変えたりしてくる。
Excelはできることが多すぎるんだよ。
余計なことをなんでもできてしまう。

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

>>513
> ちょっと複雑なヴァリデーションをしようとすると適用不能になる

普通はちょっと複雑なバリデーションを書くための方法がフレームワークに用意されてる。

それに、ちょっと複雑なところだけ別にやればいいだけ。

100個のうち1個のマイナーケースに対応できないから、
100個すべてめんどくさい方法で作りましたとかアホでしか無い。

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

>>520
日本の業務アプリを甘く見過ぎだろ
カスタムコード書きまくらないと対応できねえよ
アホみたいにシンプルなUIしか書かなくてもいいWeb屋はスキル要らないし気楽でいいよな

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

>>521
じゃあバリデーションのすべてがカスタムコードである例を教えてください

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

例えば郵便番号のバリデーションが
カスタムコードとか言いそうで笑えるｗ

そして郵便番号を使うたびに
同じバリデーションをコピペしてるんだろうな。

普通は関数にしてフレームワークに登録すれば終わり
あとは同じバリデーションを使いまわしできる。

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

あぁ、当たり前だけど範囲チェックや型チェックや正規表現チェックとか
単純なものだけではなく、カスタムバリデーションや条件付きバリデーションなんかも
フレームワークの基本機能の１つだと先に言っておこう

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

>>518-519
> こっちでこんな感じで書いてくださいっていうだけ。
えっ？
YAMLの書き方から教えるのかよ...
Excelでフォーマット守れって言うこともできない客にYAML書けるとか無職の妄想乙 w

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

日本の業務アプリを作っているところがアホなのは、
バリデーションが正しく機能しているかは
アプリを実行して画面からぽちぽち実際と同じ使い方をして
検証していることなんだよな。同じ内容のバリデーションであっても
項目ごとに検証する。それがテスト時間を無意味に増やしてしまっている。

本来はバリデーションのテストは種類ごとに１つ（すごく当たり前だがｗ）
そして、画面の項目ごとに、想定しているバリデーション名が
設定されているかを設定ファイルを見て確認するだけ。
実際に動かしてテストはしない。

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

>>517
試したけど俺の環境では↓こうなるよ
diffだけなら十分実用レベル

$git diff
diff --git a/book.xlsx b/book.xlsx
index c75fc9a..6215aa2 100644
--- a/book.xlsx
+++ b/book.xlsx
@@ -1,5 +1,6 @@
Sheet1
Hello
+ OOXML
World

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

>>525
> YAMLの書き方から教えるのかよ...

YAMLの書き方はExcelよりも簡単だよ。
Excelは知らない人が使いこなすためには
数週間とか数カ月かかるが、

YAMLだとフォーマット用意して、
これと同じように書いてくださいで説明終わり。

Excelでフォーマットを守れないのは、
これと同じように書いてくださいと言っても、使い方が難しいから。
俺の母親は、文字の自動補間機能のせいで「1」と入力しようと
しても「10」と補完されてしまって困っていたな。

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

>>527
実際のイメージ
https://i.imgur.com/uatG5Vj.png

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

>>527
じゃあ今度はある程度データを入れて、同じ内容のセルを結合する前後で
ためしてみそれがどう見えるかを確認したら絶望することになるから

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

ちなみに補足しておくと、>>529はxlsxを直接比較しているのではなく
xlsxをテキストに変換してから比較している。
その時にフォーマット情報などいろいろ抜け落ちる。

だから「取り消し線のところは無視してください。」なんてのはわからない。
このようにExcelはなんでもできてしまうから、
重要な情報が抜け落ちる所に書かれてあった時に比較できない。

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

>>528
Excelの使い方が難しい？
YAMLがきちんと書けてExcel使えない奴なんて見たことないけどな
お前のおかんはYAML書けるのか？ w

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

>>526
俺はやるべきだと思うなぁ
だって外人のアプリってそのせいなのかどうなのか知らんけど
よく動いてないじゃんｗ

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

>>531
>>500にはフォーマット情報なんて要らんだろ
どんどん深みにはまってるぞ w

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

xmlはプログラマしか編集できない上に
ファイルがでかくなると読み込み速度ヤバイので駄目だよ

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

俺が昨日書いた検証処理の一部
実際にはこれの数十倍の検証ルールがあると考えてほしい
フレームワークで簡単にできるなら教えてほしいおねがいします

webアプリ
テーブルをバリデーションする

列は4つでそれぞれinputを持ってる
typeは順に「checkbox, text, text, text」

検索でバックエンドから取ってきたデータがこのテーブルに表示される
これを手入力で編集してバックエンドに保存する
再検索できるが検索時にはバリデーションしなくてよい
保存するときはバリデーションを実行する

メッセージはローカライズすること
すべてのテキストリソースはバックエンドで管理されている

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

1列目のcheckboxがOFFの行はバリデーションしなくていい
2〜4列目のtextがすべて未入力の行はバリデーションしなくていい

2, 3列目が空白の場合エラー
2, 3列目が整数でない場合エラー
2, 3列目の合計値が1000を超えたらエラー

1列目のcheckboxがONの行の2, 3列目の合計値が10000を超えたらエラー

4列目はオプション
10文字以上の場合エラー
入力された文字列がバックエンドに登録されていない場合エラー

エラーメッセージは重複を排除して昇順に並び替えて所定の ul の子要素として追加する

エラーがあった入力項目は背景色を赤くする
同じ行で1つでもエラーがあった行は罫線を赤くする

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

>>533
> だって外人のアプリってそのせいなのかどうなのか知らんけど
> よく動いてないじゃんｗ

外人のアプリって何？Windows？Linux？MacOS？

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

OSをアプリって言う奴初めて見たw

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

>>537
どうでもいいけど、列目～とか言って時点で、画面と密結合してんなーとしか思えんなｗ

列があれば行もあるんだろうけど、一行単位で処理してるようだから、
一行が、一クラスの一インスタンスと考えればよいだろう
1000超えたらエラーなのか10000超えたらエラーなのか分からんが。

画面表示周りにビューの仕事でこれはバリデーションではない。
バリデーション結果オブジェクトを見てビューで表示さればいいだけ（何度も言わせないように）

長くなったのでコードは次のレスに書く

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

class Row
　include ActiveModel::Validations

　def col1_condition; end
　def col2_value; end
　def col3_value; end
　def col4_text; end

　def condition;
　　col1_condition && col2_value.present? && col3_value.present? && col4_text.present?
　end
　def col2_plus_col3_number
　　col2_value + col3_value
　end
　// ↑ここまでは単なるクラス定義
　//↓ここ以下がバリデーション

　validates :col2_value numericality: true, presence: true, if condition
　validates :col3_value numericality: true, presence: true, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 1000, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 10000, if condition

　validates :col4_text; maximun: 10, if condition
　validate :col4_registered

　def col4_registered
　　// 入力された文字列がバックエンドに登録されていない場合エラー
　end
end

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

× validate :col4_registered
○ validate :col4_registered, if: condition

っていうか全部 if の後の: 付け忘れてたｗ

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

>>531
だからそれは意図して属性情報は差分比較しないようにしてるからじゃん。。
なんなんその言いがかり

セルの結合もデータ的に何を意味してるのかVBA使うやつなら当然知ってるし
データとして使うExcelシートなら書式設定は変更されないようにロックするだろ
その辺のリテラシがないならExcel使うってのは選択肢にはならないわな

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

>>543
すべての属性情報が無視していいとは限らないからね。
属性情報として重要な事が書かれているかもしれない。
そういう無視して良いのがないかわからないのがExcelの欠点の１つ
Excelになれている人ほど、余計な工夫をしてくる。

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

>>541
これはなんの言語ですか?
JavaScriptだとどうなるのでしょうか?
10000を超えないのは複数の行について合計した時の話です
メッセージやCSSの処理はどうすればいいでしょうか？

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

>>545
Ruby & Rails

JavaScriptはしらん。けど大差ないものは作れるだろ
文法上の制約があるとしてんもこんなふうになる程度

validates("col2_value", {numericality: true, presence: true, if: "condition"})

> 10000を超えないのは複数の行について合計した時の話です
一行ごとに保存できるのであれば、保存する時に
この一行を保存するときに10000を超えるかどうかを調べればいい

一行ごとに保存できない、つまりまとめて保存するならば、
一行に相当するオブジェクトに含まれる配列として
テーブル全体を持っておき、そのテーブルの数値の合計を調べれば良い。

> メッセージやCSSの処理はどうすればいいでしょうか？
んなもん、バリデーション結果を返して、そこに含まれるerrorsを
画面に表示すればいいだけ。ローカライゼーションは別の話。

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

>>546
なるほど
なんとなくわかりかけてきました

肝心のエラー情報はどうやって、どのような形式で取得しますか？
検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？

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

> 肝心のエラー情報はどうやって、どのような形式で取得しますか？
フレームワーク次第なんだんだからそのやり方に従えばいい

> 検索や保存など処理によって検証内容が異なる場合は似たようなクラスを２つ用意するのでしょうか？
似たようなもの＝同じではない＝違うもの

違うなら別々に用意しなければいけないし、
100%まったく同じならば、使い回せばいい。
一部が全く同じならば、同じ部分だけつかいまわせるように切り出せばいい

絶対にやってはいけないのは、違うところがあるのに
似ているからという理由だけで違うものを使いまわすこと
そんなことをするとある修正が全く無関係な所に影響を及ぼしてしまう。

異なるなら別のものを作るのは当たり前の話だ。

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

>>544
> すべての属性情報が無視していいとは限らないからね。
限るだろ ⇒ >>500 のデータなんだから w

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

あとなぁ、コピペはいけないってことの意味を勘違いしてるやつが多いんだよな。

単語、文字列をコピペしたらいけない。ファイルをコピペしたら
いけないって勘違いしてる。

コピペしたらいけないのは処理だってーの。
処理はテストするものが定義はテストする意味はない。
定義でするべきなのはテストではなくて確認
確認は目視でもOKなんだよ。

バリデーションなんてほぼ定義にできてしまうのだから
テストする項目にはならない。確認する項目。
だからYAMLに分離して、技術者じゃなくても確認できるようにしておけば良いんだ。

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

>>548
ちなみにrubyだとバリデーション結果はどうなってるんですか？

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

>>549
問題はExcelには>>500のデータ以外の情報も自由に入れられてしまうところなんだよ。
そしてそれがわかりづらい。

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

>>551
RubyじゃなくてRailsな。バリデーションはRailsというフレームワークの一機能
バリデーション結果のオブジェクトの中に
errosってのがあってそこに項目ごとにエラーメッセージが入ってる。
またバリデーション結果のオブジェクトにはvalid?、invalid?メソッドがあって
全体がバリデーションでOKだったかどうかもわかる。

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

>>553
どの項目でエラーが出たかはわかりませんか？
背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
ここも粗結合にしたまま対応できるんでしょうか？

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

>>541
この場合のcheckboxは更新対象を示すフラグっぽいから
2~4列目のモデルの要素とは別にしたほうがいいんじゃないかな

ONになってる行のコレクション対してバリデーションすればいいので
if conditionは全部消せる

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

>>554
だからerrorsオブジェクトの中に項目ごとにエラーが入ってるって言ったろ

> 背景色を変えるには入力項目のidとrubyオブジェクトのプロパティとのひも付けが必要だと思いますが
いらねーよ。

どうせエラー画面がでたら、エラーが出たその項目の値を表示するだろ？
その項目のすぐ下にでもエラー情報だせばいいだろ。

あ？id？エラー情報の表示にidなんていらねーからな。
まさかと思うが、CSSに全項目書いてたりしないよな。
それならclass使え。アホらしいから

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

>>555
そこらへんはどうでもいいやｗ
重要なのはこの程度でカスタムコード書きまくらないと対応できないとか
思っていたことがはっきりしたってだけ

で、俺の意見はここからさらに先で、Railsのバリデーションコード
あの程度の情報量であれば、YAMLに簡単に外だしできるので、
外出して、客にもレビュー可能にして、価値の低いテストを減らしたい。
YAMLにすればフロントエンド側（JavaScript）でも再利用できるだろうし。
なんでもかんでもクラスに定義するのが良いとは思わないな。

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

その先はないので程々にした方がいい
設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて
世界中でこれは使い物にならんと判定されたものだよ

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

バリデーションすなわち入力検証をプレゼンテーションから切り離して考えるのもバカバカしい
入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
ドメインモデルに入力検証をやらせるのは愚かとしか言いようがない

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

> 設定ファイルでバリデーションするアイデアはJavaとか他の言語が大昔にとっくに通過していて

それはXMLが失敗の原因だった。
XMLにはタグや属性という技術者しか知らないものが
あるからだめだったんだよ。

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

>>559
> 入力検証はViewあるいはViewModelに属する処理だからプレゼンテーションに入るのが正解
YAMLにすることでそれも実現できる

バリデーションは、プレゼンテーションだけのものではない
プレゼンテーションでもドメインモデルでも使われるものだ

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

更に言うならば、バリデーションはフレームワークではなく
言語仕様に組み込むべきものだよ。
本質的にはD言語の契約プログラミングと同じものなんだから

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

>>560
違う

モデル定義とバリデーション定義が離れすぎていること
コンパイルできないから開発環境の恩恵をうまく得られないこと
バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること

これらが問題点

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

>>563
> バリデーションを書くのは開発者であるが開発者に馴染みのある言語はXMLやYAMLではなくJavaやC#であること

あんたはバリデーション処理とバリデーション定義をごっちゃにしてる。
バリデーション処理は動くコードで書くが、
バリデーション定義は動くコードではない。

JavaのXMLなんかも動くコードではないから
これは定義であり、定義の内容をJavaやC#で書く意味はない。
だってただのデータだぞ？ハッシュで持たせればいい程度の情報。

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

>>559
俺もその意見に賛成かなぁ

画面が変わったら変わった画面用のチェックが必要になってる気がするわ

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

>>561
違う

プレゼンテーションレイヤではオブジェクトが不正な状態を受け入れることが前提
不正な状態を検知する処理がバリデーション

ドメインレイヤではオブジェクトは不正な状態は受け入れない
プロパティの不正な値をセットしようとした瞬間に例外
メソッドに不正な引数を与えた瞬間に例外
これはバリデーションではない
ドメインレイヤでは契約を使う

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

>>541の例で言えば

　validates :col2_value numericality: true, presence: true, if condition
　validates :col3_value numericality: true, presence: true, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 1000, if condition
　validates :col2_plus_col3_number less_than_or_equal_to: 10000, if condition

　validates :col4_text; maximun: 10, if condition
　validate :col4_registered

この部分がバリデーション定義。
簡単にYAMLにできるし、客が検証したい部分でも有る。

numericalityの内容とかconditionの内容がバリデーション処理（の一部）

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

>>566
> ドメインレイヤではオブジェクトは不正な状態は受け入れない
> プロパティの不正な値をセットしようとした瞬間に例外
> メソッドに不正な引数を与えた瞬間に例外
> これはバリデーションではない

バリデーションに引っかかった結果をどう表示するか？が
プレゼンテーションでやるべきこと。

バリデーションそのものは使いまわすことができる。

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

>>566
ctrl+vで貼った1GBテキストとかメモリに保持すんの？

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

>>564
それはあなただけが感じる特殊な感覚だよ
世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった
XMLよりYAMLの方が多少マシという点は認めるが上記の手法に比べればどんぐりのせくらべといったところだ

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

>>570
> 世界中のプログラマは設定ファイルを捨て去り属性やアノテーションを使うようになった

設定ファイルを捨ててYAMLにしたの間違いだろｗ

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

設定をYAMLではなくソースコードに埋め込むのを見てみたいもんだがｗ

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

お前ら、喧嘩するな
どこに持とうがチェック項目は増えても減ってもいないんだぜ

だったら一番やりやすい画面かな

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

>>573
いや増えてる。画面でやると画面ごとにバリデーション処理が増えてしまう。
だから数を減らすにはより中心であるモデルで行う必要がある。

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

ファイルに外だししたからチェックしなくていいですなんて
んなわけねぇだろ

今時エロ本の竿役だってそんなこと言わねぇよ

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

>>574
チェックはしなきゃ駄目だよ

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

>>572
JavaのBean ValidationやC#のDataAnnotationsを調べてみればいい
モデルとバリデーション設定を分離して管理する意味がないとわかるはずだ

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

>>552
低能相手ならそうかもな
御愁傷様としか言えないけど w