我理解他们之间的差异(至少在C#中).我知道它们对分配给它们的元素有什么影响.我不明白为什么实施它们很重要 - 为什么不把所有东西都公开？
我在这个主题上阅读的材料通常都是关于类和方法如何不应该对他人进行不必要的访问,但我还没有看到一个例子,说明为什么/如何这是一件坏事.这似乎是一个安全的事情,但我是程序员 ; 我创建方法并定义它们将(或不会)做的事情.为什么我会花费所有的努力来编写一个试图改变它不应该的变量的函数,或者试图在另一个类中读取信息,如果那样糟糕的话？
如果这是一个愚蠢的问题,我道歉.这只是我在OOP上读过的第一篇文章中遇到的问题,我从来没有觉得它真的被点击了.
Car*_*icz 10
I'm the programmer 只有你是唯一的程序员才是正确的假设.
在许多情况下,其他程序员使用第一个程序员的代码.他们通过摆弄他们不应该使用的字段值来打算使用它,并且他们创建了一个有效的hack,但是当原始代码的生产者改变它时会中断.
OOP是关于创建具有明确定义的合同的库.如果所有变量都是公共的并且其他人可以访问,那么"契约"理论上包括对象(及其子对象)中的每个字段,因此构建一个仍然尊重原始契约的新的不同实现变得更加困难.
此外,对象的"移动部件"越多,对于类的用户来说,就越容易错误地操作它.
你可能不需要这个,但这是一个我认为有趣的例子:
假设您在发动机舱内销售没有发动机罩的汽车.到了晚上,司机开灯.他到达目的地,下车,然后记得他把灯打开了.他太懒了,无法解锁车门,所以他将电线拉到灯的外面,并将灯连接到电池上.这很好 - 光线不亮了.然而,由于他没有使用预期的机制,他发现自己下次在黑暗中行驶时会遇到问题.
生活在美国(继续,向我投票!),他拒绝承担他错误使用汽车内部的责任,并起诉你,制造商用于制造一种在黑暗中驾驶不安全的产品,因为灯不能关闭后可靠地打开.
这就是为什么所有汽车的引擎舱都有引擎盖:)
一个更严重的例子:你创建一个Fraction类,带有分子和分母字段以及一组操作分数的方法.您的构造函数不会让其调用者创建具有0分母的分数,但由于您的字段是公共的,因此用户很容易将现有(有效)分数的分母设置为0,并且随之而来的是欢闹.
首先,语言中没有任何内容强制您使用访问修饰符 - 如果您愿意,您可以自由地将所有内容公开.但是,使用它们有一些令人信服的理由.这是我的观点.
隐藏类的操作内部允许您保护该类免于意外使用.虽然您可能是该课程的创建者,但在许多情况下,您不会是唯一的消费者 - 甚至是维护者.隐藏内部状态可以为那些可能不了解其工作原理的人提供保护.让一切公开会产生诱惑,当类没有按照你想要的方式行事时"调整"内部状态或内部行为 - 而不是实际纠正内部实现的公共接口.这是毁灭的道路.
隐藏内部有助于消除命名空间的混乱,并允许Intellisense等工具仅显示相关且有意义的方法/属性/字段.不要对像Intellisense这样的工具进行折扣 - 它们是开发人员快速识别他们可以对您的班级做些什么的有力手段.
隐藏内部结构允许您构建适合于类正在解决的问题的接口.暴露所有内部(通常大大超过暴露的界面)使得以后很难理解该类试图解决的问题.
隐藏内部使您可以将测试重点放在适当的部分 - 公共接口上.当类的所有方法/属性都是公共的时,您必须测试的排列数量会显着增加 - 因为任何特定的调用路径都可以实现.
隐藏内部可帮助您控制(强制执行)通过类的呼叫路径.这样可以更轻松地确保您的消费者了解您的课程可以被要求做什么 - 以及何时.通常,您的代码中只有少数路径是有意义且有用的.允许消费者采取任何路径使得他们更有可能无法获得有意义的结果 - 并且会将其解释为您的代码是错误的.限制消费者如何使用您的类实际上可以让他们正确使用它.
隐藏内部实现可以让您更改它,只要知道它不会对您的类的消费者产生负面影响 - 只要您的公共接口保持不变即可.如果您决定在内部使用字典而不是列表 - 没有人应该关心.但是如果你让你的班级的所有内部都可用,那么有人可以编写代码,这取决于你内部使用列表的事实.想象一下,当您想要更改有关实施的选择时,必须更改所有消费者.黄金法则是:一个阶级的消费者不应该关心班级如何做它的作用.
| 归档时间： |
|
| 查看次数： |
221 次 |
| 最近记录： |