If you need a static, stateful singleton, there is no such thing in Apex. That's because static in Apex does not mean the same thing as static in Java. In Apex, none of your Apex can remain in memory after a request, and none of your Apex can share memory. Static is request-scoped.
If you can provide some more detail on what you're trying to achieve, we can try to help you solve your problem; in my experience, genuinely stateful singletons are a rare requirement that almost always have some alternative.
The general solution I'd recommend that most closely resembles a stateful singleton, and allows you to pass information between requests, is some combination of an abstract utility class with static methods and persisting state via either a custom object instance or a custom setting. Locking could be an issue depending on how fancy your state needs to be.
First of all your code doesn't compile now. That explains a lot.
Secondly, in my opinion messing with polymorphism in static classes (wholly static as you said) is not a good design at all. I don't see any good reason (although there might be some) driven by design needs to do try to access static method with super. But question is still interesting, so let's move on.
Third thing is, you use super keyword to reference private member. It shouldn't be possible at all. Private is private. If it compiled somehow, that was certainly a bug.
Answering to point 1:
As I said, I can't see any reason to inherit from static class. Actually It's not even an inheritance, you can access public members of any other static class anyway like listed below. Moreover, it's not permitted now - when I tried to compile your code (and many of it's variations :) I get the Variable does not exist: this error from line -1 (valuable clue!). Not surprisingly, the code like this works fine, and it doesn't grant any access to other private members:
public virtual class Fact_BaseFactory
{
public static void populateFieldNameToTypeMap(String objectName) { ... }
}
public class Fact_Account extends Fact_BaseFactory
{
static
{
Fact_BaseFactory.populateFieldNameToTypeMap('Account');
}
}
According to second question:
A)
This idea seems to be the way to go, I would just create some public method In the helper class and reuse the code within your factories. Not sure what you mean with violating DRY here.
B)
Composition instead of inheritance is good design in general based on my experience and it's also recommended by Head First "Design Patterns" book. I would stick to the A anyway, but it's a good question to ask on codereview.stackexchange.com
Best Answer
Singletons not only are not needed in Apex, they are basically pointless. In that previous thread, I described why stateful singletons are pointless, but stateless singletons are pretty much in the same boat, simply because the instantiation/cache step is unnecessary.
In Apex, I've found that abstract utility classes with all-static methods are the equivalent of a Java/Spring service layer (without dependency injection). In practice they behave the same as a stateless singleton class anyway. We have dozens of these in our app, which are used to do anything servicey, such as the describe call caching you mentioned.
When you're in an environment that is born and dies within the scope of a single (single-threaded) request, the singleton pattern is irrelevant. Static achieves the same ends, including state sharing within the request if that's what you need.