Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
This looks as if this method should be part of some class and method should change some private fields. Eg. maybe doing good OOP design would help you. – Euphoric Sep 25 '12 at 8:33
You're on the right track - multiple out parameters are typically indicative of wanting to return a struct / object. – Daniel B Sep 25 '12 at 8:39
Actually, this looks more like it should be 7 different methods in the FinancialReturn interface. – Jörg W Mittag Sep 25 '12 at 8:41
@JörgWMittag true, but I'm guessing the class it lives in already has several hundred methods /joke :) – Daniel B Sep 25 '12 at 8:59
up vote 6 down vote accepted

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.

share|improve this answer
The reason why i'm using a struct and not a class is because I'm looking for a simple container to store the out parameters that can be passed from the interfaces to all the client applications that uses it. so yes, it will be a common denominator amongst other methods. As for name of method, it's because the method is deep down in a generic class that deals with other facets of the system employing a strategy pattern 3 levels down. – Jonathan Sep 26 '12 at 1:18

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.