Quote:
Originally Posted by daveT
Yuck.. Procrastinated on PS6 and now I'm too tired to bother finishing the last question after 3 nights of 3-hours sleep. I know it's super obvious, but I'll have to let this one be @ 85%.
Project for tomorrow: I really want to look into that Trigger class. I honestly don't believe it needs to be in the code at all, unless you just want to gracefully handle and error?
I don't think it needs to be either but its purpose (I think) is like the student class from the lecture example.
It's there so you don't have to reference individual classes from other classes or get stuck having to check vs a ton of different sub classes. What happens if you want to add 15 more triggers? You wouldn't want some method in a class to be changed to reflect that. If the method using those triggers only needs to check for "is this a trigger?" then we avoid the issue and that's why Trigger exists.
I'm going through PSet7 now and a similar thing looks like it might happen. Our little robot buddy is an abstract class just like trigger. I assume later on in the pset we'll have to implement different kinds of robots.
Similar to the drunken farmer from the lecture. We had a few drunken famers but they were all drunks.
This pset is really cool if you happen to be taking cs50x too because both of them (6.00x week 7 vs. cs50x week 4) seem to be pretty similar so far. They are both so different if you read them isolated from one another but they share some similar requirements once you read both and start working on them.