Hi,
I am having trouble designing this and looking to your thoughts on this scenario.
A customer can place one or more orders.
I am considering two classes
<code>
class Customer
{
private int CustomerId;
}
class Order
{
private int OrderId;
private int OrderCustomerId;
}
</code>
Now say I want to implement a placeOrder function. Should this function be part of Customer class or Order class. Logically, it makes sense for a Customer to place order since an Order cannot place order on its own. But if you look above, Customer has no knowledge of OrderId, so should the placeOrder function be part of Order class?
Just thinking of another idea, should there be a different class say OrderPlacer
<code>
class OrderPlacer
{
Customer customerId;
List<Order> orderId;
}
</code>
and this class would have a placeOrder function?
I am just trying to learn the concept of Dependency since Order is dependent on Customer and cannot exist on it own. I am confused. Please guide.
I would create a class called OrderManager which has a collection of customers and orders which would provide the complete logic like placeOrder, cancelOrder etc.
The order and customer class could be simple objects classes that mainly store the data.
No offense, but any class that uses the words "Manager" or "Handler" is a sign of code smell; It slowly becomes hard to maintain due to you having one class that manages everything. Rule of thumb: If you cannot find a name that describes the class other than words of that nature, your class is too generic. Generally you should break them up into classes that do their individual jobs, such as OrderPlacer and you should have a separate class called OrderCache and CustomerCache that hold the orders and customers respectively.
"Friend classes" are also a sign of code smell. If you have two classes that have to access one another's private members in a way that cannot go through the public interfaces, they should probably be combined.
The placeOrder function should be implemented in OrderPlacer, because that's what the caller would/should expect. Make placeOrder take all the requirements such as a reference to the OrderCache and a reference to a customer object.
Usually when you order something from a vendor you specify the items ordered first. Identifying the customer is one of the last things that happens. For that reason I'd lean towards placing an order in the Order class.
But don't get too comfortable with that. I bet you'll find that placing an order involves a lot more. It might end up being a method of the Store class etc.
For now, I'd just make a note that you need a placeOrder method somewhere and keep designing the rest of the data. When you get further along it will become clearer where plaecOrder should go.