吸气器和吸气器设计不佳吗？看到矛盾的建议[重复]

#1 楼

还有一种观点认为，在大多数情况下，使用setter仍会通过允许您设置无意义的值来破坏封装。举一个非常明显的例子，如果您在游戏中拥有一个只会不断提高的得分计数器，而不是

>

// Game
private int score;
public void setScore(int score) { this.score = score; }
public int getScore() { return score; }
// Usage
game.setScore(game.getScore() + ENEMY_DESTROYED_SCORE);

这也许是一个简单的例子。我要说的是，讨论吸气剂/吸气剂与公共领域的问题通常会掩盖更大的问题，因为对象以亲密的方式操纵彼此的内部状态，因此彼此之间的联系过于紧密。制作直接执行您想做的事情的方法。一个例子就是如何设置敌人的“存活”状态。您可能会想拥有一个setAlive（boolean alive）方法。相反，您应该具有：

// Game
private int score;
public int getScore() { return score; }
public void addScore(int delta) { score += delta; }
// Usage
game.addScore(ENEMY_DESTROYED_SCORE);

原因是，如果更改实现，则事物将不再具有“有效”布尔值，而是“命中点”值，您可以在不破坏您先前编写的两种方法的约定的情况下进行更改：

private boolean alive = true;
public boolean isAlive() { return alive; }
public void kill() { alive = false; }

#2 楼

非常邪恶：公共领域。
有些邪恶：不需要的Getter和Setters。
优点：仅在真正需要的Getter和Setters上，使类型暴露“较大“恰好使用其状态的行为，而不仅仅是将类型视为要由其他类型操纵的状态存储库。

这实际上取决于情况-有时您确实只想要一个状态哑数据对象。

#3 楼

您已经对此有了很多好的答案，所以我只给我两分钱。吸气剂和吸气剂是非常非常邪恶的。从本质上讲，它们使您假装在大多数情况下都将自己的工作隐藏在冗余代码中，而这些代码对隐藏内部状态没有任何作用。对于简单的POJO，没有理由不能用obj.name =“ Tom”替换getName（）和setName（）。

如果方法调用仅替换赋值，那么通过偏爱方法调用而获得的全部就是代码膨胀。不幸的是，该语言在JavaBeans规范中包含了getter和setter的用法，因此Java程序员被迫使用它们，即使这样做毫无意义。

幸运的是，Eclipse（以及其他IDE）也可以让您自动生成它们。对于一个有趣的项目，我曾经在XSLT中为他们构建了一个代码生成器。但是，如果我要用Java摆脱一件事，那就是过分依赖getter和setter。

#4 楼

获取器和设置器在面向对象的编程中强制执行封装的概念。

对象具有隐藏在外部世界中的状态，因此该对象真正负责其自身，并且不能以任何方式更改这不是故意的。只能通过公开的公共方法（例如getter和setter）来操作对象。

使用getter和setter有一些优点：

1。

使用getter和setter的最大优势之一是，一旦定义了公共方法，就会有一段时间需要底层实现通过将getter和setter作为操作对象的唯一方法，可以进行更改（例如，发现需要修复的错误，使用不同的算法来提高性能等），这将使现有代码不会中断，例如，假设有一个setValue方法可以在对象中设置value私有变量：

public void setValue(int value)
{
    this.value = value;
}

但随后，有一个新的要求，该要求需要跟踪value的更改次数。将设置器放置在适当位置后，更改就变得微不足道了：跟踪更改值的次数。因此，具有getter和setter是“面向未来”的类的一种方法，以便将来进行更改。

2。强制执行操作对象的方法。

getter和setter派上用场的另一种方法是强制执行操作对象的方法，因此，对象处于自己的状态控制之下。暴露对象的公共变量，很容易损坏它。

例如，一个value对象包含一个名为ImmutableArray的int数组。如果数组是一个公共字段，那么它将不会是不变的：

写入后将返回其数组的副本：

public void setValue(int value)
{
    this.value = value;
    count++;
}

即使发生以下情况： /> myArray确实是一成不变的。公开对象的变量将使它能够以非预期的方式进行操作，而仅公开某些方式（获取器和设置器），就可以以预期的方式对对象进行操作。

我想对于将要由其他人使用的API中的类而言，拥有getter和setter方法将更为重要，因为它可以使API保持完整和不变，同时允许对基础实现进行更改。

鉴于getter和setter的所有优点，如果getter仅返回私有变量的值，并且setter仅接受一个值并将其分配给私有变量，则getter和setter似乎是无关紧要的，实际上浪费。如果该类仅供内部使用，而不会被其他人使用，则广泛使用getter和setter可能不如编写公共API那样重要。

#5 楼

它们绝对是邪恶的。

@coobird不幸的是，它们绝对不会“强制执行封装的概念”，它们所做的只是使您认为您实际上是在封装数据，而实际上您是通过带有方法宏大幻想的财产。 getter / setter在公共领域所做的任何事情都会更好。努力使客户改变其价值，例如通过

object.field = value;

而不是在认知上更加紧张

object.setField(value);

客户现在必须检查getter / setter方法是否有副作用。

其次，如果您真的需要在该方法中做其他事情，为什么要承担更多的责任而不是简单地获取或设置方法呢？
要么遵循SRP，要么调用该方法实际上可以告诉您整个方法的功能，例如Zarkonnen提到的示例。 />

public void kill(){
    isAlive = false;
    removeFromWorld(this);
}

而不是

public void setAlive(boolean isAlive){
    this.isAlive = isAlive;
    if (isAlive)
        addToWorld(this);
    else
        removeFromWorld(this);
}

setAlive（boolean）方法在哪里告诉客户端，效果会从中删除对象 世界？客户为什么要对isAlive字段有任何了解？再加上将对象重新添加到世界时会发生什么情况，是否应该重新初始化？客户为什么要关心其中的任何一个？

恕我直言，道德上要说出方法的确切名称，遵循SRP并摆脱吸气剂/吸水剂。
如果存在问题没有getters / setter的人，告诉对象在自己的类中做自己的肮脏的工作，而不是尝试在其他类中与他们做事情。 >

#6 楼

简单的Transfer对象（或Parameter对象）的唯一目的可能是保留某些字段并按需提供其值。但是，即使在这种退化的情况下，也可能会争辩说该对象应该是不可变的-在构造函数中配置并仅公开get ...方法。控制旋钮”；您的车载收音机的UI可以理解为暴露getVolume，setVolume，getChannel和setChannel之类的东西，但是其真正的功能是接收信号并发出声音。但是这些旋钮并没有太多实现细节。您从这些接口功能中不知道无线电是晶体管，主要是软件还是真空管。 ，您会要求它做更多的事情，而不是要求它告诉您其内部状态或询问它的数据，以便其他代码可以使用这些值做某事。 >那么……“邪恶”？并不是的。但是每次您倾向于输入一个值并针对该值公开get ...和set ...方法时，都要问自己为什么以及该对象的真正责任是什么。如果您能给自己的唯一答案是“为我保持这一价值”，那么也许除了OO之外，还有其他事情正在发生。

#7 楼

如果Game类公开了许多变量，则它可能遵循God对象反模式。 getter和setter没什么错（尽管它们在Java中的冗长有些令人讨厌）；在设计良好的应用程序中，每个类都具有明确分开的功能，您将不需要在单个类中包含许多功能。游戏类（我理解您的评论是这样的），那么您可能不需要getter（对于一个类而言，无需使用get方法即可访问其自己的私有变量就很好了），并且您可能会折叠许多setter放入“组设置器”中，该设置器设置了几个在概念上属于在一起的变量。

#8 楼

getter和setter方法的存在往往表明（如果您使用的是这种小学语言，则是“气味”），这是一个设计问题。琐碎的获取器和设置器与公共领域几乎没有区别。通常，对数据进行操作的代码将位于不同的类中–封装不完善，并且您希望程序员对OO感到不满意。但是通常，同时具有getter和setter的类型会指示设计问题。吸气剂的工作是不可变性的。设置员为“告诉不问”工作。不变性和“不要问”都是不错的设计选择，只要它们不能以重叠的方式应用即可。

#9 楼

我的观点是，getter和setter是好的程序的要求。坚持下去，但不要写不必要的getter / setter-不一定总是直接处理所有变量。

#10 楼

我真的不认为他们是邪恶的。但是我很想生活在一个除非真正需要就不必使用它们的世界。例如：

public void setValue(int value)
{
    this.value = value;
}

然后，需求发生变化，您需要跟踪设置值的次数。 />

public void setValue(int value)
{
    this.value = value;
    count++;
}

这很漂亮。我知道了。但是，在Ruby中，以下内容不能达到相同的目的吗？那么，您不能只覆盖设置器THEN而是仅覆盖THEN吗？我们拥有Java类，看到成千上万的代码行虽然没什么，但是基本的getter / setters却很丑陋和令人讨厌。时间，并且仅在需要时才进行自定义获取/设置程序。像魅力一样工作，它丝毫无损。

#11 楼

一如既往，唯一的答案是：取决于情况。如果您是唯一接触代码的人，那么您可以做任何自己喜欢的事情，包括使用快捷方式。

使用setter的好处之一是只需要在一个位置执行检查在您的代码中。

您可能想更加注意这些方法实际获取和设置的内容。如果使用它们提供对常量值的访问，则最好使用常量。

#12 楼

这取决于所讨论的编程语言。您的问题是在Java上下文中提出的，在该上下文中，通常将getter和setter视为一件好事。

相反，在Python世界中，它们通常被认为是不良样式：它们在代码中添加行而没有实际添加功能。当Python程序员需要时，他们可以使用元编程来捕获和/或设置对象属性。

在Java（至少是我十年前学到的Java版本）中，这是不可能的。因此，在Java中，通常最好认真使用getter和setter，以便在需要时可以覆盖对变量的访问。

（这并不一定会使Python优于Java，只是不同。）

#13 楼

仅供参考：除了该主题中的所有出色答案之外，请记住，出于各种原因，您可以提出支持或反对吸气剂/设置员的方法，性能并不是其中之一（有些人可能会相信）。 JVM足够聪明，可以内联琐碎的getter / setter（即使不是final，只要它们没有被实际覆盖）。

#14 楼

您可能需要用值类替换某些类。这将允许您删除吸气剂，并避免在内容从下面更改时发生问题。

#15 楼

如果需要外部访问各个字段的值，请使用getter和/或setter。如果没有，那就不要。切勿使用公共领域。就这么简单！ （好吧，这从来没有那么简单，但是这是一个很好的经验法则。）

通常，您还应该发现提供给setter的频率比获得getter的频率要低得多-特别是在尝试时使您的对象不可变-这是一件好事（但并非总是最好的选择）-即使不是。

#16 楼

我几个月前一直在用Java进行编程，并且我了解到，只有在应用程序需要它时，才应该使用getter和setters。