Функция?Учебный класс?

Question

Я пишу приложение (C #), и иногда мне нужно будет войти в журнал событий Windows.Поэтому первое, что приходит в голову, - это написать функцию в моем единственном и единственном классе и вызывать ее, когда мне это нужно.Примерно так:

private void Write_Event_Log(string log, string source, string message, EventLogEntryType type, int eventid)
    {
        if (!EventLog.SourceExists(source))
            EventLog.CreateEventSource(source, log);

        EventLog.WriteEntry(source, message, type, eventid);
    }

Мой коллега спросил: «Почему вы просто не создали новый класс для своего редактора журнала событий?»Итак, мой вопрос, с чего бы мне это?И как бы выглядел этот класс?И зачем мне это, когда моя функция работает хорошо?хорошо, это 3 вопроса, но вы понимаете:)

Answer 1

с чего бы я?

Инкапсулировать функциональность регистрации в свой собственный класс. Зачем? Принцип единой ответственности http://en.wikipedia.org/wiki/Single_responsibility_principle. Если вы смешаете это с вашим классом, вы возлагаете на этот класс ответственность как минимум за две (2) вещи: что бы он ни делал и ведение журнала.

А как бы выглядел этот класс?

public class LogWriter
{
    public static Log(string log, string source, string message, EventLogEntryType type, int eventid)
    {
        if (!EventLog.SourceExists(source))
            EventLog.CreateEventSource(source, log);

            EventLog.WriteEntry(source, message, type, eventid);
    }
}

А зачем мне это, когда моя функция работает хорошо?

Подумайте, когда вы больше не несете ответственности за код. Подумайте заранее, когда код будет расти. В конце концов, в дополнение к ведению журнала он может содержать множество других очень полезных функций. Следующий программист был бы намного счастливее, если бы не пришлось рефакторировать вашу работу, потому что был создан прецедент проектирования.

Answer 2

Я думаю, что у вас должен быть отдельный класс, потому что если вы собираетесь создавать больше классов no.of в своем приложении, вы можете использовать одинаковое ведение журнала для всех из них, см. Пример ниже открытый статический класс Logger { приватная статическая строка logFilePath = string.Empty;

    public static void Log(string logMessage, TextWriter w)
    {
        w.Write( logMessage);
        w.Flush();
    }


    public static void Log(string textLog)
    {
        string directoryString =
      filepath+           @"\Logging";
        Directory.CreateDirectory(directoryString);

        logFilePath = directoryString + "\\" +
          DateTime.Now.ToShortDateString().Replace("/", "") + ".txt";


        StreamWriter sw = null;
        if (!File.Exists(logFilePath))
        {
            try
            {
                sw = File.CreateText(logFilePath);
            }
            finally
            {
                if (sw != null) sw.Dispose();
            }
        }
        using (StreamWriter w = File.AppendText(logFilePath))
        {
            Log(textLog, w);
            w.Close();
        }
    }

Answer 3

По той же причине, по которой кто-то поместил SourceExists(Source) и CreateEventSource(source, log) в свой собственный класс, так что вы можете вызвать их, просто сославшись на сборку, для которой определен этот класс, и написав

 EventLog.SourceExists(source);

или

 EventLog.CreateEventSource(source, log);

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

Answer 4

Это очень общий вопрос о ОО-дизайне. Ваш коллега имеет в виду разделение обязанностей; он не думает, что идея автора журнала событий вписывается в абстракцию класса, в который вы его поместили, и заслуживает своего.

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

Написанная вами функция - это небольшая функция, которая не сохраняет состояние, поэтому другой класс на самом деле не нужен, если только он не предназначен для предотвращения проблем в будущем.

Answer 5

Если это небольшое приложение (которое должно быть с одним классом), то это, вероятно, не имеет значения.

Но при проектировании в более крупном приложении вы, вероятно, захотите рассмотреть возможность использования функции регистрации вкласс сам по себе, чтобы каждый класс был как можно более узко сфокусирован.

Answer 6

Я согласен, что вы не должны создавать новый класс для записи непосредственно в журнал событий, но по другой причине. Этот класс уже существует!

Рассмотрите возможность использования встроенных механизмов отладки / трассировки в System.Diagnostics:

Debug output

Trace output

Это стандартные классы, которые выгружают информацию в коллекцию TraceListener объектов, из которых уже существует много полезных типов:

DefaultTraceListener - вывод дампов в стандартную отладку, я думаю, через OutputDebugString().

EventLogTraceListener - Вывод дампов в журнал событий Windows.

Таким образом, ваш механизм вывода из программного вопроса превращается в вопрос о конфигурации. (Да, если вы работаете в прямом управляемом приложении, вы можете заполнить свою коллекцию TraceListener через свой app.config.) Это означает, что везде вы просто используете соответствующий вызов Trace.Write() или Debug.Write() (в зависимости от если вы хотите вывод в сборке релиза), и конфигурация определяет, куда направляется вывод.

Конечно, вы также можете заполнить свою коллекцию TraceListener программно, это весело и просто.

И таким образом, вам не нужно создавать собственную инфраструктуру для ведения лесозаготовок. Это все встроено! Используйте его на здоровье! : D

---

Если, с другой стороны, вы настаиваете на том, чтобы кататься самостоятельно (я думаю, что это плохая идея), ваш коллега прав. Это отдельная ответственность и принадлежит к отдельному классу. Я ожидал бы статических методов для вывода, потому что, вероятно, нет концептуальных экземпляров вашего журнала отладки. На самом деле, я ожидал бы, что интерфейс очень похож на System.Diagnostics.Debug, так что да, просто используйте его вместо этого.

---

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

Answer 7

Просто, что если вы захотите использовать этот метод везде во всех других частях вашей кодовой базы? Вы снова копируете - вставляете. Вместо этого есть помощник или класс Add in, где просто создайте экземпляр и продолжайте вызывать.

Плюс, если он находится в классе, вы можете иметь больше свойств и предоставить больше методов настройки, а также для регистрации данных.

Посмотрите, можете ли вы использовать встроенный журнал событий / трассировки.