geo_contracts のアーキテクチャ構成とメリット
RedRing Architecture 解説シリーズ
🟦 導入
RedRing は「Core/Extension パターン」を中心思想として設計された、モジュール型 CAD カーネルです。 その中でも geo_contracts は、幾何 API の“契約層（Contract Layer）”として、 Core と Extension の境界を定義し、型安全性と拡張性を保証する重要なコンポーネントです。
この記事では、geo_contracts のアーキテクチャ構成とメリットに焦点を絞り、 RedRing の設計思想がどのように実装へ落とし込まれているかを解説します。
🧩 geo_contracts のアーキテクチャ構成
geo_contracts は、幾何計算に関わる Trait（契約） を定義する層です。 この層は、RedRing の Core と Extension の境界を明確にし、依存方向を固定する役割を持ちます。
1. 幾何オブジェクトの Trait 契約
geo_contracts は、幾何オブジェクトが満たすべき API を Trait として定義します。
- Curve2D / Curve3D
- Surface
- Transformable
- Bounding
- Evaluatable（evaluate, derivative など）
これらは 「幾何オブジェクトは何ができるべきか」 を定義する契約であり、 実装は Extension 側に委ねられます。
2. geo_foundation（型分類）との接続点
geo_contracts の API は、geo_foundation の型分類を前提に設計されています。
- Point
- Vector
- Direction
- Transform
これらの型を使う API の 意味論的制約（semantic constraints） を契約として固定します。
例：
- derivative は Vector を返す
- tangent は Direction を返す
- evaluate は Point を返す
3. Extension 側の実装を束縛しない抽象化
geo_contracts は抽象化のみを提供し、実装は Extension 側に自由に追加できます。
Extension 側の例：
- NURBS
- Bezier
- Line / Circle / Ellipse
- Meshing
- IO（STEP, SVG）
- Renderer（wgpu）
依存方向は常に Extension → geo_contracts → geo_foundation であり、 逆方向の依存は発生しません。
🧠 geo_contracts が必要な理由
CAD カーネルは構造が複雑になりやすく、以下の問題を抱えがちです。
- 幾何計算とデータ構造が密結合
- 曲線・曲面の実装が巨大化
- NURBS・Bezier・Line が同じクラスに混在
- 依存関係が循環しやすい
- API が暗黙的で誤用が多い
geo_contracts はこれらの問題を Rust の Trait による契約として明示化し、 抽象化の境界を固定することで構造崩壊を防ぎます。
🚀 geo_contracts のメリット
1. Core/Extension の依存方向を固定できる
Core は抽象化（契約）だけを持ち、 Extension は実装だけを持つ。
依存方向が一方向で循環しないため、 CAD カーネル特有の巨大化・複雑化を防ぎます。
2. 幾何 API の意味論的誤用を防ぐ
geo_contracts は API の意味論を契約として固定します。
例：
- derivative → Vector
- tangent → Direction
- evaluate → Point
- transform → Transform
これにより、数学的誤りをコンパイル時に検出できます。
3. 曲線種の追加が容易
geo_contracts が抽象化を提供するため、 Extension 側は自由に実装できます。
rust
fn length<C: Curve2D>(curve: &C) -> f64 {
curve.length()
}
Code language: HTML, XML (xml)新しい曲線種を追加しても既存コードが壊れません。
4. geo_foundation の型分類との整合性
Point / Vector / Direction / Transform の型分類は RedRing の設計思想の中心ですが、 その型をどう使うかは geo_contracts が決めます。
型分類の意味論が API に反映されるため、 数学的整合性が保たれます。
5. Extension の自由度が最大化される
Extension 側は自由に実装を追加できます。
- KnotVector の差し替え
- BasisFunction の高速化
- Meshing アルゴリズムの変更
- IO フォーマットの追加
Core に影響せずに拡張できるため、 Rust の所有権モデルと相性が良いモジュール分離が実現します。
🔍 他CADカーネルとの比較
Truck（Rust製）
Truck は geotrait による抽象化を採用していますが、 geo_contracts のような「契約層」は明確に分離されていません。
👉 RedRing の方が 抽象化層が明確で、依存方向がより厳密。
OpenCascade（C++）
- 抽象化はあるが巨大クラスに混在
- 依存方向が複雑
- API が暗黙的で誤用が多い
👉 geo_contracts は OCCT の複雑さを避けるための“現代的な契約層” と言える。
🎯 結論
geo_contracts は RedRing のアーキテクチャの中心であり、 幾何 API の契約を定義することで、Core/Extension の分離・型安全性・拡張性を保証する。
- 抽象化の境界を固定する
- 幾何 API の意味論を明確化する
- 実装の自由度を最大化する
- 依存方向を一方向に保つ
- CAD 特有の誤用をコンパイル時に防ぐ
👉 RedRing の「モジュール型 CAD カーネル」という思想を最も体現している層が geo_contracts である。