2010-12-03 27 views
8

考虑下面的类:即使在访问本地状态时,是否始终使用访问方法是最佳实践?

public class Person 
{ 
private Integer age; 

// Standard Accessors 
public Integer getAge() { 
    return age; 
} 

public void setAge(Integer age) { 
    this.age = age; 
} 

public String getAgeAsTextString() 
{ 
    if (this.age == 20) 
    { 
     return "Twenty"; 
    } 
    return "Unknown"; 
} 
} 

我只是有1个整数,和2个存取。如果我想创建一个以String形式返回对象状态的实用程序方法,最佳做法是将类变量称为this.age,还是应该使用getAge()

是否存在最佳实践还是归结为开发人员的压抑?

回答

7

取决于。对于访问器什么都不做的小型快速类,我会直接使用这个字段。对于访问器和setter可能有副作用的较大类,我会说使用访问器。

在Android平台上,Android文档似乎认同。在某些情况下,他们甚至会推荐包级保护。请参阅http://developer.android.com/guide/practices/design/performance.html中的标题为“避免内部吸气剂/吸入器”和“使用内部类的包装范围”部分。

这一切都取决于环境,代码的大小,以及是否因代码维护原因而达成一致的“标准”。只要知道有一些微小的性能差异,但最终取决于开发人员/团队。

3

这是一个很好的做法,因为您永远无法确定您可能希望在以后的年龄改变年龄。它可能需要进行某种验证或其他操作,并且在一种方法中更改它比使用该字段的任何地方更容易(并且更容易错过一个使用它的地方,因此难以追踪潜在的错误)。

+1

通常,您对setter进行验证而不是获取方法,也没有确定将所有引用更改为最简单的方法;使该字段保持私有状态(因此您没有其他类中的依赖关系),进行会破坏代码的更改(并让编译更改用法),或让IDE查找所有用法。 – 2010-12-03 15:47:46

+0

更正,编译器找到用法。 – 2010-12-03 16:00:52

7

我想说它由开发人员决定。

我稍微偏好使用getter方法。如果你有一个类层次结构,通过受保护的getter来暴露内部状态是很好的。

1

通常人们会在简单的课程中使用this.age,但考虑使用访问器的好处,当您已经拥有它们时。如果你想介绍某一天,比如记录某人到了什么年龄,那么你必须把它放在每一个你称之为这个地方的地方。或者,您可以将其放入访问器中。代码风格并不总是固定的,但如果你寻找它,通常有一个很好的理由。

0

恕我直言:我遵循你不再需要它保持简单的原则。许多开发人员担心有一天,可能你需要一个getter或setter,但实际上这种情况从来没有发生过。

你应该做你认为最清楚的事情,尤其是那些必须维护你的代码的人。

我会建议这是一个很好的做法来使用int,除非你需要该值为null或一个对象。如果您需要将该值设为无效,则应该进行测试。

即要么

int age = 10; 
if (this.age == 20) // cannot be null. 

OR

Integer age = 10; 
if (this.age != null && this.age == 20) // age can be null 

Integer age; 
if (this.age == 20) // throws an NPE. 
+2

-1无关紧要,无题。问题不在于int与Integer有关。此外,国际海事组织在你的示例代码中缺少括号。 – 2010-12-03 15:36:38

+0

@Erick,恕我直言,他有他的代码中的错误。他在询问最佳做法,但他也应该首先关注正确性。你会在哪里放置括号? – 2010-12-03 15:41:04

3

如果类将是决赛,我会直接访问域。信任你的重构能力。如果你想稍后改变它,你总是可以做到的。

2

我喜欢用getter和setter方法甚至一个简单的类,因为它会在你的代码“挂钩”,因此很容易扩展。因此,如果您希望每次用户更改某个对象属性时都创建一个审核条目 - 这很容易实现。然后,当我到达我的项目结束时,我会花点时间删除我没有使用的getter和setter。我觉得这是有效的,因为大多数的IDE将为您生成的访问器,所以没有浪费太多的时间......

我看到有人发帖,“如果你想要在以后改变它,你总是可以做到这一点。”。在大型项目中这并不总是微不足道的,当你直接在你的代码中访问你的对象属性。

2

为了上帝的爱,不要乱你的代码了自相矛盾的“自我封装”。这个班是你的模块。让你的课变得简单。

另外,根据行为而不是数据设计你的类的接口。沟渠那些得到和设置方法。

1

有一点要记住。当使用类似Hibernate的东西时,使用访问器一般是需要!几次被这个人咬了。 Hibernate使用字节码生成来进行延迟初始化。如果直接访问成员变量,则将跳过延迟加载并获取空值。所以,我个人的最佳做法是使用访问器。像所有最佳实践一样,当然有时候可以忽略它,但是你去了。

0

虽然存取到的代码行添加到您的课程中,他们重构代码时真正增加价值。你需要通知另一个班级一个属性已经改变了吗? BAM!有一个事件并在访问器代码中触发它。

只要让成员变量可以访问,您需要在创建事件时创建访问器,或者记住在每次当类之外的对象更改成员变量时通过附加逻辑来通知对象。

我认为访问器对复杂度比例的灵活性非常好。另外,一些框架,比如hibernate需要它们。另外,像.net这样的语言具有代码结构,比如不能应用于成员变量的属性(又名WCF DataMember)。

希望有帮助!

1

几个原因访问器“可以”是一个更好的选择:

  1. 您使用的是模拟框架来测试你的代码,并希望能够BOTH改变从一个getter返回的值,并断言它被称为。
  2. 您希望公开大多数(如果不是全部)公共类作为接口(例如,您希望能够创建动态代理等)。这可能包括在界面展示存取(呼叫者不需要知道它只是获取本地属性)
  3. 你正在开发用于公共消费的图书馆和一个“简单的重构”是不恰当的,因为它可能(会)在最终用户的应用程序中导致编译时错误。访问者可以被适当的弃用,而不会影响早期库的用户的行为。
  4. 您希望保留稍后更改访问者行为的权利,或者在派生类中未完全移除访问者的行为(请参阅上一点)。
  5. 许多依赖注入框架将期望一个“bean”符合JavaBean规范,因此具有所有属性的访问器。
相关问题