Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why is static not used?  (Read 3812 times)
0 Members and 1 Guest are viewing this topic.
Offline wessles

JGO Wizard


Medals: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« Posted 2013-07-18 19:03:41 »

So, I have a few static classes in my game, where I have a static game, title, and rendering class. But, I don't see this too often, but it seems pretty nice. Instead of passing a world variable through everything, you could just call it and it's variables statically. Is there an issue with it? Is using static classes a bad idea? Inefficient? Non-flexible? Or am I just dreaming the whole thing?
Also, static class is just a class with all static variables and methods, to me in my game.

Offline Jimmt
« League of Dukes »

JGO Kernel


Medals: 128
Projects: 4
Exp: 3 years



« Reply #1 - Posted 2013-07-18 19:38:29 »

Discussion here.

To summarize, use static when it works. There's no absolute here. It's a bit difficult to explain, but look at your examples: Java Math class is static - easy access, just use Math.abs() for example. No need for individual objects because it's a utility class.
Offline actual

JGO Coder


Medals: 23



« Reply #2 - Posted 2013-07-18 19:53:59 »

Stack Overflow has some questions that ask when it's appropriate to use statics.

Where statics have gotten me into trouble is that it is so convenient to make things static that I was creating dependencies where none needed to exist. This made it harder for me to keep things understandable.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline 65K
« Reply #3 - Posted 2013-07-18 19:57:41 »

... because it is inflexible, bad for dependency management (which is essential for a maintainable software architecture),
 bad for testing, a pita to refactor, bad for encapsulation, bad for stateful behaviour, bad for inheritance.

The typical beginner's usage of static is often an arbitrary mess. Anybody who wants to dive deeper into software architecture, object orientation and Java, understand 3rd party libraries and after all learn his trade should first find out how to set up object relations and communication properly without using static.

Offline wessles

JGO Wizard


Medals: 66
Projects: 4
Exp: 3 years


Profile picture isn't relevant.


« Reply #4 - Posted 2013-07-18 21:49:11 »

So should static even exist? After 3 replies, it seems like a beginners trap! I'm using it, and have not had too many problems. I had to convert my project from no static to a few statics. No problems yet as far as organization. I just wanted to know if it will dampen performance in any way, since it seems rarely used.

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #5 - Posted 2013-07-18 21:50:29 »

... because it is inflexible, bad for dependency management (which is essential for a maintainable software architecture),
 bad for testing, a pita to refactor, bad for encapsulation, bad for stateful behaviour, bad for inheritance.

The typical beginner's usage of static is often an arbitrary mess. Anybody who wants to dive deeper into software architecture, object orientation and Java, understand 3rd party libraries and after all learn his trade should first find out how to set up object relations and communication properly without using static.

Later, when you are a master, you can unlearn all that, and go back to using static where you feel like it.

Cas Smiley

Offline davedes
« Reply #6 - Posted 2013-07-18 21:50:38 »

Generally speaking: the only reason static seems like a good idea is because you haven't looked beyond the scale of your own project.

I recently stumbled on a practical example of statics being a bitch. I was using TableLayout for a Swing app; and at a later point required a hardware-accelerated canvas which I decided to integrate with LibGDX + scene2D UI. The problem is, LibGDX also relies on TableLayout, but the TableLayout uses statics and is therefore singular by design. In the end, I couldn't smoothly integrate Swing + LibGDX TableLayout into the same application, and had to re-write my own GUI elements for the GL canvas.

With that said, static is obviously a good idea for constants and convenience methods (like Math). Or, if you are just writing your own internal code, and don't care about its scalability.

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2013-07-18 22:28:38 »

Generally speaking: the only reason static seems like a good idea is because you haven't looked beyond the scale of your own project.

I recently stumbled on a practical example of statics being a bitch. I was using TableLayout for a Swing app; and at a later point required a hardware-accelerated canvas which I decided to integrate with LibGDX + scene2D UI. The problem is, LibGDX also relies on TableLayout, but the TableLayout uses statics and is therefore singular by design. In the end, I couldn't smoothly integrate Swing + LibGDX TableLayout into the same application, and had to re-write my own GUI elements for the GL canvas.

With that said, static is obviously a good idea for constants and convenience methods (like Math). Or, if you are just writing your own internal code, and don't care about its scalability.

The two clues in this post are "your own internal code" and "scale of your own project".

When you're right at the top level, making a game (not a library, or even code you're particularly planning on using in other games), static can help make things much neater.

Cas Smiley

Offline Cero
« Reply #8 - Posted 2013-07-18 22:53:55 »

Generally speaking: the only reason static seems like a good idea is because you haven't looked beyond the scale of your own project.

I recently stumbled on a practical example of statics being a bitch. I was using TableLayout for a Swing app; and at a later point required a hardware-accelerated canvas which I decided to integrate with LibGDX + scene2D UI. The problem is, LibGDX also relies on TableLayout, but the TableLayout uses statics and is therefore singular by design. In the end, I couldn't smoothly integrate Swing + LibGDX TableLayout into the same application, and had to re-write my own GUI elements for the GL canvas.

With that said, static is obviously a good idea for constants and convenience methods (like Math). Or, if you are just writing your own internal code, and don't care about its scalability.

The two clues in this post are "your own internal code" and "scale of your own project".

When you're right at the top level, making a game (not a library, or even code you're particularly planning on using in other games), static can help make things much neater.

Cas Smiley

I love how cas always writes what I think.
Best practices and good software design are really for 3rd party libraries and stuff.
If you, and maybe just a handful people you know personally are ever going to use that code, and it makes sense, just use static.
Be aware of the problems, but dont let that stop you in your own code if you feel that it makes things easier.

Offline relminator
« Reply #9 - Posted 2013-07-19 02:18:04 »

Just use something until it gives you trouble.  Until then don't worry and just code.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jonjava
« Reply #10 - Posted 2013-07-19 10:12:59 »

I remember talking about static/global state in another (slightly derailed) thread. An explanatory question is asked at the 31:20 timestamp (video). Don't use static just for kicks. If you don't know why you're using static then you shouldn't use it.

[EDIT]: Oh I forgot to link the actual thread I was talking about and the video in it :V

Thread: http://www.java-gaming.org/topics/loading-multiple-images/24878/msg/212172/view.html#msg212172

Video: http://www.youtube.com/watch?v=-FRm3VPhseI

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2013-07-19 10:24:54 »

That is really a general maxim for any programming construct.

Cas Smiley

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #12 - Posted 2013-07-25 18:38:41 »

In my own games I happily ignore a lot of those 'best practices':
* Using static methods when it just makes the most sense (typically when one would otherwise write singletons).
* Making fields public (especially final ones) when it makes things more concise.
* Not using unit testing or worrying about 'test coverage' (in most cases, test-driven development doesn't help anyway)

But you do have to be very careful with static fields (which includes enums) if you plan to release on Android.
On the desktop you can be sure that if you start a java program, that classes are initialised (so also its static fields) and that for example static initialisers (as in static {...}) are called.
On Android otoh, you can not rely on that: It will happily reuse classes from a previous run and not call these static initialisers and re-initialise static fields.
Something to keep in mind!

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!