Je contribue cette réponse pour compléter Roger Alsing répondre à propos des invariants avec d'autres raisons.
L'information sémantique
Roger clairement expliqué que les organismes de propriété ne portent pas d'information sémantique. Autoriser un setter pour une propriété comme Post.PublishDate peut ajouter de la confusion car nous ne pouvons pas savoir avec certitude si le post a été publié ou seulement si la date de publication a été définie. Nous ne pouvons pas savoir avec certitude que c'est tout ce qui est nécessaire pour publier un article. L'objet "interface" ne montre pas clairement son "intention".Cependant, je crois que des propriétés telles que "Enabled" ont une sémantique suffisante pour "get" et "setting". C'est quelque chose qui devrait être efficace immédiatement et je ne vois pas le besoin de méthodes SetActive() ou Activate()/Deactivate() pour la seule raison de la sémantique manquante sur le setter de la propriété.
Invariants
Roger a également parlé de la possibilité de briser par setters invariants propriété. C'est tout à fait vrai, et il faut faire des propriétés qui fonctionnent en tandem pour fournir une "valeur invariante combinée" (comme les angles de triangle pour utiliser l'exemple de Roger) comme propriétés en lecture seule et créer une méthode pour les définir ensemble, qui peut valider toutes les combinaisons en une seule étape.
initialisation de la commande de propriété/Définition des dépendances
Ceci est similaire au problème car il provoque invariants des problèmes avec des propriétés qui doivent être validées/modifiées ensemble. Imaginez le code suivant:
public class Period
{
DateTime start;
public DateTime Start
{
get { return start; }
set
{
if (value > end && end != default(DateTime))
throw new Exception("Start can't be later than end!");
start = value;
}
}
DateTime end;
public DateTime End
{
get { return end; }
set
{
if (value < start && start != default(DateTime))
throw new Exception("End can't be earlier than start!");
end = value;
}
}
}
Ceci est un exemple naïf de validation "setter" qui provoque des dépendances d'ordre d'accès. Le code suivant illustre ce problème:
public void CanChangeStartAndEndInAnyOrder()
{
Period period = new Period(DateTime.Now, DateTime.Now);
period.Start = DateTime.Now.AddDays(1); //--> will throw exception here
period.End = DateTime.Now.AddDays(2);
// the following may throw an exception depending on the order the C# compiler
// assigns the properties.
period = new Period()
{
Start = DateTime.Now.AddDays(1),
End = DateTime.Now.AddDays(2),
};
// The order is not guaranteed by C#, so either way may throw an exception
period = new Period()
{
End = DateTime.Now.AddDays(2),
Start = DateTime.Now.AddDays(1),
};
}
Puisque nous ne pouvons pas changer la date de début après la date de fin sur un objet de période (à moins qu'il soit une période « vide », avec les deux dates fixées par défaut (DateTime) - oui, ce n'est pas un super design, mais vous comprenez ce que je veux dire ...) essayer de définir la date de début en premier fera une exception.
Cela devient plus sérieux lorsque nous utilisons des initialiseurs d'objets. Puisque C# ne garantit aucun ordre d'assignation, nous ne pouvons pas faire d'hypothèses sûres et le code peut ou non lancer une exception en fonction des choix du compilateur. MAL!
Ceci est finalement un problème avec la conception des classes. Comme la propriété ne peut pas "savoir" que vous mettez à jour les deux valeurs, elle ne peut "désactiver" la validation tant que les deux valeurs n'ont pas été modifiées. Vous devez soit rendre les deux propriétés en lecture seule et fournir une méthode pour définir les deux en même temps (perdre la fonctionnalité des initialiseurs d'objet) ou supprimer complètement le code de validation des propriétés (peut-être introduire une autre propriété en lecture seule comme IsValid ou valider si nécessaire).
ORM "hydratation" *
Hydratation, dans une vision simpliste, signifie obtenir les données persistantes en objets. Pour moi, c'est vraiment le plus gros problème avec l'ajout de la logique derrière les régleurs de propriétés. Beaucoup/la plupart ORM mappent la valeur persistante dans une propriété
Si vous avez une logique de validation ou une logique qui change l'état de l'objet (les autres membres) à l'intérieur des setters de la propriété, vous finirez par essayer de valider par rapport à un objet "incomplet" (un étant encore chargé). Ceci est très similaire au problème d'initialisation d'objet puisque vous ne pouvez pas contrôler l'ordre dans lequel les champs sont "hydratés". La plupart des ORM vous permettent de mapper la persistance à des champs privés au lieu de propriétés, ce qui permet d'hydrater les objets, mais si votre logique de validation se trouve principalement dans les propriétés, vous devrez peut-être la dupliquer ailleurs pour vérifier qu'une l'objet chargé est valide ou non.Étant donné que de nombreux outils ORM prennent en charge le chargement paresseux (aspect fondamental d'un ORM!) En utilisant des propriétés (ou méthodes) virtuelles, le mappage vers les champs rendra impossible le chargement par chargement accidentel d'objets dans des champs.
Conclusion
Ainsi, à la fin, afin d'éviter la duplication de code, permettent ORM d'effectuer le mieux qu'ils pouvaient, empêcher surprenantes exceptions en fonction de l'ordre des champs sont définis, il est sage de déplacer la logique loin des créateurs de propriété.
Je suis encore en train de déterminer où cette logique de 'validation' devrait être. Où validons-nous les aspects invariants d'un objet? Où mettons-nous des validations de plus haut niveau? Utilisons-nous des hooks sur les ORMs pour effectuer la validation (OnSave, OnDelete, ...)? Etc. Etc. Etc. Mais ce n'est pas la portée de cette réponse.
donc dans votre exemple devrions-nous utiliser une seule fonction comme 'period.setDateBoundries (startDate, endDate)' pour éviter les setters? une seule fonction qui détient une signification commerciale au lieu de setter factice? – Songo
@Songo c'est ce que je ferais. Mais alors on pourrait se plaindre d'avoir à passer les deux dates pour en changer une seule (imaginez si on voulait prolonger une période, on devrait passer les deux dates! ... mais alors, hé, pourquoi ne pas créer une méthode Extend? ?) Pensez comme ceci: chaque fois que vous finissez avec une propriété qui dépend d'un autre, alors peut-être c'est une bonne idée d'introduire des méthodes pour les changer ou des méthodes qui ajouteront plus de valeur sémantique (comme le Period.Extend ...)! – Loudenvier
Je ne fais que passer des tableaux. Ce n'est pas génial pour les indices IDE, mais cela me permet de transmettre des données dans n'importe quel ordre. Je peux également ajouter ou omettre des données en fonction de la circonstance (c'est-à-dire la période complète, ou une seule date). La validation est faite de toute façon, il ne semble donc pas beaucoup plus difficile de vérifier si un paramètre a été donné ou omis. – prograhammer