Est-ce une odeur de code si vous créez fréquemment un objet juste pour appeler une méthode dessus

J'ai hérité d'une base de code où il y a beaucoup de code qui ressemble à ceci:

SomeDataAdapter sda = new SomeDataAdapter();
sda.UpdateData(DataTable updateData);

Et puis sda n'est plus jamais utilisé.

Est-ce une odeur de code qui indique que ces méthodes devraient en fait être des méthodes de classe statiques?

Je considérerais cela comme une odeur d'architecture dans la mesure où UpdateData devrait probablement appartenir à une classe de «service».

Où les données sont une pomme. Où AppleAdapter est une classe de service / intelligence d'affaires. Où AppleService est une référence Singleton à un AppleAdapter qui existe en dehors de la méthode actuelle.

private static volatile AppleAdapter _appleService = null;
private static object _appleServiceLock = new object();
private AppleAdapter AppleService
{
    get
    {
        if (_appleService == null)
        {
            lock (_appleServiceLock)
            {
                if (_appleService == null)
                    _appleService = new AppleAdapter();
            }
        }
        return _appleService;
    }
}

public SomeAppleRelatedMethod(Apple apple)
{
    AppleService.UpdateData(apple);
}

Je ne pense pas que ce que vous faites soit nécessairement faux, mais si SomeDataAdapter représente effectivement une sorte de service commercial sans état, alors un singleton serait la meilleure pratique pour cela. J'espère que cela pourra aider! L'exemple fourni est un moyen sophistiqué de garantir qu'aucune contention de _appleService ne se trouve être à la fois nulle et accessible exactement en même temps par deux threads ou plus.

Vous savez quoi? Si SomeDataAdapter est un ADO IDbDataAdapter (ce qu'il est presque certainement), ignorez cette réponse entière!

: P

Je n'ai pas la permission d'ajouter un commentaire à la question d'origine, mais si vous pouviez spécifier où ce code existe.

Si ce code représente une implémentation personnalisée d'un IDbDataAdapter, et UpdateData crée un IDbConnection, IDbCommand, et le câblage tout en arrière-plan, alors je ne considérerais pas qu'une odeur de code parce que maintenant nous parlons de flux et autres les choses qui doivent être éliminées lorsque nous avons fini de les utiliser.

Je pense que ce problème va encore plus loin que cela. Même si vous le refactorisez en une méthode statique, vous obtenez du code où vous appelez une méthode statique unique partout. Ce qui, à mon avis, est une odeur de code en soi. Cela pourrait indiquer que vous manquez une abstraction importante. Peut-être que vous voulez créer un code qui fera un certain pré et post-traitement tout en vous permettant de changer ce qui se passe entre les deux. Ce pré et post-traitement contiendra les appels communs tandis que l'intervalle dépendra de la mise en œuvre concrète.

En quelque sorte. Cela signifie généralement que vous souhaitez transmettre une fonction et que la langue de votre choix ne vous le permettra pas. C'est un peu maladroit et inélégant, mais si vous êtes coincé dans un langage sans fonctions de première classe, vous ne pouvez pas faire grand-chose.

Si aucun de ces objets n'est transmis comme arguments à d'autres fonctions, vous pouvez les transformer en méthodes statiques et rien ne changera.

Si l'état de détention rend une classe donnée plus utilitaire, fonctionnelle… réutilisable, alors non. Pour une raison quelconque, le modèle de conception de commande vient à l'esprit; cette raison n'est certainement pas le désir de faire noyer Robert Harvey.

Définissez «fréquemment». Combien de fois instanciez-vous l'objet? Beaucoup - probablement pas?

Il y a probablement de plus gros problèmes à craindre dans votre système. Le fait de devenir statique communiquera plus clairement au programmeur que l'état interne de l'objet ne change pas - parfait.

Si l'état est gâché, et que vous devez commencer à rendre d'autres choses statiques pour rendre la première chose statique, vous devez alors demander quelles parties doivent être statiques et quelles parties ne le doivent pas.

Oui, c'est une odeur de code, juste une petite.

Faites-en une méthode statique et continuez. Il n'y a rien de mal avec les méthodes statiques. Une fois qu'un modèle d'utilisation émerge, vous pouvez vous soucier de l'abstraire.

L'odeur ici est que c'est du code procédural enveloppé (de façon minimale) dans des objets.

Il doit y avoir une raison pour laquelle vous souhaitez effectuer cette opération sur la table de données, mais plutôt que de modéliser cette opération avec d'autres opérations connexes qui partagent certaines sémantiques (c'est-à-dire qui ont une signification commune), l'auteur vient de créer une nouvelle procédure à l'intérieur d'une nouvelle classe et l'a appelé.

Dans un langage fonctionnel, c'est comme ça que vous feriez les choses;) mais dans le paradigme OO, vous voudriez modéliser une abstraction qui incluait cette opération. Ensuite, vous utiliseriez des techniques OO pour étoffer ce modèle et fournir un ensemble d'opérations connexes qui préservent une certaine sémantique.

Donc, l'odeur principale ici est que l'auteur utilise des classes, probablement parce que le compilateur l'exige, sans organiser les opérations dans un modèle conceptuel.

BTW attention à chaque fois que vous voyez le programme en cours de modélisation au lieu de l' espace de problème . C'est un signe que le design pourrait bénéficier de plus de réflexion. En d'autres termes, faites attention aux classes qui sont toutes "xAdaptor" et "xHandler" et "xUtility", et généralement liées à un modèle de domaine anémique . Cela signifie que quelqu'un regroupe simplement du code pour plus de commodité, au lieu de modéliser réellement les concepts qu'il souhaite implémenter.