首页 文章

为什么要使用getter和setter / accessors? [关闭]

提问于
浏览
1354

使用getter和setter的优点是什么 - 只能获取和设置 - 而不是简单地为这些变量使用公共字段?

如果getter和setter做的不仅仅是简单的获取/设置,我可以非常快地解决这个问题,但我不是100%清楚如何:

public String foo;

更糟糕的是:

private String foo;
public void setFoo(String foo) { this.foo = foo; }
public String getFoo() { return foo; }

而前者需要更少的样板代码 .

30 回答

  • 3

    此外,这是为了“面向未来”你的 class . 特别是,从字段更改为属性是ABI中断,所以如果你以后确定你需要更多逻辑而不仅仅是“设置/获取字段”,那么你需要打破ABI,这当然会产生任何问题其他已经针对你的课程编译 .

  • 76

    Getter和setter方法是访问器方法,这意味着它们通常是更改私有类成员的公共接口 . 您使用getter和setter方法来定义属性 . 您可以将getter和setter方法作为类外的属性进行访问,即使您在类中将它们定义为方法也是如此 . 类外的这些属性可以与类中的属性名称具有不同的名称 .

    使用getter和setter方法有一些优点,例如能够让您创建具有可以像属性一样访问的复杂功能的成员 . 它们还允许您创建只读和只写属性 .

    尽管getter和setter方法很有用,但是你应该注意不要过度使用它们,因为在某些情况下,它们会使代码维护变得更加困难 . 此外,它们还提供对类实现的访问,例如公共成员 . OOP练习不鼓励直接访问课程中的属性 .

    编写类时,始终鼓励您尽可能多地将实例变量设为私有,并相应地添加getter和setter方法 . 这是因为有几次您可能不想让用户更改类中的某些变量 . 例如,如果您有一个私有静态方法来跟踪为特定类创建的实例数,则您不希望用户使用代码修改该计数器 . 只有构造函数语句应该在调用时递增该变量 . 在这种情况下,您可以创建一个私有实例变量并仅为计数器变量提供getter方法,这意味着用户只能使用getter方法检索当前值,并且它们将无法设置新值使用setter方法 . 在没有setter的情况下创建getter是一种简单的方法,可以将类中的某些变量设置为只读 .

  • 14

    您应该在以下情况下使用getter和setter:

    • 你正在处理概念上属于某个属性的东西,但是:

    • 您的语言不是't have properties (or some similar mechanism, like Tcl' s变量曲线),或

    • 您的语言's property support isn'足以满足此用例,或者

    • 您的语言's (or sometimes your framework' s)惯用惯例鼓励此用例的getter或setter .

    所以这很少是一般的OO问题;这是一个特定于语言的问题,针对不同的语言(和不同的用例)有不同的答案 .


    从OO理论的角度来看,吸气剂和制定者是无用的 . 你的类的接口是它的作用,而不是它的状态 . (如果没有,你写错了类 . )在非常简单的情况下,类所做的只是,例如,表示直角坐标中的一个点,*属性是接口的一部分;吸气剂和孵化器只是 Cloud . 但是在任何非常简单的情况下,属性,getter和setter都不是接口的一部分 .

    换句话说:如果你认为你班上的消费者甚至不知道你有一个 spam 属性,更不用说能够无所畏惧地改变它,那么给他们一个 set_spam 方法是你想要做的最后一件事 .

    *即使对于那个简单的类,您也可能不一定要允许设置x和y值 . 如果这真的是一个类,不应该有翻译,旋转等方法吗?如果它只是一个类,因为你的语言没有记录/结构/命名元组,那么这不是OO的问题......


    但没有人会做一般的OO设计 . 他们用特定的语言进行设计和实施 . 在某些语言中,getter和setter远非无用 .

    如果您的语言没有属性,那么表示概念上属性但实际计算或验证的东西的唯一方法是通过getter和setter .

    即使您的语言确实具有属性,也可能存在不足或不合适的情况 . 例如,如果要允许子类控制属性的语义,则在没有动态访问的语言中,子类不能将计算属性替换为属性 .

    至于“如果我想稍后改变我的实现怎么办?”问题(重复在OP的问题和接受的答案中多次使用不同的措辞):如果它真的是纯粹的实现更改,并且您从属性开始,则可以将其更改为属性而不影响接口 . 当然,除非你的语言不支持 . 所以这真的只是同样的情况 .

    此外,遵循您正在使用的语言(或框架)的习语非常重要 . 如果你用C#编写漂亮的Ruby风格代码,那么除了你之外的任何有经验的C#开发人员都会在阅读它时遇到麻烦,这很糟糕 . 有些语言围绕其惯例的文化比其他语言更强.- Java和Python可能并不是巧合,而Java和Python恰好具有两种最强大的文化 .

    除了人类读者之外,还有一些图书馆和工具可以让您遵守惯例,如果不这样做,会让您的生活更加艰难 . 挂钩Interface Builder小部件除了ObjC属性之外的任何东西,或者使用某些没有getter的Java模拟库,只会让你的生活变得更加困难 . 如果这些工具对您很重要,请不要与它们作斗争 .

  • 410

    我们使用getter和setter:

    • 可重用性

    • 在编程的后期阶段执行验证

    Getter和setter方法是访问私有类成员的公共接口 .


    封装口头禅

    封装口头禅是将字段设为私有,方法是公共的 .

    Getter方法:我们可以访问私有变量 . Setter方法:我们可以修改私有字段 .

    即使getter和setter方法没有添加新功能,我们也可以改变主意,稍后再回来制作该方法

    • 更好;

    • 更安全;和

    • 更快 .


    在可以使用值的任何地方,可以添加返回该值的方法 . 代替:

    int x = 1000 - 500
    

    使用

    int x = 1000 - class_name.getValue();
    

    外行人的说法

    Representation of "Person" class

    假设我们需要存储此 Person 的详细信息 . 这个 Person 的字段为 nameagesex . 这样做涉及为 nameagesex 创建方法 . 现在,如果我们需要创建另一个人,则有必要再次为 nameagesex 创建方法 .

    我们可以使用getter和setter方法创建一个bean class(Person) ,而不是这样做 . 所以明天我们可以在需要添加新人时创建这个Bean class(Person class) 的对象(参见图) . 因此,我们重用bean类的字段和方法,这要好得多 .

  • 1

    从面向对象设计的角度来看,两种替代方案都可能通过削弱类的封装来破坏代码的维护 . 有关讨论,您可以查看这篇优秀的文章:http://typicalprogrammer.com/?p=23

  • 9

    因为从现在起2周(几个月,几年),当你意识到你的setter需要做 more 而不仅仅是设置值时,你也会意识到该属性已被直接用于其他238个类:-)

  • 28

    原因很多 . 我最喜欢的是当你需要改变行为或规范你可以在变量上设置的内容时 . 例如,假设您有一个setSpeed(int speed)方法 . 但是你想要你只能设置100的最高速度 . 你会做的事情如下:

    public void setSpeed(int speed) {
      if ( speed > 100 ) {
        this.speed = 100;
      } else {
        this.speed = speed;
      }
    }
    

    现在如果您的代码中使用公共字段,然后您意识到您需要上述要求,该怎么办?尽情享受公共领域的每一次使用,而不仅仅是修改你的二传手 .

    我2美分:)

  • 2

    公共字段并不比除了返回字段并分配给它之外什么都不做的getter / setter对更差 . 首先,很明显(在大多数语言中)没有功能差异 . 任何差异必须与其他因素有关,例如可维护性或可读性 .

    getter / setter对的一个常见的优点是,你声称你可以改变实现,而你的客户甚至不需要了解它 . 但是,向setter添加验证是对其前提条件的更改, a violation of the previous contract ,非常简单,"you can put anything in here, and you can get that same thing later from the getter" .

    因此,既然您违反了 Contract ,那么更改代码库中的每个文件都是您应该要做的事情,而不是避免 . 如果你避免它,你就假设所有代码都假设这些方法的 Contract 是不同的 .

    如果那不应该是 Contract ,那么接口允许客户端将对象置于无效状态 . 这与封装完全相反如果该字段从一开始就无法真正设置为任何东西,为什么从一开始就没有验证呢?

    这个相同的论点适用于这些传递的getter / setter对的其他假设优势:如果你以后决定更改所设置的值,那么你就违反了 Contract . 如果覆盖派生类中的默认功能,则会超出一些无害的修改(如日志记录或其他不可观察的修改)行为),你打破了基类的 Contract . 这违反了Liskov Substitutability Principle,这被视为OO的原则之一 .

    如果一个类对每个字段都有这些愚蠢的getter和setter,那么它就是一个没有任何不变量的类,没有 Contract . 这真的是面向对象的设计吗?如果所有课程都是那些吸气者和制定者,那么它只是一个愚蠢的数据持有者,而愚蠢的数据持有者应该看起来像愚蠢的数据持有者:

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

    将传递getter / setter对添加到这样的类中不会增加任何值 . 其他类应该提供有意义的操作,而不仅仅是已经提供的字段的操作 . 这就是你如何定义和维护有用的不变量 .

    客户:“我能用这个类的对象做什么?”设计师:“你可以读写几个变量 . ”客户:“哦......很酷,我猜?”

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

  • 833

    另一种用法(在支持属性的语言中)是setter和getter可以暗示操作是非平凡的 . 通常,您希望避免在属性中执行任何计算成本高昂的操作 .

  • 23

    我想抛出注释的想法:@getter和@setter . 使用@getter,您应该能够obj = class.field但不能使用class.field = obj . 使用@setter,反之亦然 . 使用@getter和@setter,你应该能够做到这两点 . 这将保留封装并通过在运行时不调用简单方法来减少时间 .

  • 16

    代码发展 . private 适用于需要数据成员保护的情况 . 最终所有的类都应该是"miniprograms",它们具有明确定义的接口,你不能只是拧紧内部的 .

    也就是说,软件开发并没有在第一次尝试时压制一些铸铁雕像 . 当你使用它时,代码更像是粘土 . It evolves 当您开发它并了解有关您正在解决的问题域的更多信息时 . 在开发过程中,类可能会相互影响而不是它们应该相互作用(您计划将因子分解出来),合并在一起或分开 . 所以我认为辩论归结为那些不想虔诚写作的人

    int getVar() const { return var ; }
    

    所以你有了:

    doSomething( obj->getVar() ) ;
    

    代替

    doSomething( obj->var ) ;
    

    不仅 getVar() 在视觉上有噪音,它给人的幻觉是 gettingVar() 在某种程度上是一个比实际更复杂的过程 . 你(作为 class 作家)如何看待 var 的神圣性,对于你 class 的用户来说尤其令人困惑,如果它有一个旁路安装者 - 那么看起来你正在把这些大门放到"protect"你坚持认为有 Value 的东西,( var )的神圣性,但即使你承认任何人只要进入他们想要的任何 Value 的能力,而你甚至不会窥视他们正在做的事情 .

    所以我编程如下(假设一种"agile"类型的方法 - 即当我编写的代码不知道它将要做什么/没有时间或经验来规划精心设计的瀑布式接口集时):

    1)从所有公共成员开始,获取具有数据和行为的基本对象 . 这就是为什么在我所有的C "example"代码中你都会注意到我使用的是 struct 而不是 class .

    2)当一个对象的数据成员的内部行为变得足够复杂时(例如,它喜欢以某种顺序保持内部 std::list ),写入访问器类型函数 . 因为我总是立即设置成员 private ,但是在该类的演变的某个地方,成员将"promoted"到 protectedprivate .

    3)完全充实并且对其内部有严格规则的类(即他们确切地知道他们正在做什么,并且你不得使用其内部成员)给予 class 指定,默认私人成员,以及只有少数几个成员被允许 public .

    我发现这种方法可以让我避免坐在那里,并且在课堂演变的早期阶段,当许多数据成员被迁移出去,转移等时,他们会虔诚地写下getter / setter .

  • 12

    很多人都在谈论吸气者和制定者的优势,但我想扮演魔鬼的拥护者 . 现在我正在调试一个非常大的程序,程序员决定让所有程序都得到getter和setter . 这可能看起来不错,但它是一个逆向工程的噩梦 .

    假设您正在查看数百行代码,并且您遇到了这样的问题:

    person.name = "Joe";
    

    这是一段非常简单的代码,直到你意识到它是一个二传手 . 现在,你跟着那个setter,发现它还设置了person.firstName,person.lastName,person.isHuman,person.hasReallyCommonFirstName,并调用了person.update(),它将查询发送到数据库等等 . 哦,那是你的内存泄漏发生的地方 .

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

  • 1

    我花了很长时间考虑Java案例,我相信真正的原因是:

    • Code to the interface, not the implementation

    • Interfaces only specify methods, not fields

    换句话说,您可以在界面中指定字段的唯一方法是提供用于编写新值的方法和用于读取当前值的方法 .

    那些方法是臭名昭着的吸气者和制定者....

  • 45

    它对于延迟加载很有用 . 假设有问题的对象存储在数据库中,除非您需要,否则您不希望得到它 . 如果对象是由getter检索的,那么内部对象可以为null,直到有人要求它为止,然后你可以在第一次调用getter时获取它 .

    我在一个项目中有一个基页类,它是从一些不同的Web服务调用中加载一些数据,但是这些Web服务调用中的数据并不总是在所有子页面中使用 . Web服务,为了所有的好处,开创了“慢”的新定义,因此如果您不需要,您不希望进行Web服务调用 .

    我从公共字段移动到getter,现在getter检查缓存,如果没有,则调用Web服务 . 因此,通过一点包装,可以防止大量的Web服务调用 .

    因此,getter使我无法在每个子页面上弄清楚我需要什么 . 如果我需要它,我会打电话给吸气器,如果我还没有它,它就会找到它 .

    protected YourType _yourName = null;
        public YourType YourName{
          get
          {
            if (_yourName == null)
            {
              _yourName = new YourType();
              return _yourName;
            }
          }
        }
    
  • 14

    到目前为止我在答案中遗漏的一个方面是访问规范:

    • 对于成员,您只有一个设置和获取的访问规范

    • 对于setter和getter,您可以对其进行微调并单独定义

  • 2

    There are actually many good reasons to consider using accessors 而不是直接暴露类的字段 - 不仅仅是封装的参数,使未来的更改更容易 .

    以下是我所知道的一些原因:

    • 与获取或设置属性相关联的行为的封装 - 这允许以后更容易添加其他功能(如验证) .

    • 在使用替代表示公开属性的同时隐藏属性的内部表示 .

    • 使公共接口免受更改 - 允许公共接口在实现更改时保持不变,而不会影响现有使用者 .

    • 控制属性的生命周期和内存管理(处置)语义 - 在非托管内存环境(如C或Objective-C)中尤为重要 .

    • 为属性在运行时更改时提供调试拦截点 - 在某些语言中调试属性更改为特定值的时间和位置可能非常困难 .

    • 改进了与旨在针对属性获取器/设置器进行操作的库的互操作性 - 脑海中浮现了模拟,序列化和WPF .

    • 允许继承者通过重写getter / setter方法来更改属性的行为和语义的语义 .

    • 允许getter / setter作为lambda表达式而不是值传递 .

    • getter和setter可以允许不同的访问级别 - 例如get可以是公共的,但是set可以受到保护 .

  • 22

    有一个很好的理由考虑使用访问器是没有属性继承 . 见下一个例子:

    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
    
  • 10