0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

builderパターンに見る設計の非可逆性

Posted at

"設計とは、後戻りできない工程をどこに置くかという選択の連続である。"

Rustの設計において、構造体の初期化は特に重要なフェーズだ。
一度構築されたオブジェクトは、変更されることなく、そのまま信頼して使用できる必要がある。
この「不変の構造」をどう設計するかが、型安全性と構文的信頼の核心となる。

Rustは、**「不完全な構造を一時的に許容し、完成時に正しさを保証する」**ための構文的パターンを求める。
それが builderパターンである。

この章では、builderパターンを単なる利便性の手法としてではなく、
「設計の非可逆性」=不可逆な初期化の安全な完了手段として捉え、その構文的意義を深掘りする。


初期化とは“意味を確定させる構文的契機”である

Rustでは、フィールドが未初期化のまま構造体を保持することはできない。

struct Config {
    host: String,
    port: u16,
}

// 必ずすべてのフィールドを初期化しなければならない
let config = Config {
    host: "localhost".into(),
    port: 8080,
};

この設計原則は、「すべての構造体は、完全であることを前提に扱われるべき」という言語の哲学である。
しかし、構築途中の不完全な状態を一時的に扱いたい場面もある。
その橋渡しをするのが、builderパターンだ。


builderパターンとは「初期化途中の状態を安全に表現する構造」である

struct ConfigBuilder {
    host: Option<String>,
    port: Option<u16>,
}

ここでの Option<T> は、「未設定である可能性を構文上で認めた状態」である。

そして完成系:

impl ConfigBuilder {
    fn build(self) -> Result<Config, String> {
        Ok(Config {
            host: self.host.ok_or("host is required")?,
            port: self.port.ok_or("port is required")?,
        })
    }
}

この build() メソッドは、「完全であるかどうか」を最終的に検査する門番であり、
この関数を通らない限り、Configという完全構造体は生まれないという制約を保つ。


フィールド単位の逐次的意味生成

impl ConfigBuilder {
    fn host(mut self, value: impl Into<String>) -> Self {
        self.host = Some(value.into());
        self
    }

    fn port(mut self, value: u16) -> Self {
        self.port = Some(value);
        self
    }
}

これらのメソッドは、「構造体の意味を段階的に構文上で確定させていく」行為に他ならない。

  • host() を呼べば「ホスト名が決まった」
  • port() を呼べば「ポート番号が決まった」

このように、オブジェクトが“完成に近づいていく過程”を構文的にトレースできるのがbuilderパターンの強みである。


非可逆な設計:一度buildされたら戻れない

let config = ConfigBuilder::new()
    .host("example.com")
    .port(80)
    .build()
    .expect("Failed to build config");

ここで生まれた config は、すべてのフィールドが正しく初期化されたことをコンパイラも開発者も保証している
この保証は「構文上、再び未完成には戻れない」という不可逆性によって支えられている。

設計者はこれにより、「一度完成したものは、壊せない構造」を前提としたロジックが書けるようになる。


Rustにおけるbuilderの意味:設計フェーズの分離

  • Builder設計中の一時的構造
  • Struct設計が確定した意味的構造

この分離により、以下のことが可能になる:

  • 構築途中の状態を保持しながら、型の安全性を壊さない
  • 不完全な状態に Option<T> を用いることで、欠損を構文で可視化できる
  • 完了の瞬間にだけ Result を返し、エラー処理と正規動作を分離する

これは、可変から不変への設計的移行でもある。


なぜbuilderを使うべきか?:安全と自由の同時実現

Rustは、「すべてが不変であること」を好む。
だが、現実の初期化フローは段階的な値の追加・設定を必要とする
この相反する要件に対して、builderパターンは不変設計への“構文的経路”を提供する

  • 中間状態に不安定さを許す
  • 最終状態には強固な保証を与える

この移行構造こそが、設計の現実と構文の理想を接続する唯一の道である。


結語:builderは、構文における構造化された“意思決定の記録”である

builderパターンは、構文的な利便性以上の意味を持つ。
それは、「どの段階で、どの意思決定がなされたか」を構文で記録し、
最終的に「これが完成された構造である」と宣言する設計上の一種のプロトコルである。

Rustは、不完全さを受け入れながら、それを構造で囲い込み、明確な境界で“完成”へと到達させる言語である。

"構造体とは設計の成果であり、builderはその過程を誠実にたどる構文的ドキュメントである。"

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?