継承よりも合成を採用しているにもかかわらず、それほど深刻ではありませんが、脆弱な基本クラスの問題は依然として Go で発生する可能性があります。 form.
この問題は、基底クラスへの変更によってそのサブクラスが破壊されるときに発生します。仮想メソッドを備えた言語 (Java など) では、基本クラスが変更された場合にサブクラスのメソッドをオーバーライドすると、予期しない動作が発生する可能性があります。
ただし、Go には ポリモーフィズムはありません (オーバーライド可能)方法)。型を埋め込む場合、埋め込まれたメソッドはラッパー構造体に昇格されますが、オーバーライドすることはできません。これにより、プロモートされたメソッドはサブクラスによって変更できないため、基本クラスの脆弱性の問題が軽減されます。
Java の場合:
<code class="java">class Counter { int value; void inc() { value++; } void incBy(int n) { value += n; } } class MyCounter extends Counter { void inc() { incBy(1); } }</code>
If Counter.incBy() を inc() に何度も変更すると、MyCounter は無限ループに陥ります。
Go:
<code class="go">type Counter struct { value int } func (c *Counter) Inc() { c.value++ } func (c *Counter) IncBy(n int) { c.value += n } type MyCounter struct { Counter } func (m *MyCounter) Inc() { m.IncBy(1) }</code>
同じ変更を加えてもJava の例と同様に、Counter.incBy() を呼び出しても、MyCounter は Counter.Inc() を直接呼び出すため、引き続き正しく機能します。基本クラスのメソッドは、サブクラスの変更による影響を受けません。
Go ではポリモーフィズムがないため、基本クラスの脆弱性の問題はあまり一般的ではありませんが、次のことを考慮することが重要です。構造体に型を埋め込むときの基本クラスの変更の潜在的な影響。
以上がGo の構成モデルは脆弱な基本クラスの問題を軽減しますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。