It looks like both your questions are just the fantasy of interviewers; they are not based on any well-known statements; it's hard to follow their logic. It would be natural to suggest that many people tests cases which they face in their practice, and that experience could be… will, different.
- Take the first interview question (I'm skipping your own question for now, will come to it below). Why anyone should ever suggest scenarios to existing design patterns? This would be counter-productive. Such questions don't teach right thinking and hence don't test it. Right thinking would be a response to a problem of some scenario, and then some solution could involve some pattern, or not. Patterns are published in hope to help solving problems, not to mangle "scenarios" to make a pattern fit. But the question is posed, how to answer it? I would say, there is no a problem of passing a singleton object as a parameter. No problem at all — object is an object, anything can be passed. But then why would we need a singleton? A parameters is needed as an abstraction device. That is, according to its purpose, the actual object passed as a parameter should generally be different. The body of the method with a parameter remains agnostic about what that object is and is ready to work to whatever is passed. But a singleton object is designed to be the same all the time. Why passing it?
Still, there are cases when passing a singleton would make sense. For example, you can have different layer in your application architecture, and only one layer uses the singleton as a singleton, another layer "does not know" anything about the singleton, but works with its type. In other word, it has some method parameter; and the method is, as always, agnostic to its parameters. In some calls, it could be singleton, in others, it is not; the functionality of the method does not rely on that (and this would be very good). And another layer always passes a singleton. Something like that. - I don't see any sense in the second interview question. The pattern can have many different designs; some using an interface, some not. Both kinds of designs, with interface or without interface, can be good or bad. In other words, having an interface in a singleton design is not characteristic to this design pattern. Again, the question probably reflects the experience of the interviewer. I would guess, either narrow experience, not not properly analyzed or generalized.
- And finally, I'll try to answer your own question about "static singleton". In a way, it's more interesting than both interview question, but is not quite correct. "Static" — what? Static class representing singleton functionality? The use of static member in a singleton class? A static object immediately exposed to the singleton user? What?
Whatever it is, a static object is usually involved. Because, ultimately the singleton object should always be the same. From the other hand, it would be bad to directly expose a static object to the user. For further detail, please see the code sample I referenced below.
From the other hand, it's not really required to use anything static for singleton implementation. Why? Because it's main characteristic "always one", "always the same object" has its scope. Most usually, this is the application domain of a single application. But it could be something else, say, a singleton maintaining its identity across all of the applications on the same computer (or the same session). Or, even wider, across many computers communicating with the same online service.
But let's back to the most usual singleton, the one in the scope of the application domain. Imagine that you create some object in a normal way, only once, in your program's entry point method ("Main"). And then pass this only object to all other methods (including constructors). The object is still only one. By the way, this is another answer to the first interview question.
Even though the object in this example is single, some may not agree to call it "singleton", but this is just a non-essential matter of terminology.
To illustrate all discussed questions, I want to show some implementation. I must say, I saw a number of bad singleton implementations, but what I think I want to reference here is a good example of the singleton design implemented in C#:
C# in Depth: Implementing the Singleton Pattern[
^].
Pay attention: 1) no interfaces are mentioned; 2)
static is essentially involved. :-)
—SA
Submit an article or tip