2009/4/20 Michael Roberts <mike@mjr104.co.uk>:
sorry to be pedantic but Michael's right. Â even if the second client of the class is a test where you make an instance on the fly, assert a few things and clean it up. Â You then have at least 2 instances. the singleton and short-lived adhoc ones. Â systems with dependencies on global state or behaviour are very hard to test.
Thanks, for argument! I'm also trying to be pedantic when proposing this. :) My point was, that its obviously an overkill to have a singleton<class> linked with singleton<instance> without strong evidences where multiple instances could be useful.
cheers,
Mike
On Mon, Apr 20, 2009 at 6:43 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2009/4/20 Michael Rueger <m.rueger@acm.org>:
Igor Stasenko wrote:
Another thing, that i think it would be better is to not have an instance side methods. Since we never need a multiple instances of InputEventFetcher in system, then instead of singleton scheme, it would be better to move all methods and ivars to class side - simply because a class is already singleton. This will help to avoid discrepancies, like we just met.
-10000
Using singleton instances is a proven design pattern. And, you never know if you won't need more than one input fetcher ;-)
Clearly, this is not the case, because your code hosted on a single VM ;) and its the only source of events for fetcher.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.