【大事件】オブジェクト指向の破綻。RustがClassを捨てた理由

「クラスを使いなさい。」
1990年代から2000年代にかけて、プログラマーなら何度も聞かされた言葉です。
私自身もオブジェクト指向こそがソフトウェア開発の完成形だと思っていました。

ところが60歳を過ぎてRustの勉強を始めたとき、衝撃の事実を知ります。

RustにはClassがありません。

最初は驚きました。

「え？オブジェクト指向を捨てるなんて時代遅れでは？」

ところが学べば学ぶほど、RustがClassを捨てたのは退化ではなく進化だったことが見えてきたのです。

1990年代、オブジェクト指向は救世主だった

1990年代のプログラムは巨大化していました。
機能は増え続け、コードは複雑になり、開発者は保守に苦しんでいました。

そこで登場したのがオブジェクト指向です。

データと処理を一つにまとめる。
現実世界の概念をクラスとして表現する。
継承によって共通機能を再利用する。

この仕組みは当時としては革命的でした。
コードは整理され、再利用性も向上しました。

JavaやC++は世界中で普及し、「オブジェクト指向を知らないプログラマーは時代遅れ」とまで言われるようになります。

ところがゲーム開発の現場で問題が起きた

理論上は美しかった継承構造ですが、ゲームが大規模化すると別の問題が発生しました。

ゲームには例外が大量に存在します。

例えばRPGのキャラクターを考えてみましょう。

最初は整理されて見えます。
しかし新しい敵が増えるたびに継承が深くなります。

やがて誰も全体構造を理解できなくなります。

修正すると別のクラスが壊れる。
親クラスの修正が予想外の影響を与える。

いわゆる「スパゲッティ化」が発生するのです。

継承は再利用ではなく依存を生んだ

理論では継承は便利です。

しかし実際には、
親クラスへの依存がどんどん増えていきます。

ゲーム開発では特に深刻です。

毎月仕様が変わる。
ステータス計算式も変わる。
新スキルも追加される。
新モンスターも増える。

このような環境では、
硬直化した継承構造が足かせになったのです。

RustはClassを捨てた

Rustの設計者たちは大胆な決断をしました。

Classによる継承を採用しなかったのです。

代わりに採用したのが次の考え方でした。

• Struct
• Trait
• Composition（組み合わせ）

つまり、
継承ではなく部品の組み合わせで設計しようという考え方です。

Structはデータの箱

Structは単純です。
データを保存します。

余計な機能は持ちません。

WordPressで言えば、
投稿データやユーザーデータをまとめた箱のような存在です。

Traitは能力そのもの

Traitは能力です。

攻撃できる。
飛べる。
泳げる。
回復できる。

能力ごとに分離します。

この発想はゲームと非常に相性が良いのです。

ゼビウスで考えるRust設計

1984年の名作ゲーム「ゼビウス」を例に考えてみましょう。

自機ソルバルウは、

• 移動できる
• 空中攻撃できる
• 地上攻撃できる

という能力を持っています。

一方で敵によって能力は異なります。

継承中心の設計では複雑な階層構造になりがちです。

しかしRustなら、
「移動できる」
「攻撃できる」
というTraitを組み合わせれば済みます。

その結果、設計が単純になります。

ECSという新しい考え方

さらに近年のゲーム開発ではECSが主流になっています。

Entity Component Systemの略です。

BevyもECSを採用しています。

データを部品化して組み立てる方式です。

継承構造をなくし、
柔軟性を高めます。

RustはこのECSと驚くほど相性が良いのです。

PHP経験者ほど衝撃を受ける

WordPress開発を長く続けた人ほど驚きます。

私たちは長年、
クラス設計を学んできました。

SOLID原則。
デザインパターン。
継承。
抽象クラス。
インターフェース。

しかしRustの世界に入ると、
それらとは少し違う発想が現れます。

最初は戸惑います。

それでも理解が進むにつれて、
「確かにこの方がシンプルだ」
と思う瞬間が訪れます。

60歳からだからこそ面白い

若い頃なら、
新しい考え方に出会っても深く考えなかったかもしれません。

しかし長くソフトウェア開発を続けてきた今だからこそ、
オブジェクト指向の限界も理解できます。

Rustを学ぶことは、
単に新しい言語を学ぶことではありません。

ソフトウェア設計そのものを見直す旅でもあるのです。