...Whenever I realize a function does its job without needing other data than the one provided by the function call arguments...

In other words what I call 'stateless' Agreed that then you CAN make it static. I'm never ever going to make any statement again about when you SHOULD do it because apparently that is sort of religious in nature.

Static's great. We get games made using static data and classes and methods all over the place. At night, we sleep soundly*, safe in the knowledge that our static hell is keeping the roof over our heads.

I use static all the time and it's great. The problem is, it doesn't scale--in terms of numbers of classes and interfaces and the relationships between them. As your program becomes more complicated, in the parts of the program that become more complicated, the static methods and fields start to get really awkward.

What I'm saying is use statics. But when they start to get awkward in code you intend to enhance, pay the price to get rid of them rather than pile kludge on top of kludge.

This theoretically applies to any programing language, but Java handles complexity so well you're more likely to notice the problem there. Everywhere else, when you hit static hell you'll be in so many other hells it will be the least of your worries.

And you can stick to simple programs, even in Java, and forget all this.

I try to avoid static hell so I'm not that familiar with it close up. The usual problem I encounter is trying to stuff static methods into interfaces. I pass an object that implements an interface to a method, and that method needs static (class) data. The method to get it, in all classes that implement the interface, is, of course, static. At that point, I rework the code. If I kludged it, I imagine I'd be in "static hell", which I suspect is something like writing in Fortran or C, which I do not want to do ever again.

I have recently come across code where the data for 1000 "objects" is stored in a set of 1000 element arrays. Game characters, for instance, with values for location, speed, health, etc.. This is no doubt faster than have a GameChar class with instances in one 1000 element array, but as the game gets more complex, the lack of GameChar instances to pass around gets awkward. And the locking problems if multiple threads try to access individual characters will bring game execution and development to a halt.

There's nothing wrong with any of this. Lot's of people frame nice houses with pine 2X4's. But they know they're not going to put another 60 stories on top. The problem happens when people come up with a simple solution for a simple problem, then try to stick with it when the problem becomes complex.

On the one hand, what you're describing is not a problem with static or whatnot... Is a general lack of proper software design.

You are aware that there are no truly universal solutions in software design? Specially with software as demanding as real-time applications (like most games are).

In essence, if you charge straight into implementation without devoting some time to making a decent design, you'll sooner or later hit a wall (depending on program complexity).

Keep in mind that, when you go to college to study software engineering, there are entire subjects dedicated exclusively to software design, where you don't get to see a single line of code (and, thus, I hated them with a passion )

This is what's been bothering me since the start of the thread. All that rethoric about the evils of static data, and yet you don't have a few case studies to throw around?

I'm sorry if I'm too blunt, but this stinks, as I said earlier, of dogmatic zeal.

For whatever reason you've come upon the conclusion that static data is evil and have decided to spread the gospel like a regular door to door preacher.

And just like anyone who has internalized a belief, no amount of rebuttals will sway you from either having said beliefs or refraining from proselytizing them, as evidenced by this very thread, so full of perfectly reasoned examples as to why your position doesn't hold, which are being conveniently ignored.

Again, sorry for my bluntness, but is my experience that, for any debate to be productive, the participants need to be ready to learn, or, in other words, ready to accept their preconceptions might be wrong.

Anything else is just pointless dick waving that helps no one.

And yes, I'm guilty of those very same sins myself, and it revolts me to realize I'm close minded to0, that's why I devote so much energy to try and help people break out of that mindset.

Again, I'm not saying I "know" how you think, just saying how it feels from my perspective. I'm no mind reader either.

My issue with static is pretty simple. While coding every so often I manage to create a bug. Most bugs I make cause immediate visible issues in Eclipse. Eclipse will suggest a viable repair to the problem half of the time. Probably one in four, Eclipse either gives me a better way to code what I am trying to code, or gives me a correct example of the parameters I am trying to pass. This is great. After I run the program, most of the remaining bugs quickly show up and I can even see what the line of code that blew up is. If I run the code in debug mode, I can explore some objects and values set.

So when I do create a bug, my programming environment almost always catches it. The remaining bugs, the ones that got through the sieve, are usually fairly simple. The are also usually flaws in program logic. My bad! I fix them and the problem is gone. Sometimes the bug fix requires altering a parameter or creating a int somewhere in another class. Rarely does this involve more that three object needing adjustment. Sometimes a bug is worse.

Sometimes I lose a day of programming joy to a long day of frustration while first having to find the cause and second having to adjust a hundred or so objects after finding the bug. In every case so far, these bugs, these horrid bugs that set me back and make me do a huge rewrite, have been static. In every case so far, when I have created the same bug without static being involved, Eclipse has caught the error for me. I don't know much about other SDKs. Eclipse does not seem to error check static as well as it does Enum (which is a type of static, but I love me some Enum's.)

Static is not great for unit testing, it may be the same qualities that make static instances a pain to work around for unit testing, make static instances hard for the basic system tests. For me using static, is like working without a net. If I am walking on the ground, or a thick path, static is fine. If I am on a high tight wire, I need a net. So when the code gets complex, I don't trust static.

I have but two lights by which to guide my feet, the light of experience and the light of experts experience. When I went out to look for examples of how to reduce my dependence on static, I discovered quite a bit of help. Good code examples and good methods. While I had testing using JUnit I really did not have enough grasp of testing to see the holes in my testing that static variables introduced. This was I admit a bit blind of me but since my tests were simple and based on the Eclipse and Java for Total Beginners tutorial videos. http://eclipsetutorial.sourceforge.net/totalbeginner.html I must confess, that my tests are still pretty simple and only approach quality when I am troubleshooting an issue.

While researching that help, I found quite a few brilliant coders who has strong issues with the use of static. Google, 'Java static evil,' and you will find slews of much more advanced Java coders than I, that speak fairly freely about the use of static. There are a few static apologists out there as well, and while their arguments in defense of static seem sound enough, they are still couched carefully and they advise limited use of static.

Looking at the arguments for and against the use of static, it does appear that code that is low static, is more likely to be transportable and reusable. Tests of code that is low static are generally simpler and more thorough. Examples of low static code are going to be better examples of object oriented programming. From my experience and from the experience of many others, static bugs can be nightmare fuel. When a bug moves from being one created by poor syntax, math, or logic to being one created by compilation logistics, bug hunting expands the required understanding and attention to minutia by a rather large factor.

Additionally as I started to embark on writing with as little static code as I can, I found another rather huge advantage to reducing ones dependency on the use of static. The ability to make more than one functional instance of an object. My original player object was brim full of static variables. A lot of these did not need to be static, but I figured that static variables might take less clock time for the final code so I left them that way on purpose. It was also loaded with a rather large share of static methods. I could reproduce the player object, but since the player object interacted with just about everything, static was everywhere. The very thought of trying to introduce a functioning second player was horrific. My weak attempt involved copying the player class and making the secondPlayer class. This was bad however since half the critical data in the game was passed by public static variables or methods. After making my code static free, my poor planning for the future was not really an issue. The only complexity was getting the control inputs to control the correct player and that was easy enough to resolve.

As a clarification, what I mean by low static is no static except where I have not come up with a reasonably elegant and clear way to not use static at all. By my best understanding this is a positive step toward writing much better code. It has already made my coding easier.

My issue with static is pretty simple. While coding every so often I manage to create a bug. Most bugs I make cause immediate visible issues in Eclipse. Eclipse will suggest a viable repair to the problem half of the time. Probably one in four, Eclipse either gives me a better way to code what I am trying to code, or gives me a correct example of the parameters I am trying to pass. This is great. After I run the program, most of the remaining bugs quickly show up and I can even see what the line of code that blew up is. If I run the code in debug mode, I can explore some objects and values set.

I guess you've used 'new' for your factory somewhere, and I'm pretty sure those factories use 'new' too in some extra lines of code you didn't show You can almost completely replace 'new' with for example an IoC framework, but that's imho rarely an advantage if all you want to do is release a small game.

I understand your point (factories are a useful pattern), but that's quite a sweeping statement.

Of course the factories are using new somewhere. I just wanted to point out how simple factories (no need to import huge frameworks into your small games either) solves the problem that arises when opting to not use static methods.

If you're not using a factory, and not using static methods - then you're "stuck" manually inserting the required dependencies and references etc which is a huge pain that grows exponentially with project size.

Saying using new is bad is too black & white, I can't take such statements seriously and then as a result of that I can't take the person making it seriously to be brutally honest.

SOMETIMES a factory type solution makes sense. Sometimes a simple creation method is enough, no need to create new classes for such things. And sometimes just using new to construct an object is more than enough. And sometimes creating a singleton or using statics works.

Use the right tool for the job - that's the only pattern that applies always.

Using new isn't bad, but misusing it is (as in, you don't know when to use new and when to pool objects). That's my point. It all comes down to how large the object is, how expensive it is to instantiate, and how frequently you will be allocating temporary ones.

Statics are often the only way to do certain things. While I try to keep global variables to a minimum, sometimes the alternative is worse then just having a global.

The only architecture I've used that makes it easy to avoid any statics is something like the actor model where everything is message passing.

Most of the time, statics in my code are reserved for thread safe variables that are used to share data across threads, such as thread safe queues or maps. I also find that the need to use those patterns shows up more on the server then the client.

I think a better overall goal to shoot for that will also give you very few statics is making your code thread safe. There are a lot of advantages to being able to reuse chunks of client code on the server (game logic especially), and not being thread safe makes it a real pain.

I'm not so sure, sometimes using the tool that's already in your hand works just fine.

I'll agree with you there for the sake of the argument.

Quote

If you'd bother to read the whole post you'd realize it's about how useful factories are (especially in non-static environments) - not about not using new.

Then why oh why did you have to muddy the waters by opening up with that statement? Because where I come from what you say first matters the most to you, the rest is to backup the statement you're making.

You can't blame me for misunderstanding you, you did it all by yourself. Thanks man.

static variables aren't thread safe. You need to do things in synchronized {} blocks or use things like AtomicInteger and or use stuff from the java.util.concurrent package (like concurrent queues and maps etc)

Sometimes I lose a day of programming joy to a long day of frustration while first having to find the cause and second having to adjust a hundred or so objects after finding the bug. In every case so far, these bugs, these horrid bugs that set me back and make me do a huge rewrite, have been static. In every case so far, when I have created the same bug without static being involved, Eclipse has caught the error for me. I don't know much about other SDKs. Eclipse does not seem to error check static as well as it does Enum (which is a type of static, but I love me some Enum's.)

One of the reasons why Eclipse (and any other IDE/engine) is lousy at tracking static variables is because doing so is a problem whose complexity grows exponentially. I work for a static analysis company (not to be confused with static variables) and if you think about it, Eclipse is compiling the method behind the scene and then running through hypothetical execution scenarios to determine possible problems e.g. null pointer dereferences.

Static source-code analysis can easily track local variables because what can access that instance is limited to the current execution thread. Static global variables, on the other hand, can be written to by any thread at any time! Hence no assumptions can be made about what value it contains at anytime.

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