I love using generic collections in .Net. The main reason for this is because,
like most features of .Net, they significantly reduce the work I have to do in
architecting an application. Since collection classes always seem to be a theme
in my programming, I thought I would jot (or type) down a few thoughts I have on
collection classes.
One of the things I often do when creating a
collection class is to simply inherit from the List<> class of the type I
want to collection-ize.
For instance, suppose I'm writing an application
that needs a representation of a library (a book library, not a programmatic
library). In the library, there would probably be a class called "Book," that
would look something like this:
class
Book
{
public
string Title
{
///Getter and setter for
the title
}
public
Author BookAuthor
{
///Getter and setter for
the book author
}
public
void CheckoutBook()
{
///Perform behavior that
checks out a book
}
public
void CheckInBook()
{
///Perform behavior that
checks in a book
}
}
This
library would obviously need a representation for a collection of books. This
collection could be manifested in a number of ways. The lazy way would be to
simply create member variables within other classes that are of type
List<Book>. I've written enough code that concepts as important as this
should be represented by it's own class, so I would simply create a new class
that inherits from List<Book> like the following:
class
BookCollection : List<Book>
{
///Custom methods and attributes that
}
The
reason I would do the above is because, with its own class, I have more
flexibility moving forward with the use of a collection of books. One of the
flexibility features the above offers is the context a collection of books can
exist within; for instance, a collection of books could be any of the
following:
- All of the books in the library
- All of the books
a library visitor has checked out
- All of the overdue books in the
library
- All of the overdue books a library visitor has checked out
- All of the books a particular author has written
- All of the books written
in a particular month, year, decade, or century
- All of the books in a
particular genre
- etc
With the BookCollection class, I have the
option of representing any of the above collections as a simple book collection,
or by using more inheritance to represent each. For instance:
class LibraryOverdueBooks
: BookCollection
{
///particulars of all the library's overdue books
}
class LibraryVisitorOverdueBooks
: BookCollection
{
///particulars of a particular visitor's overdue books
}
Because this sort of collection hierarchy is so common in
programming, I felt inclined to write about it. Of course, there are lots of
ways to represent a collection, especially with the System.Data namespace, or
with Linq and its collection of IEnumerable flexibility. As the size of the
collection grows, it often makes sense to reevaluate how you are implementing
the collection, but in theory, the above is a simple, but effective way to
represent collections, and it's pretty common to find code like this in the code
I write.