搞砸封装

Question

我知道封​​装究竟是什么意思。 但是在接受采访时我问过这个问题。

我有一个要求，我必须创建一个新类。 如果在一个团队中有人搞砸了班级的封装部分，但整体而言 所需的功能正常工作。假设它被传递给客户端。

客户可能面临的问题是什么？

我试图说明安全规范将被违反，我们可以使用漏洞添加一些东西并弄乱产品。但他说客户端对增强代码一无所知。  我终于放弃了。

任何人都可以帮我一些例子吗？

Answer 1

错误的封装（无论它意味着什么）使得更好地使用类。

例如，如果你有两个公共方法，并且它们应该只按正确顺序调用，否则对象状态变得腐败，这是一个错误封装的例子 - 用户无法从类定义知道那些方法应该是只按此顺序调用，并且该类没有做任何事情来防止以错误的顺序调用，一旦用户没有猜到正确的顺序，他就被搞砸了。

Answer 2

封装不是程序的属性。它是如何编写程序源代码的属性。因此，无法访问源代码的人（例如最终用户）将不会受到正确或不正确封装的影响。您可以编写一个没有封装的程序，如果功能正常，最终用户就不会注意到。

当然，那些有权访问代码的人会受到封装的影响，因为它通常会调试旧代码并更容易编写新的正交代码。因此，从某种意义上说，这确实会影响按时交付工作功能的能力，但在您的采访中，这些都是假设的情况。

Answer 3

鉴于“客户端不知道有关增强代码的任何信息”，我认为他们并没有编写任何使用API​​的代码。然后，它们的后果只能通过分布式代码直接修改本应该是对象的私有部分...这意味着更多的库和应用程序可能包含在该类的工作发生变化时也需要修改的代码。因此，对软件的更新可能更大，可能更难部署。 （如果正确封装成员函数无论如何都是内联的，它仍然可以像调用代码仍然需要重新编译一样）。

BTW，通过私有和受保护的封装不是运行时安全功能......即使在编译时，它也是为了提醒客户端代码某些东西不是为了直接访问/修改而设计的，但即使使用重新解释演员表，模板专业化和其他hackery，也很容易被绕过。

Answer 4

IMO您可能面临的最大问题是您将低估重构或实施新功能的成本。例如，用一个作为远程代理的新类替换该类可能看起来很简单，但是你可能会遇到问题，因为应用程序最终使用的内部结构很难改变以供远程使用。

可能会节省一些时间的快捷方式，但由于这种低估，你最终会免费向愤怒的客户回馈（及更多）。

另一个严重的问题是，一个具有清晰界面的程序，但是通过使用内部内容进行讨厌的事情而被戳戳只是很糟糕。这是一个问题，但也是一个问题，因为无论谁将会看到该代码都会觉得可以为将来的更改做类似的事情，特别是在时间压力下。

从长远来看，这将改变一碗腐烂的意大利面条中的程序，任何人都会因为无法解释的涟漪副作用而害怕接触。这个“broken window”效应的描述出现在好文章The Pragmatic Programmer中。