From what I understand two components A and B should only communicate with one another via an interface. Ideally this interface should be in its own separate assembly so that the client need not be loaded with the dependencies of any particular interface implementation.
The question then is how do I pass information such as enums and custom Types that appear within the interface if the client is only dependent on the interface?
Eg:
public enum Status
{
Success,
Failure
}
public interface SomeInterface
{
Status CallAPI(string s);
}
In which assembly should Statusin this example reside so that both client and service can use the interface, but without breaking the principle of Dependency Inversion? Can it be contained within the same assembly as the stand-alone interface? What if the enum was replaced with a custom type that the interface depended on?
2
two components should only communicate with one another via an
interface.
Interface includes not only some methods, but both return and argument types.
In ideal engineering world it could be written as
public interface SomeInterface {
public enum Status {
Success,
Failure
}
Status CallAPI(string s);
}
so enum become part of interface.
But for many reasons (maintainability, readability etc), in general, it’s bad idea to move enum inside interface. (In some cases, however, it’s OK and I was working on projects with such structure). That’s why best practice is to have different file with enum in same package as interface.
The core idea of DIP is to decouple components. Enums and custom types that are essential for the interface can be part of the same assembly as the interface itself. This maintains a clear separation of concerns and ensures that clients only depend on the abstraction, not the implementation details.
You can also, use a a separate assembly (e.g. CommonTypes) for the status, that contains common types shared across different components. Both the client and service can reference the CommonTypes assembly to access the Status enum without violating DIP.
Both implementation makes sense from the dependency inversion principle point of view, and if you want to extend the the functionality(open-close principle) any implementation would allow adding a new implementation of the module.
I would opt for the second option in this case, as I consider it’s more decoupled, so in that case your client relies on the Status type. Status as a type is more abstract than the interface, and can be used in more interfaces.