cchung/lab_dice
1
0
Fork 0
generated from mwc/lab_dice
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update assessment repsonding to git log

Browse Source
This commit is contained in:
Chris Proctor
2024-03-01 20:45:43 -05:00
parent 4fe9b95eda
commit 384d3b8b17
1 changed files with 26 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
assessment.md
View File

@@ -2,7 +2,7 @@
Everything works as expected. Nice work! Everything works as expected. Nice work!
## Comments ## Checkpoint 1
I love your decision to comment your code, and to write the generalized I love your decision to comment your code, and to write the generalized
function `findn`. Within that function, your loop iterating over die function `findn`. Within that function, your loop iterating over die
@@ -26,7 +26,32 @@ def findn(self, nofakind):
Just a little cleaner :) Just a little cleaner :)
## Checkpoint 2
Within your `yachtzee_goals`, I'm guessing that you probably had a feeling Within your `yachtzee_goals`, I'm guessing that you probably had a feeling
that copying the same method over into multiple classes wasn't the best way that copying the same method over into multiple classes wasn't the best way
to do it--this would be a perfect place to use a subclass or a mixin, to do it--this would be a perfect place to use a subclass or a mixin,
python's approach to inheritance and multiple inheritance respectively. python's approach to inheritance and multiple inheritance respectively.
## Comments
> I think I was thinking of objects pretty
> literally as "things" one can do stuff to or with, e.g. dice that can be
> rolled. Goals don't immediately jump out as me in the same way...
I quite agree! This was actually one of my goals in this unit--to move from more
concrete instantiations of classes (e.g. modeling dice) to less concrete (e.g.
modeling Goals, or, in the game project, things like Strategies.
> I imagine if I were to try doing this in unit 1 or 2, instead of
> treating the game as an object interacting with other objects (the dice
> and goals), it'd probably be some sort of loop with functions being
> called to mimic the methods and a declaration of a lot of global
> variables to keep track of things like score...
Yes, exactly! The beauty of encapsulating this kind of behavior within
classes really starts to shine when your projects get bigger; if you have n
components in a project, there are n^2 possible interactions if everything
potentially interacts with everything. Debugging becomes impossible.
You have some really lovely reflections in these git comments :)