Checkpoint 3:
While working on Yahtzee, I got to experience Object-Oriented Programming (OOP) by writing classes that represented different parts of the game,
such as dice, goals, and the overall Yahtzee game itself. Each class had its own attributes and methods, which made the program easier to
organize and understand. For example, the Die class handled rolling and showing values, while the Yahtzee class managed turns, scoring, and
game flow. This style of problem-solving is different from the skills in Unit 1 and 2 was mainly focused more on functions and variables whereas in
Unit 3 I was able to write out classes with OOP where each class handles its own part of the game. This ultimately makes it easier to make changes,
fix bugs, and add new features later on.
For checkpoint 2, I have always found it easier to read and describe code rather than actually writing out the code. When writing out the code
I think to myself what the process is doing and how it is doing it. This normally takes the longest for me because it is easier to read what the code
does rather than write code for the procedure. When writing docstring for my code I always pretend to run a simulation in my mind and picture
what is happening which helps me read and understand the code. In future projects I will include writing docstrings because it helps me keep
track of what certain codes do and why it does what it does.
A problem I can solve using classes is simulating a deck of cards for a card game. Each card could be an object with attributes like its suit
and its value. A separate class called Deck could hold all the cards, shuffle them, and deal them to players.
This setup would make it easier to model real game situations like Blackjack or Poker, since each player could also be a class with their own hand
of cards.
