Thank you for the feedback subtle_wonders. I didn't go to far into constructing the code with best practices for Java as I know them because I was only testing an idea. The algorithm may eventually be ported to Construct 2 for a game.
Glad to be of some help.
I have a question. With Java best practices, is it always better to shove things into a separate class or is it acceptable, if the program is small, to keep it all in a single class? What's the pros and cons?
Best practice is to always put code in a separate object (that meaning not in the main class). That however does not necessarily mean it will provide the best result though; that being speed and only speed. An example of jamming stuff up in the main class is if you were creating a POJO (Plain Old Java Object) to substitute a output only BASH script in Linux/UNIX. Remember, the String[] args of the main parameter refer to the arguments taken in at the command prompt when typing in java someJavaMainClass. If let's say you created a POJO that was designed to run a sequence of Linux/UNIX commands using the getRunTime() method of the Runtime class (http://docs.oracle.com/javase/6/docs/api/), it may be practical to do so only in the main class. However, it is actually more efficient to do this in a language designed to work at a lower level of support, such as PERL, C/C++. as you are taking a unnecessary leap into a higher level language with the use of the JVM, which is developed largely in C++. It's like avoiding C++ to use C++, which simply doesn't make any sense and uses more memory in the process.
The rule of thumb is, if you need to instantiate even one object, then you are using Object Oriented Design, and it is best practice to adhere to it. If you're not, then it's kinda fruitless to use Java unless your environmental situation mandates it.
I got a really good intro to the grid bag layout.
AWT, Swing or Java FX? You should really jump on Java FX if your not currently using it. Java FX will at some point deprecate Swing, and AWT is mostly deprecated already. You should really learn how to use either Swing or Java FX from the source up, but if you ever needed to cheat: Ever hear of Java FX Scenebuilder (http://www.oracle.com/technetwork/java/javafx/tools/index.html).
I figured the program is small so it would create more work than needed for a program that doesn't really require any scaling later on.
This is typically a debate also found in C++. Both in C++ and in Java, the answer is the same; reader's simplicity. The moment you are referring to a part of your code as a separate English subject, that subject should be in a different class. For Example, if I was coding a game about cats, dogs, birds, and fish, I would have 6 classes:
- Main (instantiates cat, dog and bird through animal)
- Animal (abstract)
- Cat (extends animal)
- Dog (extends animal)
- Bird (extends animal)
- Fish (extends animal)
Methods (otherwise referred to as functions in C++) would refer to the characteristics of a class. Here is an example:
Cat (extends animal)
Sound() (makes a unique sound pertaining to the characteristics of the class defined)
Move() (moves in a unique way pertaining to the characteristics of the class defined)
Eat() (Eats unique food in a unique way to satisfy its appetite and physical needs)
Dog (extends animal)
Sound() (makes a unique sound pertaining to the characteristics of the class defined)
Move() (moves in a unique way pertaining to the characteristics of the class defined)
Eat() (Eats unique food in a unique way to satisfy its appetite and physical needs)
Bird (extends animal)
Sound() (makes a unique sound pertaining to the characteristics of the class defined)
Move() (moves in a unique way pertaining to the characteristics of the class defined)
Eat() (Eats unique food in a unique way to satisfy its appetite and physical needs)
Fish (extends animal)
Sound() (makes a unique sound pertaining to the characteristics of the class defined)
Move() (moves in a unique way pertaining to the characteristics of the class defined)
Eat() (Eats unique food in a unique way to satisfy its appetite and physical needs)
This is essentially important because, let us say that you now needed to consider which animal was a mammal (Dog, Cat), an aves (bird), and a paraphyletic (fish). This would be done using interface as you can extend only once from an abstract. In a more gamer sense, you could see it this way:
You have a mage (aka, wizard). You create an abstract of their AD&D class (necromancer, conjurer, enchanter, etc). However, their sortie of spells depend on an alignment, so you also create an alignments (evil, natural, good). You would abstract the wizard's AD&D class, and interface their alignment. The sortie of spells they use could then be considered based off of both the abstraction and inclusion of their associations (e.g., David, the Evil Necromancer [spells control the undead and unleash disease on helpless saps], John, the Good Necromancer [spells control the undead and allow him to siphon his own life force to heal a helpless sap], Brian, the Evil Wizard [spells that control the weather and use it to devastate the land because helpless saps should just be vaporized]).
Regardless if the project is large or small, if you don't look at it for a year, or someone else looks at it for you, it becomes extremely difficult to understand it quickly.
My presumptions also guessed that doing this would make the program leaner on memory use and garbage collection.
You are correct.
What are the thoughts on those ideas?
Their is a way to compromise between what you're trying to do and what Java is designed to do. I would recommend researching Singleton, and practicing on how to develop it and around it. For a small application, it's possible to get away with using a C++ practice in Java, but as projects get bigger, you will need to consider object management.
A Few Notes: Since we are talking about objects and memory:
Since you are creating a GUI: If you create a program that uses String, you are essentially creating an object. Most people know this. However, what most people do not know is every time you change the value of your String object, you are throwing away an object and creating a new String object. To get around this, you can use either StringBuffer (is thread safe) or StringBuilder (is not thread safe) as the object is unchanged when the value changes.
If you set an object to NULL and then declare System.gc(), you are likely to have that object destroyed much quicker than if it was just simply left as is. This is again, a good reason to use the try/catch/finally exception handling. In finally, you could create a clean up procedure, and later declare a System.gc() to schedule the destruction of that object you cleaned up. An example of where this could be used in your code is as follows:
After the last use of Random rand, use:
rand = null;
System.gc();Over all, I see you doing a great job. For the size of your program, I'll assume it's fine enough to remain in the main class. I just don't want to see you get into the bad habit of using object evasion over object management. Hope this helps further. Also, thanks for the feedback.
