Правильное использование этого. в конструкторе класса - PullRequest
Новая
       31

Правильное использование этого. в конструкторе класса

2 голосов
/ 15 августа 2010

Я просматривал документацию для библиотеки физики для XNA и заметил пример, который кто-то использовал для создания класса для автомобиля.

Это довольно простой пример: 

Class Car
{
   private float gravity;
   private float maxSpeed;

   public Car(float gravity, float maxSpeed)
   {
        this.gravity = gravity;
        this.maxSpeed = maxSpeed;
   }
}

Теперь, когда я создал конструктор и настроил присвоение переданных параметров, я сделал бы это следующим образом: 

Class Car
{
  private float _gravity;
  private float _maxSpeed;

  public Car(float gravity, float maxSpeed)
  {
       _gravity = gravity;
       _maxSpeed = maxSpeed;
  }
}

Есть ли какое-либо преимущество в любом подходе?Я только сталкивался с этим несколько раз, но я полагаю, что для этого есть веские причины, я просто ищу, так сказать, «лучшую практику».

Спасибо!

Ответы [ 6 ]

4 голосов
/ 15 августа 2010

Оба примера функционально идентичны, и оба метода используются разными людьми. Вам решать, с каким соглашением об именах вы согласны. Если вы дадите полю то же имя, что и параметр, то для доступа к нему вам придется использовать this.

Важно быть последовательным в названии. Лично я предпочитаю получать доступ к полям с ключевым словом this, но здесь определенно есть много людей, которым нравится подход подчеркивания.

Подчеркивание:

Если вы префиксируете свои личные поля подчеркиванием, то вам всегда нужно будет использовать его везде, где вы к нему обращаетесь. Понятно (при условии, что вы знаете соглашение), что это частное поле, просто если посмотреть на него. К сожалению, это тоже очень некрасиво, но это только мое мнение.

Без подчеркивания:

Если вы не добавляете префикс к своим личным полям, то у вас есть опция для ссылки на нее напрямую или через ключевое слово this. Это означает, что можно забыть, и в вашем примере вы можете присвоить аргумент себе: gravity = gravity; Это должно по крайней мере генерировать предупреждение. Если вы используете инструмент StyleCop , то по умолчанию он будет принудительно всегда обращаться к закрытым полям через ключевое слово this.

См. Подобные вопросы для получения дополнительных ответов:

3 голосов
/ 15 августа 2010

С появлением автоматических свойств это тоже становится довольно популярным ... 

public class Car
{
  public Car(float gravity, float speed)
  {
    Gravity = gravity;
    Speed = speed;
  }

  protected float Gravity { get; private set; }
  ...

Лично я предпочитаю такой подход, хотя я ненавижу, что вы не можете пометить автоматическое свойство как только для чтения.

2 голосов
/ 15 августа 2010

Оба являются общими подходами, и оба прекрасно подходят.

Лично я предпочитаю первый, потому что считаю подчеркивание уродливым.Но многие люди предпочитают использовать подчеркивания, потому что они помогают определить, что переменная является членом класса, а не локальной переменной.

1 голос
/ 15 августа 2010

Если вы когда-либо сталкивались с Resharper , вот некоторые из соглашений по умолчанию:

  • Глобальные переменные объявляются с подчеркиванием.

    string _variable1;

  • Глобальная переменная, являющаяся константой, должна быть объявлена ​​в верхнем CamelCase.

    const string Переменная1;

  • Свойства всегда должны быть в верхнем CamelCase.

    string Variable1 {get; set;}

Возможно, я не являюсь поклонником подчеркивания, но я вижу, как они помогают вам определять области.

1 голос
/ 15 августа 2010

Либо в порядке.Лично я предпочитаю подход this., особенно с появлением автопринадлежностей.например: public string Something {get; set;}.Если оставить имя аргумента конструктора таким же, как имя свойства, то пользователь, вызывающий код, будет очень четко указывать, где будет находиться значение.

0 голосов
/ 15 августа 2010

Есть некоторые проблемы с читабельностью, которые "this" может помочь решить.Я бывал во многих ситуациях, когда читал чей-то код, чтобы понять, как он работает или как я могу извлечь из него.Читая несколько сложных взаимосвязанных классов, вы обнаруживаете что-то вроде 

var foo =_FatNumber;

Итак, вы начинаете искать _FatNumber и не можете найти его определенным.Это потому что это в базовом классе.если он помечен как base.Fatnumber, вы знаете, что здесь не нужно искать, тогда как this.SlimNumber очень явный.Я бы рекомендовал явно указывать, кто объявляет переменные (обычно это контроллер var).Возможно, это проблема только с более сложными производными классами, но это сэкономило бы мне много времени на понимание поведения классов.

например: 

public class FooBase
{
    protected int Foo { get; set; }
}

public class FooDerived : FooBase
{
    int Bar = 9;

    public int GetTheThing(bool something)
    {
        if (somthing)
            return this.Bar;
        else
            return base.Foo;
    }
}
...