Поэтому мой друг-кодер ненавидит использование static -кодирования. Тем не менее, моя Java-программа полна его для связи между классами, и у меня их много!
Стоит ли переписывать весь код для удаления статического метода?
Есть ли преимущество использования одного над другим?
1. Переменная экземпляра - одна для каждого объекта, каждый объект имеет свою собственную копию переменной экземпляра.
Например:
public class Test{
int x = 5;
}
Test t1 = new Test();
Test t2 = new Test();
Оба t1 и t2 будут иметь свою собственную копию x.
2. Статическая переменная - одна для каждого класса, каждый объект этого класса использует одну и ту же статическую переменную.
Например:
public class Test{
public static int x = 5;
}
Test t1 = new Test();
Test t2 = new Test();
Оба t1 и t2 будут иметь ровно один x, чтобы делиться между ними.
3. Статическая переменная инициализируется, когда JVM загружает класс.
4. A static method не может получить доступ к переменной Non-static.
5. Static methods вместе с Static variables может имитировать a Singleton Pattern, но это НЕ ПРАВИЛЬНЫЙ ПУТЬ, как в случае, когда есть много классов, то мы не можем быть уверены в порядке загрузки класса JVM, и это может создать проблему.
static предназначен для случаев, когда вы не хотите иметь копию для каждого экземпляра
instance переменные предназначены для случаев, когда требуется отдельная копия для каждого экземпляра объекта.
Исходя из бизнес-кейсов, использование которых может измениться.
Если у вас слишком много статических функций и переменных, это может привести к более функциональному подходу, а не к истинному OO. Также, если у вас есть общедоступная статическая переменная, то вы реплицируете глобальную переменную, которая не хороша. Следить за ними - это кошмар.
Как правило, мое правило заключается в использовании переменных экземпляра, если вы можете иметь и иметь только статические переменные и функции, если он действительно является общим для класса, а не для объекта
Это довольно хороший ответ на аналогичные вопросы Java: когда использовать статические методы
Вместо того, чтобы просто ссылаться на методы, рассмотрите возможность использования новой операции для создания нового объекта и доступа к этому методу с помощью нестационарного метода.
перед
public void myMethod(){
Time.setTime(Time.getTime() + 20);
System.out.println(Time.getTime());
}
после
public void myMethod(){
Time t = new Time();
t.setTime(t.getTime() + 20);
System.out.println(t.getTime());
}
Любое состояние, которое хранится в этих методах, теперь будет экземпляром времени, которое вы создали. Вы также можете использовать переменную t по другим методам, если вам нужно.
Сбор мусора - статические поля живут намного дольше, чем поля экземпляра. С логической точки зрения, статические поля ONLy предполагают, что они будут разделяться между каждым отдельным экземпляром - если это действительно ваш случай, то без проблем.
Вы говорите о статических методах или статических свойствах?
Что касается статических методов, существует только один способ их оскорбить, и именно тогда вы определяете методы, которые принимают экземпляр объекта как параметр. Вам никогда не нужно это делать, и, на мой взгляд, это плохое кодирование. Вот пример:
static int add(ThisClass a, ThisClass b) {
return a.value + b.value;
}
Если вы говорите о статических переменных в классе, вы в основном входите в тему "синглтонов", где предполагается, что это только один экземпляр определенного класса. Синглтоны подвергаются большому количеству злоупотреблений. Они используются многими библиотеками классов (думаю, JDNI и классы ведения журнала), но если приложение широко использует их, это может быть признаком плохо структурированной программы. Вероятно, это то, о чем говорит ваш друг.
Экземпляр и статическая переменная:
Ответ на ваш вопрос: я бы сказал, что для сохранения выделения памяти стоит использовать статическую переменную.
Распределение памяти:
Для статической переменной выделяется только одна ячейка памяти, не относящаяся к никому из созданного объекта, и для переменной экземпляра для каждого объекта выделено одно место памяти
Теперь рассмотрим этот пример, рассмотрим, что вы работаете над внутренним проектом компании, где вам нужно создать объект 1M для класса Employee, а некоторое свойство класса Employee - eid, ename, ecompany Теперь важно, чтобы все сотрудники работали в компании XYZ, поэтому значение свойства ecompany будет "XYZ" независимо от Employee.
Теперь вы знаете ситуацию, значение свойства ecompany будет XYZ для 1 миллиона объектов.
Теперь вы решите, что хотите объявить свойство ecomapny как статическое или экземпляр, рассматривая выделение памяти
если вы объявите его как статический, тогда минимальная память, выделенная для ecompany, будет равна 48 байтам, что в меньшей степени сравнится с памятью, необходимой для хранения 1 миллионной переменной экземпляра. 100000 * 48 байтов = 48 миллионов байт.
Когда вы используете статические объекты (кроме случая одиночного), вы фактически реализуете функциональное программирование в сочетании с глобальными переменными. Если вы делаете это много - вы должны пересмотреть свой дизайн или использовать Java (возможно, вы должны использовать функциональный язык программирования, такой как список, схема и т.д.).
Pro Static
Как только статический член вызывается изнутри или снаружи класса, вызывается статический конструктор класса. "Статический объект" будет проходить через весь сеанс, поэтому вы выиграете в производительности.
Con Static
Статические члены не могут иметь состояния, поэтому они не могут разговаривать с нестатическими членами класса.
Пример
Если мы рассмотрим класс BigInteger, этот класс выиграет, если некоторые части будут сделаны в статические члены.
Экземпляр класса представляет (как и ожидалось) большое целое число.
Однако основные методы add и multiply не являются статическими (они должны быть в лучшем мире), что плохо для производительности.
Следовательно, на практике не следует бояться смесей между статическими и нестационарными.
Мне не нравятся статические переменные или методы, потому что они не имеют реального наследования. Это затрудняет издевательство над тестированием. Использование экземпляров дает вам гибкость полного полиморфизма. С другой стороны, иногда необходимы статические переменные, например, с глобальным кешем. Статические методы могут быть полезными, если они предоставляют вспомогательные методы для классов/объектов/примитивов, к которым вы не можете получить доступ или расширить. Эти вспомогательные методы настолько просты, что им не требуется наследование. Например, java.util.Arrays класс или java.util.Collections.