LINQ Framework Design Guidelines

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?

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.)

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.