Метод расширения для регистрации.Хорошая идея?

Question

Каковы, на ваш взгляд, плюсы / минусы следующего метода расширения?

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;
    }
}

Сценарий использования:

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

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

Answer 1

Ну, для начала они статичны, что усложнит тестирование и будет все теснее связывать.

Я тоже лично думаю что-то вроде

Logger.Write("Starting..");

более понятно, чем

"Starting...".AddToLog();

Answer 2

Это делает для интересного, рубинового, синтаксиса. Однако, как сказал Джон, то, что ты можешь, не означает, что ты должен.

Это могло бы сбить с толку большинство разработчиков C # и добавить ненужную путаницу.

Для конкретных целей ведения журналов есть гораздо лучшие способы получить то, что вы хотите. Мой самый первый вопрос: почему вы катите свое собственное решение для регистрации? Ведение журнала - очень хорошо решенная проблема, и вы не должны тратить циклы разработки на то, что, например, в log4net, прекрасно работает.

Answer 3

Для меня это не очень читабельно.

То, что вы можете, не значит, что вы должны :) 1003 *

Answer 4

Самая большая проблема в этом подходе состоит в том, что почти невозможно очень просто внедрить зависимости в статические методы / методы расширения. Это означает, что ваше решение для ведения журналов (предполагая, что оно станет более сложным, чем создание дампов в stdout / console / debug) должно быть запущено и сконфигурировано для проведения практически любого тестирования проекта. Когда-либо.

Answer 5

Для правильного ведения журнала вам нужно гораздо больше, чем просто строка. Дата, источник, категория и т. Д., Которые вы можете хранить в более структурированном виде.

В целом, создание метода расширения ведения журнала в String выглядит просто неправильно. Функциональные возможности метода расширения должны иметь достаточно тесную связь с типом, с которым он работает, в соответствии с принципом единой ответственности. В случае, как вы описали, это явно нарушается.

Answer 6

Обычно вместо Console.WriteLine у вас есть вызов к вашему действующему механизму регистрации

Ваш API журналирования (если вы его используете) может не только регистрировать строки, но и регистрировать любые объекты.
Например, в log4net вы можете вызвать метод .Error с параметром объекта. Затем механизм регистрации решает, какую информацию об объекте на самом деле зарегистрировать.

То, как вы это сделали, побеждает эту идею.

Answer 7

Я пойду с не очень хорошей идеей.Я не могу думать ни о какой причине, чтобы сделать это.Он загромождает пространство имен и не очень интуитивно понятен.(По крайней мере для меня)

РЕДАКТИРОВАТЬ

Теперь, когда я думаю об этом, я видел, как какой-то адвокат расширяет простые объекты, подобные этому, но регистратор не очень хороший случай, ИМХО.Если вы предоставляете функциональность .ToX (), например, конвертируете целое число в строку MPH или что-то в этом роде, метод расширения может быть полезен, но регистратор просто не подходит.