作为良好 OO 方法和设计的练习，我想知道在公司中建模库存控制的好方法是什么。问题描述是
一个。一家公司可以拥有不同类型的项目，例如文档（电子和物理）、计算机等，这些项目可能还有自己的子类型。
b.这些物品可以保存在商店中，可以分发给员工，可以邮寄出去等。电子文档可以一次通过电子邮件发送给很多人。
c。项目可能有某些限制，例如机密文件只能分发给可以访问的人/地方（例如，有机密许可的人或被允许存储这些文件的房间等）
有什么好的类结构可以用来模拟这种跟踪？ （伪 C# 类结构或 c++ 会有所帮助）以及什么样的设计模式适合这样的任务
【问题讨论】：
标签： c# c++ design-patterns architecture oop
回答您的问题需要对问题域进行深入调查。我认为没有普遍有效的方法。
不过，有些模式可能会出现。其中之一（顺便说一句，也是最难实现的一种）是类型/实例模式。根据我的经验，我假设您的库存应用程序必须跟踪的项目类型无法固定，并且您系统的用户必须能够随时创建和修改类型。这意味着您的系统需要处理两个级别的分类，而不是通常的一个；换句话说，您的系统将有类（在代码中）、这些类的实例（在运行时）和这些实例的实例（也在运行时）。
例如，如果您在代码中创建 DocumentType 类，您的用户将多次实例化它，创建报表、备忘录或手册等对象。然后，您的系统管理的每个单独的报告都将是 Report 的一个实例。每个单独的备忘录都是备忘录的一个实例。以此类推。
如果子类型（在我的示例中为 Report、Memo、Manual）不携带它们自己的属性或它们自己与其他信息的关系，这很容易实现。但是，如果它们需要特定的数据结构（属性和/或关联），那么问题就会变得更加困难，因为您需要在系统中模拟一个完整的面向对象的类型/实例引擎。
不过，这很有趣！
【讨论】：
这里有一个初步建议可以帮助您入门：
struct Item
{
// The requirements say everything is an item.
};
struct Document
: public Item
{
// There are documents
};
struct Document_Physical
: public Document
{
// Physical documents
};
struct Document_Electronic
: public Document
{
// Electronic documents
};
struct Computer
: public Item
{
};
项目的内容及其方法取决于需求文档的解释。这是一种模式，可能还有其他模式。
一些有用的设计模式：Visitor、Factory、Producer-Consumer 等等。还要研究“重构”这个话题。
【讨论】：