A
Andy B
For holding multiple objects, what is the better way to hold them? a
collection class or an array?
collection class or an array?
A
.\\\\axxx
It depends upone what the objects are, and what you are doing with
them.
A
.\\\\axxx
.... and what you mean by 'better way'
H
Howard Swope
A lot will depend on the use. A lot will depend on the collection class.
Some collection classes are just light wrappers around arrays, others
perform many more functions. My advice is if you have the clock cycles to
spare for a little abstraction, and it makes more sense in your system for
an instance of a collection class to be a participating object with its own
unique identity in the interaction of objects that make up your system, use
the collection. If the collection is used in an area of your code that is
very time critical think about using the array.
Some collection classes are just light wrappers around arrays, others
perform many more functions. My advice is if you have the clock cycles to
spare for a little abstraction, and it makes more sense in your system for
an instance of a collection class to be a participating object with its own
unique identity in the interaction of objects that make up your system, use
the collection. If the collection is used in an area of your code that is
very time critical think about using the array.
S
sloan
I prefer these days
public EmployeeCollection : List<Employee>
{
//yeah that's it.
}
I don't like List<Employee> all over the place.
And I'm future proofed if I ever need to put methods in ..specific to that
class.
public EmployeeCollection : List<Employee>
{
//yeah that's it.
}
I don't like List<Employee> all over the place.
And I'm future proofed if I ever need to put methods in ..specific to that
class.
J
Jon Skeet [C# MVP]
sloan said:
Can't say I'm keen on adding an extra layer of inheritance for no
reason.
Why not?
True. On the other hand, if you ever want to change to use a different
base collection, or just work with IEnumerable<Employee> (which is what
LINQ queries will return, for instance) you could end up with more work
to do.
M
Marc Gravell
Indeed - I very nearly replied with something similar; in particular, you
can't override any methods on List<T>. An option then would be to switch to
Collection<T>, but then any code that uses any of the List<T> goodies will
stop working. You might as well just accept the (usually nominal) cost of
changing the list backer in the (unikely) event that you need to change the
functionality.
Extension methods may have a role to play here too... first they could be
used to bridge the gap if switching from List<T> to Collection<T> created
too many compiler errors. Second - they could be used *instead of* an
EmployeeCollection - i.e. since you can't override anything in List<T>, the
only thing you can do is add methods...
so rather than:
class EmployeeCollection : List<Employee> {
void Foo(int value) {...}
}
You could equally have:
static class EmployeeListExt {
static void Foo(this IList<Employee> list, int value) {...}
// or if you have subclasses etc
static void Foo<T>(this IList<T> list, int value) wherer T : Employee
{...}
}
This then also works for Employee[], Collection<Employee>,
BindingList<Employee>, etc
I'm not saying it is necessarily the right approach, but it is another tool
in the toolbox.
Marc
can't override any methods on List<T>. An option then would be to switch to
Collection<T>, but then any code that uses any of the List<T> goodies will
stop working. You might as well just accept the (usually nominal) cost of
changing the list backer in the (unikely) event that you need to change the
functionality.
Extension methods may have a role to play here too... first they could be
used to bridge the gap if switching from List<T> to Collection<T> created
too many compiler errors. Second - they could be used *instead of* an
EmployeeCollection - i.e. since you can't override anything in List<T>, the
only thing you can do is add methods...
so rather than:
class EmployeeCollection : List<Employee> {
void Foo(int value) {...}
}
You could equally have:
static class EmployeeListExt {
static void Foo(this IList<Employee> list, int value) {...}
// or if you have subclasses etc
static void Foo<T>(this IList<T> list, int value) wherer T : Employee
{...}
}
This then also works for Employee[], Collection<Employee>,
BindingList<Employee>, etc
I'm not saying it is necessarily the right approach, but it is another tool
in the toolbox.
Marc
A
Andy B
It wouldn't make much sense to have different instances of the object laying
around everywhere. My root object is a Contract class. It has different
sections like Event, host, Venu, ContractSections, ContractDefinitions and
all of that stuff. Wouldn't make much sense to have all of those floating
around. I wanted the Contract to be 1 complete object. That way I could do
something like this:
Contract Contract = new Contract();
Contract.Definitions.Add("Word to be defined", "Definition of the word");
or something like that. I don't know how xsd deals with these sorts of
things, but I will find out soon...
around everywhere. My root object is a Contract class. It has different
sections like Event, host, Venu, ContractSections, ContractDefinitions and
all of that stuff. Wouldn't make much sense to have all of those floating
around. I wanted the Contract to be 1 complete object. That way I could do
something like this:
Contract Contract = new Contract();
Contract.Definitions.Add("Word to be defined", "Definition of the word");
or something like that. I don't know how xsd deals with these sorts of
things, but I will find out soon...
S
sloan
Well, I (and my colleagues) actually do this. The previous answer was my
pop-shot answer.
public interface IEmployeeCollection :
IList<IEmployee>, ICollection<IEmployee>,
IEnumerable<IEmployee>,
IEnumerable
{
}
and of course a concrete
public class EmployeeCollection : List<IEmployee>, IEmployeeCollection
{
}
Any critical evaluation of that is welcomed as well. ( That is a sincere
request, not a challenge or sarcastic remark ).
...
My linq skills are subpar right now. Too much going on at work.
pop-shot answer.
public interface IEmployeeCollection :
IList<IEmployee>, ICollection<IEmployee>,
IEnumerable<IEmployee>,
IEnumerable
{
}
and of course a concrete
public class EmployeeCollection : List<IEmployee>, IEmployeeCollection
{
}
Any critical evaluation of that is welcomed as well. ( That is a sincere
request, not a challenge or sarcastic remark ).
...
My linq skills are subpar right now. Too much going on at work.
M
Marc Gravell
Well, I (and my colleagues) actually do this.
Well, everything after IList<IEmployee> is implied anyway, so this
amounts to IList<IEmployee>, which I would argue is abstract enough,
without needing to name it IEmployeeCollection (although this does allow
you to add interface methods).
I guess it depends what you are trying to achieve. That provides neither
encapsulation (you can't change away from List<IEmployee> without
breaking calling code; even if it cmopiles it is a breaking change) nor
polmorphism (you can't override any useful List<T> methods).
So really, the question is: why? What is this intended to give you? If
it does what you need, then great! But all I am saying is that if the
useful bit is that it allows you to add extra methods, then there may be
other ways of doing that - which isn't to say that those "other" ways
are any better, either...
Marc
Well, everything after IList<IEmployee> is implied anyway, so this
amounts to IList<IEmployee>, which I would argue is abstract enough,
without needing to name it IEmployeeCollection (although this does allow
you to add interface methods).
I guess it depends what you are trying to achieve. That provides neither
encapsulation (you can't change away from List<IEmployee> without
breaking calling code; even if it cmopiles it is a breaking change) nor
polmorphism (you can't override any useful List<T> methods).
So really, the question is: why? What is this intended to give you? If
it does what you need, then great! But all I am saying is that if the
useful bit is that it allows you to add extra methods, then there may be
other ways of doing that - which isn't to say that those "other" ways
are any better, either...
Marc
J
Jon Skeet [C# MVP]
sloan said:
It just seems a little unnecessary to me. Where's the advantage over
just using a List<IEmployee>? Sure, occasionally you might want
particular behaviour - but often that will be generic behaviour whether
It's really, really worth finding out about.
S
sloan
That's guys. That is what I was looking for.
public interface IEmployeeCollection : IList<IEmployee>
{
}
was my first approach at it.
Then another developer came in and added the
ICollection<IEmployee>,
IEnumerable<IEmployee>,
IEnumerable
parts.
So I was trying to get some advice ... without going into the whole history.
I should have seen it from the start.
...
LINQ
Yeah, I know. I was going to hit Silverlight 2.0 first, then LINQ. Brad
Abrams is coming to our usergroup meeting next week.
I'll be catching up on stuff starting in May, when my work stuff slows down
considerably.
...
Jon, I just got the Manning Publications email last night that the final
release is out.
Congrats!
public interface IEmployeeCollection : IList<IEmployee>
{
}
was my first approach at it.
Then another developer came in and added the
ICollection<IEmployee>,
IEnumerable<IEmployee>,
IEnumerable
parts.
So I was trying to get some advice ... without going into the whole history.
I should have seen it from the start.
...
LINQ
Yeah, I know. I was going to hit Silverlight 2.0 first, then LINQ. Brad
Abrams is coming to our usergroup meeting next week.
I'll be catching up on stuff starting in May, when my work stuff slows down
considerably.
...
Jon, I just got the Manning Publications email last night that the final
release is out.
Congrats!
J
Jon Skeet [C# MVP]
sloan said:
Yup, Silverlight 2 is worth looking at too - it's on my list... LINQ is
applicable in more places though
Have fun with Brad - should be a blast.
Cheers - don't forget to leave an Amazon Review (when the hard copy is
out)
I
Ignacio Machin ( .NET/ C# MVP )
Why create an empty class for any type you have?
IMHO this is that the generics are avoiding in the first place!!!
And what is wrong with List<T> unless T is a VERY long name it's as
readeable as your solution.
And talking about the future, well you have extension methods that
will most likely solve your issues with extending the collection