31–40 of 76 posts
Coding Pro Tip: Instead of using the Singleton pattern, make one instance of your class at the start of your program and pass it around to its users. Singletons are really just as bad as global variables. Why? Because they are global variables.
And just as handy as global variables.
var server struct {
host string
port string
}
func serverStart() {
server.host = "..."
server.port = "..."
}Coding Pro Tip: Instead of using the Singleton pattern, make one instance of your class at the start of your program and pass it around to its users. Singletons are really just as bad as global variables. Why? Because they are global variables.
> Singletons are really just as bad as global variables. Why? Because they are global variables. And just as handy as global variables.
which means not really handy in a non-thread safe context.
Coding Pro Tip: Instead of using the Singleton pattern, make one instance of your class at the start of your program and pass it around to its users. Singletons are really just as bad as global variables. Why? Because they are global variables.
One could argue that you could just create it in the section of code you want to log - but that just creates noise and you end up repeating code.
logger = Log() # run code to open the file to the last position logger.log("test")
vs
Log.instance().log("test")
Now imagine this was a multi-threaded application - singleton arguments are much different.
> Singletons are really just as bad as global variables. Why? Because they are global variables.
Everyone has their own opinions - but you can't make sweeping generalizations. I'm not saying a global variable is appropriate in every situation - but every language, and project, is different. There are even different dialects of C++ [2].
[1] - http://stackoverflow.com/questions/228164/on-design-patterns...
[2] - http://www.reddit.com/r/programming/comments/197dn1/introduc...
Earlier quoted context omitted.
Yea it's easy enough to use dependency injection to satisfy these supposedly "global" requirements. About the only global state I can tolerate is read-only constants, but even then you are much better off with DI just because of testing.
DI is an antipattern.
I thought there was a lot of literature pretty convincingly arguing that singleton is in fact an anti-pattern.
Singletons are useful and wide spread concepts. What is an anti pattern is implementing them in a way that's not thread safe (which is made worse if your singleton is mutable). Letting DI frameworks handle your singletons is the best way to get the best of both worlds.
Atomic mutable global state is still mutable global state. DI containers mean you don't need a singleton but can just create a single instance which lets you scope it and does not mix lifetime duration and object properties.
Earlier quoted context omitted.
Singletons are useful and wide spread concepts. What is an anti pattern is implementing them in a way that's not thread safe (which is made worse if your singleton is mutable). Letting DI frameworks handle your singletons is the best way to get the best of both worlds.
No no, singletons are pathological liars http://misko.hevery.com/2008/08/17/singletons-are-pathologic... Atomic mutable global state is still mutable global state. DI containers mean you don't need a singleton but can just create a single instance which lets you scope it and does not mix lifetime duration and object properties.
No, only badly implemented ones are.
Besides, this article is seven years old and it was written way before DI with Guice or Dagger became a thing. It's a very outdated perspective (and you will notice that AngularJS, which Misko contributes to, supports both DI and singletons).
Earlier quoted context omitted.
Yea it's easy enough to use dependency injection to satisfy these supposedly "global" requirements. About the only global state I can tolerate is read-only constants, but even then you are much better off with DI just because of testing.
How do handle configuration? Your program starts up, generates some settings, then those need to be shared across all threads to avoid incurring the cost of regenerating during every call to a function.
What's the point of a singleton when you can just have variables in an anonymous struct at root level, and functions defined at root as well? var server struct { host string port string } func serverStart() { server.host = "..." server.port = "..." }
What's the point of a singleton when you can just have variables in an anonymous struct at root level, and functions defined at root as well? var server struct { host string port string } func serverStart() { server.host = "..." server.port = "..." }