Classe d'assistance (ES) vs héritage fonctionnel. Meilleur entrainement

S'il y a une chance que la logique en double puissance soit nécessaire par d'autres classes en dehors de la hiérarchie, je l'aurais placé dans des classes d'assistance statique. Sinon dans la classe de base avec héritage protégé.

À mon avis, je mettrais le code en double dans la classe de base s'il ne concerne que cette hiérarchie de classe et ne sera pas utilisé en dehors de celui-ci. En cas de possibilité que le code soit utilisé à travers différentes classes, déplacez-la à une classe d'assistance dans un projet commun.

profiter!

au lieu de classes statiques Une autre option consiste à placer le code commun dans une nouvelle classe et à utiliser une injection de dépendance pour injecter la classe d'assistance dans les commandes. Cela va également avec la composition sur la notion d'héritage également.

Il n'y a probablement pas une bonne / mauvaise réponse ici, bien que je suppose que vous pouviez certainement le mettre en œuvre mal. Cela dépend probablement de vos besoins réels et de la manière dont vos commandes sont liées les unes des autres. Généralement, j'irais probablement avec une implémentation de classe de base et une hiérarchie d'héritage, en supposant que les commandes sont liées et que le code concerne directement les commandes elles-mêmes, non à une entité externe qui devrait être une classe à part entière. Certes, ils sont liés par le fait qu'ils sont des commandements et que la classe de base pourrait refléter cela.

Si vous avez du code qui est commun aux sous-ensembles de commandes non liées, cependant, et la création d'une hiérarchie d'héritage forcerait une relation qui n'existe pas, l'ajout dans une classe "sans aide" (non statique, si possible , pour améliorer la qualification) serait un moyen parfaitement naturel de résoudre le problème. Vous constaterez peut-être que vous pouvez regrouper les méthodes «d'assistance» naturellement dans des classes de leur propre. Par exemple, si plusieurs méthodes doivent interagir avec votre sous-système d'authentification, vous pourriez avoir un authentificationMediateur pour ces méthodes. Je ne vois pas non plus de conflits avec certains des deux.

Si la logique fonctionne sur interface em>, par opposition à Membres em>, puis écrivez une méthode d'assistance [ou une méthode d'extension] est conseillée.

public class SomeCommand : ICommand
{
    // an implementation-specific member, NOT a member
    // of ICommand
    public int SomeControlCount { get; set; }
}

// a method that references implementation-speciic
// details. where should this go?
public void DoSomething ()
{
    SomeCommand command;
    int count = command.SomeControlCount;
}

Cela dépend complètement de la nature de votre code dupliqué.

Quelles sont les entrées / sorties de vos fonctions d'assistance? Est-ce qu'ils fonctionnent sur un ensemble de variables logiquement associé? Ensuite, vous feriez mieux de créer une classe de base avec ces variables en tant que membres et ensemble de fonctions d'assistance connexes.

Sinon, si les paramètres de vos fonctions d'assistance ne sont pas cohérents, vous mettriez en œuvre ces fonctions comme des fonctions statiques, non? Je ne vois pas de raisons de compliquer les choses avec héritage dans ce cas et je le ferais simplement avec des fonctions d'assistance (ou si votre langue ne traite pas les fonctions de citoyens de première classe, utilisez une classe d'assistance statique).

Aides d'utilisation du code apatride.

Code dépendant de l'état avec plusieurs méthodes utilise l'héritage. Par exemple, lorsque plusieurs méthodes utilisent une variable d'élément partagé et maintiennent ainsi un état partagé.

L'objectif est de réduire la quantité de code dupliqué et dépend du type de code. Cependant, je déteste vraiment quand les gens enrognez-le et apportent des classes super abstraites ou des fonctions d'assistance qui font 7 sautes à un autre code abstrait étrange, qui sont nommés quelque chose comme "Executor" "Invoke" "DataConVoyer" "DataManager" "SharedCode". Et que d'une manière ou d'une autre, à la fin de tous ces sauts réellement réussis à faire le travail, il était supposé, mais est tellement interconnecté avec l'autre que vous n'êtes pas sûr d'où effectuer les nouvelles modifications apportées à cette nouvelle fonctionnalité. Devrais-je le faire DataConVoyer ou dois-je le faire dans DataManager?

L'objectif doré devrait donc être, le garder simple.

L'utilisation d'assistants dans votre propre code est une mauvaise pratique qui venait de la paresse.

La seule situation possible que vous avez vraiment besoin d'aide, c'est d'étendre le comportement des classes scellées des bibliothèques tierces telles que le sélénium, etc.

Qu'est-ce que l'aide? C'est une méthode statique qui est située quelque part de la classe elle-même.

quels problèmes nous obtenons?

1. Méthode statique. A des problèmes avec des tests d'unités. Par exemple, nos développeurs ont ajouté la mise en cache des aides. En conséquence, il n'était pas possible de simplement se moquer de ces méthodes, tandis que je devais ajouter à de nombreuses logiques, juste pour une moqueuse simple. Oui, il y a une possibilité de mauvaise utilisation de la méthode statique ... mais au début, personne ne s'attendait à ajouter de l'État à l'aide.
2. emplacement. La méthode est située dans une autre classe, loin de la logique de base. C'est une fausse conception de la conception de code.

   Quand utiliser Helper? Lorsque vous devez étendre la bibliothèque 3ème partie sans possibilité de le hériter. Sinon hériter de lib.

   Quand n'utilisez pas d'aide? Réduire le code dupliqué. Vous devez déplacer ce code vers un autre service. Lisez à propos de DDD pour améliorer les compétences de refactorisation et savoir comment orgraniser le service le meilleur moyen