I'm implementing a long algorithm (about 500 lines of C++). The algorithm consists currently of about 10 different methods. Each method I have to hand over multiple data-structures as parameters, which are calling each other. Only one method is can (should) be used by the end-consumer.

I was wondering if a class would be better. This way I can hold all data-structures in one place (as instance variables) and can access them from each method without passing all these as parameters.

A typical usage would be:

MyAlg myalg_instance(input_param1, input_param2, pointer to computation_results);

And afterwards the instance is useless and can be deleted. Is this patter good? Are there better patterns?


So we're looking at a big fat static method broken down into bite-sized pieces. I would definitely recommend putting it into a class, even if it is for a single purpose. Your process has a state and that state can be maintained through class members, so yes absolutely.

Just be careful to distinguish between operation parameters and process parameters. Process parameters are what you pass to your algorithm and what is required in almost every method throughout. Operation parameters are results of previous calls to methods that are necessary for the next operation, but only for the next operation.

A good example of a process parameter would be a list of items to sort. If you were to create a recursive sort algorithm, then the entire list would be your process parameter so you don't have continually pass the same array recursively. The start and end indices would be a good example of operation parameters that don't need to be class members. Using class members to hold information is an excellent way of reducing method parameters, but do it only if it is useful throughout.

If you don't like launching the algorithm in this way, as a formality you could create a public static method that does:

ProcessClass process = new ProcessClass(<parameters>);

So that the caller would only have to call Process.start(<parameters>) so you still have a neat way to call it externally and internally your code is cleaner than if you had one gigantic method.

Hope that helps!

| improve this answer | |

Consider the concept of a closure (see e.g. this question and its answers). A closure saves you from passing around extra arguments that are known in a given context. For example, instead of writing:

def addTax(taxPercentage, amounts):
    def computeTax(perc, amount):
        return perc * amount / 100.0

    return [a + computeTax(taxPercentage, a) for a in amounts]

you can write

def addTax(taxPercentage, amounts):
    def computeTax(amount):
        return taxPercentage * amount / 100.0

    return [a + computeTax(a) for a in amounts]

The closure computeTax() implicitly gets the variable taxPercentage from its context (the context in which it is defined) so that it is not necessary to pass around the same variable again and again.

Now you have several functions that need to manipulate some common data. In fact, an object can be considered as a collection of closures that close over some common variables (the object's member variables). In this way, these functions need not pass their common data to each other explicitly.

So, yes, IMO it is definitely appropriate to make an object containing the data to be used during the computation and to implement all your functions as methods (closures) that access that common data.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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