"型とは形ではなく、振る舞いの構造である。"
型を定義するとは、何を定義することか？
データの形式か？ フィールドの構造か？
Rustはその問いに対して、明確な立場を取る。
**「振る舞いを定義してこそ、型は意味を持つ」**と。
Rustにおけるトレイト（trait）は、構造体に振る舞いを宿すための哲学的道具である。
それはJavaのinterfaceや、Haskellのtypeclassに通じるが、静的型付けと言語全体の設計美学と深く結びついている。
この章では、Rustのトレイトが**“型を語らせる構造”としてどれほど思想的か**を解き明かす。
「できること」の定義が、型の存在意義を決める
trait Drawable {
fn draw(&self);
}
この一行は、「Drawableという型は存在しない」が、「Drawableである振る舞い」は存在することを示す。
Rustでは、型そのものよりも、型が何を“できるか”を定義することで構造を浮かび上がらせる。
トレイトとは、「この型はこういう振る舞いを持つ」という**“可能性の宣言”**である。
トレイト実装は“振る舞いの接続”である
struct Circle;
impl Drawable for Circle {
fn draw(&self) {
println!("Drawing a circle.");
}
}
この実装によって、Circle は Drawable の“哲学”に同意し、その振る舞いを獲得する。
言い換えれば、トレイトは型と振る舞いの間にある構造的契約である。
なぜ「継承」ではなく「実装」なのか？
Rustは継承をサポートしない。
代わりに、振る舞いを“後付けで合成”することを重視する。
- 継承：構造を上書きする（階層的）
- トレイト：振る舞いを合成する（横断的）
この違いは、設計の硬直性を嫌い、構成可能性を重視するRustの思想の表れである。
トレイト境界とジェネリクス：型の意味論的拡張
fn render<T: Drawable>(item: T) {
item.draw();
}
ここで T: Drawable は、「Tという型はDrawableでなければならない」ことを明示している。
これは、抽象化において意味論的な制限を与えることで、安全性と明快さを両立する設計である。
トレイト境界は、ジェネリクスを構文の“自由”から設計の“制約”へと引き戻す構造でもある。
自動導出（derive）は“構造的同意”の短縮記法
#[derive(Debug, Clone, PartialEq)]
struct Point {
x: i32,
y: i32,
}
derive は、その構造体が特定のトレイトの“契約”に合意していることを意味する。
これは設計者の意図が、構文の簡略化を通して表現されている。
Rustはこのように、設計の哲学的正しさと実装効率を両立させる構文的態度を取っている。
トレイトは「ポリモーフィズム」ではなく「定義の粒度」である
オブジェクト指向では、ポリモーフィズム（多態性）はしばしば柔軟さの代名詞として語られる。
しかしRustでは、トレイトによって“何ができるか”が構文上に明確に現れる。
つまり、**「この関数はこの型に対してこのことしかできない」**という宣言が、型定義の“振る舞いの粒度”を制御する。
デフォルト実装は“共通思想”の抽象化である
trait Greeter {
fn greet(&self) {
println!("Hello.");
}
}
トレイトにデフォルト実装を持たせることは、
“この振る舞いが大多数に共通である”という設計哲学の明文化である。
この仕組みは、コード量の削減だけではなく、設計構造における“共通原理”の集約でもある。
トレイトオブジェクトと動的分配：意図された柔軟性
fn show(g: &dyn Greeter) {
g.greet();
}
&dyn Trait によって、トレイトを持つ任意の型を動的に扱うことが可能になる。
ただしこれは 「全体の設計が許容するときのみ」使える柔軟性であり、
“静的保証された抽象”を越えるときの慎重な設計的選択である。
結語：型とは形ではなく、可能性の構造である
Rustのトレイトは、“この型に何ができるか”を設計者に宣言させる構造的契約である。
それは抽象のための手段であると同時に、設計の明示化、責務の分離、安全性の構造化でもある。
トレイトが語るのは、型の哲学である。
そしてRustは、型を“データの形”から“意味と振る舞いの構造”へと進化させた。
"トレイトとは、型に思想を与えるための言語である。"