Go의 구성 모델이 여전히 취약한 기본 클래스 문제를 겪을 수 있습니까?

Go의 취약한 기본 클래스 문제: 상속에 대한 구성에도 불구하고

취약한 기본 클래스 문제는 기본 클래스를 변경하면 예상치 못한 오류가 발생할 수 있을 때 발생합니다. 파생 클래스의 동작. 이 문제는 일반적으로 파생 클래스가 기본 클래스의 메서드와 필드를 상속하는 상속으로 인해 발생합니다.

Go에서는 상속이 구현되지 않습니다. 대신 Go는 구조체가 다른 구조체의 인스턴스를 포함할 수 있는 구성을 사용합니다. 그러나 일부에서는 임베디드 유형으로 작업할 때 취약한 기본 클래스 문제가 Go에 여전히 존재할 수 있다고 주장합니다.

임베디드 유형은 임베디드 유형의 필드와 메소드를 래퍼 유형으로 승격시킵니다. 이는 편리한 액세스를 제공하지만 다형성을 제거합니다. 즉, 포함된 유형에 정의된 메서드는 래퍼 유형에서 재정의될 수 없으며 포함된 유형에 의해 수행된 모든 메서드 호출은 항상 원래 정의를 호출합니다.

결과적으로 깨지기 쉬운 기본 클래스 문제가 존재합니다. Go에서는 완화된 형태로 사용됩니다. 포함된 유형의 메서드 또는 필드를 변경하면 래퍼 유형에 영향을 미칠 수 있지만 래퍼 유형이 동일한 이름을 가진 자체 메서드를 정의하지 않는 경우에만 가능합니다.

예

기본 클래스 Counter에 증분 메서드 inc()와 증분별 메서드 incBy()가 포함되어 있는 다음 Java 코드를 생각해 보세요. 파생 클래스 MyCounter는 inc()를 재정의하여 incBy(1)를 호출합니다.

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

기본 클래스의 incBy() 메서드가 루프를 사용하도록 변경되면 파생 클래스 MyCounter는 무한 루프에 들어갑니다. inc()는 inc()를 다시 호출하는 incBy()를 호출하기 때문입니다.

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

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>

Counter 유형의 IncBy() 메서드를 루프를 사용하도록 수정하더라도 MyCounter 유형은 Inc()라는 메서드를 정의하지 않기 때문에 이 동작을 상속하지 않습니다. 대신 Counter 유형에 정의된 원본 inc() 메서드를 호출합니다.

따라서 예상치 못한 동작을 방지하는 임베디드 유형의 다형성이 부족하기 때문에 깨지기 쉬운 기본 클래스 문제는 Go에서 큰 문제가 되지 않습니다. 포함된 유형을 수정할 때.

위 내용은 Go의 구성 모델이 여전히 취약한 기본 클래스 문제를 겪을 수 있습니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!