Gracias por tu artículo. En mi opinión, este es otro de los ejemplos en que "una vez que lo sabes" está claro que ahorras código pero hay que pensar en el que llega por primera vez al curso y no tiene ni idea de C#, en ese caso, las convenciones quizás le puedan liar más que ayudar. Yo lo que haría sería en la parte del curso en que se hable de ello, añadir esta información para que quien quiera usarlo sepa que puede pero yendo de lo más básico a lo más complejo. Otro tema sería cuando tienes un post sobre algo más avanzado, quizás en ese punto sí que te puedes arriesgar a usar primary constructor porque se entiende que quien está en ello, lo sabe y si no es así siempre puedes añadir un enlace a esa parte.
@uliseslopez724811 ай бұрын
Mi más sincera admiración, bien explicado y buenos ejemplos. Muchas gracias,.
@ArturoNull11 ай бұрын
¡Muchas gracias!
@PittZahott11 ай бұрын
Para "conservar" el private readonly se pueden declarar los campos a nivel de clase como private readonly (con la nomenclatura deseada) y asignarles el valor del primary constructor, así dentro de los métodos ya solo puedes usar los campos a nivel clase y no los del primary constructor.
@brandonmanuelventuraumana10357 ай бұрын
Como mencionas el problema de los primary constructors es que los parámetros recibidos por el constructor son mutables y no hay forma ni restricción del lenguaje para indicar lo contrario y tratarlos como un miembro de la clase, por lo que, en realidad lo ideal hasta que haya el soporte suficiente por la especificación, es tratar los parámetros del constructor primario como lo que son, parámetros, por lo tanto, la nomenclatura del nombre sería camelCase, y su uso es el uso regular de los constructores convencionales, solamente para inicializar los miembros de la clase, con la diferencia que estos parámetros pueden ser globales, pero para evitar problemas debido a su mutabilidad no deberían ser utilizados en cualquier otro lugar o propósito dentro de la clase salvo cosas triviales, porque esto puede ocasionar más problemas que soluciones. Yo quizá utilizaría el mixto recomendado hasta que haya soporte en C# para indicar que el parámetro sea de solo lectura o se trate como un campo de la clase por detrás, que sería el constructor primario con sus parámetros y su correspondiente inicialización de campos de la clase más que todo para el caso de la inyección de dependencias: public class MyType(SomeDependency someDependency){ private readonly SomeDependency _someDependency = someDependency; } De esta forma, se obtiene lo mejor de ambos mundos y aunque no es tan limpio como solo definir el constructor primario, evitamos cualquier cosa inesperada que pudiera ocurrir con el parámetro siendo mutado en cualquier parte de la clase, lo único que esto quizá pueda ser aún más confuso, pero bueno, es lo que hay, yo empecé utilizando los parámetros alrededor de la clase sin pensar en esto (porque precisamente así está la documentación) para inyectar las dependencias, pero me estoy moviendo a la forma comentada anteriormente, más que todo para asegurar que el código sea seguro y consistente a lo largo de su ejecución y su propósito quede claro para otras personas.
@diegoimberti439811 ай бұрын
Muy “bonito” el código reducido…: pero y si queremos meterle Dataanotations?
@NetMentor11 ай бұрын
en ese caso no puedes, porque hay algunas que si se pueden usar, pero no todas, asi que mejor no hacerlo con priary constructors
@josephmoreno973311 ай бұрын
La barra baja no es adecuada porque en realidad no es un campo de instancia, sino una variable del scope (asumo que por detrás hay un campo de instancia, igual que las pripiedades) se confunde más con campos estáticos, en realidad. Pienso que con un atributo [ReadOnly] debería bastar para lograr dicho efecto. Piensa en este ejemplo, acá se fuerza a crear un campo de instancia pero se pierde el sentido del constructor primario. public class Clase(in String parametroEntrada) { private String _campo = parametroEntrada; public String Propiedad { get => this._campo; set => this._campo = value; } }