В.NET, почему я могу получить доступ к членам парламента, не занимающим официального поста экземпляра класса в классе?
При очистке некоторого кода сегодня, написанного кем-то еще, я изменил модификатор доступа от Public кому: Private на переменной класса/member/field. Я ожидал длинный список ошибок компилятора, которые я использую для "осуществления рефакторинг/переделывания/рассматривания" кода, который использовал эту переменную. Вообразите мое удивление, когда я не получил ошибок. После рассмотрения оказывается, что другой экземпляр Класса может получить доступ к членам парламента, не занимающим официального поста другого экземпляра, объявленного в Классе. Полностью неисключенный.
Действительно ли это нормально? Я кодирование в.NET с начала и никогда не сталкивалось с этой проблемой, ни читайте об этом. Я, возможно, споткнулся на него прежде, но только "неопределенно замеченный" и движение. Кто-либо может объяснить этот behavoir мне? Я хотел бы знать, "почему" я могу сделать это. Объясните, только скажите мне правило. Я делаю что-то не так? Я нашел это поведение и в C# и в VB.NET. Код, кажется, использует в своих интересах способность получить доступ к частным переменным. Недостаток является программистом, создал большую тарелку Спагетти.
С уважением,
- Полностью перепутанный
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
4 ответа
Это "нормально". Private члены являются приватными для класса, а не для конкретного экземпляра.
Это ожидаемое поведение. Вложенные классы могут обращаться к закрытым членам класса-контейнера.
Проблема доступа заключается в том, где код обращается к закрытым членам, а не столько в том, через что он обращается к ним.
У вас есть доступ к полю _foo._int в определении класса Foo , но не за его пределами.
Вас может также удивить то, что следующее расширение вложенного класса Fred также допустимо.
Private Class Fred
Private _int As Integer
Private Sub Blah(ByVal foo As Foo)
foo._int = 9
End Sub
End Class
Вы сказали:
Пожалуйста, объясните, а не просто говорите мне правило.
Вот мои два цента.
На мой взгляд, предпосылка частных членов класса состоит в том, что класс может внутренне знать о своей собственной реализации, не подвергая эту реализацию внешнему миру. Таким образом, один экземпляр класса вполне способен понять, как реализован другой экземпляр того же класса; поэтому он не ограничен в использовании этих знаний о реализации.
Что касается примеров, манипулирующих друг другом, я признаю, что это несколько необычно. Но возьмем, к примеру, статические методы построения. Не могли бы вы также запретить им доступ к закрытым членам экземпляров? Если это так, то вы сделали невозможным использование большого количества полезного кода. В противном случае непонятно, почему статические методы должны иметь доступ к закрытым членам, а методы экземпляра - нет.
Другими словами, слово «частный» в ООП не предназначено для передачи идеи личной жизни , как если бы люди скрывались друг от друга. Скорее, думайте о классе как о «клубе только для членов» , где есть определенные способы делать вещи, о которых знают только члены клуба.