Хранение глобальных объектов в классе приложений против статического класса


Существуют ли какие-либо различия между этими двумя подходами с точки зрения жизненного цикла этих переменных?

Как я понимаю, в обоих случаях foo получает мусор, собранный, когда приложение get очищается от памяти в самом

Конец. (правильно? или я что-то упустил?)

Вариант 1: хранение статической переменной в классе Приложения:

public class App extends android.app.Application {
    private static SomeClass foo;

    public static init setSomeObject(SomeClass someValue){
       foo = someValue;
    }


    public static SomeClass getSomeObject(){
       return foo;
    }
}

Вариант 2: строка статической переменной в любом статическом классе?

public class JustSomeClass {
    private static SomeClass foo;

        public static init setSomeObject(SomeClass someValue){
           foo = someValue;
        }

        public static SomeClass getSomeObject(){
           return foo;
        }
}

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

2 2

2 ответа:

Я согласен на GhostCat и Chetan. Я тоже считаю, что использование статики необходимо избегать, чтобы избежать чрезмерного использования памяти.

Я бы предпочел сделать одноэлементный класс для каждого процесса, скажем, для обработки потока экранов в моем приложении или для написания вспомогательных методов для операций с базой данных или нескольких общих методов, используемых многими действиями / фрагментами в моем приложении.

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

Концептуально, статика является аномалией в хорошем дизайне ОО. Поэтому, когда вы спрашиваете о лучших практиках, начните с того, что придумайте проекты, которые Не используют статические в первую очередь.

И далее: ваши классы должны напоминатьполезную модель "вещи", которую вы собираетесь построить. Вы не ставите "вещи здесь или там"; вы ставите их ... где он принадлежит с концептуальной точки зрения.