public class Foo
{
private bool aBool;
public void DoBar(Foo anotherFoo)
{
if (anotherFoo.aBool) ...
}
}
根据C#规范（3.5.1，3.5.2章节）所述，私有字段的访问是基于类型而非实例。我正在与同事讨论这个问题，并试图找出它为什么会这样工作的原因（而不是限制对同一实例的访问）。
我们得出的最佳论据是在相等性检查方面，类可能想要访问私有字段以确定与另一个实例的相等性。还有其他原因吗？或者有一些绝对意味着它必须像这样工作的黄金理由，否则某些事情将完全不可能吗？
我认为其原因之一是因为访问修饰符在编译时起作用。因此，确定给定对象是否也是当前对象并不容易。例如，请考虑以下代码：
public class Foo
{
private int bar;
public void Baz(Foo other)
{
other.bar = 2;
}
public void Boo()
{
Baz(this);
}
}
other实际上是this？并非所有情况都是如此。有人可能会说，这样就不应该编译了，但这意味着我们有一条代码路径，其中不能访问正确实例的私有成员，我认为这甚至更糟糕。this来访问？this.bar = 2 而不允许 other.bar = 2，因为 other 可能是不同的实例。 - Daniel HilgarthC#和类似语言中使用的封装的目的是降低代码中不同部分（在C#和Java中是类）之间的相互依赖，而不是内存中不同对象之间的依赖关系。
例如，如果你在一个类中编写代码来使用另一个类中的一些字段，那么这些类之间就会非常紧密地耦合。然而，如果你处理的是你有两个同一类的对象的代码，那么就没有额外的依赖关系了。一个类总是依赖于它自己。
然而，所有这些关于封装的理论都失败了，只要有人创建属性（或者在Java中使用get/set对）并直接公开所有字段，这将使得类像访问字段一样紧密耦合。
*关于封装类型的澄清，请参见Abel的优秀回答。
Foo的实例访问其他实例的私有成员，那么会创建一个依赖关系，任何期望Foo的对象都需要具有这些内部成员的对象，即使它实际上并不关心它们。如果使用类似于Foo.Create()而不是new Foo()这样的东西来创建Foo的实例，则Foo不必具有任何内部成员；创建的东西可以是从Foo派生的ConcreteFoo，但不一定是唯一可以这样做的类。 - supercat这个有趣的主题已经有了很多答案，但我并没有找到真正的原因为什么会出现这种行为。让我试试：
在80年代的Smalltalk和90年代中期的Java之间，面向对象编程的概念得到了成熟。信息隐藏最初并不是面向对象的概念（首次提出于1978年），在Smalltalk中作为一个类的所有数据（字段）都是私有的，所有方法都是公共的。在90年代的众多面向对象开发中，Bertrand Meyer试图在他的里程碑式著作Object Oriented Software Construction (OOSC)中形式化大部分面向对象的概念和语言设计，此书自那时以来一直被认为是（几乎）确定性的面向对象概念和语言设计参考。
根据Meyer的说法，应该将方法提供给一组定义好的类（第192-193页）。这显然提供了非常高的信息隐藏粒度，以下功能可用于classA和classB及其所有后代：
feature {classA, classB}
methodName
private的情况下，他说：如果没有将类型明确声明为对其自身类可见，则无法在限定调用中访问该功能（方法/字段）。也就是说，如果x是一个变量，则不允许x.doSomething()。当然，在类本身内部允许不受限制的访问。private的意思是："仅对此实例私有"。doSomething()，但不允许x.doSomething()，那么语言设计者就有效地为私有方法和字段定义了仅实例可访问性。Foo的定义有效地表示了一个接口和一个实现类；由于COM没有类对象引用的概念——只有接口引用——因此，类无法持有对保证是该类的另一个实例的引用。这种基于接口的设计使得某些事情变得繁琐，但它意味着可以设计一个可替换另一个类的类，而不必共享任何相同的内部内容。 - supercat仅代表我的观点，但实际上，如果程序员可以访问类的源代码，你可以合理地相信他们可以访问类实例的私有成员。为什么要限制程序员的权利，当你已经将王国的钥匙放在他们的左手中了呢？
事实上，原因在于等值检查、比较、克隆和运算符重载...例如，在复数上实现operator+会非常棘手。
public class StringBuilder
{
private string chunk;
private StringBuilder nextChunk;
}
ToString方法:public override string ToString()
{
return chunk + nextChunk.ToString();
}
StringBuilder类的初衷。如果你可以访问自己类的其他实例的私有成员，你可以通过创建正确长度的字符串，然后将每个块的不安全复制到字符串的适当位置来实现ToString：public override string ToString()
{
string ret = string.FastAllocateString(Length);
StringBuilder next = this;
unsafe
{
fixed (char *dest = ret)
while (next != null)
{
fixed (char *src = next.chunk)
string.wstrcpy(dest, src, next.chunk.Length);
next = next.nextChunk;
}
}
return ret;
}
这个实现是O(n)的，非常快，只有在您可以访问其他实例私有成员的情况下才能实现。
我认为我们可以增加另一层隐私保护，使数据对每个实例都是私有的。事实上，这可能会为语言提供一种完整感。
但在实际应用中，我怀疑它是否真的有那么有用。正如你所指出的，通常的私密性对于诸如平等检查以及涉及多个类型实例的大多数其他操作非常有用。虽然，我也喜欢你提到的维护数据抽象的观点，因为这是面向对象编程中的一个重要点。
总的来说，提供以这种方式限制访问的能力可能是添加到面向对象编程中的一个很好的特性。它真的有那么有用吗？我会说不是，因为一个类应该能够信任自己的代码。由于该类是唯一可以访问私有成员的东西，因此在处理另一个类的实例时没有真正需要数据抽象的原因。
当然，您始终可以将代码编写为如果private应用于实例。使用通常的get/set方法来访问/更改数据。如果该类可能会受到内部更改的影响，则这可能会使代码更易于管理。
以上给出了很好的答案。我想补充一点，这个问题的一部分在于类内部实例化自身甚至被允许。例如，在递归逻辑“for”循环中使用这种技巧是有意义的，只要您有逻辑来结束递归。但是，在没有创建这样的循环的情况下实例化或传递相同的类内部会在逻辑上创建自己的危险，尽管这是一个被广泛接受的编程范例。例如，C#类可以在其默认构造函数中实例化自身的副本，但这不会违反任何规则或创建因果循环。为什么？
顺便说一句...这个问题也适用于“protected”成员。:(
我从未完全接受过这种编程范例，因为它仍然带来了一整套问题和风险，大多数程序员直到像这个问题一样的问题出现并困惑人们并违背了拥有私有成员的整个原因时才能完全掌握。
C#的这种“奇怪而古怪”的方面是好的编程与经验和技能无关，而只是知道诀窍和陷阱......就像修车一样。这是规则被打破的论点，这对于任何计算语言来说都是一个非常糟糕的模型。
在我看来，如果数据对于同一类型的其他实例是私有的，那么它就不再是相同的类型了。它似乎不会像其他实例那样表现或行为相同。基于私有内部数据，行为可以很容易地进行修改。在我看来，这只会带来混乱。
笼统地说，我个人认为编写从基类派生的类提供了与“每个实例具有私有数据”所描述的类似功能。相反，您只需针对“唯一”的类型拥有一个新的类定义。