Inventory design approach (inheritance vs generics)

Greetings! I am trying to decide on which is the best approach to implement a following scenario:

Vehicle and Part are both "entites" which can be an Item in an Inventory. Vehicle has the usual VIN, Year, Make, Model, Type, etc, etc... while Part has PartNumber, QuantityOnHand, IsPartOfSet, Vendor... When "stocked" in an Inventory as an Item, both have RetailPrice, PurchasePrice, PurchaseDate but at the same time they have a lot of other properties that are not in common (e.g Vehicle has CurrentMileage, NewOrUsed, etc... etc.. while Part has TreshholdCount, LastCountDate, etc, etc..) So as you can see both Part and Vehicle can be in Inventory, but they have very few properties that are share (more that they don't)...

With scenario above, I am trying to decide between several approaches:

Option 1 - Separate classes for everything (no inheritance)

• Vehicle - common vehicle properties (VIN, year, make, model, etc, etc)
• VehicleInventoryItem - has a reference to Vehicle and contains other inventory specific properties (pricing, warranties, status)
• VehicleInventoryManager - singleton with business logic add, remove, notify, etc, etc
• Part
• PartInventoryItem
• PartInventoryManager

I think this approach is most flexible while it suffers for some property repetition. Managers also can have very different methods...

Option 2 - Base class simple inheritance

• Vehicle - same as option 1
• Part - same as option 1
• InventoryItem - base class
• VehicleInventoryItem - extends InventoryItem, references Vehicle
• PartInventoryItem - extends InventoryItem, references Part
• InventoryManager - all methods accept InventoryItem as parameters

With this approach, I am worried about InventoryManager being polluted with different operations needed for parts vs vehicles

Option 3 - Generics

• Item - where T will be part or vehicle (I can even go more specific then, e.g. - VehicleItem : Item)
• Inventory - holds reference to Item
• InventoryManager - singleton that operates on T

In this approach, there is less classes but again I am worried about InventoryManager

Recap

1. Vehicle and Part share very few properties when "stocked" in Inventory.
2. Inventory management for Vehicle and Part will also be mostly different (parts are "reordered" when qty on hand is low, when vehicle is sold similar one may be purchased but it is unique)
3. In my scenario there will be no other objects/models that w开发者_运维百科ill be "stockable" (being in Inventory of any kind)

Questions

What does community think? Is there another approach (perhaps interfaces?) If 2 domain objects share at least 1 property (e.g. PurchasePrice), should that warrant having some sort of inheritance (e.g. option 2 or 3)

I'd create an abstract base class representing any item that is potentially held in inventory. Something like InventoryItem. It would have the basic properties you mention that everything has in common: RetailPrice, PurchasePrice, PurchaseDate, etc. And it would provide a default implementation (where appropriate) for certain properties and methods.

Then, I would inherit from this class and specialize it for each of the items you plan on stocking: Vehicle and Part. Override the methods that you need to, implement all of the methods marked as abstract, and add any additional functionality and/or business logic that is required by the specific subclasses.

There's absolutely no reason to use an interface here. As you mention, all of the things you sell share many common attributes. They have some extra ones and some of the functions might work differently, but there's a lot that is fundamentally the same. There's no reason to duplicate that functionality across multiple places. Using an abstract base class gives you the chance to provide a default implementation.

You don't need an InventoryManager class at all: you're right to be suspect of it having to be aware of the different types of subclasses. Just let the derived classes do all the work. That's what they're for.

For more on why abstract base classes are generally superior to interfaces, see the following answers:

• When should I choose inheritance over an interface when designing C# class libraries?
• Interface / Abstract Class Coding Standard.

And I can't imagine why generics are relevant here. They're a specific tool used to solve a specific problem, not a general design pattern. If you need generics, use them. But a well-conceived design that takes advantage of inheritance and polymorphism also makes it a lot less unlikely that you'll need them in the first place.

I would create a base class: Let's call it InventoryItem containing all the shared properties (RetailPrice, PurchasePrice, PurchaseDate etc.)

Part and Vehicle would then inherit from InventoryItem and extend it with whatever properties they need.

I would then create a base class called InventoryManager which VehicleManager and PartManager inherits from. InventoryManager would contain all the shared logic for managing the inventory and the sub classes would extend it with whatever functionality they need.

I get the impression that you are pretty early in the design process. I wouldn't bother trying to nail the perfect design for this, this early. Just build something basic and change and extend it as you go along, because when you start to build and use the API you will understand the problem better.

"When in doubt, leave it out."

From a brief look at your description I would like to suggest putting the Inventory related methods on the items in an Interface. If you need a relationship between vehicles and parts, you can always have a property on your parts to reference the vehicle they come from, or the other way around (or possibly both, if you need to do lookups both ways). This seems to separate the concern of dealing with inventory related tasks into a specific class. Hope that helps.

Maybe I'm missing something, but I don't understand your concern about "pollution" in the InventoryManager. If that's a concern, it would call for a separate class. Every other class you've described shares common functionality (at the very least, their identifiers), so inheritance would seem to be the order of the day.

I think, however, that you're going to want to use a mix of technologies. You'll use inheritance, with interfaces (for comparison, for example), and generics (for lists). One does not necessarily exclude the other.