【问题标题】:Where should I put contextual data related to an Object that is not really a property of the object?我应该将与对象相关的上下文数据放在哪里,而这并不是对象的真正属性?
【发布时间】:2010-04-27 19:19:51
【问题描述】:

我有一个汽车课。它具有三个属性:id、color 和 model。

在特定查询中,我想返回所有汽车及其属性,并且我还想返回一个名为“searcherKnowsOwner”的真/假字段,这是我在数据库查询中根据个人是否进行搜索了解所有者。我有一个数据库函数,它获取搜索者的 ID 和汽车的 ID,并返回一个布尔值。

我的汽车类看起来像这样(伪代码):

class Car{
  int id;
  Color color;
  Model model;
}

我有一个屏幕想要显示所有汽车,但如果查看该页面的人知道那辆车的车主,我还想在每辆车旁边显示一个标志。

我是否应该在 Car 类中添加一个字段 boolean searcherKnowsOwner?它不是汽车的财产,而实际上是进行搜索的用户的财产。但这似乎是放置这些信息最有效的地方。

【问题讨论】:

    标签: oop


    【解决方案1】:

    让 Car 和 Owner 对象保持不变。定义 2 个类 SearchCriteria 和 SearchResults

    SerachCriteria 将保存最终用户提供的搜索条件,您的应用程序逻辑将返回一个 SearchResults 类型的对象,该对象是 Cars 的集合。

    如果车主已知,您可以在 SearchResult 中维护与结果中每个汽车对象相对应的标志。

    【讨论】:

    • 我喜欢这两个答案...我想添加一个 SearchResults 类是维护 Car 完整性的一种纯粹方式。可能有点矫枉过正,但它让我晚上睡得更好。
    【解决方案2】:

    我会这样建模:

    class Car{
      int id;
      Color color;
      Model model;
      Owner owner;
    }
    
    class Owner {
      Boolean knowsSearcher;
    }
    

    现在Car 类型有一个Owner(与现实生活有点倒退,是的),Owner 类型有一个字段表明他们是否认识搜索者。

    【讨论】:

    • 我不同意这里。如果搜索者认识他,所有者对象不应该担心。
    • 我也不同意。 “KnowsSearcher”仅在搜索上下文中才有意义。它不应该是模型的一部分。最多您可以拥有一个可以在搜索上下文中调用的方法,例如 Owner.KnowsPerson(Person person),但是拥有一个在没有搜索者上下文的情况下具有值的属性是没有意义的。这。 __curious_geek 有正确的答案。无论如何,为搜索结果创建单独的类总是更好,这样您就可以将聚合数据返回到一个平面类中,而无需执行多个查询来加载所有对象的关联。
    猜你喜欢
    • 2021-11-03
    • 1970-01-01
    • 1970-01-01
    • 2012-09-05
    • 1970-01-01
    • 2013-12-09
    • 1970-01-01
    • 2015-07-17
    • 2013-07-12
    相关资源
    最近更新 更多