答え。

Goでは、メソッドは値型（value）およびポインタ型（pointer）で宣言できます。この機能は、データが誰によって変更されるかを明示的に制御するために初期のバージョンから存在しています。古典的な問題は、値のセマンティクス（コピー、変更しない）とポインタ（データへの共有アクセスと変更可能性）との間の距離の必要性です。

問題 — 値受信者でメソッドを宣言して期待した効果が得られないことや、ポインタ変数で値メソッドを呼び出すことによるミスを犯しやすい。

解決策 — 次のルールに従うこと。

オブジェクトの状態を変更する必要がある場合はポインタ受信者を使用する。
小さなイミュータブル構造体には値受信者を使用する。
インターフェースには一貫性のためにポインタ受信者が好ましい。

コード例:

type Counter struct { Value int }

func (c Counter) IncCopy() { c.Value++ }          // 値受信者
func (c *Counter) IncPointer() { c.Value++ }      // ポインタ受信者

c := Counter{}
c.IncCopy()         // Valueは0のまま
c.IncPointer()      // Valueは1になる

重要な特徴:

値受信者はデータのコピーと外部からの変更の不可能性を保証します。
ポインタ受信者は構造体の内部状態を変更することを可能にします。
インターフェースとその実装は受信者の型に依存し、割り当て時の予期しない事態を引き起こす可能性があります。

トリッキーな質問。

ポインタで値受信者メソッドを呼び出すことができますか？また、値でポインタメソッドを呼び出すことができますか？

Goは「裏で」ポインタを自動的にデリファレンスしたり、アドレスを取得したりするため、型が互換性がある場合に呼び出しが許可されます。しかし、すべての場合においてそうではありません—インターフェースでは予測通りに動作しないことがあります。

var c Counter
(&c).IncCopy()  // ポインタを通じて値メソッドを呼び出すことができる
c.IncPointer()  // ポインタメソッドを呼び出すことができ、Goは自動的にアドレスを取得する

構造体がポインタメソッドのみを実装している場合、その値をインターフェースに渡すとどうなりますか？

そのようなオブジェクトはポインタメソッドを要求するため、インターフェースを実装していないため、panicやコンパイルエラーが発生する可能性があります。

type D interface { IncPointer() }
func f(d D) {}
c := Counter{}
f(c)       // エラー！Counterは値としてインターフェースを実装していない
f(&c)      // 正しい

ポインタ受信者のメソッドを呼び出す際にポインタのコピーを渡した場合、構造体は変わりますか？

はい、ポインタがコピーされても、同じオブジェクトがその下にあるため、結果は同じになります。

c := Counter{}
p := &c
p2 := p
p2.IncPointer() // Valueが増加する

典型的なミスとアンチパターン

不適切な受信者を持つメソッドを宣言し、コピーを通じて構造体を変更しようとすること。
大きな構造体に対して値受信者を使用する — 過剰なコピー。
受信者のためのインターフェースの不一致によるエラー。

実生活の例

ネガティブケース

エンジニアが値受信者メソッド「Update」を持つ構造体を実装します。インターフェースを通じて構造体が渡されますが、変更が「失われ」ます — それはコピーで作業しているからです。

利点:

構造体の純粋な不変性。

欠点:

変更が期待されたが、なかった — バグを追跡するのが難しい。

ポジティブケース

チーム内で明示的な合意：状態を変更するメソッドはすべてポインタ受信者であり、インターフェースはポインタでのみ実装され、値は「拡張」やユーティリティのためのものです。