none
Why C# Abstract classes must implement/declare inherited Interface methods?

    Question

  • I have a question as to why in C# I must implement (or even declare) within an Abstract class an inherited member function from and Interface.

    The code below generates this error under a similar condition:
    Error 'ATest' does not implement interface member 'ITest.ITestMethod()'
    Is not the definition of an Abstract class by itself mean that this class cannot be instantiated? So what is the big deal that this Abstract class must implement (or declare) an inherited method from an Interface; for example, this Abstract class ATest must include this line of code to compile without error:
     
            public abstract void ITestMethod();

    In C++, if a class is derived from an Interface (a class that contains only purely virtual functions) and this class has not implemented all the interface's functions (Abstract class), then as long as this Abstract class is not directly instantiated, its cool by the C++ compiler.

    C# code in question:

        public interface ITest
        {
            void ITestMethod();
        }
     
        public abstract class ATest : ITest
        {
            public void ATestMethod() { } 
        }
     
        public class Test : ATest
        {
            public void ITestMethod() { }
        }

    Why is this the case for Abstract classes?

    Thanks
    Wednesday, February 18, 2009 8:22 AM

Answers

  • jeff00seattle said:

    Sorry, but somehow I am not making myself clear in this thread. I am stating that C# should have the same compile-time restrictions as are within C++ when it comes interfaces and abstract classes.



    Should this thread type really be marked as a question, or should it be marked as a discussion?  It seems to me that you're not really asking a question here, but you're simply stating your frustration with an established language specification rule.  Whether you agree with it or not, the C# designers have chosen to implement the language as a separate language from C++, with separate rules, and although the language may resemble C++ sometimes, that doesn't mean that C# is or was ever designed to be a spin-off. In this situation, it means that they chose to force the developer to write the method stubs as abstract for an abstract class.  In C++ they choose not to. 

    So the long and the short of it is, C++ is a different language than C#.  This could have been implemented like that, and I don't foresee any potential major issues, but the long and the short of it is, the designers of the C# language disagreed with this idea, and decided to go another way.  You've been given several potential answers to your original question, but it doesn't even seem that you're looking for an answer.  If this is the case, please change your thread type to discussion, so that those who give proper answers to the original question will understand they're entering a discussion where there is no "answer".
    David Morton - http://blog.davemorton.net/
    Wednesday, February 18, 2009 6:15 PM
  • To add to what David stated above, C# also has to stick to the CLI - it cannot choose its own rules regarding how abstract classes are implemented. The same rules are followed by other CLI languages such as C++/CLI and VB.NET too.

    http://blog.voidnish.com
    Wednesday, February 18, 2009 6:20 PM
  • jeff00seattle said:

    Sorry, but somehow I am not making myself clear in this thread. I am stating that C# should have the same compile-time restrictions as are within C++ when it comes interfaces and abstract classes.

    The focus of my article is that in C# is that if let us say as with InterfaceB is derived from InterfaceA whereby InterfaceB does not need to declare all of InterfaceA purely virtual functions, then so it should be the same as if an Abstract class derived from InterfaceA whereby this Abstract does not have to declare InterfaceA purely virtual functions.

    This is because in either state, classes declared as Interface or Abstract, neither are instantiate-able just by the fact that they are using these keywords, and only the classes to implement purely virtual functions.


    An abstract class in C# is more concrete than virtual or abstract.  Its' most common use is to provide base functionality to derived classes.  The other common use is to enforce a contract upon derived classes.  The two uses usually appear together. 

    The closest C++ kin to that concept might be templates.  But, C# generics provide the much of the functionality of C++ templates.

    And what is the difference between C++ interfaces and abstract classes.  Your link appeared to use the two terms interchangeably.


    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, February 18, 2009 6:12 PM

All replies

  • I think you should look at Virtual Function in C++ too. Because of Virtual Function cannot have an implementation in Abstract class so you must implement it in the derive class.

    http://www.codersource.net/cpp_virtual_functions.html

    Ming Man
    chanmm
    Wednesday, February 18, 2009 9:51 AM
  • chanmm said:

    I think you should look at Virtual Function in C++ too. Because of Virtual Function cannot have an implementation in Abstract class so you must implement it in the derive class.

    http://www.codersource.net/cpp_virtual_functions.html

    Ming Man


    chanmm


    You mean abstract function, not virtual function.
    Wednesday, February 18, 2009 9:52 AM
  • Not to diverge from this C# topic on Abstract classes, but here is an example of what is acceptable by a C++ compiler, but not by a C# compiler (the code shown at the start of this topic):
     
        class ITest // Interface
        {
        public:
            virtual void ITestMethod() = 0;
        };
     
        // Abstract class 
        // Because is does not implement ITestMethod()
        class ATest : public ITest 
        {
        public:
            void ATestMethod() { }
        };
     
        class Test : public ATest
        {
        public:
            void ITestMethod() { }
        };
    Wednesday, February 18, 2009 10:17 AM
  • While an abstract class cannot be instantiated, it can have implementation details.  The designers of C# chose to force the user to either implement the functionality, or specifically state that the functionality inherited from the interface will not be implemented at this level.  It's more of a "tell me you know you left this method out" type of check from the compiler.
    David Morton - http://blog.davemorton.net/
    Wednesday, February 18, 2009 3:50 PM
  • You can avoid declaring a body by declaring an abstract function :-

            public interface ITest
            {
                void ITestMethod();
            }
           
            public abstract class ATest : ITest
            {
                public void ATestMethod() { }

                public abstract void ITestMethod();
            }

            public class Test : ATest
            {
                public override void ITestMethod()
                {
                }
            }

    http://blog.voidnish.com
    Wednesday, February 18, 2009 4:03 PM
  • ... and you could always do this....

    interface IInterfaceA 
        { 
            void MethodA(); 
        } 
        interface IInterfaceB : IInterfaceA 
        { 
            void MethodB(); 
        } 
        interface IInterfaceC : IInterfaceB 
        { 
            void MethodC(); 
        } 


    Mark the best replies as answers. "Fooling computers since 1971."


    EDIT:  What you cannot really do in C# is "template" a class the way you can in C++.
    Wednesday, February 18, 2009 4:15 PM
  •  Any class that inherits an interface but implement the interfaces properties and methods.  Thats the whole purpose of the interface.  It allows for polymorphism.

    See this thread:

    http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvcs/thread/f1b181f1-f876-40d2-8fb3-a5c2e1020a70/


    and the threads that link to other threads.... and so on....

    Compensating what I don't know yet, with what I do know now.
    Wednesday, February 18, 2009 4:17 PM
  • Nishant Sivakumar said:

    You can avoid declaring a body by declaring an abstract function :-

            public abstract class ATest : ITest
            {
                public void ATestMethod() { }

                public abstract void ITestMethod();
            }


    http://blog.voidnish.com


    Thanks for your response Nishant,

    But within the initial entry of this thread I had stated that I was forced in C# to add this abstract function declaration, which I deem it un-necessary.

    This abstract function declaration is not necessary in C++.
    Wednesday, February 18, 2009 4:54 PM
  • You already have your answer: It's to force the programmer to visibly and consciously acknowledge that they are dealing with all the methods in the interface. You then have to decide for each interface method whether to implement it in the abstract class or not, and whether it is going to be virtual or not.

    Of course, you don't have to write all the code yourself; you can just right-click the name of the interface in the class definition in code, and select "Implement Interface".
    Wednesday, February 18, 2009 5:01 PM
  • David M Morton said:

    While an abstract class cannot be instantiated, it can have implementation details.


    David Morton - http://blog.davemorton.net/

    Thanks David for you response,

    Yes, I understand that an Abstract class can have implementation details inherited Interface function; however, I must at least declare an inherited Interface function. What is the point of declaring it abstract? An Abstract class should not behave no differently than if an Interface was derived from another Interface:
     
        public interface ITest
        {
            void ITestMethod();
        }
     
        public interface ITest_2
        {
            void ITestMethod_2();
        }
    Wednesday, February 18, 2009 5:08 PM
  • Well, you're dealing with the tension of whether an abstract class should be treated as an interface, or whether it should be treated as a class.  If it's treated as an interface, then I agree with you, if it's treated as a class, then I don't.  The C# designers chose to treat abstract classes as "classes" probably mostly to prevent confusion regarding implementing classes versus implementing interfaces.  I suppose they could have just as easily treated them as interfaces for implementation purposes, but they didn't.  Beyond that, I really don't know.
    David Morton - http://blog.davemorton.net/
    Wednesday, February 18, 2009 5:11 PM
  • jeff00seattle said:

    Nishant Sivakumar said:

    You can avoid declaring a body by declaring an abstract function :-

            public abstract class ATest : ITest
            {
                public void ATestMethod() { }

                public abstract void ITestMethod();
            }


    http://blog.voidnish.com


    Thanks for your response Nishant,

    But within the initial entry of this thread I had stated that I was forced in C# to add this abstract function declaration, which I deem it un-necessary.

    This abstract function declaration is not necessary in C++.


    Well if you want to compare with C++ you should compare the right entities. Native C++ does not really have a concept of interfaces.

    Consider the following hierarchy (I used C++/CLI) :

    interface class IRefFoo
    {
        void Foo();
    };

    ref class RefFooBase abstract : public IRefFoo
    {
    public:
        virtual void Foo() = 0;
    };

    ref class RefFoo : public RefFooBase
    {
    public:
        virtual void Foo() override {}
    };

    There's an interface, an abstract base that implements this interface, and a solid class that inherits from the abstract class.

    There's no equivalent in native C++ for IRefFoo. IRefFoo and RefFooBase are combined in native C++ as :

    class NativeFooBase
    {
    public:
        virtual void Foo() = 0;
    };

    and you can then have a solid class derived from it :

    class NativeFoo : public NativeFooBase
    {
    public:
        virtual void Foo(){}
    };

    Bu in NativeFooBase you are essentially declating the method (albeit as pure virtual) - but that's pretty much what the abstract ref class makes you do too.

    http://blog.voidnish.com
    Wednesday, February 18, 2009 5:19 PM
  • Stuck on Code said:

     Any class that inherits an interface but implement the interfaces properties and methods.  Thats the whole purpose of the interface.  It allows for polymorphism.


    My contention is that an public abstract class ATest : ITest should C# compile with incident as could public interface ITest_2 : ITest, because neither can be declare directly.

    And this approach does not violate polymorphism because it is abstract, and should be assumed that as if purely virtual function of Interface ITest is inherited by Interface ITest_2.
     
    For example, in C++, this is perfectly acceptable expectation of what because instantiation is check at compile time. Extending the fourth entry in this thread with its C++ classes, here is C++ code that tries to instantiate an abstract class and fails with this error message:
     
    Error C2259: 'ATest' : cannot instantiate abstract class
     
    // C++ code
    void main()
    {
        // Instantiate Abstract class ATest
        ATest* pATest = new ATest;
     
        Test* pTest = new Test;
    }
    Wednesday, February 18, 2009 5:27 PM
  • Nishant Sivakumar said:


    Well if you want to compare with C++ you should compare the right entities. Native C++ does not really have a concept of interfaces.

    http://blog.voidnish.com


    This thread is talking about native C++, and I do strongly disagree that native C++ does not have the the concept of interfaces.

    Read the follow posting from 1995:
    C++ as an Interface Definition Language


    Interfaces are one of the major corner stones of C++ language from which C# is derived from. The absolute only difference are:
    • C++ interface implementation is a class declaration where its body has only functions and all are purely virtual.
    • C# has the keyword interface which provide the assumption that all functions are purely virtual
    • Edited by jeff00seattle_2 Wednesday, February 18, 2009 5:45 PM bold to body
    Wednesday, February 18, 2009 5:44 PM
  • David M Morton said:

    Well, you're dealing with the tension of whether an abstract class should be treated as an interface, or whether it should be treated as a class.  If it's treated as an interface, then I agree with you, if it's treated as a class, then I don't.  The C# designers chose to treat abstract classes as "classes" probably mostly to prevent confusion regarding inheriting classes versus implementing interfaces.  I suppose they could have just as easily treated them as interfaces for implementation purposes, but they didn't.  Beyond that, I really don't know.


    David Morton - http://blog.davemorton.net/


    Note the "key words" here.  "Inheritance" and "Implementation".  =P^D

    You keep referring to inheriting interfaces, which does not occur in C#.  Inheritance, by definition, suggests that you do not need to implement code.  You don't need to write anything for inherited members of a base class.

    Implementing interface members means, by definition, that you must get busy and compose.  That is the reason behind the two terms.

    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, February 18, 2009 5:45 PM
  • jeff00seattle said:

    Nishant Sivakumar said:


    Well if you want to compare with C++ you should compare the right entities. Native C++ does not really have a concept of interfaces.

    http://blog.voidnish.com


    This thread is talking about native C++, and I do strongly disagree that native C++ does not have the the concept of interfaces.

    Read the follow posting from 1995:
    C++ as an Interface Definition Language


    Interfaces are one of the major corner stones of C++ language from which C# is derived from. The absolute only difference are:
    • C++ interface implementation is a class declaration where the bold has only functions and all are purely virtual.
    • C# has the keyword interface which provide the assumption that all functions are purely virtual


    I do not disagree with what you are saying, I am just saying that the equivalent in C# of a native C++ purely virtual abstract class is not an interface. The equivalent in C# would be an abstract class where all methods are abstract.

    In C++ terms the purely abstract C# class is the effective interface.

    I guess this is all just how you look at these things and I suppose people can argue for and against it for hours.

    http://blog.voidnish.com
    Wednesday, February 18, 2009 5:50 PM
  • jeff00seattle said:

    Nishant Sivakumar said:


    Well if you want to compare with C++ you should compare the right entities. Native C++ does not really have a concept of interfaces.

    http://blog.voidnish.com


    This thread is talking about native C++, and I do strongly disagree that native C++ does not have the the concept of interfaces.

    Read the follow posting from 1995:
    C++ as an Interface Definition Language


    Interfaces are one of the major corner stones of C++ language from which C# is derived from. The absolute only difference are:
    • C++ interface implementation is a class declaration where the bold has only functions and all are purely virtual.
    • C# has the keyword interface which provide the assumption that all functions are purely virtual


    Jeff,

    C++ does not have interfaces that are equivalent to what is defined in C#.  The closest thing to what you keep describing is the abstract class in C#.  But, C# does not permit multiple inheritance of classes, which C++ allows. 

    On the other hand a class can implement as many interfaces as it wants.  As I noted above, interfaces can implement other interfaces.  In such cases, no code needs to be written for the "inherited" base interfaces.  Not until the interface is implemented in a class, be it concrete or abstract, is the developer required to account for interface implementations.

     That's how it works.  Hope this helps.

    Rudedog   =8^D

    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, February 18, 2009 5:52 PM
  • Also, 2 notable points about a C# abstract class that separates it from a C# interface are :

    1) the C# abstract class derives from System.Object (this is not true of the interface) <-- I am talking with respect to how the IL is generated. A method body does get generated for each method in the interface, but it will always be blank.

    2) the C# abstract class has a constructor generated for it. This ctor does nothing other than call the System.Object ctor. [the generated IL for the interface has no such thing]

    So the native C++ abstract class with only pure virtual functions is essentially similar to the C# abstract class (but it's nothing like the C# interface)

    [Note that when I say C# interface or C# abstract class I mean CLR interfaces and CLR classes, I just used C# to emphasise the difference with C++]

    http://blog.voidnish.com
    Wednesday, February 18, 2009 5:55 PM
  • Sorry, but somehow I am not making myself clear in this thread. I am stating that C# should have the same compile-time restrictions as are within C++ when it comes interfaces and abstract classes.

    The focus of my article is that in C# is that if let us say as with InterfaceB is derived from InterfaceA whereby InterfaceB does not need to declare all of InterfaceA purely virtual functions, then so it should be the same as if an Abstract class derived from InterfaceA whereby this Abstract does not have to declare InterfaceA purely virtual functions.

    This is because in either state, classes declared as Interface or Abstract, neither are instantiate-able just by the fact that they are using these keywords, and only the classes to implement purely virtual functions.
    Wednesday, February 18, 2009 6:03 PM
  • jeff00seattle said:

    Sorry, but somehow I am not making myself clear in this thread. I am stating that C# should have the same compile-time restrictions as are within C++ when it comes interfaces and abstract classes.

    The focus of my article is that in C# is that if let us say as with InterfaceB is derived from InterfaceA whereby InterfaceB does not need to declare all of InterfaceA purely virtual functions, then so it should be the same as if an Abstract class derived from InterfaceA whereby this Abstract does not have to declare InterfaceA purely virtual functions.

    This is because in either state, classes declared as Interface or Abstract, neither are instantiate-able just by the fact that they are using these keywords, and only the classes to implement purely virtual functions.


    An abstract class in C# is more concrete than virtual or abstract.  Its' most common use is to provide base functionality to derived classes.  The other common use is to enforce a contract upon derived classes.  The two uses usually appear together. 

    The closest C++ kin to that concept might be templates.  But, C# generics provide the much of the functionality of C++ templates.

    And what is the difference between C++ interfaces and abstract classes.  Your link appeared to use the two terms interchangeably.


    Mark the best replies as answers. "Fooling computers since 1971."
    Wednesday, February 18, 2009 6:12 PM
  • jeff00seattle said:

    Sorry, but somehow I am not making myself clear in this thread. I am stating that C# should have the same compile-time restrictions as are within C++ when it comes interfaces and abstract classes.



    Should this thread type really be marked as a question, or should it be marked as a discussion?  It seems to me that you're not really asking a question here, but you're simply stating your frustration with an established language specification rule.  Whether you agree with it or not, the C# designers have chosen to implement the language as a separate language from C++, with separate rules, and although the language may resemble C++ sometimes, that doesn't mean that C# is or was ever designed to be a spin-off. In this situation, it means that they chose to force the developer to write the method stubs as abstract for an abstract class.  In C++ they choose not to. 

    So the long and the short of it is, C++ is a different language than C#.  This could have been implemented like that, and I don't foresee any potential major issues, but the long and the short of it is, the designers of the C# language disagreed with this idea, and decided to go another way.  You've been given several potential answers to your original question, but it doesn't even seem that you're looking for an answer.  If this is the case, please change your thread type to discussion, so that those who give proper answers to the original question will understand they're entering a discussion where there is no "answer".
    David Morton - http://blog.davemorton.net/
    Wednesday, February 18, 2009 6:15 PM
  • To add to what David stated above, C# also has to stick to the CLI - it cannot choose its own rules regarding how abstract classes are implemented. The same rules are followed by other CLI languages such as C++/CLI and VB.NET too.

    http://blog.voidnish.com
    Wednesday, February 18, 2009 6:20 PM
  • David M Morton said:

    Should this thread type really be marked as a question, or should it be marked as a discussion?



    Thank you all for your input, and yes it probably should have been marked as a discussion instead of a question.

    I did not think it would lead to so many replies, that is because I thought I was missing something and that my lingua franca for 15+ years has been C++, and it surprised me by the compile-time error of abstracts derived from interfaces.

    Truly appreciate this discussion, Thank you.
    Wednesday, February 18, 2009 7:15 PM