Java: Kopiowanie obiektów - uniknij pułapek!

Kopiowanie obiektów w Javie decyduje o tym, czy po zmianie jednej instancji druga zachowa własny stan, czy zacznie zachowywać się jak jej cień. Temat kopiowania obiektów w Javie, często opisywany skrótowo jako java copy object, sprowadza się do wyboru między prostym skopiowaniem referencji, płytką kopią i rzeczywistą, głęboką kopią danych. W tym tekście pokazuję, kiedy wystarczy konstruktor kopiujący, kiedy sens ma `clone()`, jak traktować tablice i kolekcje oraz jakie błędy najczęściej psują efekt.

Jak rozumieć kopiowanie obiektu w Javie

Największe nieporozumienie zaczyna się wtedy, gdy ktoś myli kopiowanie obiektu z kopiowaniem zmiennej. W Javie zmienna przechowuje najczęściej referencję, czyli adres do obiektu, a nie sam obiekt. Dlatego zapis `User b = a;` nie tworzy nowej instancji, tylko dwa odwołania do tego samego miejsca w pamięci.

User a = new User("Anna");
User b = a;

b.setName("Ola");

System.out.println(a.getName()); // Ola
System.out.println(b.getName()); // Ola

To właśnie dlatego kopiowanie bywa krytyczne w modelach danych, formularzach, edytorach i wszędzie tam, gdzie chcesz bezpiecznie zmienić stan bez naruszania oryginału. Jeśli obiekt ma zostać zachowany „na później”, a potem porównany, przekształcony albo odrzucony, potrzebujesz czegoś więcej niż zwykłego przypisania. Od tego momentu kluczowe staje się pytanie, czy wystarczy kopia powierzchowna, czy trzeba skopiować także cały zagnieżdżony stan.

Płytka i głęboka kopia to nie to samo

Płytka kopia duplikuje obiekt, ale nie duplikuje wszystkiego, co ten obiekt wskazuje. Jeśli pole zawiera referencję do innego mutowalnego obiektu, obie instancje mogą nadal korzystać z tego samego podobiektu. Głęboka kopia idzie dalej: tworzy nową instancję nie tylko dla obiektu głównego, lecz także dla jego mutowalnych pól i struktury zagnieżdżonej.

To rozróżnienie ma realne skutki. W płytkiej kopii możesz zmienić np. adres lub listę tagów i nagle okaże się, że oryginał też się zmienił. W głębokiej kopii taki efekt nie powinien wystąpić, bo każde istotne, mutowalne ogniwo zostaje powielone osobno. Przy bardzo złożonych grafach obiektów trzeba jeszcze pilnować cykli i już odwiedzonych instancji, bo inaczej łatwo o nieskończoną rekurencję albo wielokrotne kopiowanie tego samego elementu.

W praktyce ja rozdzielam te dwa pojęcia od razu na początku projektu. Jeśli zespół nie ustali tego jasno, później pojawiają się błędy trudne do odtworzenia, szczególnie w kodzie z wieloma referencjami do wspólnych struktur. To prowadzi naturalnie do wyboru konkretnej techniki kopiowania.

Którą technikę kopiowania wybrać w kodzie

W Javie masz kilka sposobów na skopiowanie obiektu, ale nie każdy jest równie czytelny i bezpieczny. W nowych klasach najczęściej wybieram konstruktor kopiujący, bo daje pełną kontrolę nad tym, co ma być duplikowane, a co może zostać współdzielone. `clone()` zostawiam raczej dla starszego kodu albo sytuacji, w której istnieje już taki kontrakt w API.

Widać tu ważną rzecz: nie ma jednej „najlepszej” metody dla wszystkiego. Jest metoda najlepsza dla konkretnego modelu danych. Jeśli klasa ma kilka pól prostych i jedno mutowalne, konstruktor kopiujący zwykle wygrywa, bo możesz skopiować pola proste wprost, a złożone wykonać głębiej. Jeśli pracujesz z klasą, której nie kontrolujesz, albo ze starszym API, wtedy czasem nie ma wyboru i trzeba iść w `clone()` albo własną warstwę mapowania.

class Address {
    private final String city;

    Address(String city) {
        this.city = city;
    }

    Address(Address other) {
        this.city = other.city;
    }
}

class User {
    private final String name;
    private final Address address;

    User(String name, Address address) {
        this.name = name;
        this.address = address;
    }

    User(User other) {
        this.name = other.name;
        this.address = new Address(other.address);
    }
}

To podejście jest przewidywalne: wiadomo, co kopiuję, wiadomo, czego nie kopiuję, i nie muszę zgadywać, jak zachowa się platforma. Z tego powodu dobrze przechodzi ono do następnej grupy problemów, czyli tablic i kolekcji.

Tablice i kolekcje kopiują się inaczej niż zwykłe klasy

Tablice w Javie mają własne, wygodne narzędzia. Możesz użyć `clone()`, `Arrays.copyOf()` albo niższego poziomu, czyli `System.arraycopy()`, jeśli zależy ci na kontroli nad zakresem kopiowania. W dokumentacji `Object.clone()` i klas tablicowych jest jasno widać, że tablice są wspierane przez mechanizm klonowania, ale to nadal nie oznacza automatycznej głębokiej kopii elementów.

int[] original = {1, 2, 3};
int[] copy1 = original.clone();
int[] copy2 = java.util.Arrays.copyOf(original, original.length);

Przy tablicach obiektów sytuacja robi się subtelniejsza. `String[]` nie sprawi problemu, bo `String` jest niemutowalny, ale `User[]` już tak. Kopia tablicy będzie miała nowy kontener, ale same elementy nadal mogą wskazywać na te same obiekty. Jeśli potem zmienisz jeden z nich, efekt zobaczysz w obu miejscach.

Kolekcje zachowują się podobnie. `new ArrayList<>(lista)` kopiuje listę jako strukturę, ale nie klonuje automatycznie każdego elementu. To jest dobre, gdy elementy są niemutowalne, na przykład `String`, `Integer` albo własny value object bez setterów. Jeśli elementy są mutowalne, trzeba skopiować je osobno, na przykład przez mapowanie na nowy obiekt:

List copy = original.stream()
    .map(User::new)
    .toList();

Ja traktuję to jako prostą zasadę: kopiujesz kontener, ale sprawdzasz, czy kopiujesz też jego zawartość. To jeden z tych szczegółów, które odróżniają bezpieczny kod od kodu, który tylko wygląda poprawnie. A czasem najlepsza odpowiedź brzmi po prostu: nie kopiuj wcale.

Kiedy lepiej nie kopiować obiektu wcale

Nie każdy obiekt powinien być kopiowany. Jeśli masz klasę niemutowalną, kopia zwykle nie daje prawie żadnej wartości, bo nie ma ryzyka, że ktoś zmieni jej stan po drodze. W praktyce dużo lepiej projektować modele tak, by były możliwie niemutowalne, niż później leczyć skutki przypadkowego współdzielenia referencji.

To samo dotyczy rekordów i prostych value objects. Jeśli cały obiekt powstaje raz i potem tylko jest odczytywany, kopiowanie staje się kosztownym dodatkiem bez zysku. Zamiast tego tworzysz nową instancję tylko wtedy, gdy naprawdę potrzebujesz innego stanu. To podejście jest prostsze, mniej podatne na błędy i dobrze skaluje się w kodzie, który ma żyć dłużej niż jeden sprint.

Warto też pamiętać o defensywnym kopiowaniu na granicach API. Jeśli przyjmujesz mutowalną kolekcję od użytkownika klasy, zwykle warto skopiować ją w konstruktorze. Jeśli potem ją zwracasz, dobrze jest oddać kopię albo niezmienny widok. Przykład jest prosty:

public final class Order {
    private final java.util.List tags;

    public Order(java.util.List tags) {
        this.tags = new java.util.ArrayList<>(tags);
    }

    public java.util.List getTags() {
        return java.util.List.copyOf(tags);
    }
}

To nadal jest kopia płytka, ale przy `String` działa dobrze, bo elementy są niemutowalne. Gdy elementy są złożone, trzeba podnieść poziom ostrożności. Od tej granicy już tylko krok do najczęstszych błędów, które potrafią zepsuć nawet dobrze zapowiadające się rozwiązanie.

Najczęstsze błędy, które robią z kopii znowu ten sam obiekt

Najbardziej klasyczny błąd to założenie, że przypisanie tworzy nowy obiekt. Nie tworzy. Drugi błąd to uznanie, że każda kopia kolekcji jest automatycznie bezpieczna. Nie jest, jeśli elementy są mutowalne. Trzeci błąd pojawia się przy `clone()`: ktoś zapomina, że metoda domyślnie robi kopię płytką, a później dziwi się, że zmiana w zagnieżdżonym obiekcie trafia do oryginału.

• Przypisanie zamiast kopiowania prowadzi do współdzielonego stanu i trudnych do śledzenia efektów ubocznych.
• Kopiowanie tylko kontenera rozwiązuje problem połowicznie, jeśli elementy nadal są wspólne.
• Pomijanie pól przy konstruktorze kopiującym kończy się niekompletnym stanem i błędami logicznymi.
• Używanie `clone()` bez testów jest ryzykowne, bo łatwo przeoczyć zagnieżdżone referencje.
• Rekurencyjne kopiowanie bez pamiętania odwiedzonych obiektów może wywrócić się na cyklach w grafie obiektów.

Przy złożonych strukturach przydaje się śledzenie już skopiowanych instancji, na przykład z użyciem mapy opartej na tożsamości obiektu. To jest ten moment, w którym kopiowanie przestaje być prostą operacją, a zaczyna przypominać świadome odwzorowanie całego grafu zależności. Dlatego w praktyce wolę upraszczać model danych, zamiast budować mechanizm kopiowania, który później trzeba utrzymywać jak osobny podsystem.

Jak podejść do tego rozsądnie w nowym i starszym kodzie

Jeśli mam wpływ na projekt, zaczynam od prostego pytania: czy ten obiekt naprawdę musi być mutowalny? Jeśli nie, zamieniam go na niemutowalny model i problem kopiowania znika albo staje się marginalny. Jeśli obiekt musi się dać kopiować, wybieram konstruktor kopiujący i zapisuję w nim dokładnie to, co ma być duplikowane, bez liczenia na „magiczne” zachowanie platformy.

W starszym kodzie sytuacja bywa mniej wygodna, bo trzeba szanować istniejące API. Wtedy `clone()` może mieć sens, ale tylko wtedy, gdy już jest częścią kontraktu albo kiedy koszt zmiany całego modelu byłby zbyt duży. Ja traktuję to jako wyjątek, nie domyślną strategię. Dla tablic używam `Arrays.copyOf()` lub `System.arraycopy()`, a dla kolekcji kopiuję najpierw kontener, potem elementy, jeśli są mutowalne.

Najprostsza reguła, którą stosuję w praktyce, brzmi tak: kopiuj tylko tyle, ile naprawdę potrzebujesz odseparować. Jeśli wystarczy nowy kontener, nie rób pełnej głębokiej kopii. Jeśli musisz chronić stan przed zmianą, kopiuj także zagnieżdżone obiekty. A jeśli kopiowanie zaczyna być bardziej skomplikowane niż sam model domenowy, to znak, że lepszym rozwiązaniem będzie przebudowa struktury danych, nie kolejna warstwa obejść.