473,320 Members | 1,841 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

interface vs. inheritance

Are there any good references/articles/books which provide clarity toward my
insecurity still on deciding how to model a complex system? I still feel
uncomfortable with my understanding, even though I have worked with these
systems on when to decide to use interfaces (and how they should be
developed) as opposed to or complemented by the use of inheritance from base
classes.
If I am thinking from the point of view of some specific activity and I
begin to think at the method level, how do I think about its implementation
at a code syntax level as to whether that method is obtained through
inheritance from a base class, or if I obtain it via an interface which I
have also inherited from?
Thank you. -hazz
Nov 16 '05 #1
7 12845
I tend to follow this guideline. If the relationship is clearly "is-a",
I use inheritance. If it is more like "can-be", I use interfaces. For
eg, TextBox "is-a" Control, ArrayList "can-be" enumerated (so it
implements IEnumerable). In general, if an object can be treated in
different ways (can be enumerated, can be cloned..), I implement
interfaces.

And obviously, if you're going to use existing functionality AND extend
it, I derive from it.

Regards
Senthil

Nov 16 '05 #2
Thank you so much for that very simple explanation Senthil. I think I get
that. I have to think a bit more about the "can-be" relationships.

Also as you stated, that if you are merely extending existing functionality,
you derive from it.
By that I assume you mean the other role of interfaces? ie. as a contract
with the underlying classes which they represent whose purpose is to provide
the freedom to change the underlying code without having to change the
interface ??? Wait a minute. In a project build I still have to rebuild the
whole solution with different projects whether they contain interfaces with
their associated classes or just the classes without any interface to
represent them, right? If the code changes in a class and I want to use it
somewhere outside of that namespace where it is referred to, I have to
rebuild the whole project so that Visual Studio (and my consumer class) will
recognize the new functionality.

Now I am getting into the reference dilemma which I puzzle over a bit on
complex projects ie. circular references, build problems where sometimes a
solution with many projects needs to be decomposed into smaller builds to
build without error.

If I create a project/namespace with a certain scope, like "datalayer" and
another, "application specific support utilities," then why would I use
interfaces to represent the classes contained in these projects? If I extend
the functionality of the application using either of these two different
examples, couldn't I equally inherit the interface by the 'class :
interface' syntax or by the 'using' statement? Both require I set a
reference prior to using them and both require I rebuild after any changes
are made to any of the participant classes. What I am getting at is that I
don't see how interfaces add any advantage here for extending functionality?
Is it because I can inherit from multiple interfaces? I still don't buy that
because I could just add one more 'using' statement and grab another
namespace with its underlying classes and not have to mess at all with the
time it takes to create an interface.

thanks for any clarification if I haven't absolutely lost you. ;-) It is o.k
to say my question makes absolutely no sense or I am dead wrong about my
understanding. -hazz
"sadhu" <se**********@wdevs.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I tend to follow this guideline. If the relationship is clearly "is-a",
I use inheritance. If it is more like "can-be", I use interfaces. For
eg, TextBox "is-a" Control, ArrayList "can-be" enumerated (so it
implements IEnumerable). In general, if an object can be treated in
different ways (can be enumerated, can be cloned..), I implement
interfaces.

And obviously, if you're going to use existing functionality AND extend
it, I derive from it.

Regards
Senthil

Nov 16 '05 #3
1)Favor containment.
2)Avoid extending a class unless it was designed to be extended.
3)If you have a well defined contract that will be implemented by many
classes use an interface. An interface represents a purely abstract IS_A
relationship.
4)If the contract is evolving, consider using a base class so that you
can provide default implementations of any new methods so that clients
that use your base class can be recompiled without breaking.
5)Use a base class if you need to include implementation details.

That said... every time I try to solve a problem I seem to start by
describing the contract with an interface say IVersionable. Then I end
up writing an abstract class with default implementations as in
AbstractVersion. Then I end up creating concrete classes based on the
Abstract class as in Version : AbstractVersion.

So I would try this pattern: Interface -- AbstractInterface -- Class
which uses both interfaces and base classes and offers both options to
the user of the "interface/class."

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #4
Thank you Jeff. I am digesting this. It's a big meal. As my Dad used to say,
my eyes are bigger than my stomach.

Just a bit of qualification of what you mean by;

1 Avoid extending a class unless it was designed to be extended?
a) what's one bad idea that would make it a bad idea with an eye toward
extending.

b) one good idea with an eye toward extension.

and

2. Use a base class if you need to include implementation detail
a) you mean implementation details get fleshed out in the derived classes?
Or are you saying certain implementation details should be in the base class
as opposed to somewhere else?

I really appreciate the your responses. Fortunately I wasn't the architect
on a recent project but I found out you can be thrown into a lego pond and
still expect to hook a few things up. -hazz
"Jeff Louie" <je********@yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
1)Favor containment.
2)Avoid extending a class unless it was designed to be extended.
3)If you have a well defined contract that will be implemented by many
classes use an interface. An interface represents a purely abstract IS_A
relationship.
4)If the contract is evolving, consider using a base class so that you
can provide default implementations of any new methods so that clients
that use your base class can be recompiled without breaking.
5)Use a base class if you need to include implementation details.

That said... every time I try to solve a problem I seem to start by
describing the contract with an interface say IVersionable. Then I end
up writing an abstract class with default implementations as in
AbstractVersion. Then I end up creating concrete classes based on the
Abstract class as in Version : AbstractVersion.

So I would try this pattern: Interface -- AbstractInterface -- Class
which uses both interfaces and base classes and offers both options to
the user of the "interface/class."

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 16 '05 #5
I'm certainly no guru, but I've been taking the pragmatic view.

1) You can only inherit code from one base class, but you can implement as
many interfaces as you wish.
2) You have to write code for every interface member, even if the code to
implement it in every class is the same.

In the work I've done so far, it hasn't been too difficult to figure out
when I can write a lot of useful code in a base class, and simply inherit
it, and when most of the methods would have to be overridden anyway, so it
isn't that much more work to have an interface. We save inheritance for the
cases where it's really useful. This has meant writing throwaway code (and
actually throwing it away -- after chopping out the useful bits and putting
them where they really belong), but that's how you learn to program.

And yes, as someone else mentioned, don't forget about containing things. I
have found events very useful for that. If there is a set of functionality I
might like to inherit, but can't because I'm already inheriting from
something else, and I have only a couple methods that would need overrides
(if I were able to inherit from it), then I can create a class that exposes
those methods as events. Then my main class can get the functionality by
having a variable of that type... maybe setting some properties to tell it
what it needs to know about the main class, and handle the events rather
than overriding methods.

-Rachel

"Hazz" <ha**@nospameroosonic.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Are there any good references/articles/books which provide clarity toward
my insecurity still on deciding how to model a complex system? I still
feel uncomfortable with my understanding, even though I have worked with
these systems on when to decide to use interfaces (and how they should be
developed) as opposed to or complemented by the use of inheritance from
base classes.
If I am thinking from the point of view of some specific activity and I
begin to think at the method level, how do I think about its
implementation at a code syntax level as to whether that method is
obtained through inheritance from a base class, or if I obtain it via an
interface which I have also inherited from?
Thank you. -hazz

Nov 16 '05 #6
Hi Hazz... Inline
a) what's one bad idea that would make it a bad idea with an eye toward extending.<
If you have a verified collection class that is not designed to be
extended and a user of your class adds setters and getters that do not
verify and corrupt the collection. So inheritance breaks encapsulation.
one good idea with an eye toward extension.< An AbstractVersion class with an == operator and a default virtual
Equals method designed to be overridden by the user. The user can
override the Equals method, thus changing the implementation of the ==
operator!
a) you mean implementation details get fleshed out in the derived

classes? Or are you saying certain implementation details should be in
the base class as opposed to somewhere else?<

C# only supports single inheritance of implementation so your choices
are to extend from a class with implementation or contain a class with
implementation and forward (delegate) calls to the contained class or
just write all the implementation from scratch.

Now the interesting decision is if you should extend from an incomplete
class or define a method that takes an interface that defines the
incomplete methods. So if you have a generic sort routine that is
incomplete and requires a Compare method specific to a user class you
can either create an abstract class with an abstract Compare method or
you can declare a Sort method that takes an IComparable object. In the
first case the user extends the AbstractClass and provides a concrete
Compare method. In the second case the use creates a class that
implements IComparable with a Compare method and passes the IComparable
obect to the Sort method. So
1) MySortableCollection : AbstractSortableCollection
mySortableCollection.Sort()
2) MyComparableClass : IComparable
mySortableCollection.Sort(myComparableClass)
Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #7
Absolutely fascinating. Events as another means of reuse. Legos supreme. I
don't understand that yet but maybe it has to do with the delegate or type
safe function pointer which allows a level of indirection to sidestep the
inheritance constraints. You mean I am going to have to learn how to wire up
my own events rather than limit myself to only those times when Visual
Studio does it for me automagically?

So interfaces allow you to flatten the structure?...to inherit useful
functionality by virtue of interface multiple inheritance.
Interfaces allow you to compose if you understand which role each member of
the band plays. I can create new members for my band, adding a horn section
if need be.
And inheritance being the vertical dimension where I can think about things
like, "o.k., by adding more generally used functionality higher up the
hierarchy with the base being highest, then its about using the most derived
class, the lowest member, to be consumed by most clients typically becuase I
have something useful to offer. If I do it right, maintainability is
achieved when I can change some functionality high up the chain in one place
rather than having to fly all over the landscape having to touch down
everywhere there is a component which inherited from it. Maybe just by
adding a constructor with another signature to pass an additional parameter
up the ctor chain, I can make adjustments to my application without really
doing any major design damage. The idea is to be creative right? And we can
have fun doing this? Thanks Rachel.

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:e$**************@TK2MSFTNGP10.phx.gbl...
I'm certainly no guru, but I've been taking the pragmatic view.

1) You can only inherit code from one base class, but you can implement as
many interfaces as you wish.
2) You have to write code for every interface member, even if the code to
implement it in every class is the same.

In the work I've done so far, it hasn't been too difficult to figure out
when I can write a lot of useful code in a base class, and simply inherit
it, and when most of the methods would have to be overridden anyway, so it
isn't that much more work to have an interface. We save inheritance for
the cases where it's really useful. This has meant writing throwaway code
(and actually throwing it away -- after chopping out the useful bits and
putting them where they really belong), but that's how you learn to
program.

And yes, as someone else mentioned, don't forget about containing things.
I have found events very useful for that. If there is a set of
functionality I might like to inherit, but can't because I'm already
inheriting from something else, and I have only a couple methods that
would need overrides (if I were able to inherit from it), then I can
create a class that exposes those methods as events. Then my main class
can get the functionality by having a variable of that type... maybe
setting some properties to tell it what it needs to know about the main
class, and handle the events rather than overriding methods.

-Rachel

"Hazz" <ha**@nospameroosonic.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
Are there any good references/articles/books which provide clarity toward
my insecurity still on deciding how to model a complex system? I still
feel uncomfortable with my understanding, even though I have worked with
these systems on when to decide to use interfaces (and how they should be
developed) as opposed to or complemented by the use of inheritance from
base classes.
If I am thinking from the point of view of some specific activity and I
begin to think at the method level, how do I think about its
implementation at a code syntax level as to whether that method is
obtained through inheritance from a base class, or if I obtain it via an
interface which I have also inherited from?
Thank you. -hazz


Nov 16 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: Tom Evans | last post by:
My basic question: If I have a specific interface which I know is going to be implemented by a number of classes, but there is no implementation commonality between them, what is the preferred...
4
by: Roy Pereira | last post by:
I have an application that is composed of a set of "Content" dlls and a viewer application. The viewer calls a standard set of functions that are present in all the dlls. I maintain this by...
4
by: christopher diggins | last post by:
A feature that I find signficantly missing in C# is the ability to write functions in interfaces that can call other functions of the interface. Given an interface ISomeInteface the only way we can...
21
by: Helge Jensen | last post by:
I've got some data that has Set structure, that is membership, insert and delete is fast (O(1), hashing). I can't find a System.Collections interface that matches the operations naturally offered...
10
by: Brett | last post by:
I'm still trying to figure out concrete reasons to use one over the other. I understand the abstract class can have implementation in its methods and derived classes can only inherit one abstract...
6
by: John Salerno | last post by:
I understand how they work (basically), but I think maybe the examples I'm reading are too elementary to really show their value. Here's one from Programming C#: #region Using directives ...
12
by: Meya-awe | last post by:
I am puzzled, what is the purpose of an interface? How does it work, what i mean is how does the compiler treats this? Why when we talk about separating user interface from business logic, an...
4
by: Raja Chandrasekaran | last post by:
Hai friends, I really wonder, If the interface does not have any definition, Y do we need to use interface. You can then only we can use Multiple inheritance. I really cant understand, Just for...
52
by: Ben Voigt [C++ MVP] | last post by:
I get C:\Programming\LTM\devtools\UselessJunkForDissassembly\Class1.cs(360,27): error CS0535: 'UselessJunkForDissassembly.InvocableInternals' does not implement interface member...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.