Campos y propiedades en C#: ¿cuál es la diferencia y qué hay debajo del capó?

Campo y propiedad en C#: mitos, realidad y bytecode

Si alguna vez te has preguntado «What is the difference between a field and a property?» en C#, no estás solo. Es una de las preguntas más populares en Stack Overflow con miles de visitas. Para un principiante, la diferencia parece difusa: ambos almacenan datos. Pero debajo del capó, son dos mecanismos completamente diferentes. Analicemos de una vez por todas por qué una property no es solo un «campo con getter», sino una poderosa herramienta de encapsulación y contrato.

Este artículo no es documentación seca. Es un análisis vivo con ejemplos que puedes ejecutar ahora mismo. Abróchate el cinturón, será interesante.

¿Qué es un campo (field) en C#?

Un campo es una variable declarada directamente dentro de una clase o estructura. Almacena datos y no tiene ninguna lógica adicional al leerlos o escribirlos. El campo es un almacenamiento «crudo».

public class Person\n{\n    public string Name; // Esto es un campo\n}

Muy simple. Pero hay un matiz: si el campo es público, pierdes el control sobre cómo se accede a él. Cualquier código externo puede escribir cualquier cosa en él, y no podrás reaccionar a ello (por ejemplo, verificar la longitud de la cadena o llamar a un evento).

Problemas de los campos públicos

\n
• No hay control sobre la validación.
\n
• No se puede cambiar el comportamiento de lectura/escritura sin cambiar la API de la clase.
\n
• Es más difícil mantener la compatibilidad hacia atrás.
\n

Por eso, en una POO correcta, los campos públicos son casi siempre un antipatrón. En C#, para esto se inventaron las propiedades.

¿Qué es una propiedad (property) en C#?

Una propiedad es un miembro de una clase que se ve como un campo, pero en realidad es un par de métodos (accesores): get y set. Esta es precisamente la respuesta clave a la pregunta «What is the difference between a field and a property?». Una propiedad es azúcar sintáctico, detrás del cual se esconden métodos comunes.

public class Person\n{\n    private string _name; // Campo privado — campo de respaldo\n\n    public string Name // Propiedad\n    {\n        get { return _name; }\n        set { _name = value; }\n    }\n}

Cuando escribes person.Name = "Alice", el compilador de C# lo convierte en una llamada al método set_Name("Alice"). Y al leerlo, en una llamada a get_Name(). No lo ves, pero ocurre a nivel del código IL (lenguaje intermedio de .NET).

Propiedades automáticas (auto-implemented properties)

Para simplificar, en C# 3.0 aparecieron las propiedades automáticas. El compilador crea él mismo un campo de respaldo privado. El código se vuelve más corto, pero la funcionalidad es la misma.

public class Person\n{\n    public string Name { get; set; } // Propiedad automática\n}

A nivel de IL, esto sigue convirtiéndose en los métodos get_Name y set_Name con un campo privado. Sin magia, solo comodidad.

Diferencias clave entre campo y propiedad: tabla

Para fijarlo, aquí tienes una comparación visual. Esto te ayudará a responder rápidamente a la pregunta «field vs property C#» en una entrevista o en un proyecto real.

\n
• Encapsulación: El campo es solo una variable. La propiedad son métodos de acceso que pueden contener lógica.
\n
• Validación: En una propiedad se puede agregar una verificación en el setter. En un campo, no.
\n
• Notificaciones: En una propiedad es fácil llamar a un evento (por ejemplo, INotifyPropertyChanged). En un campo, se necesitaría refactorización.
\n
• Virtualidad: Las propiedades pueden ser virtuales, abstractas y sobrescribirse. Los campos, no.
\n
• Trabajo con hilos: En una propiedad se puede agregar un bloqueo (lock). En un campo, solo a través de medios externos.
\n
• Serialización: Los serializadores a menudo trabajan con propiedades, no con campos (especialmente si