2009-10-25 5 views
4

C#에서 필요한 인터페이스는 무엇입니까? 인터페이스에 추상 메소드를 작성하고 있기 때문입니다. 대신 우리는 클래스에있는 메소드를 직접 구현할 수 있습니다.C의 인터페이스 필요 #

+2

죄송합니다. 정확히 무엇을 묻고 있습니까? 인터페이스 사용 방법 – GenericTypeTea

+1

인터페이스의 필요성은 무엇입니까? 당신은 직접 클래스 –

+1

에 메서드를 작성할 수 있습니다. 인터페이스는 추상 클래스와 같은 파생 클래스의 필수 기본 역할을 할 수 있지만 파생 클래스가 _ 인터페이스 _ 인터페이스를 구현할 수 있다는 점에서보다 일반적입니다. – RedGlyph

답변

2

polymorphism에서 읽을 수 있습니다.

+1

위키 백과? ;-) 어쩌면이 링크가 도움이 될 수도 있습니다 (그리고 좀 더 구체적으로) : http://msdn.microsoft.com/en-us/library/ms173156.aspx – RedGlyph

7

인터페이스는 구현을 지원하지 않으므로 추상 클래스처럼 기본 구현을 제공 할 수 없습니다. 또한 인터페이스는 계층 구조에만 국한되지 않으므로 추상 클래스보다 유연합니다.

+1

+1. 누군가 * 마침내 지적 * : 인터페이스는 계층 구조에 국한되지 않습니다 * –

4

이 필요하지 않습니다. C#에서 인터페이스를 사용하십시오. 그들은 일부 상황에서 유용하지만 적절하지만 모두 상황에 적합하지 않습니다. 내가 사용하는 편리한 규칙은 프로젝트에서 인터페이스를 구현하는 클래스가 하나 뿐인 경우 해당 인터페이스가 필요 없다는 것입니다.

참고 :이 규칙에 대한 한 가지 가능한 방법은 향후 인터페이스를 사용할 수있는 두 번째 구현 클래스를 작성해야 할 수도 있다는 것입니다. 프로그래밍에 상당한 시간이 낭비되는 것은 결코 실현되지 않는 미래의 시나리오를 예상한다고 생각하기 때문에 필자는 반드시 동의하지 않습니다.

+3

단위 테스트는 어떻게됩니까? 테스트를 위해 스텁이나 모의 객체로 두 번째 구현을 생성하기 때문에 일반적으로 인터페이스를 사용합니다. 어림짐작을하면 항상 인터페이스를 사용해야합니다. –

+2

하지만 단위 테스트를 작성할 때 다른 클래스의 종속성이있는 경우 클래스를 조롱하거나 스텁해야합니다. 이렇게하면 테스트 프로젝트에 인터페이스의 두 번째 구현이 자동으로 생성됩니다. 이 때문에 테스트 할 수있는 분리 된 코드를 작성하기 위해 클래스보다 인터페이스를 더 자주 생성하는 것으로 나타났습니다. –

+3

@DotNetWill and Brian Genisio : 당신이 쓴 것이 어떻게 든 내 대답에 쓴 것과는 어떤 관계가 있는지 보지 못합니다. 단위 테스트를 위해 클래스 모의/스텁을 선택하면 인터페이스를 구현하는 클래스가 두 개 이상 있으므로 인터페이스를 사용해야합니다. 유닛 테스트를 위해 클래스를 조롱하거나 스텁하지 않고 프로젝트에 해당 클래스의 구현이 하나만있는 경우 인터페이스가 필요하지 않습니다. 나는 당신의 코멘트에 뭔가를 놓치고 있습니까? 모든 프로젝트 *의 모든 클래스 *는 인터페이스를 구현해야한다고 말하고 있습니까? 그것은 지나치게 강한 주장으로 보인다. – MusiGenesis

1

나 자신을 위해, 비슷한 객체를 가지고 있지만 같은 메소드의 구현이 완전히 다른 경우 많은 인터페이스를 사용합니다.

또한 여러 인터페이스를 구현할 수 있지만 하나의 추상 클래스 만 상속합니다. 내 비즈니스 객체가 더 나은 표현을하기 때문에이 방법이 매우 유용하다고 생각합니다.

비즈니스 로직을 프리젠 테이션과 분리하는 N 계층 응용 프로그램을 작성할 때 인터페이스에 대한 많은 용도가 시작될 것이라고 생각합니다.

0

인터페이스를 계약으로 생각하십시오.

클래스가 따라야하는 계약을 만듭니다. 예를 들어 Dog 객체가 Walk 메서드를 가져야하는 경우 클래스 을 정의하고이 메서드를 구현해야합니다.

모든 개 클래스 (상속 또는 비공유)가이 메소드를 구현하도록하려면 해당 메소드를 지정하는 인터페이스를 지정해야합니다.

인터페이스는 특정 클래스가 엄격한 구현 규칙을 따르도록 강제하는 구성입니다.

이유는 기본적으로 Walk 메서드가있는 Dog 개체 (상속되거나 포함되지 않음)로 끝나기 때문입니다. 즉, 이러한 객체를 매개 변수로 전달할 수 있다는 것을 의미합니다. Dog 클래스에서 Walk 클래스를 상속 받았는지 여부에 관계없이 안전하게 호출 할 수 있다는 점에서 안전합니다.

+0

@Gary하지만 추상적 인 수업도 계약입니다. –

+0

사실,하지만 그건 내 대답에 영향을 미치지 않습니다. –

1

구성 요소 간의 계약을 정의하기 위해 서적에 설명 된 것과 똑같은 인터페이스가 필요합니다. 캡슐화를 유지하면서 특정 기능을 다른 모듈에 노출시키는 가장 좋은 방법 중 하나입니다. 예를 들어

:

1) 조립 'A'로 표시 실제 구현 조립 'B'로, 조립체 'A'에 구현 된 기능의 일부 부분을 노출시키기 위해, 계면없이 시도.

2) 우리가 고려한다면 더욱 악화됩니다.NET Remoting 시나리오에서 서버가 특정 기능을 클라이언트에 노출해야하며 서버 측에서 기능이 구현되고 호스팅되어야합니다. 이 경우 어셈블리는 서버 호스트 클래스의 인터페이스가 정의 된 클라이언트에 게시됩니다.

0

테스트 가능한 코드를 작성하려면 일반적으로 인터페이스를 사용해야합니다. 단위 테스트를 할 때, ClassC에 의존하는 ClassB에 의존하는 ClassA를 가질 수 있지만 ClassA 만 테스트하려고합니다. ClassA를 인스턴스화하기 위해 ClassB에 전달할 ClassC를 만들고 싶지는 않습니다.

그런 경우 ClassA를 IClassB (또는 좀 더 일반적인 이름, 대부분 ClassB 구현에 대해 암시하지 않음)에 의존하게하고 테스트에서 IClassB를 조롱합니다.

그것은 나를위한 의존성 관리에 관한 것입니다.

0

이질적인 클래스 집합을 모두 같은 유형의 개체라고 생각할 때 인터페이스가 필요합니다. 예를 들어, 모든 구성을 파일에서 읽는 클래스 세트가 있다고 가정 해보십시오. 이를 처리하는 한 가지 방법은 모든 클래스가 파일에서 구성을 읽는 적절한 메소드를 구현하도록하는 것입니다. 이 문제는 그 클래스를 사용하고이를 구성하고자하는 모든 코드가 다른 클래스를 알 필요가 있으므로 클래스의 메소드를 사용할 수 있어야합니다.

또 다른 방법은 모두 단일 기본 클래스에서 파생되도록하는 것입니다. 그런 식으로 클래스를 사용하는 모든 코드는 기본 클래스에 대해서만 알고 있어야합니다. 즉, 파생 클래스를 기본 클래스로 처리하고 기본 클래스에 정의 된 메서드를 사용하여 구성을 수행 할 수 있습니다. 이것은 그렇게 나쁘지는 않지만 커다란 단점이 있습니다. C#은 상속 체인을 제한하는 다중 상속을 지원하지 않기 때문입니다. 클래스의 일부에 대해 동일한 종류의 능력을 갖기를 원하지만 다른 행동에 대해 모든 클래스의 능력을 갖기를 원하지 않는다면 어쨌든 모든 클래스에 대해이를 구현하지 않을 것입니다. 안좋다.

마지막 방법은 인터페이스를 사용하여 동작을 정의하는 것입니다. 비헤이비어를 구현하려는 모든 클래스는 인터페이스 만 구현하면됩니다. 비헤이비어를 사용하려는 모든 클래스는 인터페이스에 대해서만 알고 있어야하며 인터페이스를 구현하는 모든 클래스를 사용할 수 있습니다. 클래스는 인터페이스 또는 심지어 여러 인터페이스를 구현할 수 있으므로 클래스간에 동작을 세부적으로 할당 할 수 있습니다. 여전히 기본 클래스와 상속 계층 구조를 사용하여 클래스의 기본 동작을 공유 방식으로 제공 할 수 있지만 클래스는 자유롭게 다른 인터페이스를 구현하여 더 많은 동작을 제공하고이를 사용하는 클래스의 편의성 만 유지할 수 있습니다 인터페이스에 대해.

0

인터페이스를 통해 구현자가 고유 기본 클래스를 사용할 수 있습니다. 추상 클래스를 사용하면 구현자가 프로젝트 별 기본 클래스를 사용하는 것이 더 합리적이라 할지라도 구현자는 지정된 기본 클래스를 사용하여 인터페이스를 구현해야합니다.

0

인터페이스는 구현을 지정하지 않고 클래스의 동작/속성을 정의하는 데 사용됩니다. 메서드와 속성의 묶음이 아니라 클래스를 구현하는 역할을하기 시작하면 인터페이스를 사용하여 여러 역할을 클래스에 할당 할 수 있습니다. 단일 클래스에서만 상속받을 수 있으므로 C#에서는 직계 상속을 사용할 수 없습니다. 클래스의 클라이언트를 클래스 자체가 아닌 인터페이스 (역할)에 의존하게하면 코드가 더 느슨하게 결합되고 더 잘 설계 될 수 있습니다.

단위 테스트를 작성하는 경우 주보다는 동작에 집중할 가능성이 더 많습니다. 인터페이스에 대한 코딩은 이러한 유형의 테스트를위한 모의/스텁 구현을 매우 쉽게 만듭니다.

모든 것이 인터페이스를 필요로하지는 않습니다.단순한 데이터 묶음 이상)에는 항상 두 가지 구현이 있으므로 IMHO가 있어야합니다. 애플리케이션의 실제 구현과 테스트의 하나 이상의 가짜 구현입니다.

0

인터페이스는 기능의 서명을 정의하는 계약입니다. 따라서 클래스가 외부 세계에 말하는 인터페이스 인 을 구현하면 특정 동작을 제공합니다.

예 : 클래스가 이고 '관리 가능'인터페이스를 구현하는 경우 관리되지 않는 리소스를 해제하는 기능이 있다는 의미입니다. 이제이 클래스를 사용하는 외부 객체는 사용되지 않는 관리되지 않는 객체 인 을 처리 할 계약을 갖고 있음을 알게되었습니다.

0

GoF의 첫 번째 원칙에 의해 제시된 바와 같이, 프로그램은 구현이 아닌 인터페이스에 프로그램합니다.

여러 가지 점에서 도움이됩니다. 구현을 변경하는 것이 더 쉽습니다. 코드를 테스트 할 수있게 만드는 것이 더 쉬워졌습니다.

희망이 도움이됩니다.