隐藏信息如何有助于模块化?
信息隐藏如何帮助解耦组成系统的模块?
How does information hiding help to decouple the modules that comprise a system?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
信息隐藏如何帮助解耦组成系统的模块?
How does information hiding help to decouple the modules that comprise a system?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(2)
封装(信息隐藏)允许您仅向外界暴露绝对最少的信息。这意味着您可以根据自己的喜好更改未公开的位,而不会影响客户。
一个很好的例子。假设您已经实现了一个在数组中保存字符串的数据结构。如果您公开该数组,则数据结构的用户只需使用
str[7]
即可获取位置 7 处的字符串。现在,如果您决定将数据结构重新实现为平衡的,会发生什么树以加快字符串搜索速度。您可以通过将字符串移动到树中并将数组更改为指向树中位置的指针而不是字符串来实现此目的。
这会让你的客户崩溃,因为他们期待的是字符串,而不是指针。每个客户端都必须进行更改才能从数组中获取指针,然后在树中查找这些指针。
但是,如果您完全隐藏了实现并仅提供了一个函数:
您只需更改数据结构和函数即可保持兼容。
客户端不会中断,因为您的应用程序编程接口 (API) 没有改变。
我对类遵循的最重要的规则之一是追求最大的一致性,最小的耦合。换句话说,单个类应该拥有它需要的一切(仅此而已),并且应该与外界共享尽可能少的信息。
这意味着客户端所能做的就是调用 API。不允许公开非 API 方法或允许不受限制地访问公共变量 - 一切都应该使用 setter 和 getter 来完成。
Encapsulation (information hiding) allows you to only expose the absolute minimum to the outside world. This means you can change the non-exposed bits to your heart's content without affecting clients.
A case in point. Say you've implemented a data structure that holds strings in an array. If you expose the array, users of your data structure can just use
str[7]
to get the string at position 7.Now, what happens if you decide to re-implement your data structure as a balanced tree to speed up searches for strings. You do this by moving the strings into a tree and changing your array to be, not strings, but pointers to locations within the tree.
That will break your clients, because they will be expecting strings, not pointers. Every single client would have to change to get the pointers from the array then look those up in the tree.
However, if you had totally hidden the implementation and just provided a function:
you would just change the data structure and the function to stay compatible.
The clients don't break because your application programming interface (API) hasn't changed.
One of the most important rules I follow with classes is to aim for maximum coherence, minimum coupling. In other words, a single class should have everything it needs (nothing more) and it should have as little information sharing as possible with the outside world.
That means all that clients can do is call the API. No exposing non-API methods or allowing unfettered access to public variables - everything should be done with setters and getters.
数据隐藏并没有太多地解耦模块,而是有助于限制它们之间的耦合。
这是因为除了定义它们的模块之外,任何其他模块都不能使用任何隐藏元素,因此限制了将模块“耦合”在一起的可能的搭配/依赖/随叫随到。
换句话说,它将模块间的交换限制为在 API 中专门定义的,并且这一事实在修改给定模块的实现时有很大帮助,因为只要 API保持不变,模块互操作将起作用。 (无需搜索代码来查找模块 A 是否以某种方式使用了模块 B 中的变量 x(如果 B 隐藏了 x,则它是唯一使用它的模块!)
Data Hiding, doesn't so much decouples modules, that it helps limit the coupling between them.
That is because none of the hidden elements can be used by any other module than the one where they are defined, hence limiting the possible tie-ins / dependancies / call-it-what-you-may which "couple" the modules together.
In other words, it limits the inter-module exchanges to these that are specifically defined in the API, and this fact helps a lot when the implementation of a given module is modified, because so long as the API stays the same, the module interop will work. (No need to scout through the code to find if somehow module A, used the variable x from Module B (if B hides x, it is the only one to use it !)