5

DB正規化理論の概念は次のとおりです。

非キー フィールドが別の非キー フィールドに関する事実である場合、第 3 正規形に違反します。

関数/関数パラメーターに同様の概念を適用するのは理にかなっていますか?

次の関数を検討してください。

function validate(field, rule_name, rule_value);

// Usage

validate("password", "min_length", 6);
validate("password", "matches_regex", "/^\S+$/");

この例の関数では、3 番目のパラメーターは 2 番目のパラメーターを記述しており、最初のパラメーターに対する「態度」がないように見えます。ある意味、非正規化関数のように感じます。

私がこれを正しく定式化しているかどうかはわかりませんが、DB 内のテーブル名とテーブル フィールド、および関数名と関数パラメーターの間に類推があることに気付くことができます。

この類推が理にかなっているとすれば、関数設計者が DB 正規化理論から概念を借用することも理にかなっているのではないでしょうか?

4

3 に答える 3

3

私には、その関数は、値によってパラメーター化されたある種の「ルール」の概念を示唆しています。そのようなルール/値のペアのリストを取得し、すべてのルールをループして検証できれば、より一般的なものにすることができます。

別の見方をすると、関数を次のように解釈すると、何も失われません。

function validate(field, rule);

// Usage

validate("password", MinLengthRule(6));
validate("password", RegExRule("/^\S+$/"));
于 2011-02-28T16:50:25.490 に答える
1

Strategy設計パターンを使用する場合は、例の OOP バリアントを検討してください。その場合、ルール名がクラスの属性であることが（少なくとも私にとっては）自然でありRule、それはあなたの考えをサポートします。

于 2011-02-28T17:27:47.460 に答える
0

同意しないでください。は6説明しませんmin_length。意味のあるものを作成するのは両方だけです。

ガベージ文字は、正規表現であることに気付くまで何の意味もありません。

于 2011-02-28T16:10:37.373 に答える