2

I often see classes of this form:

class Thingy {
    public Thingy( /* some arguments here */ ) {
        // Initialize some member variables.
        // Maybe do some other things that
        // are not likely to fail
    }

    public Execute() {
        // Do the important stuff.
        // This often involves actions that might
        // fail, like file access, user input etc.
    }
}

This makes perfect sense when Execute() is called multiple times per object. But why do people use this pattern in cases where Execute() is never called more than once per object. What are possible advantages over using a standalone function or - if the language does not have these - a static method?

Is there a name for this (anti) pattern?

  • 1
    Because it can be called multiple times in the future. No one knows that. – Engineert Mar 28 at 21:53
  • 1
    Because they may not know at the time of writing it if it will be called once or more. Or perhaps they want to leave the option open in the future. Or perhaps that's what they were told to do. Maybe they just like it. Lots of potential reasons. – GrandmasterB Mar 28 at 21:59
  • 1
    @GrandmasterB: I didn't explicitly state it in my question because I thought it was obvious: Creating an object instead of calling a function has a drawback. It adds complexity to the code. – Frank Puffer Mar 28 at 22:02
  • 1
    @GrandmasterB: The background of my question is that I lately had to modify some code that made excessive use of this pattern. It almost drove me crazy because the constructors were typically not called right before the Execute functions, but somewhere else. – Frank Puffer Mar 28 at 22:27
  • 1
    Whilst the answers try to justify it, you hit the nail on the head: it's an anti-pattern born out from people trying to take OO to its illogical extremes whilst not respecting DI properly. Either make the method static, or if it has side effects, inject the instance of Thingy instead. – David Arno Mar 29 at 8:31
5

What are possible advantages over using a standalone function or - if the language does not have these - a static method?

Making a class allows you to separate the initialization from the execution, perhaps because you want them to happen at different times, or because you want one part to have different parallelization or error handling or authentication/authorization behaviors.

It also allows you to implement some interface, which can allow easier reflection, provide visibility limitation to dependencies, and a few other tricks depending on the language.

As others have mentioned, its command-like in its design. Commands are useful when you have unexecute sort of functionality, need to serialize this type across servers, or when this is one implementation.

Mostly though, this sort of thing comes up in old Java code (or with programmers used to writing old Java code) where decent function-pointer/delegate/lambda syntax was unavailable.

The command pattern itself is a generally agreed upon good pattern.

The concept of some function that must be called before other things (even if it's not an initializer) is called temporal coupling, and is a well-known code smell.

4

This class looks like beginnings of a command pattern.

But why do people use this pattern in cases where Execute() is never called more than once per object. What are possible advantages over using a standalone function or - if the language does not have these - a static method?

The advantage is that you can inherit these action classes from a common interface, then treat them polymorphically. That allows to separate the initiation of the command from the execution of the command.

  • Not at all convinced by your "advantage" here as function wrappers (eg the Action delegate in .NET) here handle that without the need to declare an interface and class to wrap the function. In fact it's only of use if the language doesn't support functions as first class citizens, in which case it's a bodge, rather than an advantage. – David Arno Mar 29 at 8:26
  • @David Wrapping the command into a class allows to bundle some individual data with the command when the command is created. This can also be achieved with functional programming methods too, if language supports that. If the command doesn't need to carry individual data about itself from the time it's created, it can be a delegate or a function pointer. – Nick Alexeev Mar 29 at 16:12
4

Beyond @Telastyn's (which does mention lambdas) and @Nick's excellent answers, I'd like to specifically call out that what you're describing is akin to a closure.

The point of the closure is two fold:

  1. to capture some bindings to the local environment, and
  2. to offer a function with a specific signature, here () => void (in typescript notation), or an Action in C#.

If you have constraints that you need to provide a function that satisfies a particular signature, but you want your function to have access to additional state that you cannot pass as a parameter (because someone else is calling it), a closure is very useful, and the pattern in your question satisfies the closure pattern.  Under the covers, something similar is what the C# and Java compilers translate closure-based lambdas into.

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.