Singleton, MVC and Factory patterns are the design patterns I use very often. I also use static classes, more often than Singleton, but static classes are not design patterns. For every implementation of Singleton, one can come out with an alternate implementation with static classes. Lot of critics argue that Singleton is not the right way to program, and it is an anti-pattern. Singleton patterns can be considered as substitutions for global variables, and they are most useful when you want to use the same instance all over your program. Using one object ( say of type Class A) to manage instances of a different class (say Class B) , and providing all functionalities using the objects of Class B is obviously a better coding practice. This is a better replacement of Singleton pattern, compared with static classes. Here is an interesting discussing I'd with Cybereal at #java@irc.freenode.net. Cybereal explains why Singleton is a bad wrt to dependency injection.
(12:03:11 AM) codeshepherd: cybereal .. Aren't Singleton the best suitable implementations for Database connection pooling ?
(12:03:43 AM) codeshepherd: In a more general way... Singletons are best suitable to manager global variables..
(12:03:53 AM) cybereal: singletons *ARE* global variables, basically
(12:03:56 AM) cybereal: and that's why they are bad
(12:04:24 AM) cybereal: codeshepherd: you shouldn't need to use a singleton to use the same resource across a program
(12:04:50 AM) cybereal: but because people are lazy about typing and passing on dependency information to instantiated objects, you find they will lean towards singletons to do little more than save some keystrokes
(12:05:01 AM) cybereal: It's really hard to justify it for any other reason
(12:05:41 AM) cybereal: codeshepherd: despite being an anti-pattern, it does get used frequently so you'll still need to know how to deal with it, and sometimes to work around them
(12:06:02 AM) cybereal: at least in java if you really need to you can bury a singleton in a separate classloader instance
(12:06:13 AM) codeshepherd: So how will you implement a Database connection pool? Just a static class ?
(12:06:30 AM) cybereal: no, a regular class that you pass around to all the new instances of other classes that need to know about it
(12:06:44 AM) cybereal: like handing out invitations to a party
(12:06:58 AM) cybereal: you don't hand out houses with those invitations, and people aren't expected to figure out the address themselves
(12:07:06 AM) codeshepherd: then.. some dumb guy who comes tomorrow will start creating instances of the regular class..
(12:07:13 AM) cybereal: it won't matter
(12:07:24 AM) cybereal: but even so, if he's dumb he's gonna do dumb things :)
(12:07:34 AM) cybereal: you shouldn't write bad code just to try and protect from dumb coders
(12:07:54 AM) cybereal: but the point is you should be able to have more than one in the same vm, and not have them hurt each other
(12:07:56 AM) codeshepherd: It is really a debatable issue..
(12:08:54 AM) cybereal: codeshepherd: you probably won't really see it this way until it eventually comes back to bite you in the ass as it has me :)
(12:09:08 AM) codeshepherd: I still agree with the fact that.. you let one class (A) provide all functions.. and another class manage instances of Class A.. .. that looks more clean..
(12:09:33 AM) cybereal: you're making a mistake of thinking a class should ever be in charge of anything
(12:09:37 AM) cybereal: INSTANCES of classes should
(12:09:43 AM) cybereal: classes are blue prints
(12:09:54 AM) codeshepherd: hmm.. ok....
cybereal cybereal
(12:10:19 AM) codeshepherd: interesting argument.. thanks a lot cybereal
(12:10:28 AM) cybereal: nothing stops you, as I already described, from sharing a single instance of a class across your whole app
(12:10:50 AM) cybereal: you get what you want from a singleton without the limiting factors, and all it takes is a little longer parameter list in constructors :)
(12:11:18 AM) codeshepherd: ok.. I guess I will realize it better when it bites me back..
(12:11:24 AM) cybereal: hehe ok
Subscribe to:
Post Comments (Atom)
1 comment:
I talk about that very thing in one of my videos. Pools are about the only thing you'd ever want as few instances as possible going. But singleton is misused more often than not.
So what of singletons? Are they really useless? I would implement them as follows: exception in debug mode, singleton in production mode. This makes the singleton something you can fall-back on, while forcing you while you're coding to do things right.
-codingkriggs
Post a Comment