What's the alternative to DRY code when it requires too many parameters?

Question

What is the best strategy for maintaining easy to follow code when keeping things DRY means you have to pass a lot of parameters to shared functions?

In my specific case, I have a grails based app, and have implemented a system where to reference object B from object A, I have taglibs, gsp's, javascript and service code to manage that allows the user to click a link, a list of all object B's popup, allow them to select or Add a new 'B' entry and that reference then gets stored in a field in object A, This is being implemented in many different places, parameterising many things.

Keeping this DRY is becoming a bit of a nightmare to maintain, and certainly difficult for any new eyes to understand.

Answer 1

Without seeing any code, it's difficult to give precise advice for your situation. However, your situation is likely highlighting how DRY is the enemy of KISS and loose coupling. To reduce duplication, you have created a set of shared functions. Those functions need many parameters and likely are used in many places. So they are now more complex than they could have been if code were repeated and couple many parts of your application to those functions.

DRY is not a hard-and-fast rule. It's one of many guidelines to creating better code. It needs to be balanced against other conflicting guidelines though. If a little repetition reduces complexity and coupling, then opt for a little repetition.

Answer 2

The usual advice to avoid repeating the same set of parameters over and over again is to turn parameters that only appear together into a class, and pass an object of that class instead of a list of values. It's perfectly okay to create a class type that merely serves to make your code drier that way.

You sound as if you have the added constraint that the same set of parameters have to flow through code written in different languages. That makes things more difficult, but as long as these values keep appearing together it's often feasible to write that structure down once and then auto-generate classes/structures in different languages from that single declaration. You'd need to post more details about your system to decide whether that's possible, or worthwhile.

Answer 3

The programming language Haskell actually had a similar problem with its "record syntax" for data structures, where you would potentially be updating the third field of a data structure with things like:

incrementCount MyRecord{param1=p1, param2=p2, count=c, param3=p3} = MyRecord{
        param1=p1, param2=p2, count=c+1, param3=p3}

This was solved by adding some language-level syntactic features which look more like updating a dictionary:

incrementCount m@MyRecord{count=c} = m{count = c + 1}

Here the m@<pattern> syntax now supports a "partial pattern" and the count parameter in the record can be specifically referenced and updated. One of the biggest problems that this solves is that you no longer have to update every single function which handles the data structure, merely because you have updated the definition of the data structure to, say, rename key parameters or add new ones.

You can do this too! You just need to pass all of the parameters as one shared parameter dictionary; instead of function (url, queryParams, handlingNotes, ...) you can start to standardize on a request object {url: u, queryParams: q, handlingNotes: h, ...}. Each function which handles the request object will only care about the narrow subset that it cares about and will pass the other parameters right on through, with no boilerplate code needed.

Answer 4

TL;DR: encapsulate the common arguments or save state using partial application or object instantiation.

In the abstract if you want to reduce the number of arguments passed to functions and many of those arguments recur then you can use encapsulation. This can take the form of a data structure (list, hash map, etc). If there is high cohesion between the data and the functions you can also create a class where the functions are methods.

Alternatively, if the arguments are built up over different logical blocks or over time, you can use partial application. This would also allow reuse depending on the how long the data is valid. For example if some data is determined at start up of the application and rarely changes I could use partial application and reuse the resulting function until it does change. If you call many different functions with many of the same arguments you could leverage compose and partial application to manage the code complexity.

FYI: there are certainly other ways of solving this that may work better for you specific example. For example, you may even want to use a Singleton, globals, class variables, etc. There will be different costs and benefits to any code organization technique. Use whatever gives you the smallest implementation that is extensible, maintainable and readable.