I wrote a dlls that connect to some 3rd party API, each DLL has the methods: SignIn
,Upload
,Download
,SignOut
.
My manager asked me to implement a factory pattern because in future I will write more dlls to other APIs that has the same methods signuture.
For now I have:
DLL 1: OneDrive
It has a class with methods: SignIn
,Upload
,Download
,SignOut
.
So if I want to use it I'm adding reference to this DLL and then any app can use this DLL.
DLL 2: DropBox
It has also class with methods: SignIn
,Upload
,Download
,SignOut
.
My question: How do I implement the factory method design pattern in this secnario?
What I did: I created another DLL("The new DLL") this DLL would contain the "FactoryClass", the problem is that the creator in this dll should return a type of "OneDrive" or "DropBox" that means I should add refernce to the first two dlls ("OneDrive" and "DropBox").
But, The classes "OneDrive" and "DropBox" should implement some abstrct class whithin the new dll that means I should add refernce to the new dll.
but it's not possible because it's circular dependency (Visual studio error)
In order to eliminate the circular dependencies, you must keep the dependencies in the direction of your main assembly.
This is in partly solved by an interface (or abstract class) declared in this central assembly, but there is the additional problem of instantiating the concrete implementations without directly referencing the dependencies.
This can be solved by allowing your factory to keep a registry of available implementations. You can find an example of a simple factory with registration in this other stack overflow question