Exercise Wednesday

Goal: Practice everything we've learned this week by creating a command line interface word guessing game. Make sure to continue to practice the "Red, Green, Refactor" BDD workflow (this will be required on this week's independent project), and pay special attention to concepts introduced this week: Such as getters and setters, and encapsulation and visibility.

Warm Up

  • How is testing with objects different from testing in an application where we don't create our own custom objects?
  • What does "Encapsulation" mean, in reference to coding?
  • What about "visibility"?
  • Why is it best practice to declare attributes of a custom class private?
  • When would we use char? What is its corresponding wrapper class?
  • Generally speaking, when would you use a primitive? When would you instead use its corresponding wrapper class? Why?



Practice creating encapsulated classes, custom objects, getter methods, and using JUnit testing with objects by following along with the Testing With Objects lesson to create the Rectangle application.

Command Line Word Game

Finally, integrate all concepts from the pre-work and homework this week by creating a command line program to play a version the game commonly known as "Hangman". If you've never played this game, or would like a refresher, check out this YouTube video.

  • As always, follow the "Red, Green, Refactor" workflow. You should always write a test before implementing a new behavior. Keep this lesson open as you code, and follow along with the workflow as you develop the program.

  • You'll want to create a class to represent each new Game. To begin, Game objects should include attributes that hold the answer, and past letters the user has guessed. Classes should be fully encapsulated, containing only private properties. Use getter methods for all properties you must access outside of the class.

  • To begin, define an array containing a limited number of words. When a user creates a new game, choose a word to use from this array at random.

  • Don't worry about programming the command line to "draw" a stick figure as the user guesses until you've tackled and tested the primary logic of guessing letters and determining if/when a user has won the game.

  • Eventually, when your logic for guessing letters and determining wins is in place (and well-tested), work on displaying the user's progress, like this:

A _ _ L E


  • As seen in this lesson the indexOf() method may come in handy. You can call it on an array. If the item exists in the array, it will return this item's index. If it does not, it will always return -1.

Further Exploration

  • Once you have a basic game up and running, increase the difficulty by limiting the number of guesses a user may make. Once the user reaches this limit; let them know they've lost.

  • Then, add multiple difficulty levels and allow the user to select one. Depending on which they select, their game's word should be chosen at random from an Array of "easy", "medium" , or "difficult" words.

  • Then, add an additional gameplay option that allows the users to enter their own word to create a game. When the program executes, one partner should be able to enter a word (while the other isn't looking!). Then, the other partner should be able to play the game and attempt to guess the word.

  • Add a visual component to your application. Instead of the stick figure commonly used in this game, consider something original! Perhaps a Monster, or other image slowly appears as you make incorrect guesses. This kind of "text art" is called "ASCII Art". A quick Google search should reveal plenty of potential 'images' to use. Or, consider using a narrative instead of an image!

Pig Dice or Tic-Tac-Toe

In the last week of your Intro to Programming course, you created either a Pig Dice or Tic-Tac-Toe game.

Recreate one of these as a command line interface game in Java (consider tackling the project you didn't complete in Intro). Make sure to follow the "Red, Green, Refactor" BDD workflow throughout the course of development.

Peer Code Review

  • Tests have complete coverage for the behaviors that need to be tested.
  • Tests begin with small behaviors and increase in complexity.
  • All tests are passing.
  • Getter and setter methods are present and functioning.
  • Logic is easy to understand.
  • Unnecessary files are discluded from Git with a .gitignore file.
  • Project is in a polished, portfolio-quality state.
  • You are able to discuss your code, and the concepts behind it with an instructor using the correct terminology.
  • Code and Git documentation follows best practices (descriptive variables names, proper indentation, detailed commit messages, well-formatted README.)