java - metodos - peticiones get y post php

Usando "esto" con métodos(en Java)

Question

¿Qué hay de usar "esto" con métodos en Java? ¿Es opcional o hay situaciones en las que es necesario usarlo de forma obligatoria?

La única situación que he encontrado es cuando en la clase invocas un método dentro de un método. Pero es opcional. Aquí hay un ejemplo tonto solo para mostrar lo que quiero decir:

public class Test {

    String s;

    private String hey() {
        return s;
    }

    public String getS(){
        String sm = this.hey();
        // here I could just write hey(); without this
        return sm;
    }
}

Answer 1

La única vez que realmente se requiere es cuando tiene un parámetro para un método con el mismo nombre que una variable miembro. Personalmente, trato de usarlo siempre para hacer que el alcance de la variable / método sea explícito. Por ejemplo, podría tener un método estático o un método de instancia. Al leer el código, puede ser útil saber cuál es cuál.

Answer 2

No es una respuesta (así que no dude en votarla), pero no podría incluir esto en un comentario donde alguien estaba preguntando.

Mucha gente usa "this.x" para diferenciar visualmente las variables de instancia de las variables y parámetros locales.

Entonces ellos harían esto:

private int sum;
public int storeSquare (int b) {
    int c=b*b;
    this.sum+=c; // Makes sum "pop" I guess
    return c;
}

Personalmente, creo que es un mal hábito: cualquier editor utilizable colocará variables de instancia y locales en un color diferente para usted de manera confiable, no requiere ningún patrón de falible humano.

Haciéndolo con "esto". es solo 50% seguro. Seguro que el compilador lo detectará si intentas poner this.x cuando x es una variable local, pero no hay nada que te impida desde "Forgetting" etiquetar una variable de instancia con esto. Y si olvidas etiquetar solo uno (o si alguien más trabaja en tu código) y estás confiando en el patrón, entonces el patrón puede ser más dañino que bueno

Personalmente, estoy bastante seguro de que el patrón proviene de la incomodidad de los programadores (legítimos) con el hecho de que en este caso:

public void setMe(int me) {
    this.me=me;
}

el hecho de que necesitas "esto". frente al yo está determinado por el nombre del parámetro - Acepto que se siente descuidado. Quieres ser consistente, si lo necesitas. delante de mí, ¿por qué no usarlo siempre?

Aunque entiendo la incomodidad, escribo esto. cada lugar donde se usa una variable de instancia es simplemente pedante, inútil, feo y poco confiable. Si realmente te molesta y necesitas absolutamente usar un patrón para resolverlo, prueba el hábito de poner "p" delante de tus parámetros. Como efecto secundario, incluso debería hacerlo más constante porque el caso del parámetro ahora coincidirá con el caso del método.

public void setMe( int pMe) 

Answer 3

Utilizo "esto" para aclarar el código, a menudo como una sugerencia de que estoy llamando a un método de instancia en lugar de acceder a un método de nivel de clase o un campo.

Pero no. A menos que se requiera desambiguación debido a una colisión de denominación de alcance, en realidad no necesita "esto".

Answer 4

La única razón para anteponer this delante de una invocación de método es indicar que está llamando a un método no estático. No puedo pensar en ninguna otra razón válida para hacer esto (corríjanme estoy equivocado). No recomiendo esta convención, ya que no agrega mucho valor. Si no se aplica de manera coherente, podría ser engañoso (ya que una invocación a este método menos podría ser un método no estático). ¿Con qué frecuencia uno se preocupa si el método invocado es estático o no? Además, la mayoría de los IDE destacarán los métodos estáticos de forma diferente.

He oído hablar de convenciones donde this indica llamar al método de la subclase, mientras que la ausencia de this llama al método de la superclase. Pero esto es una tontería ya que la convención podría ser al revés.

Editar : como señala mmyers (ver comentario), this funciona con métodos estáticos. Con eso, no veo absolutamente ninguna razón para anteponer this ya que no hace ninguna diferencia.

Answer 5

Tres situaciones obvias donde lo necesita:

• Llamar a otro constructor en la misma clase que la primera parte de su constructor
• Diferenciar entre una variable local y una variable de instancia (ya sea en el constructor o en cualquier otro método)
• Pasar una referencia al objeto actual a otro método

Aquí hay un ejemplo de los tres:

public class Test
{
    int x;

    public Test(int x)
    {
        this.x = x;
    }

    public Test()
    {
        this(10);
    }

    public void foo()
    {
        Helper.doSomethingWith(this);
    }

    public void setX(int x)
    {
        this.x = x;
    }
}

Creo que también hay algunas situaciones extrañas usando clases internas donde se necesita super.this.x pero se deben evitar como muy oscuras, IMO :)

EDITAR: No se me ocurren ejemplos de por qué lo querrías para una this.foo() directa this.foo() método this.foo() .

EDITAR: saua contribuyó con esto en el caso de ejemplos oscuros de clase interna:

Creo que el caso oscuro es: OuterClass.this.foo() cuando se accede a foo() de la clase externa desde el código en una clase interna que también tiene un método foo() .

Answer 6

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StringBuilder.html

Es absolutamente necesario si su método necesita devolver la instancia del objeto.

public class StringBuildable {
    public StringBuildable append(String text) {
        // Code to insert the string -- previously this.internalAppend(text);
        return this;
    }
}

Esto le permite encadenar métodos juntos de la siguiente manera:

String string = new StringBuildable()
    .append("hello")
    .append('' '')
    .append.("World")
    .toString()
;

Answer 7

Para la mayoría de la programación general, this palabra clave es opcional y generalmente se usa para evitar confusiones. Sin embargo, hay algunos lugares donde se necesita.

class Foo {
    int val;

    public Foo(int val) {
         this(val, 0);  //this MUST be here to refer to another constructor
    }

    public Foot(int val, int another) {
        val = val;       //this will work, but it generally not recommended.
        this.val = val;  //both are the same, but this is more useful.
        method1();       //in a Foo instance, it will refer to this.method1()
        this.method1();  //but in a Foo2 instance, you must use this to do the same
    }

    public void method1() {}
}

class Foo2 extends Foo {
    public Foo2(int val) {
        this(val);        //this will refer to the other Foo2 constructor
    }
    public Foo2(int val, int another) {
        super(val, another);
        super.method1();   //this will refer to Foo.method1()
    }

    @Override
    public void method1() {}//overridden method
}

Estos no son todos los casos, sino algunos de los más generales. Espero que esto te ayude a comprender mejor this y super palabras clave super y cómo / cuándo usarlas.