はじめに
RedRing は「Core/Extension パターン」を中心思想として設計されたモジュール型 CAD カーネルです。 その中で geo_contracts は、幾何 API の契約層として、 model 層に存在する各幾何モジュールと上位層の境界を定義する役割を担います。
この記事では、geo_contracts のアーキテクチャ構成とメリットを解説します。
geo_contracts のアーキテクチャ構成
幾何オブジェクトの Trait 契約
geo_contracts は、幾何オブジェクトが満たすべき API を Trait として定義します。
- Curve2D / Curve3D
- Surface
- Transformable
- Bounding
- Evaluatable（evaluate, derivative など）
これらは「幾何オブジェクトは何ができるべきか」を定義する契約であり、 実装は model 層の各モジュール側に委ねられます。
型分類との接続点
geo_contracts の API は、RedRing 内で利用される基本的な型分類を前提に設計されています。
- Point
- Vector
- Direction
- Transform
API の意味論的制約を契約として固定することで、誤用を防ぎます。
例：
- derivative は Vector を返す
- tangent は Direction を返す
- evaluate は Point を返す
model 層の実装を束縛しない抽象化
geo_contracts は抽象化のみを提供し、実装は model 層に自由に追加できます。
model 層の例：
- geo_primitives
- geo_nurbs
- geo_entity
- geo_topology
- geo_io
- geo_algorithms
- geo_core（幾何処理の基盤モジュール）
依存方向は常に model → geo_contracts であり、逆方向の依存は発生しません。
geo_contracts が必要な理由
CAD カーネルは構造が複雑になりやすく、以下の問題を抱えがちです。
- 幾何計算とデータ構造が密結合
- 曲線・曲面の実装が巨大化
- NURBS・Bezier・Line が同じクラスに混在
- 依存関係が循環しやすい
- API が暗黙的で誤用が多い
geo_contracts はこれらの問題を Trait による契約として明示化し、 抽象化の境界を固定することで構造崩壊を防ぎます。
geo_contracts のメリット
依存方向を固定できる
抽象化（契約）と実装を分離することで、 依存方向が一方向になり循環が発生しません。
幾何 API の意味論的誤用を防ぐ
API の意味論を契約として固定することで、数学的誤りをコンパイル時に検出できます。
曲線種の追加が容易
抽象化が固定されているため、model 層は自由に実装を追加できます。
rust
fn length<C: Curve2D>(curve: &C) -> f64 {
curve.length()
}
Code language: HTML, XML (xml)新しい曲線種を追加しても既存コードが壊れません。
型分類との整合性
Point / Vector / Direction / Transform の型分類が API に反映されるため、 数学的整合性が保たれます。
model 層の自由度が最大化される
抽象化層に影響せずに拡張できるため、 Rust の所有権モデルと相性が良いモジュール分離が実現します。
まとめ
geo_contracts は RedRing のアーキテクチャの中心であり、 幾何 API の契約を定義することで、型安全性・拡張性・依存方向の明確化を実現します。
- 抽象化の境界を固定する
- 幾何 API の意味論を明確化する
- 実装の自由度を最大化する
- 依存方向を一方向に保つ
- CAD 特有の誤用をコンパイル時に防ぐ
RedRing の「モジュール型 CAD カーネル」という思想を最も体現している層が geo_contracts です。