Klassen vs Strukturen: Wann man welche verwenden sollte

Zusammenfassung: Vergleiche Klassen und Strukturen — Wert- vs. Referenztypen, Speicher, Leistung und Designhinweise, um den richtigen Typ für effizienten Code zu wählen.

Einleitung

Die Entscheidung zwischen Klassen und Strukturen ist weniger eine Frage der Syntax als der Semantik. Die entscheidende Frage ist, ob du Wertsemantik (Datenkopien) oder Referenzsemantik (gemeinsame Identität) benötigst. Dieser Unterschied wirkt sich auf Speicherverbrauch, Leistung, Änderbarkeit und Architektur aus. Dieser Leitfaden erklärt diese Abwägungen und gibt praktische Regeln zur Auswahl des passenden Typs.

Der Kernunterschied: Wert- vs. Referenzsemantik

Wenn man die Sprachsyntax weglässt, ist die Diskussion Klassen versus Strukturen im Kern eine über Werttypen versus Referenztypen. Denk an eine Struktur wie an einen fotokopierten Notizblock: Du gibst jemandem deine Notizen und diese Person erhält eine eigene Kopie. Sie kann darin herumkritzeln, ohne dein Original zu verändern. Das ist Wertsemantik — sichere, isolierte Kopien. Eine Klasse ist wie ein geteiltes Dokument: Du schickst einen Link und alle bearbeiten dasselbe Live-Objekt. Das ist Referenzsemantik — gemeinsame Identität und geteilter Zustand.

Wichtige Unterschiede auf einen Blick

Diese Prinzipien haben praktische Konsequenzen für Latenz, Speicherverbrauch und Korrektheit. Eine bewusste Wahl macht deinen Code vorhersagbarer und leichter wartbar.

Wie Speicherzuweisung die Leistung beeinflusst

Der Stack und der Heap sind die Orte, an denen die meisten Leistungsunterschiede dieser Entscheidung entstehen.

Der Stack: schnell und vorhersehbar

Der Stack ist ein LIFO-Speicherbereich, in den funktionslokale Daten gepusht und wieder gepoppt werden. Auf dem Stack zu allozieren ist sehr günstig, weil es nur Pointer-Arithmetik ist. Für kleine Werttypen sind Allokation und Deallokation nahezu kostenfrei.

Der Heap: flexibel, aber teurer

Der Heap erlaubt es Objekten, über einen einzelnen Funktionsaufruf hinaus zu leben, aber die Heap-Allokation ist langsamer und kann Garbage Collection oder manuelle Freigabe auslösen. Referenztypen bringen eine zusätzliche Indirektion mit sich: Der Stack hält einen Pointer auf Heap-Daten. Wiederholte Heap-Allokationen erhöhen den GC-Druck und können in verwalteten Laufzeiten zu Pausen führen¹.

C#-Beispiel

// 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 };
}

In engen Schleifen können tausende Heap-Allokationen für kleine Objekte die GC-Aktivität deutlich erhöhen; Strukturen in Arrays erzielen oft eine viel bessere Cache-Lokalität und geringeren GC-Druck².

Wie Sprachen Klassen und Strukturen behandeln

Verschiedene Sprachen setzen unterschiedliche Schwerpunkte. Die beste Wahl hängt ebenso sehr von Sprachgewohnheiten wie von roher Leistung ab.

C++: fast identische Schlüsselwörter

In C++ sind struct und class fast gleich; der einzige technische Unterschied ist der Standardzugriff (public für struct, private für class). Verwende struct für Plain-Data-Aggregate und class für gekapselte Typen und komplexes Verhalten³.

C#: eine klare Wert-/Referenz-Trennung

C# macht die Unterscheidung explizit: struct ist ein echter Werttyp und class ist ein Referenztyp. Verwende Strukturen für kleine, unveränderliche Werte (Koordinaten, Farben) und Klassen für Entitäten mit Identität und gemeinsamem, veränderlichem Zustand.

Swift: Werttypen bevorzugen

Swift fördert einen wertorientierten Ansatz. Die Empfehlungen von Apple und die Swift-Community bevorzugen struct standardmäßig und reservieren class für Fälle, die Referenzsemantik erfordern, wie geteilten veränderlichen Zustand oder die Interaktion mit Objective-C-APIs⁴.

Rust: Ownership und Sicherheit

Rust verwendet struct zusammen mit einem Ownership- und Borrowing-Modell, um Speichersicherheit ohne Garbage Collector zu bieten. Verhalten wird über impl-Blöcke angehängt, und der Compiler erzwingt Ownership- und Borrowing-Regeln zur Compile-Zeit, wodurch viele gemeinsame Zustandsfehler bereits vor der Laufzeit verhindert werden⁵.

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

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

Rusts Ansatz gibt dir die Leistung direkter Speichersteuerung mit Compile-Zeit-Sicherheitsgarantien.

Wann du eine Struktur für bessere Leistung wählen solltest

Wähle eine Struktur, wenn der Typ klein, in sich geschlossen und eher als Wert denn als Identität behandelt wird. Typische Kandidaten:

• Geometrische Punkte (Point2D)
• Farbwerte (RGB/RGBA)
• Kleine Konfigurations-Payloads
• Leichte Eingabewerte für Berechnungen

Vorteile sind weniger Heap-Allokationen, verbesserte Cache-Lokalität und geringerer GC-Druck in verwalteten Laufzeiten. Verbesserte Cache-Lokalität kann in datenintensiven Schleifen große Geschwindigkeitszuwächse bringen, weil Zugriffszeiten CPU-freundlicher werden².

Wann du eine Klasse wählen solltest, um komplexes Verhalten zu modellieren

Wähle eine Klasse, wenn ein Objekt eine stabile Identität hat, gemeinsamen veränderlichen Zustand besitzt oder wenn du Vererbung bzw. komplexes Lebenszyklus-Management brauchst. Typische Kandidaten:

• Benutzerprofile oder Domain-Entitäten
• Datenbank- oder Netzwerkverbindungsobjekte
• Dienste und Manager, die Zustand koordinieren

Klassen sind die Grundlage vieler objektorientierter Muster. Vererbung und Polymorphismus erleichtern das Modellieren komplexer Beziehungen und Verhaltensweisen.

Entscheidungs-Checkliste: Struktur vs. Klasse

Häufige Fragen

Kann eine Struktur Methoden haben?

Ja. Moderne Sprachen wie C#, Swift und Rust erlauben Strukturen, Methoden, Initialisierer und Protokoll- bzw. Interface-Konformität zu haben. Der Hauptunterschied bleibt, wie sie kopiert und übergeben werden.

Sind Strukturen immer schneller?

Nein. Kleine Strukturen übertreffen oft heap-allokierte Objekte, aber große Strukturen können teuer zu kopieren sein. Messe immer: Profile reale Workloads, bevor du umfassende Änderungen vornimmst.

Unterstützen Strukturen Vererbung?

In der Regel nicht. Strukturen unterstützen selten Vererbung, aber viele Sprachen erlauben Strukturen, Interfaces oder Protokolle zu implementieren, was flexible Komposition ohne tiefe Vererbungshierarchien ermöglicht.

Praktisches Q&A

Q: Wann sollte ich eine Klasse in eine Struktur refaktorisieren?

A: Refaktoriere, wenn der Typ ein kleiner, unveränderlicher Wert ohne eindeutige Identität ist und du weniger Heap-Allokationen sowie klarere Wertsemantik möchtest.

Q: Wie vermeide ich GC-Pausen in verwalteten Sprachen?

A: Reduziere kurzlebige Heap-Allokationen, indem du für kleine Werte Strukturen bevorzugst, Objekte wiederverwendest und Objekt-Pools einsetzt; messe das GC-Verhalten unter Last¹.

Q: Was ist die einfachste Faustregel?

A: Wenn das Objekt „ein Wert“ darstellt, verwende eine Struktur; wenn es „ein Ding mit Identität“ darstellt, verwende eine Klasse.

Drei prägnante Q&A-Abschnitte

Q&A 1 — Performance-Abwägung

Q: Verbessert der Wechsel zu Strukturen immer die Geschwindigkeit? A: Nein. Verwende Strukturen für kleine, häufig erstellte Werte, um GC-Druck zu reduzieren und die Cache-Lokalität zu verbessern; vermeide große Strukturen, die teuer zu kopieren sind.

Q&A 2 — Sicherheit und Korrektheit

Q: Reduzieren Strukturen Bugs durch geteilten Zustand? A: Ja. Wertsemantik verhindert unabsichtliche gemeinsame Mutation und reduziert so Nebenläufigkeits- und zustandsbedingte Fehler, wenn Werte kopiert statt geteilt werden.

Q&A 3 — Design und Architektur

Q: Wann ist eine Klasse ein besseres Modell als eine Struktur? A: Verwende eine Klasse, wenn Identität, ein langer Lebenszyklus oder Vererbung und Polymorphismus erforderlich sind.

Bei Clean Code Guy helfen wir Teams beim Refactoring für Skalierbarkeit und Wartbarkeit. Erfahre mehr unter https://cleancodeguy.com.