Is my OOP design correct?

I have a scenario where I am designing a system for a retailer. This is not a proper live application but just a scenario to check whether my OO design skills are correct and whether I am thinking correctly. I am still learning here. I am doing this in c#.

The scenario is this:

A retailer selling stationary products wants to design a system that will select the best price from his various fixed number of suppliers and make an order from that supplier. For sake of simplicity, I cut the stationary products down to just one product from the same company, which is an XYZ pen. Each of the suppliers will provide a quote for the XYZ pen when asked and the retailer system selects the best price from the various sellers and places an order from that seller.

Approach 1:

1. Create an abstract class for supplier and an implementation for each supplier.
2. Each supplier implementation to have a PlaceOrder() method and a cost property.
3. DataLayer sets the cost property for each supplier implementation.
4. Create a CheckBestRetailer class that evaluates each implementation for the best price and places an order on the appropriate implementation.

Approach 2:

1. Create a list of type supplier with Cost property and a PlaceOrder() method.
2. For each supplier the data layer adds new supplier type to list and sets the cost details it got from the database.
3. CheckBestRetailer class loops thru that list and evaluates each object for the best price and places an order on the appropriate implementation.

Of the two above, I feel approach 1 is closer to OOP but provided I have a fixed number of suppliers. If the number of suppliers can change depending on data retrieved from database then Approach 2 is more better.

What do you think?

I may not have the best scenario here开发者_高级运维 for testing my OOAD. Would love to have some sample scenarios that I can work with too... if possible with design hints.

Thanks for your time.

Option 1 will be more appropriate if you have different behaviour for each supplier, in this case it seems that going with option 2 is a better choice as its simpler.

What I usually do when I don't know how to solve something is:

• List my requirements: Get best price for an item given a supplier set.
• Create a list of candidate objects: Supplier, Item, Retailers etc.
• Draw or layout classes with relationships that I think I make sense
• When I'm lost I start coding the main classes for the requirement, in this case it would be the Retailers and the GetBestRetailer() method.

for any of the above it doesn't matter if you are wrong or not, is kind of a brainstorming to understand better what you have to achieve and what options you find to do it.

Every time you encounter something that seems to be difficult, I abstract it by either creating a method that returns you the answer you need or by creating a new class if that seems to make better sense. As an exercise I try to think that the 'difficult/complex' parts will be coded by someone else and by delegating to a method or class I separate that from the part of the problem I'm focusing right now.

hth

I'd say Approach 2 is better. There's no need to create a unique class for each supplier, because the behaviour of the suppliers are almost the same.