Действительно ли моносостояние является хорошим кузеном злой Singleton?

как насчет того, чтобы не использовать шаблоны просто, потому что?

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

Гм, моносостояние является Singleton..., таким образом, это имеет те же самые проблемы.

• тестирование
• сокрытие зависимостей
• негибкий
• потокобезопасность
• глобальное состояние мешает гарантировать правильность

Согласно этому определению Моносостояний, это примечание:

"Моносостояния являются злыми таким же образом тот SingletonsAreEvil".

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

Проблема с этой цепью рассуждений состоит в том, что она не принимает во внимание, ПОЧЕМУ globals являются злыми. Globals являются злыми, прежде всего, потому что они - переменные, к которым можно получить доступ вне локального объема случайно, так же к тому, как нетипизированные языки часто позволяют переменным быть созданными просто путем ссылки на них.

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

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

Теперь, одиночные элементы и моносостояния могут вызвать другие виды проблем?Конечно. По-видимому, люди TDD ненавидят их, потому что их трудно протестировать правильно с автоматизированным тестированием. Хорошо, прекрасный, но для тех людей, которые не используют TDD, те проблемы не существуют.

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

Многие люди предлагают шаблоны "фабрика" вместо одиночных элементов, но я чувствую, что Фабрики являются просто необычными одноэлементными генераторами. Нет, нет никакого статического метода "экземпляра", но это в основном делает то же самое (когда фабрика создает единственный объект экземпляра, который является). Фабрика. Создайте не отличается от Singleton. Экземпляр.

Править:

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

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

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

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

Соглашение с Моносостоянием состоит в том, что необходимо знать меньше о реализации объекта для использования его. Другими словами, Вы сохраняете несколько нажатий клавиш, потому что Вы не должны называть объекты getInstance методом (Singleton s = Singleton:: getInstance; s. Метод ();) для получения ссылки на объект Вы просто используете нормальные конструкции языка (мс Моносостояния; мс. Метод ();). Тонкая грань действительно.

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

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

Вот выборка от страницы 127 Шаблонов разработки: Элементы Допускающего повторное использование Объектно-ориентированного программного обеспечения Гаммой, Рулем, Johnson и Vlissides.

Используйте Шаблон "одиночка" когда

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

Это действительно делает одноэлементное зло просто, потому что они неправильно используются и неправильно понимаются?

Как насчет класса с единственным экземпляром, но без глобального доступа:

public class SingleInstance
{
    private static boolean exhausted = false;

    public SingleInstance()
    {
        if (exhausted)
        {
            throw new IllegalStateException("only one instance allowed");
        }
        exhausted = true;

        [...]
    }

    [...]
}

Это избегает проблем Singleton и MonoState, в то время как это осуществляет и ясно передает это существует только один экземпляр.