2

I have a project which loads from database a XML file which defines a form for some user. XML is transformed into a collection of objects whose classes derive from single parent. Something like

Control -> EditControl -> TextBox

Control -> ContainterControl -> Panel

Those classes are responsible for creation of GUI controls for three different enviroments: WinForms, DevExpress XtraReports and WebForms. All three frameworks share mostly the same control tree and have a common single parent (Windows.Forms.Control, XrControl and WebControl).

So, how to do it?

Solution a) Control class has abstract methods

Control CreateWinControl();
XrControl CreateXtraControl();
WebControl CreateWebControl();

This could work but the project has to reference all three frameworks and the classes are going to be fat with methods which would support all three implementations.

Solution b) Each framework implementation is done in separate projects and have the exact class tree like the Core project. All three implementations are connected using a interface to the Core class.

This seems clean but I'm having a hard time wrapping my head around it. Does anyone have a simpler solution or a suggestion how should I approach this task?

1

If you have a tree of objects (and I do mean tree of objects, not tree of classes) of various types that you want to process in different ways, then the common approach is to use the visitor pattern.

How would that look in your case? Your common project would contain an abstract class ControlTreeVisitor, which would look something like this (simplified by assuming there is no ContainterControl or EditControl):

public abstract class ControlTreeVisitor
{
    protected virtual void VisitControl(Control control)
    {
        // dispatch to the appropriate Visit* method
    }

    protected virtual void VisitPanel(Panel panel)
    {
        foreach (var childControl in panel.Children)
        {
            VisitControl(childControl);
        }
    }

    protected virtual void VisitTextBox(TextBox textBox)
    {
        // do nothing
    }
}

Each GUI-specific project would then contain a concrete class that would inherit from this visitor class and would override all the Visit* methods to create the appropriate control tree for the given GUI library.

There are some possible alternatives in the design of the visitor base class. For example, one variation would be to make it generic, where the type parameter would represent the base class in the specific GUI library (e.g. class WebControlVisitor : ControlTreeVisitor<WebControl>). All Visit* methods would then return this type. This would make creating a tree of WebControls simpler.

  • Thanks. I'll try with a visitor pattern. Basically, visitor looks perfect for myriad of conversions I'll have. Control->(Win, Xtra, Web), Control->XML, XML->Control, Designer->Control, Control->Designer, etc... – Nezreli Oct 23 '13 at 9:10
1

Solution (b) is the way to go. Define interfaces for the various controls:

public interface EditControl
{
  //...
}

public interface ContainerControl
{
  //...
}

and an interface for a factory:

public interface ControlFactory
{
  EditControl CreateEditControl(...);
  ContainerControl CreateContainerControl(...);
  //...
}

Each of the packages will then implement this set of interfaces; in particular, each package knows how to implement the ControlFactory interface by creating its own flavour of the controls.

  • 1
    The .Net naming conventions say that names of interfaces should start with I. – svick Oct 22 '13 at 17:33
  • Ah... I can't stand (bad) Hungarian notation, so I'm not using that convention. I agree with the guys who wrote amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/… - whether a type is an interface or a class is an implementation detail. From the point of view of the consumer, all I care about is that I have an instance of a ControlFactory and it can give me an EditControl. – Marcel Popescu Oct 22 '13 at 20:05
  • Ok, I can understand that. But the cost of you doing that is that your code is confusing and inconsistent with every other piece of .Net code out here. I don't think that's a good trade-off. Especially when it's code that you're posting publicly. – svick Oct 22 '13 at 23:22
  • Thanks. I'll try the visitor pattern mentioned above but will incorporate interfaces to the concrete control classes which I'll use to communicate form Control to Win, Xtra or Web controls. – Nezreli Oct 23 '13 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.