Thread overview | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
|
August 07, 2013 Question on Interface. | ||||
---|---|---|---|---|
| ||||
I like the concept of interface, It enforces its successors to implement some necessary methods. Please take a look at the following example: device.d --------------------------------- interface device { // I want the three methods implemented by its successors void PowerOn(); void PowerOff(); void Reset(); string signature; // This is not allowed in D, but every device should has a signature. } Why it doesn't support non-static members? Actually in many cases, we need an interface which needs enforce its successors to implement necessary methods, meanwhile it needs has its own non-static members. |
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to SteveGuo | Am 07.08.2013 09:11, schrieb SteveGuo:
> I like the concept of interface, It enforces its successors to
> implement some necessary methods.
>
> Please take a look at the following example:
>
> device.d
> ---------------------------------
> interface device
> {
> // I want the three methods implemented by its successors
> void PowerOn();
> void PowerOff();
> void Reset();
>
> string signature; // This is not allowed in D, but every
> device should has a signature.
> }
>
> Why it doesn't support non-static members?
> Actually in many cases, we need an interface which needs enforce
> its successors to implement necessary methods, meanwhile it needs
> has its own non-static members.
>
if D would allow this - what is then the difference between a class with your methods as virtuals + your string?
interface are for loosier coupling then classes - thats why only declerations not implementations (like your string) are allowed, same goes to Java and C# (and i think most other interface having languages)
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to SteveGuo | On Wednesday, 7 August 2013 at 07:11:58 UTC, SteveGuo wrote:
> I like the concept of interface, It enforces its successors to implement some necessary methods.
>
> Please take a look at the following example:
>
> device.d
> ---------------------------------
> interface device
> {
> // I want the three methods implemented by its successors
> void PowerOn();
> void PowerOff();
> void Reset();
>
> string signature; // This is not allowed in D, but every device should has a signature.
> }
>
> Why it doesn't support non-static members?
> Actually in many cases, we need an interface which needs enforce its successors to implement necessary methods, meanwhile it needs has its own non-static members.
in this case you could switch to abstract class, or make signature a read-only property
@property string signature();
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to dennis luehring | > if D would allow this - what is then the difference between a class with your methods as virtuals + your string?
>
> interface are for loosier coupling then classes - thats why only declerations not implementations (like your string) are allowed, same goes to Java and C# (and i think most other interface having languages)
But classes cannot enforce its successor to do something. May introduce a new keyword "enforce"?
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to SteveGuo | On Wednesday, 7 August 2013 at 07:30:52 UTC, SteveGuo wrote:
>> if D would allow this - what is then the difference between a class with your methods as virtuals + your string?
>>
>> interface are for loosier coupling then classes - thats why only declerations not implementations (like your string) are allowed, same goes to Java and C# (and i think most other interface having languages)
>
> But classes cannot enforce its successor to do something. May introduce a new keyword "enforce"?
what? O_o
let me explain, abstract class requires its successors to implement all methods, but may have fields.
class successors *always* do something, either their methods has derived behavior or overridden ones. so does interface, if you has class derived from interface then its successors may or may not override its methods.
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to evilrat | > what? O_o
> let me explain, abstract class requires its successors to implement all methods, but may have fields.
> class successors *always* do something, either their methods has derived behavior or overridden ones. so does interface, if you has class derived from interface then its successors may or may not override its methods.
Thanks for replying, I think I need read more online-docs.
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to SteveGuo | On Wednesday, 7 August 2013 at 08:18:43 UTC, SteveGuo wrote:
>> what? O_o
>> let me explain, abstract class requires its successors to implement all methods, but may have fields.
>> class successors *always* do something, either their methods has derived behavior or overridden ones. so does interface, if you has class derived from interface then its successors may or may not override its methods.
>
> Thanks for replying, I think I need read more online-docs.
As mentioned by evilrat earlier the 'string signature' should probably be made a readonly property, set in the constructor. I don't think D supports defining a constructor signature on interfaces (I could be wrong), so you want to define an invariant as part of the contract.
You may also want to protect the constructor and implement a factory method (or equivalent) pattern.
I will need to look it up, but if I recall it may be possible to define a 'final' function on the interface that can set the 'signature'.
I regret that I cannot at this time give you a definitive answer as I'm not in my office where I could verify.
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andre Artus | > As mentioned by evilrat earlier the 'string signature' should probably be made a readonly property, set in the constructor. I don't think D supports defining a constructor signature on interfaces (I could be wrong), so you want to define an invariant as part of the contract.
>
>
> You may also want to protect the constructor and implement a factory method (or equivalent) pattern.
> I will need to look it up, but if I recall it may be possible to define a 'final' function on the interface that can set the 'signature'.
>
> I regret that I cannot at this time give you a definitive answer as I'm not in my office where I could verify.
Thanks for the help:) I'm a newbie in D scene, so there should be much more to learn.
|
August 07, 2013 Re: Question on Interface. | ||||
---|---|---|---|---|
| ||||
Posted in reply to SteveGuo | On Wednesday, 7 August 2013 at 07:11:58 UTC, SteveGuo wrote:
> I like the concept of interface, It enforces its successors to implement some necessary methods.
>
> Please take a look at the following example:
>
> device.d
> ---------------------------------
> interface device
> {
> // I want the three methods implemented by its successors
> void PowerOn();
> void PowerOff();
> void Reset();
>
> string signature; // This is not allowed in D, but every device should has a signature.
> }
>
> Why it doesn't support non-static members?
> Actually in many cases, we need an interface which needs enforce its successors to implement necessary methods, meanwhile it needs has its own non-static members.
Use properties. Interfaces cannot require fields but can require methods. A property is a getter and setter method that wraps a field.
So instead ing string signature; use @property string signature();
Then for all practical purposes you can treat it as a field.
|
Copyright © 1999-2021 by the D Language Foundation