lists and interfaces
tshad
class?
This is how I usually set up my list classes:
Racer.cs
***********************************************
public class Racer
{
private string name;
private string car;
public string Name { get { return name; } }
public string Car { get { return car; } }
public Racer(string name, string car)
{
this.name = name;
this.car = car;
}
public override string ToString()
{
return name + ", " + car;
}
}
public class RacerCollection : List<Racer> { }
***********************************************
But I have seen others add an interface to their lists like so:
IRacer.cs
*******************************************
public interface IRacer
{
string Name { get; }
string Car { get; }
}
*******************************************
Racer.cs
************************************************
public class Racer : IRacer
{
private string name;
private string car;
public string Name { get { return name; } }
public string Car { get { return car; } }
public Racer(string name, string car)
{
this.name = name;
this.car = car;
}
public override string ToString()
{
return name + ", " + car;
}
}
public class RacerCollection : List<IRacer> { }
************************************************
This works as well but I was curious as to why you would do it?
Seems like one more step that isn't necessary. There is no multiple
inheritance and multiple classes are not going to inherit it.
I did find (and can't remember where) that the List<IRacer> caused me a
problem somewhere when I tried to use it. And that was because it was
because it was a List of IRacer instead of a List of Racer.
Just curious.
Thanks,
tom
Peter Duniho
> [...]
> IRacer.cs
> *******************************************
> public interface IRacer
> {
> string Name { get; }
> string Car { get; }
> }
> *******************************************
>
> Racer.cs
> ************************************************
> public class Racer : IRacer
> {
> private string name;
> private string car;
> public string Name { get { return name; } }
> public string Car { get { return car; } }
>
> public Racer(string name, string car)
> {
> this.name = name;
> this.car = car;
> }
> public override string ToString()
> {
> return name + ", " + car;
> }
> }
> public class RacerCollection : List<IRacer> { }
> ************************************************
>
> This works as well but I was curious as to why you would do it?
I don't know. I wouldn't. I've never seen anyone suggest using an
interface just for the sake of doing so.
It's possible that in the example you saw, the author of the code had a
reason for wanting to simplify what was exposed. Maybe the list was going
to be public to some code that didn't or shouldn't have access to the
actual class, and for whatever reason it wasn't possible to simply
restrict the actual class's public API to accomplish the same thing.
Or maybe the author really did anticipate the possibility of multiple
classes implementing the specific interface and wanted to allow for that.
Or maybe it was in the context of a tutorial or other demonstration
scenario, and the interface was used simply to show how an interface can
be treated just like a regular class for the purpose of using in a generic
class. (You have to be careful looking at code samples, as they often
include arbitrary decisions made either solely for the purpose of making a
point, or to support some other part of the sample. You usually can't
look at a sample and learn the best approach for everything the sample
does...it's important to look at the sample in the context of whatever
topic is being addressed, to understand what in the sample is worth
emulating and what's not).
In any case, all of the above possible reasons involve issues that really
are solved by using interfaces. That is, it wouldn't be so much that
absent any other reason there's some reason to use an interface anyway.
It's that each of those possibilities represent a specific example of
something that couldn't be dealt with without an interface.
> Seems like one more step that isn't necessary. There is no multiple
> inheritance and multiple classes are not going to inherit it.
If you don't have a need for an interface, then I don't think you should
use one. I'm not aware of anything about interfaces as they contrast with
classes that would affect in any way how they might be used in a generic
List<> instance, or any other generic class for that matter. As the
List<> class itself is concerned, an interface looks pretty much like any
other type.
> I did find (and can't remember where) that the List<IRacer> caused me a
> problem somewhere when I tried to use it. And that was because it was
> because it was a List of IRacer instead of a List of Racer.
Well, I don't know why using an interface would cause a _problem_ per se,
assuming the interface duplicates the public API of the original class
exactly. Of course, if it doesn't and you find yourself needing some
public member of the original class, then you have to cast the list
element back to the original class. That could get annoying, especially
if you didn't really have a good reason to make an interface out of the
class in the first place.
Another problem you could wind up with would be trying to use a
List<IRacer> where a List<Racer> is expected, but that's an issue with
respect to any situation where one list is defined with a type that
inherits the type used to define another list. It's not unique to
interfaces, and it's always avoided in the same way: just define the lists
consistently.
Pete
tshad
I agree about sample code not being real world. But in this case, the code
I was looking wasn't sample code (mine was - just to show what I was talking
about).
I just wanted to see if I was missing anything. The code I saw was pretty
much the same as mine.
Thanks,
Tom
"Peter Duniho" <NpOeS...@nnowslpianmk.com> wrote in message
news:op.t67ty...@petes-computer.local...
sloan
The first time you hit an issue, where coding to an interface and not an
implementation (a single concrete class)....bails you out because you didnt'
screw yourself in the beginning by going "all concretes".......you'd
appreciate the payoff by implementing an interface up front.
........
One benefit of an interface is if you have multiple concretes implementing
it.
When you need to add a new method...and you start coding it up on one of the
concretes....if everything on the outside refers to it by interface..you'll
know quickly that 'oh yeah, i'm changing one concrete, i need to update the
interface as well'...and then you get the trickle down effect of not
forgetting to implement the same method in the 2nd, 3rd, Nth other concrete
class.
Even if in the 2nd, 3rd, Nth concrete all you do is "throw new Not
ImplementedException"...at least this is something you did so knowing about
it....
Download the code here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
ignore the WCF part of it ... and just look at the
IZebra
IZebraCollection
IZebraController
and the concretes of those as well.
I kinda hear ya on the "it'll always be just one concrete"...but software
dev is a discipline as well.
I really like right clicking on an interface ( like IAnimal ), going to the
definition and seeing a very clean contract of what it does.
Instead of a thousand lines of code...and having to pull the methods down
from the combbox.
People will argue either way. But when you care (really care) about
software maintenance...you tend to stick with IEverything.
(my experience at least)
I would suggest a book called the
Pragmatic Programmer as well.
and/or
Head First Design Patterns.
Those books really lay out...the "better road to software development".....
"tshad" <ts...@dslextreme.com> wrote in message
news:%23%239bbUbe...@TK2MSFTNGP04.phx.gbl...
tshad
> The first time you hit an issue, where coding to an interface and not
> an implementation (a single concrete class)....bails you out because
> you didnt' screw yourself in the beginning by going "all
> concretes".......you'd appreciate the payoff by implementing an
> interface up front.
> ........
>
> One benefit of an interface is if you have multiple concretes
> implementing it.
>
> When you need to add a new method...and you start coding it up on one
> of the concretes....if everything on the outside refers to it by
> interface..you'll know quickly that 'oh yeah, i'm changing one
> concrete, i need to update the interface as well'...and then you get
> the trickle down effect of not forgetting to implement the same
> method in the 2nd, 3rd, Nth other concrete class.
>
My question is in this case is it overkill.
In my application I have 6 different List<t> objects, such as the Racer
object, where I just have Properties, in them (as well as a ToString()
method so I can see what the object is in the debugger).
Each one is completely separate from the other so each would have its own
interface. The interface would never be used for another list class (in my
case).
Even if I add a sort method, it's not like I should put it in the Interface
to make sure it gets built in the object - I would build it in the object if
I decide to use it.
> Even if in the 2nd, 3rd, Nth concrete all you do is "throw new Not
> ImplementedException"...at least this is something you did so knowing
> about it....
>
> Download the code here:
> http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry
> ignore the WCF part of it ... and just look at the
> IZebra
> IZebraCollection
> IZebraController
>
> and the concretes of those as well.
>
> I kinda hear ya on the "it'll always be just one concrete"...but
> software dev is a discipline as well.
>
> I really like right clicking on an interface ( like IAnimal ), going
> to the definition and seeing a very clean contract of what it does.
> Instead of a thousand lines of code...and having to pull the methods
> down from the combbox.
>
> People will argue either way. But when you care (really care) about
> software maintenance...you tend to stick with IEverything.
> (my experience at least)
>
That may be true, which is why I was asking the question. To see what the
opinions are and Best Practices on it. I do know that "just because you can
doesn't mean you alway should...".
Thanks,
Tom