A singleton for your UserInterface makes only sense when all of the following conditions are met:

• having more than one instance cannot be allowed, because that would cause a misfunction in the program if two of those objects exist at the same time

• you are sure you don't need any unit tests for the code which requests the singleton - unit tests which shall be isolated from a UserInterface

• you know for sure you will never need inheritance for UserInterface.

If not all three conditions are met, a singleton is either unsuitable or overdesigned. This is pretty often the case in real-world scemarios, that's why Singleton is often considered to be an anti-pattern.

A singleton for your UserInterface makes only sense when all of the following conditions are met:

• having more than one instance cannot be allowed, because that would cause a misfunction in the program if two of those objects exist at the same time

• you know for sure you will never need inheritance for UserInterface.

If not both conditions are met, a singleton is either unsuitable or overdesigned. This is pretty often the case in real-world scemarios, that's why Singleton is often considered to be an anti-pattern.

Note also that when there are components depending on the "singleton candidate", passing the latter by constructor injection into the components / classes may simplify unit testing. By this kind of design, it does not make a huge difference if the injected object is a singleton or not. In case all the depending components are implemented that way, the "singleton mechanics" is probably not worth the hassle, since you can make sure there is only one object of the "singleton candidate" in "wiring up" part of the program.