Function "normalization"

Question

Here's a concept from the DB normalization theory:

Third normal form is violated when a non-key field is a fact about another non-key field.

Doesn't it makes sense for a similar concept be applied for functions / function parameters?

Consider the following function:

function validate(field, rule_name, rule_value);

// Usage

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

In this example function, the third parameter describes the second and seems to have no "attitude" towards the first. It feels like a denormalized function in a way.

I don't know if I'm formulating this right, but I can notice an analogy between table names and table fields, in the DB, and function names and function parameters.

If such analogy makes sense, wouldn't it also make sense for function designers to borrow concepts from the DB normalization theory?

score 3 · Accepted Answer · answered Feb 28 '11 at 16:50

3

To me that function does suggest some sort of "rule" concept that is parametrized by a value. It could be made more generic if you could have a list of such rule/value pairs and validate by looping over all the rules.

Looking at it another way, nothing seems to be lost if you interpret the functions as follows:

function validate(field, rule);

// Usage

validate("password", MinLengthRule(6));
validate("password", RegExRule("/^\S+$/"));

answered Feb 28 '11 at 16:50

Joris Timmermans

10,814
2
49
75

I'm so glad you posted this because now I know that it's not just me that feels that there's something wrong with the function. What is it that makes it feel wrong, though? What "rule" does it violate? – Emanuil Rusev Feb 28 '11 at 16:55
2

@Emanuil If I were to take a stab at it, the original function violates separation-of-concerns: @MadKeithV's method allows the `validate` function to have its actual validation behavior injected, which makes it highly reusable. The original, even with the simple examples given, requires multiple signatures to accommodate rules on different data types. – Dan J Feb 28 '11 at 17:57
@djacobson - yes, thanks, that's actually what was in the back of my mind. Validation becomes a single function with one signature, and a "rule" becomes an abstraction that can be easily extended to process any "field" string and return a boolean value to say if the string passes validation or not. – Joris Timmermans Mar 01 '11 at 08:05

score 1 · Answer 2 · answered Feb 28 '11 at 17:27

1

Consider the OOP variant of your example, when using the Strategy design pattern. In that case it would be natural (to me, at least) for the rule name to be an attribute of the Rule class, which would support your idea.

answered Feb 28 '11 at 17:27

Raedwald

46,613
43
151
237

That's a very interesting angle on the subject. – Emanuil Rusev Feb 28 '11 at 17:29
I see that @MadKeithV also considers use of a rule object. – Raedwald Feb 28 '11 at 17:35

score 0 · Answer 3 · answered Feb 28 '11 at 16:10

0

Don't agree. The 6 doesn't describe min_length. Only both create something meaningfull.

The garbage characters doesn't mean anything neither until you notices it is a regexp.

answered Feb 28 '11 at 16:10

Jan Zyka

17,460
16
70
118

2

The thing is `rule_name` and `rule_value` have a special relationship. The way `rule_value` is interpreted is determined by the value of `rule_name`. As you can see, the value is an int in the first usage example and a regex in the second. – Emanuil Rusev Feb 28 '11 at 16:18

Function "normalization"

3 Answers3