【问题标题】:Accessors vs. public members访问者与公共成员
【发布时间】:2010-10-14 19:58:14
【问题描述】:

我有一个类,其中包含许多具有读/写访问权限的内置类型成员。我应该将它们设为公共成员并为每个成员提供 get/set 方法吗?结构呢?

【问题讨论】:

    标签: c++ class member


    【解决方案1】:

    拥有访问器(getter)和修饰符(setter)的全部原因是为自己提供额外的间接级别。

    这种额外的间接级别允许您向公共接口提供变量的只读视图,同时不允许更改数据成员。您仍然可以使用私有或受保护的设置器。

    设置器允许您在设置值时进行特殊的错误检查、验证和更正。例如 setDirectory(const std::string &strPath),如果用户没有指定,你可以确保有一个终止斜杠。这可确保您的类状态始终有效。

    Getter 还可以保护您的成员免于暴露它们以允许指向它们的指针。通过不允许从外部指向它们的指针,您可以确保如果您的对象超出范围不会导致崩溃。

    getter/setter 的额外间接级别还允许您更改它们封装的数据成员。

    使用 getter,您还可以获得数据的不同视图,例如:getMinutes,当您的数据成员实际存储在几秒钟内时。

    这不是使用它们的原因,但是使用 getter 和 setter 的一个很好的副作用是你可以在你的修饰符中设置一个断点,例如准确地查看它何时被更改。

    您是否应该使用它们是基于您的需要的判断电话。如果您有这么多成员,以至于提供 getter 和设置是一个巨大的痛苦,您可以考虑将数据成员存储在一个结构中,并在您的类中使用该结构。您甚至可以一次为整个结构的对象提供 getter/setter。

    【讨论】:

      【解决方案2】:

      如果有invariants你需要保存,那么可以。否则,请不要打扰。

      【讨论】:

      • 致反对者:我听取了 Stroustrup 本人的建议:artima.com/intv/goldilocks3.html "Bjarne Stroustrup:我的经验法则是,当且仅当当且仅当您应该有一个具有接口和隐藏表示的真实类你可以考虑类的不变量。”
      • 确实如此。稍后在同一文本中:“是的。如果每个数据都可以有任何值,那么拥有一个类就没有多大意义。以一个具有名称和地址的单一数据结构为例。任何字符串都是一个好名称,并且任何字符串都是一个好地址。如果是这样,它就是一个结构。
      • 继续:“不要有任何私有的东西。不要做任何愚蠢的事情,比如使用 get_name 和 set_address 以及 get_name 和 set_name 函数隐藏名称和地址字段。或者更糟糕的是,制作一个虚拟基地具有虚拟 get_name 和 set_name 函数等的类。"
      • 我认为反对者(我不是其中之一)可能会考虑除了不变性之外还有其他问题,例如虚拟行为、便利性、自我记录等。
      • 虽然我同意,如果他们解释他们的反对票,这将是礼貌和有用的。
      【解决方案3】:

      您应该只使用公共数据成员

      • 在结构中,您不会向客户端代码公开(例如,绑定样式函子) - 保护外部任何人都无法获得的结构是没有用的
      • 如果它们的类型封装了设置/获取它们的逻辑(例如,如果您创建一个 ObservableAttribute 类)
      • 如果它们是不可变结构中的 const 成员(如果它们是不可变的,则除了读取它们之外,您无能为力)

      如果您创建一个公共数据成员,您必须确保它的值与该类的其他成员完全正交。例如,您禁用了未来的可能性

      • 观察成员的变化
      • 让成员在类的不变量中扮演任何角色
      • 禁止访问该成员
      • 根据性能需要更改成员的实现(例如,计算、缓存和存储)

      【讨论】:

        【解决方案4】:

        对私有/受保护的数据成员使用 get/set 方法是一种糟糕的设计。

        它会导致客户端代码依赖于你的类的实现细节。

        类中的更改会导致客户端代码的更改。

        但是可以使用公共成员的 get/set 方法。但避免它们总是好的。

        【讨论】:

        • 我赞成它,所以它至少有 4 个反对票 :) 说真的,我认为 getter/setter 是一个糟糕的设计是一个常识。吓人。
        • 好吧,问题是是否可以使用 getter/setter?大多数时候这是一个糟糕的设计,而我的回答正是如此。从上面的大多数答案中得出相同的结论。我不确定这是所有人的常识。
        【解决方案5】:

        首先,如果您的班级有很多数据成员,则可能设计得不好。您可能需要考虑将其拆分为多个类或将数据存储在地图等结构中。

        关于提供访问器,问题是您是否想要修改访问权限,可能会阻止它。如果答案是肯定的,那么您需要访问功能。另一方面,如果你的类真的只是一堆比特,没有任何行为,那就把它变成一个结构。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2019-05-01
          • 1970-01-01
          • 2010-12-29
          • 2015-07-11
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2017-11-23
          相关资源
          最近更新 更多