Méthode d'extension pour la journalisation. Une bonne idée?

Question

Quels sont, selon vous, les avantages/inconvénients de la méthode d'extension suivante?

static class Log 
{ 
    public static string AddToLog(this string input) 
    { 
     Console.WriteLine(input); 
     return input; 
    } 

    public static string AddToLog(this string input, string format) 
    { 
     Console.WriteLine(format, input); 
     return input; 
    } 
} 

scénario d'utilisation:

class Program 
{ 
    static void Main(string[] args) 
    { 
     string tableName = "Bills".AddToLog("Default table name is {0}"); 

     "Starting...".AddToLog(); 
     "Creating table".AddToLog(); 
    } 
} 

Answer 1

Eh bien ils sont statiques pour un début, ce qui va rendre les tests plus difficiles et tout deux plus étroitement.

Je pense personnellement aussi quelque chose comme

Logger.Write("Starting.."); 

est plus compréhensible que

"Starting...".AddToLog(); 

Answer 2

Pour moi, ce n'est pas très lisible.

Juste parce que vous pouvez ne signifie pas que vous devez :)

Answer 3

Je vais aller avec pas une bonne idée. Je ne peux pas penser à aucune raison de le faire. Cela encombre l'espace de noms, et ce n'est pas très intuitif. (Au moins pour moi)

EDIT

Maintenant que je pense, je l'ai vu quelques-uns des objets simples défenseur extension comme celui-ci, mais un enregistreur n'est pas un bon exemple à mon humble avis. Si vous fournissez une fonctionnalité .ToX(), comme la conversion d'un entier en une chaîne MPH ou quelque chose comme ça, une méthode d'extension peut être utile, mais un enregistreur n'est pas un bon ajustement.

Answer 4

Normalement, au lieu de Console.WriteLine vous avez un appel à votre mécanisme de journalisation réelle

Votre API de journalisation (si vous utilisez un) pourrait non seulement être en mesure de se connecter chaînes, mais également enregistrer tout type d'objets.
Par exemple, dans log4net, vous pouvez appeler la méthode .Error avec un paramètre d'objet. Ensuite, le mécanisme de journalisation décide des informations sur l'objet à journaliser.

La façon dont vous l'avez fait va à l'encontre de cette idée.

Answer 5

Cela donne une syntaxe intéressante, semblable à du rubis. Cependant, comme l'a dit John, ce n'est pas parce que vous le pouvez que vous devez le faire.

Ceci pourrait perturber la plupart des développeurs C# et ajouter une confusion inutile. Pour les besoins spécifiques de la journalisation, il existe de bien meilleurs moyens d'obtenir ce que vous voulez. Ma toute première question serait, pourquoi lancez-vous votre propre solution de journalisation? La journalisation est un problème très bien résolu et vous ne devriez pas gaspiller des cycles de développement sur quelque chose qui, log4net par exemple, ne pose pas de problème.

Answer 6

Pour une journalisation correcte, vous voudriez bien plus qu'une simple chaîne. Date, source, catégorie, etc., que vous pouvez stocker de manière plus structurée. Dans l'ensemble, la création d'une méthode d'extension de journalisation sur String semble tout simplement fausse. La fonctionnalité de la méthode d'extension devrait avoir une association assez forte avec le type sur lequel elle opère, conformément au principe de la responsabilité unique. Dans le cas que vous avez décrit, c'est manifestement violé.

Answer 7

Le plus gros problème de cette approche est qu'il est presque impossible d'injecter des dépendances dans des méthodes statiques/d'extension très proprement. Ce qui signifie que votre solution de journalisation (supposant qu'il devient plus complexe que de déverser des objets dans stdout/console/debug) doit être lancée et configurée pour effectuer à peu près n'importe quel type de test sur le projet. Déjà.