ILoggable

A place to keep my thoughts on programming

 Subscribe

Contact me

geekblog
[at]
claassen [dot] net

My Other Blogs

My Projects

Previous Posts

Powered by Blogger

Wednesday, November 28, 2007

Searching a Tree of Objects with Linq

I've finally had legitimate use for LINQ to Objects, not just to make the syntax cleaner, but also to simplify the underlying code and provide me a lot of flexibility without significant work.

The scenario

I have a tree of objects that have both a type and a name. The name is unique, the Type is not. The interface is this: 

public interface INode
{
  int Id { get; }
  string Name { get; set; }
  string Type { get; set; }
  List<INode> Children { get; }
}

I want to be able to find a single named Node in the tree and I want to be able to retrieve a collection of all nodes for a particular type. The searchable interface could be expressed as this: 

public interface ISearchableNode : INode
{
  INode FindByName(string name);
  IEnumerable<INode> FindByType(string name);
}
Both require me to walk the tree and examine each node, so clearly I just want to have one walk routine and generically evaluate the node in question. In C# 2.0 parlance, that means I could pass an anonymous delegate into my generic find routine and have it recursively iterate through all the children. I also pass along a resultset to be populated.

The signature for the evaluation delegate looks like this: 

delegate bool FindDelegate(INode node);
but since I'm using C# 3.0 (i.e. .NET 3.5) I can use lambda expressions to avoid creating a delegate and simplify my syntax. Instead of FindDelegate, I can simply use Func<INode,bool>: 
// Instead of this:
private void Find(INode node, List<INode> resultSet, FindDelegate findDelegate);
// called like this for a Name search:
Find(this, resultSet, delegate(INode node) { return node.Name == name; });

// I can use this:
private void Find(INode node, List<INode> resultSet, Func<INode, bool> f)
// called like this:
Find(this, resultSet, node => node.Name == name);

Thus giving me the following implementation for ISearchableNode: 

public INode FindByName(string name)
{
  List<INode> resultSet = new List<INode>();
  Find(this, resultSet, x => x.Name == name);
  return resultSet.FirstOrDefault();
}

public IEnumerable<INode> FindByType(string type)
{
  List<INode> resultSet = new List<INode>();
  Find(this, resultSet, x => x.Type == type);
  return (IEnumerable<INode>)resultSet;
}

private void Find(INode node, List<INode> resultSet, Func<INode, bool> f)
{
  if (f(node))
  {
    resultSet.Add(node);
  }
  foreach (INode child in node.Children)
  {
    Find(child, resultSet, f);
  }
}

Problem solved, move on... Well, except there is significant room for improvement. Here are the two main issues that ought to be resolved:

  1. Syntax is limited to two types of searches and exposing the generic find makes for an ugly syntax. It would be much nicer if queries to the tree could be expressed in LINQ syntax.
  2. It's also inefficient for the Name search, since I'm walking the entire tree, even if the first node matched the criteria.

LINQ to Hierarchical Data

In order to use LINQ to objects, I need to either create a custom query provider or implement IEnumerable. The latter is significantly simpler and could be expressed using the following interface: 

public interface IQueryableNode : IEnumerable<INode>
{
}
Ok, ok, I don't even need an interface, I could just implement IEnumerable<INode>... But what does that actually mean? In the simplest sense, I'm iterating over the node's children, however, I also with do descend into the children's children and so on. So a simple foreach won't do. I could just do the same tree walking with a resultset as I did above and return the Enumerator of the resulting list to implement the interface, but C# 2.0 introduced a much more useful way to implement non-linear Iterators, i.e. the yield keyword. Instead of building a list to be interated over, yield let's the iterating code return values as they are found, which means it can be used for recursive iteration. Thus the GetEnumerator is implemented simply as follows 
#region IEnumerable<Node> Members
public IEnumerator<INode> GetEnumerator()
{
  yield return this;
  foreach (Node child in Children)
  {
    foreach (Node subchild in child)
    {
      yield return subchild;
    }
  }
}
#endregion

#region IEnumerable Members
System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
{
  return this.GetEnumerator();
}
#endregion
Nice and simple and ready for LINQ.

Searching for all Nodes of a type becomes 

var allBar = from n in x
                where n.Type == "bar"
                select n;
foreach (Node n in allBar)
{
  // do something with that node
}
and the search for a specifically named node becomes 
INode node = (from n in x
              where n.Name == "i"
              select n).FirstOrDefault();
But the real benefit of this approach is that I don't have hard-coded search methods, but can express much more complex queries in a very natural syntax without any extra code on the Node.

Deferred execution

As it turns out, using yield for the recursive iteration also solved the second issue. As yield returns values as it encounters them during iteration, the search doesn't happen until the query is executed. And one of the side effects of LINQ syntax is that creating a query does not execute it until the result set is iterated over. Therefore, FirstOrDefault() actually short-circuits the query as soon as the first match (and in case of Name, it's going to be the only match) is hit.

Labels: , , , , ,

posted by ether @ 11:22 AM

5 Comments:

At 8:43 AM, Anonymous Anonymous said...

Great stuff !!!! Exactly what I looked for.

 
At 11:15 AM, Anonymous Mike B said...

This looks like exactly what I need. But when I use it I notice that LINQ never seems to call the iterator. For example, I have a List of objects that each have a Children property, which is also a List. When I use LINQ to query the main List, it only looks at the parent level of ther objects. It never iterates through the children. Any ideas?

Thanks,
Mike

 
At 11:26 AM, Blogger ether said...

LINQ won't traverse the hierarchy automatically. I.e. if you have have your children as regular lists, then it will only stay at that level. That's where the custom IEnumerable<INode> comes in and the GetEnumerator does the hierarchical dive.

So you're node can still have it's children as a list, but needs to implement IEnumerable<INode> and provide a custom enumerator that can dive into the children recursively.

 
At 11:43 AM, Anonymous Mike B said...

Thanks ether.

I may have misunderstood, but I'm suppose to have my base object ("node") implement IEnumerable right?

Here is an example of what I am trying (please excuse my use of []. I am just trying to get blogger to accept the comment):

MyObject mo =
(from item in items
where (item.ID == 22)
select item).FirstOrDefault();

Where items is a list of nested MyObjects.



Assuming this as my class definition:


public class MyObject : IEnumerable[MyObject]
{

int id = 0;
List[MyObject] children = new List[MyObject]();
int ID
{
get { return id; }
set { id = value; }
}

List[MyObject] Children
{
get { return children; }
set { children = value; }
}

public IEnumerator[MyObject]GetEnumerator()
{
yield return this;
foreach (MyObject child in Children)
{
foreach (MyObject subchild in child)
{
yield return subchild;
}
}
}

IEnumerator IEnumerable.GetEnumerator()
{
return this.GetEnumerator();
}
}

 
At 6:04 AM, Anonymous Mike B said...

ether,
Thanks again for your help. I solved my problem using something similar. I just used an extension method that took the list and the "property" to descend by and recursed the tree. Very similar to:
http://mutable.net/blog/archive/2008/05/23/using-linq-to-objects-for-recursion.aspx

Thanks again for the informative post.

 

Post a Comment

<< Home