I’m encountering a lot of methods in my project that have a bunch of out parameters embedded in them and its making it cumbersome to call the methods as I have to start declaring the variables before calling the methods.
As such, I would like to refactor the code to return a struct instead and was wondering if this is a good idea.
One of the examples from an interface:
void CalculateFinancialReturnTotals(FinancialReturn fr, out decimal expenses, out decimal revenue, out decimal levyA, out decimal levyB, out decimal profit, out decimal turnover, out string message)
and if I was to refactor that, i would be putting all the out parameters in the struct such that the method signature is much simpler as below.
[structName] CalculateFinancialReturnTotals(FinancialReturn fr);
Please advise.
4
This is pretty much a non-question to me. Yes, what you suggest is most likely an improvement over the current design.
The overall best approach is dependent on the context though and without knowing the broader context – just that isolated example – one cannot recommend much beyond what you have already thought of.
For example, what other methods are there? Do they have some common denominator (I mean similar set of out parameters); can you reuse this struct (good) or would you have to create many different structs (bad)?
And why a struct, not a class? Remember that structs can’t be inherited.
The name of this method – CalculateFinancialReturnTotals – is a code smell in its own right to me. My feel is that CalculateTotals should be sufficient. If it’s not obvious that it deals with financial returns, the overall design might be flawed somehow. But it’s just guessing.
1