Everyone seems to be bullying on the poor singleton sample, the general public name it anti-pattern. However what precisely is a singleton class and why is it so dangerous?

What’s a singleton?

It is a very talked-about and generally adopted sample due to simplicity. A singleton class can solely have precisely one occasion by means of the complete software lifecycle. That single occasion is barely accessible by means of a static property and the initialized object is often shared globally. It is like a worldwide variable. 🌏

International variables and states

Singletons have dangerous repute as a result of they share international mutable states. The worldwide key phrase is at all times feared even within the circle of skilled builders. International states & variables are the hotbed of uncomfortable side effects. International variables will be accessed from wherever of your program so your lessons that use them will develop into stateful, unsecure, tight coupled and laborious to debug. It is not a superb observe to share states alongside objects by means of this manner for apparent causes. 🤮

Uncomfortable side effects

You must scope and isolate your variables as a lot as you possibly can and reduce the statefullness of your code. This can eradicate uncomfortable side effects, make your code safer to make use of. Take into account the next instance:

var international = 0


func sq.(_ x: Int) -> Int {
    international = x
    return x * x
}

international = 1;
var consequence = sq.(5)
consequence += international 
print(consequence) 

The sq. methodology is written by another person, who wished to retailer the enter in the identical international variable for some motive. Now once you name that perform you will not be avare of this, till you have a look at his code. Think about this type of points inside a undertaking with a lot of oop lessons written by a number of code authors… good luck with the military of BUGS! 🐛🐛🐛

The key lifetime of a singleton object

Singletons are created as soon as and stay endlessly, they work nearly precisely like international variables and that is why it’s important to be extraordinarily cautious with them. You must solely handle these states with singletons that lasts for the entire lifecycle of the app. For instance user-specific classes are normally dangerous practices and you need to rethink your design. Additionally Swift just isn’t thread protected by default, so in case you are working with singletons it’s important to be ready for multi-threading points as effectively. But when they’re so problematic, should not we merely keep away from them completely? The reply isn’t any. 🚫

When to make use of a singleton class?

For instance UIApplication is probably a singleton as a result of there needs to be just one software occasion, and it ought to stay till you shut it down. That makes simply the right instance for a singleton. One other use case could be a Logger class. It is protected to make use of a singleton as a result of your software will not behave any completely different if a logger is turned on or not. Noone else will personal or handle the logger and you will solely go data into the logger, so states cannot be tousled. Conclusion: a console or a logger class is sort of an appropriate state of affairs for the utilization of the singleton sample. 👏

Console.default.discover("Hiya I am a singleton!")

There are a a lot of “singletonish” (not the whole lot is a real singleton object) use circumstances in Apple frameworks, here’s a quick checklist, so you possibly can have a little bit inspiration:

• HTTPCookieStorage.shared
  • URLCredentialStorage.shared
  • URLSessionConfiguration.default
  • URLSession.shared
  • FileManager.default
  • Bundle.important
  • UserDefaults.customary
  • NotificationCenter.default
  • UIScreen.important
  • UIDevice.present
  • UIApplication.shared
  • MPMusicPlayerController.systemMusicPlayer
  • GKLocalPlayer.localPlayer()
  • SKPaymentQueue.default()
  • WCSession.default
  • CKContainer.default()
  • and so on.

I’ve seen a lot of supervisor lessons applied as singletons, akin to community, location or core information managers, however these objects normally should not be singletons, just because it may be multiple of them. 💩

Singleton sample will be very helpful, but it surely needs to be used with warning

If you wish to flip one thing right into a singleton, ask your self these questions:

Will the rest personal, handle or be chargeable for it? Is there going to be precisely one occasion?

• Will or not it’s a worldwide state variable?
• Ought to I actually use a globally shared object?
• Ought to stay by means of the entire app lifecycle?
• Is there any alternate options for it?

If the solutions is clearly a sure for the whole lot above, then you possibly can “safely” use a singleton or a worldwide variable to retailer your information. 🎉🎉🎉

Methods to create a singleton in Swift?

It is very easy to make a singleton object in Swift, however please at all times suppose twice and take into account alternate options earlier than you apply this design sample.

class Singleton {

    static let shared = Singleton()

    personal init() {
        
    }
}
let singleton = Singleton.shared

These days I am at all times creating one particular singleton object, that is known as App. This fashion I can hook up each software associated international state properties into that one singleton. The naming conference additionally helps me to reevaluate what goes into it. 💡

Methods to eradicate singletons?

If there’s different approach you need to go along with that in ~90% of the circumstances. The commonest different answer for singletons is dependency injection. First you need to summary the singleton strategies right into a protocol, then you should use the singleton because the default implementation if it is nonetheless wanted. Now you possibly can inject the singleton or a refactored object into the fitting place. This fashion your code will be examined with mocked objects of the protocol, even ignoring the singleton itself. 😎

typealias DataCompletionBlock = (Information?) -> Void


protocol Session {
    func make(request: URLRequest, completionHandler: @escaping DataCompletionBlock)
}


extension URLSession: Session {

    func make(request: URLRequest, completionHandler: @escaping DataCompletionBlock) {
        let job = self.dataTask(with: request) { information, _, _ in
            completionHandler(information)
        }
        job.resume()
    }
}

class ApiService {

    var session: Session

    
    init(session: Session = URLSession.shared) {
        self.session = session
    }

    func load(_ request: URLRequest, completionHandler: @escaping DataCompletionBlock) {
        self.session.make(request: request, completionHandler: completionHandler)
    }
}



class MockedSession: Session {

    func make(request: URLRequest, completionHandler: @escaping DataCompletionBlock) {
        completionHandler("Mocked information response".information(utilizing: .utf8))
    }
}


func check() {
    let api = ApiService(session: MockedSession())
    let request = URLRequest(url: URL(string: "https://localhost/")!)
    api.load(request) { information in
        print(String(information: information!, encoding: .utf8)!)
    }
}
check()

As you possibly can see the singleton sample may be very simple to implement, but it surely’s actually laborious to decide about it is software varieties. I am not saying that it is an anti-pattern, as a result of it is clearly not, however take care in case you are planning to take care of singletons. 😉