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
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?