2011-02-28 10 views
5

est ici un concept de la théorie de la normalisation DB:Fonction « normalisation »

Troisième forme normale est violée lorsqu'un champ non-clé est un fait d'un autre domaine non-clé.

N'est-il pas logique qu'un concept similaire soit appliqué aux fonctions/paramètres de fonction?


Tenir compte de la fonction suivante:

function validate(field, rule_name, rule_value); 

// Usage 

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

Dans cet exemple, la fonction, le troisième paramètre décrit la deuxième et semble ne pas avoir « attitude » vers le premier. Cela ressemble à une fonction dénormalisée d'une certaine manière. Je ne sais pas si je formule ce droit, mais je peux remarquer une analogie entre les noms de table et les champs de table, dans la base de données, et les noms de fonction et les paramètres de fonction.

Si une telle analogie a du sens, cela n'aurait-il pas aussi un sens pour les concepteurs de fonctions d'emprunter des concepts à la théorie de la normalisation de DB?

Répondre

3

Pour moi, cette fonction suggère une sorte de concept de "règle" qui est paramétré par une valeur. Il pourrait être rendu plus générique si vous pouviez avoir une liste de telles paires règle/valeur et valider en bouclant toutes les règles.

regardant une autre façon, rien ne semble être perdu si vous interprétez les fonctions suivantes:

function validate(field, rule); 

// Usage 

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

Je suis tellement contente que tu aies posté ça parce que maintenant je sais que ce n'est pas seulement moi qui pense qu'il y a quelque chose qui cloche avec la fonction. Qu'est-ce qui fait qu'il se sent mal, cependant? Quelle «règle» viole-t-elle? –

+2

@Emanuil Si je devais y aller, la fonction d'origine viole la séparation des préoccupations: La méthode de @ MadKeithV permet à la fonction 'validate' d'avoir son propre comportement de validation injecté, ce qui la rend hautement réutilisable. L'original, même avec les exemples simples donnés, nécessite plusieurs signatures pour s'adapter aux règles sur différents types de données. –

+0

@djacobson - oui, merci, c'est en fait ce qui me restait à l'esprit. La validation devient une fonction unique avec une signature, et une "règle" devient une abstraction qui peut être facilement étendue pour traiter n'importe quelle chaîne "champ" et renvoyer une valeur booléenne pour dire si la chaîne passe la validation ou non. –

0

Je ne suis pas d'accord. Le 6 ne décrit pas min_length. Seulement les deux créent quelque chose de significatif.

Les caractères parasites ne signifient rien tant que vous ne remarquez pas qu'il s'agit d'une expression rationnelle.

+2

La chose est 'rule_name' et' rule_value' ont une relation spéciale. La façon dont 'rule_value' est interprétée est déterminée par la valeur de' rule_name'. Comme vous pouvez le voir, la valeur est un int dans le premier exemple d'utilisation et une regex dans la seconde. –

1

la variante Considérez POO de votre exemple, lorsque vous utilisez le modèle de conception Stratégie . Dans ce cas, il serait naturel (pour moi au moins) que le nom de la règle soit un attribut de la classe Rule, ce qui étayerait votre idée.

+0

C'est un angle très intéressant sur le sujet. –

+0

Je vois que @MadKeithV considère aussi l'utilisation d'un objet de règle. – Raedwald