I totally agree that singletons are bad, even if it's just for the race conditions they can introduce.
Would you explain more about why static classes violate the single responsibility principle? I went to the post, but I'm still having a hard time seeing this. It appears to me that if the whole class is static, and the function encapsulates business logic, it is still one representation in the system even if the class isn't ever instantiated.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
Single responsibility.
An object should do just one thing
Classes are objects. They define the creation of their instances.
In most languages you cannot manipulate classes and use them polymorphically , so you can't mock them or plug them on tests. therefore, you have a global reference too difficult too decouple.
Hmmm... I guess I'm still not convinced. What I'm talking about using these for, I would never want to mock or inherit from.
I could see your argument that this creates strong coupling, but I would only ever call this code in one place and I would want it to fail at the same time as the rest of my user flow. I'll have to think more about the nature of coupling though. That may win me over in the end.
Learn something new every day.
- I am a senior software engineer working in industry, teaching and writing on software design, SOLID principles, DDD and TDD.
Location
Buenos Aires
Education
Computer Science Degree at Universidad de Buenos Aires
I totally agree that singletons are bad, even if it's just for the race conditions they can introduce.
Would you explain more about why static classes violate the single responsibility principle? I went to the post, but I'm still having a hard time seeing this. It appears to me that if the whole class is static, and the function encapsulates business logic, it is still one representation in the system even if the class isn't ever instantiated.
Single responsibility.
An object should do just one thing
Classes are objects. They define the creation of their instances.
In most languages you cannot manipulate classes and use them polymorphically , so you can't mock them or plug them on tests. therefore, you have a global reference too difficult too decouple.
Hmmm... I guess I'm still not convinced. What I'm talking about using these for, I would never want to mock or inherit from.
I could see your argument that this creates strong coupling, but I would only ever call this code in one place and I would want it to fail at the same time as the rest of my user flow. I'll have to think more about the nature of coupling though. That may win me over in the end.
sure !
Coupling is not obvious on small systems.
But it is the infection on larger ones
maximilianocontieri.com/coupling-t...
I'm using this in a 100,000+ line, enterprise scale code base and having great success 😁