Kann das Kompositionsmodell von Go immer noch unter dem Problem der fragilen Basisklasse leiden?

Problem mit fragilen Basisklassen in Go: Trotz Komposition über Vererbung

Das Problem mit fragilen Basisklassen entsteht, wenn Änderungen an einer Basisklasse zu unerwarteten Ergebnissen führen können Verhalten in abgeleiteten Klassen. Dieses Problem wird häufig auf die Vererbung zurückgeführt, bei der abgeleitete Klassen die Methoden und Felder ihrer Basisklassen erben.

In Go ist die Vererbung nicht implementiert. Stattdessen verwendet Go Komposition, wobei eine Struktur Instanzen anderer Strukturen enthalten kann. Einige argumentieren jedoch, dass das fragile Basisklassenproblem in Go immer noch bestehen kann, wenn mit eingebetteten Typen gearbeitet wird.

Eingebettete Typen befördern die Felder und Methoden des eingebetteten Typs zum Wrapper-Typ. Dies ermöglicht zwar einen bequemen Zugriff, eliminiert jedoch Polymorphismus. Dies bedeutet, dass im eingebetteten Typ definierte Methoden im Wrapper-Typ nicht überschrieben werden können und alle vom eingebetteten Typ durchgeführten Methodenaufrufe immer die ursprüngliche Definition aufrufen.

Daher liegt das Problem der fragilen Basisklasse vor in Go in abgeschwächter Form. Änderungen an den Methoden oder Feldern des eingebetteten Typs können sich auf den Wrapper-Typ auswirken, jedoch nur, wenn der Wrapper-Typ keine eigenen Methoden mit denselben Namen definiert.

Beispiel

Betrachten Sie den folgenden Java-Code, in dem eine Basisklasse Counter eine Inkrementierungsmethode inc() und eine Inkrementierungsmethode incBy() enthält. Eine abgeleitete Klasse MyCounter überschreibt inc(), um incBy(1) aufzurufen.

<code class="java">class Counter {
    int value;
    void inc() { value++; }
    void incBy(int n) { value += n; }
}

class MyCounter extends Counter {
    @Override
    void inc() { incBy(1); }
}</code>

Wenn die incBy()-Methode in der Basisklasse so geändert wird, dass sie eine Schleife verwendet, tritt die abgeleitete Klasse MyCounter in eine Endlosschleife ein weil inc() incBy() aufruft, das wiederum inc() aufruft:

<code class="java">void incBy(int n) {
    for (; n > 0; n--) { inc(); }
}</code>

In Go weist dasselbe Beispiel dieses Problem nicht auf, da Go keine überschreibenden Methoden in eingebetteten Typen unterstützt:

<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>

Auch wenn die IncBy()-Methode im Counter-Typ so geändert wird, dass sie eine Schleife verwendet, erbt der MyCounter-Typ dieses Verhalten nicht, da er keine Methode namens Inc() definiert. Stattdessen wird die ursprüngliche inc()-Methode aufgerufen, die im Counter-Typ definiert ist.

Daher stellt das fragile Basisklassenproblem in Go aufgrund des fehlenden Polymorphismus in eingebetteten Typen kein großes Problem dar, was unerwartetes Verhalten verhindert beim Ändern eingebetteter Typen.

Das obige ist der detaillierte Inhalt vonKann das Kompositionsmodell von Go immer noch unter dem Problem der fragilen Basisklasse leiden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!