Question

I’m defining an API as an interface which we’ll call IFoo and I want to define a method Bar()

This method Bar() will take one required argument and then some arbitrary number of other arguments. The interpretation of these other arguments will be up to implementors of IFoo

For this scenario is it more appropriate to define my interface using params or using Dictionary<String, Object> e.g.

public interface IFoo
{
   bool Bar(String id, params Object[] params);
}

Or

public interface IFoo
{
   bool Bar(String id, Dictionary<String, Object> params);
}

It seems like the former is easier for users to invoke but the latter is more explicit in its intentions since with the former you’d have to specify the parameters in a specific order for the implementation to interpret them properly while with the latter you are essentially doing named parameters.

So questions:

• Which form should I be using (and why?) – is one of these considered best practice over another?
• Are there specific advantages to one style versus the other that I should be aware of? Is one of these considered a code smell?
• Is there an alternative pattern that would achieve the same thing in a different/nicer way?

For the record I am aware of named parameters in .Net 4.0 but this code needs to be compilable on .Net 3.5 so can’t use any .Net 4.0+ functionality

Edit

Just to add more detail on what my IFoo and Bar() methods are actually representing because someone asked.

IFoo represents some storage subsystem and Bar() is actually a create operation. Depending on the storage subsystem Bar() could require no parameters other than the ID or it could require many parameters.

Edit 2

So in response to @Kirk Woll’s comment and @Fernando’s answers here’s more information.

I will likely never invoke IFoo.Bar() myself, this interface is part of an open source framework. 3rd party devs will be implementing IFoo and end users will be invoking specific instances of it, the point of having IFoo at all is to make it easier for users to migrate their applications between storage subsystems because they can code to interfaces rather than specific implementations as far as humanly possible.

In the simplest case the underlying storage subsystem only has one form of store so no parameters will be required other then the ID. In the complex case the storage subsystem may allow multiple types of store and each type of store may permit arbitrarily complex set of configuration parameters e.g. index size, persistence, transaction behavior, indexing strategy, security and ACL considerations etc.

I agree with @Fernando that maybe something more polymorphic may make sense, maybe polymorphism combined with generics and type restrictions may be best e.g.

public interface IFoo
{
  bool Bar<T>(T parameters) where T : IBarConfig;
}

public interface IBarConfig
{
  String ID { get; set; }
}

Then with an implementation like so:

public class MyFoo
{
  bool Bar<T>(T config) where T : MyBarConfig
  {
    //Implementation
  }
}

public class MyBarConfig : IBarConfig
{
  public String ID { get; set; }

  public long IndexSegmentSize { get; set; }

  //Etc...
}

This is off the top of my head so not sure if it is actually legal to define Bar() in MyFoo with a different type restriction then the interface it implements?

Answer 1

The dictionary approach has another problem: typos. You’ll probably need to define a lot of constants to use as keys to avoid this problem.

Why not going for a polymorphic solution?

public interface IFoo {
    void Bar(FooData data);
}

public abstract class FooData {
     public int Id {get;set;}
}

public class MyFooData1 : FooData {
    public string SomeProperty {get;set;} 
    //...
}

public class MyFoo : IFoo {
    public void Bar(FooData data) {
        var myData = (MyFooData1)data;
        //...
    }
}

public class MyFooData2 : FooData {
    public int SomeOtherProperty {get;set;}
    //...
}

public class MyFoo2 : IFoo {
    public void Bar(FooData data) {
        var myData = (MyFooData2)data;
        //...
    }
}

You’ll end up with more smaller classes, but they are easy to test and extend.

Update

@RobV you can’t change the type restriction if you’re implementing an interface, but, if you put your type parameter at the interface declaration, you may accomplish what you’re trying to do:

public interface IFoo<T> where T : IBarConfig {
    void Bar(T parameters);
}

public class MyBarConfig: IBarConfig {
    public String ID { get; set; }
    public long IndexSegmentSize { get; set; } 
}

public class MyFoo : IFoo<MyBarConfig> {
  public void Bar(MyBarConfig config) {
    //Implementation
  }
}