Is it generally okay to use concrete classes from OS libraries on an interface?

Question

I do believe that my question is similar to: Is it OK for interfaces to depend on concrete classes? and see/understand what the answer explains about how the dependency-inversion principle should be followed. But I am interested in a slight variation of this question. Would it be acceptable to define an interface containing objects from framework/OS libraries?

An answer in the question I am referencing mentions a bit about how Java libraries are believed to be stable and more or less acceptable to include in an interface, but they don't fully discuss this aspect. In my case I am using C# and would like to create an interface that accepts a CancellationToken to have the object support cancellation, for example. Would it be an acceptable practice to use this .NET object on my interface?

Answer 1

The reasons this might be a bad idea are because you want your program to work even when the library interface changes, or at the very least, you need only change little in your program for it to work.

The likelihood that you shoot yourself in the foot increase with every direct reference to the library you make. Sometimes you must, but if you were to minimize calls through an interface of your own making, you've essentially added a layer to soften the coupling. So long as the library makes reasonable changes offering alternative methods, you can more often then not make due without even altering your program beyond the interface class handling concrete classes.

Similarly, the objects returned from a library may be important throughout your program. You should encapsulate those instances in your own classes and offer only methods that you use internally. This pattern is sometimes called Facade. Whether or not your facade acts like the library class is entirely up to you, but you're encouraged to simplify where you can.

Hope that helps!

Answer 2

As often before the answer is - it depends.

It depends entirely on which consumers you support and where this concrete class is from. If you require consumers to take in an dll they don't need or want just to implement your interface then it would be a very bad idea.

Lets say you made an interface ISqlSomething and you have implementations ISqlServiceSomething and MySqlSomething. The implementations are in different assemblies so they don't need dependencies on a db they don't use. In that case it would be a very bad thing to put MySql or SqlServer specific things in the interface.

In your example, if you don't support any use cases where CancelationToken is not available then you should be fine. One such example could be if you wanted support an old version of the framework. In that case you should another solution.

Answer 3

Yes, I would say that CancellationToken, Exception, Task, List etc are acceptable to expose.

Obviously you are requiring that those who use your library also use the libraries which contain these classes, and with .net Standard now out you might want to check what is supported by what! (System.Threading is in .Net Standard 2.0)

https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md

But these kind of objects are very likely to be in use already in most .net projects.