艾伦·霍尔布写道：“你永远不应该使用 get/set 函数”，他正确吗？
艾伦·霍尔布写道：“你永远不应该使用 get/set 函数”，他正确吗？
这个问题已经在这里有了答案：
Allen Holub写道:
没有耦合就没有程序。然而，通过奉行面向对象（OO）原则（其中最重要的是对象的实现应该完全隐藏在使用它的对象之外），可以大大减少耦合。例如，一个对象的实例变量（并非常量的成员字段）应该始终是私有的。没有例外。永远不要使用protected实例变量，你可以偶尔有效地使用protected方法。
听起来很合理，但他接着说:
由于同样的原因，您永远不应该使用get/set函数，它们只是过于复杂的方式来使字段公开（尽管在返回完整对象而不是基本类型值的情况下返回对象的访问函数在设计中是合理的）。
对我来说，这听起来很疯狂。
我理解信息隐藏的原理，但是如果没有访问器和变异器，您根本无法使用Java bean。我不知道如果模型没有访问器，如何遵循MVC设计，因为模型不能负责呈现视图。
然而，我是一名年轻的程序员，我每天都学习更多有关面向对象设计的知识。也许有更多经验的人可以就这个问题发表意见。
Allen Holub的相关文章
相关问题：
仔细阅读这篇文章。Holub强调getter和setter是一种“默认反模式”，是在设计系统时我们会不由自主地陷入的坏习惯；因为我们可以这么做。\n\n思考过程应该是这样的：这个对象是做什么的？它的责任是什么？它的行为是什么？它知道什么？认真思考这些问题，自然会将您带向设计提供最高级别接口的类。\n\n车是一个很好的例子。它提供了一个定义明确、标准化的高级接口。我不关心setSpeed(60)...是MPH还是km/h？我只是加速、巡航、减速。我不需要思考setSteeringWheelAngle(getSteeringWheelAngle()+Math.rad(-1.5))中的细节，我只需调用turn(-1.5)，这些细节会被隐藏起来。\n\n归根结底，它可以总结为：“您可以并应该确定每个类将用于什么、它是什么、它代表什么，并提供实现这些要求的最高级别接口。Getter和setter通常是一种逃避责任的方式，当程序员懒得分析每个类是什么和什么不是时，我们就会走向“它可以做任何事情”的道路。Getter和setter是邪恶的！”\n\n有时候类的实际要求是不可预知的。没关系，暂时采用getter/setter反模式，但当您通过经验知道类被用于什么时，您可能会回来清理低级别接口。基于“在第一次编写时希望自己知道的东西”进行重构是常规做法。您不必事先了解所有内容才能开始，只是您了解的越多，就越不需要重新工作。\n\n这就是他所提倡的心态。getter和setter是陷入的一个容易的陷阱。\n\n是的，bean基本上需要getter和setter，但对我而言，bean是一种特殊情况。Bean表示名词、东西、有形可辨认(如果不是物理的)的对象。并不是很多对象会自动行为；大部分时候，外部力量，包括人类，会操作它们，使它们成为生产力。\n\ndaisy.setColor(Color.PINK)是完全有道理的。还可以做什么？也许进行一次瓦肯人的加农，让花儿想成为粉色？嗯？\n\nGetter和setter有它们的“邪恶”之处。只是像所有真正好的面向对象的事物一样，我们倾向于过度使用它们，因为它们是安全和熟悉的，更不用说它们是简单的了，因此，对于新手来说最好不要看到它们或听到它们的存在，至少要等到他们掌握了精神加农的事情。
