views:

67

answers:

3

I am about to define an interface in my application that plug-in writers can implement to provide user-defined "export" capabilities. It'll look something like this:

public interface IFooExporter
{
    void ExportFoo(Foo foo, string path);
}

However, I need to let the plug-in writers know (explicitly, not just in documentation) that "path" represents a folder, not a filename. It's their responsibility to create the files as part of the export process.

What's the best way to enforce that a path is a folder and not a filename? My best guess right now is to use DirectoryInfo instead of string:

public interface IFooExporter
{
    void ExportFoo(Foo foo, DirectoryInfo folder);
}

Is that a good solution, or are there pitfalls I'm not aware of with passing DirectoryInfo instances around?

+1  A: 

Use XML comments, they will show up in Visual Studio's Intellisense popup.

/// <summary>
/// Type in the text you want to appear
/// </summary>
TravisO
Like I said in the question, though, I want this to be explicit in the interface - not just a documentation thing.
Matt Hamilton
The comments in intellisense come from the concrete implementation, not the interface.
benPearce
+1  A: 

Name your variable more explicitly. Is it merely a path? You're saying no it is not, but you're still leaving it with a generic name. Name it folderPath and there will be less confusion and less need to explicitly communicate this to implementers.

sliderhouserules
Yes, parameter naming is part of the answer (hence my renaming it to "folder" in the DirectoryInfo answer), but I'm not underestimating the stupidity of potential add-in writers here! A string is a string and could be anything, despite the parameter name.
Matt Hamilton
I don't understand why you are needing to "enforce" anything. These implementers are implementing the receiving side of something here, no? Is not your code going to be the one sending the value in this parameter? If not then your question isn't very clear to me.
sliderhouserules
Yes, my code will be supplying the parameter. I'm trying to make it foolproof in a "strongly-typed" sense. If I pass a string and the imlpementor decides to treat it like a filename, his exporter is going to crash and burn. I know it's his fault but I want to help prevent that up front.
Matt Hamilton
+1  A: 

Because you are not implementing the solution, then I agree with you solution of using the DirectoryInfo as a parameter. If you specify a string then there is no way to stop any string being passed.

benPearce
Positive reinforcement! I'm gonna leave this question open for a while, and if nobody comes up with a better solution or a convincing argument *against* DirectoryInfo then I'll flag this as the answer and go with that idea.
Matt Hamilton
If you do go the DirectoryInfo route, make sure to remember that you're passing an object with mutable properties.
sliderhouserules
In that case a new class inheriting from DirectoryInfo, making it readonly, is also a possibility.
benPearce
I just meant "remember" in the sense that when you send a string to some method it isn't going to get changed on you. Don't rely on the properties of your DirectoryInfo object after you've handed it off to a plugin.
sliderhouserules
Yep good point. Because this will be for custom exporters, it's likely I'll construct a DirectoryInfo and pass it in and never look at it again, so mutability shouldn't be a problem.
Matt Hamilton