Go의 임베딩 접근 방식은 취약한 기본 클래스 문제를 제거합니까?

Go의 취약한 기본 클래스 문제: 미묘한 차이

설계 원칙으로 상속보다 구성을 수용함에도 불구하고 다음 질문이 남아 있습니다. 취약한 기본 클래스 문제가 Go에 존재합니까?

취약한 기본 클래스 문제 정의

취약한 기본 클래스 문제는 기본 클래스의 변경이 Go의 파생 클래스에 영향을 미칠 때 발생합니다. 의도하지 않은 방식. 이는 파생 클래스의 메서드가 기본 클래스의 메서드를 재정의할 수 있는 다형성으로 인해 발생합니다. 그런 다음 기본 클래스 메서드를 수정하면 파생 클래스의 동작이 의도치 않게 중단될 수 있습니다.

문제에 대한 Go의 관점

Go에서는 다형성이 없습니다. 가상 메소드가 부족하기 때문입니다. 대신 Go는 구조체가 다른 구조체를 포함하고 해당 메서드에 직접 액세스할 수 있는 임베딩을 활용합니다. 이 접근 방식은 취약한 기본 클래스 문제의 직접적인 영향을 제거하지만 미묘한 뉘앙스를 도입합니다.

임베딩 및 메서드 승격

구조체가 임베디드되면 모든 메소드는 둘러싸는 구조체로 승격됩니다. 그러나 이러한 메서드는 바깥쪽 구조체에서 재정의될 수 없습니다. 대신, 동일한 이름을 가진 새 메서드를 추가할 수 있지만 포함된 구조체 내에서 승격된 메서드를 호출하면 여전히 원래 정의가 호출됩니다.

컨텍스트의 예

취약한 기본 클래스 문제를 보여주는 다음 Java 예제를 고려해 보겠습니다.

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

여기서 Counter.incBy()를 수정하여 inc()를 반복하고 호출하면 MyCounter.inc()가 중단되어 오류가 발생합니다. 무한 루프.

그러나 Go에서는 유사한 예가 다형성이 부족하여 이러한 중단을 초래하지 않습니다. 포함된 Counter 메서드는 재정의될 수 없으므로 호출 컨텍스트에 관계없이 원래 Counter.Inc() 메서드가 항상 호출됩니다.

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

이 경우 Counter.IncBy()를 수정해도 영향을 미치지 않습니다. 카운터를 계속 1씩 증가시키는 MyCounter.Inc().

결론

Go는 가상 메소드가 없기 때문에 취약한 기본 클래스 문제를 완화합니다. , 완전히 제거되지는 않습니다. 임베딩 중 방법을 홍보하면 미묘한 형태의 문제가 발생합니다. 그러나 이 미묘한 차이는 기존의 취약한 기본 클래스 문제에 비해 덜 혼란스럽고 예측 가능성이 더 높습니다.

위 내용은 Go의 임베딩 접근 방식은 취약한 기본 클래스 문제를 제거합니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!