首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么有人真的要使用setter,而常规变量就可以做到这一点呢?

在编程中,setter是一种用于设置对象属性值的方法。尽管常规变量可以实现相同的功能,但使用setter方法有以下几个优势:

  1. 封装性:使用setter方法可以将属性的访问限制在类的内部,通过setter方法可以对属性进行验证、处理和控制访问权限。这样可以确保属性的有效性和一致性,提高代码的可维护性和安全性。
  2. 可扩展性:使用setter方法可以在属性赋值的过程中执行额外的逻辑操作,例如触发事件、更新相关属性等。这样可以方便地扩展和修改属性的行为,而不需要修改调用方的代码。
  3. 数据校验:通过setter方法可以对属性值进行校验,确保属性值符合预期的范围和格式。这样可以避免错误的数据被赋值给属性,提高代码的健壮性和可靠性。
  4. 代码一致性:使用setter方法可以统一属性赋值的方式,避免直接访问属性导致的代码分散和不一致。这样可以提高代码的可读性和可维护性,减少潜在的bug。
  5. 兼容性:使用setter方法可以方便地适应未来的需求变化,例如在属性赋值时增加日志记录、权限验证等功能。这样可以保持代码的兼容性和可扩展性,减少代码重构的成本。

在云计算领域,setter方法的应用场景较为广泛。例如,在云原生应用开发中,使用setter方法可以方便地配置和管理应用的各种属性,如环境变量、配置文件、资源配额等。在云数据库中,setter方法可以用于设置和更新数据库的各种参数和选项。在云存储中,setter方法可以用于设置文件的权限、元数据等。总之,使用setter方法可以提高云计算系统的灵活性、可配置性和可管理性。

腾讯云相关产品中,例如云原生应用开发平台Tencent Cloud Native,提供了丰富的API和工具,可以方便地配置和管理云原生应用的各种属性。具体产品介绍和文档可以参考:Tencent Cloud Native产品介绍

注意:本回答仅代表个人观点,不涉及任何特定云计算品牌商。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

谈谈fnal、fnally、 fnalize有什么不同?

使用fnal修饰参数或者变量,也可以清楚地避免意外赋值导致的编程错误,甚至,有人明确推荐将所有方法参数、本地变量、成员变量声明成fnal。...为什么?简单说,你无法保证fnalize什么时候执行,执行的是否符合预期。使用不当会影响性能,导致程序死锁、挂起等。...将所有成员变量定义为private和fnal,并且不要实现setter方法。通常构造对象时,成员变量使用深度拷贝来初始化,不是直接赋值,这是一种防御措施,因为你无法确定输入对象不被其他人修改。...关于setter/getter方法,很多人喜欢直接用IDE一次全部生成,建议最好是你确定有需要时再实现。2.fnalize真的那么不堪?...前面简单介绍了fnalize是一种已经被业界证明了的非常不好的实践,那么为什么会导致那些问题

73440

【面试精讲】Java:final、finally 和 finalize 有什么区别?

使用 final 修饰参数或者变量,也可以清楚地避免意外赋值导致的编程错误,甚至,有人明确推荐将所有方法参数、本地变量、成员变量声明成 final。...为什么?简单说,你无法保证 finalize 什么时候执行,执行的是否符合预期。使用不当会影响性能,导致程序死锁、挂起等。...通常构造对象时,成员变量使用深度拷贝来初始化,不是直接赋值,这是一种防御措施,因为你无法确定输入对象不被其他人修改。...关于 setter/getter 方法,很多人喜欢直接用 IDE 一次全部生成,建议最好是你确定有需要时再实现。 ---- 2、finalize 真的那么不堪?...前面简单介绍了 finalize 是一种已经被业界证明了的非常不好的实践,那么为什么会导致那些问题

18230
  • Getter & Setter使用还是废弃

    私有变量 为什么我们要使用私有的实例变量? 因为我们不希望其他类直接的依赖于这些变量。而且在心血来潮时,我们还可以灵活的修改变量类型和实现。...然而,为什么程序员们都自动在对象中加入getter和setter方法,以此对外暴露私有变量,就如同这些变量是公有的一样?...这是一个特殊的例外,我也告诉人们不要在他们的类中使用公共属性,但也存在例外。这就是这个规则的一个例外,因为仅仅说它是一个属性会更加简单和安全。我们退一步想一想:既然这样,为什么这条规则?...这真的实现了封装吗? 实际上,Getter/Setter和封装性没有任何关系。 数据并没有比使用公共属性获得更多隐蔽或封装。 其他的类对这个类的内部细节仍然了如指掌。...结论 通过使用存取方法来限制对属性变量的访问优于直接使用公共属性变量。 但是,为每一个属性都创建getter和setter方法确实有些极端。

    1.3K60

    还在用@Autowired和@Resource?试试@RequiredArgsConstructor吧!

    @Qualifier和Autowired配合使用,指定bean的名称,也可以做到按名称装配。...为什么说是避免不是解决? 因为构造器注入是通过构造方法来生成对象,其必须要先获取属性,才能生成调用构造方法进行实例化,这种情况的循环依赖是无法解决的。...另外要注意一点,属性注入和Setter注入的变量都无法使用final关键字修饰。...@RequiredArgsConstructor 这里可能会有人说不推荐使用Lombok,只要我们知其然且知其所以然,那他就是一个帮助我们快速开发的好工具。...那我们就可以使用属性注入(@Autowired和@Resource)的方式,直接通过构造器的方式来完成注入,不仅能够省略简化许多代码,也解决了属性注入可能存在的空指针问题。

    82120

    为什么需要 Kotlin

    现在?你摇摇头,显得有些无奈。『再也不需要注入 View 了是么?』...可你们为什么就不愿意 commit ?』SP 先生大惑不解。 『请问 SP 先生,我是 《Dalvik 日报》记者,我想问一下,为什么必须要 commit ?』 『您好,这是规定。』...Log.d(TAG, name) // 第一次读取,只能读取到默认值,那就是 橘右京 name = "不知火舞" Log.d(TAG, name) // 这里输出的就是 不知火舞 啦 我们真正做到了读写持久化数据就如同读写内存变量一样简单直接...Kotlin 之前是无法使用这把利刃的,这可能真的打击了不少人的积极性。不过,这已经不是问题了,因为你在前不久读到 Kotlin 1.0.4 的更新说明的时候,就已经发现 kapt 的存在。...只要你添加 apply plugin: “kotlin-kapt” 这句配置,你就可以像在 Java 当中一样使用 Dagger 了——你甚至还做了个 demo 试了一下,程序员嘛,总是无法摆脱成功写出一个

    1.1K40

    编程语言大对决!Ruby和Python谁更可读?

    很多网友站队Ruby,这是为什么? Ruby大战Python 其实,Ruby和Python几乎没有区别。 如果一个Python程序员打开了一个Ruby代码库,他不需要外部资料也能轻松弄懂它。...由于这是一个类变量,我们需要能够从类本身访问它。 现在我们可以使用BlogPost.count了,但我们不用post.count,因为它可能与常规实例变量混淆。...现在我们只能从BlogPost 类中访问count,那我们可以设置类变量吗? 让我们试试看。 OMG,我们从来没有为这个变量定义过setter。 放到Python里怎么样?...那么有人就要问了,Ruby的对象更直接吗? 我认为在 Ruby 中更容易看出类和实例属性之间的区别。 Setter 和 getter 允许您清楚地指定哪些属性是可读和可写的。...一旦有人开始进行高级元编程,你就想杀了他然后把他给埋了。 使用Ruby编写的Web应用开发框架Rails在很大程度上可以通过自主设计、良好的文档,以及已经编写问题答案的大量用户群来摆脱这些困境。

    68820

    哪些代码设计看似是面向对象,实际是面向过程的?

    getter、setter 问题我们就讲完了,我稍微总结一下,在设计实现类的时候,除非真的需要,否则,尽量不要给属性定义 setter 方法。...除此之外,尽管 getter 方法相对 setter 方法安全些,但是如果返回的是集合容器(比如例子中的 List 容器),也要防范集合内部数据被修改的危险。 2....为什么这么说?原因主要有以下几点。 首先,这样的设计会影响代码的可维护性。...拼接和分割两个方法,不需要共享任何数据,所以新的类不需要定义任何属性,这个时候,我们就可以把它定义为只包含静态方法的 Utils 类了。...只要它能为我们写出好的代码贡献力量,我们就可以适度地去使用

    80661

    Java 中的 final、finally、finalize 有什么不同?

    首先可以从语法和使用角度出发简单介绍三者的不同: final 可以用来修饰类、方法、变量,分别有不同的意义,final 修饰的 class 代表不可以继承扩展,final 的变量是不可以修改的, final...使用 final 修饰参数或者变量,也可以清楚地避免意外赋值导致的编程错误,甚至,有人明确推荐将所有方法参数、本地变量、成员变量声明成 final。...通常构造对象时,成员变量使用深度拷贝来初始化,不是直接赋值,这是一种防御措施,因为你无法确定输入对象不被其他人修改。...finalize 对于 finalize,是不推荐使用的,在 Java 9 中,已经将 Object.finalize() 标记为 deprecated。 为什么?...为什么不推荐使用 finalize? 前面简单介绍了 finalize 是不推荐使用的,究竟为什么不推荐使用

    87921

    警惕不规范的变量命名

    Boolean,isSend使用的是原生类型boolean,getter,setter方法是使用Intellij IDEA自动生成的,布尔类型生成getter,setter方法时略微特殊,比如原生类型的...在类变量中,也普遍提倡使用包装类型,原生类型的不足之处是很明显的。...所以提倡在局部作用域的计算中使用原生类型,而在类变量使用包装类型。 JavaBean规范 如今的微服务的时代,都是在聊架构,聊容器编排,竟然还有人聊JavaBean,但既然说到了规范,顺带提下。...(),即当类变量的首字母是小写,第二个字母是大写时,生成的getter,setter应当是(get/set)+类变量名。...另外需要知晓一点,IDE提供的自动生成getter,setter的机制,以及lombok这类框架的机制,都有默认的规则,在与其他反射框架配合使用时,只有双方都遵循规范,才能够配合使用不能笃信框架。

    2K90

    编程语言大对决!Ruby和Python谁更可读?

    很多网友站队Ruby,这是为什么? Ruby大战Python 其实,Ruby和Python几乎没有区别。 如果一个Python程序员打开了一个Ruby代码库,他不需要外部资料也能轻松弄懂它。...在Ruby中,无法像在Python中那样访问实例变量。你需要一个getter。 你也不能直接设置属性——你需要一个setter: 现在我们再试着运行看看。...由于这是一个类变量,我们需要能够从类本身访问它。 现在我们可以使用BlogPost.count了,但我们不用post.count,因为它可能与常规实例变量混淆。...现在我们只能从BlogPost 类中访问count,那我们可以设置类变量吗? 让我们试试看。 OMG,我们从来没有为这个变量定义过setter。 放到Python里怎么样?...一旦有人开始进行高级元编程,你就想杀了他然后把他给埋了。 使用Ruby编写的Web应用开发框架Rails在很大程度上可以通过自主设计、良好的文档,以及已经编写问题答案的大量用户群来摆脱这些困境。

    53120

    Kotlin、Swift、Scala 的延迟求值

    除了使用 Lazy 包装真实的值来实现延迟求值,我们当然也可以使用函数来做到这一点: [Kotlin] fun assertAllTrue(vararg conditions: () -> Boolean...哇,这样看起来 Scala 使用 lazy 关键字定义属性的语法比起 Kotlin 简单多了哎!不过换个角度,乍一看明明有一行代码放在前面却没有立即执行是不是会很怪?...其实 Swift 当中对于变量的读写有更严格的设计,这一点从 struct 与 class 的差异就可见一斑。...常见的语言当中都有 while 循环,为什么没有 whileNot ?聪明的我们想到了这一点,于是就开始造语法了。...小结 总结一下: Kotlin 没有 lazy 关键字,通过属性代理实现只读属性的延迟求值, Scala 和 Swift 则通过 lazy 关键字来做到这一点 Kotlin 和 Scala 对于属性的延迟求值只支持只读属性

    1.7K20

    iOS理论基础(二)

    category 使用 @property 也是只会生成 setter 和 getter 方法的声明,如果我们真的需要给 category 增加属性的实现,需要借助于运行时的两个函数: objc_setAssociatedObject...这时你就可以使用下面的方式来避免编译器报错: @property(nonatomic, strong, getter=p_initBy, setter=setP_initBy:)NSString*initBy...用@property声明的NSString(或NSArray,NSDictionary)经常使用copy关键字,为什么?如果改用strong关键字,可能造成什么问题?...= _myLastName;@end 上述语法会将生成的实例变量命名为_myFirstName与_myLastName,不再使用默认的名字。...笔者还是推荐使用默认的命名方案,因为如果所有人都坚持这套方案,那么写出来的代码大家都能看得懂。

    42510

    用十年的时间学会编程,不是21天

    在计算机专业领域,国内优秀的原创内容真的是太少了。我想这一点出版社的从业者应该体会非常深刻。...作为在阿里呆过的人当然不会相信,这里的门道其实并不高深,网上随便查下就可以知道,阿里巴巴高级专家一年收入几百万上下,教一个学生才收三千,那么他一年收多少学生才能赚回工资?...再比如你看到书上说朴素贝叶斯不太容易陷入过拟合,因此在一些正例稀疏的场景下广泛使用。不仔细看一眼瞥过去就过去了,但是如果深入去想,又会发现许多许多问题。为什么贝叶斯模型不容易过拟合?...什么样的模型不容易过拟合,什么样的容易过拟合为什么不容易过拟合就使用正例稀疏的场景?什么场景是典型的正例稀疏的场景? 你看,简单的一句描述,深挖下去有许多许多的细节。...既然黑天鹅总会出现,写的程序bug总是难免,那么我们又为什么着急

    50520

    写了个全局变量的bug,被同事们打脸!!!

    话说栈长前阵子写了一个功能,测试 0 bug 就上线了,上线后也运行好好的,好多天都没有人反馈bug,超爽。。 不出问题还好,出问题就是大问题。。...慎用全局变量,我在公司一直在强调,没想到这么低级的问题居然发生在自己身上,说起来真的惭愧啊。。...,我改成了这种方式: @Setter private Object object; 这个 @Setter 是 Lombok 的注解,用来生成 setters 方法,现在想起来,真是低级啊,同时操作的情况下...为什么说 SimpleDateFormat 不是线程安全的? 来看下它的 format 方法源码: ? 可以看到 calendar 变量居然也是全局变量,多线程情况下就会存在设置脏变量的情况。...所以,如果要用 SimpleDateFormat,就在每次用的时候都创建一个 SimpleDateFormat 对象,做到线程间隔离。

    76020

    Kotlin 的 Property Delegate 与 Swift 的 Property Wrapper

    实际上,如果我们把 SharedPreference 看成是类似内存一样的存储空间,那么为什么我们不能像读写内存中的变量那样轻松自在?...如果定义成 Bitmap,用的时候倒是省事儿了,可是最后我们又无法将其置为 null。怎么办? 有人说你这个是伪需求,不置为 null 也不会有内存泄露。...这其实也不难做到,我们可以通过属性代理提供一个 backingfield 来保存这个值就可以了。...getter 和 setter 的实现,Swift 通过 wrappedValue 这个计算属性来做到这一点,这样对于被包装的属性的访问其实就转发到对 wrappedValue 的访问上。...而这在 Kotlin 当中我们就只能通过反射来做到这一点了。

    5.2K20

    成为核心程序员的一些建议

    领导者之所以是领导者,是因为有人会追随他们,不是因为他们被任命了某个职位。权力可以被授予得到,但领导力却只能靠自己。你可以是一个没有领导力的权威,也可以成为未经授权的领导者。...如果你能做到这一点,那么你就成功了。 但是,该怎么做? 以身作则 ? 一开始一定要以身作则。 不要指挥别人怎么做,要做给他看。...你应该确保你对于你的团队正在使用的技术理解得最为透彻——如果可能的话——这样你就可以成为你的团队的可靠支持,你就可以自信地引导他们往更好的技术方向前进。...你应该给他们资源来做到这一点。你应该分享你正在学习的东西,并指引团队成员以帮助鼓励他们专业化地成长。...所以,好好地想一想,你是否真的想成为首席开发人员,如果你已经下定决定的话,那么谦虚,敢于承担责任,要尽你的力量使你的团队——以及团队成员——尽可能地成功。

    68150

    成为核心程序员的一些建议

    领导者之所以是领导者,是因为有人会追随他们,不是因为他们被任命了某个职位。权力可以被授予得到,但领导力却只能靠自己。你可以是一个没有领导力的权威,也可以成为未经授权的领导者。...如果你能做到这一点,那么你就成功了。 但是,该怎么做? 以身作则 ? 一开始一定要以身作则。 不要指挥别人怎么做,要做给他看。...你应该确保你对于你的团队正在使用的技术理解得最为透彻——如果可能的话——这样你就可以成为你的团队的可靠支持,你就可以自信地引导他们往更好的技术方向前进。...你应该给他们资源来做到这一点。你应该分享你正在学习的东西,并指引团队成员以帮助鼓励他们专业化地成长。...所以,好好地想一想,你是否真的想成为首席开发人员,如果你已经下定决定的话,那么谦虚,敢于承担责任,要尽你的力量使你的团队——以及团队成员——尽可能地成功。

    85490
    领券