Traits

Was ein Trait ist

Ein Trait ist eine Sammlung von Methoden-Signaturen, die ein Typ implementieren muss. Konzeptuell ähnlich zu Interfaces in Java oder C#, aber mit deutlich mehr Möglichkeiten.

trait Greet {
    fn greet(&self) -> String;
}

Das trait-Keyword führt die Definition ein. Im Block stehen Methoden-Signaturen — Name, Parameter, Rückgabetyp, aber kein Body. Der Body wird vom implementierenden Typ geliefert.

Implementiert wird ein Trait mit impl Trait for Typ:

# trait Greet { fn greet(&self) -> String; }

struct Person { name: String }
struct Dog;

impl Greet for Person {
    fn greet(&self) -> String {
        format!("Hallo, ich bin {}", self.name)
    }
}

impl Greet for Dog {
    fn greet(&self) -> String {
        String::from("Wuff!")
    }
}

fn main() {
    let p = Person { name: "Anna".into() };
    let d = Dog;
    println!("{}", p.greet());
    println!("{}", d.greet());
}

Zwei völlig unabhängige Typen (Person und Dog) implementieren dasselbe Trait. Beide bekommen die greet-Methode, mit jeweils eigener Implementierung. Aus Sicht des Trait-Konsumenten sind beide Typen austauschbar — solange er nur die Trait-Methoden braucht.

Warum Traits statt Vererbung

In klassischen OOP-Sprachen ist die Standard-Form für Polymorphismus die Klassen-Vererbung: eine Basis-Klasse mit virtuellen Methoden, abgeleitete Klassen die sie überschreiben. Rust hat das nicht. Stattdessen Traits.

Diese Entscheidung ist bewusst. Klassen-Vererbung hat bekannte Probleme: das Diamond-Problem bei Mehrfach-Vererbung, fragile Base-Class-Probleme (Änderungen in der Basis brechen abgeleitete Klassen), tiefe Hierarchien, die schwer zu durchblicken sind, und die enge Kopplung zwischen Basis und Ableitung.

Traits umgehen das alles. Ein Typ kann beliebig viele Traits implementieren, ohne Hierarchie. Es gibt keine „Basis" — nur einen Vertrag, den der Typ erfüllt. Die Polymorphismus-Logik wird auf der Verwendungsseite beschrieben (Trait-Bound an Funktion), nicht auf der Definitionsseite (Klasse erweitert Basis).

Das Resultat ist ein flacheres, kompositionelleres Design. Ein String ist nicht „eine Art Object" (wie in Java), sondern „etwas, das Clone, Display, Debug, Hash, Eq, und viele andere Traits implementiert". Jedes Trait gibt ihm eine spezifische Capability — gemeinsam ergeben sie das Verhalten des Typs.

Die zwei Welten: Static und Dynamic Dispatch

Traits können auf zwei Weisen verwendet werden — eine fundamentale Designentscheidung mit Performance-Folgen.

# trait Greet { fn greet(&self) -> String; }
# struct Person { name: String }
# impl Greet for Person { fn greet(&self) -> String { self.name.clone() } }

fn print_greeting<T: Greet>(item: T) {
    println!("{}", item.greet());
}

fn main() {
    let p = Person { name: "Anna".into() };
    print_greeting(p);
}

Static Dispatch über Generics + Trait-Bound: <T: Greet> ist ein Typ-Parameter mit Constraint. Der Compiler kennt zur Compile-Zeit den konkreten Typ und kann den Aufruf monomorphisieren — eine separate spezialisierte Version pro konkretem T. Maximale Performance, kein Indirection-Cost.

# trait Greet { fn greet(&self) -> String; }
# struct Person { name: String }
# impl Greet for Person { fn greet(&self) -> String { self.name.clone() } }

fn print_greeting(item: &dyn Greet) {
    println!("{}", item.greet());
}

fn main() {
    let p = Person { name: "Anna".into() };
    print_greeting(&p);
}

Dynamic Dispatch über &dyn Trait: der konkrete Typ ist erst zur Laufzeit bekannt. Der Compiler erzeugt eine Vtable — eine Lookup-Tabelle mit Pointern auf die konkreten Methoden-Implementierungen. Beim Aufruf wird die Vtable geladen, der passende Pointer ermittelt, die Methode aufgerufen. Etwas langsamer (Indirection), dafür eine einzige kompilierte Variante und Möglichkeit zu heterogenen Sammlungen wie Vec<Box<dyn Trait>>.

Beide Mechanismen werden in eigenen Artikeln vertieft. In der Praxis ist Static Dispatch der Standard; Dynamic kommt zum Einsatz, wenn du wirklich verschiedene Typen unter einem gemeinsamen Trait-Interface zusammenfassen willst.

Was dich erwartet

Dieses Kapitel ist umfangreich. Es teilt sich in drei thematische Blöcke:

Grundlagen

• Trait-Definition — die Syntax, Methoden-Signaturen, mehrere Methoden pro Trait, Selbst-Parameter, generische Trait-Methoden.
• Default-Methoden — Methoden mit vorgegebenem Body, die der implementierende Typ überschreiben kann. Klassisches Pattern für Trait-Komposition.
• Trait-Bounds im Detail — Trait-Bounds an Funktionen, Methoden, Strukturen. where-Klauseln, kombinierte Bounds, conditional impl.

Dynamic Dispatch

• dyn Trait-Objekte — die Syntax, Trait-Objekt-Safety, Box<dyn Trait>, &dyn Trait, Heterogene Sammlungen.
• Static vs. Dynamic Dispatch — die Unterschiede im Detail. Wann was, mit Performance-Messungen, Binary-Größen, Anwendungsfällen.

Fortgeschrittene Konzepte

• Associated Types — Typen, die Teil des Traits sind und vom implementierenden Typ konkretisiert werden. Iterator::Item, Add::Output.
• Supertraits — wenn ein Trait einen anderen voraussetzt. Ord: Eq + PartialOrd, Copy: Clone. Trait-Hierarchien.
• Orphan-Rule — die Regel „Trait ODER Typ muss aus deinem Crate sein". Warum sie existiert, wie man sie umgeht (Newtype-Pattern).
• Blanket-Implementations — Trait-Impls für alle Typen, die ein anderes Trait haben. impl<T: Display> ToString for T. Mächtiges Pattern aus der Stdlib.
• Marker-Traits — Traits ohne Methoden, die Eigenschaften markieren. Send, Sync, Sized, Copy, Unpin. Auto-Traits.
• Operator-Overloading-Traits — Add, Sub, Mul, Div, Neg, PartialEq, Index, Deref. Wie Operatoren auf eigene Typen erweitert werden.

Was du nach diesem Kapitel kannst

• Eigene Traits definieren — mit oder ohne Default-Methoden, mit Associated Types, mit Trait-Bounds an den Methoden.
• Traits für eigene Typen implementieren und die Stdlib-Traits (Clone, Display, Debug, Iterator, Default) gezielt einsetzen.
• Die Wahl zwischen Static und Dynamic Dispatch bewusst treffen — anhand von Performance-Anforderungen, API-Design, Container-Heterogenität.
• Die Orphan-Rule verstehen und mit Newtype-Pattern umgehen, wenn fremde Traits für fremde Typen implementiert werden sollen.
• Blanket-Implementations als Pattern erkennen und nutzen — sowohl beim Konsumieren (ToString ist eine Blanket-Impl) als auch beim Schreiben eigener.
• Marker-Traits wie Send/Sync in API-Designs einsetzen, um Thread-Safety-Garantien auszudrücken.
• Operator-Overloading nutzen, um eigene Domain-Typen mit natürlicher Mathematik-Syntax auszustatten.

Im nächsten Kapitel geht es zu Lifetimes — das letzte große Konzept, bevor das Buch in spezialisiertere Themen einsteigt.

Weiterführende Ressourcen

Externe Quellen

• The Rust Book – Traits
• Rust Reference – Traits
• Rust by Example – Traits
• The Rustonomicon – Trait Objects
• Rust API Guidelines – Predictability

Verwandte Artikel

• Trait-Definition
• Default-Methoden
• Trait-Bounds im Detail
• dyn Trait-Objekte
• Static vs. Dynamic Dispatch
• Associated Types
• Supertraits
• Orphan-Rule
• Blanket-Implementations
• Marker-Traits
• Operator-Overloading-Traits