Soli-Tearing Through the Semester

This week, I finished out the Solitaire project and also the official midpoint of this term. I began with Card.java because the Deck could not really exist until it had working Card objects to hold. The detailed TODOs helped me break the project into smaller, testable steps, almost like they were giving me pseudocode to follow. This project confirmed that I work best when I focus on one requirement at a time instead of trying to design the entire program in my head before I start. For the next project, I want to read through all of the requirements first and map out how the classes relate to each other before writing code.

The OOP concept that became clearer for me was class composition. In plain language, composition means that one object can be built using other objects. A Deck contains Card objects, and each Card uses Rank and Suit enums. It reminded me of the joke about “building the whole forest just to get a monkey,” but this time the forest actually felt useful. Constructors are still a little shakier for me because I want more practice deciding when overloaded constructors are helpful and when one should simply delegate to another.

I also compared my work to code generated by an LLM. It produced code much faster than I could, and at first the result looked surprisingly similar to my own solution. After reading it more carefully, though, I noticed that it was not completely ready to drop into the project. Writing the code myself required more effort, but I enjoyed understanding each decision and watching my own tests pass much more.