Чи повинні приватні помічникові методи статичні, якщо вони можуть бути статичними

Скажімо, у мене клас, призначений для екземпляра. У мене є кілька приватних «помічників» методів всередині класу, які не потребують доступу до когось із членів класу, і діють виключно на їх аргументах, повертаючи результат.

public class Example {
   private Something member;

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

   private double computeOne(Something arg) { ... }
   private double computeMore(Something arg) {... } 
} 

Чи є якась конкретна причина вказувати computeOneі computeMoreяк статичні методи - чи якась конкретна причина цього не робити?

Безумовно, найпростіше залишити їх нестатичними, хоча вони, безумовно, можуть стати статичними, не викликаючи жодних проблем.

Я вважаю за краще такі допоміжні методи private static; що дасть зрозуміти читачеві, що вони не будуть змінювати стан об’єкта. Мій IDE також показуватиме дзвінки до статичних методів курсивом, тому я буду знати, що метод є статичним, не шукаючи підпису.

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

Я зробив би їх статичними, оскільки, як правило, роблю це, якщо це можливо. Але це тільки я.

EDIT: Ця відповідь не змінюється, можливо, через необґрунтоване твердження про розмір байтового коду. Тож я фактично проведу тест.

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

}

Викликання статичного методу займає два байт-коди (проміжки часу): iconst_0(для аргументу) та invokestatic.
Викликання нестатичного методу займає три: aload_1(для TestBytecodeSizeоб'єкта, я думаю), iconst_0(для аргументу) та invokespecial. (Зауважте, що якби це не були приватні методи, це було б invokevirtualзамість них invokespecial; див. JLS §7.7 Методи виклику .)

Тепер, як я вже сказав, я не сподіваюся, що між цими двома різними показниками ефективності між цими двома, окрім того, що invokestaticпотрібно один менший байт-код , я не очікую . invokestaticі invokespecialобидва повинні бути трохи швидшими invokevirtual, оскільки вони обидва використовують статичну прив'язку замість динамічної, але я не маю уявлення, чи то інший швидший за інший. Я не можу знайти жодних хороших посилань. Найближче, що я можу знайти, - це стаття JavaWorld 1997 року , яка в основному повторює те, що я щойно сказав:

Швидкіші інструкції, швидше за все, будуть invokespecialі invokestaticтому, що методи, на які посилаються ці інструкції, статично пов'язані. Коли JVM вирішить символічне посилання на ці вказівки і замінить його прямим посиланням, це пряме посилання, ймовірно, буде включати вказівник на фактичні байт-коди.

Але багато речей змінилося з 1997 року.

Отже, на закінчення ... Я думаю, я все ще дотримуюся того, що я говорив раніше. Швидкість не повинна бути причиною вибору одного за іншим, оскільки це була б оптимізація в кращому випадку.

Моє особисте перевагу було б оголосити їх статичними, оскільки це чіткий прапор, що вони без громадянства.

Відповідь ... це залежить.

Якщо член є змінною екземпляра, характерною для об'єкта, з яким ви маєте справу, то навіщо взагалі передавати його як параметр?

Наприклад:

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не може бути методом екземпляра в цьому випадку.

Я не можу реально думати про явні переваги для приватного статичного методу. Незважаючи на те, конкретних переваг для того, щоб зробити їх нестатичними, немає. Це головним чином питання презентації: ви можете зробити їх статичними, щоб чітко підкреслити той факт, що вони не змінюють об'єкт.

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

• статичні методи можна викликати без створення екземпляра об'єкта, який може бути корисним
• статичні методи не можуть бути успадковані, що може бути проблемою, якщо вам потрібен поліморфізм (але це не має значення для приватних методів).

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

Правильна відповідь:

будь-який метод, який не бере жодної інформації з поля і не вводить будь-яку інформацію в поле, не повинен бути методом екземпляра. Будь-який метод, який не використовує та не змінює поля у своєму класі чи об'єкті, також може стати статичним методом.

чи якась конкретна причина не [оголосити їх статичними]?

Так.

Зберігаючи їх як методи екземплярів, ви дозволяєте надавати іншу реалізацію пізніше.

Це може здатися нерозумним (і насправді це було б, якби ці методи використовуються тільки ви в програмі на 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не потрібно мати доступ до внутрішніх даних класу, тому навіщо давати можливість керівникам класу втручатися у внутрішні.

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

По-перше, оскільки методи приватні, навіть якщо ви оголосите їх статичними, ви не зможете отримати доступ до них поза цим класом. По-друге, вони є приватними, тому ви навіть не можете переосмислити підклас, тому статичне чи нестатичне значення не має ніякого значення. По-третє, нестатичний приватний метод також може бути викликаний від конструктора класу, він не повинен бути статичним.

Тепер перейдемо до вашого питання, чи слід визначити метод приватного помічника як статичний чи нестатичний. Я піду з відповіддю Стіва, оскільки маркування приватного методу статичним показує, що цей метод без громадянства, оскільки я також дотримуюся цього правила, коли кодую.

З досвіду я зазначу, що такі приватні методи, як правило, є досить універсальними та багаторазовими.

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

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

Більш конкретно на прикладі ви дали, здається , що мета визначення цих методів більше для коду ясності , коли ви читаєте це , ніж для функціональності (вони будуть визначені як приватні). У такому випадку перехід із статикою насправді нічого не робить для вас, оскільки мета статики - розкрити функціональність класу.

Однією з причин є те, що при рівності інших статичні виклики методу повинні бути швидшими. Статичні методи не можуть бути віртуальними, і це посилання не береться неявно.

Як багато хто казав, зробіть це як статичне ! Ось головне правило, яке я слідую: Якщо ви вважаєте, що метод є лише математичною функцією тобто він без стану, не залучає змінних екземплярів (=> у методі немає синього кольору, змінюється), а результат метод буде однаковим для 'n' кількості викликів (з тими ж параметрами, звичайно), потім позначте цей метод як STATIC.

І якщо ви думаєте, що цей метод буде корисним для іншого класу, тоді перенесіть його до класу Util інакше, поставте метод як приватний у той самий клас. (мінімізація доступності)

Off-Topic: Я б утримував допоміжні методи в окремому утиліті / класі помічника, лише в ньому є статичні методи.

Проблема з тим, що в точці використання помічницьких методів (читайте "той самий клас") полягає в тому, що хтось із лінії може просто вибрати розміщення власних непов'язаних допоміжних методів у тому самому місці

class Whatever {

    public static varType myVar = initializeClassVariable();

    private static varType initializeClassVariable() {

        //initialization code goes here
    }
}

Перевага приватних статичних методів полягає в тому, що вони можуть бути використані пізніше, якщо вам потрібно повторно ініціалізувати змінну класу.

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

2. Тоді "статичний" модифікатор може дати вам ідеї щодо рефакторингу, окрім інших речей, які інші можуть вважати непотрібними. Наприклад, переміщення методу до якогось класу Utility або перетворення його в метод-член.

Я б оголосив їх статичними, щоб позначити їх як без громадянства.

У Java немає кращого механізму для незначних операцій, які не експортуються, тому я вважаю, що приватна статика є прийнятною.