Contrapositive-ish question: What is the design reason a library class would not implement an interface as a convenience to the developer? (e.g. the .Net library class FileInfo)
The FileInfo
class necessarily is dependent on the file system. This obviously present problems when unit-testing. If I had to design and implement this class for my own internal use, I would get around the issue by implementing FileInfo
as a matching IFileInfo
. Then I can inject the IFileInfo dependency however I want and unit-test dependent code easily.
But I don't implement FileInfo
myself, I get it from a 3rd party, so I have to create an interface, a wrapping class, and somehow stub or mock that interface to achieve a similar result.
It seems to me that providing the interface as part of the library is a thoughtful way of making the future developer's life easier, and their code easier to maintain.
Would that be an acceptable way to design a library, why or why not?
FileInfo
has 22 public methods/properties. Providing an interface with all those signatures for mocking "just in case" is probably not a really good idea.