tag:blogger.com,1999:blog-3950843830534268483.post8417600035624578446..comments2023-10-29T08:37:26.204-07:00Comments on The Recursion King: Should Singletons be avoided?Pete Kinghttp://www.blogger.com/profile/03438651595079082035noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3950843830534268483.post-65346486578834478482008-01-16T07:29:00.000-08:002008-01-16T07:29:00.000-08:00I'm relating this to Actionscript as that is the t...I'm relating this to Actionscript as that is the technology I'm currently using for development. Actionscript, like many languages, connects classes together through import statements. So addressing your first, point, the relationship is explicit because you must import the singleton class into your custom class in order to access it. It is not globally available implicitly. So, certainly for Actionscript (and other technologies too), it is an explicit declaration that your class will be using the singleton class.<BR/><BR/>Good second point though. If developers are using large amounts of memory or cpu intensive code in a singleton (all possible, nothing inherently restricts you from doing this except good programming practices generally - but you can't bank on common sense winning the day) then you could have a problem.<BR/><BR/>It's good to have another perspective on this to see the potential downsides.Pete Kinghttps://www.blogger.com/profile/03438651595079082035noreply@blogger.comtag:blogger.com,1999:blog-3950843830534268483.post-29458719277137906442008-01-16T05:47:00.000-08:002008-01-16T05:47:00.000-08:00Hi,There are a few reasons you didn't named explai...Hi,<BR/><BR/>There are a few reasons you didn't named explaining why developpers are making so much fuss over singleton.<BR/><BR/>First, by using singleton you are coupling your class/methods/functions with other class without explicitly saying so. Thus your objects interfaces are tainted.<BR/><BR/>Second point is about the lifetime of singletons. Why would you want to create something when it's first accessed ? That means you don't know when it is created (or at least it's not explicit) and that it can be created at the worst time. Also, When do you end the life of a singleton object? Since you don't know when it starts, it's a bit hard to determine when it finishes (meaning that if your singleton is allocating memory, you end up fragmenting a bit ...).<BR/>This whole point could be rejected because singleton are defined by "classes that should be instanciated only once" and, AFAIK, nothing dictates the way they are actually created. But since most programmers instantiate them at first use I think this point is relevant enough to be stated.<BR/><BR/>About unit testing, the problem is states. When several tests are run, it acceptable to think they have been pack'd in a test suite and will be run in a single execution.<BR/>The problem with singleton in that case is that they are persistant and they may have an internal state. You have to be very careful about your tests because of this internal state. You may need to "restart" your singleton (and again, another developper won't necessarily know this because the use of this class isn't in your prototypes).<BR/><BR/>Still, they are very useful in practice :) But as a design pattern there are practical drawbacks one shouldn't ignore.<BR/><BR/>GabrielGabriel Warehttps://www.blogger.com/profile/04765858976134545415noreply@blogger.com