Respuesta.

Historia de la pregunta

La encapsulación es uno de los pilares de la programación orientada a objetos, y se logra mediante modificadores de acceso como Private y Protected. En las versiones clásicas de Visual Basic, solo se admitían los niveles de visibilidad más simples, pero con la transición a VB.NET aparecieron mecanismos modernos similares a C#.

Problema

La tarea principal es aislar los detalles internos de la implementación del código externo, incluido el resto de la aplicación. Los errores típicos están relacionados con niveles de acceso incorrectos, intentos de acceder a campos y métodos fuera del ámbito de visibilidad permitido o una comprensión errónea del comportamiento de Protected y sus combinaciones con otros modificadores.

Solución

Se soportan los siguientes modificadores:

Private — acceso solo dentro de la clase/módulo actual
Protected — acceso dentro de la clase actual y todos los herederos (incluso desde otras ensambladuras)
Friend — acceso dentro de una misma ensambladura
Protected Friend — acceso dentro de herederos o dentro de la ensambladura

Ejemplo de código:

Public Class BaseClass
    Private Sub PrivateMethod()
        Console.WriteLine("PrivateMethod")
    End Sub
    Protected Sub ProtectedMethod()
        Console.WriteLine("ProtectedMethod")
    End Sub
    Friend Sub FriendMethod()
        Console.WriteLine("FriendMethod")
    End Sub
    Protected Friend Sub ProtectedFriendMethod()
        Console.WriteLine("ProtectedFriendMethod")
    End Sub
End Class

Public Class DerivedClass
    Inherits BaseClass
    Public Sub AccessMethods()
        'PrivateMethod() 'Error de compilación
        ProtectedMethod() 'Ok
        FriendMethod() 'Ok, si está en la misma ensambladura
        ProtectedFriendMethod() 'Ok
    End Sub
End Class

Características clave:

El modificador Private limita el ámbito de visibilidad a los límites de la clase
Protected funciona en todas las clases heredadas en cualquier ensambladura
Protected Friend combina ambas reglas

Preguntas engañosas.

¿Se puede acceder a un campo private desde una clase derivada?

No, los miembros private siempre son accesibles solo en la clase donde se declaran. La clase derivada no tiene acceso a los miembros private incluso a través de reflexión (a menos que se utilicen métodos no estándar).

¿Cuál es la diferencia entre Protected y Protected Friend?

Protected — accesible solo desde la clase y sus descendientes, incluso en otras ensambladuras; Protected Friend — accesible ya sea desde clases derivadas o desde cualquier código dentro de la misma ensambladura.

¿Se puede llamar a un método protected de la clase a través de una instancia de la clase base?

No, incluso si el método protected es públicamente visible dentro del heredero, no se puede llamar a él en una instancia de la clase base desde código externo. Los métodos protected solo son accesibles dentro del propio cuerpo de la clase o del heredero.

Errores comunes y anti-patrones

Abrir todos los métodos como public o friend para mayor rapidez
Usar campos protected donde deberían ser propiedades private
Violar la encapsulación debido a un acceso excesivamente amplio

Ejemplo de la vida real

Caso negativo

Un desarrollador, para simplificar las pruebas, hace que los campos internos sean public para poder acceder a ellos directamente desde el código externo o pruebas unitarias. Con el tiempo, otras llamadas comienzan a utilizar estos campos, confiando en su estructura interna.

Pros:

Pruebas rápidas
Menos código para acceder

Contras:

Baja encapsulación
Aumento de errores con cambios en la implementación interna
Dificultad para modificar la clase

Caso positivo

Se aplican claramente modificadores de acceso, todos los campos son private por defecto, y el acceso externo es solo a través de propiedades y métodos públicos. Para las necesidades de pruebas, se utilizan interfaces o clases amigas en la misma ensambladura.