Сайты Singleton и Static Utility

Какие факторы влияют на соответствующий шаблон проектирования?

Разъяснение:

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

Ответ 1

Я использую статические классы утилиты для общих функций, которые будут вызываться из разных контекстов. математические функции аналогичны функциям в java.util.Math. Это подходящий шаблон, предполагающий, что это "чистые" функции (т.е. Не манипулировать каким-либо состоянием или не обращаться к каким-либо данным, кроме параметров, которые они заданы).

Я очень редко использую одноточие и, в частности, стараюсь избегать глобальных синглетонов. Они страдают от всех обычных проблем, связанных с глобальными переменными. Они затрудняют тестирование, и, если ваш синглтон не является неизменным, они вводят проблемы глобального состояния. Основное место, которое я нашел полезным, - это хакеры производительности, которые зависят от идентификатора объекта - например:

  public static final END_OF_SEQUENCE_MARKER=new EndMarker();

Затем при прохождении последовательности вы можете просто проверить, есть ли (объект == END_OF_SEQUENCE_MARKER). Поскольку это статическая окончательная ссылка, JIT превратит это в чрезвычайно быстрый тест....

ИЗМЕНИТЬ

Только что увидев ваше разъяснение, некоторые быстрые дополнительные комментарии:

Статические классы factory обычно не имеют смысла. Вся цель класса factory заключается в том, что вы можете его создать (или подкласс!), Внести некоторые изменения в конфигурацию в объект factory, а затем использовать его для генерации экземпляров объектов в соответствии с необходимой вам конфигурацией. Если вы станете статичным, вы можете просто создать статический метод MyObject.create(..) вместо того, чтобы иметь весь статический класс MyObjectFactory....
Аналогичным образом, почему у вас отдельный отдельный менеджер-менеджер? Обычно лучшим классом для управления singleton является сам singleton-класс, так как вам обычно понадобится доступ к частному конструктору, если вы хотите гарантировать, что только один экземпляр будет когда-либо создан. Просто имея простой статический метод MySingleton.getInstance(), как правило, делает все, что вам нужно.

Ответ 2

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

Статическая утилита используется, когда у вас есть класс, который представляет собой просто служебные функции без состояния. Он не поддерживает состояние. Экземпляр объекта никогда не создается.

Ответ 3

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

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

Ответ 4

Я не уверен, что вопрос здесь.

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

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