LINQ Framework Design Guidelines

Posted by Jonathan Allen on Mar 13, 2008

Sections

Operations & Infrastructure,

Process & Practices,

Development,

Architecture & Design

Topics

.NET ,

Data Access ,

Delivering Quality

Tags

LINQ

Now that LINQ has been finalized and released, it is time to start thinking about the ways to use it. Keith Farmer even talks about using it eliminate subclasses. But before we get into that, let us take a look at the official guidance from Microsoft.

In the spirit of the Framework Design Guidelines, Microsoft has released guidelines for building frameworks based on LINQ. The LINQ Framework Design Guidelines covers topics such as API design and behavior. Unlike the coding guidelines found in many companies, these don't cover trivialities such as naming patterns and formatting, except where they touch a libraries public API.

Most of the original Framework Design Guidelines eventually found their way into FxCOP, the code analysis tool used both within Microsoft and without for ensuring consistency.

After the introduction, the document covers Extension Methods and the generic delegates Func, Action, and Expression. Amongst the standard warnings about overusing extension methods when normal methods would do, there is a not about namespace collisions. When two libraries expose extension methods on the same type, method name collisions may occur. If this occurs, only one of the two libraries may be imported and the other will have to be referenced using its full name.

In the section on extending LINQ, there is a helpful note about naming generic types. Generic types named T always refer to items, while types named S refer to collections of said items. While this is not enforced, it should at least make it easier to read the built-in methods.

On the performance side, there is a note saying that implementing ICollection helps when performing actions that involve the count. When you only implement IEnumerable, it has to walk the entire collection to get the count.

Now back to Keith Farmer and avoiding subclassing:

One thing I've been considering is reducing classes to their basics: pretty much just properties, methods directly relevant to those properties, and constructors and convertors.

Then use extension methods to define operations that are, pretty much, not required to mantain the concept of the class as an entity in itself, and where it doesn't make sense to create a subtype (if a subtype is even possible).

For example, a Node exists just fine without knowing about operations over Graph, and arguably Graph need not have any knowledge about IsNetworkRouter.

In that case, something like Traverse(GraphLink) would be a great method method on Graph, but something like FindLeastWorkRoute(Node, Node), which depends on implementation details of the particular subtype of GraphLink (ie, it has an associated Work metric) would best be an extension method in my mind.

This is a way to avoid creating custom subtypes just to implement application-specific logic, and thereby cluttering up the interesting classes (eg, Graph, rather than both Graph and GraphLink).

Does this make sense in the context of .NET programming? And does it abide by the design principals from Microsoft? Or for that matter, how much to those guidelines matter?

1. Back to top

   back to Keith Farmer?!?

   by Keith Farmer

   Please don't interpret my comments as meaning subclasses shouldn't exist. Just consider them as an experiment in not making gratuitous subclasses. IE, how can I make simpler APIs, which contain only those methods and types that I care about?
   
   IMHO, the guidelines do matter, inasmuch as they *are* guidelines that everybody can point to, with a variety of experienced people contributing to them. But they are still just guidelines -- of course you're free to do what makes the most sense in your own work.
   
   (And, of course, nothing I say represents my employer, nor even those who came up with the FDGs. I think I've been in the same room before, but that's it.)

   Reply

2. Back to top

   Re: back to Keith Farmer?!?

   by Jonathan Allen

   My apologizes sir. I didn't mean to mis-represent you, but rather use your ideas to continue the ongoing debate on whether or subclasses are overused and what the alternatives are.

   Reply

3. Back to top

   Re: back to Keith Farmer?!?

   by Keith Farmer

   No worries.. Just don't want people to think my thoughts are more than they really are or something silly like that. :)

   Reply

• Older >