Is it good practice to encapsulate many parameters that are alike into a struct

Question

Basically, I have something like the following:

public string SomeDBMethod(string server, string dbName, string userName, string password,...)

Is it good practice to refactor it to the following:

public string SomeDbMethod(DBParams parameters, ...)

Where DBParams is defined as follows:

public struct DBParams
{
  string Server {get;set;}
  string DbName {get;set;}
  string UserName {get;set;}
  string Password {get;set;}
}

My point is really to be able to pass around less parameters as I find functions with long parameter lists really quite ugly.

I have also found that there are some limitations to this approach: if SomeDbMethod is to be exposed as a web service method, I cannot use the DBParams struct as a parameter (as far as my understanding on the subject of web services go...which isn't very far).

So, is this too much trouble for little benefit or am I on to something here?

Answer 1

Unless you actually need to pass around this set of parameter very frequently (with the same data), I don't see any need. Long parameter lists are sometimes a sign of a need to refactor your code, but then again are sometimes inevitable. (In your situation is seems more like the latter.) So, simply go with the straightforward method of passing the parameters directly unless you find yourself needing to store the parameter sets (at least temporarily) - you really won't be saving any code otherwise, and certainly not increasing readability.

The method use a struct does not impose any limitations in relation to web services. You just need to make the type as serialisable (DataContract in WPF, I believe), and there shouldn't be any problems.

Answer 2

I would suggest reading this question on structs verses values objects

Almost certainly making the struct mutable is a really bad idea in this case.

Given that named parameters are coming in c# 4.0 I would suggest anything like this is simply going to be annoying later on and should be avoided unless there is a serious need to pass about this 'packet' of information in many different paces as well as operations which are only meaningful on them.

To be honest if the class/struct does not maintain/enforce some invariant then there is little point.

Answer 3

I always group parameters that go together into a single object - the code is cleaner this way, it is obvious that they are related to each other and always used together.

However, in most cases I use a class and not a struct. The benefits of structs were never clear to me, and they are pain in the back in many situations (I guess the webservices scenario is just one example).

You can make a class immutable if you don't want people to change it (if this was the reason to use struct)

Answer 4

There is a pattern called encapsulate context that talks about the issues involved with using this technique. It might be worth taking a look at that for a detailed analysis.

Answer 5

Hi,

You can use Struct if you want to encapsulate related variables. It does not have to be an object. As Structs are value types, unlike classes, they do not require heap allocation, also they are passed by value not by reference like objects.

IMHO in this case creating a class to hold that information does not add value, but if you plan to something more sophisticated with the DBParams information (exposing it as a parameter for a Webservice), then consider using an object. If you want to simply pass those parameters in a succinct way the struct is ok.

You can get more info here:

http://discuss.joelonsoftware.com/default.asp?dotnet.12.489354.15