At my company, we’re building an SDK consisting of a number of assemblies. For example, we deliver an assembly called Company.Platform.Security that contains the implementation of our authorization model.
Now, this assembly contains code that talks to other services over HTTPS. It therefore needs to discover where those services live and needs to log the interactions and any errors that result from it.
So the same SDK, contains assemblies called Company.Platform.Logging, Company.Platform.ServiceDiscovery etc. These assemblies expose interfaces called Company.Platform.Logging.ILogging and Company.Platform.ServiceDiscovery.IServiceDiscovery respectively.
Now my question is, should the classes in Company.Platform.Security take these interfaces as dependencies in their constructors? Or should Company.Platform.Security define its own Company.Platform.Security.Interfaces.ILogging and Company.Platform.Security.Interfaces.IServiceDiscovery interface and take objects implementing those in the constructor of its classes?
The latter makes the assembly more cohesive IMO as it protects it against changes in those interfaces (which may or may not be maintained by other team members or teams). But a lot of concrete classes will just be very simple adapter classes for the classes in the other assemblies. It might also make the system more complex.
What are valid arguments for either approach?
2
I would use the former approach. The latter duplicates a lot of effort, especially since the pairs of interfaces will likely be the same. So following the KISS and DRY principles, I would simply use one set of interfaces and not create a second (likely duplicate) set.
2