Question

Is it bad practice to write a library that defines an interface dependent on another library?

I know tight coupling is bad, but does this still apply when using .NET classes?

For example, in .NET, if I have a library that returns a Color object, it would force a dependancy on System.Drawing on anything that uses my library. Would I be better off creating my own Color-type class inside my library?

Answer 1

I distinguish between Volatile and Stable Dependencies.

In general, Color looks like a Stable Dependency because it’s already in the BCL, it’s deterministic in nature and doesn’t involve any resource-intensive out-of process communication, and neither does it rely on a particular set-up of its run-time environment.

The only consideration here is that when it comes to Color, there are more than one such class in the BCL, so make sure that you really mean to target only Windows Forms applications with your API, because WPF has its own definition of Color.

If you just need the Color to paint parts of the UI in a certain color, then the built-in Color class is probably fine, but if Color is a main concept in your Domain Model, and you need to target different UIs (WPF, Windows Forms, Web) you would probably be better of by defining your own abstraction.

In such a more advanced case, you could subsequently create Adapters and Mappers around your abstraction to bridge the gap between the abstraction and the concrete Color classes.