Składowe statyczne w Javie: pola i metody static

Należy do klasy, a nie do obiektu

Większość pól i metod napisanych do tej pory należy do obiektów: przy każdym new każda instancja dostaje własną kopię pól, a metody działają na stanie tego konkretnego obiektu. Słowo kluczowe static to odwraca. Składowa static należy do samej klasy: jest jedna kopia, współdzielona przez wszystkie instancje, i istnieje niezależnie od tego, czy kiedykolwiek utworzysz obiekt.

To jedno rozróżnienie wyjaśnia pola statyczne, metody statyczne, stałe, a nawet to, dlaczego main zawsze jest static.

Współdzielone pole static

Pole niestatyczne daje każdemu obiektowi własne miejsce. Pole static daje klasie jedno miejsce, które wszyscy współdzielą. Klasyczny przykład to licznik, który śledzi, ile obiektów utworzono:

class User {
    static int count = 0;     // jedno współdzielone miejsce dla całej klasy
    String name;              // jedno na obiekt

    User(String name) {
        this.name = name;
        count++;              // zwiększ współdzielony licznik przy każdym tworzeniu obiektu
    }
}

public class Main {
    public static void main(String[] args) {
        new User("Ada");
        new User("Linus");
        new User("Grace");

        System.out.println("users created: " + User.count);
    }
}

Zwróć uwagę, że licznik odczytujesz jako User.count, czyli przez nazwę klasy, bo wartość nie należy do żadnego pojedynczego User. Każde name natomiast mieszka we własnym obiekcie. Zmień count przez dowolną instancję, a każda instancja zobaczy nową wartość, bo istnieje tylko jedna.

Metody static

Metoda static też należy do klasy, więc wywołujesz ją na klasie, bez obiektu:

class MathUtils {
    static int square(int x) {
        return x * x;
    }

    static int max(int a, int b) {
        return a > b ? a : b;
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(MathUtils.square(7));
        System.out.println(MathUtils.max(3, 9));
    }
}

Dokładnie według tego wzorca działa biblioteka standardowa: Math.max, Integer.parseInt, Arrays.sort i List.of są static, bo to zachowania narzędziowe, które nie potrzebują obiektu. Sięgaj po metodę static, gdy praca zależy tylko od argumentów, a nie od stanu konkretnego obiektu.

Wielka pułapka: static nie widzi instancji

Metoda static działa bez żadnego obiektu, więc nie ma this. Oznacza to, że nie może bezpośrednio używać pól instancji ani wywoływać metod instancji, bo nie ma konkretnego obiektu, z którego mogłaby je odczytać. To najczęstszy błąd początkujących związany ze static:

class Account {
    int balance = 100;          // pole instancji

    static int show() {
        return balance;         // BŁĄD KOMPILACJI: do niestatycznego pola 'balance'
    }                           // nie można się odwołać z kontekstu statycznego
}

Rozwiązaniem jest zamiana metody na metodę instancji (usuń static, żeby miała this) albo jawne przekazanie obiektu:

class Account {
    int balance = 100;

    static int show(Account a) {     // przyjmij obiekt jako parametr
        return a.balance;
    }
}

public class Main {
    public static void main(String[] args) {
        Account a = new Account();
        System.out.println(Account.show(a));
    }
}

W drugą stronę wszystko działa: metoda instancji może swobodnie czytać pola static i wywoływać metody static, bo współdzielone dane na poziomie klasy zawsze istnieją.

Stałe przez static final

Połącz static z final, a dostaniesz stałą: jedną współdzieloną wartość, której nie da się zmienić. Zgodnie z konwencją nazywa się je w stylu UPPER_SNAKE_CASE:

class Circle {
    static final double PI = 3.14159265;

    double radius;

    Circle(double radius) { this.radius = radius; }

    double area() {
        return PI * radius * radius;   // metoda instancji używająca stałej static
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.printf("%.2f%n", new Circle(2).area());
    }
}

static final to idiomatyczny sposób na wyrażenie "stałej wartości należącej do typu", jak Integer.MAX_VALUE czy Math.PI w bibliotece standardowej. static sprawia, że nie marnujesz kopii na każdy obiekt; final sprawia, że nikt nie może jej przypisać na nowo.

Statyczne bloki inicjalizacyjne

Proste pole static można zainicjalizować w miejscu deklaracji. Gdy przygotowanie wymaga prawdziwej logiki, np. budowy tabeli wyszukiwania przez HashMap albo odczytu konfiguracji, użyj bloku static. Wykonuje się raz, przy pierwszym załadowaniu klasy, zanim powstanie jakikolwiek obiekt:

import java.util.HashMap;
import java.util.Map;

class Roman {
    static final Map<Character, Integer> VALUES = new HashMap<>();

    static {                       // wykonuje się raz, przy ładowaniu klasy
        VALUES.put('I', 1);
        VALUES.put('V', 5);
        VALUES.put('X', 10);
        VALUES.put('L', 50);
    }

    static int valueOf(char c) {
        return VALUES.get(c);
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(Roman.valueOf('X') + Roman.valueOf('I'));
    }
}

Blok uruchamia się jeden raz, niezależnie od tego, ile razy używasz klasy, więc to właściwe miejsce na jednorazową konfigurację dla całej klasy.

Kiedy używać static

Prosta zasada:

• Używaj pola static tylko dla danych naprawdę współdzielonych przez wszystkie instancje: licznika, cache'u, stałej. Jeśli dwa obiekty mogłyby rozsądnie mieć różne wartości, powinno to być pole instancji.
• Używaj metody static, gdy wynik zależy tylko od argumentów, a nie od stanu obiektu (czyste funkcje narzędziowe).
• Domyślnie wybieraj składowe instancji. Nadużywanie static po cichu zamienia program w stertę stanu globalnego, który trudno testować i analizować. static to wyjątek, a nie punkt wyjścia.

Dalej: enumy

Stała static final wystarcza dla jednej ustalonej wartości, ale gdy masz mały, stały zestaw powiązanych wartości, np. kierunki, dni tygodnia czy statusy zamówień, Java ma specjalny typ, który jest bezpieczniejszy i bardziej wyrazisty niż rozrzucone stałe. To enum i o nim jest następna strona.