![]() Public PasswordBuilder(IList rules, int validLength) Private static bool IsValidDays(int days) Return PasswordPolicy.IsValid(candidate) If (string.IsNullOrWhiteSpace(candidate)) Private static bool IsValidPassword(string candidate) Var duration = Duration.FromStandardDays(daysValid) ĮxpiryInstant = (duration) Private void SetPasswordExpiration(int daysValid) Guard.IsValid(() => daysValid, daysValid, IsValidDays, "Invalid number of days") Guard.IsValid(() => password, password, IsValidPassword, "Invalid Password") Guard.NotNullOrEmpty(() => password, password) Public Password(string password, int daysValid) : base(IsValidPassword, password) I’m going to propose two ways of doing this, depending on whether or not you own the code of the Singleton.īoth examples are going to use the same starting code.I have a Password class that looks like this: public class Password : SemanticType Let’s get down to it: how to refactor your code to get rid of that hard cast concrete dependency on a Singleton? I hope this heps making the point accress that static is generally a bad idea, unless previously stated conditions and maybe some other exceptions that I didn’t think of. Leaving apart the gazillions issues that arise from using this as is (time zones etc), if any logic of your code depends on the current time and you got it from DateTime.Now, you cannot test it (yes I know that you can use Fakes which are super cool but you should use them for testing in legacy code, not new code that you are writing). ![]() Let’s take another simple but compelling example: DateTime.Now, the nemesis of testable code. If the Singleton writes to a database, your test code will do so too. The second one is easy too: by not using an abstraction, you cast in concrete the behaviour of your code and make it impossible to change it for testing purposes. The first one is easy: most of the times, a singleton is a central access to a resource - a database, some logging tool, the network… That is the definition of an external dependency, which you definitely should not depend on directly but use through an abstraction ( interface or abstract class). You have a dependency on another concrete class.I’m fairly certain Jon would not recommend you to use the Singleton in the calling code but instead to have it injected behind an abstraction, which is exactly what he has done with NodaTime’s IClock and SystemClock. Side note: although Jon wrote that Singleton, it is more of a demonstration on how to do it in C# than a recommendation to use it. A method performing an addition would be a good example of something that can be static, while accessing a database or logging is not. I allow myself to use static only when the method or property has no side effect whatsoever. If you take the classical implementation of the Singleton pattern ( courtesy of Jon Skeet, so we know it’s correct), it uses static: The rest of the post will focus on the analysing the issue in depth and solving it in C#, but it probably more or less applies to other languages. Whoever is using these Singletons that have been registered in the container will receive them through an abstraction and will not be aware that this instance is being shared by god-knows how many callers.Īnd that is the way to get “rid” of a dependency on a Singleton: get the calling code to use an abstraction instead. It seems that we don’t like Singletons but still we like Singletons. It’s actually telling that all the DI containers have a Singleton life-time implementation, which is the recommended usage for all dependencies that are stateless as it will be very performant. How do we achieve this? By using Dependency Injection, of course! Singletons are not bad, but the callers should not be aware that they are calling a Singleton. ![]() Why am I doing this? Because I still encounter Singletons in the wild and some developers still think that it is a good idea it its raw form… TL DRĪ class being a singleton is be an implementation detail. ![]() In short, the problem lies with their implementation, more specifically the way it is implemented in the GoF book. I’m just to add my two cents to the fray (years later) by saying that I disagree with the principle that singletons are bad per say and try to untangle the issue. Singleton have been qualified as evil, stupid, and so on, for quite some time now. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |