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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22038

Doug Mika wrote:
> I know this is explained in a lacklustre way, but I hope it gets the point 
> across.  

Not really.

> Any free resources on the web would be appreciated.

http://sscce.org/

Please do not top-post.
> Stefan Ram wrote:
...

-- 
Lew

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

#22044

On Sat, 2 Feb 2013 16:17:09 -0800 (PST), dougmmika@gmail.com wrote,
quoted or indirectly quoted someone who said :

>How are java applications written to let the ev=
>entlisteners see the classes they are to modify (sometimes these classes ar=
>e seperate application components in seperate files)?

I can think of three ways to link to a class.

pass an X.class  parameter

call a X.somestatic method

pass a reference to an X object and call a X.someinstance method 

I mean "pass" in the more general sense of pass parm or leave ref in
package scope var.

Event handlers have no extra properties.  See
http://mindrod.com/jgloss/anonymousclasses.html
-- 
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development 
time. 
~ Tom Cargill  Ninety-ninety Law 

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

#22075

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.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#22082

Stefan Ram wrote:
> Joerg Meier 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«. Maybe this is related to being in Java, where we
>   have static clas^H^H^H^H^H^H^H^H^H^H^Hclasses with static methods and
>   fields. After all, we would not frown upon things our expert language
>   inventors came up with - static public variables like java.lang.System.out
>   (»globals«), which is used in every Java class, often even within the
> 
>   first »Hello World« program.

Right, and we all know that Java devotés are pure fanboys who never bitch and moan 
about the language's imperfections or how it should have been done, and simply take 
everything given them as emanating from the forehead of the gods, Perls of wisdom all.

It rivals COBOL that way.

-- 
Lew

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

#22102

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

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

#22105

On 5 Feb 2013 04:10:11 GMT, 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_ 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.
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).

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
some cases, those issues can actually be a problem, in which case it's nice
to implement a singleton.

Each caller can "solve" the efficiency problem by caching their own copy of
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
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.

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.

Pete

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

#22106

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.

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

#22143

On 2/5/2013 12:25 AM, Lew wrote:
> 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.

I think you can assume he use "static class" in the C# meaning not the
Java meaning.

Arne

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

#22149

Arne Vajhøj wrote:
> I think you can assume he use "static class" in the C# meaning not the
> Java meaning.

Wait, isn't this comp.lang. *java* .programmer?

I'm in the wrong newsgroup!

No, we do not assume any such thing.

-- 
Lew

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

#22150

On 2/5/2013 8:51 PM, Lew wrote:
> Arne Vajhøj wrote:
>> I think you can assume he use "static class" in the C# meaning not the
>> Java meaning.
>
> Wait, isn't this comp.lang. *java* .programmer?
>
> I'm in the wrong newsgroup!

It happens that other languages come up here.

> No, we do not assume any such thing.

Well - his description fit with C# semantic and it is
rather well known that he uses C#, so it would be a
very natural assumption.

Arne

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

#22110

On 05/02/13 05:03, Peter Duniho wrote:
> On 5 Feb 2013 04:10:11 GMT, 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_ 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.
> 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).

OK, I know I'm probably still being ignored because I've upset some 
people but can someone please explain to me exactly what a 'static 
class' is (WRT Java of course)

This is illegal

public static class Foo{...

a class with all static methods certainly can implement an interface

This compiles

public class Foo implements Serializable{
    public static void Bar(){
    }
}

So what makes a class 'static enough' so that it can't implement an 
interface ? (for example)

As for a Singleton

Well some years ago I went for an interview
The interviewer showed me the following line of code(or something like it)

private final Integer var = 10;

He asked me what I thought of it.

I said it was a flag to future maintainers that this value was important 
and should not be changed without fully understanding the implications.

I got the job (after lots more questions of course)

And this is one reason I think I might use a singleton

In a system with potentially many statics a Singleton (hopefully) stands 
out. It makes explicit the intentions of the developer.
People who understand design patterns will understand what a Singleton 
is, if you like it's a form of documentation.

As for an example (I think this has been mentioned before).
I seem to remember back in the day writing a database connection pool 
manager as a Singleton. Why ? well it probably seemed like a good idea 
at the time :-)

just my 2 euros worth

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#22125

lipska the kat wrote:
> OK, I know I'm probably still being ignored because I've upset some 
> people but can someone please explain to me exactly what a 'static 
> class' is (WRT Java of course)

RTFM:
http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.5.1

The original statement was inaccurate, as you point out.

What he meant must have been something like "except for static methods, which cannot 
implement an interface".

I also made an inaccurate statement on this matter, as your example shows.

-- 
Lew

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

#22145

On 2/5/2013 4:03 PM, Lew wrote:
> lipska the kat wrote:
>> OK, I know I'm probably still being ignored because I've upset some
>> people but can someone please explain to me exactly what a 'static
>> class' is (WRT Java of course)
>
> RTFM:
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.5.1
>
> The original statement was inaccurate, as you point out.
>
> What he meant must have been something like "except for static methods, which cannot
> implement an interface".

He just left out "C#" in the text.

Arne

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

#22130

On 2/5/2013 1:43 AM, lipska the kat wrote:

> OK, I know I'm probably still being ignored because I've upset some
> people but can someone please explain to me exactly what a 'static
> class' is (WRT Java of course)


Part of the reason I'm generally ignoring your posts is that you don't 
look obvious stuff up with Google.  If you had said "I searched for 
'static Java class' but didn't really understand the results," that 
would a bit different.  But at least trying to look stuff up is pretty 
basic.

That said, I think people are using the term loosely and expecting the 
reader to fill in the gaps.  A real static class is a nested class that 
has no (implied) reference to its enclosing instance.

<http://docs.oracle.com/javase/tutorial/java/javaOO/nested.html>

What's being referred to up-thread is just a class with all static 
methods which also has no public constructor.  (I think, I'm not really 
reading this discussion closely.)  It's a standard pattern in Java which 
is used to make "utility classes."  c.f. java.lang.Math, which does 
exactly this.

The standard pattern is:

public class UsefulUtils {
   private UsefulUtils() {}

   ... public static methods here

}

This class is effectively final because without a public ctor it cannot 
be extended.  If this class is stateless or has no mutable state, then 
it is also thread safe, absent some other use of globals.

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

#22133

On 2/5/2013 2:06 PM, Stefan Ram wrote:
> markspace <markspace@nospam.nospam> writes:
>> A real static class is a nested class
>
>> that has
>
>    whose instances have
>
>> no (implied) reference to
>
>> its enclosing instance.
>
>    their enclosing instances.
>
>    BTW: A static class has a reference to its enclosing class.


"Class object."  It's splitting hairs a bit, but that is how the JLS 
refers to them.

Example:

"In the Java virtual machine, every object belongs to some particular 
class: the class that was mentioned in the creation expression that 
produced the object (§15.9), or the class whose Class object was used to 
invoke a reflective method to produce the object..."

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-4.html#jls-4.12.6>


>
> public class Main
> { static class C {}
>    public static void main( final java.lang.String args[] )
>    { java.lang.System.out.println( C.class.getEnclosingClass() ); }}
>

C.class is a class object.  "Class" as I use it above (usually with a 
lower case 'c') is more the concept of a class, rather than its Java 
implementation of the class.  (Rather the same way that the JLS uses 
'class' to refer to the general concept of a class in OOD, for example 
that section of the JLS I quoted above.)

That said, you're not really wrong to point out it's really the 
instances that have references to their enclosing class.

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

#22134

On Tue, 05 Feb 2013 13:56:26 -0800, markspace wrote:

> [...]
> What's being referred to up-thread is just a class with all static 
> methods which also has no public constructor.

Yes, thank you for clarifying that. Exactly right. I'm not the only one to
use the phrase "static class" in the context of Java to mean that, but
yes...it's imprecise language, especially given that Java assigns a
different meaning to the declaration "static class".

In C# (which is where my mind is usually, hence the goof), it would have
made more sense. There, there's no such thing as inner classes, and the
declaration "static class" does mean a class only with static members
(which the compiler enforces).

Pete

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

#22155

On 05/02/13 21:56, markspace wrote:
> On 2/5/2013 1:43 AM, lipska the kat wrote:
>
>> OK, I know I'm probably still being ignored because I've upset some
>> people but can someone please explain to me exactly what a 'static
>> class' is (WRT Java of course)
>
>
> Part of the reason I'm generally ignoring your posts is that you don't
> look obvious stuff up with Google.

I've just had a very quick look through all my posts here in cljp
and AFAICS this is my very first actual 'technical' question here (well, 
apart from one about PayPal which was a matter of desperation given that 
their 'technical support' is a farce). I'd be interesting to know which 
posts you were referring to so I don't make the same mistake in the future.

> If you had said "I searched for
> 'static Java class' but didn't really understand the results," that
> would a bit different. But at least trying to look stuff up is pretty
> basic.

I was actually trying to understand the term 'static class' in the 
context of a discussion about Singleton classes. It is apparent from the 
replies that my question was valid.

But thanks for taking the time to reply

lipska

-- 
Lipska the Kat©: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

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

#22144

On 2/5/2013 4:43 AM, lipska the kat wrote:
> On 05/02/13 05:03, Peter Duniho wrote:
>> On 5 Feb 2013 04:10:11 GMT, 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_ 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.
>> 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).
>
> OK, I know I'm probably still being ignored because I've upset some
> people but can someone please explain to me exactly what a 'static
> class' is (WRT Java of course)
>
> This is illegal
>
> public static class Foo{...
>
> a class with all static methods certainly can implement an interface
>
> This compiles
>
> public class Foo implements Serializable{
>     public static void Bar(){
>     }
> }

In Java you can use:

package demo;

public class Foo {
     public static class Bar {
         ...
     }
     ...
}

in which case Bar is just a class with the name
demo.Foo.Bar.

You can also have:

package demo;

public class Foo {
     public class Bar {
         ...
     }
     ...
}

in which case instances of Bar is tied to instances of
Foo (access to its members).

In C# you have:

namespace Demo
{
     public class Foo {
         public class Bar {
             ...
         }
         ...
     }
}

which is the equivalent of the first Java example (with static).

You can also have:

namespace Demo
{
     public static class Bar {
         ...
     }
     public class Foo {
         ...
     }
}

in which case Bar is a class that can only have static methods
(and can not implement interfaces).

Arne

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

#22114

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.

     Runtime.getRuntime().exit(0);

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#22119

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?

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

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

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

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

csiph-web