стиль сеттеров

Question

Я работаю над кодом, в котором много такого кода:

private int x;

public void SetX(int new_x)
{
   this.SetXValue(new_x); 
}

private void SetXValue(int new_x)
{
   this.x = new_x; 
}

и аналогично со свойствами:

private int x;

public int X 
{
    get { return this.GetX(); }
}

private int GetX()
{
    return this.x; 
}

Чего я не понимаю, так это почему нужны частные методы, которые выполняют реальную работу, то есть почему бы просто не иметь такие методы вместо этого:

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

public int X
{
    get { return this.x; }
}

Это просто личный выбор других людей или есть веская причина для использования первого способа?

(я набрал код выше вручную, извините, если есть ошибки, но вы должны надеяться увидеть то, что я пытаюсь сказать)

Приветствие A

Answer 1

Насколько я вижу, нет причин для такого кода. Если вы ничего не делаете с новыми значениями (например, обрабатываете / проверяете перед сохранением) и пишете на C # 3.0, вы можете просто записать это так:

public int MyProperty { get; set; }

Компилятор создает резервное хранилище для вас, и вы можете просто сослаться на:

this.MyProperty

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

public int MyProperty { get; private set; }

Все, что я считаю довольно аккуратно!

Answer 2

Одной из возможных причин может быть то, что свойства могут иметь логин, который должен выполняться только в том случае, если свойство установлено внешне, а вызовы из класса не выполняют всю логику, а только логику в приватном методе.Конечно, нет смысла делать эти методы заранее, потому что введение их позже не изменит контракт класса.Скорее всего, тот, кто написал этот код, был новичком в C # и не понимал, что делают свойства.

Answer 3

Общее правило - использовать свойства для простых операций get / set и методов get / set, когда для получения / установки значения необходима соответствующая часть логики (например, проверка во время установки или доступ к базе данных во время получения).

Так что, если реальный код действительно такой простой, как в вашем примере, просто используйте свойства и выполняйте работу в их методах получения / установки.

Если реальный код более сложный, замените свойства (по крайней мере, сеттеры) методами, как в третьем примере.

Answer 4

Я думаю, что это должен был быть старый разработчик Java.

.Net путь

private int _foo;

public int Foo
{
     get
     {
         return _foo;
     }
     set
     {
          _foo = value;
          dostuff();
     }
 }

Answer 5

Нет, для этого нет никаких оснований, похоже, кому-то заплатили строчки кода.

Итак, да, вы правы, это просто личный выбор других людей, и он не очень хороший.

Answer 6

Почему бы вам не использовать геттеры и сеттеры напрямую для реализации своей логики? Я не понимаю необходимости в дополнительных методах, если у вас нет дополнительных параметров, которые влияют на поведение установщика:

    private int myVar;

    public int MyProperty
    {
        get 
        { 
            return myVar; 
        }
        set 
        {
            myVar = value; 
        }
    }

    public void SetMyPropertySpecial(int a, string reason)
    {
        Console.WriteLine("MyProperty was changed because of " + reason);
        this.myVar = a;
    }

Обновление:

Действительно, этому человеку, похоже, нравится иметь больше строк кода, но структура совершенно бесполезна. Придерживайтесь стандартов .NET, используя геттеры и сеттеры (см. MSDN )

Answer 7

Да, это хорошо, только если SetValue равен private или protected и делает больше, чем просто установка значения.

Я работаю над проектом, в котором мы делаем много таких вещей.Это потому, что мы делаем больше, чем просто устанавливаем значение (проверки значений, проверки состояния и т. Д.). Публичный установщик и общедоступный SetValue не имеют никакого смысла и будут путать ваших потребителей с тем, какой установщик использовать.

Вот еще один сценарий, в котором мы используем такой дизайн:

public abstract class A{
   protected virtual void SetValue(object value);
   public object SomeObject{
      set{SetValue(value);}
   }
}

В этом случае мы хотим, чтобы класс A делегировал установку / проверку этого значения какому-либо классу, унаследованному от него.

Answer 8

Я могу что-то здесь упустить, но это выглядит немного безумно для меня!

Вы можете достичь того же, используя автоматические свойства или свойства с полями поддержки. вот хорошее описание обоих: http://weblogs.asp.net/dwahlin/archive/2007/12/04/c-3-0-features-automatic-properties.aspx

Answer 9

Это очень странно, для этого нет оправданной причины. Пожалуйста, рефакторинг этого кода. Также нет необходимости в методе SetX, поскольку сеттер может быть включен в свойства. e.g.:

public int X {get; set;}