我有更多的“你会做什么”问题，而不是实际的编码问题。 它与我目前正在进行的一个项目有关。在这个项目中， 我们的任务是将多个市场 API 合并到一个界面中。每个 API有其独特的产品分类方式。顶层 我们正在查看的所有 API 的父类别或多或少 相同，但有一些变化。但是，子类别非常广泛 不同的。
例如，一个 API 需要很长的面包屑路径 选择一个类别，例如:体育 > 球类运动 > 新英格兰 > 足球 > 现役球队 > 爱国者 > 大事记。而另一个 API 有两级 分类: 体育 > 爱国者纪念品。在许多情况下，还有子类别 与其他 API 的子类别没有任何关系。
所以，问题是 - 设计时采取的最佳方法是什么 界面？我们目前正在考虑两种可能性:
1) 在客户端设计一个自定义类别UI，然后将逻辑构建到 能够对各种 API 的需求进行排序的服务器 基于用户选择的选择。
2) 以用户必须遍历的方式创建 UI 每个单独的 API 的必要步骤。根据用户设置，这意味着 他可能需要填写 API - 具体信息 5、6、10 或更多 次。
虽然我被告知第一个选项是一个真正的编程噩梦( 我给出的示例是更改 API 数据字段)我强烈认为第二个选项会激怒客户。
有什么想法吗？
最佳答案
这是一个非常困难的问题。如果您搜索“本体产品分类”，您会发现许多有关该主题的研究论文和讨论。如果一个只是另一个的更详细版本，那将是非常可行的，但您的描述暗示情况并非如此，因此您需要构建自己的分类方案并将其他分类方案映射到它上面。
您是否有通用 key (UPC 代码？或其他)来验证不同产品类别之间的映射？如果是这样，您也许能够构建自己的分类方案，然后将其他分类方案映射到该方案上，并取得一定程度的成功。
显然，第一个选项对消费者来说是最好的，但构建这样的映射可能非常困难且非常耗时，并且需要不断更新。
一种方法是构建一个比所提供的任何层次结构更简单的层次结构。更简单的层次结构将使将类别映射到层次结构的[主要是手动]工作变得更加容易，因为大多数只是包含项。这可能会使用户体验变得更糟，但如果您围绕产品浏览体验添加出色的搜索功能和出色的“相关产品”/“购买此产品的人也购买了此”工具，您可能可以弥补层次结构的缺乏。
关于oop - 需要帮助规划分类难题的架构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4049176/