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

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.