Aug 25 2005

Interfaces or Inheritance

Category: .NetRory Primrose @ 20:12

I have been thinking about this a bit recently. When is it the most appropriate to use an interface or inheritance? There are so many advantages and disadvantages with both.

Not that I can go to his talk, but I liked a few of Doug's comments on the matter.

Interfaces are better for those places where extensibility is the highest requirement. Inheritance is better for those places where reusability is the highest requirement.

You can screw up your software by doing too much of either one, or by neglecting either one.

A couple of weeks ago I was building a queueing system using generics. The main problem I had was that I wanted a little bit of functionality in the queued item, so I wrote a base class for it. That was all well and good, but then I quickly realised that most of my objects already have a base class. As you can't have multiple inheritance, there goes that idea.

To get around this, I have to change the implementation to use an interface instead. This isn't a bad thing, but to get the same functionality there will probably be a performance hit. This is because the queue would need to constantly check with eached queued item for its progress status rather than the queued item notifying the queue when its progress status changes.

Other than the performance consideration, I don't like the interface solution so much because the queue will have to assume that the queued item correctly uses the interface. An interface will ensure that an object has the right signatures, but not whether the code in the implemented interface of the object does what is intended.

Any thoughts?

Tags:

Comments

1.
Eddie de Bear Eddie de Bear says:

Callbacks...

Use the interface to register a callback delegate with each class, then when the item needs to do it's notification, it can just use the callback..

Sure, you are likely going to have to write similar code in each class, but this way you get the cake and eat it too.. Smile

2.
Rory Primrose Rory Primrose says:

Cheers Eddie.

I did have that as one of my solutions and it would get around the performance problem. What you have suggested will be the way that I do it in the end.

The reason I don't like it is that I don't trust the implemented interface to be used correctly. What I mean is that I can't trust that when something is given to the interface (property set of a callback reference for example), that the object will store that value and use it correctly.

What it comes down to is that objects which talk to these interfaces have to be designed in such a way that it doesn't matter if an object doesn't support the interface as expected, or simply fall over if ignoring the situation isn't possible.

I guess it is the responsibility of the coder that uses the interface to use it as expected, not the responsibility of the creator of the interface.

This is why I like base classes because as the coder, I can strickly determine the code and how the object is used in the derived class. Interfaces place too much reliance on the coder that uses the interface to use it correctly.

3.
Bill McCarthy Bill McCarthy says:

Use both Smile

The limitation you are hitting requires an interface, so use an interface.  But you can still do delegation, by having the interface return a Type which is based on your base class

4.
trackback notgartner.com: Mitch Denny's Blog says:

Trackback from notgartner.com: Mitch Denny's Blog\n\n

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading