Question

I have a concept for a framework of controls that I would like to build. What makes this idea different is that I do not intend to take the “one size fits all” approach or the “one control to rule them all” approach.

As an example, Telerik makes a very nice Grid control, as does ComponentOne, Xceed, etc.. However, they are all gigantic controls with hundreds or thousands of methods and properties, complex object model hiearchies, etc… All too often these grids are way overkill for what you need, but you still have to take on the herculean task of learning the entire grid to do something simple.

My concept is more of an “mix-in” aproach. Where you create a very simple control, and then build features that you can “add-in” to the control a la carte. For example, you have a simple grid, and you want to add grid “sections” with headers and footers for each.

Ok, so where’s the problem? The traditional way of doing something like this is via multiple inheritance, which C# does not support. Even if it did support it, I’m still of the opinion that MI adds more problems than it solves.

So I’m soliciting SO for opinions on how to approach this problem. Would MEF be a potential solution?

EDIT:

Something that occurs to me is that it could be possible to use expression trees to build the control from various expressions. I’d have to think through this some more, but it’s an interesting concept.

Another possible option might be a “Control Generator” that generates an assembly based on a the selected features. That seems more complex, but with T4 might be managable.

Answer 1

A few options

1. Consider the Decorator pattern; small objects that extend behavior of a fairly minimalist class that you can build up at runtime. The canonical example in the Dotnet framework would be around the IO streams (e.g. StreamReader/Writer, TextStreamReader/Writer, FileStreamReader/Writer); it’s fairly common also in OO UI frameworks, with the typical example looking something like var window=new HorizontalScrollingWindowDecorator(new VerticalScrollingWindowDecorator(new Window));

2. The State, Strategy, Command, and Composite patterns offer various alternatives for dealing with composition of behavior without requiring lots of control flow. For example, you delegate certain types of behavior to the current State of your object (some of your class methods basically call methods of the current object State). You can also delegate behavior to command objects, or build up complex commands using composite commands. Single inheritance generally leads you to favor composition of objects over inheritance, and these are all classic patterns for composing behavior that work well with single-inheritance.

3. You can use delegates for the “hole in the middle” pattern that’s commonplace in functional programming, when some small piece of behavior needs to be implemented by a particular instance.

4. You can use PostSharp or a similar aspect-oriented programming tool to do runtime or compile-time weaving of behavior, especially useful for cases when behavior needed by several different classes that doesn’t have much to do with the primary responsibility of that class.