Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (526)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (593)
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  
  to static or not to static  (Read 2039 times)
0 Members and 1 Guest are viewing this topic.
Offline MickeyB

Senior Devvie




my game will work, my game will work!


« Posted 2004-12-14 18:08:10 »

ok, seen it done both ways and based on an example I went this route.  Then kinda stuck with it.  My main game class has the following code snippet:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
        /** TextureLoader */
        public static TextureLoader textureLoader;
       
        /** Font Writer */
        public static FontWriter fw;
       
        /** SplashScreen */
        public static SplashScreen splash;
       
        /** Client - foer server communication */
        public static Client client;
       
        /** LoginManager - for login, player create steps */
        public static LoginManager loginManager;
       
        public static List<gl2DComponent> components = Collections.synchronizedList(new ArrayList<gl2DComponent>());

private static void run() {}


private static void render() {}
       


This objviously allows access to these object from just about anywhere.  I know this isnt the most object oriented path(or maybe it is).
Would you do it another way?  

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #1 - Posted 2004-12-14 18:22:32 »

Well, it doesn't hurt anything to use static AND final objects. If you want to allow assignments, then you should really use setters and getters. Of course, it doesn't actually matter if no one else will ever use the code. OO design is really one of those "protect you from yourself" type of things.

A good comparison is database foreign keys. Sure, you can get away without using foreign keys, but wouldn't you feel much safer if you knew for a fact that no one could add garbage ids?

Java Game Console Project
Last Journal Entry: 12/17/04
Offline Grazer

Junior Devvie




My other avatar is much more flattering.


« Reply #2 - Posted 2004-12-15 01:09:34 »

Quote
Would you do it another way?  

Yep. Definitely.
Not that what you've done is "wrong".
I've just found that if you get out of your static main() method and into an instance method as soon as possible, it makes it much easier to refactor stuff when the time comes.

Here's my re-do of your code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
public class Game {
   /** TextureLoader */
   private TextureLoader textureLoader;
   
   /** Font Writer */
   private FontWriter fw;
   
   /** SplashScreen */
   private SplashScreen splash;
   
   /** Client - foer server communication */
   private Client client;
   
   /** LoginManager - for login, player create steps */
   private LoginManager loginManager;
   
   private List<gl2DComponent> components = Collections.synchronizedList(new ArrayList<gl2DComponent>());

   private void Game() [
     // Initialise all the above stuff here!!!
   }
 
   private void run() {}
 
   private void render() {}

   public static void main(String[] argv) {
     new Game().run();
   }


Current Project: Easy Decal
Other Stuff: grlea online
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline MickeyB

Senior Devvie




my game will work, my game will work!


« Reply #3 - Posted 2004-12-15 12:17:42 »

I have headed to the masters  Smiley ....I have refactored 90% of my statics and now initialize by passing reference to parent.

thanks!

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline princec

« JGO Spiffy Duke »


Medals: 423
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2004-12-15 12:38:57 »

I use statics all over the place Smiley
So much easier. So much more sensible when you're writing a standalone game!

Cas Smiley

Offline MickeyB

Senior Devvie




my game will work, my game will work!


« Reply #5 - Posted 2004-12-15 17:06:35 »

If it was mutliplayer, would you switch to instances?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #6 - Posted 2004-12-16 00:47:55 »

Getter/setter or public static... it's pretty much the same. Both means you lose a bit data encapsulation, both means those objects are now coupled together and you should try to avoid both of em were possible.

弾幕 ☆ @mahonnaiseblog
Offline Serethos

Junior Devvie




Java games rock!


« Reply #7 - Posted 2004-12-16 06:12:51 »

nice. the topic static vs oop is a little like attacking the holy cow. i had (have?) this problems myself and discussed with many people about that. even my professors have very different opinions about that. old school programmers often tend towards the practical static.
it often gave me headaches cause clean oop can cause several headaches. sometimes it is necessary to take care of a big pattern only to avoid direct access.

now i use static much more than before, especially when i know that i really need only one instance. my server only needs one gui, my game only one resourcemanager. and those components often need to be accessed from the farest place of your class structure, often only one time in a year.
Offline princec

« JGO Spiffy Duke »


Medals: 423
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2004-12-16 09:54:28 »

No difference in multiplayer either.

Cas Smiley

Offline MickeyB

Senior Devvie




my game will work, my game will work!


« Reply #9 - Posted 2004-12-16 11:35:29 »

Great!  Smiley

I think I have a happy medium that I am comfortable with.  Now that base classes are done...I can extend till I am blue in the face and have access to whateva I need.

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline weston

Junior Devvie





« Reply #10 - Posted 2004-12-17 04:09:06 »

reading this post made me think of many singleton classes that I've written for managing various resources etc. It seems to me like the very nature of a 'singleton' class makes it suitable for everything being static instead of the general implementation (stores a single instance of itself with a private constructor and a public getInstance() method). Wouldn't it be better (or at least equivelant)  to make all attributes and methods static? there is really no point in creating the object of the class if you know there will only be one instance of it ever. Any downside to doing this (other than OOD purists yelling at me)?

for(int i = 1; i > 0; i++)
{
System.out.println(i+" cups of java downed");
}
Offline Serethos

Junior Devvie




Java games rock!


« Reply #11 - Posted 2004-12-17 06:06:18 »

although i am not doing this (making *all* static, if you dont need many instances) it should be a good way. especially when youre taking into mind that static variables are slightly
faster to access than member ones.

but on the other hand, when i look back at most of my projects there aren't too many cases where you can declare lots of variables static. only few classes (often manager entities) only need to be instantiated once. or there is the problem that you need to harmonize the access from static to
member entities...
Offline Grazer

Junior Devvie




My other avatar is much more flattering.


« Reply #12 - Posted 2004-12-18 10:43:56 »

Quote
there is really no point in creating the object of the class if you know there will only be one instance of it ever. Any downside to doing this (other than OOD purists yelling at me)?

Prepare to be yelled at  Angry .... just kidding.

I believe (IANAnExpert/Academic) the major benefit of using a Singleton (which is an object) rather than static methods is that if, in the future, you decide to provide an alternate implementation or an enhanced implementation of the methods, it would be very easy to change either the call that returns the singleton or the call that retrieves the singleton to return/retrieve a different object with the same interface (read "method signatures" not necessarily "java interface"). If using static methods, you would have to manually change EVERY call to those methods to make the same change.
So, in essence, it's a future-proofing pattern, not one that gives any particular advantage at runtime.

Current Project: Easy Decal
Other Stuff: grlea online
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.

toopeicgaming1999 (72 views)
2014-11-26 15:22:04

toopeicgaming1999 (61 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (27 views)
2014-11-24 19:59:16

trollwarrior1 (40 views)
2014-11-22 12:13:56

xFryIx (78 views)
2014-11-13 12:34:49

digdugdiggy (56 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!