私人与受保护-可见性良好做法关注

我一直在寻找，我知道理论上的区别。

• public-任何类/函数都可以访问该方法/属性。
• protected-仅此类和任何子类可以访问该方法/属性。
• 私有 -只有此类可以访问方法/属性。它甚至不会被继承。

很好，问题是，它们之间的实际区别是什么？什么private时候使用protected？什么时候使用？在这方面是否有标准或可接受的良好实践？

到目前为止，为了保留继承和多态的概念，我使用public应从外部访问的所有内容（例如构造函数和主类功能），以及protected内部方法（逻辑，辅助方法等）。我在正确的轨道上吗？

（请注意，这个问题是给我的，但也供将来参考，因为我还没有看到像这样的问题）。

不，您的路线不正确。一个好的经验法则是：使所有内容尽可能私密。这使您的类更具封装性，并允许更改类的内部结构而不会影响使用您的类的代码。

如果您将类设计为可继承的，那么请仔细选择可以从子类重写和访问的类，并对其进行保护（最后说一句Java，如果要使其可访问但不可重写）。但是请注意，一旦您接受了该类的子类，并且有一个受保护的字段或方法，则此字段或方法就是该类的公共API的一部分，并且在以后不破坏子类的情况下可能不会更改。

不应继承的类应设为final（在Java中）。为了进行单元测试，您可以放宽一些访问规则（从私有到受保护，从最终到非最终），然后记录下来，并明确说明尽管该方法是受保护的，但不应覆盖该方法。

首先，我要说的是我在这里主要讨论方法访问，而在较小程度上，将类标记为最终访问，而不是成员访问。

老智慧

“将其标记为私人，除非您有充分的理由不这样做”

在开放源代码主导开发人员库空间和VCS /依赖关系mgmt之前的几天里，它就很有意义。在Github，Maven等的帮助下成为超级协作。那时，通过限制图书馆的利用方式也可以赚钱。我可能在职业生涯的前8到9年中严格遵循了这种“最佳实践”。

今天，我认为这是个坏建议。有时有一个合理的论据将一个方法标记为私有，或将一个类标记为final，但这种情况极为罕见，即使那样也可能没有任何改善。

你有没有：

• 被库等感到失望，惊讶或伤害，该库具有可以通过继承和少量代码修复的错误，但是由于私有/最终方法和类被迫等待可能永远不会出现的正式补丁？我有。
• 是否希望将库用于与作者想象的稍有不同的用例，但由于私有/最终方法和类而无法使用？我有。
• 是否对库的可扩展性过于宽容感到失望，惊讶或伤害？我还没有。

这是我听说过的默认情况下将方法标记为私有的三个最大的合理化方法：

合理化1：这是不安全的，没有理由要覆盖特定的方法

我无法数出是否有必要重写我编写的特定方法的错误次数。在研究了几个流行的开源库之后，我很难理解将内容标记为私有的真实成本。它通常消除了针对不可预见的问题或用例的唯一实际解决方案。相反，由于API安全相关的原因，我从未有超过16年的专业发展后悔将方法标记为保护而非私有。当开发人员选择扩展类并覆盖方法时，他们会自觉地说“我知道我在做什么”。为了提高生产力，应该足够了。期。如果很危险，请在类/方法Javadocs中加以注意，不要盲目地关上门。

默认受保护的标记方法可以缓解现代软件开发中的主要问题之一：想象力的失败。

合理化2：保持公共API / Javadocs的清洁

这是更合理的做法，并且取决于目标受众，这甚至可能是正确的选择，但是值得考虑的是保持API“干净”的代价实际上是：可扩展性。出于上述原因，为防万一，标记默认情况下受保护的内容可能更有意义。

合理化3：我的软件是商业软件，我需要限制其使用。

这也是合理的，但是作为消费者，我每次都会选择限制性较小的竞争对手（假设不存在明显的质量差异）。

永远不要把话说绝了

我并不是说永远不要将方法标记为私有。我说的更好的经验法则是“除非有充分的理由不这么做，否则使方法受到保护”。

该建议最适合那些正在分解成模块的图书馆或大型项目的人员。对于更小或更单一的项目，这无关紧要，因为您始终控制所有代码，并且在需要时很容易更改代码的访问级别。即使那样，我仍然会给出相同的建议:-)

停止滥用私人领域！！！

这里的评论似乎绝大多数支持使用私有字段。好吧，那么我有话要说。

私人领域原则上好吗？是。但是说一个黄金法则是在不确定时将所有内容都保密，这肯定 是错误的！在碰到一个问题之前，您不会看到问题。我认为，如果不确定，则应将字段标记为受保护。

您要扩展类有两种情况：

• 您想向基类添加额外的功能
• 您想修改当前包之外的现有类（也许在某些库中）

在第一种情况下，私有字段没有错。人们滥用私人领域的事实使您在发现自己无法修改时就感到沮丧。

考虑一个简单的汽车模型库：

class Car {
    private screw;
    public assembleCar() {
       screw.install();
    };
    private putScrewsTogether() {
       ...
    };
}

图书馆作者认为：我图书馆的用户没有理由需要访问assembleCar()正确的实现细节吗？让我们将螺丝标记为私有。

好吧，作者是错的。如果您只想修改assembleCar()方法而不将整个类复制到程序包中，那么您很不走运。您必须重写自己的screw字段。假设这辆车使用了十二个螺钉，并且每个螺钉都以不同的私有方法包含一些非常规的初始化代码，并且这些螺钉都标记为私有。在这一点上，它开始吮吸。

是的，您可以和我争论说，库作者可以编写更好的代码，所以私有字段没有错。我并不是说私有领域是OOP的问题。人们在使用它们时会出现问题。

这个故事的寓意是，如果您正在编写库，则永远不会知道用户是否要访问特定字段。如果不确定，请标记出来，protected以便以后每个人都更快乐。至少不要滥用私​​人领域。

我非常支持尼克的回答。

我前一段时间读过一篇文章，该文章讨论了尽可能多地锁定每个类。除非您迫切需要将某些数据或功能暴露给外界，否则请使所有内容均为最终私有。将范围扩展到以后更容易被接受总是很容易的，但是反之则不行。首先考虑让尽可能多的东西尽可能final这将使之间进行选择private和protected容易得多。

1. 除非您需要立即对它们进行子类化，否则将所有类定为最终类。
2. 使所有方法最终化，除非您需要立即子类化并覆盖它们。
3. 将所有方法参数定为最终值，除非您需要在方法主体中进行更改，否则无论如何，这在大多数情况下都是很尴尬的。

现在，如果您要上最后一堂课，那么将所有内容都设为私有，除非世界上绝对需要某些东西-将其公开。

如果剩下一个带有子类的类，请仔细检查每个属性和方法。首先考虑是否要将该属性/方法公开给子类。如果这样做，则考虑子类是否会在覆盖过程中使属性值或方法实现混乱，从而对对象造成严重破坏。如果有可能，并且您甚至想从子类中保护类的属性/方法（听起来很讽刺，我知道），则将其设为私有。否则使其受到保护。

免责声明：我不太用Java编程：）

什么private时候使用protected？什么时候使用？

可以从关系而不是IS-A关系的角度考虑实现私有继承。简而言之，继承类的外部接口与继承类没有（可见）关系，它private仅使用继承来实现基类提供的类似功能。

与私有继承不同，受保护的继承是继承的一种受限形式，其中派生类IS-A是基类的一种，它希望将派生成员的访问权限限制为仅对派生类。

好吧，如果paybill类处理付款记帐，那么封装就是全部，那么在产品类中，为什么它需要整个记帐过程，即付款方法如何在哪里付款，所以只让其他类和对象使用什么对于那些也会使用其他类的人来说，只不过是公共的而已，仅针对扩展类的那些限制而受到保护。由于您是madara uchiha的私人，就像"limboo"您可以看到它一样（您只上一堂课）。