Попытка выяснить, дает ли этот код какую-либо выгоду, используя Singleton - PullRequest
3 голосов
/ 09 января 2012

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

Например:

public class FooFacade
{
    private static FooFacade m_facade = null;
    private static DataAccessManager m_dataAccessMgr = null;

    public StringBuilder Status {get; set; }

    private FooFacade()
    {
        this.Status = new StringBuilder();
    }

    public static FooFacade getInstance()
    {
        if (m_facade == null)
        {
            m_dataAccessMgr = DataAccessManager.getInstance();
            m_facade = new FooFacade();
        }

        return m_facade;
    }

    public void clearStatus()
    {
        this.Status.Remove(0, Status.Length);
    }

 public void Method1(string value1, int value2)
    {
     // DO SOMETHING
    }


 public List<string> Method2(string value1, int value2)
    {
     // DO SOMETHING ELSE
     // RETURN LIST
    }

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

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

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

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

Спасибо, Чад

ОБНОВЛЕНО БлагодаряВ комментариях ниже я знаю, что статус вызывает серьезную обеспокоенность, поскольку у него есть шанс стать огромным недостатком безопасности.Есть ли польза от использования этого кода в Singleton, когда речь идет об управлении памятью, скорости и т. Д.?Или было бы проще создавать экземпляр FooFacade каждый раз, когда мне это нужно.

Ответы [ 3 ]

6 голосов
/ 09 января 2012

Поскольку у вашего объекта есть внутреннее состояние (Status), вы напрашиваетесь на неприятности.В частности, если синглтон используется из нескольких потоков (например, в веб-приложении), код, вероятно, просто не будет работать.

Используйте синглтоны только в том случае, если у вас есть классы, у которых нет внутреннего состояния.

2 голосов
/ 10 января 2012

Есть ли польза от использования этого кода в Singleton, когда речь идет об управлении памятью, скорости и т. Д.? Или было бы проще создавать экземпляр FooFacade каждый раз, когда мне это нужно.

Все, что содержит экземпляр этого типа, является ссылкой на StringBuilder. Кроме того, при создании нового экземпляра не требуется выполнять тяжелую работу (если только DataAccessManager.getInstance() не делает неприятных вещей за кулисами). Так что нет, никакой ощутимой выгоды с точки зрения управления памятью, скорости и т. Д. Я бы просто создал новый экземпляр, когда он мне понадобится. (Или скорее: я бы попытался полностью избавиться от этого класса ...)

1 голос
/ 10 января 2012

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

...