Obviamente siempre que se herede de una clase se tendrá total acceso en la clase hija –e implícitamente sin necesidad de usar la sintaxis <objeto>.<miembro>- a los miembros que ésta herede de su clase padre, como muestra el siguiente ejemplo:

using System; class A {  protected int x=5; } class B:A {  B()  {   Console.WriteLine("Heredado x={0} de clase A", x);  }    public static void Main()  {   new B();  } }

Como es de esperar, la salida por pantalla del programa de ejemplo será:

Heredado x=5 de clase A

A lo que no se podrá acceder desde una clase hija es a los miembros protegidos de otros objetos de su clase padre, sino sólo a los heredados. Es decir:

using System; class A {  protected int x=5; } class B:A {  B(A objeto)  {   Console.WriteLine("Heredado x={0} de clase A", x);   Console.WriteLine(objeto.x); // Error, no es el x heredado  }    public static void Main()  {   new B(new A());  } }

• private: Sólo puede ser accedido desde el código de la clase a la que pertenece.     Es lo considerado por defecto.
• internal: Sólo puede ser accedido desde código perteneciente al ensamblado en que se ha definido.
• protected internal: Sólo puede ser accedido desde código perteneciente al ensamblado en que se ha definido o          desde clases que deriven de la clase donde se ha definido.

    Si se duda sobre el modificador de visibilidad a poner a un miembro, es mejor ponerle inicialmente el que proporcione menos permisos de accesos, ya que si luego detecta que necesita darle más permisos siempre podrá cambiárselo por otro menos restringido. Sin embargo, si se le da uno más permisivo de lo necesario y luego se necesita cambiar por otro menos permisivo, los códigos que escrito en base a la versión más permisiva que dependiesen de dicho miembro podrían dejar de funcionar por quedarse sin acceso a él.

    Es importante recordar que toda redefinición de un método virtual o abstracto ha de realizarse manteniendo los mismos modificadores que tuviese el método original. Es decir, no podemos redefinir un método protegido cambiando su accesibilidad por pública, pues si el creador de la clase base lo definió así por algo sería.

    Respecto a los tipos de datos, por defecto se considera que son accesibles sólo desde el mismo ensamblado en que ha sido definidos, aunque también es posible modificar esta consideración anteponiendo uno de los siguientes modificadores a su definición:

• public: Es posible acceder a la clase desde cualquier ensamblado.
• internal: Sólo es posible acceder a la clase desde el ensamblado donde se declaró. Es lo considerado por defecto.

    También pueden definirse tipos dentro de otros (tipos internos) En ese caso serán considerados miembros del tipo contenedor dentro de la que se hayan definido, por lo que les serán aplicables todos los modificadores válidos para miembros y por defecto se considerará que, como con cualquier miembro, son privados. Para acceder a estos tipos desde código externo a su tipo contenedor (ya sea para heredar de ellos, crear objetos suyos o acceder a sus miembros estáticos), además de necesitarse los permisos de acceso necesarios según el modificador de accesibilidad al definirlos, hay que usar la notación <nombreTipoContendor>.<nombreTipoInterno>, como muestra en este ejemplo:

// No lleva modificador, luego se considera que es internal class A { //  Si ahora no se pusiese public se consideraría private  public class AInterna {}  } //  B deriva de la clase interna AInterna definida dentro de A. //  Es válido porque A.AInterna es pública class B:A.AInterna      {}

    Nótese que dado que los tipos externos están definidos dentro de su tipo externo, desde ellos es posible acceder a los miembros estáticos privados de éste. Sin embargo, hay que señalar que no pueden acceder a los miembros no estáticos de su tipo contenedor.