tag - Propiedades en c#en Unity(Unity5): ¿puede evitar la variable de respaldo?

unity tag

Question

Con Unity5 (es difícil saber exactamente qué versión de c # / Mono / .Net se está utilizando), hacemos propiedades exactamente así:

private int _distance;
public int Distance
    {
    private set
        {
        _distance = value;
        controls.Blahblah(_distance);
        }
    get
        {
        Debug.Log("hah!);
        return _distance;
        }
    }

Pero considere las nuevas "propiedades automáticas" en c #, que parecen ser similares

 public int Distance {get; set;}   // ?

pero no sé cómo "hacer algo" en el getter / setter ??

O, en otras palabras, ¿hay alguna manera de generar automáticamente la variable de respaldo (así como la conveniencia, para mantenerla privada) cuando se hace una propiedad "manualmente"?

Para repetir, ya que esto se marcó como un duplicado, ¿cómo puedo "hacer cosas" en el idioma automático de la propiedad durante el getter / setter ...

... o por el contrario ...

¿Cómo esconderse, deshacerse de, o proporcionar automáticamente el respaldo si escribe sus propias propiedades "manuales"?

Tenga en cuenta que, por supuesto, usted u otro programador pueden tocar accidentalmente la variable de respaldo _underscore: ¿hay alguna manera de evitar eso?

Answer 1

Las propiedades automáticas no le permiten hacer ''nada'' en ellas. Son simplemente una abreviatura de:

public int Distance
{
    get
    {
        return _distance;
    }
    set
    {
        _distance = value;
    }
}
private int _distance = default(int);

No hay nada de malo con el uso de una variable real en esta propiedad, no afectará nada.

Sin embargo, una cosa a tener en cuenta es que si desea editar una variable en el editor, no puede usar una propiedad. Deberá exponer un campo público:

public int Distance;

Answer 2

No puede usar propiedades automáticas si desea "hacer algo" en el getter / setter, además de solo asignar al campo. Para el caso de uso descrito por su código de ejemplo, las propiedades automáticas no son una opción. No tiene nada de malo tener un campo de respaldo explícito.

Answer 3

Si solo tiene la variable privada sin otra lógica, entonces puede usar las propiedades Auto.

Class Something something
{
    public int Distance
    {
    private set
     {
       _distance = value;
     }
    get
     {
       return _distance;
     }
    }

// Keep this at the end of the class
// In visual studio you can collapse region and wont attract
// attention/distracting in your editor.

#region data members
private int _distance;
#endregion data members
}

puedes reemplazarlo con public int Distance {get; set;} public int Distance {get; set;}

Pero si realiza otras acciones como el registro, entonces debe escribirlo de manera tradicional.

Editar

Es toda la práctica de codificación. En general, adjunto las variables privadas en una #region p ...#endregion . Y use solo las Propiedades para configurar - Distancia y nunca haya usado _distance. Es más una práctica de codificación que una solución real para lo que estás haciendo.

Una razón más por la que hago eso es: en WPF necesitaríamos llamar al evento NotifyPropertyChanged siempre que establezcamos las propiedades. Será un error si no uso el nombre de la propiedad. Entonces, este hábito de usar propiedades sobre variables privadas está atascado.

No se puede hacer que la variable sea imposible de descubrir, solo se agrupan para facilitar la lectura y sí, esta es una práctica aplicada por los humanos.

Answer 4

Si su get y set necesita tener un código adicional como el que tiene para iniciar sesión, debe implementarlos de la manera en que lo hizo en primer lugar, si solo necesita obtener y establecer el valor, entonces las propiedades implementadas automáticamente son mejores, me refiero al segundo enfoque. .