Interestingly enough, the same phenomenon arises in languages with fewer features. In go, for example, there are no constructors, only functions that return structs. Singletons are just global variables referencing a struct, etc etc.

Every programming language has “singletons”: they’re just global variables.

Singleton’s main feature is not that it is globally accessible, but in that it represents a state that cannot be naturally duplicated. The pattern itself lies in a controlled instantiation, where a method/constructor/factory returns a cached value on a second call. Globals are just that – globals.

Global variable is naturally can't be duplicated. Or do you assume dark corners of initialization spec for c++?

At global level:

   ThingThereCanBeOnlyOneOf a;
   ThingThereCanBeOnlyOneOf b;

Oops. That's not a singleton. That depends on nobody, ever, anywhere in the code creating another one. In contrast, a true singleton can enforce that there is only one, no matter what the callers do.

Globals like a and b are fields of the singleton, not instance of singleton(s). The global space is the singleton (or a juxtaposition of singletons, if we let aside the lack of visibility protection), and global variables and functions are the fields (members) and the methods of the singleton.

You can look at it that way, I suppose, though I consider it to be a fairly odd perspective. But it doesn't help at all with the problem of enforcing that there be only one ThingThereCanBeOnlyOneOf. Therefore globals are not a true solution to the problem that singletons are trying to solve.

Just use static methods.

Singletons solve several problems with static methods, namely that you can't change their behavior (e.g. do error logging to both the global error log and a per-request log, then at other times do it to a log buffer for testing, and NOT to anywhere else).

At least with a singleton you can create a bunch of "standard configurations" by calling them with a different constructor at startup time. So you can have a test DB during tests, different log targets, read from different filesystem (not the real one, but the one in the testdata/ directory) ...

Better yet is to have a "context" abstraction that you pass down the chain. Issue with that is, every method needs to have a first parameter that is the context ... so it requires some discipline.

Some frameworks (java @#$@#%@# servlet spec for example) make this parameter implicit and then use something akin to exception resolution to get this parameter (so when you do GetContext(), it unwinds the stack to give you the correct context). That makes things very complicated, and is an invisible LOT of state that gets passed down the stack. Still better than singletons or static methods, but good luck figuring out why a context is set to X.

In all cases you need to be very careful to USE the context. DO NOT use database except the one in the context, no caches except the one in the context, no filesystem reading, logging, ... except by redirecting through the context.

I can also get second instance with singleton. In reality singleton doesn't enforce anything. It's a only a convenient way to make global scope in inconvenient languages.

I would partially agree, although I don't know many implementations.

It's a state that cannot be naturally duplicated, alright, a "single source of truth". But lazy instantiation is nothing more than a very important and very common second. The pattern itself lies in preventing public-level instantiation (i.e. in Java it could translate to a class with a private constructor, private instantiation and access to the instance through a class-level/static getter, and also making it a final class).

my (very tongue in cheek) favorite description of singletons - an object oriented way to break object orientedness.

Not quite - variables are references to objects, there's nothing that restricts global variables themselves to only reference a single _instance_ of an object.

That said, a global singleton (and global state in general) is usually an anti-pattern; having pretty much any code be able to depend on the state makes it very difficult to evaluate the impact of a change.

> - Classes aren't objects

Right. Except in Smalltalk they are

Ruby, too, IIRC. And likely others.

is the Abstract Factory showing a weakness of all languages in which it is useful? What is the underlying weakness?

The question is, "I have some code that wants to make some different kinds of a thing in the same way, then use the different kinds in the same way, being unaware that they are different and not depending on any particular kind. How?" The answer is typically that you can pass a function to that code which accepts some stuff and returns the thing it is concerned with. You may say "Thats an Abstract Factory" but when we write like 4 LoC instead of 3 classes in different files we often don't feel a need to give it a name.

Edit: Also, depending on the circumstances, you can probably just pass the class or its constructor instead of passing a newly written function. That would get you down to ~0 LOC involved in replicating the functionality of this pattern.

I guess if we want to get really abstract, we can say that the Abstract Factory pattern is a shim from a kind of late binding that is implemented in the language ("object orientation" a.k.a. dynamic dispatch on the first argument to a function) to one that is not (late binding of classes, constructors returning null, etc.). This isn't the whole picture though, because sometimes late binding isn't even an important part of what we're getting from the Abstract Factory pattern! For many use cases, we could imagine implementing the function that consumes the Abstract Factory using C++ templates or Zig comptime, and our compiler would generate separate subroutines for each factory type and statically determine which one to use at each call site and we would still be doing the Abstract Factory thing.

Another pattern called the Visitor Pattern is similarly a shim from dynamic dispatch on one argument to dynamic dispatch on two arguments. You just really hope you don't need dynamic dispatch on five arguments one day.