Accessors (getters and setters) are a big pain in the ass. The Java language should have followed the Uniform Access Principle, but it doesn't, so accessors are here to stay. They might take up extra space in a program listing, but they shouldn't be at all cumbersome to generate -- every IDE has the ability to generate accessors for you, so learn that feature. That or use Lombok which will generate them invisibly so they don't even show up in your source.

Following with my theme...I think it's a better to get an idea of "why" you want to hide implementation details first, before blinding following the "wrap the accessors " dogma. (And yeah, getter/setters should be hidden behind the scenes...but I'll leave at that or I might start ranting about operator overloading again). Beside, invoke the "refactoring fairy" when you get it wrong isn't a big deal.

One thing that I haven't understood from my classes is the idea of having variables private and using getters and setters. I feel like the code is much easier to use when variables are public,

http://en.wikipedia.org/wiki/Principle_of_least_privilegesetter and getters are also useful when you always wnat to do something else, when calling a method. For instance, whenever increase the money, I want a sound effect to play; so instead of manipulating a money variable directly, you call changeMoney(40) which plays a sound automatically - crude example

Roquen is quite right.You should KNOW what good software design is, and what practices are good, which are bad and why and what the pitfalls are exactly.But you don't have to adhere to these rules if you don't think its necessary. Especially in game programming where it is important to get something done.Almost all these rules are for big codebases with a lot of people working on it, constant evolution and re-use... that sort of thing, the "worst/best" case

Doesn't mean you should take a dump on your codebase; but especially when you are the only one that will use this code that you are writing, you should do, what you think makes sense.

BTW, business apps are often some of the most hacked-up crap you can imagine. The average piece of open source code tends to be engineered better because the programmer would be too embarassed to release anything less.

Good engineering is as much about being able to understand and work with your own code as it is about being robust in the face of change. One thing the eXXXTREME!!! DøøD! Programming crowd gave us (other than a name I can't help but make fun of) that's actually useful is a huge emphasis on the importance of tests. Not just writing tests, but writing them first, or at worst, simultaneously. And not just ensuring complete test coverage, but writing your code in such a way that tests are easy and natural to write. Tests not only help you verify proper behavior, which is nice when you're constantly changing things around, they also make you use the API you're designing much earlier, which can clue you in to design problems early, even if all the tests are passing.

Making everything testable has a huge positive impact on your design, because it forces you to modularize things so you can write isolated unit tests with alternate stub/mock implementations of dependencies. Now for games with their heavy graphical component, automated unit tests are probably not so doable. But everything else should be as easy or easier to test than to use in real-world code.

business apps are often some of the most hacked-up crap you can imagine.

Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code?? Who'd a thunk!

Quote

Good engineering is as much about being able to understand and work with your own code as it is about being robust in the face of change.

Exactly..and in here is part of the "artistic" element. We all develop techniques and styles as our skills evolve. Brilliant code today is likely to be bloody-aweful in a few years time. The bottom line here is there's no replacement for experience...so get off your bottom and program!

EDIT:OP: I clicked on your blog where you have a mention of Jobs & Richie. The really ironic thing here is that http://en.wikipedia.org/wiki/John_McCarthy_%28computer_scientist%29 died soon thereafter and is never mentioned in popular press. It's kinda dicky of me to measure the worth of some person's life...but McCarthy's contributions make Richie's look pretty scant.

business apps are often some of the most hacked-up crap you can imagine.

Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code?? Who'd a thunk!

the point is that most business software is just quickly thrown together code snippets without any methodology.

And pls don't give crappy advice like, use this only when working on a huge cooperate software project, because it doesn't matter for your little game. Let me tell you something, every big software started small and in the beginning a lot of people think like this and end up with some crappy software after some years.

I do work a bit for a little software firm which does software for small industry businesses, there is one project which started small. And the boss told everybody just to finish it as fast as possible, because it was a one time only thing anyways.Now we ended up making the software at least 5 times bigger and licensing it to several other companies. I can tell you how much fun it is to work with the old l agency code. We had to rewrite a lot of modules just because it is so a big pain in the ass to work with them.

I do work a bit for a little software firm which does software for small industry businesses, there is one project which started small. And the boss told everybody just to finish it as fast as possible, because it was a one time only thing anyways.Now we ended up making the software at least 5 times bigger and licensing it to several other companies. I can tell you how much fun it is to work with the old l agency code. We had to rewrite a lot of modules just because it is so a big pain in the ass to work with them.

And still your boss was (probably) right. It's extremely important to publish a product to client #1, even if it sucks behind the scenes. That first client has to use it first, before it can become a success. Trying to get it absolutely right for client, and you probably never get it good enough, and miss deadline after deadline, before the developers deem it 'worthy'.

Your boss is there to keep the business running, not to win a prize in code quality. That the maintenance is a burden, is just a minor inconvenience - for the business - regardless of what is it to you.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I think its only important when lives are on stake or big sums of money.

Quote

On June 4, 1996 an unmanned Ariane 5 rocket launched by the European Space Agency exploded just forty seconds after lift-off....development costing $7 billiondestroyed rocket and its cargo were valued at $500 million...software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,768, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.

Not really so much a software engineering problem, but still makes me angry that a lazy programmer caused this (more than angry obviously);IMO space shuttle code should be THE most sophisticated code there is. Maybe on par with CERN code.

The problem with software engineering, is that, as opposed to the designs of (structural) architects, there is no margin to work with. It either works or it doesn't. When you build a bridge, you typically make it capable of handling 3 times the maximum stress it will be subjected to throughout its projected lifespan. There is no such concept in programming. A single typo or brain fart will bring the entire application down, while a rusty bolt will not affect the structural integrity of the bridge to the extend that it will collapse in the next few decades. So, there you go, there is no safety net in programming, and unless we manage to reliably put complex business logic in neural nets, it will stay this way. Forever.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Not really so much a software engineering problem, but still makes me angry that a lazy programmer caused this (more than angry obviously);IMO space shuttle code should be THE most sophisticated code there is. Maybe on par with CERN code.

The Ariane 5 incident is a *lot* more complicated than "a lazy programmer". The integer overflow is just one piece of a big chain of events that caused the overall failure.

Most interestingly, the code was correct when originally written. The situation couldn't occur on the hardware it was written for, and only later was the same code reused on a different hardware where the error was now possible. You could equally pin the blame on hardware engineers for not having sufficient documentation to describe the differences or on testing for not fully exercising the functionality of the system as a whole. But pinning blame in a complicated failure like that is neither helpful nor interesting.

It's been a while since I read the full investigation report into Ariane 5. Have you read it? I would recommend it for anyone who wants an insight into how tiny errors (both technical and people) can propagate and grow.

well it is still an unacceptable mistakeyou have "all" the time and money in the world to prepare such a systemits just such goddamn waste, and people could have died too, just because some people didn't triple check after all parts were in place

business apps are often some of the most hacked-up crap you can imagine.

Wow...so blind-esque following on some methodology doesn't insure well-designed, written and bug-free code?? Who'd a thunk!

No, it's more like they're designed without any methodology in the first place, often by the "guy who knows some programming". The world of "business apps" is full of one-offs that people thought was throwaway code when written, that's still running 10 years later.

I already have packages and classes and I feel like it's organized, but I still have to search through my classes to find certain methods and variables. For example, I'm in the process of drawing the equipment my player has equipped in the UI and it took me a few minutes to trace back through the player class and equipment class where I actually stored the equipment information. Also when I add more character classes(archer, wizard, etc) to my game, I'm going to have to go through quite a few java classes to add functionality for a new character class. I'm worried that it will be easy to miss places that I would need to add code for full functionality. Is this just inherent in bigger games?

I could upload my whole zip file project, but I feel it would be a lot to look through.

What IDE are you using? Finding methods and variables should be as easy as tab completion.

Adding a new class shouldn't require onerous amounts of work if you have a default implementation (e.g. MouseAdapter implements most of the MouseListener interface).

Probably best if you can post an example. Then you'll get more distinct feedback.

The problem with software engineering, is that, as opposed to the designs of (structural) architects, there is no margin to work with. It either works or it doesn't. When you build a bridge, you typically make it capable of handling 3 times the maximum stress it will be subjected to throughout its projected lifespan.

I wouldn't say there's no margin to work with in certain kinds of software projects. It's just that it's between almost working and functioning rather than between basic functionality and working correctly with future problems in mind. Also:

1. Build bridge2. Use and maintain the bridge for a few years3. Wonder why you're still putting money into a project that's already finished4. Keep using bridge for three times the projected lifespan5. Argue over the best thing to do with the bridge6. Build another bridge to accommodate more traffic without shutting down the old one7. Goto 2

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