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