Conseil de modèle de conception pour calculer des prix

Question

J'ai une meilleure question de modèle de conception/pratique. Je travaille sur un système de dispatching où j'ai besoin de calculer un prix.

Dans les paramètres du système, l'administrateur peut gérer 8 règles de débit différentes. Il y en a un pour le minimum, le parking, le péage, ... Chaque règle peut être activée et désactivée, et chaque règle a ses propres paramètres, par exemple la règle «parking» a les paramètres «prix», «TVA», «prix par heure ou prix fixe», .. Je pensais à utiliser un modèle de stratégie ou un modèle de pont, mais ni l'un ni l'autre ne conviennent bien.

Une autre solution serait un héritage simple sans utiliser d'interface.

J'ai modélisé quelque chose, mais je ne suis pas 100% satisfait du résultat:

https://www.dropbox.com/s/jllb8h0671ssq8u/RateRule-Pattern.png

Answer 1

me semble très raisonnable ... Quel que soit le modèle que vous l'appelez, je vois beaucoup de sens dans votre idée - collection de ParkingCalculator, TollCalculator etc, avec une interface commune. Cela facilite l'ajout de plusieurs types de paiements s'ils apparaissent en cours de route et vous permet de remplacer certaines pièces (par exemple, des règles de stationnement différentes). Si ce dernier se produit, alors il tombe en effet dans la définition classique de «stratégie».

Personnellement, je voudrais aussi cacher tout derrière une interface de niveau supérieur de « calculateTotal » - la mise en œuvre actuelle étant « itérer à travers une collection de calculatrices », mais le reste du système ne devrait pas l'esprit si ce changements (par exemple, si les règles deviennent si complexes qu'elles nécessitent un arbre, ou un appel REST à un service externe par le ministère des Transports).