Patterns Currently being employed:
----------------------------------
Facade: Interface between GUI and GameKernel (Facade)
	Not properly implemented because it is performing control operations.


Command: Turned into data class with no behavior (Move)
	 Had an execute(NetworkMove)

Strategy: Player is abstract, Network and Local implement the different ways they work.

	  (Player/NetworkPlayer/LocalPlayer)

Observer: Observed to fire events(Timer)
	  Observed to fire events(Notifier)

Mediator: Try, but didn't work out too well.(Driver)



Bad Smells
----------
Hard coding of board squares
Constants not declared final
Methods returning constants
No cleanup of debug sections
Java Vector
Strings not externalized
Unclear variable names
Large class - CheckerGUI.java, Rules.java, Secondscreen.java, NetworkPlayer.java, Firstscreen.java, Driver.java
Long method - initComponents(CheckerGUI.java, Firstscreen.java, Secondscreen.java), processCommand(NetworkPlayer.java), validateMove(Rules.java), checkForPossibleJumps(Rules.java)
Giant if - actionPerformed(CheckerGUI.java)
Large nested block depth - update(CheckerGUI.java)
Data classes - Piece.java, KingPiece.java, SinglePiece.java, Move.java
Large nested blocks - checkForPossibleJumps(Rules.java), checkForOtherPossibleJump(Rules.java), wallPieceMove(Rules.java), validateMove(Rules.java), actionPerformed(Secondscreen.java)
Duplicated code - Rules.java
Generic Catch blocks everywhere that don't provide any information

Refactoring ideas
-----------------
packaging (MVC)
Use iteration to create the board and the GUI
Only need 32 buttons for GUI, not 64, store in a collection
Observer for GUI/model update
Rules can be implemented as a Singleton
Facade can be implemented as a singleton, and renamed to match its purpose (more of a controller than facade)
Instead of inheriting Component to fire action events, Observer can be used in Facade
Rename 
Proxy - "player proxy" for network player and "board proxy" for remote server
Player should track its pieces
Piece should know its location
With those changes, the Board class is no longer needed
In Rules - Remove "CheckForOtherPossibleJump" and replace with multiple calls to "CheckPossibleJumps"
	also extract methods from checkPossibleJumps to reduce complexity
  ValidateMove can be used for both regular and king moves
  Extract initial "for" loop in ValidateMove to check all possible jumps for current player (i.e. forced jumps) into a new method
  Use an index from 1-32 to represent valid positions on the board
  A simple formula can then be used to validate move (current position +4 or +5, and some other fancy math to check wall pieces)
  Using the new indexing, fillWallVector and wallPieceMoves are no longer needed
Piece can be "de-abstracted" to remove the need for separate Single and King pieces
Piece can keep a collection of possible moves, which is updated when the piece moves, so it doesn't have to be calculated on every move for every piece
Checking for possible jumps will still have to be done at each turn, but by having each player keep track of his pieces, it's not necessary to check every square of the board
