Sorting by various fields

[Quake2Player]

Hi, What would be the best solution for this? Suppose I have a list of messages.. each message haves date, from, to, etc. I would like to allow to sort by any of these fields.. Should I make my own MessageCollection class? or inherite from List<T> ..or ..? I guess there are a lot of solutions but I would like to know which one is the most used for this problem (which I'm sure it must be a common problem) Sorry bad english

[Christian Graus]

Make a message class and create function objects to use with the Sort method on List<T> to sort the different ways

Quake2Player wrote:

Sorry bad english

Actually, Englsih was fine, and either way, bad English is one thing no-one should ever punish you for, on an international forum.

Christian Graus Driven to the arms of OSX by Vista. "! i don't exactly like or do programming and it only gives me a headache." - spotted in VB forums. I can do things with my brain that I can't even google. I can flex the front part of my brain instantly anytime I want. It can be exhausting and it even causes me vision problems for some reason. - CaptainSeeSharp

[dojohansen]

There are, as you say, many solutions to this. As always it comes down to making the right tradeoffs (between encapsulation, performance, coding effort, ...) and there is really no single answer that is "the best way" for all scenarios. As long as the field types are IComparable you could implement a "ListSorter" class that could sort any List<T> by any field using reflection. This would require relatively little code and the great benefit is that you do it once and then sort whatever object types you want to. The downside is that it's slow, but that may not be a problem if the collections are small. An interesting possibility is to build on this approach by making a ListSorterFactory class instead; this could use reflection to dynamically generate a ListSorter class for a specific type. It may sound like a very advanced sort of thing, but .NET has actually made this kind of thing relatively easy to do. If you have just one type of collection (and don't mind that this code won't be reusable anytime in the future - a sorter factory is potentially useful in many projects down the line) you can always go for inheriting from List<T> and add sort methods using the built-in Sort function with a predicate that compares the particular field the method sorts by. Since this requires the least code, I'll provide an example, but personally I think the ListSorterFactory is a rather more interesting idea!

public class Item
{
public int Number;
public DateTime Time;
public string Message;
}

public class ItemCollection : List<Item>
{
public void SortByNumber()
{
Sort((Item a, Item b) => a.Number.CompareTo(b.Number));
}

public void SortByTime()
{
    Sort((Item a, Item b) => a.Time.CompareTo(b.Time));
}

public void SortByMessage()
{
    Sort((Item a, Item b) => a.Message.CompareTo(b.Message));
}

}

However, since the pattern of this code is so regular, why not just generate it instead of writing it manually? Using reflection you can easily find all public fields or properties (or non-public if that's of interest, though you shouldn't do this with private members in any case!) and generating the code is then completely straightforward. And now I realize that dynamically compiling such generated code may not be so meaningful, because you've got no obvious way to *use* that generated code in your non-generated code! (If there was a single interface with many implementations generated code would do the t