List Class

  • Thread starter Thread starter Joe Cool
  • Start date Start date
J

Joe Cool

Is there any real difference between the following two ways to
implement a class that represents a list of objects? Is there any
reason to use one technique over the other?

class myObjects
{
public List<object> Objects { get; set; }
}

class myObjects : List<object>
{
}
 
Is there any real difference between the following two ways to
implement a class that represents a list of objects? Is there any
reason to use one technique over the other?

class myObjects
{
public List<object> Objects { get; set; }
}
Click to expand...

With this class, you must do this:

foreach(object item in someInstanceOfMyClass.Objects)
{
//
}
class myObjects : List<object>
{
}
Click to expand...

Whereas with this class you can do this:

foreach(object item in someInstanceOfMyClass)
{
//
}

I consider the second one more elegant. Plus you can also assign it to
variables that are defined as List<object>, which would support polymorhpism
if you had other classes which also derive from List<object>.

Of course the real problem with both implementations is that you have named
a class starting with a lower-case letter. YUCK!!
 
Jeff said:
With this class, you must do this:

foreach(object item in someInstanceOfMyClass.Objects)
{
//
}


Whereas with this class you can do this:

foreach(object item in someInstanceOfMyClass)
{
//
}

I consider the second one more elegant. Plus you can also assign it to
variables that are defined as List<object>, which would support
polymorhpism if you had other classes which also derive from
List<object>.
Click to expand...

You can have that syntax, and polymorphics reusability under LSP, by
implementing IList on your class. Because .NET doesn't support multiple
inheritance, interfaces are usually used for this sort of thing and not
class derivation.

Also, by implementing the interface yourself and delegating to a contained
object, you can perform additional checking. If you use (public)
inheritance of the class, you cannot restrict your callers from using the
entire set of operations available.

And of course with "sealed" classes, inheritance is not an option at all.
 
Is there any real difference between the following two ways to
implement a class that represents a list of objects? Is there any
reason to use one technique over the other?

class myObjects
{
public List<object> Objects { get; set; }
}

class myObjects : List<object>
{
}
Click to expand...

Other replies have covered the mechanics, but I'll offer my comments with
respect to preferring one or the other.

Unless you class _is_ a list, making it inherit List<object> is wrong. If
it _is_ a list, then inheriting List<object> is fine, but the rest of the
class had better be only list-like. Otherwise, you've got a serious class
design problem.

The syntax used to enumerate the elements in the list is the least of the
concerns with respect to how to design the class. The real question is
what the class actually is, and is supposed to represent. If it's not
actually a list, it's got no business inheriting List<object>.

Pete
 
Other replies have covered the mechanics, but I'll offer my comments with 
respect to preferring one or the other.

Unless you class _is_ a list, making it inherit List<object> is wrong.  If  
it _is_ a list, then inheriting List<object> is fine, but the rest of the 
class had better be only list-like.  Otherwise, you've got a serious class  
design problem.

The syntax used to enumerate the elements in the list is the least of the 
concerns with respect to how to design the class.  The real question is 
what the class actually is, and is supposed to represent.  If it's not  
actually a list, it's got no business inheriting List<object>.
Click to expand...

Yes, the sole purpose of the class is to be a list of objects.
 
Back
Top