Specifying interface for third-party implementors

Question

I have a project that requires certain functions, and I have created an interface for these functions. If the implementations of the interface is to be performed by external parties, what should be the correct way to do this?

The idea I have is to create a class library project ( MyInterface ), define my interface ( IModule ) in this project, compile this and give the DLL ( MyInterface.dll ) to the external parties. The external parties would develop/implement using the DLL as a reference, then give me their final DLL. My main project would reference the MyInterface project, as well as all the implementations. In my code, I would do something like this:

IModule module = new ImplementationA();
module.DoSomething();
module = new ImplementationB(); // Change implementation at runtime

Is this approach correct? Are there better alternatives?

Side question: Is this strategy design pattern? Or facade?

Answer 1

I would probably use configuration to load the 3rd party assembly at runtime, look for a single factory type, create a singleton instance, and create each implementation class through the factory. This way you can give all of your assemblies to a 3rd party, and they can build and update their component at any time. They depend on your code, but you don't depend on theirs.

Answer 2

I don't know much about your project or situation, but I would consider publishing a nuget package of your interface and allow the third parties to install it. That gives you the power of versioning when you need to make changes to your interface(s). You publish the change(s) as a new version and then they can update their installed package of your dll accordingly. That at least gives them a concrete way to develop against what you require in a controlled, robust manner.

In case you aren't familiar with nuget packages, in Visual Studio you can right click the necessary project with the dll within the solution and select Pack . You can also change pack settings by going to the Package tab in the project properties (same context menu on the project, select Properties ).

You can also do dotnet pack through the command line, which has a lot of command line arguments that you can leverage.

Whichever way you go about it, you can publish your nuget package to nuget.org, to some other service with an artifact feed, or simply to a file on disk.

Helpful Nuget Package References:

• Installing a nuget package
• Create and publish a nuget package

As for your question about the pattern, typically when you switch implementations like that at run time that is the strategy pattern at work. The facade is when you use a single class to abstract away multiple instances of different sub-system classes. So for example lets say you have operation classes for GetUser , UpdateUser and DeleteUser . Your facade could be a single class called UserManager and within that class you would expose functions of each user operation. Inside those functions you would be accessing each individual instance of each operation class and passing the call on to those functions internally. In this example, inside the facade you know you are working with 3 classes. From the perspective of code/callers outside of it, they only know about the single UserManager class.