在实践中私人与公共成员(封装有多重要？)

面向对象编程的最大优点之一是封装,我们(或者至少,我已经)教过的"真理"之一是成员应该始终保持私密并通过访问者和变异器提供方法,从而确保验证和验证更改的能力.

不过,我很好奇,这在实践中有多重要.特别是,如果你有一个更复杂的成员(例如集合),那么将它公开而不是制作一堆方法来获取集合的密钥,添加/删除集合中的项目是非常诱人的,等等

你一般遵守规则吗？你的答案是否会改变,取决于它是为自己编写的代码还是其他人使用的代码？这种混淆是否有更微妙的原因？

由于过去许多人不得不维护几年前的代码,我很清楚,如果一个成员属性被公开,它最终会被滥用.我甚至听到人们不同意访问者和变异者的想法,因为它仍然没有真正达到封装的目的,即"隐藏一个类的内部工作".这显然是一个有争议的话题,但我的观点是"让每个成员变量都变得私密,主要考虑类必须做什么(方法),而不是让你如何改变内部变量".

这取决于.这是必须务实决定的问题之一.

假设我有一个代表一个点的类.我可以为X和Y坐标设置getter和setter,或者我可以将它们公开并允许对数据进行免费的读/写访问.在我看来,这是可以的,因为这个类就像一个美化的结构 - 一个数据集合,可能附加了一些有用的功能.

但是,在很多情况下,您不希望提供对内部数据的完全访问权限,并依赖类提供的方法与对象进行交互.一个例子是HTTP请求和响应.在这种情况下,允许任何人通过网络发送任何内容是一个坏主意 - 它必须由类方法处理和格式化.在这种情况下,该类被视为实际对象而不是简单的数据存储.

这实际上取决于动词(方法)是否驱动结构或数据是否存在.

是的,封装很重要.公开底层实现(至少)有两件事是错误的:

混合责任.呼叫者不应该或不想了解底层实现.他们应该只希望班级做好自己的工作.通过公开底层实现,你就是上课没有做好自己的工作.相反,它只是将责任推到了呼叫者身上.

将您与底层实现联系起来.一旦暴露了底层实现,就会与它相关联.如果您告诉呼叫者,例如,下面有一个集合,您就无法轻松地将集合交换为新的实现.

无论您是直接访问底层实现还是只复制所有底层方法,这些(和其他)问题都适用.您应该公开必要的实现,仅此而已.保持实施私密性使整个系统更易于维护.