Question

I’m having issues on how to seperate property values and their accessors. I have some electronic instruments encapsulated into classes. Some wrap a DLL which was provided by the manufacturer to handle communications.

A simple example:

public class Instrument
{
    private ManufacturerDLL.Instrument _instrument;

    public Instrument()
    {
        _instrument = new ManufacturerDLL.Instrument;
    }
    public float SomeSetting
    {
        get
        {
            return _instrument.SomeSetting;       
        }
        set
        {
            _instrument.SomeSetting = value;
        }
    }
}

Once connected, I can edit the properties with a propertygrid. I want to use serialization to not only save/restore the settings to a file, but also edit the settings with the device offline. With the implementation above, exceptions will throw if the device is not connected. I could add private fields as a middle man and if statements to check for connection status. But I have a lot of properties and hope there is a better way.

Is there an easy method to construct an ‘abstract’ version of an object? I basically want a clone but replace the original accessors logic with private fields. I know I can use GetMembers, but where to go from there?

Answer 1

You have several possibilities, so you’ll have to decide based on your specific situation which seems most feasible.

Separate:
As in Marc Gravell’s answer, you could separate your model entirely from the manufacturer’s and use an external parser which handles desired transactions by doing specific calls. I would only use this approach if you can’t imagine an abstraction layer to work with on top of the original DLLs.

Decorator:
Since you want to add behavior to a given library (check for connection), the first thing that comes to mind is using the decorator pattern. This basically comes down to what you were implying in the first place; wrapping the entire DLL and implement extra intermediate logic where necessary. Since you write the decorator manually, there are plenty of API changes you can do in order to suit it to your needs.

Proxy:
Based on how varied this intermediate logic you want to implement is, you could consider using a proxy pattern. E.g. when all you want to do is expose the original properties, and add the same extra behavior for every property. When the Instrument classes of the manufacturer implement interfaces, you could generate a class which implements this interface at run time, and redirects the calls to the actual DLL of the manufacturer. This isn’t easy, but there are a few libraries which can help you do just that. Castle DynamicProxy, or more low-level RunSharp. Only consider walking this path when you can reap the benefits of it. E.g. when you are supposed to wrap a big library, or a library which changes often over time.

When all you have to do is wrap 20 properties, I suggest you go for the decorator approach. When you have some spare time on your hands it might still be interesting to have some fun with run time code generation and attempting to generate a proxy.

I can give you an example of a run time generated proxy created by using RunSharp, just to give you a feel of whether it is something you would like to attempt. The CreateGenericInterfaceWrapper<T>() function wraps any interface with a ‘less generic’ interface, generating casts where needed.