Моностат против Синглтона

Каковы сценарии, когда вы используете шаблон Monostate вместо singleton inorder для поддержки глобального объекта?

Изменить: Я знаю, каковы модели Singleton и Monostate. Также реализовали Singleton в довольно многих сценариях. Просто хочу знать сценарии (примеры примеров), где должен быть реализован шаблон MonoState.

Например, Мне нужно вести список столбцов на экран в приложении Windows Forms. В этом случае я мог бы использовать словарь Синглтона. Тем не менее, я храню список в статическом глобальном var, и я хотел бы предоставить индексаторы (так как мне нужно динамически добавлять новую запись в список, если нет ключа), где я мог бы указать ScreenDetails.ScreenName в качестве ключа и получить ScreenDetails.ColumnsTable. Поскольку индексы не могут работать в статическом классе, я изменил шаблон на Monostate.

Итак, я хотел бы знать, какие другие сценарии могут заставить пользователя использовать Monostate вместо Singletons.

Ответ 1

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

Простой - если несколько надуманный и не очень эффективный:) - пример:

public class GlobalTable implements Iterable<Key> {

  /** Shared state -- private */    
  private static final Map<Key, Value> MAP = new LinkedHashMap<Key, Value>();

  /** Public final accessor */    
  public final Value get(Key key) {
    return MAP.get(key);
  }

  /** Public final accessor */    
  public final boolean put(Key key, Value value) {
    return MAP.put(key);
  }

  /** Protected final accessor -- subclasses can use this to access
      the internal shared state */    
  protected final Set<Key> keySet() {
    return MAP.keySet();
  }

  /** Virtual -- subclasses can override for different behavior */    
  public Iterator<Key> iterator() {
    return Collections.unmodifiableSet(MAP.keySet()).iterator();
  }
}

Теперь, если мы хотим индексированный доступ?

public class IndexedGlobalTable extends GlobalTable {

  public List<Key> getKeysAsList() {
    return Collections.unmodifiableList(new ArrayList<Key>(keySet()));
  }

  public Key getKeyAt(int index) {
    return getKeysAsList().get(index);
  }

  public Value getValueAt(int index) {
    return get(getKeyAt(index));
  }
}

Как насчет отсортированных ключей?

public class SortedGlobalTable extends GlobalTable {

  @Override
  public Iterator <Key> iterator() {
    return Collections
      .unmodifiableSortedSet(new TreeSet<Key>(keySet())).iterator();
  }

}

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

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

Ответ 2

monostate и singleton - две грани одной и той же медали (глобальное состояние):

monostate заставляет поведение (только одно значение по всем экземплярам класса)
singleton заставляет структурное ограничение (только один экземпляр)

Использование Singleton не прозрачно

то есть:.

Singleton singleton = Singleton.getInstance();

Использование моностата прозрачно

то есть:.

MonoState m1 = new MonoState();
MonoState m2 = new MonoState(); // same state of m1

Ответ 3

Здесь, что Роберт К. Мартин скажет об этом: Singleton vs. Monostate (pdf)

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

Ответ 4

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

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

Об этом написано много: