Architecture: utilisation de différentes classes sur le développement/production

Question

Je suis intéressé par l'utilisation de 2 classes différentes dans 2 environnements différents. Les deux classes devraient partager la même structure (méthodes), mais celle utilisée en production serait "légère", avec moins de vérifications ou moins de funalités ou d'actions différentes.

Exemple: une classe de requête SQL qui ne vérifie pas le type/l'existence des champs. Autre exemple: une classe de gestion d'erreurs qui enregistre et n'affiche pas les messages.

Je suppose qu'un modèle de conception spécifique existe déjà, mais je ne sais pas vraiment dans lequel je devrais creuser.

Answer 1

Cela peut être juste moi ... mais c'est une très mauvaise idée.

Vous ne devriez pas avoir de code en cours d'exécution en direct que vous n'utilisez pas dans Développement/Test. Sinon, il n'y a aucun moyen de vérifier que le code fonctionne correctement (à part, bien sûr, en le poussant à la production et en croisant les doigts). Pour cette raison, je ne pense pas que vous allez trouver un bon exemple de ce que vous cherchez.

Mise à jour

Qu'est-ce que vous avez décrit est légèrement différente de celle que votre lit question initiale. Si c'est le cas, vous pouvez faire lire votre 'framework' pour un fichier de configuration qui spécifie les niveaux de validation et de journalisation. De cette façon, votre fichier de configuration peut différer d'un environnement à l'autre et continuer à utiliser la même base de code.

Answer 2

Ce n'est pas une bonne idée d'avoir un code différent dans vos différents environnements. Pour votre scénario, je pense que la meilleure option est d'externaliser comme aspects de la configuration les choses que vous voulez éviter dans un environnement particulier et lorsque l'application est déployée définir les journaux détaillés on/off, vérification des champs on/off,

Toutes les modifications apportées aux environnements doivent être effectuées de manière cohérente pour éviter les problèmes. Un système de contrôle de version et un processus cohérent de construction et de déploiement sont vos amis pour cela.

Answer 3

Convenu de la plupart des commentaires ci-dessus concernant la non-exécution de code différent dans les environnements de production et de développement. Cela dit, vous êtes probablement à la recherche d'un modèle Factory ou Factory Method.

Answer 4

Dans mon cas, j'ai une passerelle de paiement avec un bac à sable et un environnement en direct. ce que j'ai fait était d'utiliser un factory pattern + Interfaces (donc toutes les passerelles ont la même signature) + configuration (où le système sait quelle classe doit être instance)