Singletons Are Evil
In either case, the GlobalVariable reference is gone.
I am putting this at the top as it is one of the best articles on the singleton I have seen.... http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx
I too was once a singleton lover. If you prevent yourself from doing singletons for 1 year straight, you will find out one thing....singletons are evil. If you have not prevented yourself for 1 straight year, you have no right to talk. That is like never eating ice cream and saying you know the fries are better. Maybe the fries are better but shut up until you have tried the ice cream first!!! You can still represent the real world and only have one thing(though naturally you just need to make sure you only instantiate one). That is usually done in some top level module and passed down to services(ie. Depenency Injection). The worst thing I have found out about singletons is when it comes to wanting to write reset code(specifically in tests). In a no singleton system, I can just new Service() and if it was designed right, the use of static keyword is rarely used except maybe for constants and all state will be reset....Great for the test setup method. -- http://smallbiztochina.com/I've run into the same problems and a few more. I'm writing up a paper about it. -- MichaelFeathers
I see singletons as the cause of a dichotomy within an ObjectModel. All of a sudden there are two types of objects, those that can be instantiated in a standard fashion and those that cannot be created at all. I would personally rather use a container which governs the number of a given object that can exist in a system and acquire the objects from the container. -- JohnHarby I've never used a singleton to make sure there was only one of something. Singletons usually are used to provide a single point of access to a global service. I always make the singleton separate from the class itself so the class can be used any way you want. The singleton can then use the class. The singleton also doesn't have to instantiate the object. It just has to provide access to the object. The object returned can bet set by any means necessary.
"Use Your Singletons Wisely"http://www-106.ibm.com/developerworks/webservices/library/co-single.html I wrote the article after seeing at least two dozen instances of the following code deep within the server of the project I was working on:
MySingletonObject mySingletonObject = MySingletonObject.getInstance();
MyApp.singletonObject = mySingletonObject;
The rest of the programmers were encouraged to use the singleton objects through M yApp rather than directly. In that case, why the hell are they singletons?! I shook my head for minutes when I ran across this. Then I started ranting. Then I started writing. -- JbRainsberger
Looks fine to me - keep the structural detail in one place to simplify changing the multiplicity later. Works especially well with threads. Still, ranting is good for you.
Theological debate Let's assume that all singletons are evil. We observe that every entity is a singleton. From this we can conclude that everything is evil, including the wiki at c2.com. But if the wiki is evil then it must be lying when it calls singletons evil. This is a contradiction, and so the original assumption must be wrong. Therefore, it follows that singletons are not evil. -- AsimJalis I don't think your argument is sound. The problem with your argument lies in the assumption that every evil thing never tells the truth. Something like this makes the problem clear: all entities are singletons; all singletons are evil; therefore, all entities are evil; all entities are evil; all evil things are things that tell only lies; therefore, all entities are things that tell only lies; the wiki at c2.com is an entity; all entities are things that tell only lies; therefore, the wiki at c2.com is a thing that tells only lies (there should be more about deducing that lies are untrue, the statement about singletons being evil is a lie, blah, blah, blah). The basic problem is that evil things will quite often tell the truth. I don't think it's hard to think of situations in which truth telling in no way impedes the execution of evil or the presence of evilness.
Comments applicable to JavaLanguage: Is Evil
In a good framework, Singletons are never tried to be instantiated twice (leaving a remote occasion of two or more threads doing that). Assuming this, we just need a safe guard of not having another instance. Possible Solution: SingletonsAreGood -- NitinVerma
Doesn't a CeeSharp static class, with its static constructor, provide all the functionality you would ever need from a singleton? -- John Static classes lack polymorphism - you'd have to wrap your static methods in an object if you ever wanted to use it to implement an interface. Still, C# does provide a useful implementation of a singleton through the static mechanism - static constructor can be used to construct a private static member through a protected constructor, which can, in turn, be returned with a property. -- MartinZarate
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
JAVA 객체 작성 및 제거 방법정적 공장 방법 정적 공장 방법의 장점 를 반환할 수 있습니다. 정적 공장 방법의 단점 류 공유되거나 보호된 구조기를 포함하지 않으면 이불류화할 수 없음 여러 개의 구조기 파라미터를 만났을 때 구축기를 고려해야 한다...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.