Skip to content

Latest commit

 

History

History
77 lines (48 loc) · 2.63 KB

F16_lab03.md

File metadata and controls

77 lines (48 loc) · 2.63 KB
Raw

F16_lab03.md

cs56-games-dealer

by Eric Xiao | Kin Kwan Poon

a)

The dealer class represents a standard deck of 52 playing cards and displays these cards in a text based format.

b)

As a user I can shuffle the deck as well as deal cards from it and see which cards have been dealt and which are left in the deck.

c)

Yes, the software can run. All cards in the deck are represented as strings and these strings are written to the string as a way to display cards. The deck can shufle itself or deal any number of cards.

d)

We can implement a better graphical interface so that the cards can be represented with images rather than just strings displaying the name of the card. In addition, we can make the game more fun by adding games such as Blackjack to be played with the deck.

e)

The current ReadMe gives a brief description of the program and instructions on how to run it, as well as an overview on how it works. Information on how to improve the software would be helpful to people in the future, so they have direction on how to make progress.

f)

The build.xml is missing a description for "clean" as well as for "javadoc" and "jar". There is some old legacy tags that should be modified, as they are from Winter 2012.

g)

There are currently 7 open issues, and their expectations are clear. If each of these issues are solved we could earn 1000 or close to 1000 points.

h)

At the moment no new issues have been added.

i)

  1. The main method, in the dealer class, is very long and some code can be moved into other methods to make main more clear to other programmer.

  2. The code is kind of hard to read, due to word alignment. We could add or remove some space on each line, make them aligned, so it is more readable. Also, we need to remove some unuseful comment.

  3. The code of the card in deck is just plain text. The previous programmer just create them by copy and paste the name of each card, which is very redundant.

  4. The GUI of this program is not so GUI. It just shows up a panel with full of text. However, even the GUI looks so simple, the code under the hood is very complicated.

  5. Also, there are many repeated code in dealer.java and GamesDealerPanel.java. Some of them are doing the same thing. This is not OO-style.

j)

There is no test coverage and no JUnit tests at all. There are many opportunities to implement test coverage for each class in the project, and more as the project develops.

We would begin by adding JUnit test coverage to the existing classes and additional driver classes for testing if necessary.