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?

Fermanagh

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.

Strait

Excellent link to volatile dependencies and in general a great answer. +1! – Kulseth

Thank you for this information, full of advice on issues I had not even considered. I'm sure I'd like to break away from WinForms at some point. – Fermanagh

I do like this advice, it reminds me to keep dependancy out of my classes, and coupled with the post from Gus (The Gus Principle) the general advice seems to be "Roll my own". This course of action is most effective due to the Color class being trivial. In more complex situations with 3rd party dependencies, as Randolpho mentions, this principle may have to be bent, or the design rethought somehow. Thanks for your posts! – Fermanagh

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.

Cargo

BCL code tend not to change between versions, but on the other hand, new Color types may appear - and they have: if you take a dependency on System.Drawing.Color you will have shut yourself out from using your API in WPF. – Strait

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.

Johnathon

I think it's acceptable to work with namespaces in mscorlib; outside of that, the principle is sound. – Antitrust

I like your principle too, I am going to follow it. – Fermanagh

Answer 4

You pose an excellent question. The answer is: it depends. In the case of standard libraries that will always be available, then it's fine; the core library references different .DLLs all the time.

In the case of a third party library you run into issues. It's not always a good idea to roll your own if something else does what you want, but then you have a dependency on another library, which is a logistical problem for users.

There's no right answer here, you just have to go with what makes the most sense for your project. Try to decouple as much as possible, yes, but sometimes you just gotta cuddle up and get the job done.

Kulseth

Hehe, I like the term "You just gotta cuddle up and get the job done". I think in this case, because of the relative triviality of the Color class I will be better off rolling my own. I see more complicated cases are going to bring headaches. – Fermanagh

Answer 5

It depends on your usage of the class.

If you ever need to obtain an instance of the system Color class from an instance of your Color class (for example if you draw to a windows form) then it would be better to use the System class - it saves you the effort of having to convert between the two types and gives you the advantage of being able to use all the "Features" of the Color class for free (such as built in constants for "Red", "Black", "Green" etc...

If on the other hand you are simply working with arbitrary RGB values (perhaps for scientific calculations) and never need to convert to an instance of System.Color, then it might make sense to create your own class.

In all likelihood you are better off using the System.Color class - yes encapsulation and all that is a good idea, however not at the expense of saving you massive amounts of time!

Frag

I am 99% sure I won't be needing the built-in constants, so in this case I think I am better off rolling my own. Thank you for your advice. – Fermanagh

Answer 6

You shouldn't worry about using anything in the .NET core library. You wouldn't get very far in writing a DLL without it. The only place possibly to be careful around it is the System.Web namespace as I believe .NET 4 has a client profile installer which basically means if you use this installer it will only install things expected to be used on a client. I personally think it is a bad idea on Microsoft's Part as it just adds un-necessary complication for saving a small amount of download time.

Blastocyst