Architecture Design for DataInterface - remove switch on type

Question

I am developing a project that calculates various factors for a configuration of components. The configuration is set/changed by the user at runtime. I have a Component base class and all configuration items are derived from it.

The information for each component is retrieved from data storage as and when it is required. So that the storage medium can change I have written a DataInterface class to act as an intermediary.

Currently the storage medium is an Access Database. The DataInterface class thus opens the database and creates query strings to extract the relevant data. The query string will be different for each component.

The problem I have is designing how the call to GetData is made between the component class and the DataInterface class. My solutions have evolved as follows:

1) DataInterface has a public method GetXXXXData() for each component type. (where XXX is component type).

Sensor sensor = new Sensor();
sensor.Data = DataInterface.GetSensorData();

2) DataInterface has a public method GetData(componentType) and switches inside on component type.

Sensor sensor = new Sensor();
sensor.Data = DataInterface.GetData(ComponentType.Sensor);

3) Abstract component base class has virtual method GetData() which is overidden by each derived class. GetData() makes use of the DataInterface class to extract data.

Sensor sensor = new Sensor();
sensor.GetData(); 
//populates Data field internally. Could be called in constructor

For me solution 3 appears to be the most OOD way of doing things. The problem I still have however is that the DataInterface still needs to switch on the type of the caller to determine which query string to use.

I could put this information in each component object but then this couples the components to the storage medium chosen. Not good. Also, the component should not care how the data is stored. It should just call its GetData method and get data back.

Hopefully, that makes sense. What im looking for is a way to implement the above functionality that does not depend on using a switch on type.

I'm still learning how to design architecture so any comments on improvement welcome.

TIA

Answer 1

First, I agree with the idea of each component object, in it's constructor being responsible for asking for its configuration. In fact, perhaps that's pushed up into the base class constructor. We end up with

DataInterface.GetData( getMyType() );

kind of a call.

Then, you main question, how can we implement GetData( type)?

In effect you want a mapping from a type to a query string, and you don't want to be changing code as new components are added. So how about providing some data-driven approach. A simple external configuration proving that mapping. Then it's just a config change to add more components.

Answer 2

Actually, solution #3 is the worst because it gives the Sensor class artificial responsibilities. The other two solutions are better in that they encapsulate the data access responsibilities into different classes.

I would suggest the following interfaces and classes.

interface IComponentDataReader 
{
    object GetData();
}

abstract class AbstractComponent
{
    private IComponentDataReader dataReader;

    public AbstractComponent(IComponentDataReader dataReader)
    {
        this.dataReader = dataReader;
    }

    protected object GetData()
    {
        return dataReader.GetData();
    }
}

class Sensor : AbstractComponent
{
    public Sensor(IComponentDataReader dataReader)
        : base(dataReader)
    {
    }

    public void DoSomethingThatRequiresData()
    {
        object data = GetData();

        // do something
    }
}

class SensorDataReader : IComponentDataReader
{
    public object GetData()
    {
        // read your data

        return data;
    }
}

class MyApplication
{
    public static void Main(string[] args)
    {
        Sensor sensor = new Sensor(new SensorDataReader());
        sensor.DoSomethingThatRequiresData();
    }
}

I hope this makes sense. Basically, for good OOD, if you can keep your classes to do only one thing (Single Responsibility Principle) and know only about itself, you will be fine. You must be asking why there is an IComponentDataReader passed to SensorComponent if it should only know about itself. In this case, consider that this is provided to SensorComponent (Dependency Injection) instead of it requesting for it (which would be looking outside its own responsibilities).