well id first learn some file io like 'open' and 'close' so you can make a file with names and prices. then the application would read the information and ask for money
Think about what makes up your object, and what your object can do. For instance, a vending machine has sodas/snacks. It can dispense them based on input (buttons pressed, money given), and stock (maybe no more items left.) It can also turn on and off. Remember that you don't need to implement everything, you just create what you need as you need it. What part of the machine do you want to create/prototype? Do you want a physical object with attributes such as size, mass, …, or do you want to create the idea of a vending machine, a devise to supply/dispense a particular type of items? These are some of the things you need to contemplate.
Personally, I'd start by drawing pictures. Consider the popularity (and relevance) of UML use case diagrams. At first, identify your main abstraction and the actors that are involved. Then go into more detail by defining the interfaces between them.
So do I need to consider the entire vending machine as a huge class and then add items, slots, buttons as sub objects?
Mathhead200 wrote:
... you don't need to implement everything, you just create what you need as you need it.
What I meant was, when designing a class based on physical object, the idea behind the implementation has to be unambiguous. Do you want to make the whole “kit and caboodle” or do you just want a machine that dispenses items. If your not sure then think about what type of program you are going to use this class in. Most would not need to know things like size, color, electrical power, … but some might.