Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
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  
  Almost Completely Static Class Design  (Read 1109 times)
0 Members and 1 Guest are viewing this topic.
Offline Gibbo3771
« Posted 2014-04-09 18:41:57 »

This is my last dumb question for today :p

I am in the process of developing an Event based system, I have created an EventManager but I am in 2 minds about how this should be designed.

It makes no sense to have multiple EventManagers, so I was going with the design idea of making it almost a completely static class, the only method that is not static is the update method, therefore you would still have to construct one and call that in your render() method.

This would make it easier to add a new Event from anywhere in the code without having to rely on having an instance of it within scope.

But is this stupid? Still having to construct it just to call that one method?

Should I just make it completely static, it only has 2 constructors anyway, 1 of which is no-args. Other is not necessary as a method that is static does the same and is completely optional.

Here is what my addEvent method looks like:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
   public static Event addEvent(Event event) {
      if (EventManager.events.size == maxEvents)
         throw new GameUtilRuntimeException(
               "Failed to add an event, max reached");
      if (event == null)
         throw new NullPointerException("Trying to add a null event");
      if (clock != null)
         if (clock.getFormat() == ClockFormat.HOUR_12) {
            if (event.oClock == null)
               throw new GameUtilRuntimeException(
                     "Failed to add an event, AM or PM not specified");
         }
      /* Make sure we don't already have the exact same event in the array */
      if (!EventManager.events.contains(event, true))
         events.add(event);

      /* Return the event if we want to change anything */
      return event;
   }


"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Endos
« Reply #1 - Posted 2014-04-09 19:14:21 »

If you only needs one instance of your class, instead of making all his methods static, you can make a singleton class:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
class EventManager{
 private static final EventManager instance=new EventManager();

 private EventManager(){
 ...
 }

 public static EventManager getInstance(){
 return instance;
 }

 public Event addEvent(Event event) {
 ...
 }
}


And to access the methods use EventManager.getInstance().addEvent();


Bored Birds - End with your boredom for Android
Retroships - Space Shooter for Android
Ultimate - 2D Side-Scrolling Platformer project
Offline Gibbo3771
« Reply #2 - Posted 2014-04-09 19:19:38 »

Thanks for the reply!

I literally just done something similar, would a singleton be the best approach?

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Endos
« Reply #3 - Posted 2014-04-09 19:21:47 »

IMHO, yes.

Bored Birds - End with your boredom for Android
Retroships - Space Shooter for Android
Ultimate - 2D Side-Scrolling Platformer project
Offline Roquen
« Reply #4 - Posted 2014-04-09 19:41:30 »

If you're compelled by the forces of evil to use a singleton: http://www.java-gaming.org/topics/stupid-enum-tricks/31916/view.html
Offline jonjava
« Reply #5 - Posted 2014-04-09 19:45:00 »

Or you could get rid of all static and singletons. If the user wants to access it from anywhere they can themselves create a static reference to the object they create.

Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #6 - Posted 2014-04-09 20:09:36 »

There is really no clear answer to this argument... I mean, take a look at this thread.

Static-Free Engine

There is a way to go static without actually making a singleton, but I think the true answer is just "doing what feels right". Yes, there is the option that everyone has to just turn any object static. However, when designing a library, it does make sense for the creator to decide how a feature of that library is best used. (Like in LWJGL's case, they decided that having once instance for Display was the best way.)

In this specific case, I do believe that going static is a good idea for removing overhead of creating "too many classes". There is a talent for finding the middle ground on classes without having to necessarily create a singleton, but instead a helper class. All aspects of computer science always run the risk of being overdone. In Java, too many getters and setters create an unreadable mess of classes, while giving users of a library direct access to a variable can cause devastating errors. Same with inheritance, encapsulation, abstract, and static builds of classes.

It is up solely to the developer to decide how best to utilize the tools given. Trends are born mostly by not following convention. How else are you supposed to create a library that doesn't reinvent the wheel if you don't add some of your own flair to your projects?

Offline 65K
« Reply #7 - Posted 2014-04-09 20:29:56 »

It makes no sense to have multiple EventManagers
...one for input events
...one for backend logic
...one for communicating between clients and server
...different implementations with uniqe characteristics, whatever

Static design puts unnecessary restriction on the usability on your classes.
Btw. dont call it Manager. That is the most misused and meaningless name pattern.

Offline theagentd

« JGO Bitwise Duke »


Medals: 361
Projects: 2
Exp: 8 years



« Reply #8 - Posted 2014-04-09 21:20:39 »

I've yet to see any reason at all for why singletons are better less horrible, or even in any way different from static fields.

1  
2  
3  
Singleton.getInstance().function()
vs
Singleton.function()


You will never need to pass it in as an argument anywhere since any class can just fetch the instance through getInstance() so there's no need for it to be an object in the first place.

Myomyomyo.
Offline pitbuller
« Reply #9 - Posted 2014-04-09 22:23:30 »

I've yet to see any reason at all for why singletons are better less horrible, or even in any way different from static fields.

1  
2  
3  
Singleton.getInstance().function()
vs
Singleton.function()


You will never need to pass it in as an argument anywhere since any class can just fetch the instance through getInstance() so there's no need for it to be an object in the first place.

If its instance you can lazily create it. This might have some benefits sometimes.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd

« JGO Bitwise Duke »


Medals: 361
Projects: 2
Exp: 8 years



« Reply #10 - Posted 2014-04-09 22:25:45 »

Hmm, that's true actually. Holy shit, view of life changed.

Myomyomyo.
Offline TeamworkGuy2

Junior Devvie


Medals: 10



« Reply #11 - Posted 2014-04-09 22:31:40 »

^Yes, possibly for lazy creation (use inner enum pattern to protect multi-threaded application).

You will never need to pass it in as an argument anywhere since any class can just fetch the instance through getInstance() so there's no need for it to be an object in the first place.

Singleton.getInstance() is easier to modify at runtime than Singleton.  In particular if the class handles something OS related (graphics, sound, user input) then being able to return different objects from Singleton.getInstance() when the program runs in a different environment is quite useful.
Using Singleton as a static class means we are assuming that it will not need to be changed or replaced, which, from programming experience, tends to be a bad assumption.

A good example in Java is FileSystem.getFileSystem() (package-private class in java.io) which just returns a file system handle.  However, underneath different file systems can be returned depending on the OS.
Offline Endos
« Reply #12 - Posted 2014-04-09 22:36:13 »

And a singleton can extend classes (inherit their instance members), implement interfaces, and you can allow others to extend your class and override your methods (using a protected constructor) if you wish...

Bored Birds - End with your boredom for Android
Retroships - Space Shooter for Android
Ultimate - 2D Side-Scrolling Platformer project
Offline Cero
« Reply #13 - Posted 2014-04-10 01:44:06 »

I've yet to see any reason at all for why singletons are better less horrible, or even in any way different from static fields.
I agree 100%.


If its instance you can lazily create it. This might have some benefits sometimes.
You can just have an init method that you call whenever, however

Offline Roquen
« Reply #14 - Posted 2014-04-10 05:16:11 »

Oh yeah lazy loading!  Kids: exactly when does the JVM load a class?  We're not C++.  If you think you need a singleton it's because you're parents gave you a red bicycle instead of a blue one when you were two.  You can forgiven them now.
Offline Gibbo3771
« Reply #15 - Posted 2014-04-10 06:59:58 »

It makes no sense to have multiple EventManagers
...one for input events
...one for backend logic
...one for communicating between clients and server
...different implementations with uniqe characteristics, whatever

Static design puts unnecessary restriction on the usability on your classes.
Btw. dont call it Manager. That is the most misused and meaningless name pattern.

I'll find a better name Lol, you can technically just use the same event manager for that, although it would make it more readable if you had one for each.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Gibbo3771
« Reply #16 - Posted 2014-04-10 07:56:44 »

IMHO, yes.

I feel as if at the moment I there will only be a need for 1 instance of the given class, so that is why I am edged towards your answer...then...


If you're compelled by the forces of evil to use a singleton: http://www.java-gaming.org/topics/stupid-enum-tricks/31916/view.html

Puts me off lol

Or you could get rid of all static and singletons. If the user wants to access it from anywhere they can themselves create a static reference to the object they create.

Valid point. Then you gotta go:

1  
MyPossiblyHorribleAndUnrelatedClassName.eventManager.doSomething();


Then again that is the users own design flaw, not mine.

Oh yeah lazy loading!  Kids: exactly when does the JVM load a class?  We're not C++.  If you think you need a singleton it's because you're parents gave you a red bicycle instead of a blue one when you were two.  You can forgiven them now.

Then there's this guy, that always has a valid argument but likes to run it past you in the form of a riddle or witty comment Cheesy

I love you   Wink

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline Roquen
« Reply #17 - Posted 2014-04-10 10:09:48 »

The "other" choice is worse: http://en.wikipedia.org/wiki/Initialization-on-demand_holder_idiom

You only need to do that if you need type compatibility (of the singleton with something else) where the type must (or very desirable) via inheritance and not interface.

All other choices are either: not thread safe or an insane mess which looks thread safe but probably isn't.
Quote
I love you   Wink
I'd say it warms my heart but I seem to have misplaced it.
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 (19 views)
2014-11-26 15:22:04

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

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

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

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

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

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

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

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

digdugdiggy (52 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!