Method with object vs parameter list in Repository Search. Violation of SRP?

Question

I have a debate with my peer on whether it is good practice or not to either encapsulate a repository method's search options in an object or in a (potentially growing) parameter list.

In summary, psuedocode would be:

SearchItems(int id,string name,int statusId)

Vs

class SearchOptions
{
   /*
   For illustration purposes, I intentionally made the, otherwise private fields public.
   Under normal circumstances, they would be private with their respective accessors or mutators or properties for C#
   */
   public int id;
   public string name;
   public int statusId;
}


SearchItems(SearchOptions filter)
{
   //Rest of code here
}

Argument for parameter list are:

1. That the search has the single responsibility of getting only the results required at that point. If search requirements should change,a new method with the specific function should be written.
2. Even if object argument says it is less breaking, any change in search options will still require modification
3. It is friendlier to integrating across platforms (e.g. Java service backend to WCF service backend due to simplicity of method signature)

Argument for having an object to hold filter options are: (my argument)

1. Method remains intact and flexible to change without breaking much and requiring less work
2. No unsightly, long parameter list in method signature
3. Interfaces are left intact, adding more weight to less breaking changes

What would be considered good practice? And do the arguments hold(both sides) Or is this subjective?

Answer 1

Argument for parameter list are:

That the search has the single responsibility of getting only the results required at that point. If search requirements should change,a new method with the specific function should be written.

It can also have a single responsibility if the Paramter object is dedicated to the search method. E.g.

class SearchByIdNameAndStatus { // Maybe you find a better name depending on your use case

   public int id;
   public string name;
   public int statusId;
}

Even if object argument says it is less breaking, any change in search options will still require modification.

That's true. Furthermore... if you use one parameter object in serveral service methods they depend on each other. E.g. if you change the parameter object it might affect the other services that use it too.

It is friendlier to integrating across platforms (e.g. Java service backend to WCF service backend due to simplicity of method signature)

Maybe it is. Do you really have this requirement? You can also add a simple transport layer on top of your service layer to adapt the different transports.

Argument for having an object to hold filter options are: (my argument)

Method remains intact and flexible to change without breaking much and requiring less work.

I guess you mean that you will not get a compiler error, because the signature does not change. But clients still must set the "new" properties and the service must interprete them. So there is no really less work.

No unsightly, long parameter list in method signature

That's a good argument. Furthermore you can simply define which paramters are mandatory and which optional. Make the mandatory parameters constructor params of the search param object and the optional will just be setters. Also the validation of the paramters can be done in the parameter object.

Interfaces are left intact, adding more weight to less breaking changes

I think I already answere this before.

At least you can take a look at a blog that I wrote and maybe it helps you in your discussions to find a way. See

1. https://www.link-intersystems.com/blog/2012/02/26/separation-of-api-and-implementation/
2. https://www.link-intersystems.com/blog/2012/02/05/simplify-service-layer-design-using-bean-validation-jsr-303/

Answer 2

You're practically using the specification pattern, so in the sense that documented patterns are good practice, then yes, it would be considered good practice.