Должны ли частные вспомогательные методы быть статическими, если они могут быть статическими

Я предпочитаю, чтобы такие вспомогательные методы были private static; что даст понять читателю, что они не будут изменять состояние объекта. Моя IDE также будет отображать вызовы статических методов курсивом, поэтому я буду знать, что метод статический, не глядя на подпись.

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

Я бы сделал их статичными, так как обычно делаю это, если это вообще возможно. Но это только я.

РЕДАКТИРОВАТЬ: Этот ответ продолжает получать отрицательные голоса, возможно, из-за необоснованного утверждения о размере байт-кода. Так что я действительно проведу тест.

class TestBytecodeSize {
    private void doSomething(int arg) { }
    private static void doSomethingStatic(int arg) { }
    public static void main(String[] args) {
        // do it twice both ways
        doSomethingStatic(0);
        doSomethingStatic(0);
        TestBytecodeSize t = new TestBytecodeSize();
        t.doSomething(0);
        t.doSomething(0);
    }
}

Байт-код (извлекается с помощью javap -c -private TestBytecodeSize):

Compiled from "TestBytecodeSize.java"
class TestBytecodeSize extends java.lang.Object{
TestBytecodeSize();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   return

private void doSomething(int);
  Code:
   0:   return

private static void doSomethingStatic(int);
  Code:
   0:   return

public static void main(java.lang.String[]);
  Code:
   0:   iconst_0
   1:   invokestatic    #2; //Method doSomethingStatic:(I)V
   4:   iconst_0
   5:   invokestatic    #2; //Method doSomethingStatic:(I)V
   8:   new     #3; //class TestBytecodeSize
   11:  dup
   12:  invokespecial   #4; //Method "<init>":()V
   15:  astore_1
   16:  aload_1
   17:  iconst_0
   18:  invokespecial   #5; //Method doSomething:(I)V
   21:  aload_1
   22:  iconst_0
   23:  invokespecial   #5; //Method doSomething:(I)V
   26:  return

}

Для вызова статического метода требуются два байт-кода (byteops?): iconst_0 (для аргумента) и invokestatic.
Для вызова нестатического метода требуется три: aload_1 (для объекта TestBytecodeSize, я полагаю), iconst_0 (для аргумента) , и invokespecial. (Обратите внимание, что если бы это не были частные методы, это было бы invokevirtual вместо invokespecial; см. JLS §7.7 Вызов методов.)

Как я уже сказал, я не ожидаю большой разницы в производительности между этими двумя, кроме того факта, что invokestatic требуется на один байт-код меньше. invokestatic и invokespecial оба должны быть немного быстрее, чем invokevirtual, поскольку они оба используют статическое связывание вместо динамического, но я понятия не имею, быстрее ли один из них, чем другой. Я тоже не могу найти хороших ссылок. Ближайшее, что я могу найти, - это эта статья о JavaWorld 1997 года, который в основном повторяет то, что я только что сказал:

Самыми быстрыми инструкциями, скорее всего, будут invokespecial и invokestatic, потому что методы, вызываемые этими инструкциями, статически связаны. Когда JVM разрешает символическую ссылку для этих инструкций и заменяет ее прямой ссылкой, эта прямая ссылка, вероятно, будет включать указатель на фактические байт-коды.

Но с 1997 года многое изменилось.

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

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

Ответ ... это зависит от обстоятельств.

Если member - это переменная экземпляра, специфичная для объекта, с которым вы имеете дело, тогда зачем вообще передавать ее как параметр?

Например:

public class Example {
   private Something member;

   public double compute() {
       double total = 0;
       total += computeOne();
       total += computeMore();
       return total;         
   }

   private double computeOne() { /* Process member here */ }
   private double computeMore() { /* Process member here */ } 
}

Одна из причин, по которой вы можете захотеть объявить статические вспомогательные методы, заключается в том, что вам нужно вызвать их в конструкторе класса «перед» this или super. Например:

public class MyClass extends SomeOtherClass { 
    public MyClass(String arg) {
       super(recoverInt(arg));
    }

    private static int recoverInt(String arg) {
       return Integer.parseInt(arg.substring(arg.length() - 1));
    }
}

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

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

Для метода с разными привилегиями доступа, я думаю, есть два основных аргумента:

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

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

Правильный ответ:

любой метод, который не берет информацию из поля и не помещает информацию в поле, не обязательно должен быть методом экземпляра. Любой метод, который не использует и не изменяет какие-либо поля в своем классе или объекте, также может быть статическим методом.

или какая-либо конкретная причина не [объявлять их статическими]?

да.

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

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

Таким образом, вы создаете подкласс и возвращаете его в новых версиях, а поскольку методы были объявлены как методы экземпляра, вы просто позволяете полиморфизму выполнять свою работу.

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

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

См. Здесь видео по теме: Как создать хороший API и почему это важно

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

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

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

Это позволяет использовать его в других статических методах или при инициализации класса, то есть:

public class Example {
   //...

   //Only possible if computeOne is static
   public final static double COMPUTED_ONE = computeOne(new Something("1"));

   //...
}

Статический / нестатический вопрос сводится к тому, «действительно ли мне нужно использовать объект этого класса»?

Итак, вы передаете объект между разными методами? Содержит ли объект информацию, полезную вне контекста статических методов? Есть ли причина не определять методы обоими способами, если вы будете использовать их обоими способами?

Если вы находитесь в этой дилемме, мне кажется, что у вас есть все данные, необходимые для метода, плавающие в вашем коде за пределами объекта. Это то, что вы хотите? Было бы проще всегда собирать эти данные в объект каждый раз? У вас может быть двойственное отношение к единой модели. Если вы можете сделать все одним способом, выберите статический или нестатический и следуйте ему.

В подобных случаях я предпочитаю создавать статические методы computeOne и computeMore. Причина: инкапсуляция. Чем меньше кода имеет доступ к реализации вашего класса, тем лучше.

В приведенном вами примере вы заявляете, что computeOne и computeMore не должны иметь доступа к внутренним компонентам класса, так зачем давать возможность сопровождающим класса вмешиваться во внутренние компоненты.

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

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

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

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

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

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

Если говорить более конкретно о приведенном вами примере, кажется, что цель определения этих методов больше для ясности кода, когда вы его читаете, чем для функциональности (они определены как частные). В этом случае использование static действительно ничего не делает для вас, поскольку цель static - раскрыть функциональность класса.

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

Как говорили многие, сделайте это как static! Вот правило большого пальца, которому я следую: если вы думаете, что метод - это просто математическая функция, то есть он не имеет состояния, не включает никаких переменных экземпляра (=> нет переменных синего цвета [в затмении] в method), и результат метода будет одинаковым для n вызовов (конечно, с теми же параметрами), затем пометьте этот метод как STATIC.

И если вы думаете, что этот метод будет полезен для другого класса, переместите его в класс Util, в противном случае поместите метод как закрытый в том же классе. (минимизация доступности)

Вне темы: я бы сохранил вспомогательные методы в отдельном служебном / вспомогательном классе, содержащем только статические методы.

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

class Whatever {

    public static varType myVar = initializeClassVariable();

    private static varType initializeClassVariable() {

        //initialization code goes here
    }
}

Преимущество частных статических методов заключается в том, что их можно повторно использовать позже, если вам нужно повторно инициализировать переменную класса.

1. Без модификатора static вы не можете понять, что метод не имеет состояния, без дополнительного анализа, который можно легко выполнить, когда вы (пере) пишете метод.

2. Тогда модификатор static может дать вам идеи о рефакторинге, помимо прочего, что другие могут счесть бесполезным. Например. перемещение метода в какой-либо служебный класс или преобразование его в метод-член ..

Я бы объявил их статичными, чтобы пометить их как апатриды.

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