Что представляет собой лучший дизайн для этого класса?

Question

считать, этот класс:

public class Logger 
{ 
    static TextWriter fs = null; 

    public Logger(string path) 
    { 
     fs = File.CreateText(path); 
    } 

    public static void Log(Exception ex) 
    { 
     ///do logging 
    } 

    public static void Log(string text) 
    { 
     ///do logging 
    } 
} 

, и я должен использовать это как:

Logger log = new Logger(path); 

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

Редактировать на основе ответа Marc «s:

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

Answer 1

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

Тогда вы можете либо сделать его static class, либо одноэлементным, если это необходимо для удовлетворения некоторого интерфейса.

Следующий: вы must добавьте синхронизацию здесь! Это не потокобезопасно. Если два потока попытаются войти в одно и то же время, я ожидаю, что это обрушится ужасно. Это не должно быть сложным; в самом простой:

private readonly object syncLock = new object(); 
public static void Log(string value) { 
    lock(syncLock) { 
     //... 
    } 
} 

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

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

Answer 2

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

В качестве альтернативы вам может потребоваться использовать log4net, который будет выполнять этот вид ведения журнала для вас.

Answer 3

Я думаю, что вы должны сделать статический класс целиком со статическим свойством, позволяющим вам установить путь к журналу.

public static class Logger 
{ 
    static TextWriter fs = null; 

    public static string FileName 
    { 
     set 
     { 
     fs = File.CreateText(value); 
     } 
    } 

    public static void Log(Exception ex) 
    { 
     if(fs == null) return; 
     ///do logging 
    } 

    public static void Log(string text) 
    { 
     if(fs == null) return; 
     ///do logging 
    } 
}