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

Groups > comp.lang.java.programmer > #22029 > unrolled thread

Design Patterns

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 3 of 3 — ← Prev page 1 2 [3]

#22126

Stefan Ram wrote:
> Eric Sosman writes:
>> A singleton class can be transformed into an uninstantiable
>> class having only static methods.
> 
>   Static methods cannot be passed via reference or used to

Do you mean "via a reference to their owning instance"?

>   implement interfaces. Therefore, there is a need for
>   non-static methods sometimes. But this does not mean a
>   singleton, I am thinking of a POJO first and foremost
>   until someone shows me where a POJO does not suffices,
>   but a singleton is needed.

Most of the time, at least, it suffices to have only one instance of a class where 
otherwise one might be tempted to implement a Singleton.

I have a strong bias toward using instance methods over static methods, in part because 
they can implement an interface method. It does not suffice that the method merely 
doesn't access instance state. It also needs to be "global" by design.

Instance methods can be easier to control in multi-threaded contexts. It's often good to 
have a manager instance that controls the methods so that different units can use them 
independently. 

If you later decide that "singleton" was a mistake, instance methods don't need to be 
refactored.

There's also a circular analysis where type state is maintained in mutable static variables, so one 
creates static methods on the theory that they don't access instance state. 

The risk of mistake with instance methods is lower than with static methods.

So if I have a compelling argument for making a method static, fine, but tie or a close second 
goes to the instance implementation.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#22147

On 2/5/2013 1:20 PM, Eric Sosman wrote:
> On 2/5/2013 12:51 PM, Stefan Ram wrote:
>> Eric Sosman <esosman@comcast-dot-net.invalid> writes:
>>>> Maybe someone can come up with an SCSE where a singleton is needed.
>>> Runtime.getRuntime().exit(0);
>>
>>    The library (Java SE) could have been defined to allow:
>>
>> class Main
>> { public static void main( final java.lang.Runtime runtime )
>>    { runtime.println( runtime.getArgc() + " command-line arguments." );
>>      runtime.exit(); }}
>>
>>    or - with less changes to the current state of Java - to allow:
>>
>> Runtime.exit( 0 );
>
>      A singleton class can be transformed into an uninstantiable
> class having only static methods.  An uninstantiable class with
> only static methods can be transformed into a singleton class.
> The two designs are duals: Why should one be deprecated and the
> other preferred?

I would in most cases with more serious code prefer singleton
due to its interface capability.

For throw away code I would probably go for the static just
because I am a lazy bastard.

>      If all-static vs. singleton is the most pressing problem
> someone faces, he has an easy life indeed!

I agree with that.

Arne

[toc] | [prev] | [next] | [standalone]

#22117

On 2/4/13 6:31 PM, Arne Vajhøj wrote:
> On 2/4/2013 11:44 AM, Stefan Ram wrote:
>> Joerg Meier <joergmmeier@arcor.de> writes:
>>> While we are talking about design patterns, you should be aware that
>>> a lot
>>> of people now consider Singletons an antipattern. Your usage of them
>>> certainly sounds like the justly despised "global variable" replacement
>>> many people abuse them for. Might be a good idea to reconsider that
>>> design.
>>
>>    Pattern or anti-pattern, I never encountered a situation where I
>> felt a
>>    need for »singletons«.
>
> Other have.
>
> GoF has it.
>
> Spring has had it since 1.x.
>
> EJB got it in 3.1.
>
> Implementations and usage are very different, but the idea of
> everybody using the same object is the same.
>
> Arne

I think the real anti-pattern is the common implementation of how to get 
the value of the singleton. Singleton's are useful, but when the 
singleton status of an object is enforced beyond reason, you end up with 
with all kinds of "work-arounds" to the fact that the object is a 
singleton.  Dependency Injection can help alleviate some of those 
problems, by making the singleton nature of the object a consequence of 
it only being instantiated by the framework, rather than by the class 
itself being a "singleton class".

[toc] | [prev] | [next] | [standalone]

#22136

On 02/05/2013 01:53 PM, Daniel Pitts wrote:
> On 2/4/13 6:31 PM, Arne Vajhøj wrote:
>> On 2/4/2013 11:44 AM, Stefan Ram wrote:
>>> Joerg Meier <joergmmeier@arcor.de> writes:
>>>> While we are talking about design patterns, you should be aware that
>>>> a lot
>>>> of people now consider Singletons an antipattern. Your usage of them
>>>> certainly sounds like the justly despised "global variable" replacement
>>>> many people abuse them for. Might be a good idea to reconsider that
>>>> design.
>>>
>>>    Pattern or anti-pattern, I never encountered a situation where I
>>> felt a
>>>    need for »singletons«.
>>
>> Other have.
>>
>> GoF has it.
>>
>> Spring has had it since 1.x.
>>
>> EJB got it in 3.1.
>>
>> Implementations and usage are very different, but the idea of
>> everybody using the same object is the same.
>>
>> Arne
>
> I think the real anti-pattern is the common implementation of how to get
> the value of the singleton. Singleton's are useful, but when the
> singleton status of an object is enforced beyond reason, you end up with
> with all kinds of "work-arounds" to the fact that the object is a
> singleton.  Dependency Injection can help alleviate some of those
> problems, by making the singleton nature of the object a consequence of
> it only being instantiated by the framework, rather than by the class
> itself being a "singleton class".
>

Exactly so. Let it be a "singleton" only because an external framework 
is tracking that there is one instance, and you obtain the instance via 
the framework.

AHS

[toc] | [prev] | [next] | [standalone]

#22142

On 2/5/2013 12:53 PM, Daniel Pitts wrote:
> On 2/4/13 6:31 PM, Arne Vajhøj wrote:
>> On 2/4/2013 11:44 AM, Stefan Ram wrote:
>>> Joerg Meier <joergmmeier@arcor.de> writes:
>>>> While we are talking about design patterns, you should be aware that
>>>> a lot
>>>> of people now consider Singletons an antipattern. Your usage of them
>>>> certainly sounds like the justly despised "global variable" replacement
>>>> many people abuse them for. Might be a good idea to reconsider that
>>>> design.
>>>
>>>    Pattern or anti-pattern, I never encountered a situation where I
>>> felt a
>>>    need for »singletons«.
>>
>> Other have.
>>
>> GoF has it.
>>
>> Spring has had it since 1.x.
>>
>> EJB got it in 3.1.
>>
>> Implementations and usage are very different, but the idea of
>> everybody using the same object is the same.
>
> I think the real anti-pattern is the common implementation of how to get
> the value of the singleton. Singleton's are useful, but when the
> singleton status of an object is enforced beyond reason, you end up with
> with all kinds of "work-arounds" to the fact that the object is a
> singleton.

What workarounds are you thinking of?

Arne

[toc] | [prev] | [next] | [standalone]

#22148

On 2/4/2013 11:10 PM, Stefan Ram wrote:
> Arne Vajhøj <arne@vajhoej.dk> writes:
>>> Pattern or anti-pattern, I never encountered a situation where I felt a
>>> need for »singletons«.
>> Other have.
>
>    Maybe someone can come up with an SCSE where a singleton is needed.

Needed as in "problem can not be solved without"? I doubt such exist!

Needed as in "a large of programmers prefer it to solve the problem"?
There are many. Connection pools, configuration settings, web app
statistics etc..

Arne

[toc] | [prev] | [next] | [standalone]

#22169

On 2/5/13 5:34 PM, Arne Vajhøj wrote:
> On 2/4/2013 11:10 PM, Stefan Ram wrote:
>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>>> Pattern or anti-pattern, I never encountered a situation where I felt a
>>>> need for »singletons«.
>>> Other have.
>>
>>    Maybe someone can come up with an SCSE where a singleton is needed.
>
> Needed as in "problem can not be solved without"? I doubt such exist!
>
> Needed as in "a large of programmers prefer it to solve the problem"?
> There are many. Connection pools, configuration settings, web app
> statistics etc..

Logging is another one.  They thing about all those is that there is a 
globally accessible shared instance, but that doesn't have to be 
enforced by the class itself. Rather, the life-cycle of the object is 
managed externally.

Self-managed life-cycles should be very rare.  For instance, something 
which actually manages external resources may need to enforce some 
invariants about its life-cycle, in order to manage external state in a 
sane manor.  This isn't something an application programmer need worry 
about on a frequent basis.

I'm *not* a fan of a global Configuration object for many reasons.  One 
is that the configuration class becomes overly involved with the rest of 
the application.  At least, if they treat it as a place to "go grab some 
settings".  If the settings are injected, then that's a different story.

[toc] | [prev] | [next] | [standalone]

#22242

On 2/6/2013 11:40 AM, Daniel Pitts wrote:
> On 2/5/13 5:34 PM, Arne Vajhøj wrote:
>> On 2/4/2013 11:10 PM, Stefan Ram wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> writes:
>>>>> Pattern or anti-pattern, I never encountered a situation where I
>>>>> felt a
>>>>> need for »singletons«.
>>>> Other have.
>>>
>>>    Maybe someone can come up with an SCSE where a singleton is needed.
>>
>> Needed as in "problem can not be solved without"? I doubt such exist!
>>
>> Needed as in "a large of programmers prefer it to solve the problem"?
>> There are many. Connection pools, configuration settings, web app
>> statistics etc..
>
> Logging is another one.  They thing about all those is that there is a
> globally accessible shared instance, but that doesn't have to be
> enforced by the class itself. Rather, the life-cycle of the object is
> managed externally.
>
> Self-managed life-cycles should be very rare.  For instance, something
> which actually manages external resources may need to enforce some
> invariants about its life-cycle, in order to manage external state in a
> sane manor.  This isn't something an application programmer need worry
> about on a frequent basis.

It does not need to enforce it by itself. But I do not see a real
problem of it doing it.

If one is already using a framework that can provide the functionality
then fine. But I would not add a framework to avoid writing the
singleton boilerplate.

> I'm *not* a fan of a global Configuration object for many reasons.  One
> is that the configuration class becomes overly involved with the rest of
> the application.  At least, if they treat it as a place to "go grab some
> settings".  If the settings are injected, then that's a different story.

Up to a certain level I would prefer a single configuration
over multiple configurations.

Arne

[toc] | [prev] | [next] | [standalone]

#22103

On 2/4/2013 11:06 AM, Joerg Meier wrote:
> On Sat, 2 Feb 2013 16:17:09 -0800 (PST), dougmmika@gmail.com wrote:
>
>> I'm writing an application and I have the following problem.
>> When I write EventListeners I write them in seperate classes (and
>> seperate files) for reasons of clearity.  But these event
>> listeners I want to modify other classes that aren't  defined in
>> the EventListeners.  They already exist in the main program.
>> The problem I have is how best to get these eventlisteners to
>> know of these classes (which are also in seperate files)?  Up to
>> know I have used Singletons (I made the classes the event
>> listeners were to modify global) but this seems ugly.  How are
>> java applications written to let the eventlisteners see the
>> classes they are to modify (sometimes these classes are seperate
>> application components in seperate files)?
>
> While we are talking about design patterns, you should be aware that a lot
> of people now consider Singletons an antipattern. Your usage of them
> certainly sounds like the justly despised "global variable" replacement
> many people abuse them for. Might be a good idea to reconsider that design.

Yes.

I don't see Singleton as an anti-pattern.

But it is certainly bad design if Singleton is used
as global variable that all code is writing to and
reading from making it very hard to figure out
what is going on.

And the description could sound like this is
indeed the case.

I don't see a problem if it is well defined who
writes and who reads. Having a Singleton load
config information and expose readonly API
is fine.

I don't see a problem if usage is independent
of other usage. With a connection pool you don't
care who else is using the connection pool. With
a statistics collector you don't care who else is
updating statistics.

Arne

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web