web-dev-qa-db-fra.com

Comment nettoyer une classe de logique commerciale qui fait trop de choses sans injecter une tonne de cours de classe?

Disons que nous avons une logique commerciale à effectuer dans un cadre MVC après que l'utilisateur soumet un formulaire:

class BusinessLogic:
    def sendDataTo3rdPartyApi(self):
        # do stuff
    def validateResponse(self):
        # do stuff 
    def persistData(self):
        # do stuff 
    def calculateFees(self):
        # do stuff 
    def sendDataToAnotherApi(self):
        # do stuff

Les données post-formulaire sont reçues par le contrôleur et transmettent ces données à la couche logique d'entreprise pour le traitement. Toutes ces fonctions sont nécessaires pour traiter les données. Nous reconnaissons que cette classe BusinessLogic fait probablement de nombreuses choses, donc nous résumons les différentes méthodes dans leurs propres cours et les injectez via DI:

class BusinessLogic:
    def __init__(self, dataSender, validator, dataPersister, feeCalculator, anotherDataSender):
        # assign objects to private properties within class
    def doLogic(self):
        # utilize the injected classes to perform necessary business logic

Le problème que je vois avec cette approche est que cela supprime les fonctions dans des classes qui effectuent une chose nous laisse toujours avec une classe qui fait trop de choses - c'est juste sous la forme de classes au lieu de fonctions. Nous pouvons essayer de déplacer ces cours de cette classe, mais nous allons simplement envoyer les dépendances dans le contrôleur. Comme notre logique commerciale devient plus complexe, plus nous allons devoir injecter puisque nous créons une classe pour chaque exigence d'entreprise.

Je me sens comme peu importe ce que vous faites, vous aurez toujours besoin d'une classe de Dieu d'une sorte pour organiser les différentes parties ensemble pour l'exécution. Maintenant, je ne suis pas sûr si cela est nécessairement une mauvaise chose, mais je me demande s'il ya une meilleure approche pour refactore une classe de logique d'entreprise comme celle-ci.

refactoringdependency-injectionsolidbusiness-logic
5
Robert Calove

Vraisemblablement pas tout ce qui s'appuie sur la logique commerciale, doit avoir ou même besoin d'accéder à toutes les fonctions de cette classe.

Pourquoi ne pas rechercher un point de clivage naturel? Un bon clien serait celui qui réduit la quantité d'utilisateurs nécessitant des moitiés, ou lorsque la mise en œuvre n'a pas besoin de l'autre moitié de la classe pour atteindre son objectif.

Une autre astuce serait de pousser certains de ces détails de mise en œuvre dans des classes logiques spécialisées, puis relier leurs instances via une classe de parapluie.

0
Kain0_0