为什么有私有字段，保护不够？

private类字段/属性/属性的可见性有用吗？在OOP中，迟早要创建一个类的子类，在这种情况下，最好能够理解并能够完全修改实现。

当我对一个类进行子类化时，我要做的第一件事就是将一堆private方法更改为protected。但是，对外部世界隐藏细节很重要-因此我们需要protected而不仅仅是public。

我的问题是：您是否知道一个重要的用例，private而不是protected一个好的工具，或者两个选项“ protected＆public”对于OOP语言是否足够？

因为正如您所说，您protected仍然可以“完全修改实现”。它并不能真正保护班级内部的任何事物。

我们为什么要关心“真正保护”课堂内的东西？因为否则，在不破坏客户端代码的情况下更改实现细节是不可能的。换句话说，对于写原始基类的人来说，写子类的人也是“外部世界”。

实际上，protected成员本质上是类的“子类的公共API”，并且需要保持稳定和向后兼容，就像public成员所做的一样。如果我们没有创造真正的能力private的成员，则没有在一个实现将永远是安全的改变，因为你不能就能够排除可能性（非恶意）客户端代码总算依靠它。

顺便说一句，虽然“在OOP中，迟早要成为一个类的子类”在技术上是正确的，但您的论点似乎是在做出一个更强的假设，即“迟早要成为一个子类的子类”。每个班级”几乎可以肯定不是这样。

在OOP中，迟早要创建一个类的子类

错了 并非每个类都应该被子类化，并且某些静态类型的OOP语言甚至具有阻止它的功能，例如final（Java和C ++）或sealed（C＃）。

理解并能够完全修改实现是一件好事。

不，这不对。对于一个类来说，即使它是继承自它的，也能够清楚地定义其公共接口并保留其不变量，这是一个好习惯。

通常，访问控制与分区有关。您希望理解代码的单个部分，而不必详细了解它如何与其余代码交互。私人访问允许。如果所有内容至少都受到保护，则必须了解每个子类的操作才能了解基类的工作方式。

或用斯科特·迈耶斯（Scott Meyers）的话来说：类的私有部分受有限数量的代码（即类本身的代码）的影响。

公共部分可能会受到现有的每一位代码以及尚未编写的每一位代码的影响，这是无限数量的代码。

受保护的部件可能会受到每个现有子类以及尚未编写的每个子类的影响，这也是无限数量的代码。

结论是，受保护比公共给您带来的收益更多，而私有给您带来了真正的进步。受保护的访问说明符的存在是有问题的，而不是私有的。

是的，私有字段是绝对必要的。就在这周，我需要编写一个自定义词典实现，在其中我控制了放入词典中的内容。如果要对字典字段进行保护或公开，那么我本来要精心编写的控件可能会很容易被规避。

专用字段通常用于提供保护措施，以确保数据符合原始编码器的要求。使一切都受到保护/公开，您将通过这些程序和验证来骑马训练。

当试图正式推理关于面向对象程序的正确性是典型的使用涉及模块化方法的对象不变。用这种方法

1. 方法与条件（合同）的前后相关。
2. 对象与它们相关联的不变量。

关于对象的模块化推理如下（至少首先近似）进行

1. 证明对象的构造函数建立了不变式
2. 对于每个非私有方法，假定对象不变式和方法前提条件在输入时成立，然后证明代码主体暗示后置条件和不变条件对方法的退出

想象一下，我们object A使用上述方法验证了。而现在希望验证method g的object B它调用method f的object A。模块化推理使我们method g无需重新考虑的实现即可进行推理method f。假设我们可以在调用站点建立的不变性object A和前提条件，method f那么method g,我们可以将的后置条件method f作为方法调用行为的总结。此外，我们还将知道，在调用返回后，A仍然保持不变。

这种推理的模块化使我们可以正式考虑大型程序。我们可以分别对每种方法进行推理，然后将这种推理的结果组合起来，从而对程序的更大部分进行推理。

私有字段在此过程中非常有用。为了知道对象的不变性在该对象的两个方法调用之间继续保持不变，我们通常依赖于以下事实：在此期间对象没有被修改。

为了使模块化推理能够在对象没有私有字段的情况下工作，那么我们将必须有某种方法来确保无论哪个字段碰巧被另一个对象设置，都必须始终重建不变式（在字段之后组）。很难想像一个对象不变式，无论对象的字段具有什么值，都保持不变，并且在推理程序的正确性时也很有用。我们可能必须发明一些关于现场访问的复杂约定。而且可能还会失去部分（甚至是全部）模块化推理能力。

受保护的领域

受保护的字段恢复了我们进行模块化推理的能力。取决于语言，protected可能会限制将字段设置为所有子类或所有子类和相同包装类的能力。通常情况下，当我们在思考所编写对象的正确性时，我们无法访问所有子类。例如，您可能正在编写一个组件或库，以后将在一个较大的程序（或几个较大的程序）中使用-其中某些甚至可能尚未编写。通常，您将不知道是否可以将其分类。

但是，子类通常有责任维护其扩展类的对象不变性。因此，在一种语言中，保护仅表示“子类”，并且我们受到纪律以确保子类始终保持其父类的不变量，因此您可能会争辩说使用受保护而不是私有的选择只会损失最小的模块化。

尽管我一直在谈论形式化推理，但通常人们认为，当程序员非正式地对代码的正确性进行推理时，他们有时还依赖于类似类型的参数。

privateprotected出于相同的原因，一个类中的变量优于块break内switch的goto label语句胜于语句。这就是人类程序员容易出错。

protected变量很容易导致意外滥用（程序员错误），就像该goto语句很容易创建意大利面条式代码一样。

是否可以使用protected类变量编写有效的无错误代码？当然是！就像可以使用编写有效的无错误代码一样goto；但正如老话所说，“只是因为你可以，并不意味着你应该！”

存在类以及确实是OO范式，以防止不幸的易于出错的人类程序员犯错误。防止人为错误的防御措施仅与班级内置的防御措施一样好。实施课程protected相当于在堡垒的墙壁上凿出一个大洞。

基类完全不了解派生类。就基类而言，protected实际上并没有为您提供更多保护public，因为没有什么可以阻止派生类创建public行为类似于后门的getter / setter。

如果基类允许不受阻碍地访问其内部实现细节，那么该类本身就无法防范错误。基类绝对不了解其派生类，因此无法防范那些派生类中的错误。

基类可以做的最好的事情是隐藏尽可能多的实现，private并放置足够的限制以防止破坏派生类或该类之外的任何其他内容的更改。

最终，存在高级语言以最大程度地减少人为错误。还存在良好的编程习惯（例如SOLID原则），以最大程度地减少人为错误。

忽略良好编程习惯的软件开发人员，失败的可能性更高，并且更有可能产生无法维护的解决方案。遵循良好实践的人失败的可能性要低得多，并且更有可能产生可维护的可行解决方案。

可继承类具有两个协定-一个带有对象引用的持有者，另一个带有派生类。公共成员受参考所有者的合同约束，受保护成员受派生类的合同约束。

使成员protected成为更通用的基类，但通常会限制类的将来版本更改的方式。创建成员private可以使类作者具有更多的通用性来更改类的内部工作方式，但是限制了可以从类中派生的类的种类。

例如，List<T>在.NET中将后备存储设为私有。如果受保护，派生类型可能会做一些有用的事情，而这些事情原本是不可能的，但是将来的版本List<T>将永远不得不使用笨拙的整体式后备存储，即使对于包含数百万个项目的列表也是如此。将后备存储设置为私有将允许将来的版本List<T>使用更有效的后备存储，而不会破坏派生类。

我认为您的论点中有一个关键的假设：当某人写某堂课时，他们不知道谁会继续上课，原因是什么。在这种假设下，您的论点将是非常合理的，因为您私有的每个变量都可能会切断未来的发展途径。但是，我会拒绝这个假设。

如果该假设被拒绝，则仅需考虑两种情况。

1. 原始类的作者对于为什么要扩展它有非常明确的想法（例如，它是BaseFoo，并且在将来还会有一些具体的Foo实现）。

在这种情况下，作者知道有人会扩展该类及其原因，因此将确切知道要保护的内容和私有化的内容。他们使用私有/受保护的区别将各种接口传达给创建子类的用户。

2. 子类的作者正试图以某种行为侵入父类。

这种情况很少见（您可能会认为这是不合法的），并且不建议仅在原始代码库中修改原始类。这也可能是不良设计的征兆。在那种情况下，我更喜欢黑客行为的人，只是使用其他黑客，例如朋友（C / C ++）和setAccessible(true)（Java）。

我认为拒绝这个假设是安全的。

这通常归结为继承而不是继承的想法。继承通常被认为是减少代码重用的理想方法，但是很少应该将其作为代码重用的首选。我没有简单的否定论点，理解起来可能相当困难且充满争议。但是，根据我在域建模方面的经验，我发现在很少清楚谁将继承我的类及其原因的情况下，很少使用继承。

所有这三个访问级别都有其用例，缺少它们的OOP将是不完整的。通常你会

• 将所有变量/数据成员设为私有。您不希望外部有人弄乱您的内部数据。同样为公共或受保护的接口提供辅助功能（根据几个成员变量进行计算的方法）的方法-仅供内部使用，您将来可能希望对其进行更改/改进。
• 公开课堂的通用界面。那就是原始类的用户应该使用的东西，以及您认为派生类也应该是什么样子。为了提供适当的封装，这些通常只是方法（以及帮助程序类/结构，枚举，typedef，无论用户需要使用哪种方法来使用它们），而不是变量。
• 声明受保护的方法，该方法可用于想要扩展/专业化您的类的功能的人，但不应作为公共接口的一部分-实际上，您通常会在必要时将私有成员提高为保护对象。如果没有疑问，请直到知道
  1. 您的班级可以/可以/将被分类，
  2. 并清楚地知道子类的用例可能是什么。

而且只有在有充分理由的情况下，您才可以偏离此一般方案。提防“当我可以从外部自由访问它时，这将使我的生活更轻松”（并且这里外部还包括子类）。当我实现类层次结构时，我通常从没有受保护成员的类开始，直到我对它们进行子类化/扩展/专业化，成为框架/工具包的基类，有时将其原始功能的一部分上移。

也许一个更有趣的问题是，为什么除了私有之外，还需要其他任何类型的字段。当子类需要与超类的数据进行交互时，这样做会直接在两者之间创建直接耦合，而使用提供二者之间交互的方法可以实现某种程度的间接调用，从而可以对父类进行更改。超类，否则将非常困难。

多种语言（例如Ruby和Smalltalk）不提供公共字段，因此不鼓励开发人员直接耦合到其类实现，但是为什么不走得更远，而只有私有字段呢？不会失去一般性（因为超类始终可以为子类提供受保护的访问器），但是它将确保类始终与子类至少保持很小的隔离度。为什么这不是更常见的设计？

这里有很多不错的答案，但是我还是会投入两分钱。:-)

私有是好的，其原因与全局数据不好的原因相同。

如果一个类声明数据为私有，那么您绝对知道，与此数据混淆的唯一代码是该类中的代码。出现错误时，您不必在整个创建过程中进行搜索，只需查找可能会更改此数据的每个位置。您知道它在课堂上。当您对代码进行更改时，并且您对该字段的使用方式进行了更改，则不必跟踪可能使用此字段的所有潜在位置，也不必研究计划的更改是否会破坏它们。您知道班上只有地方。

我已经有很多次不得不对库中的类进行更改，并且这些类被多个应用程序使用，而且我必须非常谨慎以确保不会破坏我一无所知的应用程序。公开和受保护的数据越多，发生故障的可能性就越大。

我认为值得一提一些不同意见。

从理论上讲，出于其他答案中提到的所有原因，最好控制访问级别。

实际上，在查看代码的过程中，我经常看到人们（喜欢使用私有的），将访问级别从私有->受保护的更改为访问级别，而不是从受保护的->公共更改。几乎总是，更改类属性涉及修改setter / getter。这些浪费了我很多时间（代码审查）和他们的时间（更改代码）。

这也让我感到恼火，这意味着它们的类没有为修改而关闭。

那就是内部代码，您可以根据需要随时更改它。当第三方代码不那么容易更改代码时，情况更糟。

那么有多少程序员认为这很麻烦？那么，有多少人正在使用没有私有语言的编程语言？当然，人们不仅使用这些语言是因为它们没有专用说明符，而且还有助于简化语言，并且简单性很重要。

Imo与动态/静态输入非常相似。从理论上讲，静态类型非常好。在实践中，它只防止类似错误的2％，动态类型不合理的有效性...。使用private可能会减少错误。

我认为SOLID原则很好，我希望人们更关心它们，而不是关心创建具有公开，受保护的和私有的类。

我还要补充一个实际的例子，说明为什么protected还不够。在我的大学里，最初的几年从事一个项目，他们必须开发桌面版的棋盘游戏（后来开发了AI，并通过网络将其连接到其他玩家）。提供了一些部分代码以使他们开始使用它们，包括测试框架。公开了主游戏类的某些属性，protected以便扩展该类的测试类可以访问它们。但是这些字段不是敏感信息。

作为TA为单位我经常看见学生们简单地使他们的所有添加的代码protected或public（或许是因为他们看到了其他protected和public东西，认为他们应该效仿）。我问他们为什么他们的保护水平不合适，许多人不知道为什么。答案是，他们暴露给子类的敏感信息意味着其他玩家可以通过简单地扩展该类并访问游戏的高度敏感信息来作弊（本质上是对手的隐藏位置，我想这类似于如果您可以通过扩展某些班级在战舰板上看到对手的碎片）。这使得他们的代码在游戏环境中非常危险。

除此之外，还有许多其他原因可以使某些内容甚至对于您的子类也保持私有。可能是隐藏实现细节，如果某些人不一定知道他们在做什么，那么可能会改变类的正确工作（大多数情况是在这里考虑其他人在使用您的代码）。

私有方法/变量通常将从子类中隐藏。那可能是一件好事。

私有方法可以对参数进行假设，并将健全性检查留给调用方。

一种受保护的方法应进行完整性检查输入。

“私有”是指：除类本身以外，任何人都不得更改或访问。不打算由子类更改或访问。子类？什么子类？你不应该继承这个！

“受保护”是指：仅旨在由类或子类更改或访问。可能推论您应该继承，否则为什么要“受保护”而不是“私有”？

这里有明显的区别。如果我将某些内容设为私人，则应该避免弄脏您的手指。即使您是子类。

当我对一个类进行子类化时，我要做的第一件事就是将一堆私有方法更改为protected

关于privatevs protected 方法的一些理由：

private方法防止代码重用。子类不能使用私有方法中的代码，而可能不得不再次实现它-或重新实现最初依赖于私有方法＆c的方法。

在另一方面，这是任何方法不是 private可以看作是由类“外部世界”提供的API，在这个意义上的第三方子类被认为是“外面的世界”也一样，别人在他的回答提出已经。

那是一件坏事？-我不这么认为。

当然，（伪）公共API会锁定原始程序员，并阻碍这些接口的重构。但是反过来，为什么程序员不应该像公共API一样干净，稳定地设计自己的“实现细节”呢？他是否应该使用它private以便草率构造“私有”代码？想也许他以后可以清理，因为没人会注意到吗？-不

程序员也应该在他的“私有”代码中稍加思考，以便以允许甚至促进尽可能多地重用它的方式来构造它。这样，非私有部门在将来可能不会像某些恐惧那样成为沉重的负担。

很多（框架）代码，我看到采用不一致的用途private：protected，它几乎做任何事情比委托给私有方法更多的非最终方法是常见的。protected，其非最终方法的合同也只能通过直接访问私有字段来实现。

尽管从技术上讲，没有任何方法可以使（编译器）显而易见，但是这些方法在逻辑上不能被覆盖/增强。

需要可扩展性和继承性吗？不要做你的方法private。

不想改变班上的某些行为吗？做你的方法final。

真的不能在定义明确的特定上下文之外调用您的方法吗？使您的方法private和/或考虑如何使所需的定义明确的上下文可用于通过另一个protected包装方法重用。

这就是为什么我主张private谨慎使用。并且不要private与之混淆final。-如果方法的实现对于该类的总协定至关重要，因此不能替换/重写该方法，请使用它final！

对于领域来说，private还算不错。只要可以通过适当的方法（不是 getXX()或setXX()！）合理地“使用”该字段。

您是否知道一个重要的用例，其中私有而不是受保护是一个很好的工具，或者两个选项“受保护和公共”对于OOP语言来说足够了吗？

私有的：当您拥有一些永远不会对任何子类调用或重写有用的东西时。

受保护的：当您的某些东西具有特定于子类的实现/常量时。

一个例子：

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}

我很难理解这个问题，所以我想分享一下我的经验：

• 什么是保护区？这是没有更多比一个领域，即不能在类的外部访问，即公开这样的：$classInstance->field。而这就是“就是这样”的窍门。您班上的孩子们将拥有全部使用权，因为这是他们合法的内部组成部分。
• 什么是私人领域？对于您自己的类和您自己的此类实现，这是一个“ 真正的私有 ” 。就像放在药瓶上一样，“不要让孩子接触”。你就有了保证，它是由你的类的衍生物，你的方法unoverridable -当所谓的-将有确切你声明什么

更新：我已经解决的实际任务的实际示例。这就是：您有一个令牌，例如USB或LPT（在我的情况下），并且您有一个中间件。令牌要求您输入密码，如果密码正确，则会打开，您可以发送加密的部分和一些要解密的密钥。密钥存储在令牌中，您无法读取它们，只能使用它们。并且有用于会话的临时密钥，由令牌中的密钥签名，但存储在中间件本身中。临时键不应泄漏到外部，而应存在于驱动程序级别。我使用一个专用字段来存储此临时密钥和一些与硬件连接有关的数据。因此，没有任何衍生工具不仅可以使用公共接口，还可以使用某些受保护的接口。我为某个任务制作的“方便”子例程，但是无法通过按键和硬件交互来打开保险箱。说得通？