Added IFileSystemWatcher, IFile and IDirectory interfaces

[wexman]

I have added the IFileSystemWatcher, IFile and IDirectory interface for easier mocking...

[fgreinacher]

This would implement #175, though I'm not sure if a breaking API change like that would produce more negative than positive echo.

@jpreese @robkeim What's your opinion?

[wexman]

That might indeed be a breaking change, but a rather theoretical one, meaning it won't actually break because the interfaces have the same members as the abstract classes...

[robkeim]

Minor: extra newline here

[robkeim]

I also agree with the direction that #175 wants to go, how difficult do you think the breaking changes would be for people consuming the library to fix in their solutions @fgreinacher?

If you're using the var keyword the change shouldn't be breaking for local variables inside functions:

var fileSystemWatcherFactory = new FileSystemWatcherFactory();
var fileSystemWatcher = fileSystemWatcherFactory.CreateNew(); // No breaking change here changing from FileSystemWatcherBase to IFileSystemWatcher

For instances where there are breaking changes (explicitly typed local variables, function parameters, function return type, etc, is a simple replace of XyzBase to IXyz sufficient for all the types that introduced the interface? That's definitely a naive approach, but I can't think of situations off the top of my head where doing so wouldn't be sufficient or would introduce other issues.

If that's the case then I don't think we should be too worried about this breaking change.

[wexman]

BTW, do you have any idea why the comments from my previous pull request show up here? Did i do something wrong?

[fgreinacher]

BTW, do you have any idea why the comments from my previous pull request show up here? Did i do something wrong?

(I assume comments == commits) That's just happening because we are updating your branch from master. It's fine :)

[fgreinacher]

OK - let's do this. A couple of things that I'd ask you to do:

1. Update the version in version.json to 4.0 (as this is a breaking change)
2. Add <inheritdoc>comments to the new interfaces (just mirror what's done in the implementations) so that we get proper XML docs.
3. Think about whether it makes sense to add a short chapter to README.md that describes the new use case this change enables

[wexman]

Oh, ok. But if we're going that route anyway, maybe we should do the same for all other cases as well? For example, IPath instead of PathBase, IFileInfo instead of FileInfoBase, IDirectoryInfo instead of DirectoryInfoBase and so on?

[robkeim]

@wexman Yes I think it definitely makes sense to have a consistent API

[wexman]

Ok, it's done...

[fgreinacher]

Merged with some adaptions. Thanks a lot for your work @wexman!