Hmmh, ich muss mal kurz trollen - Sorry Also in einem kleinen Projekt nutze ich gerne Singletons und ignoriere die ganze Kritik von wegen Anti-Pattern und so (s. [1][2][3][4][5][6]). Aber in einem sehr, sehr großen Projekt würde ich es anders designen, weil es echte Probleme geben kann. Vor allem die Reihenfolge der Initialisierung - muss nicht aber - kann zu Fehlern führen, die nur schwer zu fixen sind. Mock-Objekt-Instanziierung für Test-Fälle u.ä. wird auch eher komplexer. Da tendiere ich in diesem Fall (großes Projekt) eher zu einer zentralen Klasse, die die Instanzen kreiert und verwaltet.
Ich würde auch für ein Singleton ungern den einen Schuss opfern, den man bei der Vererbung hat. Irgendwie kommt mir das nicht natürlich vor, dies als Is-A-relationship zu designen. Wenn ich z.B. von MonoBehaviour abgeleitete Objekte mit DontDestroyOnLoad habe, so sind diese meistens auch Singleton-artig unterwegs. In diesem Fall kann ich kein ": Singleton<MyClass>" angeben und somit habe ich doch 2 verschiedene Wege, mit Singletons zu arbeiten.
Aber: Man kann das so sehen und beim Software-Design gibt es kein Richtig und Falsch (manchmal ist da sogar das sogenannte Richtige falsch oder das vermeintlich Falsche richtig