Ir al contenido principal

Modificadores de acceso c#

En C#, los modificadores de acceso se utilizan para controlar la visibilidad y accesibilidad de clases y sus miembros (campos, métodos, propiedades, etc.).

1. public: El miembro es accesible desde cualquier parte del código, tanto dentro de la misma clase como desde otras clases que estén en el mismo ensamblado o en ensamblados diferentes.

   
    public class MiClase
    {
        public int MiVariable;
        public void MiMetodo() { }
    }
    

2. private: El miembro es accesible solo dentro de la clase en la que se define. No es accesible desde clases externas ni desde otras partes del código.

    
    public class MiClase
    {
        private int MiVariable;
        private void MiMetodo() { }
    }
    

3. protected: El miembro es accesible dentro de la clase que lo define y en las clases derivadas (subclases). No es accesible desde clases externas a menos que sea una subclase.

    Q
    public class MiClase
    {
        protected int MiVariable;
        protected void MiMetodo() { }
    }

    public class MiClaseDerivada : MiClase
    {
        public void OtroMetodo()
        {
            MiVariable = 10; // Acceso permitido porque MiClaseDerivada es una subclase de MiClase
            MiMetodo();      // Acceso permitido por la misma razón
        }
    }
    

4. internal: El miembro es accesible solo dentro del mismo ensamblado (assembly). Es decir, otras clases que estén en el mismo proyecto pueden acceder a este miembro, pero no clases externas.

    
    internal class MiClase
    {
        internal int MiVariable;
        internal void MiMetodo() { }
    }
    

5. protected internal: Este modificador combina las características de `protected` e `internal`. El miembro es accesible en las clases derivadas (subclases) dentro del mismo ensamblado.

    
    public class MiClase
    {
        protected internal int MiVariable;
        protected internal void MiMetodo() { }
    }

    public class MiClaseDerivada : MiClase
    {
        public void OtroMetodo()
        {
            MiVariable = 10; // Acceso permitido porque MiClaseDerivada es una subclase de MiClase
            MiMetodo();      // Acceso permitido por la misma razón
        }
    }
    

6. private protected: Introducido en C# 7.2, este modificador es similar a `protected`, pero restringe aún más el acceso a las clases derivadas (subclases) solo dentro del mismo ensamblado.

    
    public class MiClase
    {
        private protected int MiVariable;
        private protected void MiMetodo() { }
    }

    public class MiClaseDerivada : MiClase
    {
        public void OtroMetodo()
        {
            MiVariable = 10; // Acceso permitido porque MiClaseDerivada es una subclase de MiClase
            MiMetodo();      // Acceso permitido por la misma razón
        }
    }
   

Comentarios

Entradas populares de este blog

De Coverlet a JaCoCo: Trayendo la magia de la cobertura a Android Studio

Todo comenzó un día cualquiera, mientras revisaba un reporte de cobertura de pruebas generado por Coverlet para un proyecto en .NET. Me quedé fascinado por el nivel de detalle y claridad que proporcionaba: saber exactamente qué partes del código estaban cubiertas por las pruebas, y cuáles no. Fue entonces cuando me pregunté: ¿Y si pudiera tener algo así en mi proyecto de Android con Kotlin y Jetpack Compose? La Chispa Inicial ✨ Como desarrollador, siempre busco mejorar la calidad de mi código, y contar con herramientas que me permitan medir la cobertura de pruebas es clave. Después de una rápida búsqueda, me topé con **JaCoCo**, una herramienta muy popular para medir cobertura de código en proyectos Java y Kotlin. ¡Lo mejor de todo es que es compatible con Android Studio! Mi objetivo estaba claro: debía integrar JaCoCo en mi proyecto de Android para tener reportes detallados de cobertura, tal como lo había visto en Coverlet. El Desafío: Configurar JaCoCo en un Proyecto Android 🛠️ El p...

Guía Definitiva de Estrategias de Branching en Git: Elige la Mejor para tu Equipo

Imagina esta situación: lideras un equipo de desarrollo y todos están enviando código al mismo tiempo. Sin una estrategia de ramas (branching) clara, tu base de código se convierte rápidamente en un caos de conflictos, compilaciones rotas y desarrolladores frustrados. ¿Te suena familiar? Si alguna vez te has encontrado en este lío, no estás solo. Una estrategia de branching en Git es el mapa que tu equipo necesita para gestionar los cambios de código, colaborar de manera efectiva y entregar software de calidad. Es, en esencia, un conjunto de reglas que define cómo los desarrolladores interactúan con el repositorio, cuándo crear ramas, cómo fusionar cambios y cómo mantener la estabilidad del código en todo el ciclo de vida del desarrollo. Pero es más que solo reglas. Una buena estrategia de branching se alinea con la forma en que trabaja tu equipo: tus ciclos de lanzamiento, los flujos de trabajo de QA, tus pipelines de CI/CD e incluso la frecuencia con la que necesitas aplicar correcc...

Inyección de Dependencias usando Hilt

Inyección de Dependencias usando Hilt La Inyección de Dependencias (DI) es fundamental para construir aplicaciones Android robustas, escalables y fáciles de testear. Mientras que existen varias librerías para lograrlo, Hilt se ha establecido como la solución recomendada y estándar de Google. Construido sobre la potencia de Dagger, Hilt simplifica enormemente la implementación de DI en Android. Si buscas una forma estandarizada, con menos boilerplate que Dagger puro y con excelente integración con los componentes de Android Jetpack, Hilt es la respuesta. ¡Descubramos cómo funciona! ¿Por qué elegir Hilt? Hilt ofrece ventajas significativas para el desarrollo Android: Estándar de Android: Es la librería DI recomendada por Google, lo que asegura buena documentación, soporte y alineación con las prácticas modernas de Android. Menos Boilerplate (vs. Dagger): Reduce drásticamente el código de configuración necesario en comparación con usar Dagger directamente en Andr...