引言

声明，今天的文章中没有一行Python代码，更多的是对编程语言设计理念的思考。

上一篇文章中介绍了关于Python面向对象封装特性的私有属性的相关内容，提到了Python中关于私有属性的实现是通过“名称混淆”的方式来实现的，我们还是可以通过混淆后的属性名称来访问私有属性。这样一来，似乎没有真正起到私有属性保护的作用，只是一种掩耳盗铃的做法而已。

Python关于私有属性的实现方式，到底是偷懒的掩耳盗铃还是相对来说恰到好处的实现呢？今天稍微发散一下，接着聊下私有属性。

Java、C#中的私有属性

最容易诟病Python中私有属性的，可能是从Java或者C#语言转过来的老手。在Java和C#中，通过关键字private/protected/public实现不同的属性保护级别。相较于Python中简陋的名称混淆，通过关键字这种访问级别的控制方式，似乎更加高级，被编程老手所推崇。

但是，稍微了解“反射”机制（Python中称之为“自省”）的，都会知道，所谓的私有属性的访问控制，仍然是可以绕过的。尤其是在一些特殊场景中，比如故障排除、反序列化或者涉及到历史系统迁移的兼容性问题等，可能需要通过反射机制来绕开私有属性的访问控制。

所以，Java、C#中的私有属性也并不是完全意义上的绝对安全。

私有属性的需求到底是什么

其实不只是Python、Java、C#的私有属性可以绕过访问控制，其他语言也存在类似的“问题”（这里，我们姑且称之为问题）。比如，C++可以通过指针来绕过，JS也可以通过类方法来实现。

是这些语言的设计者没有能力真正更好地保护私有属性？我看未必。

任何一个功能，从设计到实现，其实最应该问的问题，不是“能不能做到”，而是“有没有必要”。

私有属性是谁定义的，谁可能会使用，谁又可能错用。错用中场景中，又有多少是不小心错用，还是故意乱用。须知，很多错事，并不是出于恶意去做的，更多的是由于愚蠢。

假如能够做到绝对的安全，且不考虑成本，那么上述哪些特殊需求场景中，涉及到系统迁移的兼容性问题等，完全没法子访问到私有属性了，又该怎么办呢？要知道很多历史遗留系统的迁移工作，要么是没有源代码，要么是已经没法维护了，绝对安全假设下，显然完全拒绝了这些特殊场景的需求。

成本与收益、安全与灵活，显然是需要权衡取舍、更加动态平衡地看待。

所以，绝大多数编程语言设计中，虽然提供了一定的机制进行私有属性的声明，以限制其访问的随意性。但是，这些限制通常是在语法和语言约定的层面上实现的，并不保证绝对不可绕过。虽然，大多数常规需求中，不建议绕过私有属性的访问限制，但是仍然提供特殊场景中访问私有属性的手段，比如“名称混淆”，比如“反射”。

如何看待可以绕过的私有属性

Perl之父Larry Wall说过，“Perl不会强制你保护隐私。你应该待在客厅外，因为你没有收到邀请，而不是因为里面有把枪”。

我们对私有属性的使用，应该基于真正的使用场景，通常遵守语言的约定，极少的特殊场景，不得已才考虑违背这种约定。

私有属性的实现机制，更像是有些开关上的保护罩。这种保护罩只能是一种保护装置，能够有效避免不小心、误触开关的场景；但是，不是一种安全装置，因为它无法防止有意地去触动。

总结

除了Python之外，其他编程语言的私有属性，也更多的是在践行一种“语言约定”意义上的私有保护。私有属性的设计，到底是掩耳盗铃形式的偷懒，还是一种恰到好处的设计，仁者见仁、智者见智。在自己的编程实践中，是否有必要使用或者如何使用私有属性，也是根据具体场景具体分析。也许，没有绝对的更好、更差，只是是否有必要，以及哪种方案更适合而已吧。