Static classes?

[nickdotjava]

I've heard some talk about static classes, but can't find any clear info on them.  Are they classes where everything is by default static instead of dynamic?  And I heard that they're going to be added in 1.5.  Is this correct?

Thanks.

[Herkules]

IMHO 'static classes' are classes where you made everything static and don't have a ctor.

Concerning 1.5, I only have in mind the static imports, that allow a slightly more elegant usage of constants. But I feel this will be a minor detail, no big deal.

[nech_neb]

Eww...

never use static classes.
Always use singletons

Games published by our own members! Check 'em out!

[Matzon]

never use static classes.
Always use singletons

Why in [insert favorite worhiped entity(ies)] name(s) would you want to give that advise?
static is a perfectly valid keyword, and can be used quite powerfully. Use what suits you best!

IMHO 'static classes' are classes where you made everything static and don't have a ctor.

All classes have a constructor, though it might now have a public one... so if it is private, it can still be instantiated by itself. Other than that, I agree with Herkules.

[abies]

FYI:

nickdotjava - you have heard about static imports, not static classes. Static classes are inside java since 1.2, it is static imports that get introduced inside 1.5.

Static imports - ability to put static methods and fields of given class into 'default' namespace of class you are using. When you static-import Math class, you can later write cos(PI) instead of Math.cos(Math.PI). This is just a syntax sugar, compiler-only, has not effect on bytecode/execution.

Static class - this is a special case of inner class. Normally, inner class has invisible pointer to enclosing class, which allows it to access enclosing class members. But sometimes, you just want to have small utility class as inner class, without burdening it with extra pointer inside. Example (althrough not best, because it inherits from enclosing class) is Rectangle2D.Float and Rectangle2D.Double.

nech_neb - you probably meant 'never use static methods, use singletons'. I have heard it before few times. While it is a valid religious belief, which can be even supported by heap of anecdotal evidence, remember that you will also need to bend sometimes - for example, to retrieve singleton, you need static method Same is true for many utility methods - there is really no need to make java.lang.Math class singleton.

[bmyers]

I think nech_neb really did mean don't use static classes.

While I agree in general that Singletons are better than static classes, there can be times when it makes sense to use an actual static class -- java.lang.Math being a good example.  But a static class should ideally be used only when it doesn't make any sense to use a Singleton -- i.e. when there are no data members, when none of the methods will ever be used outside of a static context,  etc.

And I'm sure someone is going to chime in with: "But it's different for games!"  

[Herkules]

I personally really LOVE statics for they remember me of god old times, when programming was easy....

Than came the time when everything had to be pure OO, everything needed to be an object - darn, that was hard! Now I'm half way back again and I feel better now.

private final static - that's my favorite modifier list

[abies]

I think nech_neb really did mean don't use static classes.

There is a difference between 'class with static methods' and 'static class'. Latter has very well defined meaning in java and has nothing to do with former. I suppose that by 'static class' he referred to 'class with static methods', because it is a construct which can be replaced with Singleton. 'Static class' in java meaning can be replaced with top-level class in same package, but has nothing to do with singletons.

Sorry to be picky about the words, but IMHO vocabulary common  to people discussing is neccesary if you try to explain any ideas.

For info about 'static class' (called 'static nested class')
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#262890

[bmyers]

I personally really LOVE statics for they remember me of god old times, when programming was easy....

Back when all variables were global, with none of this pesky "data hiding" and "encapsulation" and stuff?  

abies:  Thanks for the clarification!

[Captain-Goatse]

Use singletons where you have to. When you start doing static classes you are already out of "pure" oo since you are basically creating a global.

Also using singletons in java is kind of stupid since you can't pass by reference and is analogous to argument use goto instead of while in loops.

Why would anyone use static class instead of singleton class where singleton pattern is appropriate. Static classis ugly, results in odd behaviour and breaks all the class hierarchies you might ever have.

Static class = design flaw and there is no other way around it.

Also my post contains a paradox, take that as you wish

Games published by our own members! Check 'em out!

[princec]

Static classes aren't global, and nor are they flawed... they do exactly what they say they do, and if the situation fits, then it's the right thing to use.

Cas

[Captain-Goatse]

In java they are "global" by nature because you can access them anywhere. This is in static class where there are only static members and functions, for example Camera.x where x is static int.

Howeve when using static Camera camera = new Camera(0, 0, 0); you have to be careful whether you are supposed to use singleton.

[AndersDahlberg]

In java they are "global" by nature because you can access them anywhere.

Not correct, depends on class and method visibility. I.e. they "belong" to their class and are *not* "global".

Howeve when using static Camera camera = new Camera(0, 0, 0); you have to be careful whether you are supposed to use singleton.

Why?! As any static method is accessed by Camera.<method> (notice Case) it's obvious that there is nothing "special" about instantiating an object of a class with static methods (just that if the class contains only static methods it's rather bad design though...).

(And don't come with the lame excuse that camera.<method> also works - this is an error even though you only get a compiler warning - this should be fixed a.s.a.p.)

[Captain-Goatse]

Why?! As any static method is accessed by Camera.<method> (notice Case) it's obvious that there is nothing "special" about instantiating an object of a class with static methods (just that if the class contains only static methods it's rather bad design though...).

(And don't come with the lame excuse that camera.<method> also works - this is an error even though you only get a compiler warning - this should be fixed a.s.a.p.)

Because you can't do a proper singleton design in java.  And it is not a lame excuse. You are violating at least 2 major OOP principles (information hiding, encapsulaing single access). That is why. Let's take an example here: http://c2.com/cgi/wiki?JavaSingleton

Singleton is supposed to be a fast and efficient way to go around things, not a gimmick hack. When implementing a singleton in java, you are almost forced to use static class one way or another, thats why the term java singleton.

This is one of the downfalls in java, because no better way has been implemented yet. How come can you access Camera.<method> if you have to init the class anyway or pass it around camera and use camera.<method>? Thats a major design flaw. If you have a constructor it will also allow constructing the class("heap" or "stack") anywhere and you can simply access things this way.

///Hopefully the programmer has non static methods withing the camera
Camera camera;
camera.doStuff();

//Or static methods only
Camera.doSuff();

This is the reason if you are going to create static Camera camera you should not have static funtions inside the camera. The former one especially is bad design and even worse if both can be accessed at the same time.

I would be very careful when playing around with static code especially if someone else has to use it.

Besides when you are saying they *belong* to the class and thus not global, you are wrong. You are just moving the dot around the problem and making it seem better for your own purposes. A global is a global no matter where it is if you can access it anywhere. It doesn't make difference whether it is in a class or not. You are violating class hierarchies.

static NoGlobalsHere omgNoGlobals

for(int i =NoGlobalsHERE.lol; i > x; i--){
         omgNoGlobals.globarlRBad(lol);
}

Either way you are doing a global access.

If you are tight about design do it right especially in Java because it is one of the few languages that provides you with really tight quidelines already,

[swpalmer]

There is nothing wrong with static classes.  What is wrong is trying to follow some sort of rule book to keep everything "purely OO" when that is just plain silly.  Do what fits your problem.  OO programming is not a requirement.  It is simply a method of doing things that is usually helpful.

I have seen people waste so much time trying to figure out the "right" Oo way to do something, when they could just simply write code that gets the job done.  They are stuck thinking that somehow this code will be cursed and cause tons of problems when for all practical purposes that is rarely the case, and if some issue is found later on a slight refactoring could overcome it.  Don't over design trivial operations, just be aware of the larger picture.

Sure some practices can lead to more errors than others, but there is no hard rule that any particular practice will always cause a problem.

[princec]

Everyone seems to have forgotten that classes are local to a classloader as well so it's quite possible to have multiple instances or purely static classes.

Cas

[AndersDahlberg]

Because you can't do a proper singleton design in java.

Yes, you can - and many have.

And it is not a lame excuse.

Yes it is

You are violating at least 2 major OOP principles (information hiding, encapsulaing single access). That is why. Let's take an example here: http://c2.com/cgi/wiki?JavaSingleton

information hiding:
declare class

1   2   3   4   5   6

package com.my.singleton.whatever; public class Whatever {     /* package */ Whatever (...) { ... }     public void doSomething(Object data); }

encapsulating single access:
provide factory

1   2   3   4   5

package com.my.singleton.whatever; public class WhateverFactory {     private static final Whatever whatever = ...;     public static Whatever getMyWhateverSingleton() { return whatever } }

Any questions so far?
(and this is just an example mind you - use whatever works...)

Singleton is supposed to be a fast and efficient way to go around things, not a gimmick hack.

Not always - it can also be a design feature.

When implementing a singleton in java, you are almost forced to use static class one way or another, thats why the term java singleton.

Please enlighten me on what *you* consider a static class?

This is one of the downfalls in java, because no better way has been implemented yet. How come can you access Camera.<method> if you have to init the class anyway or pass it around camera and use camera.<method>?

This above make no sense to me - what are you trying to say?

Thats a major design flaw. If you have a constructor it will also allow constructing the class("heap" or "stack") anywhere and you can simply access things this way.

wrong

///Hopefully the programmer has non static methods withing the camera
Camera camera;
camera.doStuff();
//Or static methods only
Camera.doSuff();

ehh?

This is the reason if you are going to create static Camera camera you should not have static funtions inside the camera. The former one especially is bad design and even worse if both can be accessed at the same time.

ehh??

I would be very careful when playing around with static code especially if someone else has to use it.

Why would you feel any different when using static methods versus non-static methods?

Besides when you are saying they *belong* to the class and thus not global, you are wrong. You are just moving the dot around the problem and making it seem better for your own purposes.

Tips:
try to declare a class with no access modifier (i.e. package only) and access a static method of that class from another package - maybe you'll see the light

A global is a global no matter where it is if you can access it anywhere.

I agree. But since that aint the case in java I don't understand why you keep rambling about it?

It doesn't make difference whether it is in a class or not. You are violating class hierarchies.

static NoGlobalsHere omgNoGlobals

for(int i =NoGlobalsHERE.lol; i > x; i--){
         omgNoGlobals.globarlRBad(lol);
}

Either way you are doing a global access.

If that above is supposed to tell me something the only thing I can think of is that I'm very happy that I usually program in java and only touch c/c++ when I have to.

If you are tight about design do it right especially in Java because it is one of the few languages that provides you with really tight quidelines already,

I agree(?)!

[AndersDahlberg]

Everyone seems to have forgotten that classes are local to a classloader as well so it's quite possible to have multiple instances or purely static classes.
Cas

IIRC:

Nitpick: they aren't consider the same class though if they are loaded by different class loaders

EDIT: Maybe that was your point, silly me

[Captain-Goatse]

Yes, you can - and many have.


Yes it is


information hiding:
declare class

1   2   3   4   5   6

package com.my.singleton.whatever; public class Whatever {     /* package */ Whatever (...) { ... }     public void doSomething(Object data); }

encapsulating single access:
provide factory

1   2   3   4   5

package com.my.singleton.whatever; public class WhateverFactory {     private static final Whatever whatever = ...;     public static Whatever getMyWhateverSingleton() { return whatever } }

Any questions so far?
(and this is just an example mind you - use whatever works...)
Not always - it can also be a design feature.

Please enlighten me on what *you* consider a static class?

This above make no sense to me - what are you trying to say?


wrong

ehh?
ehh??
Why would you feel any different when using static methods versus non-static methods?
Tips:
try to declare a class with no access modifier (i.e. package only) and access a static method of that class from another package - maybe you'll see the light

I agree. But since that aint the case in java I don't understand why you keep rambling about it?


If that above is supposed to tell me something the only thing I can think of is that I'm very happy that I usually program in java and only touch c/c++ when I have to.


I agree(?)!

1.) It is not a singleton. You pass singleton as around as a reference or a pointer. This does not work in java, because you have to duplicate the class. Dupe != singleton. Read "Design Patterns" p149, it'll explain you why "Java singleton" is a gimmick (not even a hack because you can't have single access to a class everywhere.

2.) Globals: A class that has members accessible any class without construction can easily be considered global class.  Globals have few uses, mainly when working with hardware, but usually then it is a design flaw. If you take into account what princec said, your singleton is not a singleton. If you can show me a way to implement a true singleton in java I'll let you have my manbabies.

This is considered a global in java.  Now you can do all smarty things like information hiding and stuff, but it is still a global if you access it Global.fag instead through the constructed object.

public class Global{
public static fag;
publiv static hat;

}


now you can access anything Global.fag ot Global.hat.
2.1) You should use static member functions only when you are handling static member, for example returning it. Other wise you'll get big cross overs in class hierarchies again.

Concerning tips: No I don't see the light. That is just plain bad design and I hope your co-workers appreciate your insightful addition to the world of design.

Personally, I'd never use singleton, because there are so many oppoturnities to miss when using a singleton and when you miss, other people who read your code can't understand it and your classes will be worthless considering future usage..

If you don't use class hierarchies and proper encapsulation your code will be only good for yourself.

Only way I can think of having a singleton in java is using the VM namespace and declaring a class with static methods only that never gets constructed. However this again imposes some problems and is bad design.

[AndersDahlberg]

It feels more and more like you don't even read what I write and are on some kind of strange religious battle trying to explain that java is evil (even though admittedly you do it by making claims that are at best misleading and in some cases even right out false)?!

Well, one more reply trying to explain my views on your claims comes here...

1.) It is not a singleton.

What is not a singleton?

You pass singleton as around as a reference or a pointer.

If you like too, I see no problem with that yes (even though I don't use singletons much- when I do, I usually don't "pass them around")

This does not work in java, because you have to duplicate the class. Dupe != singleton.

Here you're making a claim that I don't understand - please explain. Duplicate the class!?

Read "Design Patterns" p149, it'll explain you why "Java singleton" is a gimmick

I don't have a copy of that book here (vaccation).

(not even a hack because you can't have single access to a class everywhere.

In reality no (as you can have multiple java vm's running)
But then you could argue that you can't have any singleton whatsoever (another OS running, another machine running ad absurdum...)

2.) Globals: A class that has members accessible any class without construction can easily be considered global class.  

Not a java class  - unless our definition on global is different. My is something like this:
Global:
* Everybody can access
* Don't belong to a namespace (i.e. it can clash with another global somewhere in a source tree)

A java class is clearly not a global according to neither of those two requirements.

Globals have few uses, mainly when working with hardware, but usually then it is a design flaw.

I agree that usually globals are a design flaw.

If you take into account what princec said, your singleton is not a singleton. If you can show me a way to implement a true singleton in java I'll let you have my manbabies.

If you take it ad absurdum you can never have a singleton...
And I showed you a pretty good singleton above
<flamesuite on>
even though it obviously didn't fit your belief in the mighty über-singletons religion
</flamesuite off>
Anyway: but as I said: If the same class (the "singleton") is loaded by two different classloaders you *can't* use both of them as the *same singleton* (i.e. they are both singletons - but different - strange, yes, but then so is most of computer science theory)  - you will get a ClassCastException (IIRC) as they are no longer *the same singleton* / they are *different*.

This is considered a global in java.

Well, then - if you could provide your defintion of globals maybe we could call that
Captain-Goatse Globals, or short form CGG

Now you can do all smarty things like information hiding and stuff, but it is still a global if you access it Global.fag instead through the constructed object.

public class Global{
public static fag;
publiv static hat;

}


now you can access anything Global.fag ot Global.hat.

Above makes no sense, first of all I guess you mean that Global is just a class with two public static Singleton classes member variables (case is misleading though)?
Not sure what this got to do with globals, except that it is providing a good lesson in bad design.

2.1) You should use static member functions only when you are handling static member, for example returning it. Other wise you'll get big cross overs in class hierarchies again.

Now your getting religious again , my oppinion is that use what works - and static methods are a great way to provide utility methods (Math.sin etc etc)

Concerning tips: No I don't see the light.

Well, the point was that you can have different visibillity on java classes - thus breaking one of the fundamental properties of a "global".

That is just plain bad design and I hope your co-workers appreciate your insightful addition to the world of design.

touché, well I don't have any problems with constructive critique

Personally, I'd never use singleton, because there are so many oppoturnities to miss when using a singleton and when you miss, other people who read your code can't understand it and your classes will be worthless considering future usage..

Singletons have their uses.
Tthere are probably better designs available when you use one - but then, who cares, if it works, it's documented and not totally confusing?

If you don't use class hierarchies and proper encapsulation your code will be only good for yourself.

Nope, that's religous OO talk - there are many ways to design, OO is just one of them.

Only way I can think of having a singleton in java is using the VM namespace and declaring a class with static methods only that never gets constructed. However this again imposes some problems and is bad design.

VM namespace? You lost me there

[Captain-Goatse]

Ok, more religious oo talk, when I think of java I think of a call wrapper built on top of C++ and then interpreted.

No, I'm not in a religous battle. I'm just trying to be objective(haha pun intended). Seriously, the best thing in java is its natural straightforward OOP. If you use Java then you might as well
use all of the object oriented design, because otherwise I see no point in using Java at all.

As a language there are so many other ones with similiar syntax but after all not similiar OOP. Also GC helps a lot with OOP. Now, when using a language like Java, priorities should be(at least are for me):
1.) Clean, logical understandable code.
2.) Object oriented intependent classes.
3.) Reliable and error proof

Java = epitome of OOP.
C++ = dirty oop power house.
C = clean non-oop language.

However I can't see why some people neglect the fact that Java is not capable of everything. Why? Because it is not meant to be. Singleton was adapted from C++, but are not the best way to do things in Java. You seem to clearly have your own view of what a singleton is and how it used, but I suggest you read Design Patterns by Gamma et al where the singleton patterns was introduced first academically.

[AndersDahlberg]

Ok, more religious oo talk, when I think of java I think of a call wrapper built on top of C++ and then interpreted.

Hehe, then I can see why you have trouble with my views on Java and OO in general

No, I'm not in a religous battle. I'm just trying to be objective(haha pun intended). Seriously, the best thing in java is its natural straightforward OOP. If you use Java then you might as well
use all of the object oriented design, because otherwise I see no point in using Java at all.

Here is probably where we differ the most - I can see many features in java that, for instance, make it a better imperitive (spelling?) language than even C (maybe not better than ada though)- great compiler checks, garbage collection and rather close to optimized C performance on most accounts (where all within 20-80% C speed is close enough - it usually is, i.e. only linear slower, sometimes even faster in a few cases where runtime information can increase speed even further than a static compiler can).

OO is just the big thing now - what will it be 5,10 or even 20 years? I'm sure OO will still be around, but I'm equally sure that there will be The Next Big Thing that will treat OO just as we OO programmers sometimes treat impertive and procedural programmers.

And becuase java the platform is just that, a platform,  it will probably be around then too

As a language there are so many other ones with similiar syntax but after all not similiar OOP. Also GC helps a lot with OOP. Now, when using a language like Java, priorities should be(at least are for me):
1.) Clean, logical understandable code.
2.) Object oriented intependent classes.
3.) Reliable and error proof

Here I agree - just that I would add
2.1) If above doesn't work good enough - don't hang on to it like a religion

Java = epitome of OOP.
C++ = dirty oop power house.
C = clean non-oop language.

Well, java is not really object oriented (according to some definitions...) - say that it is in a smalltalk user group and you'll see my point

However I can't see why some people neglect the fact that Java is not capable of everything. Why? Because it is not meant to be. Singleton was adapted from C++

Nah, Singletons have nothing to do with C++ they have (without any facts) probably been around *a long* time before C++ came around.

, but are not the best way to do things in Java. You seem to clearly have your own view of what a singleton is and how it used, but I suggest you read Design Patterns by Gamma et al where the singleton patterns was introduced first academically.

I've read that book (or atleast a couple of chapters of it, and others in the same category) and I can say to you that it's not a bible, just a cook book of different recipies. As in, all recipies can differ from country (language...) to country while still being considered the same dish

And YES, java is not good for everything and you can't do everything in java - but that is another story.

[swpalmer]

1.) Clean, logical understandable code.
2.) Object oriented intependent classes.
3.) Reliable and error proof

You've got it almost backwards for me.  Is not reliability no errors the most important thing for a program?  The other aspects are only good for the programmer.  Usually there are more users than programmers and it is the use of the program that is the whole point.

C is clean??  C is old and well understood.. but clean isn't the right word. C is just a small abstraction on top of an assembler.

Java is a general purpose language and as such is it is capable of almost everything.  (I think it can do a perfectly acceptable singleton... at least for any definition of singleton that I would care to use.)
I like OOP, and use Java.. but there are other reasons to use Java as well.. the great tools and libraries being significant factors.

[blahblahblahh]

they aren't consider the same class though if they are loaded by different class loaders

Yeah, and I once got badly bitten by the fact that instanceof operators then stop working!

Class.instanceOf() definitely stops working as expected (unless you know all about ClassLoader's and the above-mentioned fact), but IIRC  "instanceof" also stops working as expected (apologies if this is wrong, I'm going off the top of my head here.

[princec]

I'd say it still works as expected but not how you were thinking it would work

I was always tripping over this stuff when I was fiddling with classloaders.

Cas

[blahblahblahh]

No, I'm not in a religous battle. I'm just trying to be objective(haha pun intended). Seriously, the best thing in java is its natural straightforward OOP. If you use Java then you might as well
use all of the object oriented design, because otherwise I see no point in using Java at all.

Personally, I follow Bjarne Stroustrup (C++ inventor); an "Object Oriented Language" is one that "supports" the major features of OO in a way that makes them easy to use. You can do OO in assembly, and could hence argue that assembly is an OO language (in fact, it's probably the most OO language because you have the most freedom to do any kind of OO however you want ).

C++, Java, Smalltalk, Modula-2 and others are all examples of different sets of OO features, supported in different ways. There's no such thing (at the moment) as a "reference implementation" of the archetypal OO language.

Java's two main differences over what has gone before are:
  1. Lots of things that "seemed like a good idea at the time" (e.g. various aspects of C++) but turn out to be nightmarish in practice - on real projects - were cleaned up / excised (although many agree that initially this was taken too far...)
  1.b. ...and lots of things that other languages had discovered really were a good idea, but only a few languages were currently doing.
  2. Standardisation of the libraries...and making sure the libraries encompassed all the major things they ought to (again, not achieved perfectly - e.g. regexps should have been in much earlier in an ideal world - but the intention was clear)

As a language there are so many other ones with similiar syntax but after all not similiar OOP. Also GC helps a lot with OOP. Now, when using a language like Java, priorities should be(at least are for me):
1.) Clean, logical understandable code.
2.) Object oriented intependent classes.
3.) Reliable and error proof

Your list makes sense to me, but I think you could have phrased it a little better. Number one priority should be phrased "ease of maintenance, including source upgrades/redevelopment" - since this is where the greatest unnecessary cost is in normal development.

I think your second ought to be phrased "loosely connected interface implementations (OO)" - i.e. the claim to fame of Object-Orientation (Objects use encapsulation etc to be highly modular, and robust to unexpected/unforseen changes in the design of the overall application...hence easy to replace, easy to change, easy to re-architect, easy to reason about/explain, etc)

...and I think you ought to include "standard libraries" in the top three too. If you were around in the bad old days of non-standardised C you may remember the pain of everyone re-inventing the wheel, with each library having it's own unique unfixed bugs.