Question

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 will 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)

Answer 1

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.