Feedback

[remihoeppe]

Snap Project – Feedback: Niko

Brief Stages (50%)

Criterion	Score	Notes
Stage 1: Card & CardGame, 52-card deck	10/10	Card has suit, symbol, value (Unicode), getters, and toString(). CardGame has name, 52 cards in createDeck(), getDeck() (prints), and getDeckOfCards().
Stage 2: dealCard, sort, shuffle methods	20/20	dealCard() returns and removes first card. sortDeckInNumberOrder(), sortDeckIntoSuits(), and shuffleDeck() implemented and return/store deck as required.
Stage 3: Snap class complete, CLI, symbol match	40/40	Snap extends CardGame. Two players, enter to deal, game ends when two consecutive cards have the same symbol (currentCard.getSymbol().equals(previousCard.getSymbol())). Correct.
Stage 4a & 4b: Two player + timer	50/50	Two players with names, turn-taking. When snap occurs, 2-second window with visual progress bar (Timer/TimerTask); player must type "snap" in time. Win/loss and “nobody wins this round” handled.

Brief total: 50/50

---

OOP (50%)

Pillar	Score	Notes
Abstraction	10/10	Clear responsibilities: Card, CardGame, Snap, Player, SnapTerminal. Constructors set up state.
Encapsulation	10/10	Private fields with getters. Appropriate use of protected (e.g. getDeckOfCards()) for subclasses.
Inheritance	10/10	Snap extends CardGame, uses super("Snap"), reuses deck and methods.
Polymorphism	10/10	TimerTask.run() overridden for progress bar. toString() overridden in Card and Player.
Bonus	0/10	No interfaces or abstract classes.

OOP total: 40/50

---

Code Quality (20%)

Score

Notes

15/20

Javadoc on key methods and classes. Meaningful names, clear structure. Package error: all classes use package src.main.java; — that is invalid (it’s a path, not a package). It causes compilation/IDE errors because the package does not match the directory under src/main/java/. Use the default package (remove the line) for files in src/main/java/, or use a real package (e.g. package snap;) and put files in src/main/java/snap/. Timer: the snap input still blocks on scanner.hasNextLine() so "time's up" only after user presses Enter; use Future.get(2, TimeUnit.SECONDS) to enforce the limit. Other: Card value comment wrong (J/Q/K/A); "main mandatory in every class" is false; five classes have main(); Scanner in Snap never closed; SnapTerminal unused.

---

Summary

Section	Score
Brief Stages	50/50
OOP	40/50
Code Quality	15/20
Total	105/120

What went well

• Full brief coverage including Stage 4: two-player game with a 2-second snap window and a clear visual countdown.
• CardGame and Card match the brief; Snap correctly implements “two consecutive cards, same symbol.”
• Code is readable and well documented; SnapTerminal shows a clean separation of timer UI if you want to reuse it.

Suggestions for improvement

• Fix package declaration: Every class has package src.main.java;. Remove it (default package) or use e.g. package snap; with files in src/main/java/snap/. The current declaration breaks compilation and IDE resolution.
• Fix timer so it actually enforces 2 seconds: In Snap.play(), the loop that waits for "snap" uses scanner.hasNextLine(), which blocks until Enter. The program never shows "time's up" until the user types something. Use a time-bounded read (e.g. ExecutorService + Future.get(2, TimeUnit.SECONDS)) so that after 2 seconds you can show "time's up" even when the user has not pressed Enter.
• Card.java: Fix the value comment (line 6) to J=11, Q=12, K=13, A=14; the comment "Main method (mandatory to any Java class)" is incorrect (main is only required in the entry-point class).
• Multiple main() methods: Card, CardGame, Player, SnapTerminal, and Snap each define main(). Only Snap is the real entry point. Consider removing or moving the test mains so it is clear how to run the game.
• Resource leak: Each new Snap(...) creates a Scanner(System.in) that is never closed when starting a new game. Consider closing it when a game ends or reusing a single Scanner.
• SnapTerminal: Never used by Snap (Snap has its own inline timer UI). Either use it for the snap prompt or remove it to avoid dead code; if kept, it has the same blocking-timer issue.
• Consider an interface (e.g. for playable games) or an abstract base class if you add more games, to aim for the OOP bonus.
• Small note: Snap.play() continues the game after a snap round (“nobody wins this round”) and can deal again; the brief does not require that, but it’s a reasonable extension.

Well done.