Je rencontre souvent des situations dans lesquelles j'ai envie de créer une instance d'un objet en le transmettant certaines données données ou peut-être un autre objet, mais que les données ou l'objet doivent être valides ou dans le bon état. Je suis toujours un peu peu claire sur le moyen "correct" de faire cela. Voici mon exemple:
donné cette classe: p> Il est possible de rencontrer certains problèmes si vous le faites: P> class BusinessObject()
{
const Threshold = 10;
public static Create(SetOfData<SomeType> setofdata)
{
if (setofdata.count > Threshold)
{
return new BusinessObject(setofdata);
}
else
{
return null;
}
}
private BusinessObject(SetOfData<SomeType> setofdata)
{
// performance some business logic
// set properties
}
}
5 Réponses :
Je ne peux pas dire la méthode "correcte". Mais je peux vous dire mon chemin =)
Je choisirais le motif d'usine. Si vous ne voulez pas abandonner votre application en cause d'une erreur de validation, l'usine pourrait remplir les pièces défectueuses avec des valeurs par défaut.
Peut-être que vous pourriez implémenter le modèle de stratégie à votre usine (méthode) Code> Pour fournir des capacités de validation: public static Create(SetOfData<SomeType> setofdata, DataValidationStrategy validation)
{
if (validation.isValid(setofData))
{
return new BusinessObject(setofdata);
}
else
{
return null;
}
}
Je crois que cet objet NULL serait nuisible dans cette situation. Le consommateur peut vérifier contre NULL et supposer que si le retour BusinessObject n'est pas NULL, il a été correctement créé. Et vérifier si l'objet renvoyé par Create n'est pas un objet NULL serait un exemple d'utilisation incorrecte du motif.
La validation du constructeur IMHO est la meilleure pour de nombreuses situations où vous devez vous assurer qu'aucun objet ne peut être créé que si un paramètre spécifié étant défini. Cependant, cela a une mauvaise implémentation lorsque: < / p> pour le point n ° 1 et 2, je ne peux pas suggérer une autre option, à l'exception de la demande - Valider - Soumettre le mécanisme. pour point n ° 3, la raison est que la classe fera Trop pour la validation elle-même et la création d'un code monolithique. S'il y a beaucoup de logique de validation, je suggère de mettre en œuvre un motif de constructeur avec un validateur injecté et de créer le constructeur de cette application modulaire Programmation et prévenir le code monolithique. Les deux du code sont les suivants:
businessObject interne.
Je crois que c'est une pratique générale de jeter une exception d'une méthode comme créer code> lorsque les arguments sont incorrects. Vous avez raison dans vos réservations sur le retour null code> dans ce scénario et essayant d'éviter d'utiliser des exceptions pour le contrôle de flux. Vous pouvez simplement avoir: public bool TryBuild(SetOfData<SomeType> setofdata, out BusinessObject businessObject)
{
if (validator.IsValid(setofdata))
{
businessObject = new BusinessObject(setofdata);
return true;
}
businessObject = null;
return false;
}
Regardez sur framework ovale. Vous pouvez l'étendre avec vos propres annotations.
Juste une note, les usines ne ont-elles besoin d'avoir "un type ou une énumération" transmise; Ils peuvent prendre tout type de données (même un
SetOfData ) ou aucune donnée du tout (paramètre non). Les exemples ont tendance à les utiliser car c'est un moyen assez commun / simple d'utiliser / les décrire. Si vous le souhaitez, vous pouvez toujours créer un BusinessObjectValidator pour l'usine à effet de levier qui inspecterait les paramètres, mais je voudrais tout aussi tôt que dans la méthode de création d'usine si le chèque aussi simple que vous décrivez. .