인터페이스 대신 추상 클래스를 사용하지 않는 이유는 무엇입니까?

명시 적 인터페이스 구현 보일러 플레이트 코드를 피하기 위해 인터페이스 대신 모든 추상 멤버와 추상 클래스를 사용하는 것이 좋습니다. 그래서 그 대신인터페이스 대신 추상 클래스를 사용하지 않는 이유는 무엇입니까?

type IMyInterface = 
    abstract Name : string 
    abstract Text : string 

type MyClass() = 
    member __.Name = "name" 
    member __.Text = "text" 
    interface IMyInterface with 
     member this.Name = this.Name 
     member this.Text = this.Text

의 나는주의 또는 의미의

[<AbstractClass>] 
type MyAbstractClass() = 
    abstract Name : string 
    abstract Text : string 

type MyClass() = 
    inherit MyAbstractClass() 
    override __.Name = "name" 
    override __.Text = "text"

아무 단어 나 여기 알고 있어야이있을 것이다?

출처

2011-04-24 Stephen Swensen

인터페이스와 추상 기본 클래스 사이를 결정하는 경우 두 가지를 모두 사용해보십시오. 구현자가 * 상속 할 수있는 추상 기본 유형을 제공하고 인터페이스를 구현하도록합니다. 그런 다음 ABC가 아닌 인터페이스에 대한 참조를 승인하십시오. 이는 모든 시나리오에서 작동하지 않습니다 (예 : 코드에서 실제로 구현할 때마다 ABC에있는 코드가 필요하며 대체 구현을 허용 할 수 없음). 그러나 종종 좋은 아이디어가 될 수 있습니다. –

@Merlyn Morgan-Graham - 우수 제안! 나는이 접근법을 시도하고 있으며, 지금까지 두 세계의 장점을 최대한 발휘하여 노력하고 있습니다. –

주의해야 할 점은 클래스가 하나의 클래스에서만 상속받을 수 있지만 많은 인터페이스를 구현한다는 것입니다.

그 외에도, 추상 클래스 나 인터페이스를 사용하는 방법에 대한 몇 가지 권장 사항 : 당신이 당신의 구성 요소의 여러 버전을 만드는 예상되는 경우

, 추상 클래스를 만들 수 있습니다. 추상 클래스 은 구성 요소의 버전을 간단하고 쉬운 방법으로 제공합니다 ( ). 을 기본 클래스로 업데이트하면 클래스를 상속하는 모든 클래스가 으로 자동 업데이트됩니다. 한편, 인터페이스는 으로 작성된 후에는 변경할 수 없습니다. 인터페이스의 새 버전이 인 경우 완전히 새로운 인터페이스를 만들어야합니다.

작성중인 기능이 범위의 서로 다른 개체에서 유용 할 경우 인터페이스를 사용하십시오. 추상 클래스는 주로 과 밀접한 관련이있는 객체에 대해 주로 사용되는 이어야하며 인터페이스 은 관련없는 클래스에 공통 기능을 제공하는 데 가장 적합합니다.

작고 간결한 기능을 설계하려면 인터페이스를 사용하십시오. 크기가 큰 기능 단위를 디자인하는 경우 추상 클래스를 사용하십시오.

구성 요소 중 공통적으로 구현 된 기능을 제공하려면 추상 클래스를 사용하십시오. 추상 클래스 을 사용하면 클래스를 부분적으로 구현할 수 있지만 인터페이스에는 모든 멤버에 대해 구현이 포함되지 않습니다.
http://msdn.microsoft.com/en-us/library/scsyfw1d%28vs.71%29.aspx

는 개인적으로, 나는 이러한 권장 사항이 자리에있다 생각합니다. 특히 인터페이스는 생성 된 후에는 변경할 수 없습니다. 새 버전의 인터페이스가 필요한 경우 완전히 새로운 인터페이스를 만들어야합니다.은 매우 중요한 포인트입니다.

출처

2011-04-24 04:08:45 manojlds

오른쪽, 고마워요. 저 사람이 방금 내 마음에 들었습니다. 확실히 큰. –

COM을 통해 노출되지 않는 한 인터페이스를 변경할 수없는 기술적 인 이유는 없습니다. 닷넷 프레임 워크/언어로 보자. 버전 관리와 관련하여, 정말 좋은 이유가없는 한 공공 도서관 인터페이스에서 변경 사항을 적용하는 것은 나쁜 습관으로 간주되지만, 추상 기본 유형 (즉, 추상 멤버 추가)에도 동일한 권장 사항이 적용됩니다. –

"닷넷 프레임 워크/언어를 통해"당신이 무엇을 의미하는지 설명해 주시겠습니까 – manojlds

스티븐,

하나,

가장 기본적인, 그리고 분명 ... 인터페이스가 다른 구현을 할 수 있습니다; '게시 된 잘 아는 유형'이 추상 클래스 인 경우 대체물을 개 제공 할 수 없습니다.따라서 단점은 미래 옵션을 제한한다는 것입니다. 위쪽은 (얼마나 많은 상속인이 있느냐에 따라) 많은 보일러 플레이트 코드를 저장할 수 있다는 것입니다.

정말 확실한 다른 구현이 없다면 추상 클래스로 이동하십시오. 그렇지 않으면 인터페이스에 충실하십시오.

그리고 나는 둘 다 할 수 있다고 생각합니다. 그리고 그것은 여러분에게 두 세계에서 가장 좋은 것을 줄 것입니다.

건배. 키이스.

PS : manojlds가 오른쪽 물론 ... 그리고 soooo를 훨씬 더 sucinct ;-)

출처

2011-04-24 04:16:21 corlettk

필자는 인터페이스를 사용하여 추상 클래스보다 미래의 옵션을 제한한다고 생각합니다. 인터페이스를 제공하는 경우 변경 사항이 급격한 변화이므로 요구 사항이 변경되면 나중에 인터페이스를 변경할 수 없습니다. 공개 추상 메소드가 서명을 변경하지 않는다면 가상 클래스를 추가하고 내부 구현을 조정할 수 있으므로 추상 클래스는 훨씬 더 융통성이 있습니다. –

마크, 당신은 "유효한"요점을 가지고 있습니다. 그것은 단지 "중요하지 않은"것이 아닙니다. 내 경험에 의하면 "기존 클래스의 변형"이 더 많이 필요합니다. 기존 PUBLISHED 인터페이스에 메소드를 추가해야하는 "절. 아주 간단하게; 일단 인터페이스가 게시 단계에 도달하면 돌에 설정됩니다. 그렇지 않으면 게시하지 않을 것입니다. – corlettk

요구 사항은 출판 이후에 변경 될 수 있습니다. 플러그인 인터페이스를 노출 한 후 나중에 수행해야 할 작업보다 더 많은 작업을 수행해야하는 경우를 고려하십시오.인터페이스를 사용할 때의 해결책은 새로운 인터페이스를 만들어야한다는 것입니다. 그런 다음 새로운 클래스를 가상 클래스로 추가 할 수 있기 때문에 추상 클래스를 사용하여 문제가 존재하지 않는 여러 플러그인 아키텍처를 유지해야합니다. 행동 양식. 나는이 문제를 여러 번 경험했다. 여러 오픈 소스 프로젝트에서 여러 번 본 적이 있습니다. 그래도 내 머리 꼭대기에서 벗어날 수는 없다. –

추상 클래스에서, 당신은 모든 하위 클래스의 일반적인 동작을 구현할 수 있습니다.

인터페이스 디자인에서 복합 작업을 수행하기 위해 메서드를 다른 메서드로 호출 할 수 있습니다. 예를 들어, predictAll(Instance array)은 predictSingle(Instance)을 사용할 수 있으며 모든 하위 클래스에 대한 기본 구현을 제공합니다. 인터페이스를 사용하는 경우 모든 서브 클래스에 predictAll을 구현해야합니다.

그러나이 점은 다중 상속과는 큰 차이가 아닙니다. 나는 추상 클래스 이상의 인터페이스를 선호한다.

인터페이스를 통해 디자인을 유지할 수도 있습니다.

한 번 더 요점 : 인터페이스가 더 추상적 인 수업보다 기능 코드를 장려합니다. Haskell의 Typeclass는보다 강력한 인터페이스입니다.

출처

2011-04-24 04:22:12

인터페이스 대신 추상 클래스를 사용하지 않는 이유는 무엇입니까?

답변

관련 문제