Learning Journal CST338 - Final Week

 Learning Journal — End of Semester

1. Reading my own Project 1 code now

Opening Project 1 again, the first thing I noticed is that the code actually reads like something I designed on purpose. When I was writing it, each file felt like its own fire to put out. Rereading it now, I can see the shape of the whole thing: four pile classes implementing one Pile interface, a Game class that orchestrates them, and a Code enum that lets every method report success or failure in a structured way.

The class I'd rewrite first is Game.java. Right now it's a fat controller that holds every pile, every flag, and every method for moving cards. It works, but the UI has no way to know when state changes unless something explicitly asks. If I wrote it today I'd apply the Observer pattern: Game would maintain a list of listeners and fire an event after every successful move, and the UI would subscribe instead of polling. That's a real separation of concerns, and it would make the model stop caring about who's watching it.

2. Two things that went well

The first win is the Pile interface. Committing to a shared contract with addCard, canAcceptCard, removeTopCard, and peekTopCard felt tedious while I was writing four nearly identical files, but the payoff hit immediately in Game.java. I could iterate over foundations and call canAcceptCard without caring about the concrete type. That's the moment polymorphism stopped being a vocab word and started being a thing I used.

The second win is the Code enum. Returning Code.SUCCESS, Code.INVALID_MOVE, and the others instead of booleans made Game much easier to reason about. Checking foundations.get(i).canAcceptCard(card).isSuccess() reads cleanly at the call site, and it made unit tests sharper because I could assert on a specific failure reason instead of just "something went wrong."

3. Skills that have genuinely improved

First, interfaces versus inheritance. Early on I would have made Foundation and Tableau extend some abstract BasePile class just to share code. I understand now that they aren't is-a variants of each other. They're two different things that share a contract. Implements means behaves-as; extends means is-a. I know the difference in my gut now, not just on a quiz.

Second, the Factory pattern. The SceneFactory refactor of the temperature converter was the moment it clicked. Pulling all scene construction into SceneFactory.create and reducing Main.start to three lines taught me what Single Responsibility actually feels like in code. Adding a new scene later would mean one enum value and one private builder, without touching Main.

Third, reading code I didn't write. By Project 1 Part 3 I was using unit tests as a spec. I'd read GameTest first to understand what Game was supposed to do, then work backward to the implementation. That's a skill I didn't have at the start of the semester.

4. Looking ahead to Project 2

The skill I'm planning to lean on heaviest is separation of concerns, specifically the MVC mindset the SceneFactory work introduced. A full JavaFX app will have far more scenes and state than a two-scene converter, and if any one class does too many things the project will collapse under its own weight. I want model classes that don't import javafx, controllers that delegate to the model, and a factory layer that owns scene construction.

What I'm watching closely is the Observer pattern in practice. I understand it conceptually, but I haven't wired one up in a real JavaFX app yet. JavaFX has its own property binding system that's essentially Observer under the hood, and getting comfortable with Property and listener registration early will save me from rewriting half the project when I realize the UI isn't updating.