Go는 "암시 적"인터페이스를 사용하여 생산성을 어떻게 향상 시키며 C #의 확장 방법 개념과 비교하면 어떻습니까?

Go Language Tutorial에서 인터페이스 작동 방식 을 설명 합니다.

바둑에는 수업이 없습니다. 그러나 구조체 유형에 대한 메서드를 정의 할 수 있습니다. 방법 수신기는 FUNC 키워드와 메소드 이름과 자신의 인수 목록에 나타납니다.

type Vertex struct {
    X, Y float64
}

func (v *Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

인터페이스 유형은 일련의 메소드로 정의됩니다. 인터페이스 유형의 값은 해당 메소드를 구현하는 모든 값을 보유 할 수 있습니다.

Go에서 인터페이스를 만드는 유일한 방법입니다. 구글은 다음과 같이 설명한다 :

유형은 메소드를 구현하여 인터페이스를 구현합니다. 의도에 대한 명시적인 선언은 없습니다 (예 : interface선언).

암시 적 인터페이스는 인터페이스를 정의하는 패키지에서 구현 패키지를 분리합니다. 둘 다 다른 것에 의존하지 않습니다.

또한 모든 구현을 찾아서 새 인터페이스 이름으로 태그를 지정할 필요가 없기 때문에 정확한 인터페이스의 정의를 권장합니다.

Go의 메소드가 무자비한 다형성이라는 점을 제외하면 C #의 확장 메소드 와 비슷하게 들립니다 . 그것들 을 구현하는 모든 유형에서 작동 합니다.

구글은 이것이 빠른 개발을 장려한다고 주장하지만 왜 그런가? C #의 명시 적 인터페이스에서 벗어나 무언가를 포기합니까? C #의 확장 메서드를 사용하면 Go 인터페이스가 C #의 이점을 얻을 수 있습니까?

확장 메서드와 암시 적 인터페이스가 전혀 동일하지 않습니다.

먼저 목적에 대해 이야기합시다.

확장 방법은 구문 설탕으로 존재하므로 해당 객체의 내부에 액세스 할 필요없이 객체의 멤버 인 것처럼 메서드를 사용할 수 있습니다. 확장 메소드가 없으면 정확히 같은 일을 할 수 있습니다. 유쾌한 구문을 얻지 못하고 someObjectYouCantChange.YourMethod()대신 호출해야합니다 YourMethod(someObjectYouCantChange).

그러나 암시 적 인터페이스의 목적은 변경 권한이없는 객체에서 인터페이스를 구현할 수 있도록하는 것입니다. 이를 통해 자신이 작성하는 객체와 내부에 액세스 할 수없는 객체간에 다형성 관계를 만들 수 있습니다.

이제 결과에 대해 이야기합시다.

확장 방법에는 실제로 아무것도 없습니다. .NET은 모델에 대한 고유 한 관점 (내부, 외부, 상속자 및 이웃의 관점)을 돕기 위해 사용하는 무자비한 보안 제약 조건과 완벽하게 일치합니다. 결과는 단지 약간의 구문 적 즐거움이다.

암시 적 인터페이스의 결과는 몇 가지입니다.

• 실수로 인터페이스를 구현 한 경우, 이는 계약의 의도를 존중하지 않으면 서 의도하지 않은 다른 사람의 인터페이스를 만나서 우발적 인 사고 또는 LSP 위반 일 수 있습니다.
• 객체 인터페이스를 단순히 미러링하여 (또는 해당 메소드 요구 사항을 충족하는 인터페이스를 만드는 것만으로) 모든 메소드를 지정된 객체의 모의를 쉽게 받아 들일 수있는 기능.
• 내부에 방해 할 수없는 물체와 관련하여 더 쉽게 어댑터 또는 기타 다양한 패턴을 만들 수있는 기능.
• 인터페이스 구현을 지연시키고 실제 구현을 건드리지 않고 나중에 구현할 수 있으며 실제로는 다른 구현자를 생성하려는 경우에만 구현할 수 있습니다.