简体   繁体   中英

How to prevent having to update all implementing classes after updating an interface?

We have a WPF application which is primarily a charting application. There are approximately 30 charts. Each chart has its own table in a database which holds configuration information for the chart. Each chart has an class in the app containing configuration information related to the chart.

We have an interface in our app ( IChartConfiguration ) which each chart configuration class implements. It allows the app to work with any particular chart configuration in a consistent and similar manner.

The 'problem' we have is that each time we need to add a property to the interface, for a new chart that adds a new configuration property we haven't already dealt with, we have to go back to each chart configuration class, that doesn't already have this new property implemented (most of them usually) and add it. to satisfy the interface implementation. This isn't a huge burden, but it seems to me there must be a better way to deal with this.

Is there a better way to handle this?

Your problem lies elsewhere, the 'problematic' behavior you are experiencing isn't problematic at all. It is the intended use of interfaces. By implementing an interface you are stating, 'this class supports this interface'. If you wouldn't update all classes that implement that interface you are no longer upholding this contract.

The main question you should be asking yourself is whether the configuration property you just added makes sense for the other charts. If it doesn't it shouldn't be specified in one common interface.

Just a few alternatives worth exploring:

  • Having one main interface and extending others from it.
  • Abstract classes with common implementations.
  • Dividing behavior across multiple interfaces.

Without knowing exactly what the differences are between your charts, I can't recommend any one approach as being the best.

In my understanding of interfaces this is exactly what an interface is used for . So no, I don't think that you can prevent this with your implementation of IChartConfiguration.

But probably you could split IChartConfiguration into several smaller interfaces and implement only the interfaces that match the particular chart class.

Try this architecture:

interface IChart
{
    string newProperty { get; set; }
}

abstract class BaseChart : IChart
{
    public virtual string newProperty
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }
}

class Chart1 : BaseChart
{
    private string _newProperty;
    public override string newProperty
    {
        get
        {
            return _newProperty;
        }
        set
        {
            _newProperty = value;
        }
    }
}

class Chart2 : BaseChart
{

}

Then when adding new property to one of the charts, you will be needing to add it only in your interface and abstract class. Other charts will be untouched.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM