Функциональность C # Utility Статический метод / Статический класс / Шаблон Singleton - PullRequest
3 голосов
/ 22 мая 2011

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

UtilityManager также содержит несколько других методов.

Мой вопрос:

1) Это правильный способ реализации функциональности?

2) делать ли UtilityManager также статическим классом / нет? Какая разница?

3) Написан ли приведенный ниже код (для функциональности TicketProvider) в одноэлементном шаблоне?(Учитывая, что большинство одноэлементных классов создают один и тот же класс UtilityManager.)

другая информация: класс, вызываемый в приложении Asp.Net

public  sealed class UtilityManager
{    
    public static readonly TicketProvider _ticket = new TicketProvider();

    public static int GetServiceTicketNumber()
    {       
        return _ticket.GetTicket();
    }
}

Ответы [ 2 ]

4 голосов
/ 22 мая 2011

1: звучит жизнеспособно; часто это субъективный вызов; например, если ваша утилита опирается на статические поля, это ограничивает вас одной установкой на домен приложения. Это может быть хорошо, но может быть ограничением, если вы позже перейдете на многопользовательский режим. Это также может быть сложнее проверить.

2: статический класс не может иметь экземпляры (или методы экземпляров); если все методы реализованы как статические, то, вероятно, это должен быть статический класс

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

Другим вариантом здесь может быть обычный экземпляр, но просто убедитесь, что весь ваш код взаимодействует с одним и тем же экземпляром - возможно, через IoC / DI (и, возможно, нет). Это даст вам аналогичное удобство, но больше гибкости для тестирования и мультитенантности

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

3 голосов
/ 22 мая 2011

Методы утилит лучше всего объявлять статическими, и многие инструменты проверки кода, такие как stylecop, на самом деле рекомендуют статические функции утилит, так что вы на правильном пути.Если вы хотите иметь одноэлементный экземпляр TicketProvider, вы можете использовать статический конструктор, чтобы убедиться, что поле инициализируется до того, как оно действительно будет доступно и инициализировано только один раз.Также вы можете сделать класс статическим, чтобы указать, что этот класс предназначен не для создания экземпляра, а только для служебного использования.Ниже моя рекомендация:

public static class UtilityManager
{  
    static UtilityManager()
    {
        Ticket = new TicketProvider();
    }

    public static TicketProvider Ticket { get; private set; }

    public static int GetServiceTicketNumber()
    {       
        return Ticket.GetTicket();
    }
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...