Existe-t-il un modèle de conception qui s'appliquerait aux modèles à escompte?

Existe-t-il des modèles de conception connus pour la mise en œuvre de modèles à escompte?

Par modèles à prix réduits, j'entends ce qui suit:

1. Si un client achète le produit X, le produit Y et le produit Z, il bénéficie d'une réduction de 10% ou de 100 $.

2. Si un client achète 100 unités du produit X, il obtient un rabais de 15% ou 500 $

3. Si un client a rapporté l'année dernière plus de 100 000 dollars, il bénéficie d'une réduction forfaitaire de 20%.

4. Si un client a acheté 2 unités du produit X, il obtient gratuitement 1 unité du produit X (ou du produit Y).

5. ...

Existe-t-il un modèle générique pouvant être appliqué pour gérer tous les scénarios ci-dessus? Je pense à quelques modèles, mais je suis incapable de trouver un modèle générique.

Si le problème est que vous devez appliquer plusieurs remises, dans certaines circonstances, vous pouvez envisager le modèle de chaîne de responsabilité .

En un mot, vous transmettez les informations que vous souhaitez traiter au premier processeur, qui décide ensuite s'il convient de les transmettre à d'autres processeurs avant de renvoyer le résultat.

De cette façon, vous pouvez changer la structure et la séquence des processeurs sans jamais changer le code d'appel.

Les modèles de stratégie, de décorateur et d'état me paraissent constituer des points de départ potentiels. State peut être particulièrement utile pour 2 ou 3, car 2 dépend de l'état de la commande et 3 dépend de l'état du client au cours d'une période donnée. Stratégie et Décorateur se distinguent des autres, car vous pouvez utiliser stratégie pour implémenter plusieurs algorithmes de calcul du prix de la commande et décorateur pour ajouter de nouvelles remises à la commande.

Cependant, rappelez-vous que les modèles de conception ne sont que des modèles. Il se peut qu’il n’y ait pas un seul modèle qui s’applique, mais plutôt un système de modèles. Pensez également à apporter des modifications aux modèles décrits pour les adapter davantage à votre solution. Il est préférable d’avoir un bon design que de forcer un motif qui n’aide pas forcément pour pouvoir dire que vous avez un motif.

Eh bien, je concevrais un modèle d’escompte comme une paire "Précondition" et "Escompte", où "Précondition" est une classe avec méthodes.

  bool IsFulfilled(Customer c);

ou et

  bool IsFulfilled(Customer c, Order o);

et Discount a une méthode void ApplyTo(Customer c). Cela vous donne la possibilité de combiner n'importe quel type de condition préalable avec n'importe quel type de réduction (je pense qu'il s'agit d'une forme de "modèle de pont").

Si vous avez un nombre fixe de conditions préalables, vous pouvez résoudre le problème en créant des sous-types spécifiques (modèle de stratégie). Toutefois, lorsque vos conditions préalables sont considérées comme très complexes, avec des instructions logiques telles que AND, OR et NOT, vous pouvez mieux implémenter un interpréteur de règles pour les conditions. Les règles peuvent être une chaîne de texte en clair écrite dans un "langage spécifique à un domaine".

Il en va de même pour la classe "Remise", vous pouvez avoir soit des sous-types pour différents types de remises, soit une approche générale dans laquelle les règles de remise sont données sous forme de texte, évaluée par un interprète.

• Il faut probablement une interface IDiscount, car toutes les remises sont identiques, et nous voudrons les traiter de manière conceptuelle en tant que remises génériques.

• La classe "commande de ce client" nécessite probablement une collection de remises. Liste? Hacher? Liste liée? Ne t'en fous pas encore. Des rabais s'appliquent à l'achat, pas au client!

• Conservez le bâtiment de l'instance Discount à l'écart du client, du panier d'achat, de l'historique, etc. Cela changera beaucoup - comme l'a souligné @jfrankcarr.

• Probablement une classe différente pour chaque remise car l'algorithme et les paramètres de chaque remise varient énormément et de façon imprévisible.

• Je considère que la gestion des événements est très fréquente, car le calcul des remises répond aux modifications du panier, et inversement.

Application de modèle de conception

• Je vois un strategy pattern. IDiscount est l'interface permettant d'implémenter différents algorithmes de réduction.

• Je vois un factory. Certainement pas une abstract factory patternclasse à part entière , mais une seule classe à ce stade de l'analyse. Raisonnablement, il doit exister un seul endroit où le contexte est suffisant pour décider des remises applicables et les créer ensuite. Une classe. Si les règles relatives à l'application de remises explosent par la suite en raison d'une fête organisée par le département du marketing, toute logique supplémentaire de construction de remises doit quand même fusionner dans cette classe d'usine de base, à mon avis.

• Je peux voir Chain of Responsibility. Ce n'est pas mutuellement exclusif à l' factoryidée. Au lieu d'itérer une collection de remises, chaque remise appelle le type suivant. La classe "commande du client" ne contient pas une collection de remises dans ce cas.

• Le facteur "hmmmm ...." dans la chaîne de responsabilité, je pense, est que chaque remise a une référence à la suivante. L'implication est que l'ordre est important. Ce qui n'est pas le cas. En outre, le concept incarné par le CdR est qu'un objet ne peut pas gérer la demande , elle est donc transmise "à l'autorité suivante." Notre modèle est différent. La seule demande est de calculer. Chaque réduction fait ceci. La sortie ou l'effet peuvent être nuls, mais chaque remise est calculée. Je me penche instinctivement vers une plus grande fidélité dans le monde réel.

Hypothèses

• Les remises sont basées sur le panier d'achat actuel et / ou l'historique des achats
• Zéro ou plusieurs rabais peuvent s'appliquer. Il n'y a pas de rabais mutuellement exclusif
• Un calcul correct ne dépend pas de l'ordre dans lequel les remises sont appliquées.

Qu'est-ce qui change, qu'est-ce qui reste pareil?

• Les remises sont très différentes. Nombre et type de paramètres différents pour chaque règle.

• Les arguments en faveur des remises admissibles changent en fonction des modifications du panier.

• Le nombre de remises disponibles change

• Les remises accordées par ce client aux modifications apportées en fonction de l'évolution de son panier.

• L'historique des achats ne change pas dans le contexte de cet achat

• Le coût total change de manière dynamique en fonction des lignes d'achat et des remises appliquées.

• Après l'application initiale, le résultat de la remise peut changer, par exemple lorsque la quantité achetée change.

Logiquement, un modèle de réduction peut être n'importe quoi , vous ne pouvez donc pas supposer que vous pouvez programmer tous les cas à l'avance. Quiconque répond à votre question ne peut pas non plus être complètement sûr de ce dont vous avez réellement besoin. Cependant, en supposant que vous obteniez les types de rabais habituels trouvés dans le monde réel ...

Une grande question est de savoir si les réductions seront programmées ou si vous voulez que les utilisateurs les saisissent. Comme mentionné ci-dessus, vous ne pouvez jamais les programmer, mais l'objectif consiste généralement à essayer de créer davantage de données, comme dans les cas courants, plutôt que de les programmer toutes. Ceci s’applique dans une certaine mesure même si les programmeurs sont utilisés pour créer toutes les remises.

Martin Fowler mentionne "Méthode d'instance individuelle" dans "Modèles d'analyse: modèles d'objet réutilisables" dans le cadre de la mise en œuvre de "Règles de comptabilisation" pour les systèmes de comptabilité, mais les règles semblent assez similaires aux vôtres. Je donnerais plus de détails, mais c'est une œuvre protégée par le droit d'auteur et

Pour une interface utilisateur, vous devez soit proposer des cas d’utilisation assez simples, soit créer un interpréteur et un générateur de requêtes. Peut-être les deux, un pour les cas simples et un plus avancé. Si vous écrivez un interprète, c'est probablement un assez bon cas pour utiliser le motif Interpreter, puisqu'il est relativement simple à coder par rapport à un générateur d'analyseur, et que le temps d'analyse plus lent n'aura probablement pas d'importance. (Si vous aimez utiliser des générateurs d'analyseur, ne me laissez pas vous arrêter).

Cependant, n'essayez pas de tout faire avec un interprète - à un moment donné, vous programmez simplement dans votre propre langage minable, vous pouvez donc aussi bien utiliser un vrai langage. Si votre langage interprété prend en charge des fonctions (il devrait probablement prendre en charge leur appel - leur définition est douteuse), celles-ci peuvent être codées dans un langage réel. N'allez pas plus loin dans cette voie que nécessaire.

Peu importe ce que vous faites, quelqu'un voudra éventuellement que le rabais soit calculé en fonction de son achat dans les 30 jours ouvrables suivant une promotion - les jours ouvrables étant pris en compte uniquement s'il n'y a pas eu de jour férié dans la région définie par le code postal du magasin ou par le client. code postal. N'essayez donc pas de concevoir le système parfait à l'avance. Supposons que vous deviez parfois écrire du code pour de nouveaux types de remises et concevoir en conséquence.

Est-il utile de demander s'il existe un modèle utile pour cela? Quel type de modèle est requis - structurel ou comportemental?

Idéalement, si je devais écrire un logiciel pour cela, tout ce qu'il faudra, c'est un algorithme . Une fonction simple qui calcule la remise totale comme suit:

cart.calculateDiscount(productVector);

Vous n'avez pas besoin de plus que ça!

Pour clarifier: je comprends qu’il y aura de nombreuses règles - la représentation la plus élémentaire devrait être sous la forme d’une base de règles (ensemble d’attributs de données et de la réduction résultante contre celle-ci) et la fonction telle que celle décrite ci-dessus l’itérerait pour la calculer. Si des règles sont ajoutées ou supprimées, vous ne devriez pas changer le code; changez simplement la base de règles.

Un modèle n'est requis que si nous avons besoin de différents objets pour pouvoir accéder aux API les uns des autres ou communiquer pour mettre une tâche en place.

PS: Pensez-y: lorsque le pare-feu traite les paquets et les transmet ou les rejette (ou le modifie), quel modèle de conception utilise-t-il? La réponse est AUCUNE de celles décrites ci-dessus!