Блог

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

 public class Example extends Service
{
    private static Example mInstance = null;


     public void onStart( Intent aIntent, int aStartId )
    {

        mInstance = this;
        .
        .
        .
   }
}
 

Какова цель этого?

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

Смотрите здесь .

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

http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html

Класс Android Service (sub) не может быть одноэлементным, поскольку для фреймворка требуется доступ к конструктору по умолчанию для класса. Единственная причина, которую я могу придумать для сохранения статической ссылки на (последний) экземпляр, для которого onStart был вызван, — это упростить некоторый внутренний код, который может находиться в статических методах.

Учитывая, что onStart это устарело давным-давно (начиная с уровня API 5), это, скорее всего, пример плохого стиля кодирования с первых дней Android.

Чтобы другие классы могли получать экземпляр и вызывать методы экземпляра для объекта. Он часто используется с одноэлементным шаблоном. А для сервисов и действий в Android это очень плохая идея — он сохраняет ссылку на Activity / Service после его завершения, что приведет к утечке памяти.

В небезопасной для потоков реализации одноэлементного шаблона у вас будет частный конструктор и public static getInstance метод, при необходимости инициализирующий этот экземпляр и возвращающий его.

Вот пример. Обратите внимание, что рекомендуется использовать товар одноэлементного перечисления вместо приведенного ниже кода, чтобы получить «истинный» синглтон.

 public class MyThreadUnsafeSingleton {
    private static MyThreadUnsafeSingleton instance;
    private MyThreadUnsafeSingleton() {
        //TODO some ctor logic
    }
    public static MyThreadUnsafeSingleton getInstance() {
        if (instance == null) {
            instance = new MyThreadUnsafeSingleton();
        }
        return instance;
    }
}
 

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

Если у него есть частный конструктор по умолчанию, это, вероятно, одноэлементный.

Если это не так, это что-то странное.

Такой макет заставляет все экземпляры объектов этого класса обмениваться данными, независимо от того, когда они создаются. Экземпляр объекта, для которого вызывается OnStart, станет базовым источником данных для любых ссылок на этот класс, независимо от того, когда они были объявлены или созданы (до или после OnStart), и независимо от того, в каком потоке они были созданы.

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

Трудно представить конкретное применение для этого, но я предполагаю, что класс представляет собой абстракцию некоторого ресурса с отслеживанием состояния, который является глобальным по отношению к процессу, например, форма / окно или клиент веб-службы, который кэширует свои учетные данные. Хотя может быть что угодно.

Если этот код был написан примерно в 2003-2005 годах (ранние дни c #) Я бы предположил, что это неаккуратная реализация синглтона — тогда это было в моде, поскольку шаблоны проектирования становились привычными, а Синглтон был примером во всех учебниках. Оказывается, это ужасный шаблон для внедрения зависимостей и насмешек, поэтому в наши дни этот шаблон используется не так часто.

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

 public class Server {
    private static Server server = null;

    // Stop them making their own.
    private Server () {
        // Heavyweight stuff.
    }

    public static Server getServer () {
        if ( server == null ) {
            // Heavy constructor.
            server = new Server();
        }
        return server;
    }
}
 

В многопоточной среде это обычно сочетается с одноэлементным шаблоном проектирования.