DEV Community

Discussion on: Generic Singletons

 
andreasjakof profile image
Andreas Jakof

The situation you are describing does not call for a singleton.

I know, but I really want to enforce the usage of just ONE instance of a type. And experience told me, that I need to enforce it, otherwise it won't be used like that.

If you need one instance... then make and share one instance! That's it! ... Just code pragmatically.

I'd prefer that approach, too, but then again... I saw, how others in the team used a class, I designed to load encrypted credentials... and that told me a lot about, what I need to enforce and how they are going to use it. It was as if the two pages extensive step-by-step examples were not there at all. And I made it as simple as var creds = MyCreds.Load(Certificate, encryptedData);

When design patterns are concerned, the most commonly used might be the factory and the singleton.

Goodness, I hope not. How many singletons are you seeing in your code bases? :(

Okay, maybe not the most commonly used, but the most well known.
Actually, there currently are 10 Singletons all of the same "kind", encapsulating access to an Azure AD Group each. I like to have a name for something instead of a GUID. User.HasService<Android>() is better readable than User.HasService(someGuid).

Actually, the Singletons I described in my initial blog post, weren't singletons at first, but became such only afterwards, when I saw, that even I not always followed my own intention of using just ONE instance of it. So I made it, that I had to and the compiler just won't let me do it otherwise. I like the compiler, he is my friend and if I am doing it right, he can tell me, whether I did something wrong or not.

Thread Thread
 
thebuzzsaw profile image
Kelly Brown • Edited

I totally understand the desire to steer developers into the "pit of success". This is just an area I feel is more appropriate for something like a Roslyn Analyzer or at the very least code reviews. (And again, your blog post was good. I just had to be first to share the dissenting voice.)

The common issues you'll hear come around testability. Having to 'reset' the singleton is non-trivial at times, and it basically means tests cannot run in parallel. Plus, I don't know about you, but I've had times where I later realized I do need more than one instance. This is where I feel it's important to always use dependency injection so that you are insulated from such decisions. When a method can freely grab SomeSingleton<SomeWidget>.Instance, that dependency is less visible. You'd have to know to "Find All References" on the singleton itself.

I love the discourse. :)

Thread Thread
 
andreasjakof profile image
Andreas Jakof

I like discussing such things as well. If you look at my post „Brilliant but also horribly wrong“, I had like to learn from others, who know more than me.

And I usually don‘t use Singletons much. But in this case, I think, it is fine. The Singletons are usable in multiple threads and they mostly let me compare the membership of a user in an AAD-Group. And they NEVER change. If they would, they would no longer be of the same kind, not only the same instance.

And I know about the issues with testability as well... this is where I have a considerable lack of experience, even though I am already in the business for about 10 years now.

That’s why I am currently looking into DI in .Net Core. To make my code more testable. But then again, the code is mostly glue between systems and I am struggling with the basic approach, hie I will test it. Currently there are some basic unit tests, but lots of untested code, because the CD/CI server does not have access to all the credentials for the different systems I am glueing together. 😳