When should I use params Object[] versus Dictionary<String, Object>?

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
  }
}

Answer 2

You need to decide if you need to search or be able to retrieve an Object from the params collection/Array.

When using Object[] params, There is no indexing on the Objects. You need to iterate the whole collection to find an item (by its key).

When using a Dictionary<String, Object>, your Objects are indexed by their key, and its always easy to search/query by the key.

Depending on your need, you need to decide your Approach.

Dictionary is faster for searches, but there is an overhead to create the indexes.

Answer 3

The fact that you mention optional parameters makes me think the IDictionary<string,object> approach would be better - that's your best approach to give that kind of interface in .Net 3.5. You could just ask for object and do something like what MVC does for htmlAttributes (using reflection to turn the anonymous object into an IDictionary<string,object>).

The scenario where I'd prefer the params object[] approach are ones where trying to give them names in every situation would just be weird/impossible, like for string.format.

Answer 4

params provide easier to write/read code compared to Dictionary if you need to write them inline. I.e. imaging constructing dictionary for every call to String.Format - code will be unreadable. On other hand if you already have dictionary of parameter - ok to use it.

I would recommend to reconsider API and see if you can accept IEnumerable, or even better IEnumerable<T> as arguments. Unfortunately with such generic IFoo name of sample it is not possible to see if such approach would work.

Answer 5

Which form should I be using (and why?) - is one of these considered best practice over another? ---> You should use the second one, because it's a lot less error prone than the second one.

Regarding the alternative pattern, there is surely a way to implement this in a nicer way. Can you tell us what your problem actually is? instead of using IFoo and Bar? I can't suggest anything else unless I know exactly what you are trying to do, and why...