0

例如，让我们考虑一下我有以下课程：

  • Item

  • ItemProperty这将包括诸如Colour和之类的对象Size。类的关系属性Item列出了ItemProperty适用于该项目的所有对象（即，对于一个项目，您可能需要指定颜色，而对于另一个项目，您可能需要指定大小）。

  • ItemPropertyOption将包括Red, Green(for Colour) 和Big, Small(for Size) 等对象。

然后ItemObject 将与 an 相关ItemProperty，而ItemChoiceObject 将与 an 相关ItemPropertyOption（并且可以推断出所指的）ItemProperty。ItemPropertyOption

这样做的原因是我可以更有效地使用查询。即给我所有的项目选择是Red。它还允许我使用 Parse Dashboard 快速将元素添加到站点，因为我可以轻松地指定更多ItemPropertys 和ItemPropertyOptions，而不必将它们添加到代码库中。

这只是一个小例子，还有更多我想使用类的实例，以便表单中各种下拉列表的“选项”在数据库中，并且可以由我轻松添加和编辑，而不是硬编码.

1）我可能会以类似的方式对 5 种以上类似的类结构进行此操作

2）可能有数百个我想通过“反向查询”访问的嵌套属性</p>

因此，我可以想到 2 个导致效率低下的潜在原因，并想知道它们是否成立：

  • 有很多课程效率低下吗？

  • 对嵌套类的反向查询效率低下吗？

我能想到的另一个选择——如果“类膨胀”确实是一个问题——是在父类上创建字段，而不是嵌套在其他类中（代表进一步的属性，如上所述），只是将它们表示为直接嵌套 JSON 属性。

4

2 回答 2

0

有很多课程效率低下吗？

对于必须记住所有这些类做什么以及它们如何相互关联的穷人来说，这肯定是低效的。首先编写所有这些类需要时间，并且您编写的每一行都是必须维护的行。

除此之外，任何 OOP 语言中的每个类肯定都会产生一些成本，并且创建比您真正需要的更多的类意味着您为正在做的工作支付的费用比您需要的多，这几乎就是定义的低效。

对于 5 种以上类似的类结构，我可能会以类似的方式执行此操作

也许您可以花一些时间考虑这些情况之间的相似性，并提出一组更灵活的类，您可以在所有这些情况下使用它们。编写通用代码比编写非常具体的代码更难，但如果你做得好，你将通过重用多次收回额外的努力。

于 2018-09-21T20:34:06.227 回答
0

设计的工作是在对象描述中呈现与系统要求相关的关于世界的真相。在 OP 的“物品”世界中，物品有颜色是事实，这是一个相关的事实，因为用户关心物品的颜色。如果系统消耗了不需要消耗的计算资源，您只会称系统效率低下。

所以，对于像配置器这样的东西，我们有项目，这些项目有属性，这些属性有一组可枚举的可能值，这听起来像是一个完全合理的设计。

是低效还是“臃肿”？我要提出疑问的唯一地方是明确断言项目具有属性。当然可以，但 javascript 对象和解析实体本身就是如此。

换句话说，您可能能够只使用 item 和几种类型的 propertyOptions：例如，Item 有一个名为“colorProperty”的属性，它是一个指向“ColorProperty”实例的指针（其实例有一个 name 属性，如 'red '、'green' 等，并可能描述其他相关事实，如 RGB 形式的更精确描述）。

如果它们代表相关的事实，那么许多类没有错。先这样做。您可能会凭经验发现您的设计过于消耗资源（我怀疑在这种情况下您会不会），此时我们会开始寻找更精简的作弊。但先以正确的方式做，只有在必要时才作弊。

于 2018-09-24T17:57:04.730 回答