Quote:
Originally Posted by Damien
Nice Punky. It's only not 'proper' OO because it's limited in scope (i.e the project is too small) to use many features. OO becomes more central to your application structure in bigger applications anyway. I mean all you can do is make door an object really...(which you did, smart).
You probably know this but when accessing a variable outside of it's containing class you should make it a property..
|
Indeedy. Normally I make all class variables private with the proper accessors (proper encapsulation) but I didn't just because it meant typing lines and lines of code for no real benefits. I would for any "production"-level app.
Here's the Door class with proper encapsulation (I would normally prefix private class variables with _ (like _doorNumber) but that's just convention)
I tend to find because I use OO a lot now that unless something is really small (i.e. an algorithm rather than a game) that I start building it in OO first and then scaling back if it really gets unnecessary.
BTW the point being of all that is that you can control what comes in and out of the class. For example for the prize, I can make sure its one of x pre-determined prizes, that a door number is greater than 0, etc.