为什么许多开发人员反对在OOP中使用"protected"修饰符？

Question

我的一位同事正在参加面向对象编程课程的介绍,并被他的教授问了一个讨论问题:

为什么许多开发人员反对在类上/内使用"受保护"修饰符？

当问题在午餐时提出时,我的同事和我都无法想到有人可能会反对protected在课堂上使用修饰语的原因.设置问题的前提(假设许多开发人员实际上反对protected修饰符;是吗？),我们试图找出原因.

就个人而言,我在类上使用protected访问修饰符的唯一时间是我编写的代码,我可能想在测试环境中进行补充.例如,我可能编写一个没有调试信息的基类,然后创建一个新的类进行测试,继承基类并覆盖其方法,以便在基本方法调用之前/之后添加调试输出代码.我想我可以轻松地使用涉及接口和依赖注入的设计来实现相同的目标,但我唯一的经验protected是用于测试目的.在这种情况下,唯一要避免的原因protected是因为你可以用更好的方式完成同样的事情.

为什么开发人员可能会反对protected在他们的OOP设计中使用修饰符？

注意:因为教授要求一般OOP问题不是特定于任何一种语言,我不确定答案是否可能因为protectedC#,Java等的不同实现而加权不同.

Answer 1

开发人员不会抱怨保护,直到他们阻止开发人员获得他们想要使用的东西.对于正在创建子类的开发人员来说,受保护并不重要,因为他们可以从子类中访问这些商品.

对于使用给定类(不扩展)的开发人员,受保护的块可以访问可能多汁的内部实现细节.这是他们会抱怨的.

可以说,一些框架设计人员在隐私方面犯了太多错误 - 拒绝访问所有内容,只允许访问特定的文档化支持功能.如果您知道内部有很好的东西可以用来解决您的问题,那么这可能会令人沮丧,但请考虑另一方面:如果您的框架是由可以免费访问所有内容的人设计的,那么所有的内部细节都是如此.实现,在将来某个时候更新框架时,您很可能会遇到以下两种情况之一:

1. 更新后的框架会更改代码所依赖的实现细节,并且代码会中断
2. 设计人员意识到他们无法在不破坏大量代码的情况下更改实现,因此他们选择不实现有用的功能或错误修复.这称为代码瘫痪.

即使看到无法访问的内容令人沮丧,但在限制性(拒绝所有,异常允许)模式下运行代码的寿命和修订成本要低于允许模式.

我一直致力于(nay,书面)框架,其中使用框架的开发人员抱怨它对内部细节不够宽容.这些人抱怨即使修复了错误,添加了功能并且在各种平台迁移中重写了实现,但是公共支持的接口,代码合同保持稳定,代码基本上不受影响.

因此,简而言之,开发人员会抱怨受保护(和私有)访问修饰符,因为它妨碍了开发人员认为最简单,最快速的方法来实现解决方案,忽略了依赖此类实现的未来成本细节.

封装是一件好事,即使它阻止了解决方案的最短路径.;>

Answer 2

因为对象交互优于继承.

据报道,詹姆斯·戈斯林说如果他再次做Java,他就会没有上课,并澄清说"阶级"他的意思是继承. protected在private没有继承的情况下(或者没有在Java中)是没有意义的(或简化为),但是对于继承,它会爆炸成一个粘糊糊的公共退化,在Java中更是如此(Scala编程第5章).

Allen Holub写道(在Holub on Patterns是一本Java书,但从一般的OOP角度来看很棒),这protected是public另一个名字,特别是在Java中.一个受保护的符号是一个不能被信任是你它在声明的类中看到的.其他类(后代)可以在你的鼻子底下掉它.你正在处理溜溜球的效果.

Gosling和Holub暗示了对象之间的交互优于类继承的概念.可能会有更多的内容,但与基于继承的代码的代码相比,代码在软件质量指标(更灵活,更易于适应和扩展到新需求)方面会更好.当然,你需要务实.Holub写道,继承(protected)在生产代码中占有一席之地,但作为代码量优化,而不是设计元素.实际上,所有设计都应该在接口方面完成,这意味着公共 -只有.