很多人都在谈论二传手和二传手的优点，但我想扮演魔鬼代言人的角色。现在我正在调试一个非常大的程序，程序员们决定让所有的东西都变得更好和更好。这看起来不错，但这是一场逆向工程噩梦。

假设你正在查看数百行代码，你会发现：

person.name = "Joe";

这是一段非常简单的代码，直到你意识到它是一个setter。现在，您遵循该setter，发现它还设置了person.firstName、person.lastName、person.isHuman、person.hasReallyCommonFirstName，并调用person.update（），后者将查询发送到数据库等。哦，这就是发生内存泄漏的地方。

乍一看就理解一段本地代码是具有良好可读性的一个重要特性，getter和setter往往会打破这一特性。这就是为什么我尽量避免使用它们，并在使用它们时尽量减少它们所做的事情。

考虑使用访问器是有充分理由的，因为没有属性继承。请参见下一个示例：

public class TestPropertyOverride {
    public static class A {
        public int i = 0;

        public void add() {
            i++;
        }

        public int getI() {
            return i;
        }
    }

    public static class B extends A {
        public int i = 2;

        @Override
        public void add() {
            i = i + 2;
        }

        @Override
        public int getI() {
            return i;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.i);
        a.add();
        System.out.println(a.i);
        System.out.println(a.getI());
    }
}

输出：

0
0
4

除非您当前的交付需要，否则不要使用getters setter。例如，如果要更改任何内容，请不要过多考虑将来会发生什么，这是大多数生产应用程序和系统中的更改请求。

思考简单、简单，必要时增加复杂性。

我不会仅仅因为我认为这是正确的或者我喜欢这种方法，就利用对拥有深厚技术知识的企业主的无知。

我编写了一个没有getters setter的大型系统，只使用了访问修饰符和一些验证n perform-biz逻辑的方法。如果您确实需要。使用任何东西。

来自数据隐藏的获取者和设置者。数据隐藏意味着我们正在向外部人员或外部人员/事物隐藏无法访问的数据这是OOP中一个有用的特性。

例如：

如果您创建了一个公共变量，您可以访问该变量并在任何地方（任何类）更改值。但如果创建为私有，则该变量无法在除声明的类之外的任何类中查看/访问。

public和private是访问修饰符。

那么我们如何在外部访问该变量：

这是获得者和获得者的地方。您可以将变量声明为private，然后可以为该变量实现getter和setter。

示例（Java）：

private String name;

public String getName(){
   return this.name;
}

public void setName(String name){
   this.name= name;
}

优势：

当任何人想要访问或更改/设置平衡变量的值时，他/她必须获得许可。

//assume we have person1 object
//to give permission to check balance
person1.getName()

//to give permission to set balance
person1.setName()

您也可以在构造函数中设置值，但稍后需要时要更新/更改值，必须实现setter方法。

公共字段并不比getter/setter对差，它除了返回字段并赋值之外什么都不做。任何差异都必须存在于其他因素，如可维护性或可读性。

getter/setter对的一个经常提到的优点不是。有一种说法是，您可以更改实现，而不必重新编译客户端。据推测，setter允许您稍后添加验证之类的功能，而您的客户甚至不需要知道它。然而，将验证添加到setter是对其前提条件的更改，违反了以前的合同，这很简单，“您可以将任何东西放在这里，稍后您可以从getter那里获得相同的东西”。

因此，现在您违反了合同，更改代码库中的每个文件是您应该做的事情，而不是避免。如果你避免这样做，你就假设所有的代码都假设这些方法的契约是不同的。

如果这不应该是约定，那么接口允许客户端将对象置于无效状态。这与封装正好相反。如果该字段从一开始就不能真正设置为任何值，为什么验证从一开始不存在？

同样的论点也适用于这些传递getter/setter对的其他假定优点：如果您稍后决定更改设置的值，那么您就违反了合同。如果您在派生类中重写默认功能，而不是进行一些无害的修改（如日志记录或其他不可观察的行为），那么您就违反了基类的约定。这违反了Liskov替代原则，这被视为OO的原则之一。

如果一个类对每个字段都有这些愚蠢的getter和setter，那么它就是一个没有不变量、没有契约的类。这真的是面向对象的设计吗？如果类只有那些getter和setter，那么它只是一个哑数据持有者，哑数据持有者应该看起来像哑数据持有者：

class Foo {
public:
    int DaysLeft;
    int ContestantNumber;
};

向此类类添加传递getter/setter对不会增加值。其他类应该提供有意义的操作，而不仅仅是字段已经提供的操作。这就是如何定义和维护有用的不变量。

客户：“我可以用这个类的对象做什么？”设计器：“你可以读写几个变量。”客户：“哦……我想很酷吧？”

使用getter和setter是有原因的，但如果这些原因不存在，那么以虚假封装之神的名义制作getter/setter对并不是一件好事。使用getter或setter的有效原因包括经常提到的稍后可以进行的潜在更改，如验证或不同的内部表示。或者，该值应该是客户端可读但不可写的（例如，读取字典的大小），因此简单的getter是一个不错的选择。但是，当你做出选择时，这些理由应该存在，而不仅仅是你以后可能想要的潜在原因。这是YAGNI（你不需要它）的一个例子。

我只是想补充一点，即使有时它们对于变量/对象的封装和安全是必要的，如果我们想编写一个真正的面向对象的程序，那么我们需要停止过度使用附件，因为有时我们在不真正必要的情况下非常依赖它们，这几乎与我们将变量公开一样。