Question

In a project I am working on, we have several “disposable” classes. What I mean by disposable is that they are a class where you call some methods to set up the info, and you call what equates to a doit function. You doit once and throw them away. If you want to doit again, you have to create another instance of the class. The reason they’re not reduced to single functions is that they must store state for after they doit for the user to get information about what happened and it seems to be not very clean to return a bunch of things through reference parameters. It’s not a singleton but not a normal class either.

Is this a bad way to do things? Is there a better design pattern for this sort of thing? Or should I just give in and make the user pass in a boatload of reference parameters to return a bunch of things through?

Answer 1

Sounds like your class is basically a parameter block in a thin disguise.

There’s nothing wrong with that IMO, and it’s certainly better than a function with so many parameters it’s hard to keep track of which is which.

It can also be a good idea when there’s a lot of input parameters – several setup methods can set up a few of those at a time, so that the names of the setup functions give more clue as to which parameter is which. Also, you can cover different ways of setting up the same parameters using alternative setter functions – either overloads or with different names. You might even use a simple state-machine or flag system to ensure the correct setups are done.

However, it should really be possible to recycle your instances without having to delete and recreate. A “reset” method, perhaps.

• As Konrad suggests, this is perhaps misleading. The reset method shouldn’t be seen as a replacement for the constructor – it’s the constructors job to put the object into a self-consistent initialised state, not the reset methods. Object should be self-consistent at all times.
• Unless there’s a reason for making cumulative-running-total-style do-it calls, the caller should never have to call reset explicitly – it should be built into the do-it call as the first step.
• I still decided, on reflection, to strike that out – not so much because of Jalfs comment, but because of the hairs I had to split to argue the point 😉 – Basically, I figure I almost always have a reset method for this style of class, partly because my “tools” usually have multiple related kinds of “do it” (e.g. “insert”, “search” and “delete” for a tree tool), and shared mode. The mode is just some input fields, in parameter block terms, but that doesn’t mean I want to keep re-initializing. But just because this pattern happens a lot for me, doesn’t mean it should be a point of principle.

I even have a name for these things (not limited to the single-operation case) – “tool” classes. A “tree_searching_tool” will be a class that searches (but doesn’t contain) a tree, for example, though in practice I’d have a “tree_tool” that implements several tree-related operations.

Basically, even parameter blocks in C should ideally provide a kind of abstraction that gives it some order beyond being just a bunch of parameters. “Tool” is a (vague) abstraction. Classes are a major means of handling abstraction in C++.