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