* the use of managers
* grouping manager instances into a structure

Now, I might be a wrong doer, but that’s a bit too much for me.

* managers are low cohesion, high coupling classes that are typically very stable and concrete. (OK ; simplified reading gives: a manager is made of several parts that have little in common (low cohesion), involve a lot of dependencies (high coupling), are difficult to modify because they are used everywhere (very stable), and cannot be extended because they use no abstraction (concrete)). That’s a 0 out of 4 in the realm of ‘do the correct design’. Most managers can be implemented as a factory, a collection and possibly a cache. That’s 3 parts, and that should be 3 classes. The behavior of the factory, the collection and the cache should be modifiable, so that even if they are coupled, they are not coupled to other part of the software. There is no such thing as a manager.

* library context – wait, what’s that? As I read your description, it appears to me that it’s a God class.

I kind of agree with you: neither managers nor contexts are perfect. I would go farther than you in your conclusion: I bet that if you’d stayed far away from both managers and contexts, you’d be safer in the ever-more complex virtual world. I would love to see a dependency graph of Despair. OK, maybe not (frankly, 50 libraries, most of them with a manager?)

BTW, I really love your blog. It’s just that post… Sorry.

I have encountered some of the issues you present in the development of the Phoenix engine* for my uni course.
Here’s my take at solving the singleton hell:
Andrei Alexandrescu describes in his book Modern C++ Design a complex singleton template based on policy classes.

Those policies allow a lot of customization of the behavior of the singleton; one of those policies being the singletonWithLongevity.

Essentially each singleton class specify a static function that returns its longevity as an unsigned int in its class declaration body.

The policy uses that number when it builds a list of singletons to sort them by order of destruction.
It then registers each of them with atexit.
Singleton instantiation is JIT.

When one needs to know if they can access a singleton from another singleton, it’s a simple matter of looking up in the header file for the getLongevity method and comparing the numbers.

Now for the icing on the cake, by using Alexandrescu’s static_check (or compile time assertion) and the static longevity number, checking and changing the order of destruction of the singletons becomes a breeze

Of course the whole thing is thread-safe thanks to the threading policy.

* For the story, the name comes from the fact that every semester we pretty much rebuild the engine from “scratch” but keeping the good elements from the previous design.
Like the Phoenix, it never really dies

The problem with singletons is that you can never make a system independent of other systems if they are pulling each other’s singletons into themselves left and right. How about if each system declares an interface – file system, memory allocation, and the like – and then an outside system injects the implementation of those interfaces into the various subsystems.

The disadvantages are, as I see them:

* Virtual call overhead (and lack of inlining etc)
* Lots of boilerplate code to make your actual file system (eg) implementation adhere to the various subsystems’ file system interfaces.

The advantages are:

* Total decoupling of systems, leading to…
* Reuseability of the systems since other clients can now cherry-pick the systems they want without getting the whole code base with it.