代码之家 › 专栏 › 技术社区 › Thomas L Holaday

有些陷阱是boojums:boojums列表,还是所有陷阱上都有boojum属性?

data-modeling

Thomas L Holaday · 技术社区 · 17 年前

问题域具有大量的命名陷阱。有些陷阱是繁荣的。

至少有两种建模方法:

// as a property: 
    class Snark { 
      string name; 
      bool is_boojum; 
    };  

// as a list:
    class Snark { 
      typedef long Id;
      Id id;
      string name;
    };  

    tree<Snark::Id> boojums;

很直观的是,如果我们确定圈套是由男性和女性组成的,我们会在圈套阶级的定义中增加一个“性”属性;如果我们确定除了五个圈套以外的所有圈套都是被征服的,我们会列出一个王室成员的名单。

有没有可以应用的原则,或者这是一个建筑偏好的问题?

6 回复 | 直到 17 年前

chaos 17 年前

我相信与分类相关的信息熵可以指导使用哪种方法。低熵分类(即大多数对象具有相同的值)建议使用跟踪异常情况的列表实现,而高熵分类(不能很好地预测对象将具有哪些分类)建议使用属性实现。

Oddthinking 17 年前

你想解决什么问题?

如果记录陷阱的版税的目的是在GUI中在它们的头上显示一个王冠,那么仅仅作为一个属性是有意义的。(或者,也可以有一个Royalsnark子类,使用重写的呈现方法。)

如果目的是快速找到所有皇家陷阱,那么列表更合适——否则您需要查看每个陷阱并检查其属性。

Shog9 17 年前

作为派生类:

class Snark 
{
   virtual void Approach(Creature& approacher) {};
};

class Boojum : public Snark
{
   virtual void Approach(Creature& approacher) 
   { 
      approacher.softlySuddenlyVanishAway(); 
   }
};

frankodwyer 17 年前

这种自然的方式似乎在任何情况下都是一种财产。

您可以使用一个列表来提高性能,或者优化空间。这两个原因都让我觉得可能是过早优化、破坏封装和/或存储冗余数据而导致缺乏完整性的风险(因为我仍然能够查询对象本身以查明它是否是皇家的-我不必知道这由于性能原因,以特殊方式处理属性)。我想您可以将列表实现隐藏在getter后面,使其表现为一个属性。

此外,如果这些对象存储在数据库中,那么性能问题就会消失,因为数据库层可以在运行时使用查询创建列表。

Bill Karwin 17 年前

如果你问的是数据库建模,那么最简单的方法就是 is_boojum 作为表中的属性列 Snarks . 如果需要搜索所有boojum,则查询很简单:

SELECT * FROM Snarks WHERE is_boojum = 1

这给出了逻辑上正确的答案,并且很容易建模。它可能不会这么快,因为索引具有低选择性的列(许多行具有相同的值)的效率不是很高,而且可能根本没有从索引中受益。

但你的问题是建模,而不是优化。

Charlie Martin 17 年前

嗯,我的第一个想法是,实际上,布琼姆是陷阱的一个亚型。但是规范似乎反对它,因为“陷阱是一个boojum,你看。”这意味着陷阱是一个boojum,这将使继承图循环。不能这样。

另一方面,我认为没有任何迹象表明圈套可以成为一个乳房;要么是一个乳房,要么不是。

我想你可能想要个布琼姆混血儿--

abstract class Snark { /*...*/ };
class PlainSnark extends Snark {/*...*/};
class RoyalSnark extends Snark implements Boojum {/*...*/};