pghtech
pghtech

Reputation: 3702

Need help structuring my Inheritance with the use of Interfaces?

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

Answers (2)

Will Vousden
Will Vousden

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

Albin Sunnanbo
Albin Sunnanbo

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

Related Questions