Abstract classes vs interfaces, casting from void*
Alex
sascha.orlov at gmail.com
Sat Aug 10 17:28:32 UTC 2019
On Saturday, 10 August 2019 at 14:29:03 UTC, John Colvin wrote:
> On Saturday, 10 August 2019 at 10:11:15 UTC, Alex wrote:
>> On Saturday, 10 August 2019 at 08:20:46 UTC, John Colvin wrote:
>>> On Friday, 9 August 2019 at 13:39:53 UTC, Simen Kjærås wrote:
>>>> <snip>
>>>
>>> Thanks for the extra detail.
>>>
>>> Is there a solid reason to ever use an interface over an
>>> abstract class? (Other than multiple inheritance).
>>>
>>> I'm such a noob at anything related to OO.
>>
>> The general question is tricky, as different languages differ
>> in details what is forced and what is allowed for abstract
>> classes and interfaces.
>>
>> But roughly speaking, my opinion is: if you can/want to
>> provide some default behavior than you are about to write an
>> abstract class.
>> If you are about to provide information/restriction of
>> behavior, then this is more like an interface.
>
> Ok. What would go wrong (in D) if I just replaced every
> interface with an abstract class?
´´´
void main(){}
interface A { void fun(); }
abstract class B{ void fun(); }
class C : A{ void fun(){} }
class D : B{ /*override*/ void fun(){} }
´´´
case 1:
interface A and class C implementing interface A:
You don't need to "override" anything. You are forced to provide
an implementation of the function inside the class.
case 2:
abstract class B and class D inheriting from it:
You can but not have to provide an implementation of a function
inside the abstract class.
If I don't and do not provide any implementation inside D I get a
linker error. Don't how this case behaves on your system.
If you provide an implementation inside the abstract class, you
don't have to provide any in the derived one.
In any case, if you want to provide an implementation inside the
derived class you have to literally "override", as in D implicit
overrides are not allowed.
More information about the Digitalmars-d-learn
mailing list