Cómo la nueva palabra clave field mejora las propiedades de C#

Overview of C# Properties and the Upgrade in C# 14

Tim comienza explicando que hay una gran actualización en las propiedades de C# en C# 14. Deja en claro que el enfoque del video es la nueva palabra clave field, que afecta cómo funcionan internamente las propiedades automáticas. Tim también menciona que C# 14 se lanza junto a .NET 10 y Visual Studio 2026, aunque la característica en sí misma puede funcionar en versiones anteriores de .NET.

Él presenta el video como una explicación rápida y enfocada, diseñada para responder a una pregunta específica: ¿cómo usamos esta nueva característica en código real? Esto establece el tono para una guía práctica en lugar de una discusión teórica sobre la definición de propiedades.

El Ejemplo de la Clase Persona y las Propiedades Automáticas

Alrededor de las 0:23, Tim presenta una aplicación de consola con una clase pública simple llamada Person. Esta clase de persona contiene varias propiedades públicas, incluyendo:

• public string FirstName

• public string LastName

• public int Age

Tim explica que estas son propiedades implementadas automáticamente (también llamadas propiedades implementadas automáticamente). No hay variables privadas visibles ni campos privados porque el compilador crea automáticamente un campo secundario detrás de escena.

También incluye una propiedad Demo que no es auto-implementada. En su lugar, utiliza un campo de respaldo de tipo string privado (_demo) y expone una propiedad de solo lectura utilizando únicamente un accesor get. Este contraste se vuelve importante más adelante en el video.

Uso de propiedades en Program.cs

Tim luego pasa a la clase Program y muestra cómo se crea el objeto Person dentro de public static void main (o static void main string args, conceptualmente). Él instancia una nueva persona usando:

new Person { FirstName = "Tim", LastName = "Corey" }

Tim señala que las propiedades permiten el acceso fuera de la clase mientras siguen ocultando los miembros de datos privados. Él recupera valores como el apellido, la edad y la demostración, mostrando cómo las propiedades aparecen igual que los campos al ser accesadas, incluso aunque en realidad son métodos especiales en segundo plano.

El problema con valores inválidos en propiedades automáticas

Alrededor del 1:23, Tim asigna deliberadamente un valor no válido:

person.LastName = null;

Aunque se requiere LastName y no está marcado como nullable, la asignación aún funciona en tiempo de ejecución. Tim explica que las propiedades automáticas no protegen automáticamente contra valores no válidos. El compilador te advierte, pero el método set aún acepta el valor.

Esto demuestra un problema clave con las propiedades implementadas automáticamente: aunque son concisas, no proporcionan una manera incorporada de agregar validación. Los datos no válidos pueden pasar e infringir silenciosamente las suposiciones.

La propiedad completa tradicional con campo de respaldo

Alrededor de las 2:58, Tim muestra lo que los desarrolladores solían hacer en versiones anteriores de C#. Convierte LastName en una propiedad completamente implementada con:

• Un campo de respaldo privado de tipo string

Un accesor de establecimiento que verifica el valor de la propiedad

Una excepción lanzada por valores inválidos

Este enfoque ofrece un control total sobre los accesores de propiedades, pero Tim enfatiza lo verboso que se vuelve. La propiedad ahora ocupa varias líneas, en comparación con la sintaxis de una sola línea de las propiedades automáticas.

También explica que cambiar de una propiedad automática a una propiedad completa no rompe el código existente, ya que el nombre de la propiedad, el nivel de accesibilidad y el uso externo permanecen iguales.

La Nueva Palabra Clave field como un Punto Intermedio

A las 4:19, Tim introduce la mejora clave en C# 14. En lugar de escribir una propiedad completa, mantiene la estructura de la propiedad automática y modifica solo el accesor set utilizando la palabra clave field.

Tim explica que el campo representa el campo privado generado por el compilador que normalmente permanece oculto. Al asignar campo = valor, los desarrolladores ahora pueden interceptar y validar el valor de la propiedad sin declarar su propia variable privada.

Esto conserva la misma sintaxis a la que los desarrolladores están acostumbrados mientras añade flexibilidad. Tim destaca que esto reduce el código al tiempo que permite la lógica de validación, colocándolo entre propiedades automáticas y propiedades completas.

Campos de Respaldo con Alcance y Aislamiento de Propiedades

Tim explica que la palabra clave campo se limita a la propiedad donde aparece. Cada propiedad obtiene su propio campo de respaldo y no hay riesgo de interferencia entre propiedades.

Si se usa la misma sintaxis en otra propiedad, como FirstName, se refiere al propio campo de respaldo de esa propiedad. Esto hace que la función sea predecible y segura para usarse en múltiples propiedades públicas.

Validando Propiedades Numéricas Como Edad

Alrededor de las 6:16, Tim aplica el mismo enfoque a una propiedad pública int Edad. Él asigna un valor negativo no válido y explica por qué no debería permitirse.

En lugar de lanzar una excepción, Tim muestra una estrategia diferente: ignorar valores no válidos. El método set verifica si el valor está dentro de un rango válido antes de asignarlo al campo.

Esto demuestra que el nuevo enfoque funciona igualmente bien para int privado edad, validación numérica y lógica condicional, todo sin convertir la propiedad en una implementación completa.

Conflictos de Nombres con la Palabra Clave Campo

Luego Tim discute un caso particular potencial: conflictos de nombres. Si una clase ya contiene una variable llamada campo, puede entrar en conflicto con la nueva palabra clave dentro de propiedades.

Él demuestra cómo esto causa confusión y comportamiento inesperado. Tim explica que la solución es referenciar explícitamente la variable usando this.field o @field. Esto diferencia el nombre de la variable de la palabra clave del campo de respaldo.

Tim recomienda encarecidamente renombrar tales variables como una buena práctica, especialmente al actualizar bases de código existentes.

Dónde No Se Aplican Conflictos de Nombres

Tim aclara que la palabra clave campo solo tiene significado especial dentro de los accesores de propiedad. En constructores, métodos u otras partes de la clase, campo se comporta como una variable normal.

Esta distinción ayuda a los desarrolladores a entender cuándo existe el campo de respaldo generado por el compilador y cuándo no.

Comentarios Finales de Tim Corey

Tim concluye su video resumiendo cómo funciona la nueva palabra clave campo y por qué mejora las propiedades en C#. Permite a los desarrolladores seguir usando propiedades automáticas al tiempo que añade validación, control y claridad.

Él anima a los espectadores a probar la función, explorar cómo se ajusta a su estilo de codificación y pensar cuidadosamente sobre las convenciones de nombres. Tim cierra el video reforzando que este cambio hace que las propiedades sean más expresivas sin añadir complejidad innecesaria.