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:
Without knowing exactly what the differences are between your charts, I can’t recommend any one approach as being the best.