There are ways to code that potentially cause problems, and there are ways to avoid actually causing those problems. The reality is: Every code "pattern" can be abused. So the real lesson to learn is: Never get emotionally attached to a piece of code. And as a corollary: Never get emotionally outraged over a piece of someone else's code. Children get emotional about things; adults are better than that.
Great video! Now do an episode on CLEAN architecture and how many layers one has to change every time one needs to add a feature.. it's depressing... entire layers that are just forwarding calls..
I’m not a huge fan of super intricate architectures with tons of layers. I’m sure they have their place, but most of the time it’s more trouble than it’s worth.
The same with Android, people tend to use it to store state but it can be really huge headache if not properly initialized due to lifecycles. Thanks for the information.
Sean, love the content. Been following for years now and have your courses. I'm just a hobbyist who codes on the side for fun. Something I struggle with is learning new stuff with limited information online that I can find. Example for me right now is trying to drag and drop between lists in SwiftUI. I try diving into the documentation and find myself just getting more confused at times. Do you have any suggestions on learning new topics? Thought it might be an interesting video as well, having you learn something with us following along.
Great job. I’m not one of those proposing ‘gotcha’ interview questions… but if someone showed up and badmouthed UserDefaults and said they should not be used, I’d probably vote no on hiring. Apple knew exactly what they were creating. And just like the girl with the hammer, anything can be misused.
To help developers understand how singletons can go wrong, it's important to consider the problem of shared mutable state. Thankfully we now have actors that makes this easier, but with classes singletons can be accessed globally from any thread and aren't thread safe.
I like your balanced overview! Personally I'm not the biggest fan of the Singleton pattern, but I actually use it quite a bit in case where multiple instances really don't make sense. Alternatively I prefer to use an enum with static functions, so there can just never be an instance of the thing.
Hi Sean, love ur short and sweet easy to learn videos. Ive been watching ur videos for several years. Thanks a lot for all the info you've shared over time. I have a small suggestion regarding this video. You could dive into a code snippet explaining the cons more. Like multiple objects updating a variable in a singleton. Also I agree DI is a whole other concept. DI is the secret sauce for achieving great code architecture + testability. Looking forward to your sharing.
I have to point out that if a singleton is created using 'static let' with 'private init' the instance is lazily created, atomic, and thread-safe. If it is created with 'static var', it will NOT be thread safe but still lazily created and atomic.
Omg I love apple! Calling that “standard” instead of “instance” makes soooo much more sense! That’s why I want to migrate from a react career to ios.. swift seems marvelous!
"The most misused design pattern in iOS dev" would be a more accurate title for this video, as you said there is nothing wrong about singleton pattern itself.
Expert (higher comprehension of reality than merely a veteran, that has learned a lot from painful experience and actively engaged in searching out how to avoid making the same mostakes repeatedly): never creates new ones in applications, removes those not in external libraries that are already there previously, as time permits, because it’s actually easy to design an arbitrarily large system with a single instance of an object instead of using the OO fancy renamed version of a global variable.
Hi Sean, would you be open to doing a tutorial on combine anytime soon? I use RxSwift most of the time when I work and would love to learn about combine and transition to that but I don’t want to yet just because I’m looking for the right resource to teach me and I’m sure it’s you because I like how you teach and break down concepts.
Thanks for the video. If uniqueness is the key reason for using singleton, then how do I architect a layer that I would like to assess from every where within my app but uniqueness is not required. An example of such use case is like FirebaseManager, or TwitterClient, where these files are the central classes to handle firebase and twitter networking calls.
I don't think of a singleton as requiring only one instance; it's more of a way to access global services. It solves the service discovery problem. It's really no different than scoping through a namespace. For example, you can unit test through the class without using the singleton. An infinite chain of passing references is far uglier IMHO. Thread safety is not an argument because any shared object must deal with thread safety regardless of how it's accessed. If the once instance thing is a hangup, you can create the class and then put the singleton in another ClassService type class.
A huge hole in the narrative here is that UserDefaults is not, as far as I can tell, a singleton. To recap for those who didn't get it the first dozen times, a singleton is a class that can only be instantiated _once_. UserDefaults is not such a class. Yes, it has a `.standard` method that returns a shared object, but you can still instantiate as many more instances of UserDefaults as you like (and there are good reasons that you might want to do that). Similarly, the other classes that you mention as examples, FileManager and URLSession, are also not singletons.
There are ways to code that potentially cause problems, and there are ways to avoid actually causing those problems. The reality is: Every code "pattern" can be abused. So the real lesson to learn is: Never get emotionally attached to a piece of code. And as a corollary: Never get emotionally outraged over a piece of someone else's code. Children get emotional about things; adults are better than that.
As a jr ios dev I would love an update on what to use instead of singletons, great video!
Great video! Now do an episode on CLEAN architecture and how many layers one has to change every time one needs to add a feature.. it's depressing... entire layers that are just forwarding calls..
I’m not a huge fan of super intricate architectures with tons of layers. I’m sure they have their place, but most of the time it’s more trouble than it’s worth.
@@seanallen exactly...
I only use singletons for my core data stacks, which then uses combine to feed the rest of my application
Nice
The same with Android, people tend to use it to store state but it can be really huge headache if not properly initialized due to lifecycles. Thanks for the information.
Happy to help!
Sean, love the content. Been following for years now and have your courses. I'm just a hobbyist who codes on the side for fun. Something I struggle with is learning new stuff with limited information online that I can find. Example for me right now is trying to drag and drop between lists in SwiftUI. I try diving into the documentation and find myself just getting more confused at times. Do you have any suggestions on learning new topics? Thought it might be an interesting video as well, having you learn something with us following along.
Great job.
I’m not one of those proposing ‘gotcha’ interview questions… but if someone showed up and badmouthed UserDefaults and said they should not be used, I’d probably vote no on hiring. Apple knew exactly what they were creating. And just like the girl with the hammer, anything can be misused.
Agreed 👍
To help developers understand how singletons can go wrong, it's important to consider the problem of shared mutable state. Thankfully we now have actors that makes this easier, but with classes singletons can be accessed globally from any thread and aren't thread safe.
I like your balanced overview! Personally I'm not the biggest fan of the Singleton pattern, but I actually use it quite a bit in case where multiple instances really don't make sense. Alternatively I prefer to use an enum with static functions, so there can just never be an instance of the thing.
Thanks Flo! Good tip about the enums.
That was amazing and you explained it very nice thank you so much man ❤
Hi Sean, love ur short and sweet easy to learn videos.
Ive been watching ur videos for several years.
Thanks a lot for all the info you've shared over time.
I have a small suggestion regarding this video.
You could dive into a code snippet explaining the cons more. Like multiple objects updating a variable in a singleton.
Also I agree DI is a whole other concept. DI is the secret sauce for achieving great code architecture + testability. Looking forward to your sharing.
i really like the way you explain the Singleton
Thanks, Sean. Looking forward to the DI video too :)
Thanks for content just one point UserDefaults is not a singleton as it has a public constructors, init() and init?(suiteName suitename: String?)
Good explained
Glad it helped!
Great explanation of the pros and cons
thank you bro, how DI will solve singleton
Thank you!
I have to point out that if a singleton is created using 'static let' with 'private init' the instance is lazily created, atomic, and thread-safe. If it is created with 'static var', it will NOT be thread safe but still lazily created and atomic.
Omg I love apple! Calling that “standard” instead of “instance” makes soooo much more sense! That’s why I want to migrate from a react career to ios.. swift seems marvelous!
Can't quite tell if this is sarcasm but this is horrible naming in my opinion.
"The most misused design pattern in iOS dev" would be a more accurate title for this video, as you said there is nothing wrong about singleton pattern itself.
Great info as usual!!❤
Right on!
The evolution of singleton: New coder: YAY SINGLETONS EVERYWHERE / Amateur coder: no never use it!!! / Veteran: Yeah they are ok
Expert (higher comprehension of reality than merely a veteran, that has learned a lot from painful experience and actively engaged in searching out how to avoid making the same mostakes repeatedly): never creates new ones in applications, removes those not in external libraries that are already there previously, as time permits, because it’s actually easy to design an arbitrarily large system with a single instance of an object instead of using the OO fancy renamed version of a global variable.
Hi Sean, would you be open to doing a tutorial on combine anytime soon?
I use RxSwift most of the time when I work and would love to learn about combine and transition to that but I don’t want to yet just because I’m looking for the right resource to teach me and I’m sure it’s you because I like how you teach and break down concepts.
Can I at least use singletons for my preview data? Please?
Thanks for the video. If uniqueness is the key reason for using singleton, then how do I architect a layer that I would like to assess from every where within my app but uniqueness is not required. An example of such use case is like FirebaseManager, or TwitterClient, where these files are the central classes to handle firebase and twitter networking calls.
practically every 3rd party library exposes their public functions via a singleton (especially for API services)
I love singleton. Bummer it's not a good practice.
like sharedPreferences in android?
I don't think of a singleton as requiring only one instance; it's more of a way to access global services. It solves the service discovery problem. It's really no different than scoping through a namespace. For example, you can unit test through the class without using the singleton. An infinite chain of passing references is far uglier IMHO. Thread safety is not an argument because any shared object must deal with thread safety regardless of how it's accessed. If the once instance thing is a hangup, you can create the class and then put the singleton in another ClassService type class.
A huge hole in the narrative here is that UserDefaults is not, as far as I can tell, a singleton. To recap for those who didn't get it the first dozen times, a singleton is a class that can only be instantiated _once_. UserDefaults is not such a class. Yes, it has a `.standard` method that returns a shared object, but you can still instantiate as many more instances of UserDefaults as you like (and there are good reasons that you might want to do that). Similarly, the other classes that you mention as examples, FileManager and URLSession, are also not singletons.
Nice
👌
Worst Design Patter in iOS Dev is PIDOR. But please don't make a video about it.