2012-03-26 2 views
1

내 응용 프로그램 중 하나에 여러 개의 컨트롤이 있는데, 모두 분명히 Control 클래스를 확장합니다.인터페이스에 대해 특정 클래스 유형을 적용합니까?

몇 가지 공유 인터페이스가 필요하므로 공유 기능을 다루는 인터페이스를 만들었습니다.

컨트롤의 하위 클래스에만 내 인터페이스를 부여 할 수있는 방법이 있습니까? MyClass에 그것을 제어하지 경우에도 IEmbed을 구현하려고하기 때문에

즉, (의사)

interface IEmbed 

class MyControl1 : Control, IEmbed 

class MyControl2 : Control, IEmbed 

class MyClass : IEmbed 

은 이상적으로는, 여기에 실패 할 컴파일러를하고 싶습니다.

잘못된 방식으로 진행되었거나이 동작을 적용 할 수있는 방법이 있습니까?

내가이 동작을 시행하고자하는 이유를 물어 봤는데

편집.

IEmbed 구현을 가져 와서 다른 요소에 자식 컨트롤로 추가하려는 메서드가 있습니다.

모두 좋지만 Controls.Add()는 IEmbed 개체를 거부하고 컴파일되지 않습니다.

나는 컴파일러에게 IEmbed를 구현하는 모든 것이 컨트롤이어야한다고 생각했다.

+0

인터페이스가 Control의 하위 클래스에만 주어져야하는 이유는 무엇입니까? 아마도 그것을 Control으로 다시 캐스팅해야합니까? 그렇다면 인터페이스에 메소드'Control GetControl()'을 추가하기 만하면 인터페이스가 Control의 서브 클래스가 아니어도 연결된 Control을 제공해야하고 캐스트를 피할 수 있습니다. – digEmAll

+0

편집을 참조하십시오. – KingCronus

+0

@digEmAll OP가 모든 구현물을 컨트롤로 만들려고한다면 컨트롤의 하위 클래스를 정확하게 지정해야합니다 (Strillo의 대답 참조). 특정 GUI 프레임 워크에 아무 것도 묶지 않아서 인터페이스가 더 멋지다고 상상해 봅니다. 그러나 그 안에있는''Control GetControl()''메소드는 모든 것을 망가 뜨립니다. –

답변

6

아니요, 컴파일 할 때이를 적용 할 방법이 없습니다.

당신 obj is Control 경우 IEmbed 인스턴스로 obj을 사용하기 전에 프레임 워크 코드 테스트를함으로써 런타임에 그것을 적용 할 수 있습니다.

업데이트 : 좋은 해결책이 중간 abstract class EmbedControl : Control에서 상속과 방법이 경우에 정말 필요가 없을 것입니다 (대신 IEmbedEmbedControl을 받아 들일 수 있도록하는 것처럼는 의견의 피드백을 바탕으로, 그것은 본다 인터페이스를 유지하려면 기본 클래스에서 abstract 메소드를 간단하게 사용할 수 있습니다.

위에서 "기본"클래스 인 Control에서 파생되어야한다고하더라도 "클라이언트"클래스의 구현자가 자신의 중간 클래스에서 파생되도록하는 것이 바람직하지 않은 경우도 있습니다. 같은 시간. 이 경우, 또 다른 좋은 방법은 제네릭을 사용하는 것입니다 :

public void DoSomethingWithControl<T>(T control) where T : Control, IEmbed 
+0

동의합니다. 문제는 OP가이 동작을 시행해야하는 이유를 알지 못한다는 것입니다. 그럴 가능성이있는 다른 방법이 있습니다. – digEmAll

+0

내 디자인을 다시 생각하게 될 것 같습니다 ... – KingCronus

+0

IEmbed 구현을 가져 와서 다른 요소에 자식 컨트롤로 추가하려는 메서드가 있습니다. 이것은 모두 훌륭하지만 Controls.Add()는 IEmbed 개체를 거부하며 컴파일되지 않습니다. IEmbed를 구현하는 모든 것이 컨트롤이어야한다는 것을 컴파일러에게 알리면 작동 할 수 있습니까? – KingCronus

2

내가 거기에 이런 일을 적용 할 수있는 방법이 생각하지 않습니다 -하지만 난 당신이 정말로 그냥 확인할 수있는 필요가 있다고 생각하지 않습니다 런타임에 인터페이스의 인스턴스가 컨트롤 인 경우.

하지만 : 당신은 그때 당신은 당신의 디자인을 검토 좋을 것 같은 검사를 수행 할 필요가있는 경우

abstract class EmbedControl 
    : Control 
{ 
    // your abstract members 
} 

class MyControl1 : EmbedControl 
5

: alternativley 그냥 대신 인터페이스 (Control에서 파생 된) 추상 클래스를 사용합니다. 인터페이스는 단지 계약 일 뿐이며 인터페이스를 고수 할 수있는 것에 제한을 두지 않습니다.유형이 중요한 경우 기본 클래스와 같은 다른 접근 방식을 시도해야합니다. 상속자가 인터페이스의 메서드를 구현해야하는 추상 클래스 (형식 제약 조건을 지정할 수있는)를 사용하는 방법에 대해 설명하겠습니까?

이렇게하면 BaseClass에서 파생 된 클래스가 모두 Control이고 IInterface를 구현할 수 있습니다.

0

선언을 사용하지 않고 T가 제어인지 확인하는 것은 무엇입니까?

또한, 필자는 abaove에 대해 동의합니다. 인터페이스가 유형이어야하는 이유는 무엇입니까? 나중에 컨트롤에 인터페이스를 다시 캐스팅 할 것이라는 것을 알고있는 나쁜 deszign처럼 보입니다 ...

0

사실 내가 왜 상상할 수 없는지 상상해보십시오. 그러나 컨트롤은 IComponent의 하위 항목입니다. 아마도 그걸 상속해야합니까?

0

글쎄, 내가 제공하는 솔루션은 매우 못 생겼지 만 컴파일하는 동안 실패합니다.

public interface IEmbed<T> where T: Control 
{ 
} 

public class A :Control, IEmbed<A> 
{ 
} 

//this fails at compile time as B does not inherit from Control class. 
public class B : IEmbed<B> 
{ 
} 
+0

B가 Control을 구현하지 않기 때문에 실패했다는 의미입니다. 그것은 물어 본 행동입니다. – daryal

+0

thx 그것은 월요일이었고 코드에서 주석을 놓쳤습니다. 코드가 일반적으로 컴파일되지 않는다고 생각했습니다. – RvdK

+2

이것은 거의 좋은 해결책이 아닙니다. 개발자는''T''의 목적을 알지 못하고''클래스 C : IEmbed ''을 선언함으로써 쉽게 이것을 깨뜨릴 수 있습니다. –

관련 문제