5

这是来自 DB 规范化理论的一个概念:

当一个非关键字段是关于另一个非关键字段的事实时,违反了第三范式。

将类似的概念应用于函数/函数参数是否有意义?


考虑以下函数:

function validate(field, rule_name, rule_value);

// Usage

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

在这个示例函数中,第三个参数描述了第二个参数,并且似乎对第一个参数没有“态度”。在某种程度上,它感觉像是一个非规范化的函数。

我不知道我是否正确地制定了这一点,但我可以注意到数据库中的表名和表字段以及函数名和函数参数之间的类比。

如果这样的类比有意义,那么函数设计者从 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

在使用策略设计模式时,请考虑示例的 OOP 变体。在这种情况下,规则名称是类的属性是很自然的(至少对我来说)Rule,这将支持您的想法。

于 2011-02-28T17:27:47.460 回答
0

不同意。6min_length描述。只有两者都创造了有意义的东西。

在您注意到它是一个正则表达式之前,这些垃圾字符也没有任何意义。

于 2011-02-28T16:10:37.373 回答