In .NET, Why Can I Access Private Members of a Class Instance within the Class?

Question

While cleaning some code today written by someone else, I changed the access modifier from Public to Private on a class variable/member/field. I expected a long list of compiler errors that I use to "refactor/rework/review" the code that used this variable. Imagine my surprise when I didn't get any errors. After reviewing, it turns out that another instance of the Class can access the private members of another instance declared within the Class. Totally unexcepted.

Is this normal? I been coding in .NET since the beginning and never ran into this issue, nor read about it. I may have stumbled onto it before, but only "vaguely noticed" and move on. Can anyone explain this behavoir to me? I would like to know the "why" I can do this. Please explain, don't just tell me the rule. Am I doing something wrong? I found this behavior in both C# and VB.NET. The code seems to take advantage of the ability to access private variables. The disadvantage is the programmer created a big plate of Spaghetti.

Sincerely,

• Totally Confused

---

Class Jack
    Private _int As Integer
End Class
Class Foo
    Public Property Value() As Integer
        Get
            Return _int
        End Get
        Set(ByVal value As Integer)
            _int = value * 2
        End Set
    End Property
    Private _int As Integer
    Private _foo As Foo
    Private _jack As Jack
    Private _fred As Fred
    Public Sub SetPrivate()
        _foo = New Foo
        _foo.Value = 4  'what you would expect to do because _int is private
        _foo._int = 3   'TOTALLY UNEXPECTED
        _jack = New Jack
        '_jack._int = 3 'expected compile error 
        _fred = New Fred
        '_fred._int = 3 'expected compile error 
    End Sub
    Private Class Fred
        Private _int As Integer
    End Class
End Class

Answer 1

This is "normal". Private members are private to the class, not to the particular instance.

Answer 2

You said:

Please explain, don't just tell me the rule.

Well, here's my two cents.

As I see it, the premise of private members of a class is that a class may internally be aware of its own implementation without exposing that implementation to the outside world. Thus one instance of a class is perfectly capable of understanding the way another instance of the same class is implemented; so it is not restricted from taking advantage of that implementation knowledge.

As for instances manipulating each other, I will concede this is somewhat unusual. But take for example static construction methods. Would you also restrict these from accessing instances' private members? If so, you've rendered a lot of useful code impossible. If not, it's unclear why static methods should be able to access private members but instance methods shouldn't.

In other words, the word "private" in OOP is not meant to convey the idea of personal privacy, as in individuals hiding from one another. Rather, think of a class as more of a "members only" sort of club, where there are certain ways of doing things that only members of the club know about.

Answer 3

The issue of access is about where the code is accessing the private members and not so much about what it is accessing them through.

You have access to the _foo._int field in the definition of the Foo class, but not outside of it.

It may surprise you further that the following extension to the nested Fred class is also legal.

Private Class Fred
    Private _int As Integer
    Private Sub Blah(ByVal foo As Foo)
        foo._int = 9
    End Sub
End Class

Answer 4

This is expected behavior. Nested classes can access private members of the container class.