new - polymorphism constructor c#
C#Cuándo utilizar la palabra clave "This" (8)
Posible duplicado:
¿Cuándo usas la palabra clave “this”?
Hola, entiendo que This palabra clave se usa para referirse a una instancia de la clase; sin embargo, supongamos que tengo una clase llamada Life , que define dos campos, la persona ( su nombre ) y su compañero ( su nombre ):
class Life
{
//Fields
private string _person;
private string _partner;
//Properties
public string Person
{
get { return _person; }
set { _person = value; }
}
public string Partner
{
get { return _partner; }
set { _partner = value; }
}
//Constructor 1
public Life()
{
_person = "Dave";
_partner = "Sarah";
MessageBox.Show("Life Constructor Called");
}
//Constructor 2
public Life()
{
this._person = "Dave";
this._partner = "Sarah";
MessageBox.Show("Life Constructor Called");
}
}
¿Hay alguna diferencia entre el constructor 1 y el constructor 2? ¿O es simplemente una mejor práctica de codificación usar la palabra clave "This"?
Saludos
"esto" también se usa en .Net 3.5 con métodos de extensión:
public static class MyExtensions
{
public static string Extend(this string text)
{
return text + " world";
}
}
extendería la clase de cadena
var text = "Hello";
text.Extend();
Para responder a su pregunta: no, no hay diferencia en sus dos constructores. Imo, el "esto" desordena el código y solo debe usarse cuando sea necesario, por ejemplo, cuando los parámetros y las variables de campo tienen los mismos nombres.
También hay un caso en el que la clase implementa explícitamente una interfaz. Si necesita llamar a los métodos de la interfaz desde su clase, tendría que enviar esto a la interfaz:
class Impl : IFace
{
public void DoStuff()
{
((IFace)this).SomeMethod();
}
void IFace.SomeMethod()
{
}
}
Ambos constructores hacen lo mismo de todos modos en el segundo this es redundante
Los constructores son los mismos. La razón por la que preferiría la segunda es que le permitirá eliminar los guiones bajos de sus nombres de variables privadas y conservar el contexto (mejorando la comprensión). Hago práctica usar this siempre cuando me refiero a variables y propiedades de instancia.
Ya no uso this palabra clave de esta manera después de mudarme a una compañía diferente con estándares diferentes. Me he acostumbrado a ello y ahora rara vez lo uso en absoluto cuando se refiere a miembros de instancia. Todavía recomiendo usar propiedades (obviamente).
Mi versión de tu clase:
class Life
{
//Fields
private string person;
private string partner;
//Properties
public string Person
{
get { return this.person; }
set { this.person = value; }
}
public string Partner
{
get { return this.partner; }
set { this.partner = value; }
}
public Life()
{
this.person = "Dave";
this.partner = "Sarah";
MessageBox.Show("Life Constructor Called");
}
}
o, incluso mejor, pero no tan claro sobre el uso de this en los campos.
class Life
{
//Properties
public string Person { get; set; }
public string Partner { get; set; }
public Life()
{
this.Person = "Dave";
this.Partner = "Sarah";
MessageBox.Show("Life Constructor Called");
}
}
No debes usar las variables privadas _person y _parter. Ese es el propósito de tus captadores y setters.
En cuanto a los constructos, no hay diferencia real entre ellos. Dicho esto, siempre prefiero usar esta palabra clave, ya que se adapta a la legibilidad.
No hay diferencia en las dos afirmaciones ...
//These are exactly the same.
this._person
//and
_person
La referencia a "esto" está implícita en el caso de _persona. No diría que es necesariamente una "mejor" práctica de codificación, diría que es simplemente una preferencia.
Puede usar esto para diferenciar entre una variable local llamada X y un campo / propiedad de nivel de clase del mismo nombre.
Ya que estás usando guiones bajos, no hay conflicto entre los nombres; por lo que el " this. " es redundante y puede omitirse. La IL no se verá afectada.
Siempre que no haya ambigüedad entre un campo y una variable / parámetro, solo hay un escenario en el que la palabra clave this (en el contexto de la instancia actual, no el encadenamiento de ctor) es estrictamente necesaria: invocar un método de extensión que sea definido por separado:
this.SomeExtensionMethod(); // works
SomeExtensionMethod(); // fails