Requesting code review
I am hoping for volunteers to review some Java code of mine from last semester and suggest improvements to the design and coding style. They were all rushed so there is probably plenty to comment on.
These are my primary concerns:
The ImageLoader framework used in all three programs was provided by the instructor. I find its usage odd. The ImageLoader is implemented in a semi-global fashion where all objects that can diplay images have references pointing back to an instantiated ImageLoader object or they just declare a new one for themselves. Is this a good practice? Might it be better to make the ImageLoader an interface and have the classes implement it, if possible, or do something else entirely?
In some cases, sub-objects on a game board have references back to the parent board in order to do things needing information about the board, like move and clip against a wall. In the MineSweeper game, I went the other way and gave the Board a reference to the overall game and had it send the MouseEvents it captured back to the game object. It all seems hacky.
In a grid-based game like the third, is it more proper for an object to move on the game board (object.move(x,y) with the object having a pointer back to the board) or for the board to move an object across it (board.move(obj,x,y)), taking into account that the move can be blocked by other objects? Or should there be move functions for both board and object, with the board's calling the object's? Besides propriety, what is more likely to causes less trouble in maintenance and etc?
In the balls game, I put collision functions inside the moving object and had the gameboard call the objects' collision functions. The collision functions look like x.collideWith(y) where Y is one of the types that type X can collide with. The game board has all of the objects in one set of the most basic class. When the board loops through the set and detects a collision, it triggers the descended class's collision function with the most basic class as the argument, no matter what class it collided with. I hacked around this by having this method run getClass().getString() and shunt off to the method for colliding with the right descended object. I've read that I should never have to do that, so can anyone suggest a better way?
In the third game, I had an object representing the NxN-cell playing field and I wanted to add another object that made a 1-cell border all around it. I wanted something grid-based that would let me fill in part of the grid with an NxN-sized object. I used GridBagLayout which by all accounts is a huge mistake, but I could not find anything else that would do the job without requiring a change to the logic for the playing field. What alternatives exist, if any?
My use of the standard objects and libraries can probably be improved as I am weak in this area.
Thanks in advance to anyone who takes the time to look at any of these files.
