This is my pseudocode for DAL:
CusOrderDTO GetCustomerOrder(DateTime OrderDate, string customerCode)
CusOrderDTO orderSet = new CusOrderDTO()
* query data from database, populate CusOrderDTO
return orderSet
Now the parameters for the DAL have grown so large that I should pass a custom data object for parameter
CusOrderDTO GetCustomerOrder(SomeParameterClassName orderParameters)
What naming convention is generally used for SomeParameterClassName? Naming it DTO seems weird since it’s solely used for parameter purposes only and service layer is only going to work on CusOrderDTO object.
For the above, please assume that CusOrderDTO and orderParameters have nothing in common.
-
If
SomeParameterClassNameregroups logically connected objects, then name it accordingly.For instance, if it regroups coordinate X, Y and Z, name it
3DPoint. If it regroups the product name, product price and product description, name itProduct.<code>void Demo(int x, int y, int z) { }――― ↧ ―――void Demo(3DPoint coordinates) { }</code><code>void Demo(int x, int y, int z) { } ――― ↧ ――― void Demo(3DPoint coordinates) { } </code>void Demo(int x, int y, int z) { } ――― ↧ ――― void Demo(3DPoint coordinates) { }and:
<code>void Demo(string productName, int productPrice, string productDescription) { }――― ↧ ―――void Demo(ProductInfo product) { }</code><code>void Demo(string productName, int productPrice, string productDescription) { } ――― ↧ ――― void Demo(ProductInfo product) { } </code>void Demo(string productName, int productPrice, string productDescription) { } ――― ↧ ――― void Demo(ProductInfo product) { } -
If
SomeParameterClassNameregroups objects which have nothing in common except being passed to the same method, then you are doing it wrong. There is no need to create a type for unrelated entities: just pass them as-is to the method.For instance, if it regroups coordinate X and product description, remove the object and pass two parameters.
<code>void Demo(int x, string productDescription) { }――― ↺ ―――</code><code>void Demo(int x, string productDescription) { } ――― ↺ ――― </code>void Demo(int x, string productDescription) { } ――― ↺ ――― -
It may be that you have many parameters passed to a method, but not all can be grouped. In this case, search for the ones you can group, and leave the others.
For instance, with parameters such as product name, product price, product description and logger, then group first three into a product class and leave the last one:
<code>void Demo(string productName, int productPrice,string productDescription, AppLogger logger) { }――― ↧ ―――void Demo(ProductInfo product, AppLogger logger) { }</code><code>void Demo(string productName, int productPrice, string productDescription, AppLogger logger) { } ――― ↧ ――― void Demo(ProductInfo product, AppLogger logger) { } </code>void Demo(string productName, int productPrice, string productDescription, AppLogger logger) { } ――― ↧ ――― void Demo(ProductInfo product, AppLogger logger) { }
In a presence of a method which accepts many disparate parameters, additional refactoring may be required. For example, in the previous piece of code, one may wonder why is AppLogger passed as a parameter, instead of being injected when calling a constructor:
var something = new Something();
...
something.Demo(product, logger);
――― ↧ ―――
var something = new Something(logger);
...
something.Demo(product);
Since other method of Something are probably logging their activity as well, injecting the logger in the constructor makes sense.
Another refactoring technique is to split the method. The large number of parameters is a good indication that the method does too much. There are sometimes obvious cases:
void Demo(a, b, c, d, e, f, g, h)
{
if (a)
{
// A few hundred lines which use exclusively the parameters b, c and d.
}
else
{
// A few hundred lines which use exclusively the parameters e, f, g and h.
}
}
but most are less obvious: some parameters may be used through the entire method, may be interconnected, etc. Still, if you feel like you have too many parameters, look at other indications (such as LOC, ILLOC in C# and the number of branches) and check if your method is doing one and one only thing.
I agree with MainMa: group locally connected objects. In case there is no other connection, there is still the request / query:
CusOrderDTO GetCustomerOrder(CustomerOrderQuery query)
I add Request or Query to parameter objects.