Could a Swift Singleton be a class with purely class functions

Question

This feels like the discussion stopped a couple of Swift iterations ago, but I'm curious that in the discussions, it was never suggested (or if it was I never saw it) that a singleton could just be a class with purely class functions, eg -

class MySingleton {

    private static var someVar: String?
    private static var someOtherVar: SomeType?

    class func start() {
        // etc...
    }

    class func doSomething() {
        // etc...
    }

    // etc, etc...
}

Are there any good reasons why we shouldn't do this? I can't think of any.

Possible duplicate of https://stackoverflow.com/questions/36312461/singleton-vs-staticclass-variables — Martin R, Jan 12 '18 at 11:32
Yeah - you could be right - I didn't find that when I was looking — SomaMan, Jan 12 '18 at 12:04
One situation to consider is if you ever need to 'reset' your singleton by which I mean return it to it's initial state. With a 'proper' singleton you can just drop your current instance and create a new one but with your approach you have to have some kind of method that resets everything and it's easy to miss something out from that. — Upholder Of Truth, Jan 12 '18 at 14:14
One issue would be to prevent subclassing, and that could be solved by using `final class` or `struct` instead. Also, consider to hide your initializer eventually: https://stackoverflow.com/a/42569039/1033581 — Cœur, Mar 12 '18 at 04:53

score 0 · Answer 1 · edited Jun 20 '20 at 09:12

If an object is never instantiated, it's not a singleton. There are no instances of the object, not just a single instance.

There's nothing inherently wrong with doing that, but what's the benefit?

EDIT

It strikes me that the real comparison is between a class that only has class methods and global functions.

In that comparison, the benefit I see is name-spacing. When you create class methods, you have to qualify function calls with the name of the class, so you can say

SomeClass.someMethod()

or

SomeOtherClass.someMethod()

Those are 2 distinct functions and it is obvious that they are distinct functions.

With global functions, you simply say

someMethod()

If at a future date you merge in somebody else's code that also has a global function someMethod() you will get a compiler error about a duplicate function and have to resolve it.

A benefit appears to be that you don't have to instantiate anything or worry about private inits. I realise it's negligible, but somehow it appears more "honest". I know it's not a singleton, but the effect is the same - maybe I should have worded it better. — SomaMan, Jan 12 '18 at 11:49

score 0 · Answer 2 · answered Jan 12 '18 at 11:54

What do you want to achieve?

In my experience your approach is fine, if

you don't want to create an instance of your class
you don't care, that someone can create an instance of your class (which does not have any benefits, but is still technically possible).
someVar and someOtherVar should contain always the same value for all instances.

Another approach is to have a sharedInstance

class MySingleton {
    private(set) static var sharedInstance = MySingleton()
    private var someVar: String?
    private var someOtherVar: SomeType?

    func start() {
        // etc...
    }

    func doSomething() {
        // etc...
    }

    // etc, etc...
}

This gives you more flexibility.

You can call MySingleton.sharedInstance.start() if you want to use the shared instance.
But on the other hand, you can still create your own instance like let customInstance = MySingleton, with its own values for someVar and someOtherVar.

So it really depends on what you want to achieve. If you want to be sure, that no one can create another instance with its own vars, then your approach is safer than my alternative.

In that case, you might even want to consider to make the class final, so no one can create a subclass that behaves differently.

Thanks - I should have made it clear, I'm completely familiar with the normal approaches for creating singletons, & sharedInstance, etc, I was just curious why we never use this approach. I know that Apple themselves do it with eg UIView.animate, but I've not really seen it elsewhere. Final would be good, but as to instantiating the class, that would seem pointless. — SomaMan, Jan 12 '18 at 12:03
In my opinion if just anything can create an instance of the class then it is not really a singleton. It's just a class which has it's own shared instance. The idea of a singleton is there is only ever one instance of it. Not that this invalidates your point totally and this approach would still work. — Upholder Of Truth, Jan 12 '18 at 14:17

Could a Swift Singleton be a class with purely class functions

2 Answers2

EDIT