I am new to Programming, Java is my first language that I would like to learn. Currently I am trying to learn Java with the help of Head First Java, I got some problems with the Extra - Strength Methods chapter.. I am confused on how to separate all my classes and let them interact in my main(), so I come up with exercises and one of the ideas that I am currently working on is the Vending Machine Program, currently I have 3 classes, first is
and the second one is,
and to test my methods I come up with the TestDrive Class(but i guess this should be a real class, I am really confuse with this one).
Now the problem is I want to know what of these codes is unnecessary and the problem with the setOrder() method if I input a greater number than 3 it will go to the next method that will ask for the quantity my desired output should be if the user inputted a number that is greater than 3 it will just print "Invalid Selection" on the screen. I hope someone could be of help. thanks
A common way of splitting code for user interface scenarios is to use the Model-View-Controller (MVC) design pattern. There are lots of on-line tutorials on using it so I won't go into detail here but basically you need to divide the code into the data (Model), the display (View) and the logic that mediates between the Model and View (Controller).
Your test class isn't really a test class as just starts the application and keeps it running for an amount of time. But the logic in this class is very strange, I suggest you sit down with a pen a paper and write out the sequence of events that are required and only then try to run it into code.
For reading input from the command line look at using java.util.Scanner, you may find it easier as it has methods to read ints etc
Joined: Oct 17, 2012
I really do have time to sit down and write it in a paper the first part of that code was written and what I wrote was actually good(for me I think lol), the problem is when I came up with an update I immediately put it to codes. Regarding MVC, I will try to learn this, actually its the first time that I posted my codes, the first time after 1 month of studying java that I got a suggestion, and to talk my codes to someone rather than the comparing my codes in the examples written in the book. Thank you very much
Jhoel Esmejarda wrote:I hope someone could be of help. thanks
Well, my advice is going to be general, rather than specific to your problem:
1. Don't use constants like 3, because they make your code very brittle. What if you decide to have 4 items later on? Or ten? You'll have to go through your entire program and replace every piece of code that has 3 in it. There is a much better way to do tests like that, and it's based on the fact that all arrays have a length. And if, later on, you decide to use collections (eg, a List), you can use the size() method. In fact, it might not be a bad thing to write a little method called numberOfItems().
2. Your classes have names that sound like functions. In general, classes are things (not always, but certainly in your case), so they should usually have names that are nouns not verbs. And to get a good class, you need to understand what it's modelling.
Take your program: You're trying to model a vending machine, yet you don't have a class called VendingMachine. You have items of food, yet you don't have a class called FoodItem. Vending machines usually have slots that contain the items to be sold, but I don't see a class called Slot. A vending machine also has to interact with a person in order to do anything at all, yet there's no User or Customer class.
I have a feeling you're worrying too much about how you're going to do things, rather than concentrating on what needs to be done.
It's a common mistake for beginners because you're just dying to bash out some code; but it's almost always the wrong thing to do.
STOP CODING and get out a pencil and paper, and write down what it is that a vending machine does. What's the sequence of events needed for a user to get an item of food? Exactly. Does it coincide with the classes that you've written?
I hope it helps.
Joined: Aug 07, 2007
The temptation when given a problem, especially as a beginner, is just to try to write the code. At the moment you are probably of the view that writing the code is hardest part of solving the problem but in time you will come to realise that writing the code is the easy bit, it's analysing the problem and designing a solution that's the tricky bit.
If you don't do a proper job of the analysis and design the upside is you will get lots of practice at writing lots of code, the downside is unfortunately most of it will be wrong and you'll spend more time rewriting it than you would have spent doing a proper analysis and design.
Edit: Oops hadn't noticed Winston had already said this.
Joined: Oct 17, 2012
Wow thanks a lot with the great comments.. I will surely take note of the things that you notice on how I do things. Now I know what I'm lacking. thanks again if there is anything that you can add kindly inform me.