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

Я просматривал некоторую документацию для библиотеки физики для 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 2
c# .net this default-constructor

6 ответов:

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

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

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

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

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

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

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

4

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

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

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

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

3

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

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

2

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

1

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

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

    Строка _variable1;

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

    Const string Variable1;

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

    Строка Variable1 {get; set;}

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

1

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

var foo =_FatNumber;

Итак, вы начинаете искать _FatNumber и не можете найти его определенным. Это потому, что он находится в базовом классе. если он помечен как база.Fatnumber вы знаете, чтобы не утруждать себя поисками здесь, в то время как это.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;
    }
}
0