Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (487)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (553)
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  
  GLC/GLO Pattern - static accessor to get/peek  (Read 960 times)
0 Members and 1 Guest are viewing this topic.
Online kevglass

JGO Kernel


Medals: 159
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Posted 2006-04-03 20:42:10 »

Ok, little more awake now (was getting pretty tired last night/this morning) - this may or may not make more sense..

As I said in another post I have a central listener recording channel join/leave requests (UserHandler). I wanted to proxy this request on to an Arena (so that they can tell when a user has joined/left them) so I want to call userJoined() on my Arena GLO. However, I'm calling this from my UserHandler so I end up with either:

1  
2  
3  
4  
5  
arenaRef.get(task).userJoined(somInfoHere)

or

arenaRef.peek(task).userJoined(someInfoHere)


Right now, I use the get because I happen to know that hte userJoined method is going to want to write to the GLO. I'm not too keen on this because it means UserHandler has to have some implicit knowledge about whats going on in userJoined to know how to access the GLO. So, I was considering a pattern where I had static methods proxying inside Arena, something like

1  
2  
3  
4  
5  
6  
7  
8  
9  
public static void userJoined(GLOReference<Arena> ref, SomeInfo somInfo) {
    SimTask task = SimTask.getCurrent();

    ref.get(task).userJoined(someInfo);
}

public void userJoined(SomeInfo someInfo) {
    // do real work here
}


Since this at least leaves me with the knowledge about whether userJoined needs to get or peek in one place it seems better, but I can remember seeing static proxy style thing shown as an Anti-Pattern.

I could have of course added the Arena itself as a listener in this particular case, but thats not true in all cases. So, I suspecet I've missed something along the way (brain?) but I was wondering if this the right way to do things or if theres a nicer pattern or if I've just made a big mistake somewhere..

Sorry if this is all getting a bit spammy now, I've only got a couple more questions.. honest

Kev

Offline Jeff

JGO Coder




Got any cats?


« Reply #1 - Posted 2006-04-04 01:58:13 »

Ok, little more awake now (was getting pretty tired last night/this morning) - this may or may not make more sense..

As I said in another post I have a central listener recording channel join/leave requests (UserHandler). I wanted to proxy this request on to an Arena (so that they can tell when a user has joined/left them) so I want to call userJoined() on my Arena GLO. However, I'm calling this from my UserHandler so I end up with either:

1  
2  
3  
4  
5  
arenaRef.get(task).userJoined(somInfoHere)

or

arenaRef.peek(task).userJoined(someInfoHere)


Right now, I use the get because I happen to know that hte userJoined method is going to want to write to the GLO. I'm not too keen on this because it means UserHandler has to have some implicit knowledge about whats going on in userJoined to know how to access the GLO.

SimTask.accessCheck() doe sa run-time check to make sure that a method has been called with its gLo in the access strate itexpects. I use it extensively  in PDTimer as an example.

Quote
So, I was considering a pattern where I had static methods proxying inside Arena, something like

1  
2  
3  
4  
5  
6  
7  
8  
9  
public static void userJoined(GLOReference<Arena> ref, SomeInfo somInfo) {
    SimTask task = SimTask.getCurrent();

    ref.get(task).userJoined(someInfo);
}

public void userJoined(SomeInfo someInfo) {
    // do real work here
}


Since this at least leaves me with the knowledge about whether userJoined needs to get or peek in one place it seems better, but I can remember seeing static proxy style thing shown as an Anti-Pattern.

This shoudl be fine.  Wher it gets hairy is in contrcutors because Java states that yo ushoudl NOT use a "this" parameter inside of a constructor.  This rather complicates static constructors.

Static fields must also be avoided. But static methods otherwise are fine.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
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.

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

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

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

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

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

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

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

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

BurntPizza (42 views)
2014-08-09 21:09:32

BurntPizza (34 views)
2014-08-08 02:01:56
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!