• some guy (unregistered)

    Frist of all, that's brillant, because you got rid of all those complicated fields in your class. An anti-struct, if you will. Secondly, all the unit tests with the single "instantiations" pass - seems like a you problem.

  • Industrial Automation Engineer (unregistered)

    The thought that scares me most is: how can the application even mimic something reasonable? How effed up must the application be to even remotely able to work with these anti-patterns? What architecture is robust enough to take this nonsense?

  • (nodebb) in reply to Industrial Automation Engineer

    The object might just be a "coincidental" singleton, that is, a thing there's only ever one of for practical purposes, but it's really meant to be a "true" singleton (with a static "get_instance()" method, and all the tra-la), and this is the other developer's way of achieving that without making it a real "true" singleton.

  • (nodebb)

    My guess is that someone couldn't figure out the syntax for a static member variable but knew how function-level static variables worked. Since the two get/set functions can't share the static variable, they created a common function to hold the static, but exposed two separate get/set functions for the interface.

  • (nodebb)

    getter/setters, or properties as they sometimes are called, are not an anti pattern, they are a concept from design by contract and are super valuable because they abstract contract from implementation. In all good languages they are a zero-cost feature do to inlining at a compile level (like C/C++/C#) and even on more meh languages like Java they still offer a very low overhead do to concepts like PGO.

    Now why is a contract relevant; well, it allows backwards compatibility and clarity of expression. So basically you can future proof code, which is not the case with (instance) member variables on types.

    That said, properties can be abused. Expected behaviors are as important to contracts as is the syntax. So if you actually turn a field into a property (or use getter/setters in language that don't have properties directly), you expect them to behave like properties. So no long running execution times or observable side effects especially when it comes to state or concurrency.

    Addendum 2025-04-17 12:08: For completion sake, yeah everything about setGetField is garbage - there's no way to sugarcoat it really.

  • Guessed (unregistered) in reply to davethepirate

    My guess is that someone couldn't figure out the syntax for a static member variable but knew how function-level static variables worked. Since the two get/set functions can't share the static variable, they created a common function to hold the static, but exposed two separate get/set functions for the interface.

    That is disturbingly plausible, but if you're willing to go full WTF (as the author of this code clearly is), you could just do:

    private:
int &fieldref() {
    static int s_val = 0;
    return s_val;
}

public:
void setField(int val) {
    fieldref() = val;
}

int getField() {
    return fieldref();
}

    Function-level static, but no weird boolean-controlled set/get logic.

  • (nodebb) in reply to davethepirate

    I can totally see this being the result of trying the proper way to do this, but continuously getting the syntax slightly wrong, and after a day of banging their head against the wall, settling on this because it worked. And then thinking that this must be the way to do it, due to what they believe are "idiosyncrasies of the language", and not due to them "being unable to read a manual".

  • (nodebb)

    These CSOD are amazing. Not in a million years would have I had been creative enough to think of such a twisted pattern.

    But there it is. Someone not only thought about it, they actually implemented it. It would almost be pure genius if it had been done in a cynical way, like some kind of obfuscated C contest. Sadly, it probably wasn't.

  • (nodebb)

    @prueg. Yeah, this.

  • LionKor (unregistered)

    and we've blundered back into Singletons again, somehow.

    This caused a shiver down my spine after the last weeks on here.

  • Justin Time (unregistered) in reply to MaxiTB

    They're typically considered an antipattern in C++ because they're essentially extraneous boilerplate for making the variable itself publicly accessible. (Which is something that encapsulation is typically against, and that Java in particular usually considers outright heretical.) It's not entirely false (they're essentially useless for their stated purpose, since they're typically inlined into direct access to the underlying variable), but it's not entirely true (since they provide a way to specify intent during every access or limit undesired write access, and in particular allow you to control the const-ness of the access), either. (And they're also useful for debugging, since the debugger can latch onto them semantically even if they're being optimised into direct access mechanically.)

    Really, the main reason there's such a big fuss about whether they're an antipattern or not is that most people don't want to admit that using friends to give one or two other snippets free access is usually better encapsulation than giving everyone free access through getter/setter patterns. So, they're considered a better pattern than friends, which in turn just leads to people looking at that rule and asking why "give everyone free access with extra boilerplate" is considered a form of encapsulation to begin with. (And it's rare for either side to acknowledge that you can befriend the getters/setters themselves.)

Leave a comment on “Static State”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article