Klasy vs struktury: kiedy używać których

Podsumowanie: Porównanie klas i struktur — wartości vs referencje, pamięć, wydajność i wskazówki projektowe pomagające wybrać odpowiedni typ dla wydajnego kodu.

Wprowadzenie

Decyzja między klasami a strukturami to mniej kwestia składni, a bardziej semantyki. Kluczowe pytanie brzmi, czy potrzebujesz semantyki wartościowej (kopiowanie danych), czy semantyki referencyjnej (wspólna tożsamość). Ta różnica wpływa na użycie pamięci, wydajność, mutowalność i architekturę. Ten przewodnik wyjaśnia te kompromisy i daje praktyczne zasady wyboru właściwego typu.

Podstawowe rozróżnienie: semantyka wartościowa vs referencyjna

Gdy odrzucisz składnię języka, rozmowa o klasach kontra strukturach sprowadza się do typów wartościowych kontra typów referencyjnych. Pomyśl o strukturze jak o skserowanym notatniku: dajesz komuś swoje notatki i otrzymuje on własną kopię. Może bazgrać bez zmieniania twojego oryginału. To semantyka wartościowa — bezpieczne, odizolowane kopie. Klasa jest jak współdzielony dokument: wysyłasz link i wszyscy edytują ten sam, żywy obiekt. To semantyka referencyjna — wspólna tożsamość i współdzielony stan.

Kluczowe różnice w pigułce

Te zasady mają praktyczne konsekwencje dla opóźnień, użycia pamięci i poprawności. Świadomy wybór sprawi, że twój kod będzie bardziej przewidywalny i łatwiejszy w utrzymaniu.

Jak alokacja pamięci wpływa na wydajność

Stos i sterta to miejsca, z których wynikają większość efektywnych konsekwencji tej decyzji dotyczącej wydajności.

Stos: szybki i przewidywalny

Stos to obszar pamięci LIFO, gdzie wypychane i zdejmowane są dane lokalne funkcji. Alokacja na stosie jest bardzo tania, ponieważ to tylko arytmetyka wskaźnika. Dla małych typów wartościowych alokacja i dealokacja są prawie darmowe.

Sterta: elastyczna, ale droższa

Sterta pozwala obiektom przeżyć jedno wywołanie funkcji, ale alokacja na stercie jest wolniejsza i może wywołać garbage collection lub wymagać ręcznej dealokacji. Typy referencyjne wprowadzają dodatkową indirection: na stosie przechowywany jest wskaźnik do danych na stercie. Powtarzające się alokacje na stercie zwiększają presję GC i mogą powodować pauzy w środowiskach zarządzanych¹.

Przykład w C#

// Value Type - lives inline (often on the stack)
public struct PointStruct {
    public int X;
    public int Y;
}

// Reference Type - object lives on the heap
public class PointClass {
    public int X;
    public int Y;
}

public void ProcessPoints() {
    PointStruct p1 = new PointStruct { X = 10, Y = 20 };
    PointClass p2 = new PointClass { X = 10, Y = 20 };
}

W ciasnych pętlach tysiące alokacji na stercie dla małych obiektów mogą znacząco zwiększyć aktywność GC; struktury w tablicach często osiągają znacznie lepszą lokalność pamięci podręcznej (cache locality) i niższą presję GC².

Jak języki traktują klasy i struktury

Różne języki kładą nacisk na różne domyślne podejścia. Najlepszy wybór zależy od idiomów języka tak samo jak od surowej wydajności.

C++: niemal identyczne słowa kluczowe

W C++ struct i class są prawie takie same; jedyna techniczna różnica to domyślny dostęp (public dla struct, private dla class). Używaj struct dla agregatów prostych danych i class dla typów kapsułkowanych i złożonego zachowania³.

C#: wyraźny podział wartości/referencji

C# wyraźnie rozgranicza: struct to prawdziwy typ wartościowy, a class to typ referencyjny. Używaj struktur dla małych, niemutowalnych wartości (współrzędne, kolory) i klas dla bytów z tożsamością i współdzielonym, mutowalnym stanem.

Swift: preferuj typy wartościowe

Swift zachęca do podejścia „wartość najpierw”. Wytyczne Apple i społeczność Swift faworyzują struct domyślnie i rezerwują class dla przypadków wymagających semantyki referencyjnej, takich jak współdzielony mutowalny stan lub integracja z API Objective-C⁴.

Rust: własność i bezpieczeństwo

Rust używa struct wraz z modelem własności i pożyczania (ownership and borrowing), aby zapewnić bezpieczeństwo pamięci bez garbage collectora. Zachowanie jest dołączane przez bloki impl, a kompilator wymusza reguły własności i pożyczania w czasie kompilacji, zapobiegając wielu błędom związanym ze współdzielonym stanem przed uruchomieniem⁵.

struct Player {
    username: String,
    level: u32,
    is_active: bool,
}

impl Player {
    fn level_up(&mut self) {
        self.level += 1;
    }
}

Podejście Rust daje wydajność dzięki bezpośredniej kontroli pamięci oraz gwarancje bezpieczeństwa w czasie kompilacji.

Kiedy wybrać strukturę dla lepszej wydajności

Wybierz strukturę, gdy typ jest mały, samodzielny i traktowany jak wartość, a nie tożsamość. Typowe kandydatury:

• Punkty geometryczne (Point2D)
• Wartości kolorów (RGB/RGBA)
• Małe ładunki konfiguracyjne
• Lekkie wejścia do obliczeń

Korzyści obejmują mniejszą liczbę alokacji na stercie, poprawioną lokalność pamięci podręcznej oraz mniejszą presję GC w środowiskach zarządzanych. Lepsza lokalność cache może dać duże przyspieszenia w pętlach przetwarzających dużo danych, ponieważ wzorce dostępu do pamięci stają się bardziej przyjazne dla CPU².

Kiedy wybrać klasę do modelowania złożonego zachowania

Wybierz klasę, gdy obiekt ma stabilną tożsamość, współdzielony mutowalny stan lub gdy potrzebujesz dziedziczenia albo złożonego zarządzania cyklem życia. Typowe przykłady:

• Profile użytkowników lub byty domenowe
• Obiekty połączeń z bazą danych lub siecią
• Serwisy i menedżery koordynujące stan

Klasy są fundamentem wielu wzorców obiektowych. Dziedziczenie i polimorfizm ułatwiają modelowanie złożonych relacji i zachowań.

Lista kontrolna decyzji: struktura vs klasa

Częste pytania

Czy struktura może mieć metody?

Tak. Nowoczesne języki jak C#, Swift i Rust pozwalają strukturom mieć metody, konstruktory i implementować protokoły lub interfejsy. Główna różnica nadal dotyczy tego, jak są kopiowane i przekazywane.

Czy struktury są zawsze szybsze?

Nie. Małe struktury często przewyższają wydajnością obiekty alokowane na stercie, ale duże struktury mogą stać się kosztowne w kopiowaniu. Zawsze mierz: profiluj rzeczywiste obciążenia przed dokonaniem szerokich zmian.

Czy struktury wspierają dziedziczenie?

Zazwyczaj nie. Struktury rzadko wspierają dziedziczenie, ale wiele języków pozwala strukturom implementować interfejsy lub protokoły, co umożliwia elastyczną kompozycję bez głębokich łańcuchów dziedziczenia.

Praktyczne Q&A

P: Kiedy powinienem zrefaktoryzować klasę na strukturę?

A: Zrefaktoryzuj, gdy typ jest małą, niemutowalną wartością bez unikalnej tożsamości i chcesz mniej alokacji na stercie oraz jaśniejszej semantyki wartości.

P: Jak uniknąć pauz GC w językach zarządzanych?

A: Zmniejsz krótkotrwałe alokacje na stercie, preferując struktury dla małych wartości, ponownie używaj obiektów i stosuj pule obiektów; mierz zachowanie GC pod obciążeniem¹.

P: Jaka jest najprostsza zasada?

A: Jeśli obiekt reprezentuje „wartość”, użyj struktury; jeśli reprezentuje „rzecz z tożsamością”, użyj klasy.

Trzy zwięzłe sekcje Q&A

Q&A 1 — kompromis wydajności

P: Czy zmiana na struktury zawsze poprawi szybkość? A: Nie. Używaj struktur dla małych, często tworzonych wartości, aby zmniejszyć presję GC i poprawić lokalność cache; unikaj dużych struktur kosztownych do kopiowania.

Q&A 2 — bezpieczeństwo i poprawność

P: Czy struktury zmniejszają liczbę błędów związanych ze współdzielonym stanem? A: Tak. Semantyka wartościowa zapobiega przypadkowemu współdzieleniu mutacji, co zmniejsza błędy związane z współbieżnością i stanem, gdy wartości są kopiowane zamiast współdzielone.

Q&A 3 — projekt i architektura

P: Kiedy klasa jest lepszym modelem niż struktura? A: Użyj klasy, gdy wymagana jest tożsamość, długotrwały cykl życia lub dziedziczenie i polimorfizm.

W Clean Code Guy pomagamy zespołom refaktoryzować pod kątem skalowalności i utrzymywalności. Dowiedz się więcej na https://cleancodeguy.com.