Let me start with some caveats regarding the presented proposals before I present mine. I take the liberty of skipping the "smelly" solutions - HashMap and beans, because you can clearly see their disadvantages.
Be careful with
Blindly using helper classes to hold groups of parameters. They can really shine when the group is cohesive (like in Mark Phillips' answer), but they will cause problems otherwise (essentially acting just like a typed HashMap). I doubt that they'd apply to the problem of passing 7 params from view to DAO layer.
Minimized methods are also great, when they make sense (like in List example from Effective Java book). I just rarely see places when they do, so I doubt they'd solve your problem.
The Builder pattern is often very clean, however it only solves the problem of one layer - it doesn't tell you how to pass parameters further down. And when you have a parameter from view, that's needed in DAO, the Builder will just bloat your code and you will need to pass parameters anyway.
And before I finally present the solution, let me challenge a common implicit assumption, that all data needs to be passed via stack in form of method parameters. That's only true if you make your processing objects application- or session-scoped. The constraint goes away when you create all your relevant objects at the start of request processing. Then you can use objects' constructors to pass only necessary information to them.
The optimal way: Use objects of request lifecycle
To some degree this resembles Method Object or Command pattern.
In order to apply this solution, you need to change the entry point to your system - usually that's a method in some view-layer object. Make it responsible for two things:
- request object graph creation
- calling the object graph root's execute/run method
The first step is crucial. This is the place, where you construct request-scoped objects from each layer: view, service and DAO. For each of those objects you only pass the required data to their constructors (for example, if parameter "userIP" is only needed in DAO - say for auditing DB access, pass it to DAO request object only). The request objects also need references to their collaborators (like service needing the DAO) - pass those via constructor accordingly.
The second step: when you have your object graph set up, just call the execute/run method on the first of them (usually it's an object from view layer).
/** The example (in Scala) shows how your app's entry point could look like.
* The presented method belongs to an app-scoped view-layer object.
*/
def delete(itemId: Id, userIP: IPAddress) {
// Note, that only RepositoryHelperReq class is interested in the
// "itemId" and "userIP" parameters
val repoReq = MainRepositoryReq(RepositoryHelperReq(itemId, userIP))
val serviceReq = MainServiceReq(ServiceHelperReq(repoReq))
val viewReq = MainViewReq(ViewHelperReq(serviceReq))
viewReq.execute()
}
Now let me respond to some anticipated criticism of this pattern.
Criticism rebuttal
Some will say, that performance will suffer, because there will be more object on the heap to garbage collect.
I would ask those for measurements, because usually it's not object allocation, that costs performance, but object retention (see last presentation of Simon Ritter).
Some will ask about application- or session-scoped data, like datasources or shopping basket object. Those objects still can be used - you just inject those into your request-scoped objects.
Some will criticise the dependency structure, saying that view should depend only on service and not on DAO. That's valid remark, only note, that in classic webapps you still have a central place, that depends on every layer used (place often called "end of the world"). Sometimes it's web.xml, other times it's Spring application context or Guice module. If you care for proper dependencies, I advise you to put all the factory logic in such place, to let it implement some View-layer interface and to be injected to the view. That way your whole dependency structure will stay clean and modular.
Some will say, that popular DI frameworks (mainly Spring) support that pattern very poorly. That's true, you'll need to either use a decent DI library (Guice, Dagger for Java or Macwire if you fancy Scala) or prepare to fight Spring in order to do it right.
The benefits
- No long-parameter-list smell
- No incohesive "request context" objects (the MagicContainer antipattern)
- No "stamp"-coupling - intermediate layers need not to depend on passed parameters, so they can be released independently, are more testable and cleaner
- Data is used only where it's needed - easier testing, less mocking
- Can be used even where other methods fail, like when you do not have cohesive ParameterObject to extract or when you cannot easily split methods into minimal, orthogonal ones
Credits
The solution to this particular problem was introduced to me by Miško Hevery in his excellent blog post How to do Everything Wrong with Servlets and precisely nailed down in Managing Object Lifetimes (see "More common violation" fragment). I want to thank him for his posts, because it's hard to find precise guidance about this specific problem in other sources.
