My focus has been more on the core of the game itself, so there are some things that aren’t as polished as others. One example is the form to add players and start the game. Depending on my free-time and pressure from friends I may continue to build upon it.
Challenge for my fellow code geeks
One area that I know needs improvement is handling aces. The logic I am using for the possible double value (1, 11) of an ace is oversimplified and can lead to poor choices by the dealer. For instance, two aces will always equal 2, and never 12.
One suggestion that was given to me is to change how I wrote the objects. Tim Novinger suggested I switch to a Object Literal approach. The reason I choose to use functions as objects is the ability to create a new instance of objects.
Does refactoring ever stop?
I tried my best to showcase best practices when it came to the design of objects. I spent most of the day yesterday refactoring the code. The last change I made was to separate all the core logic of the game from the display logic. I’m not fully satisfied on how the outcome, but it is much better than before. If you wanted to change from jQuery to mootools it would only effect the display class.
It would be best to refactor the the display code up into smaller objects. The fact that the “BlackjackFrontend” object is responsible for displaying the card just doesn’t sit well with me. I’d also like to refactor blackjack specific information from the “Player” object to an one that extends the “Player” to maximize the potential for code reuse.
I think I could refactor this code to death.
Demonstrating the need for testing
This project really taught me the need for unit tests and automated testing. The form of automated testing I used was my dear wife, and I have to thank her for her diligent efforts. Her poor fingers from having to refresh until a specific situation occurred. I still am not sure what would happen if everyone got a blackjack on the deal.