Reasons not to use an abstract class instead of an interface?

I am considering using an abstract class with all abstract members instead of an interface in order to avoid an explicit boiler room code interface. Therefore, instead of

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

I would have

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

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

Any words of caution or consequences that I should be aware of here?

+5
source share
3 answers

The only thing you need to know and make an informed decision is that a class can inherit from only one class, but implement many interfaces.


In addition, some guidelines for using abstract classes or interfaces:

  • , . . , . , , . , .
  • , . , , .
  • , , . , .
  • , , . , .

http://msdn.microsoft.com/en-us/library/scsyfw1d%28vs.71%29.aspx

, . , , . , . - .

+8

, ... ; " " , - ... , , ; ( ) .

, , . , .

, , ... , .

. .

PS: manojlds , ... soooo ; -)

+4

.

. , predictAll(Instance array) predictSingle(Instance) . , predictAll .

. , .

.

: , . Typeclass Haskell - .

+2

All Articles