ci-dessous est une méthode:
private RiskFactor calculateMotoristRiskFactor()
{
if (motorist.PointsOnLicense > 3
|| motorist.Age < 25)
return RiskFactor.HighRisk;
if (motorist.PointsOnLicense > 0)
return RiskFactor.ModerateRisk;
return RiskFactor.LowRisk;
}
5 Réponses :
Eh bien, vous pouvez avoir une liste var risk = filters.Where(filter => filter.Item1(motorist))
.Select(filter => filter.Item2)
.DefaultIfEmpty(RiskFactor.LOW_RISK)
.First();
OK, et le type de filtre personnalisé doit être hérité de tuple?
Downvoter: soin d'expliquer? Je pense que c'est une solution fine, notamment en remplaçant les tuples avec un type personnalisé comme suggère Jon.
@Vicky no, le type serait sa propre classe contenant un Func Riskfactor . Il pourrait ensuite être injecté avec la mise en œuvre du prédicat (tel que m => m.pointsonlicense> 3 ) et lequel risque pour revenir lorsque le prédicat est évalué à vrai.
Vous pouvez ajouter l'entrée par défaut à la liste dans la dernière position avec m => true , puis votre extraction serait simplement var risque = filtres.first (x => x.item1 (automobiliste )). Item2
@Brian: True ... Bien que je ne suis pas sûr que ce soit aussi clair que de rendre cela évident que c'est la valeur par défaut. Certainement une option à considérer cependant.
Je ne pense pas que le modèle de stratégie devrait être la réponse ici - vous utiliseriez généralement une stratégie si le type le type de l'automobiliste que vous traitez affecte le comportement.
Dans votre cas, vous avez simplement une logique de domaine standard basée sur les propriétés d'un automobiliste. Je pense que la manipulation conditionnelle est très appropriée.
Effectuez l'élimination du Par exemple, vous pouvez définir une stratégie Fonctionfactor entièrement. Au lieu du code consommateur de cette fonction, encapsulez la logique qui nécessite sa valeur de retour dans des classes séparées qui effectuent la tâche différemment.
de classe abstraite héritée par lowrisppolicy , moderateriskpolicy et highriskpolicy . Celles-ci ont simplement des valeurs de retour calculées en fonction de la politique appropriée et du code consommateur ne se connaissent pas et ne se soucient pas du type de politique qu'ils sont. Toute la logique spécifique à la politique est enveloppée dans la police.
Non ceci est une valeur enum basée sur laquelle la prime est calculée
Je peux voir ça. Je vous interroge sur la question de savoir pourquoi vous avez besoin de l'énum et vous suggérez que vous remplacez le code qui l'utilise avec le polymorphisme.
Je ne pense pas que vous devez être plus orienté objet juste pour être plus orienté objet. Si ce n'est que la place du code où vous calculez des risques et que je suppose qu'il existe un nombre d'autres données calculées sur la base de l'âge et des points de licence que je laisserais votre code tel qu'il est.
Sauf que vous passez probablement un mot automobiliste comme paramètre sur la méthode de la classe RISCCalculator.
Juste dans le cas d'un exemple d'exemple ici, ici Remplacer le conditionnel avec le polymorphisme
Vous allez avoir beaucoup plus de code, mais cela vous permettra de le prendre en compte. Vous pouvez créer une classe de stratégies pour chaque type de facteur de risque et les collecter ensemble. Quelque chose comme ceci:
Les noms d'Enum doivent être
CAMELCASED . N'utilisez jamais All_Caps dans .NET, sauf pour les jetons de préprocesseur.Faites-vous cela parce qu'un modèle de stratégie est en réalité meilleur, ou simplement parce que vous voulez être plus "orienté objet?"
Je veux être plus orienté objet
Regarde assez pour moi. Je pense que le modèle de stratégie ne compliquerait que la conception ici.
@alexantd Ne pensez-vous pas que la responsabilité unique est violée ici?
@Vicky: Pas vraiment; Si vous êtes en désaccord, jetez un coup d'œil à la réponse de Tom W., mais cela sent comme le motif-itis pour moi.