Why Implementation?

  • Thread starter Thread starter Jeff Bowman
  • Start date Start date
J

Jeff Bowman

If there weren't a real strong reason for having it, Microsoft wouldn't have
bothered with including Implementation in the language. But doggone it, I'll be
darned if I can see what's so great about it. For starters, you've got to make
sure all the implemented members are present, whether you're going to use them
or not. That's cumbersome enough all by itself.

Why not just keep things nice and simple--build a class, and then instantiate it
and use its members? Much more--I rarely even use inheritance--seems like
spaghetti code to me.

But then again, my brain tends to get wrapped in a fog from time to time. If I'm
causing myself to miss out on something that'd improve my general approach, I'd
sure like to know about it.

So there's the question, I guess--Why Implementation?

TIA,
Jeff
 
Jeff Bowman said:
For starters, you've got to make sure all the implemented members are
present, whether you're going to use them or not. That's cumbersome
enough all by itself.
Click to expand...

Thats the contract.
instantiate it and use its members? Much more--I rarely even use
inheritance--seems like spaghetti code to me.
Click to expand...

Ouch - inheritance is vital to any OO design.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Make your ASP.NET applications run faster
http://www.atozed.com/IntraWeb/
 
Jeff said:
If there weren't a real strong reason for having it, Microsoft wouldn't have
bothered with including Implementation in the language. But doggone it, I'll be
darned if I can see what's so great about it. For starters, you've got to make
Click to expand...

I presume you are referring to Interface Implementation. Consider
Adobe Photoshop. It has a menu of available plugins that each
manipulate the image in some way. These plugins, however, are not
necessarily written by Adobe. They could be written by third parties.
When PS loads the plugin, it has no idea of how the plugin is
implemented. It only knows that the plugins support a particular set
of methods (read: interface).

For the plugin designer, he doesn't have to know anything about how
Adobe calls the methods. So long as he follows the contract, he knows
his plugin will work with PS.

Conside Microsoft's own ADO.Net. It provides an IDbConnection
interface. Various backends can be created that implement this
interface. For example the SQLConnection object implements the
interface. Oracle has a connection object that also implements this
interface.

The application designer only needs to code to the interface and in
doing so, the backend database can be changed without having to
recompile his code.

These are simple examples but I think that they help show the value of
interface programming.
 
Chad Z. Hower aka Kudzu said:
Ouch - inheritance is vital to any OO design.
Click to expand...

I disagree with that pretty strongly. I tend to aggregate rather than
using inheritance. It's useful occasionally, and where it *is* useful
it's absolutely invaluable. However, writing classes which should be
inherited from - especially outside your own assembly - requires a lot
more work to do it properly, and your implementation can end up being a
lot less flexible, as you need to stick to the same rules about which
method calls which other method etc.

There's a good article about this somewhere - I wish I could find it...
 
Jon Skeet said:
I disagree with that pretty strongly. I tend to aggregate rather than
using inheritance. It's useful occasionally, and where it *is* useful
it's absolutely invaluable. However, writing classes which should be
inherited from - especially outside your own assembly - requires a lot
more work to do it properly, and your implementation can end up being a
lot less flexible, as you need to stick to the same rules about which
method calls which other method etc.
Click to expand...

Just to clarify this somewhat - I'm talking about inheritance of
implementation here, not interface. Using interfaces is a different
matter, and something which is *very* handy when it comes to AOP, using
mock objects etc.

I just don't think that every OO design requires inheritance of
implementation.
 
Jon Skeet said:
I just don't think that every OO design requires inheritance of
implementation.
Click to expand...

Neither do I - when I said "design" I meant as into C#, the CLS, etc. Imagine building the FCL without
inheritance, only interfaces. Oh wait we had that, it was called COM. :(


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Develop ASP.NET applications easier and in less time:
http://www.atozed.com/IntraWeb/
 
Chad Z. Hower aka Kudzu said:
Neither do I - when I said "design" I meant as into C#, the CLS, etc.
Imagine building the FCL without inheritance, only interfaces. Oh
wait we had that, it was called COM. :(
Click to expand...

Oh, I see - certainly every OO language/platform has to have
inheritance, yes - and every large framework is *likely* to include
some inheritance.
 
Chris said:
I presume you are referring to Interface Implementation.
Click to expand...

Yes. Pardon me for not clarifying.


Consider
Adobe Photoshop. It has a menu of available plugins that each
manipulate the image in some way. These plugins, however, are not
necessarily written by Adobe. They could be written by third parties.
When PS loads the plugin, it has no idea of how the plugin is
implemented. It only knows that the plugins support a particular set
of methods (read: interface).

For the plugin designer, he doesn't have to know anything about how
Adobe calls the methods. So long as he follows the contract, he knows
his plugin will work with PS.
Click to expand...

OK, that makes sense... so far...


Conside Microsoft's own ADO.Net. It provides an IDbConnection
interface. Various backends can be created that implement this
interface. For example the SQLConnection object implements the
interface. Oracle has a connection object that also implements this
interface.
Click to expand...

But--as I understand it--the actual functioning code exists in the members of
the implementing class and not the interface. Thus it seems the same as just
building a standalone class, but with additional complexity.


The application designer only needs to code to the interface and in
doing so, the backend database can be changed without having to
recompile his code.
Click to expand...

Yes, I've heard that said before: "Code to interface, not implementation." But
again, if all the coding must be done in the down-level class, what's the point?
There doesn't seem to be any common code base, such as there can be with
inheritance.


These are simple examples but I think that they help show the value of
interface programming.
Click to expand...

Please don't misunderstand my resistance--I WANT to know these things. I'm
rebutting only because I want to make sure the concept passes my personal tests.
I'm sure it will, and with flying colors, but at the same time I need full
comprehension.

Would you happen to know of some code I might look at wherein Interface
Implementation is NOT employed, and could be, and whose architecture thereby
suffers for it?

Thanks,
Jeff
 
Jeff said:
But--as I understand it--the actual functioning code exists in the members of
the implementing class and not the interface. Thus it seems the same as just
building a standalone class, but with additional complexity.
Click to expand...

If you built a standalone class, the code that calls it will have to
reference that class and it then would not work with other classes,
even if they had the same method names, because they would be different
types.
Yes, I've heard that said before: "Code to interface, not implementation." But
again, if all the coding must be done in the down-level class, what's the point?
There doesn't seem to be any common code base, such as there can be with
inheritance.
Click to expand...

I think inheritance implies that the derived classes can change or
extend the behavior of the base class. When implementing an interface
there is a contract which must be adhered to.
 
OK, gotcha! That clears it up a lot, thanks. The next step, of course, is to
start fiddling around with it.

Maybe I should've done that before I opened my trap, think? ;-)
 
Funny, I googled for "interface+what's+the+point+c# and this thread came
up. Thanks for the great clarification. Let me see if I got the gist.

The creation of an interface is not so much to make your own life easier
as inheritance does in desigining a custom application. But it's more
for facilitating an outside customer or client who is using a library
you created.

It makes perfect sense now. Thanks again!
 
Back
Top