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)
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?