Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #22106

Re: Design Patterns

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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