Reputation: 3702
So I am trying to stick to the whole "programming to an interface" methodology and wanted to structure some separate actions in my windows form app using interfaces.
Basically, I have a structure that I broke down like this
IActions
|----------------------------------------|
IValidateAction IExecuteAction
|----------------------| |----------------------|
IIis6Validate IIis7Validate IIis6Actions IIis7Actions
| |
|--------------------| |---------------------|
ValidateWebCreation CreateWebsite
I wanted to have an Execute() method on IActions that would propagate down. I know I could do that with a base abstract class but, again wanted to follow the "Program to an interface" methodology as I liked the idea of injecting an instance of (interface) so that at anytime that object could receive a different object as long as that object inherited from the same base interface.
But I find that the contract enforced when you have a class inherit from an interface doesn't adherer to a interface that inherits from another interface. I also read on another post "as long as InterfaceB can be interchangeable with InterfaceA". Does this apply here?
Can I use this tree? Am I forced to either use class inheritance or break this tree into separate tree structures?
Upvotes: 0
Views: 61
Reputation: 33388
This seems like a fairly complicated interface structure. Are you sure each of the interfaces you're defining here is actually inherently meaningful and useful? Does it need such a degree of specificity in the lower level interfaces, and are the higher level interfaces specific enough to be useful?
I'm not sure what you're referring to when you say that an interface extending another interface doesn't incur the same "contract enforcement" as a class. Remember that an interface doesn't implement anything, and so in deriving one interface from another, you're merely extending the contract that must be implemented by implementing classes. The members of the parent interface are implicitly included in the contract specified by the child interface. For example:
interface A
{
void Foo();
}
interface B
{
void Bar();
}
class C : B
{
void Foo();
void Bar();
}
Class C
must implement both Foo
and Bar
, since B
"inherits" Foo
from A
.
You may also like to look into explicit interface implementation; see here and here.
Update: If a method takes different parameters in more specific implementations, then you probably need to rethink your interface structure. Take a step back and think about what IAction
represents and how client code might use it.
For example, suppose IAction
defines a general Execute()
method with no parameters, while more specific derivatives of IAction
define more specific Execute(...)
methods with parameters.
What use, then is the "general" Execute()
method? Since each of the specific implementations actually requires additional information in the form of the parameters of the method, what exactly should the parameterless Execute()
do?
Upvotes: 0
Reputation: 47058
About the interface inheriting from another interface:
if you have
interface IA
{
void A();
}
interface IB : IA
{
void B();
}
A class implementing IB
must implement both A
and B
. You don't need to explicitly repeat the declaration from IA
in IB
since they are just declarations. IB
will require everything from IA
anyway.
I see no problem using your interface hierarchy.
As as side note you can create a parallel abstract class hierarchy that implements the corresponding interfaces (for some or all interfaces). This is relevant if you want to share some implementation, not just the declaration of some methods.
Upvotes: 3