Best practices for creating libraries that use .NET namespaces

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.

Answer 2

If it's a standard .NET library, I wouldn't worry about it. No reason to map from one class to another ... what if System.Color changed in the next .NET release? You'd have to change your mapping code too, and possibly have to detect the version and map accordingly. That's a real pain.

Answer 3

With all of my libraries, I return objects that depend only on things in the library.

I would ask myself why I was writing a library that would depend upon another namespace that was not implicit. It seems to go against the whole "Encapsulation" concept.

So just by going off of my own reasoning and knowledge of OOP, I would say you are on the right track with returning your own non-dependent object.