Day 008 — 構造体の基礎（struct定義・フィールドタグ）

📚 背景知識（読んでから問題へ）

構造体（struct）は、複数の異なる型のフィールドを1つにまとめた集合型です。Goにはクラスがないため、「データの入れ物」としての役割は構造体が担います。

📋 コピーtype Config struct {
	Name    string
	Retries int
	Timeout int
}

構造体を宣言しただけでは値は作られません。Config{}のようにゼロ値で作ることも、Config{Name: "api", Retries: 3}のようにフィールド名を指定して初期化することもできます。フィールドを指定しなかった場合は、それぞれの型のゼロ値（stringなら""、intなら0）が入ります。

構造体にはフィールドタグという文字列メタデータを付けられます。

📋 コピーtype Config struct {
	Name    string `json:"name"`
	Retries int    `json:"retries"`
}

フィールドタグ自体はGoの言語仕様としては「フィールドに付随する単なる文字列」に過ぎず、コンパイラは特別扱いしません。しかしencoding/jsonのような標準ライブラリやサードパーティのライブラリがreflectパッケージ経由でこの文字列を読み取り、「JSONエンコード時にこのフィールドをnameというキー名にする」といった振る舞いを実現しています。つまりフィールドタグは「構造体とリフレクションを組み合わせることで、言語機能を拡張せずにメタデータ駆動の振る舞いを実現する」というGoらしい設計の一例です。

そして、今回のテーマで最も重要なのが構造体は値型であるという事実です。

📋 コピーc1 := Config{Name: "api"}
c2 := c1      // c2 は c1 の「コピー」。フィールドが全部複製される
c2.Name = "web"
fmt.Println(c1.Name) // "api" のまま。c2の変更はc1に影響しない

これは配列と同じ挙動で、スライスやマップとは対照的です（スライス・マップは内部にポインタを持つ参照的な型でした）。構造体は「代入」でも「関数への引数渡し」でも、値そのものがまるごとコピーされます。この挙動を理解していないと、「関数の中でフィールドを書き換えたつもりが、呼び出し元には反映されていない」という典型的なバグを踏みます。

📝 問題

以下のコードは、Config構造体に対してデフォルト値を設定するapplyDefaults関数を実装したつもりですが、期待通りに動作しません。バグを特定し、修正してください。

バグのあるコード:

📋 コピーpackage main

import "fmt"

type Config struct {
	Name    string `json:"name"`
	Retries int    `json:"retries"`
	Timeout int    `json:"timeout"`
}

// applyDefaults は Name が空文字列、Retries・Timeout が 0 の場合に
// デフォルト値を設定するつもりの関数。
func applyDefaults(c Config) {
	if c.Name == "" {
		c.Name = "default-service"
	}
	if c.Retries == 0 {
		c.Retries = 3
	}
	if c.Timeout == 0 {
		c.Timeout = 30
	}
}

func main() {
	cfg := Config{}
	applyDefaults(cfg)

	fmt.Printf("Name=%q Retries=%d Timeout=%d\n", cfg.Name, cfg.Retries, cfg.Timeout)
}

要件:

1. なぜapplyDefaultsを呼び出してもcfgのフィールドが変わらないのか、構造体の値型としての性質を踏まえて理由を説明してください
2. applyDefaultsを修正し、実際にcfgへデフォルト値が反映されるようにしてください。修正方法は次のどちらか一方（または両方を実装して比較しても構いません）:
   • (A) applyDefaultsがConfigを受け取り、デフォルト値を適用した新しいConfigを返すようにし、呼び出し側でcfg = applyDefaults(cfg)のように再代入する
   • (B) applyDefaultsが*Config（ポインタ）を受け取り、ポインタ経由でフィールドを直接書き換える
3. main関数を修正後の関数シグネチャに合わせて更新し、go run main.goを実行して期待する出力が得られることを確認してください

go run main.go でそのまま実行できる、完全な1つのプログラムとして提出してください。

🔍 ヒント（段階的開示）

📋 コピーpackage main

import "fmt"

type Config struct {
	Name    string `json:"name"`
	Retries int    `json:"retries"`
	Timeout int    `json:"timeout"`
}

// 方法(A): 新しい Config を返す版
func applyDefaults(c Config) Config {
	if c.Name == "" {
		c.Name = "default-service"
	}
	// Retries, Timeout も同様に...
	return c
}

func main() {
	cfg := Config{}
	cfg = applyDefaults(cfg) // 戻り値で再代入する

	fmt.Printf("Name=%q Retries=%d Timeout=%d\n", cfg.Name, cfg.Retries, cfg.Timeout)
}

✅ 模範解答

📋 コピーpackage main

import "fmt"

// Config はサービスの設定を表す構造体。
// json タグは encoding/json でエンコード/デコードする際のキー名を指定する。
type Config struct {
	Name    string `json:"name"`
	Retries int    `json:"retries"`
	Timeout int    `json:"timeout"`
}

// applyDefaults は Name・Retries・Timeout がゼロ値の場合にデフォルト値を
// 適用した「新しい Config」を返す。呼び出し側は戻り値を使って更新する。
func applyDefaults(c Config) Config {
	if c.Name == "" {
		c.Name = "default-service"
	}
	if c.Retries == 0 {
		c.Retries = 3
	}
	if c.Timeout == 0 {
		c.Timeout = 30
	}
	return c
}

// applyDefaultsInPlace はポインタ経由でフィールドを直接書き換える版。
// 比較のために両方の方法を示す。
func applyDefaultsInPlace(c *Config) {
	if c.Name == "" {
		c.Name = "default-service"
	}
	if c.Retries == 0 {
		c.Retries = 3
	}
	if c.Timeout == 0 {
		c.Timeout = 30
	}
}

func main() {
	// 方法(A): 戻り値で再代入する版
	cfg := Config{}
	cfg = applyDefaults(cfg)
	fmt.Printf("(A) Name=%q Retries=%d Timeout=%d\n", cfg.Name, cfg.Retries, cfg.Timeout)

	// 方法(B): ポインタを渡してその場で書き換える版
	cfg2 := Config{}
	applyDefaultsInPlace(&cfg2)
	fmt.Printf("(B) Name=%q Retries=%d Timeout=%d\n", cfg2.Name, cfg2.Retries, cfg2.Timeout)
}

(A) Name="default-service" Retries=3 Timeout=30
(B) Name="default-service" Retries=3 Timeout=30

※ この実行結果は実際に go run main.go で検証済みです（バグありコードが Name="" Retries=0 Timeout=0 を出力することも合わせて確認済みです）。

🪜 Step-by-Step 解説

📋 コピーfunc applyDefaults(c Config) Config {
	// ... c を書き換える ...
	return c
}

cfg = applyDefaults(cfg)

📋 コピーfunc applyDefaultsInPlace(c *Config) {
	c.Name = "default-service" // 実際は (*c).Name の糖衣構文
}

applyDefaultsInPlace(&cfg2)

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

Java/Python/TypeScript経験者は「オブジェクトは常に参照」という前提が染み付いているため、Goの構造体が値型であることを見落として今回のようなバグを踏みやすいポイントです。Goでは「値渡しがデフォルトで安全、共有したければポインタを明示する」という逆の発想に切り替える必要があります。

🏆 実務での使いどころ

• 設定・DTO（Data Transfer Object）の受け渡し: Configのような設定用構造体、APIリクエスト/レスポンスを表す構造体は、値渡しによる「呼び出し元を汚染しない」性質を活かして安全に受け渡しされます
• JSON APIのリクエスト/レスポンス変換: フィールドタグ（json:"name"）は、REST APIのJSONペイロードを構造体にデコードしたり、構造体をJSONにエンコードしたりする際にキー名を制御するために実務で必ず使われます（例: Goのフィールド名は大文字始まりの慣例だが、JSONのキーはキャメルケース/スネークケースにしたい、といった変換）
• 「値を返して更新する」パターン: 今回のapplyDefaultsのように、設定のマージ・デフォルト値の適用・バリデーション後の正規化などは「新しい値を返して呼び出し元が再代入する」スタイルで書かれることが多く、context.WithValueなど標準ライブラリの一部の設計思想とも共通します
• 大きな構造体のポインタ渡し: データベースの行を表す構造体や、多数のフィールドを持つ設定構造体を関数間で頻繁に受け渡しする場合、コピーコストを避けるために*Tで渡すのが一般的です

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: Config構造体にTags []stringのようなスライスフィールドを追加し、applyDefaultsを値渡し版で呼び出した場合に、スライスフィールドへのappendが呼び出し元にどう影響するか（構造体自体は値型でコピーされるが、スライスフィールドの中身の基底配列は共有されたままである点）を実験してみましょう
• 次回予告: Day 009 — メソッドとレシーバ（値レシーバ vs ポインタレシーバ）（概念理解→実装問題）。今回学んだ「値渡し vs ポインタ渡し」の判断基準が、そのままメソッドのレシーバ選択の基準に直結します

🎯 自己評価

自分の回答

気づき・メモ