Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  Passing a variable vs. Storing that variable  (Read 1499 times)
0 Members and 1 Guest are viewing this topic.
Offline cubemaster21
« Posted 2014-02-14 02:03:44 »

Just as a general question I was wondering which method would be the best practice. Passing the variable containing the game world in the update function during every update of an entity, or, upon creation of the entity, store it as a variable in the entity class. I've used the second method before and it worked just fine. If I recall correctly minecraft uses the former of the two. What is your opinion on which is better?

Check out my game, Viking Supermarket Smash
http://www.java-gaming.org/topics/iconified/28984/view.html
Offline HeroesGraveDev

JGO Kernel


Medals: 260
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #1 - Posted 2014-02-14 03:07:11 »

It doesn't really make much of a difference, and never use the Minecraft source as a reference. As much as Notch is a genius, it doesn't mean his code is a good example.

Personally, I store it as a variable, as it gives me nicer code to work with.

Offline opiop65

JGO Kernel


Medals: 154
Projects: 7
Exp: 3 years


JumpButton Studios


« Reply #2 - Posted 2014-02-14 03:23:51 »

I do the same as Heroes. If I need to use an object frequently, I just store it. If I only use it occasionally, I pass it in.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cubemaster21
« Reply #3 - Posted 2014-02-14 03:38:49 »

Ok, thanks. I was only citing Notch's code because it was one example that I could think of.

Check out my game, Viking Supermarket Smash
http://www.java-gaming.org/topics/iconified/28984/view.html
Offline 65K
« Reply #4 - Posted 2014-02-14 14:29:35 »

Always limit the scope of variables, thus passing in required parameters on the fly should be the default way.
Except, of course, the caller has no parameter access, values are needed across multiple methods or a reasonable component structure is built for a reason.
The more places you store objects, the more messy und unmaintainable the overall object structure gets. In case of cyclic references, memory leaks could be the effect as well.

Offline Gibbo3771
« Reply #5 - Posted 2014-02-14 16:03:07 »

Always limit the scope of variables, thus passing in required parameters on the fly should be the default way.
Except, of course, the caller has no parameter access, values are needed across multiple methods or a reasonable component structure is built for a reason.
The more places you store objects, the more messy und unmaintainable the overall object structure gets. In case of cyclic references, memory leaks could be the effect as well.

Will go ahead and give my opinion of the benefit of passing rather than storing, I usually have a lot of fields but try my best to use methods and passing parameters.

From what I have read, due to modern hardware method calling is practically free in terms of performance, as is passing instances of variables.

Just remember if you are passing an object it gets passed as is, if you pass primitive data (int, float etc etc) it passes a copy not the actual variable. That is where the wonderfulness of OO comes in Cheesy.

So passing an int to a method and changing it, won't change the actualy field, only the passed variable.

Anyway, I use a lot of fields but try to use methods to alter fields and pass values/objects, it makes it more maintainable as well.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Offline lcass
« Reply #6 - Posted 2014-02-14 16:07:40 »

Does the state of the variable change if the object it refers to changes ro does it stay the same?
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


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


« Reply #7 - Posted 2014-02-14 18:08:02 »

Yes, if you make a new object or point to a different object, the state of all variables inside that object change (unless it is a static variable).

Offline SwordsMiner

JGO Coder


Medals: 3
Projects: 2
Exp: 1 year


The one and only.


« Reply #8 - Posted 2014-02-14 23:42:30 »

With the 1 FPS it *may* save *somehow* on a *horrible* an xp or something, and just because it seems nicer and I can call the object anytime- with my opinion injected into the thought I also think its a good idea to give on creation.

If I made you laugh, helped you at all, or did something cool, I only ask that you smash that appreciate button with your nose.
Offline trollwarrior1
« Reply #9 - Posted 2014-02-16 07:31:02 »

With computers being so fast, it doesn't matter at all.. Completely doesn't matter..
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Agro
« Reply #10 - Posted 2014-02-16 07:47:37 »

if your going to really pass it in all the time it might be better to just to use dependency injection. sadly java doesnt have it, but scala's cake pattern provides beast dependency injection at compile time vs run time.

Offline Danny02
« Reply #11 - Posted 2014-02-16 10:28:34 »

@Agro
First of all, DI in Java isn't that bad(yes it exists) and quite usefull and when you do it right you won't have any speed problems either. The cake pattern in Scala is a nice solution, but not as powerful as runtime DI, so even in Scala you would use libs like guice.

@topic
At first you should always try to pass a value. This can get cumbersome in many cases, so you want to store a reference to the var, but in that case always try to store the reference in the most local scope.

Offline Grunnt

JGO Wizard


Medals: 70
Projects: 8
Exp: 5 years


Complex != complicated


« Reply #12 - Posted 2014-02-17 10:21:29 »

Another vote for passing the world variable as a parameter, although I have also used the other approach.

Passing it as a variable and thus limiting the variable scope sometimes also helps in understanding your code and in debugging since the world variable then can only be modified or used within this scope, instead of in the entire class. But meh, this is one of these cases where depending on how your code looks one or the other can be better.

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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (45 views)
2014-09-23 14:38:19

radar3301 (27 views)
2014-09-21 23:33:17

BurntPizza (63 views)
2014-09-21 02:42:18

BurntPizza (33 views)
2014-09-21 01:30:30

moogie (41 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
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!