库存设计方法（继承与泛型）

Question

问候！ 我正在尝试确定实施以下方案的最佳方法：

车辆和零件都是“entites”，可以是库存中的物品。 车辆有通常的VIN，年份，品牌，型号，类型等等......而Part有PartNumber，QuantityOnHand，IsPartOfSet，供应商...... 当库存中的库存“库存”时，它们都有RetailPrice，PurchasePrice，PurchaseDate，但同时它们还有很多其他不相同的属性 （例如，车辆有CurrentMileage，NewOrUsed等等......而Part有TreshholdCount，LastCountDate等等。） 因此，您可以看到Part和Vehicle都可以在Inventory中，但它们只有很少的共享属性（更多它们不是）...

根据上述情况，我试图在几种方法之间做出决定：

选项1 - 所有内容的单独类（无继承）

• 车辆 - 普通车辆属性（VIN，年份，品牌，型号等）
• VehicleInventoryItem - 具有对Vehicle的引用，并包含其他特定于库存的属性（定价，保修，状态）
• VehicleInventoryManager - 具有业务逻辑的单例添加，删除，通知等等
• 部分
• PartInventoryItem
• PartInventoryManager

我认为这种方法最灵活，但它会因某些属性重复而受到影响。经理也可以有不同的方法......

选项2 - 基类简单继承

• 车辆 - 与选项1相同
• 部分 - 与选项1相同
• InventoryItem - 基类
• VehicleInventoryItem - 扩展InventoryItem，引用Vehicle
• PartInventoryItem - 扩展InventoryItem，引用Part
• InventoryManager - 所有方法都接受InventoryItem作为参数

通过这种方法，我担心InventoryManager受到零件与车辆所需的不同操作的污染

选项3 - 泛型

• 项目 - 其中T将是部分或车辆（我甚至可以更具体，例如 - VehicleItem：Item）
• 库存 - 保留对项目的引用
• InventoryManager - 在T
上运行的单例

在这种方法中，课程较少，但我再次担心InventoryManager

小结

1. 在库存中“库存”时，车辆和零件共享的属性非常少。
2. 车辆和零件的库存管理也将大不相同（当手头的数量很少时，零件被“重新订购”，当车辆出售类似的时候可以购买但是它是独一无二的）
3. 在我的场景中，没有其他对象/模型可以“库存”（在任何类型的库存中）

问题

社区的想法是什么？还有其他方法（可能是接口吗？） 如果2个域对象共享至少1个属性（例如PurchasePrice），那么该证书是否具有某种继承（例如选项2或3）

Answer 1

我将创建一个抽象基类，表示可能存在于库存中的任何项目。像InventoryItem这样的东西。它会提到你提到的基本属性，一切都有共同点：RetailPrice，PurchasePrice，PurchaseDate等。它将为某些属性和方法提供默认实现（如果适用）。

然后，我将继承此课程，并为您计划放养的每个项目专门设置：Vehicle和Part。覆盖您需要的方法，实现标记为abstract的所有方法，并添加特定子类所需的任何其他功能和/或业务逻辑。

这里绝对没有理由使用界面。如你所述，你出售的所有东西都有许多共同的属性。他们有一些额外的，其中一些功能可能不同，但有很多基本相同。没有理由在多个地方复制该功能。使用抽象基类可以提供默认实现。

您根本不需要InventoryManager类：您怀疑它必须知道不同类型的子类是正确的。让派生类完成所有工作。这就是他们的目的。

有关为什么抽象基类通常优于接口的更多信息，请参阅以下答案：

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

我无法想象为什么泛型在这里是相关的。它们是用于解决特定问题的特定工具，而不是一般设计模式。如果您需要泛型，请使用它们。但是，一个利用继承和多态性的精心设计的设计也使得你不太可能在一开始就需要它们。

Answer 2

我会创建一个基类：让我们称之为InventoryItem，其中包含所有共享属性（RetailPrice，PurchasePrice，PurchaseDate等。

然后

Part和Vehicle将从InventoryItem继承并使用他们需要的任何属性进行扩展。

然后我会创建一个名为InventoryManager的基类，VehicleManager和PartManager继承自的基类。 InventoryManager将包含用于管理库存的所有共享逻辑，子类将使用他们需要的任何功能扩展它。

我的印象是你在设计过程中很早。这个早期，我不打算试图为此完美设计。只需构建一些基本的东西，并随着时间的推移进行更改和扩展，因为当您开始构建和使用API​​时，您将更好地理解问题。

“如有疑问，请将其删除。”

Answer 3

通过简要介绍一下您的描述，我建议将与库存相关的方法放在界面中的项目上。如果您需要车辆和零件之间的关系，您可以在零件上始终拥有一个属性来引用它们来自的车辆，或者相反（如果您需要同时进行查找，则可能两者都有）。这似乎将处理库存相关任务的关注分为特定类。 希望有所帮助。

Answer 4

也许我错过了什么，但我不理解你对InventoryManager中“污染”的担忧。如果这是一个问题，它将需要一个单独的类。您描述的每个其他类都共享共同的功能（至少，它们的标识符），因此继承似乎是一天的顺序。

但是，我认为你会想要使用各种技术。您将使用继承，接口（例如用于比较）和泛型（用于列表）。一个不一定排除另一个。