Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #22106
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Date | 2013-02-04 21:25 -0800 |
| References | (1 earlier) <68pyk4ua9x9m.1nm4lckdwgp86.dlg@40tude.net> <singleton-20130204174059@ram.dialup.fu-berlin.de> <51106eff$0$293$14726298@news.sunsite.dk> <singleton-20130205050434@ram.dialup.fu-berlin.de> <1g6plnhx9njxt$.bx5mrpbwc6mi$.dlg@40tude.net> |
| Message-ID | <2f9f0ba0-dc87-48e6-b746-163f2ab202c1@googlegroups.com> (permalink) |
| Subject | Re: Design Patterns |
| From | Lew <lewbloch@gmail.com> |
Peter Duniho wrote: > _Needed_ is situation-specific, but examples generally will include > situations where multiple callers require access to some shared resource > abstracted by the singleton class. In some cases, a static class suffices. Nitpick: "static class" is the wrong term. I figure you mean a "utility class", or class with only static members. > But in other cases it's either useful or required to have a singleton (e.g. > because you need the singleton to implement an interface, something static > classes in Java can't do). Static classes certainly can implement interfaces. It's non-instantiable classes that can't, and classes containing only static methods. > But even in absence of _need_, there is the class of examples where one > needs an implementation of an interface that can be shared by multiple > callers. One approach is to keep creating new instances of the implementor > every time a caller needs it, but this has obvious efficiency issues. In Sometimes has efficiency issues. The "obvious" ones often aren't actually issues at all. To "keep creating instances" is actually a situation for which Java is optimized. > some cases, those issues can actually be a problem, in which case it's nice > to implement a singleton. Isn't "issue" a synonym for "problem"? > Each caller can "solve" the efficiency problem by caching their own copy of Yes, "solve" in quotes, because quite often something labeled a "cache" simply isn't. Also, there's that aforementioned optimization for short-lived instances. > the class, but it's generally better to do the work once in the singleton > class rather than making each caller duplicate the effort. Good API design And this is the heart - not whether the instance hangs around but whether the work needs to be repeated. It's the latter that helps decide on whether to keep an instance (singleton or otherwise) lingering. > means the client of the API has a minimum of work to accomplish needed > functionality, without a bunch of extra busy work. > > Another class of examples involve classes where it's useful to have a > "default" instance. Again, callers could use a default constructor and > create a new instance every time they needed the default one. But it's > convenient to have a singleton instance representing that default. Strictly speaking, that's not a singleton unless it's the only possible instance. > Frankly, I'm amazed any experienced programmer would argue against the > pattern solely on the basis of perceived lack of "need". Almost everything > in a high-level language and framework is there not because of need, but > rather convenience and simplicity (which often in turn leads to code that > is easier to get correct, always a nice feature of one's code). Everything > you can do in Java, you can do in assembly language. You don't _need_ Java > at all. > > And yet, we use it. Now that is a salient point indeed. -- Lew It's an incursion of logic into the center of the line of defense posed by irrationality.
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Design Patterns dougmmika@gmail.com - 2013-02-02 16:17 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 19:39 -0500
Re: Design Patterns Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-02-03 18:52 +0100
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-03 14:23 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:57 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 11:10 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-09 19:36 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 23:44 -0800
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-09 23:47 -0800
Re: Design Patterns "John B. Matthews" <nospam@nospam.invalid> - 2013-02-10 12:28 -0500
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-10 13:35 -0500
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-10 13:36 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-10 23:12 -0800
Re: Design Patterns "John B. Matthews" <nospam@nospam.invalid> - 2013-02-09 19:45 -0500
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-02 20:17 -0500
Re: Design Patterns Doug Mika <dougmmika@gmail.com> - 2013-02-02 19:43 -0800
Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-02 20:54 -0800
Re: Design Patterns Doug Mika <dougmmika@gmail.com> - 2013-02-02 21:11 -0800
Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-03 08:24 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:41 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-02 21:57 -0800
Re: Design Patterns Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 06:38 -0800
Re: Design Patterns Joerg Meier <joergmmeier@arcor.de> - 2013-02-04 17:06 +0100
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-04 12:38 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 21:31 -0500
Re: Design Patterns Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-04 21:03 -0800
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-04 21:25 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 19:54 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 17:51 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:54 -0500
Re: Design Patterns lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-05 09:43 +0000
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 13:03 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:09 -0500
Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-05 13:56 -0800
Re: Design Patterns markspace <markspace@nospam.nospam> - 2013-02-05 14:30 -0800
Re: Design Patterns Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-05 14:33 -0800
Re: Design Patterns lipska the kat <"nospam at neversurrender dot co dot uk"> - 2013-02-06 09:03 +0000
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:07 -0500
Re: Design Patterns Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-02-05 09:10 -0500
Re: Design Patterns Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-02-05 13:20 -0500
Re: Design Patterns Lew <lewbloch@gmail.com> - 2013-02-05 13:10 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:11 -0500
Re: Design Patterns Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-05 09:53 -0800
Re: Design Patterns Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-05 20:17 -0400
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 19:50 -0500
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 20:34 -0500
Re: Design Patterns Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-06 08:40 -0800
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:38 -0500
Re: Design Patterns Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 21:41 -0500
csiph-web