View Single Post
Old 17-08-2009, 20:35   #77
punky
Inactive
 
Join Date: Jun 2003
Age: 44
Posts: 14,750
punky has a golden aurapunky has a golden aura
punky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aurapunky has a golden aura
Re: Programming Challenges?

Quote:
Originally Posted by Damien View Post
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)

Spoiler: 
Code:
    //class to represent the door
    class Door
    {
        private int doorNumber;
        private Boolean open = false;
        private String prize;

        //constructor, this happens when a door is created
        public Door(int doorNumber, String prize)
        {
            this.doorNumber = doorNumber;
            this.prize = prize;
        }

        //this is called when we Console.WriteLine a door. We have to override the default ToString() method
        public override String ToString()
        {
            String status = open ? "Open" : "Closed";
            return "Door " + doorNumber + ": " + prize + " (" + status + ")";
        }

        public bool Open
        {
            get 
            {
                return open;
            }
            set
            {
                open = value;
            }
        }

        public String Prize
        {
            get
            {
                return prize;
            }
            set
            {
                prize = value;
            }

        }

        public int DoorNumber
        {
            get
            {
                return doorNumber;
            }
            set
            {
                doorNumber = value;
            }
        }
    }


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.
punky is offline   Reply With Quote