There are always other alternatives to singleton patterns. If this was all we were doing we could easily do an extension or helper function without needing to break out an entire class and singleton pattern. In the FileManager case we get nicer API calls without having to deal with NSError or looking up the documents directory. Its important to look at the benefits and see why you are using a singleton. Not all third-party code has to be wrapped. Now that you know the singleton pattern beware of going crazy and trying to use it where it doesn't belong. In the example above we saw how singletons can be used to wrap framework/third-party code. Singletons are probably so few that I should already know that there's a sharedDataAccess variable used throughout the app. As a Swift developer I know that global string constants and global functions can be accessed in any other file of the app. For a single iOS app I don't ever see this as too big of a problem. So far the Apple's APIs I've seen encapsulates it but that might just be because they were written in Objective-C.ĭ = 1Ī big argument for not having a global variable is namespace issues where you might run into variable name clashing in other files. You could argue that keeping it encapsulated within the class makes it easier to use since you can autocomplete and the class it belongs to seems like a natural way to access it. You'd need to create an unnecessary method to just return a variable and then anytime you have to access the singleton you'll need to type the class as a prefix and that is also unnecessary overhead. While I try to avoid making anything global I think the alternative creates too much overhead. Even Apple uses them for notifications, user defaults, and file management. While singleton objects are generally frowned upon due to their global complexity they are also solving complexity issues when used correctly. When you have multiple places in the app that need to update a central storage location then it could be a potential candidate. I have found this pattern to be especially useful with a class that persists data or wrapping a framework that persists or syncs data from various places in the app. I like to break out some of the complexity in the AppDelegate into its own singleton, like for the Core Data work I like to have a DataAccess singleton. Good use cases for the singleton pattern are usually when you need to manage something in particular throughout your app. There is only 1 application so this makes sense. One example is the UIApplication singleton. This pattern should only be used when it makes sense that there can only be 1 of that object. It is your responsibility to know or to document that it is meant to be used as a singleton.Ī singleton is a global object and that one single instance can be referenced from any file. There's no real way to make an object only be allowed to be a Singleton instance in Objective-C, and as far as I know the same holds true for Swift. If you've programmed in Objective-C before then you already know it interprets the "restricts" part of that definition loosely. According to Wikipedia: "In software engineering, the singleton pattern is a design pattern that restricts the instantiation of a class to one object".
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |