Хранение глобальных объектов в классе приложений против статического класса
Существуют ли какие-либо различия между этими двумя подходами с точки зрения жизненного цикла этих переменных?
Как я понимаю, в обоих случаях 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 ответа:
Я согласен на GhostCat и Chetan. Я тоже считаю, что использование статики необходимо избегать, чтобы избежать чрезмерного использования памяти.
Я бы предпочел сделать одноэлементный класс для каждого процесса, скажем, для обработки потока экранов в моем приложении или для написания вспомогательных методов для операций с базой данных или нескольких общих методов, используемых многими действиями / фрагментами в моем приложении.
Эта ссылка имеет хорошее обсуждение класса приложения против Синглтона.
Концептуально, статика является аномалией в хорошем дизайне ОО. Поэтому, когда вы спрашиваете о лучших практиках, начните с того, что придумайте проекты, которые Не используют статические в первую очередь.
И далее: ваши классы должны напоминатьполезную модель "вещи", которую вы собираетесь построить. Вы не ставите "вещи здесь или там"; вы ставите их ... где он принадлежит с концептуальной точки зрения.