Question

作为良好的面向对象方法和设计的练习，我想知道在公司中建立库存控制的好方法是什么。问题描述是

一个。公司可以有不同类型的项目，如文档（电子和物理），计算机等，可能还有自己的子类型。

湾这些物品可以存放在商店中，可以发送给员工，也可以邮寄等。电子文件可以一次通过电子邮件发送给很多人。

℃。物品可能有某些限制，例如分类文件只能传播给有访问权限的人/地方（例如，具有机密清关的人员或清理存放这些文件的房间等）

什么是可以用来模拟这种跟踪的良好类结构？（伪C＃类结构或c ++会有所帮助）以及哪种设计模式对这样的任务有好处

Answer 1

回答您的问题需要对问题域进行深入调查。我不认为有一种普遍有效的方法。

但是，有些模式可能会出现。其中之一（顺便说一下，也是最难实现的一种）是类型/实例模式。根据我的经验，我假设您的库存应用程序必须跟踪的项目类型无法修复，并且您的系统用户必须能够随时创建和修改类型。这意味着您的系统需要处理两个级别的分类而不是通常的级别;换句话说，您的系统将具有类（在代码中），这些类的实例（在运行时）和这些实例的实例（在运行时也是如此）。

例如，如果您在代码中创建DocumentType类，您的用户将多次实例化它，创建诸如Report，Memo或Manual之类的对象。然后，您的系统管理的每个单独的报告都是Report的实例。每个备忘录都是备忘录的一个实例。等等。

如果子类型（我的例子中的Report，Memo，Manual）没有自己的属性或与其他信息的关系，这很容易实现。但是，如果他们需要特定的数据结构（属性和/或关联），那么问题会变得更加困难，因为您需要在系统中模仿完整的面向对象的类型/实例引擎。

但这很有趣！

Answer 2

这是一个让你入门的初步建议：

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等等。还研究“重构”这个主题。

库存控制系统的类结构

2 个答案: