Menu
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,
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
458
Well, it's all one class, so you can access your own private members. If you don't want to update secret for example, just don't. Coding can't protect you from yourself. The definition of private says only instances of Foo can access it.
You can access private members from any code block that is defined in the same class. It doesn't matter what the instance is, or even if there is any instance (the code block is in a static context). But you cannot access them from code that is defined in a different class.
If a member is private (as in your case) you can either declare other classes as a friend of this class or write getters and setters. class A { private: int a; public: int GetA() { return a; } void SetA(int newA) { a = newA; } }; This however will grant access to your private data from every other place in your code.
The private modifier specifies that the member can only be accessed in its own class. The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.
This is "normal". Private members are private to the class, not to the particular instance.
61
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.
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
