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