Синглтон и статические занятия

Question

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

Так что для себя я определил два разных случая - я использую одиночные тона в основном для классов POJO (в java), если должен быть только один экземпляр этого класса (что очень редко) и статические классы для всех службзанятия (которые происходят очень часто).

Например, в моем приложении мне нужно хранить сообщения (у меня есть сериализуемый класс Message), записывать их в файл, читать из файла и получать доступ во время выполнения.Я не вижу смысла использовать синглтон здесь, статический класс просто в порядке.Единственный статический класс - это MessageStorage, который имеет 3 функции - read, write и getMessages, а также один статический частный массив сообщений.

Является ли такой подход разумным, а если нет, то в чем его проблема?

Answer 1

Здесь нужно понимать, что существуют разные группы памяти для c # / java.

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

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

Фактическая точка решения между опцией singleton и статическим классом:

1) Хотите ли вы наследование или интерфейс для вашего класса (если вам нужен Singleton)
2) Имеет ли смысл принудительно заставлять ваш класс иметь жизненный цикл, который совпадает с вашими приложениями (т. Е. Вам придется вручную очищать класс или писать для этого метод, который неоправданно увеличивает код, а следовательно, снижает удобство сопровождения). (если этого не произойдет, то вам нужен синглтон)
3) Требует ли ваше приложение масштабируемости и возможности для изменений. В настоящее время синглтон часто считается анти-паттерном, если он реализован через статическое свойство. Причина этого заключается в том, что вы инвестируете в инфраструктуру, например, выставляете статическое свойство экземпляра для вашего класса, что может быть совсем не тем, что вы хотите в будущем, потому что ваше приложение с одним окном может внезапно стать многооконным, и вам нужно переписать код. (переписывание кода указывает на плохой дизайн, особенно если его основная инфраструктура).

Как правило, я бы рекомендовал следующее:

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

Answer 2

Двумя основными причинами использования «синглтона» в Java являются:

1) Таким образом, некоторое хранилище может быть связано с иным «статическим» классом.

2) Где вы можетеиметь несколько «синглетонов» для разных подклассов (или реализаций интерфейса) данного сервиса, и синглтон передается как способ определения того, какой конкретный сервис использовать.

Конечно, вместо # 1 вы можете использоватьстатические поля «статического» класса для хранения данных, но зачастую более удобно (и во многих случаях более эффективно) иметь один экземпляр класса-субъекта для хранения данных по сравнению с несколькими статическими членами, которые являются экземплярамидругие классы.

И, в # 2, в JDK есть ряд случаев, когда один класс реализует несколько «одиночек» под видом определения «констант».(Например, java.awt.font.TextAttribute.)

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

Answer 3

Идеальный дизайн: -)

• MessageStore должен быть интерфейсом
• MessageStoreFactory должен быть синглтоном с методом getMessageStore () (если getMessageStore () каждый раз возвращает одно и то же хранилище сообщений, это не проблема, и у вас есть синглтон).
• тогда вы можете иметь несколько реализаций MessageStore, таких как FileMessageStore, JDBCMessageStore, SubversionMessageStore и т. Д. *
• Самое главное, вы можете иметь MockMessageStore, чтобы макетировать хранилища сообщений и иметь возможность тестировать компоненты, которые зависят от хранилища сообщений, независимо от хранилища сообщений (и изолировать любой сбой). Например, если вы тестируете MessageView и получаете сообщение об ошибке, вы можете быть уверены, что ошибка находится в MessageView, а не в вашем статическом хранилище MessageStore, учитывая, что MockMessageStore является правильным.

Это то, что крутые дети делают сейчас дни, во всяком случае ... и инъекция зависимости, а не фабрика, но один шаг за раз ...