面向对象其实不需要封装

短命女 2022-01-30 10:25 197阅读 0赞

Note: 这里的‘封装(Encapsulation)’指的是限制对象访问的语言特性，也被称为信息隐藏(information hiding)。翻译的初衷在于看看一些不同的想法，作者的思考在某个层次上是有道理的，但并是完全正确。总之这里有一个决策和角度的问题。

## **没有封装的OOP?** ##

Python支持Object Oriented Programming, 却没有封装(encapsulation)**.** 许多都对此不解，但讨论来讨论去，最终的结论是OO压根不需要封装。 Python里什么公有的，如果在成员名字前加两个下划线则表示不能由外部使用，也即非接口类的成员。但也有办法使用，当然风险自理。Python开发者称之为命名约定式的封装，而非强制封装。本质上，这并不是封装，也没有隐藏什么。原因何在？

## **用电脑做个比喻 ** ##

我可以随时打开我的电脑，升级一下，或者换个部件，这很容易做到。如果硬件厂商也开始使用封装，我们可能很难再打开机箱，如果要加个内存或换个什么，就只能送回厂家了。

如上封装限制了对实现细节的使用。但确实需要时，就只能自己动手了。硬件上并没有限制我把它打开，软件为什么要这样做？

## **使用抽象代替封装 ** ##

一个关于抽象(abstraction)的定义说到: ‘the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances**.**’. 从编程上看，意思就是在实现之上提供一个接口，用户只需要知道接口层(即抽象层)，而不用关心实现的细节。与封装的差异在于，如果用户想要去了解那些潜在的细节，仍然可以做得到。绝大多数硬件都是使用抽象代替封装，使用一个很少变化的接口，同时允许高级用户窥看细节。

当使用抽象代替封装时，用户可以清楚地看到接口，和使用封装的方式也没什么差别。我们鼓励用户使用开放的接口，但并不仅限于此。对于使用接口而言，抽象与封装的效果是一样的，只是前者允许访问背后的内容。这样使用者完全可以了解到他的行为可能带来的风险。

## **一个实例 ** ##

假设我用一个跨平台的GUI库来开发应用程序。跨平台的GUI库好用，在不同平台上也保持相同的接口，会省去不少麻烦。

假设Windows用户希望添加一个特别的功能。这个时候，你如果坚持封装，你会面临如下的问题::

*  在原来的GUI库上实现一个新的库，这样就要包括其它的接口。
 *  联系厂商做特殊修改，这个可能性不大，即使可行，也未必来得及！
 *  放弃原先的库，在Windows上使用新的库。这个风险很高，成本也很高！

如果你转而使用抽象呢**?** 除了上面的选项外，你可以动到库里的细节实现，不过要考虑一下几个风险:

*  有没有可以破坏其它行为。
 *  库的升级可能导致你的修改失败，所以每次升级时都要检查一下它的行为是否仍然正常。
 *  当然库的厂商可不一定愿意为你提供技术支持了。

就是说，使用抽象代替封装时，你一定要自行权衡利弊。我可不是鼓励大家使用那些细节的内容，只是在一些情况下，这可能是一个最佳方案。

## **How I do it ** ##

在传统的OO语言，我将接口定义为public, 其它实现的细节内容我定义在protected中。四人帮曾经说: “因为继承会将父类的实现细节暴露给子类，所以通常称为‘继承破坏了封装’’”**.** 事实上，这正是我想要的效果。我的用户可以使用public接口，如果需要，他们可以子类化自己的类。

这招让我省了不少的事，我不用再纠结于private, protected或者public。我的座佑铭正是:*Keep It Stupid Simple*.

## **封装不是安全 ** ##

把数据隐藏或者保护起来不让用户接触到，通常讲是很有必要的。但如果是要讨论安全性，我认为通过封装来实现安全性是极为糟糕的。

## **结论 ** ##

依赖于细节实现绝不是什么好主意，所以只能使用类的公共接口。不过总有些意思不到情况让你需要使用一些内部细节，这个时候最好把类设计更加有用一些，让用记可以通过一些专业的方式来使用它。用户不是白痴，要假定他们都是专家，可以很合理的使用你的类来解决一些问题。如果他们要访问一些细节内容，自然有他们的理由，或许就是别无它法。所以，不要拿封装来对付他们。

[原文地址][Link 1].

转载请注明出处:http://blog.csdn.net/horkychen

[Link 1]: http://www.koonsolo.com/news/object-oriented-programming-doesnt-need-encapsulation/