A Thought On Collections

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<>. 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 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:
1. All of the books in the library
2. All of the books a library visitor has checked out
3. All of the overdue books in the library
4. All of the overdue books a library visitor has checked out
5. All of the books a particular author has written
6. All of the books written in a particular month, year, decade, or century
7. All of the books in a particular genre
8. 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.