google-singleton-detector - Project Hosting on Google Code

Last 7 days Dec 24, 2009 Usage (Details on how to use this program.) Wiki page commented on by amoiz.sh...@gmail.com - good project! good project! Earlier this year Nov 19, 2009 WhySingletonsAreControversial (A brief explanation of the problems with singletons.) Wiki page commented on by drewmca - Of course when one class references another, there's coupling. I think the issue with singletons is that their use can hide the particulars of those dependencies in multiple places within source code, making changes and testing much more difficult to deal with. That's what led to the rise of dependency injection's popularity in the Java world. Those dependencies are explicitly stated in the class definition, avoiding the use of any singletons behind the scenes. That means, for example, that it's easy to test a class that's dependent on a db and mail connection because you can set the connection references directly in a test class using either a test db or mail account, or a mocked connection. If you're using a singleton in your implementation without that kind of explicit dependency declaration, you don't know how or where the connection is coming from and it's difficult to swap out for testing purposes, let alone when implementation details change. I think that singletons in and of themselves aren't bad, though. It's just that using them behind the scenes makes testing and debugging more difficult than it could be otherwise. Of course when one class references another, there's coupling. I think the issue with singletons is that their use can hide the particulars of those dependencies in multiple places within source code, making changes and testing much more difficult to deal with. That's what led to the rise of dependency injection's popularity in the Java world. Those dependencies are explicitly stated in the class definition, avoiding the use of any singletons behind the scenes. That means, for example, that it's easy to test a class that's dependent on a db and mail connection because you can set the connection references directly in a test class using either a test db or mail account, or a mocked connection. If you're using a singleton in your implementation without that kind of explicit dependency declaration, you don't know how or where the connection is coming from and it's difficult to swap out for testing purposes, let alone when implementation details change. I think that singletons in and of themselves aren't bad, though. It's just that using them behind the scenes makes testing and debugging more difficult than it could be otherwise. Sep 28, 2009 WhySingletonsAreControversial (A brief explanation of the problems with singletons.) Wiki page commented on by csgrimes1 - When one class references another class, it is coupled to that class, period. It does not matter if either class is a singleton. Coupling is unavoidable in software. You can not reduce it by avoiding the singleton pattern. Further, the 'getInstance()' method of a singleton gives you a reference to an object. At that point, you don't care if the object is singleton or not, so long as it exposes it instance methods instead of statics. There is a time and a place for singleton. The real problems with singletons are the problems with all statics - holding memory, synchronizing initialization and access, etc. When one class references another class, it is coupled to that class, period. It does not matter if either class is a singleton. Coupling is unavoidable in software. You can not reduce it by avoiding the singleton pattern. Further, the 'getInstance()' method of a singleton gives you a reference to an object. At that point, you don't care if the object is singleton or not, so long as it exposes it instance methods instead of statics. There is a time and a place for singleton. The real problems with singletons are the problems with all statics - holding memory, synchronizing initialization and access, etc. Older Aug 06, 2008 issue 7 (graphml elements are all positioned in the same place) reported by ioannis.cherouvim - The generated graphml output does not contain any elements such as: <y:Geometry height="30.0" width="30.0" x="177.0" y="10.0"/> So all nodes on the graph are positioned on the same spot, thus making the graph non usable. I used gsd-0.7.3.zip thanks The generated graphml output does not contain any elements such as: <y:Geometry height="30.0" width="30.0" x="177.0" y="10.0"/> So all nodes on the graph are positioned on the same spot, thus making the graph non usable. I used gsd-0.7.3.zip thanks

WhySingletonsAreControversial (A brief explanation of the problems with singletons.) Wiki page commented on by drewmca - Of course when one class references another, there's coupling. I think the issue with singletons is that their use can hide the particulars of those dependencies in multiple places within source code, making changes and testing much more difficult to deal with. That's what led to the rise of dependency injection's popularity in the Java world. Those dependencies are explicitly stated in the class definition, avoiding the use of any singletons behind the scenes. That means, for example, that it's easy to test a class that's dependent on a db and mail connection because you can set the connection references directly in a test class using either a test db or mail account, or a mocked connection. If you're using a singleton in your implementation without that kind of explicit dependency declaration, you don't know how or where the connection is coming from and it's difficult to swap out for testing purposes, let alone when implementation details change. I think that singletons in and of themselves aren't bad, though. It's just that using them behind the scenes makes testing and debugging more difficult than it could be otherwise.

Of course when one class references another, there's coupling. I think the issue with singletons is that their use can hide the particulars of those dependencies in multiple places within source code, making changes and testing much more difficult to deal with. That's what led to the rise of dependency injection's popularity in the Java world. Those dependencies are explicitly stated in the class definition, avoiding the use of any singletons behind the scenes. That means, for example, that it's easy to test a class that's dependent on a db and mail connection because you can set the connection references directly in a test class using either a test db or mail account, or a mocked connection. If you're using a singleton in your implementation without that kind of explicit dependency declaration, you don't know how or where the connection is coming from and it's difficult to swap out for testing purposes, let alone when implementation details change. I think that singletons in and of themselves aren't bad, though. It's just that using them behind the scenes makes testing and debugging more difficult than it could be otherwise.

Last 7 days

Earlier this year

Older