Избежание «Доступа к статическому члену типа через производный тип» - PullRequest
2 голосов
/ 10 декабря 2010

Я считаю, что это чисто предупреждение Резарпера, но обоснование этого (объяснено здесь ) имеет смысл. Грег Бич говорит, что вы можете вызывать статический метод базового класса из класса-брата ... в своем примере он использует:

var request = (FtpWebRequest)HttpWebRequest.Create(...)

... что вводит в заблуждение.

Так есть ли дизайн, который позволил бы мне избежать этого предупреждения в следующих классах?

public abstract class BaseLog {

    //  I omitted several other properties for clarity
    protected static string category;
    protected static TraceEventType severity;

    static BaseLog() {
        category = "General";
        severity = TraceEventType.Information;
    }

    public static void Write(string message) {
        Write(message, category, severity);
    }

    //  Writes to a log file... it's the same code for 
    //  every derived class.  Only the category and severity will change
    protected static void Write(string message, string messageCategory, TraceEventType messageSeverity) {

        LogEntry logEntry = new LogEntry(message, messageCategory, messageSeverity);

        //  This is Microsoft's static class for logging... I'm wrapping it to 
        //  simplify how it's called, but the basic principle is the same:
        //  A static class to log messages
        Logger.Write(logEntry);

    }

}


public class ErrorLog : BaseLog {

    static ErrorLog() {
        category = "Errors";
        severity = TraceEventType.Error;
    }

    //  I can add more functionality to the derived classes, but
    //  the basic logging functionality in the base doesn't change
    public static void Write(Exception exc) {
        Write(exc.Message);
    }

}


//  Code that could call this...
catch (Exception exc) {
    //  This line gives me the warning
    ErrorLog.Write("You did something bad");
    ErrorLog.Write(exc);
}

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

Классы являются статическими, потому что я не хочу создавать новый объект ErrorLog каждый раз, когда я хочу что-то записать, и я не хочу, чтобы 50 из них перемещались в форме переменной уровня члена в каждый класс я пишу. Ведение журнала использует Microsoft Enterprise Library, если это имеет значение.

TIA!
Джеймс

1 Ответ

5 голосов
/ 10 декабря 2010

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

Мой совет: потерять статическое цепление - превратить классы-держатели функций в объекты.Это позволяет вам переопределять (и не путать других читателей) по мере необходимости - полиморфизм работает только с экземплярами.

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

e.g. ErrorLogProvider.Instance.Write(something)

PS: Халява - проще тестировать и эти объекты.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...