I believe Mr. K5054 has given very valuable advice. After looking over your code, I think you should step back and take a "bigger picture" look at your code. I noticed you have a common pattern in your classes that should be moved into a base class that other classes derive from. This base class will do the following : display a list of the options and their prices; accept input of the choice(s) and quantities; display order summary, cost, and estimate of delivery time. Every single one of your food classes does these same things. The only differences are their text names, prices, and delivery times so each of these should be data parameters. I would make two classes to handle this. One would be a food item that contains a text name (used in prompting) and a cost. The second would be the order. It contains groups of food items, the total cost, and an estimated delivery time for them. This class would be the base class mentioned above.
Taking this approach would shrink the amount of code you have considerably since so much of it is repeated. To get you started, I will show you what a food item class might like like.
class FoodItem
{
public:
const char * name { nullptr };
int cost { 0 };
int count { 0 };
public:
FoodItem() {}
FoodItem( const char * n, int c ) { Set( n, c ); }
void Set( const char * n, int c )
{
name = n;
cost = c;
}
int GetCost() const
{
return count * cost;
}
};
const FoodItem biryanis[3];
biryani[0].Set( "Chicken Biryani", 160 );
biryani[1].Set( "Sindhi Biryani", 220 );
biryani[2].Set( "Beef Biryani", 140 );You can defined groups of food items for each type you have. Then implement the class that does the prompting and acquires the order data. Here is a prototype for the function that gets the order :
int GetOrder( FoodItem items[], int itemcount, int deliveryTime );
int rv = GetOrder( biryanis, 3, 30 );
Note that the food item class contains the number of items ordered. You could make several groups of food items, one for each kind, and this would represent one order. Here is what the data members for an order class might look like:
class FoodOrder
{
public:
FoodItem pizzas[3];
FoodItem burgers[3];
FoodItem sandwiches[3];
FoodItem rolls[3];
FoodItem biryanis[3];
};If this were my project, I would split the name into two parts : a type (biryani) and the variety (chicken). Then I would have a vector for all of those so I could have as many of them as I wanted to. The prompting would first ask for what type and then it would display a list of all options of that type. It would make things much more flexible and open-ended. In fact, you could have a vector of food types and options with no limit on either. If you wanted, you could view this as configuration data that is loaded from a file when the program starts. The program could figure out how many different types there are and operate accordingly.
Submit an article or tip