I will also sometimes define a bean to abstract a complex set of arguments -- has a bit more structure than a Map. But I like the Map solution as well (a habit from JavaScript). I'll use whichever seems to make the most sense within a scenario.
I tend to make a bean, often with "fluent"-style methods. I use maps sometimes, but find the lack of type safety (depending on what you're doing, of course) a little bothersome.
David Newton wrote:I use maps sometimes, but find the lack of type safety (depending on what you're doing, of course) a little bothersome.
That. And the fact that both sides need to agree on the keys. But sometimes, a map just feels right.
David Sharpe
Ranch Hand
Joined: Jun 15, 2009
Posts: 32
posted
0
If I write a method that has more than three parameters, I usually get suspicious that I'm either not decomposing the problem, or not encapsulating my solution.
For example:
void recordSale(Sale sale, int day, int month, int year) {...}
Should probably be:
void recordSale(Sale sale, Date date) {...}
Or potentially even just:
void recordSale(Sale sale) {...}
Like most best practices, any answer to your question will really only be a heuristic for good design. Sometimes, one parameter is too many.
I worry that the Map solution is easily misused:
void recordSale(Sale sale, Map date) {...}