Why Implementation?

[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

[Chad Z. Hower aka Kudzu]

"Jeff Bowman" <wr*********@my.addess.com> wrote in
news:eB**************@TK2MSFTNGP12.phx.gbl:

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.
Thats the contract.
instantiate it and use its members? Much more--I rarely even use
inheritance--seems like spaghetti code to me.

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/

[Chris Dunaway]

Jeff Bowman wrote:

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

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.

[Jon Skeet [C# MVP]]

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

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

Ouch - inheritance is vital to any OO design.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

Ouch - inheritance is vital to any OO design.

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.

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 - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d250fd1dbd282ff98c393
@msnews.microsoft.com:

I just don't think that every OO design requires inheritance of
implementation.

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/

[Jon Skeet [C# MVP]]

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d250fd1dbd282ff98c393
@msnews.microsoft.com:

I just don't think that every OO design requires inheritance of
implementation.

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. :(

Oh, I see - certainly every OO language/platform has to have
inheritance, yes - and every large framework is *likely* to include
some inheritance.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jeff Bowman]

Chris Dunaway wrote:

I presume you are referring to Interface Implementation.
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.

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.
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.
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.

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

[Chris Dunaway]

Jeff Bowman wrote:

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.
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.

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.

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om:

Oh, I see - certainly every OO language/platform has to have
inheritance, yes - and every large framework is *likely* to include
some inheritance.

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

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/

[Jeff Bowman]

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? ;-)

Chris Dunaway wrote:

Jeff Bowman wrote:

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.

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.

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.

[SeeSharper]

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!

*** Sent via Developersdex http://www.developersdex.com ***