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" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):
> 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/

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.

Chad Z. Hower aka Kudzu <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jon Skeet [C# MVP] <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jon Skeet [C# MVP] <(E-Mail Removed)> 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/

Chad Z. Hower aka Kudzu <(E-Mail Removed)> wrote:
> Jon Skeet [C# MVP] <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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

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.

Jon Skeet [C# MVP] <(E-Mail Removed)> wrote in
news:(E-Mail Removed):
> 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/