Uso de properties de C# en contexto de Clean Code

[EduardoCaceres5566]

Hola,

En C# existe el concepto de Auto-Implement Properties doc.

En el proyecto, esto significa que para una data structure la forma correcta de generar un getter o setter según C# es hacer:

public Unit UnitInstance {get; set;}

Donde eso crea automáticamente un field privado _unitinstance y también crea el Getter UnitInstance y el Setter UnitInstance. ¿Es correcto usar esto o tenemos que crear un método que se llame GetUnitInstance() igual?

¿Si en lo anterior está bien usar properties para data structures, en los objetos sí tendría que agregar un método si quisiera entregar algún dato calculado desde los datos internos del objeto? O podria hacer algo como:

public double Hours
    {
        get { return _seconds / 3600; }
        set
        {
            if (value < 0 || value > 24)
                throw new ArgumentOutOfRangeException(nameof(value),
                      "The valid range is between 0 and 24.");

            _seconds = value * 3600;
        }
    }

doc

[RodrigoToroIcarte]

Sí, no hay problema con usar auto-implemented properties en el proyecto. De hecho las usamos para leer los jsons.

En objetos hay que ser un poco más cuidadosos en el sentido de que un objeto busca esconder sus atributos. Agregar un auto-implemented property es una forma muy abierta de exponer tus atributos. Eso no quita que podría estar bien. Todo depende del contexto. Así que te recomiendo tener un poco de cuidado con eso. Si lo haces, ten un buen motivo para tener esa property en ese objeto :)

[EduardoCaceres5566]

En mis objectos si quiero tener un campo privado que solo se accede adentro de la instancia, esta bien crear un auto property privada, para no tener que crear atributos como _name manualmente?

private string Name {set;}

vs

private string _name;

[RodrigoToroIcarte]

¿Ganas algo con tener un property privado vs hacer el atributo privado?

Yo haría el atributo privado no más. No veo el punto de crear un property privado para que me autogenere un atributo privado por debajo. Aunque puede que en tu caso sí tenga una ventaja que no estoy viendo :thinking:

[EduardoCaceres5566]

Supongo que lo único que gano es si quiero agregar alguna lógica al setter/getter en el futuro. Tambien puedo hacer las variables readonly, osea que no se puedan cambiar, sin tener que especificar readonly en cada variable que encuentro que es un mejor default.

Ahora mismo lo veo más porque no pierdo nada y ya lo tengo escrito, así entonces quería saber si se considera malo, ya que es más de convención que de correctitud.

[RodrigoToroIcarte]

Ya veo. Es una pregunta interesante. Los properties se usan cuando uno quiere hacer público un atributo (ya sea por su método get o set). Tener un property privado en vez de un atributo privado es muy extraño. Rompe las expectativas de cualquiera que lea tu código. Al igual que yo, se preguntarán por qué es un property y no un atributo.

Si tienes código en tu método set lo van a entender. Pero si no lo tienes, será extraño. Y romper las expectativas de quien lee tu código es una señal de que no es un código limpio.

Dicho eso, al menos en la E2, no te deberíamos descontar por eso. Aunque, claro está, todo depende del contexto. Podría ser que te descontemos por otro motivo que se relacione con ese property. Pero no será bajo el argumento de que "ese property debió ser un atributo privado".