posted 13 years ago
Forget about parsing "1 1/2 cups flour" for now. That's just one particular way to get data into your system. A better place to start (though not necessarily the best) would be with what the model is going to look like and what operations it can perform, and, once you have a decent idea of that landscape, write some test code and some hardcoded dummy data, and then write and refine code until the tests pass.
Only then should you think about taking input from the outside world. And when you do, you'll have to decide on what form it will take. If you're reading from a text file, you'll want to define a strict format, so youdon't have to deal with all the ambiguities that humans are so good at processing but which computers suck at.
So, for instance, you might start with a simple Ingredient class, that has fields for name, unit, and amount. You might start off with the unit being a String, but as you learn more about Java, you'll see that an enum is better suited for that. Or you might decide to have the Ingredient class just have the name and unit, if you want your model to assume that sugar always comes in cups and margarine always comes in tablespoons. For the ingredients in a recipe, you could define a RecipeIngredient or IngredientPortion class that combines an Ingredient with an amount. The Recipe class would then have a List (or Set) of RecipeIngredients (or IngredientPortions, or whatever you decide to call it).
The point is, before you write code, you need to think about how you're going model the system you're representing--what kinds of objects there will be, what they can do, and how they relate to each other. And as much as is practical, it's almost always better to get that part fairly stable on hardcoded test dataa before worrying about how to accept input. That way, you can work out those two parts independently of each other, and bring them together when each is working properly.