Thread: Split a program into smaller objects

There isn't really a strict rulebook to follow. A general guideline is that each method should do one thing, and each class should have one job. If you can't sum up a class or a method in a single sentence, you might consider splitting up its responsibilities. Extracting listeners is one place to start.

Another general rule to follow is that your actual logic should be separate from your display code. This isn't always completely obvious, especially with games, but one way to look at it is "what if somebody else wanted to implement this game in a way that looks completely different, using my code?"

Originally Posted by Melawe

That's what I was thinking, but if you looked at the code, there isn't a lot of it. So I don't know if there is any use in making a new file for health, time, or points. The key listener code is the only thing that took a nice amount of lines to consider splitting.

It doesn't sound like health, time, or points require their own files. But perhaps the display for those things could be in their own class that draws that part of the screen?

Originally Posted by Melawe

Do you mean AI when you say logic? Or everything to do with staying alive? If AI, there isn't any AI code atm, but I will keep your comment in mind since its one of the next things to code.

I meant pretty much anything that would be considered your game engine versus its display. For example, movement, positions, etc. might be kept separate from whatever is displaying those things. If somebody wanted to port your game to use a different renderer, how hard would it be? What if they wanted to convert it to a command line game? Like I said, games oftentimes make the frontent/backend separation pretty fuzzy, but it's one way to think about things.

If you have not read about them yet, you might study the basics of design patterns. They can be a bit overwhelming and confusing to begin with, but they are methods that have stood the test of time in helping with code re-usability, maintenance, and much more. Breaking things into smaller classes is one thing, doing it with a certain intent and having a set of rules to guide you towards that intent is another. Design patterns help you with the latter.

Google 'java design patterns' and there are any number of sites that try and describe the patterns. All are important in one context or another, and all oftentimes have implementations in J2SE. For example:

1) Observer - similar to the 'listener' types in Swing (ActionListener, KeyListener, etc...), it facilitates notifying observers when a change or event in one class occurs. My model (data, etc...) is often written completely separate from anything else (and access to the data is abstracted away to prevent concrete ties) and then plugged into other classes (such as a UI) using this pattern.

2) MVC - sometimes listed as a J2EE concept, it is also a J2SE concept. Many Swing components are designed with this in mind. Take for instance a JTable - it has a TableModel (the Model), CellRenderers (the View), and event notifications such as ListSelectionListener, MouseListener, etc... (the Controller) - it even goes further to separate out other features, such as selection.

I list the above two not just because they have implementations that serve as great examples for how and when to use, but also because they can serve a lot of importance in applications such as the one you are writing. They are not essential, but serve to make life much easier down the road