C # 인터페이스. 암시 적 구현과 명시 적 구현

인터페이스를 구현의 차이점은 무엇입니까 암시 적 및 명시 적으로 C #으로는?

언제 암시 적으로 사용해야하고 언제 명시 적으로 사용해야합니까?

하나 또는 다른 것에 대한 장단점이 있습니까?

Microsoft의 공식 지침 (1 판 Framework Design Guidelines ) 은 코드에 예기치 않은 동작을 제공하므로 명시적인 구현 을 사용하지 않는 것이 좋습니다 .

이 가이드 라인은 인터페이스로 물건을 전달하지 않을 때 IoC 시간 이전에 매우 유효 하다고 생각합니다 .

누구도 그 부분을 만질 수 있습니까?

암시 적은 클래스의 멤버를 통해 인터페이스를 정의 할 때입니다. 인터페이스의 클래스 내에서 메소드를 정의 할 때 명시 적 입니다. 혼란스럽게 들리지만 여기에 내가 의미 IList.CopyTo하는 바는 다음과 같이 암시 적으로 구현됩니다.

public void CopyTo(Array array, int index)
{
    throw new NotImplementedException();
}

그리고 명시 적으로 :

void ICollection.CopyTo(Array array, int index)
{
    throw new NotImplementedException();
}

차이점은 암시 적 구현을 ​​통해 인터페이스를 해당 클래스 및 인터페이스 자체로 캐스팅하여 생성 한 클래스를 통해 인터페이스에 액세스 할 수 있다는 것입니다. 명시 적 구현을 ​​통해 인터페이스 자체로 인터페이스를 캐스팅하여 인터페이스에 액세스 할 수 있습니다.

MyClass myClass = new MyClass(); // Declared as concrete class
myclass.CopyTo //invalid with explicit
((IList)myClass).CopyTo //valid with explicit.

나는 구현을 깨끗하게 유지하거나 두 가지 구현이 필요할 때 명시 적으로 사용합니다. 어쨌든 나는 거의 사용하지 않습니다.

다른 사람들이 게시 할 명시 적 사용 / 사용하지 않는 더 많은 이유가 있다고 확신합니다.

이 글 의 다음 글 에서 각각의 훌륭한 추론을 확인하십시오.

암시 적 정의는 인터페이스에서 요구하는 메소드 / 속성 등을 클래스에 직접 공개 메소드로 추가하는 것입니다.

명시 적 정의는 기본 구현이 아닌 인터페이스를 직접 사용하여 작업 할 때만 멤버가 노출되도록합니다. 대부분의 경우에 선호됩니다.

1. 인터페이스를 직접 사용함으로써 코드를 인식하고 기본 구현에 연결하지 않아도됩니다.
2. 코드에 public 속성 Name이 이미 있고 Name 속성도있는 인터페이스를 구현하려는 경우 명시 적으로 수행하면 두 속성이 별도로 유지됩니다. 동일한 작업을 수행하더라도 Name 속성에 명시 적 호출을 위임합니다. 당신은 결코 알지 못합니다, 당신은 Name이 일반 클래스에서 작동하는 방식과 인터페이스 속성 인 Name이 나중에 작동하는 방식을 변경하고 싶을 것입니다.
3. 인터페이스를 암시 적으로 구현하면 클래스는 이제 인터페이스의 클라이언트에만 관련 될 수있는 새로운 동작을 노출하며 클래스를 간결하게 유지하지 않습니다 (내 의견).

이미 제공된 훌륭한 답변 외에도 컴파일러가 필요한 것을 알아낼 수 있도록 명시 적 구현이 필요한 경우가 있습니다. IEnumerable<T>상당히 자주 나타날 수있는 주요 예를 살펴보십시오 .

예를 들면 다음과 같습니다.

public abstract class StringList : IEnumerable<string>
{
    private string[] _list = new string[] {"foo", "bar", "baz"};

    // ...

    #region IEnumerable<string> Members
    public IEnumerator<string> GetEnumerator()
    {
        foreach (string s in _list)
        { yield return s; }
    }
    #endregion

    #region IEnumerable Members
    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.GetEnumerator();
    }
    #endregion
}

여기에 IEnumerable<string>구현 IEnumerable하므로 우리도 필요합니다. 그러나 일반 버전과 일반 버전 모두 동일한 메소드 서명으로 함수를 구현합니다 (C #은 이에 대한 반환 유형을 무시합니다). 이것은 완전히 합법적이고 괜찮습니다. 컴파일러는 어떤 것을 사용해야합니까? 최대 하나의 암시 적 정의 만 갖도록 강요하면 필요한 모든 것을 해결할 수 있습니다.

즉.

StringList sl = new StringList();

// uses the implicit definition.
IEnumerator<string> enumerableString = sl.GetEnumerator();
// same as above, only a little more explicit.
IEnumerator<string> enumerableString2 = ((IEnumerable<string>)sl).GetEnumerator();
// returns the same as above, but via the explicit definition
IEnumerator enumerableStuff = ((IEnumerable)sl).GetEnumerator();

추신 : IEnumerable에 대한 명시 적 정의의 간접적 인 작은 부분은 함수 내에서 변수의 실제 유형이 StringList임을 알고 컴파일러가 함수 호출을 해결하는 방법을 알고 있기 때문에 작동합니다. 일부 추상화 계층을 구현할 수있는 멋진 사실은 일부 .NET 코어 인터페이스가 누적 된 것 같습니다.

C #을 통해 CLR에서 제프리 리히터의 말을 인용
( 에이미는 의미 E xplicit I nterface M은 ethod I의 mplementation)

EIMI를 사용할 때 존재하는 일부 파급 효과를 이해하는 것이 매우 중요합니다. 이러한 파급 효과로 인해 EIMI를 최대한 피해야합니다. 다행히 일반 인터페이스를 사용하면 EIMI를 상당히 피할 수 있습니다. 그러나 이름과 서명이 같은 두 가지 인터페이스 메소드를 구현하는 등의 방법을 사용해야 할 때가 있습니다. EIMI의 큰 문제는 다음과 같습니다.

• 형식이 EIMI 메서드를 구체적으로 구현하는 방법을 설명하는 설명서는 없으며 Microsoft Visual Studio IntelliSense 지원 은 없습니다 .
• 인터페이스로 캐스트 할 때 값 유형 인스턴스가 상자로 표시됩니다.
• EIMI는 파생 형식으로 호출 할 수 없습니다.

인터페이스 참조를 사용하는 경우 파생 클래스에서 모든 가상 체인을 EIMI로 명시 적으로 대체 할 수 있으며 해당 유형의 오브젝트가 인터페이스로 캐스트 될 때 가상 체인이 무시되고 명시 적 구현이 호출됩니다. 그것은 다형성 이외의 것입니다.

EIMI를 사용하면 IEnumerable <T>와 같은 기본 Framework Interfaces 구현에서 강하게 형식화되지 않은 인터페이스 멤버를 숨길 수 있으므로 클래스가 강하게 형식화되지 않은 메서드를 직접 노출시키지 않지만 구문은 정확합니다.

이유 # 1

나는 "구현 프로그래밍"( 디자인 패턴의 디자인 원칙) 을 피하고 싶을 때 명시적인 인터페이스 구현을 사용하는 경향이있다 .

예를 들어 MVP 기반 웹 응용 프로그램에서 :

public interface INavigator {
    void Redirect(string url);
}

public sealed class StandardNavigator : INavigator {
    void INavigator.Redirect(string url) {
        Response.Redirect(url);
    }
}

이제 다른 클래스 (예 : 발표자 )는 StandardNavigator 구현에 의존 할 가능성이 적고 INavigator 인터페이스에 의존 할 가능성이 더 높습니다 (구현은 Redirect 메소드를 사용하기 위해 인터페이스로 캐스트되어야하기 때문에).

이유 # 2

명시적인 인터페이스 구현으로 갈 수있는 또 다른 이유는 클래스의 "기본"인터페이스를 더 깨끗하게 유지하는 것입니다. 예를 들어 ASP.NET 서버 컨트롤 을 개발하는 경우 두 가지 인터페이스가 필요할 수 있습니다.

1. 웹 페이지 개발자가 사용하는 클래스의 기본 인터페이스. 과
2. 컨트롤의 논리를 처리하기 위해 개발 한 발표자가 사용하는 "숨겨진"인터페이스

간단한 예는 다음과 같습니다. 고객을 나열하는 콤보 상자 컨트롤입니다. 이 예제에서 웹 페이지 개발자는 목록을 채우는 데 관심이 없습니다. 대신 GUID로 고객을 선택하거나 선택한 고객의 GUID를 얻을 수 있기를 원합니다. 발표자는 첫 페이지로드시 상자를 채우고이 발표자는 컨트롤에 의해 캡슐화됩니다.

public sealed class CustomerComboBox : ComboBox, ICustomerComboBox {
    private readonly CustomerComboBoxPresenter presenter;

    public CustomerComboBox() {
        presenter = new CustomerComboBoxPresenter(this);
    }

    protected override void OnLoad() {
        if (!Page.IsPostBack) presenter.HandleFirstLoad();
    }

    // Primary interface used by web page developers
    public Guid ClientId {
        get { return new Guid(SelectedItem.Value); }
        set { SelectedItem.Value = value.ToString(); }
    }

    // "Hidden" interface used by presenter
    IEnumerable<CustomerDto> ICustomerComboBox.DataSource { set; }
}

발표자는 데이터 소스를 채우고 웹 페이지 개발자는 그 존재를 알 필요가 없습니다.

그러나 그것은 은색 캐논볼이 아닙니다

항상 명시 적 인터페이스 구현을 사용하는 것은 좋지 않습니다. 이것들은 도움이 될만한 두 가지 예입니다.

이미 언급 한 다른 이유와 더불어, 이것은 클래스가 이름과 서명이 같은 속성 / 메소드를 갖는 두 개의 다른 인터페이스를 구현하는 상황입니다.

/// <summary>
/// This is a Book
/// </summary>
interface IBook
{
    string Title { get; }
    string ISBN { get; }
}

/// <summary>
/// This is a Person
/// </summary>
interface IPerson
{
    string Title { get; }
    string Forename { get; }
    string Surname { get; }
}

/// <summary>
/// This is some freaky book-person.
/// </summary>
class Class1 : IBook, IPerson
{
    /// <summary>
    /// This method is shared by both Book and Person
    /// </summary>
    public string Title
    {
        get
        {
            string personTitle = "Mr";
            string bookTitle = "The Hitchhikers Guide to the Galaxy";

            // What do we do here?
            return null;
        }
    }

    #region IPerson Members

    public string Forename
    {
        get { return "Lee"; }
    }

    public string Surname
    {
        get { return "Oades"; }
    }

    #endregion

    #region IBook Members

    public string ISBN
    {
        get { return "1-904048-46-3"; }
    }

    #endregion
}

이 코드는 컴파일되고 확인되지만 Title 속성은 공유됩니다.

분명히 우리는 Title1의 가치가 우리가 Class1을 책으로 취급하는지 아니면 사람으로 취급하는지에 따라 달라지기를 원합니다. 이때 명시 적 인터페이스를 사용할 수 있습니다.

string IBook.Title
{
    get
    {
        return "The Hitchhikers Guide to the Galaxy";
    }
}

string IPerson.Title
{
    get
    {
        return "Mr";
    }
}

public string Title
{
    get { return "Still shared"; }
}

명시 적 인터페이스 정의는 공용 인 것으로 추론되므로 명시 적으로 공용 (또는 기타)으로 선언 할 수 없습니다.

"공유"버전 (위에서 볼 수 있음)을 계속 사용할 수 있지만 가능하지만 이러한 속성의 존재 여부에 의문이 있습니다. 아마도 Title의 기본 구현으로 사용될 수 있으므로 Class1을 IBook 또는 IPerson으로 캐스트하기 위해 기존 코드를 수정할 필요가 없습니다.

"공유"(암시 적) 제목을 정의하지 않으면 Class1의 소비자는 먼저 Class1의 인스턴스를 IBook 또는 IPerson으로 명시 적으로 캐스팅 해야합니다. 그렇지 않으면 코드가 컴파일되지 않습니다.

대부분 명시적인 인터페이스 구현을 사용합니다. 주요 이유는 다음과 같습니다.

리팩토링이 더 안전합니다

인터페이스를 변경할 때 컴파일러가 확인할 수있는 것이 좋습니다. 암시 적 구현에서는 더 어렵습니다.

두 가지 일반적인 경우가 생각납니다.

• 구현이 인터페이스가 이미 발생한다는 기존 클래스는 새와 같은 서명하는 방법이 할 수있는 인터페이스에 기능을 추가 . 이로 인해 예기치 않은 동작이 발생할 수 있으며 여러 번 어려움을 겪었습니다. 해당 기능이 파일의 다른 인터페이스 메소드와 함께 위치하지 않을 가능성이 있기 때문에 디버깅 할 때 "보기"가 어렵습니다 (아래에 언급 된 자체 문서화 문제).

• 인터페이스에서 기능 제거 . 암시 적으로 구현 된 메소드는 갑자기 죽은 코드이지만, 명시 적으로 구현 된 메소드는 컴파일 오류에 의해 포착됩니다. 데드 코드를 유지하는 것이 좋더라도 코드를 검토하고 홍보해야합니다.

불행히도 C #에는 메소드를 암시 적 구현으로 표시하도록하는 키워드가 없으므로 컴파일러가 추가 검사를 수행 할 수 있습니다. 가상 메소드에는 '재정의'및 '신규'의 필수 사용으로 인해 위의 문제점 중 하나가 없습니다.

참고 : 고정되거나 거의 변경되지 않는 인터페이스 (일반적으로 공급 업체 API에서 제공)의 경우 이는 문제가되지 않습니다. 그러나 내 인터페이스의 경우 언제 어떻게 변경되는지 예측할 수 없습니다.

자체 문서화

클래스에 'public bool Execute ()'가 표시되면 인터페이스의 일부라는 것을 알아 내기 위해 추가 작업이 필요합니다. 누군가는 "ITask의 구현"이라는 영역 또는 그룹화 주석 아래에이를 언급하거나 다른 인터페이스 구현 그룹에 배치해야 할 것입니다. 물론 그룹 헤더가 화면에 표시되지 않은 경우에만 작동합니다.

반면 : 'bool ITask.Execute ()'는 명확하고 모호하지 않습니다.

인터페이스 구현의 명확한 분리

인터페이스는 콘크리트 유형의 표면적을 약간 노출 시키도록 만들어 졌기 때문에 공용 메소드보다 '공개'인 인터페이스라고 생각합니다. 그것들은 유형을 능력, 행동, 특성 집합 등으로 줄입니다. 그리고 구현에서, 나는이 분리를 유지하는 것이 유용하다고 생각합니다.

클래스의 코드를 살펴보면 명시 적 인터페이스 구현을 접할 때 두뇌가 "코드 계약"모드로 전환됩니다. 종종 이러한 구현은 단순히 다른 방법으로 전달되지만 때로는 추가 상태 / 매개 변수 확인, 내부 요구 사항에 더 잘 맞도록 들어오는 매개 변수 변환 또는 버전 화 목적을위한 변환 (예 : 공통 구현에 대한 여러 세대의 인터페이스)을 수행하기도합니다.

(공개도 코드 계약이지만 인터페이스가 훨씬 강력합니다. 특히 구체적인 유형을 직접 사용하는 것이 일반적으로 내부 전용 코드의 표시 인 인터페이스 기반 코드베이스에서 더 강력합니다.)

관련 : 이유 2 존 이상 .

등등

또한 다른 답변에서 이미 언급 한 장점은 다음과 같습니다.

• 에 따라, 필요한 경우 모호성 은 OR 필요 내부 인터페이스
• "구현을 프로그래밍하는"것을 권장하지 않음 ( Jon의 1 이유 )

문제

그것은 모두 재미와 행복이 아닙니다. 암시 적을 고수하는 경우가 있습니다.

• 값 유형은 권투와 낮은 성능을 요구하기 때문입니다. 이것은 엄격한 규칙이 아니며 인터페이스와 사용 방법에 따라 다릅니다. 비교할 수 있습니까? 절대적인. 포맷 가능? 아마 명백하다.
• IDisposable.Dispose와 같이 자주 직접 호출되는 메서드가있는 간단한 시스템 인터페이스

또한 실제로 구체적인 유형을 가지고 있고 명시 적 인터페이스 메소드를 호출하려고 할 때 캐스팅을 수행하는 것이 어려울 수 있습니다. 나는 이것을 두 가지 방법 중 하나로 처리합니다.

1. 공개를 추가하고 구현을 위해 인터페이스 메소드를 전달하십시오. 내부적으로 작업 할 때 일반적으로 더 단순한 인터페이스에서 발생합니다.
2. (내 선호하는 방법) public IMyInterface I { get { return this; } }(인라인되어야 함 )을 추가 하고을 호출하십시오 foo.I.InterfaceMethod(). 이 기능이 필요한 인터페이스가 여러 개인 경우 이름을 I 이상으로 확장하십시오 (제 경험상이 기능이 필요한 경우는 거의 없습니다).

명시 적으로 구현하면 인터페이스 유형의 참조를 통해서만 인터페이스 멤버를 참조 할 수 있습니다. 구현 클래스의 유형 인 참조는 해당 인터페이스 멤버를 노출하지 않습니다.

구현 클래스가 클래스를 생성하는 데 사용 된 메소드 (공장 또는 IoC 컨테이너 일 수 있음 )를 제외하고 인터페이스 메소드를 제외하고는 물론 공개 클래스가 아닌 경우 명시 적으로 구현하면 이점이 없습니다. 인터페이스.

그렇지 않으면 인터페이스를 명시 적으로 구현하면 구체적인 구현 클래스에 대한 참조가 사용되지 않으므로 나중에 해당 구현을 변경할 수 있습니다. "확실히"는 "장점"이라고 생각합니다. 잘 구현 된 구현은 명시적인 구현 없이도이를 달성 할 수 있습니다.

내 의견으로는 단점은 비공개 멤버에 액세스 할 수있는 구현 코드의 인터페이스에서 유형을 캐스팅 할 수 있다는 것입니다.

많은 것들과 마찬가지로, 장점은 단점입니다 (그 반대도 마찬가지). 인터페이스를 명시 적으로 구현하면 구체적인 클래스 구현 코드가 노출되지 않습니다.

암시 적 인터페이스 구현은 인터페이스의 서명이 동일한 메소드가있는 곳입니다.

명시 적 인터페이스 구현은 메소드가 속한 인터페이스를 명시 적으로 선언하는 곳입니다.

interface I1
{
    void implicitExample();
}

interface I2
{
    void explicitExample();
}


class C : I1, I2
{
    void implicitExample()
    {
        Console.WriteLine("I1.implicitExample()");
    }


    void I2.explicitExample()
    {
        Console.WriteLine("I2.explicitExample()");
    }
}

MSDN : 암시 적 및 명시 적 인터페이스 구현

인터페이스를 구현하는 모든 클래스 멤버는 VB.NET 인터페이스 선언이 작성되는 방식과 의미 상 유사한 선언을 내 보냅니다.

Public Overridable Function Foo() As Integer Implements IFoo.Foo

반원의 이름은 종종 인터페이스 회원의 이름과 일치하지만 반원은 종종 공개적이지만, 그 둘 중 어느 것도 필요하지 않습니다. 다음과 같이 선언 할 수도 있습니다.

Protected Overridable Function IFoo_Foo() As Integer Implements IFoo.Foo

이 경우 클래스와 그 파생어는 이름을 사용하여 클래스 멤버에 액세스 할 수 IFoo_Foo있지만 외부 세계는 캐스트를 통해서만 해당 특정 멤버에 액세스 할 수 있습니다 IFoo. 이러한 접근 방식은 인터페이스 메소드가 모든 구현에서 특정 동작을 지정 하지만 일부에 대해서만 유용한 동작 (예 : 읽기 전용 콜렉션의 IList<T>.Add메소드에 대해 지정된 동작이 발생하는 경우)에서 유용합니다NotSupportedException . 불행히도 C #에서 인터페이스를 구현하는 유일한 방법은 다음과 같습니다.

int IFoo.Foo() { return IFoo_Foo(); }
protected virtual int IFoo_Foo() { ... real code goes here ... }

좋지 않다.

명시 적 인터페이스 구현의 중요한 용도 중 하나는 가시성 이 혼합 된 인터페이스를 구현해야하는 경우입니다 .

문제와 해결책은 C # 내부 인터페이스 기사에 잘 설명되어 있습니다.

예를 들어 응용 프로그램 계층간에 개체의 누수를 보호하려는 경우이 기술을 사용하면 누수를 일으킬 수있는 멤버의 다른 가시성을 지정할 수 있습니다.

위의 답변은 C #으로 명시 적으로 인터페이스를 구현하는 것이 바람직한 이유를 설명합니다 (주로 공식적인 이유로). 그러나 명시적인 구현이 필수 인 상황이 하나 있습니다. 인터페이스가 아닌 경우 캡슐화의 누출을 피하기 위해 public구현 클래스는 public입니다.

// Given:
internal interface I { void M(); }

// Then explicit implementation correctly observes encapsulation of I:
// Both ((I)CExplicit).M and CExplicit.M are accessible only internally.
public class CExplicit: I { void I.M() { } }

// However, implicit implementation breaks encapsulation of I, because
// ((I)CImplicit).M is only accessible internally, while CImplicit.M is accessible publicly.
public class CImplicit: I { public void M() { } }

C # 사양에 따르면 "모든 인터페이스 멤버가 암시 적으로 공개 액세스 권한을 갖기 때문에"위의 누수는 피할 수 없습니다 . 결과적으로, public인터페이스 자체가 예를 들어서도 암시 적 구현은 액세스 를 제공해야합니다 internal.

C #에서 암시 적 인터페이스 구현은 매우 편리합니다. 실제로, 많은 프로그래머들은 더 이상 고려하지 않고 언제 어디서나 사용합니다 . 이로 인해 가장 지저분한 유형의 표면이 만들어지고 최악의 경우 누출 된 캡슐이 생깁니다. F #과 같은 다른 언어 에서도 허용되지 않습니다 .