c# - When should I use params Object[] versus Dictionary? -

i'm defining api interface we'll call ifoo , want define method bar()

this method bar() take 1 required argument , arbitrary number of other arguments. interpretation of these other arguments implementors of ifoo

for scenario more appropriate define 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 former easier users invoke latter more explicit in intentions since former you'd have specify parameters in specific order implementation interpret them while latter doing named parameters.

so questions:

• which form should using (and why?) - 1 of these considered best practice on another?
• are there specific advantages 1 style versus other should aware of? 1 of these considered code smell?
• is there alternative pattern achieve same thing in different/nicer way?

for record aware of named parameters in .net 4.0 code needs compilable on .net 3.5 can't use .net 4.0+ functionality

edit

just add more detail on ifoo , bar() methods representing because asked.

ifoo represents storage subsystem , bar() create operation. depending on storage subsystem bar() require no parameters other id or require many parameters.

edit 2

so in response @kirk woll's comment , @fernando's answers here's more information.

i never invoke ifoo.bar() myself, interface part of open source framework. 3rd party devs implementing ifoo , end users invoking specific instances of it, point of having ifoo @ make easier users migrate applications between storage subsystems because can code interfaces rather specific implementations far humanly possible.

in simplest case underlying storage subsystem has 1 form of store no parameters required other id. in complex case storage subsystem may allow multiple types of store , each type of store may permit arbitrarily complex set of configuration parameters e.g. index size, persistence, transaction behavior, indexing strategy, security , acl considerations etc.

i agree @fernando maybe more polymorphic may make sense, maybe polymorphism combined generics , type restrictions may best e.g.

public interface ifoo { bool bar<t>(t parameters) t : ibarconfig; } public interface ibarconfig { string id { get; set; } } 

then implementation so:

public class myfoo { bool bar<t>(t config) t : mybarconfig { //implementation } } public class mybarconfig : ibarconfig { public string id { get; set; } public long indexsegmentsize { get; set; } //etc... } 

this off top of head not sure if legal define bar() in myfoo different type restriction interface implements?

the dictionary approach has problem: typos. you'll need define lot of constants use keys avoid problem.

why not going 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 more smaller classes, easy test , extend.

update

@robv can't change type restriction if you're implementing interface, but, if put type parameter @ interface declaration, may accomplish you're trying do:

public interface ifoo<t> 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 } }