为什么许多开发人员反对在OOP中使用“受保护”修饰符？

oop java c# language-agnostic

2022-09-03 16:59:42

我的一位同事正在上面向对象编程入门课，他的教授问了他一个讨论问题：

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

当这个问题在午餐时被提出来时，我和我的同事想不出为什么有人会反对在课堂上使用修饰符。撇开问题的前提不谈（假设许多开发人员实际上反对修饰符;他们是吗？），我们试图找出原因。protectedprotected

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

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

注意：因为教授问的是一个不特定于任何一种语言的一般OOP问题，所以我不确定答案是否会因为C#，Java等中受保护的实现不同而有不同的权重。

答案 1

开发人员不会抱怨保护，直到他们阻止开发人员获得他们想要使用的东西。对于正在创建子类的开发人员来说，受保护没什么大不了的，因为他们可以从子类中访问商品。

对于使用给定类（不扩展它）的开发人员，受保护的会阻止访问可能多汁的内部实现详细信息。这就是他们会抱怨的。

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

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

尽管看到无法访问的内容令人沮丧，但在限制性（全部拒绝，例外允许）模式下运行代码寿命和降低修订成本比在宽松模式下运行更好。

我曾经研究过（不，书面的）框架，其中使用该框架的开发人员抱怨它对内部细节不够宽容。即使修复了错误，添加了功能，并在各种平台迁移中重写了实现，这些人也抱怨说，但是公共的，支持的接口，代码的契约保持稳定，他们的代码基本上不受影响。

因此，简而言之，开发人员会抱怨受保护的（和私有的）访问修饰符，因为它阻碍了开发人员认为实现解决方案的最简单，最快捷的方式，忽略了依赖此类实现细节的未来成本。

封装是一件好事，即使它阻挡了最短的解决方案路径。;>

答案 2

因为对象交互优于继承。

据报道，James Gosling表示，如果他重新做Java，他就不会有类，并澄清说，“类”指的是继承。没有继承（虽然不是在Java中），是没有意义的（或简化为），但是有了继承，它就会爆炸成一个粘糊糊的公共退化，在Java中更是如此（Scala编程第5章）。protectedprivate

Allen Holub 写道（在 Holub on Patterns 中，这是一本 Java 书籍，但从一般的 OOP 角度来看很棒），这是另一个名字，特别是在 Java 中。受保护的符号是不能被信任为您在声明它的类中看到的符号。其他类（后代）可以在您的眼皮底下交换它。你正在处理溜溜球效应。protectedpublic

Gosling和Holub暗示了对象之间的交互优于类继承的概念。可能还有更多，但就软件质量指标（更灵活，更容易适应和扩展到新要求）而言，该代码将比基于继承的代码更好。当然，你需要务实。Holub写道，继承（受保护）在生产代码中占有一席之地，但作为代码批量优化，而不是设计元素。事实上，所有的设计都应该在接口方面完成，这意味着只有公共。