: this() Como constructor

Estoy tratando de obtener una mejor comprensión de la práctica general ... derivando específicamente esto() en un constructor. Entiendo que es menos código, pero lo considero menos legible. ¿Es una práctica común/buena hacerlo de esta manera? ¿O es mejor escribir un segundo constructor que lo maneje específicamente?: this() Como constructor

public SomeOtherStuff(string rabble) : this(rabble, "bloop") { }

Public SomeOtherStuff(string rabble) 
{ 
    //set bloop 
}

Cualquier entrada sería muy apreciada

Fuente

2010-08-19 Aardvark

'this()' es una buena forma de tener auto-propiedades en un tipo de estructura y aún así permitir que se establezcan en un constructor parametrizado. Sin el 'this()', requiere que use campos de respaldo explícitos. –

@ Dan: ¡Eso es genial, nunca pensé en eso!¡En el futuro usaré 'this()' en estructuras que tienen auto-propiedades! ¡Gracias! – Timwi

Es una buena práctica usar this() siempre que sea posible. De lo contrario, estará duplicando algún código, lo que viola el principio DRY (No repetir). El problema con la repetición es que cada vez que necesita realizar un cambio, aunque sea un simple cambio en una sola línea de código, debe recordar para hacer el cambio mismo en varios lugares, y mantener el múltiplo copias sincronizadas

Solo debe "duplicar" el código cuando lo necesite porque debe ser diferente, por lo que ya no es un duplicado. De esta forma, tener un duplicado es un mensaje para el lector de que el código es realmente diferente, y lo es por una razón.

Fuente

2010-08-19 17:40:38 Timwi

Gran respuesta y eso definitivamente aclara mi pregunta. No había visto el principio DRY y creo que mejorará mi código en todos los ámbitos. ¡Gracias! – Aardvark

me importa menos acerca de la legibilidad y más para la fiabilidad.

Encadenar constructores es mucho mejor que copiar cuerpos de métodos de constructor.

Fuente

2010-08-19 17:39:08 Will

Acepto que encadenar constructores es mejor que copiar código. La legibilidad, sin embargo, es muy importante. En este caso, creo que encadenar constructores es más legible y mucho más confiable. Pero como afirmación general, "no preocuparse" por la legibilidad es una práctica peligrosa de la OMI. –

@foo ¿Buggy y legible u oscuro pero confiable? Por supuesto, no siempre es una situación cualquiera, pero si tiene la opción de hacer una u otra, mejor la otra. Además, el código más ilegible se vuelve más comprensible con la aplicación de comentarios de código. – Will

Uh, ¿por qué asocias "buggy" con "legible"? ¿Qué tal "legible y confiable"? No son mutuamente exclusivos. –

Así es como encadenas a los constructores y es una cosa perfectamente válida.

Fuente

2010-08-19 17:39:09

El problema con los dos constructores independientes es que a menudo contienen un código idéntico, lo que puede ocasionar problemas con las refactorizaciones posteriores, cuando se cambia un constructor y el otro no. De modo que podría ver el encadenamiento de constructor con this() como una aplicación del DRY principle.

Fuente

2010-08-19 17:41:05 Landei

Las listas de inicialización son una práctica muy común en la industria.

En cuanto a la legibilidad ... eso es una cuestión de opinión. Pero el mantenimiento es usualmente un objetivo más alto para esforzarse.

DRY es una buena cosa :)

Fuente

2010-08-19 17:41:27 Josh

me gusta mucho la primera forma (constructor de encadenamiento), pero si se siente la segunda forma es más fácil de leer y luego ir por eso y que podría poner lo código duplicado que tiene en el constructores en un método privado para evitar romper el principio DRY que las personas han mencionado.

Además, siempre trato de codificar según el estilo del código en el que estoy trabajando, por lo que si el estilo predominante es uno u otro, seguiría con ese estilo por coherencia.

Fuente

2010-08-19 18:38:31

Otra forma de DRY es escribir un método de inicialización, por ejemplo Init(rabble, bloop) y todos los constructores llaman a este método.

Esto tiende a ser menos confuso y más flexible, especialmente cuando hay muchos constructores.

Fuente

2010-08-20 02:08:19

Respuesta

Cuestiones relacionadas