Defining an interface which is blank and its implications

I recently came across the situation where I wanted a set of classes to be passed into a method (so that method took an interface as a parameter).

However, the classes under the interface each had a different number of methods, so the interface itself was blank.

What, if anything, does this say about the design of my application? I was going to use an abstract class in this case, but I kept with interfaces so s开发者_Go百科omething probably stopped me from using abstract classes (can't remember what).

Language: C# (though this is independent of the language).

What you've described is a 'Marker Interface'.

http://en.wikipedia.org/wiki/Marker_interface_pattern

As with any design pattern, there's nothing inherently good or bad about it as long as it is the right pattern for the task at hand.

The question I would be asking is why you needed instances of those classes passed into your method, and why it could only be one of that set.

If the method could have done exactly the same thing with, say, System.Object, then it should have taken an object as a parameter. If it required items passed in to have some particular functionality, then that functionality should have been codified in the interface.

What, if anything, does this say about the design of my application??

Maybe it says that you need to think a little more about where certain responsibilites really lie? Remember Liskov substitution principle (LSP): Sub-types must be substitutable for their base types. I'd also keep Single Responsibility Principle (SRP) in mind as well. But most importantly keep things simple.

I've often found that it's only after I've put something like this together and worked with it for a while (from different points of view and in different cases of use) that things start to become clear. So what it might be saying is that you have something in mind but it's not yet clear to you how best to do it - that's cool; get something working and then refactor when you're ready.