In short, I am writing an app in .NET with a plugin architecture.
Main app provides a set of interfaces abstracting different service implementations. Here is how one of that interfaces may look like:
public interface IMessageService { void ShowError(string message); void ShowMessage(string message); } Everything seems OK for now but what if I will add a new member in future, for exaple, void ShowWarning(string message);?
I expect users not to implement those interfaces by themselves and to use implementations provided by main app. But they can write a mock by hand or write a wrapper or something and their code will break after a new release. Maybe it is not so bad to make developers rewrite a little code from time to time, but there must be a better way out.
One possible way is to create an abstract class with all methods throwing NotImplementedException instead of an interface. So that new members will not break user codem, but it seems like a major code smell.
Another way is even worse: interface versioning. It looks ugly and will end up in casting everywhere which breaks an OOP concept.
Third, the easiest and fastest way is to pass concrete class directly to the user as some framework developers do. Main drawback is that users will need to adapt those classes for unit testing each time while my aim is to give them a way to develop plugins as easy as possible.
What is the best approach of designing extensible public interfaces?
