-->

In OOP, what is the best practice in regards to us

2020-08-16 16:54发布

问题:

Something I've always wondered; in a class where you can reference a member by either using 'this.[NAME]' or simply [NAME], which is preferred?

For example in Java:

public class foo {
    public int bars = 0;
    private void incrementBars(){
        bars++;
    }
}   

and

public class foo {
    public int bars = 0;
    private void incrementBars(){
        this.bars++;
    }
}

'seem' to have the same effect.

In cases where I instantiate multiple instances of class foo, I'd, so far, do something like:

for (foo f : listOfFoos){
    f.incrementBars();
}

and it seems to still work.

Is it technically ambiguous, and if so is there a preferred way?

回答1:

use this in the case of variable shadowing.

 class MyClass{
        int i;//1
        public void myMethod(){
            i = 10;//referring to 1    
        }

        public void myMethod(int i){//2
            i = 10;//referring to 2
            this.i = 10 //refering to 1    
        }    
    }  

also sometime this will make code more readable due to our English mindset



回答2:

There's no ambiguity. If there were, you'd have to use this.

Some people recommend this for clarity. Others recommend against it when it's not required, as it introduces "noise". Some modern IDEs or editors may be able to use syntax highlighting to color (for instance) arguments differently from fields for clarity.

Personally I avoid this when I can and use @unholysampler's underscore convention. Agree on something with your coworkers and put it in your coding standards.



回答3:

You use this to ensure and communicate that you are dealing with a field.

It allows you to write a setter like

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

which is very succint.



回答4:

The only time you need this. is when the current scope also has a variable of the same name. I prefer to use the convention of _variable for all class variables. This way I never have to use this. and never accidentally touch a class variable thinking it was a locally scoped variable.



回答5:

It is technically ambiguous except in the case of where you have variable shadowing (which Jigar pointed out in his answer).

Most often if you working in an editor / IDE that is very aware of your class structure syntax highlighting will make it obvious as to whether or not a variable is field in the object or just a variable defined in a method. However, in more pure text editors (vim, for instance)the syntax highlighting doesn't make this clear.

With that said, I prefer using this.field to refer to all fields that belong in the object if only because I know that every now and then I'll be reading code outside of my normal IDEs. It is marginally more verbose, but that's a tradeoff I don't mind.



回答6:

In your question the first two samples have exactly the same thing. The only where this is mandatory is when an attribute is shadowed by a local variable:

public class Test {
    private int a;

    public void noShadow() {
        System.out.println(a); // attribute
    }

    public void shadow(int a) {
        System.out.println(a); // parameter
        System.out.println(this.a); // attribute
    }
}

Now I don't think there is an absolute best practice, especially as modern IDEs provide advanced syntax highlighting. Some like to prefix the attribute with something like _, m_, etc. and not use this. Some prefer to make the use of this mandatory and do not add any naming rules on attributes. What you are going to do is vastly depending on the existing code or existing coding standards. I nothing exists ensure that the coding standards will be the same for all people working on the project.



回答7:

class Test
{
  private int value;

  public Test(int value)
  {
     // This is wrong
     // value = value

     // This is right
     this.value = value;
  }
}

Use "this" to access member variables when they have been hidden by a local variable. Since "this" is just a reference to the current object, ou can do this:

doSomething(this);

These are essentially the only ways you will ever need to use this.