@Gฤ
ska said in c# - Any clean way for generic parent to get type of child?:
You may think you want. But most often it's not worth it. The worst thing is, you only start seeing it's not worth it two years down the line, and then it's too late and the only solution is rewriting half of the project. BTDT.
Same thing with any other interface - the more it's used, the harder it's to change.
It's just a matter of time until you want something to be done in parallel. To prevent freezing the entire GUI for the duration of the operation, for example.
Yeah, switching to parallel would be such a smooth ride if not for singletons.
Properly locking all the moving parts is a lot of fun itself. Unless your idea of locking is the same as Python's - a single global mutex that reduces all environments to a single thread environment.
Depends on how many moving parts there are, how they move and what accesses them. Properly locking stuff is not a problem inherent to singletons.
Only if you don't need/want unit or module tests. I have a very strong opinion of programmers who think they don't need/want unit or module tests.
If the singleton is an integral part of some unit operation, then stubbing it doesn't make sense. Unless you like testing units mocked so hard that they don't do anything.
Or it may not make sense.
Singletons are usually used to communicate with other modules in the application. This is the very first thing you want to stub out in tests.
Just set the state in the singleton to what you want.
If your data type changes from int to float, you just replace int with float everywhere and you're (mostly) done.
No, I said 'when interface changes' - methods, parameters, returned types, properties change.
If the class that previously only ever had one instance now can have multiple instances... hoo boy, that's going to change a lot of things. Suddenly all other things have to be multiplied too. Lists of objects become lists of lists. A previously threadsafe operation needs to be reworked from scratch. And so on and so on. BTDT. De-singletonizing is a really major change; few things can compare.
"things have to be multiplied", "Lists of objects become lists of lists", wth are you talking about?
Change the way instance is acquired, check if access is thread safe and that's all.
Hey, it's a valid criticism. You're not alone in the project, your code will be touched by juniors eventually.
Juniors are to be taught and guided, not shielded from problems.
It's not just that singletons allow God objects. They encourage God objects by making them super easy.
There's a lot of stupid stuff that's super easy, yet somehow we manage to avoid it.
Also, dependency graph will absolutely suck.
Who cares.
Like a constructor?
Like synchronizing singular stuff between many instances.