Timeline for Are immutable/stateless singletons bad?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17, 2022 at 8:50 | comment | added | JonasH | To provide an example. In .Net many methods take a object for doing comparisons (ex. IComparable). In many cases the implementation will be stateless, but you cannot use a static class since you need an actual object. But you would only ever need one object, so a singleton would be perfectly appropriate. | |
| Jan 8, 2013 at 6:49 | comment | added | Random42 | @Billy ONeal I would agree with you for a typical singleton, but I do not see problems with a stateless singleton; that's why I asked this question. If the object is stateless, then different clients of this object can share that object; why shouldn't they? I don't see anything wrong with a stateless global value (if it is stateless, technically it is not a variable, since it cannot vary, being... stateless). | |
| Jan 7, 2013 at 22:27 | comment | added | Billy ONeal | @m3th0dman: Yes, I'm saying it shouldn't be a singleton. Making anything a singleton is an extremely limiting decision in a design -- you should have as few of them as possible. They are no better than global variables. You would be better off having the factory just having a static member variable containing the item in question. There's no need to encode that constraint into the design of the other objects. | |
| Jan 7, 2013 at 22:17 | comment | added | Random42 | @BillyONeal The factory maintains it's own reference, and the object can be accessed only via the factory. Basically it is still a singleton since it has only one instance and has a global point of access (even via the factory). Why do you say it shouldn't be a singleton? If it is stateless, why should you need an instance each time is needed? | |
| Jan 7, 2013 at 19:14 | comment | added | Billy ONeal | @m3th0dman: Then the class in question shouldn't be a singleton. The factory should maintain its own reference. | |
| Jan 7, 2013 at 6:57 | comment | added | Random42 | @BillyONeal Not necessarily; you can provide a factory over them, factory which always gives the same references. | |
| Jan 6, 2013 at 19:29 | comment | added | Billy ONeal | @m3th0dman: Because to get the singleton object requires specifying the name of the singleton at the call site. Which means that you aren't using polymorphic behavior. Which means that composition is far more flexible than inheritance. | |
| Jan 6, 2013 at 11:36 | comment | added | Random42 | @BillyONeal Why not? What forbids me from making my subclasses singletons? Think about EJB 3.1 and @Singleton annotation on an EJB class which is obliged to inherit from an interface which represents the business logic. | |
| Jan 6, 2013 at 1:49 | comment | added | Billy ONeal | @m3th0dman: Erm, no. I can be pretty positive without knowing anything about the domain model. Inheritance is for polymorphic behavior. But as a singleton, you aren't going to have polymorphic behavior. | |
| Jan 5, 2013 at 12:18 | comment | added | Random42 | @BillyONeal You can say that something is good or bad for inheritance if you know the domain model, what is to be modeled in that way... | |
| Jan 4, 2013 at 15:10 | comment | added | Billy ONeal | @m3th0dman: Doesn't sound like a good place for inheritance. | |
| Jan 4, 2013 at 11:07 | comment | added | Random42 | Why not use a class with static methods? Inheritance for example... | |
| Jan 4, 2013 at 10:36 | review | First posts | |||
| Jan 4, 2013 at 10:43 | |||||
| Jan 4, 2013 at 10:27 | history | edited | StampedeXV | CC BY-SA 3.0 | added 120 characters in body |
| Jan 4, 2013 at 10:18 | history | answered | StampedeXV | CC BY-SA 3.0 |