Зачем определять геттер перед сеттером (соглашение о кодировании) - PullRequest
Новая
       41

Зачем определять геттер перед сеттером (соглашение о кодировании)

3 голосов
/ 03 апреля 2012

Я ценю этот вопрос немного глупо, поэтому заранее прошу прощения, если это не по теме или неконструктивно.

Почему в C # это стандартное соглашение * определять свойства с помощью getter перед setter? Для свойств с обоими вы почти всегда будете использовать установщик перед получателем, поэтому он находится в допустимом состоянии. Поэтому мне кажется немного отсталым, что мы сначала определяем геттер.

Кроме того, сеттер обычно имеет некоторую логику валидации, которая ему не нужна. Разве не было бы уместнее иметь эту логику перед геттером, чтобы прояснить, как должно вести себя свойство. Например: 

public decimal Price
{
    get { return _price; }
    set
    {
        if(value < 0m)
        {
            throw new ArgumentOutOfRangeException();
        }

        _price = value;
        OnPropertyChanged("Price");
    }
}

Код в установщике гораздо интереснее, чем в геттере, не должен ли он иметь приоритет и быть определен первым?

* Я знаю, что с этими вещами нет никаких правил, но практически каждый пример когда-либо свойств определяет геттер перед сеттером.

Ответы [ 4 ]

16 голосов
/ 03 апреля 2012

Потому что лучше дать, чем получить.

На более серьезной ноте, я предполагаю, потому что тот, кто написал фрагмент (или что-то еще, что автоматически генерирует код свойства в VS), подсознательно выбрал этот порядок.

Тогда как остальные из нас - просто овцы этому новаторскому пастырю, мы последовали без вопросов.

До тебя.

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

11 голосов
/ 03 апреля 2012

Геттер обычно намного короче (обычно однострочный), поэтому, поместив его в начало, вы сможете лучше рассмотреть, как вы бы предпочли: 

if (condition)
{
    // Short code
}
else
{
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
}

вместо этого: 

if (!condition)
{
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
    // Long code
}
else
{
    // Short code
}

И более того - просто потому что.

1 голос
/ 03 апреля 2012

Порядок получения и установки полностью не имеет значения, я думаю, что причиной соглашения является фрагмент свойства Visual Studio, который сгенерировал свойства таким образом (получение перед установщиком). Таким образом, после использования этого фрагмента пару раз этот заказ стал неписаной, бессознательной практикой для большинства программистов (включая меня). Это, конечно, не объясняет, почему разработчики VS реализовали этот фрагмент таким образом. Мое мнение: они этого не знают, и им это безразлично, или, может быть, потому, что g в английском алфавите раньше, чем s. Во всяком случае, кто в мире так много времени, чтобы заботиться?

0 голосов
/ 03 апреля 2012

Я думаю, что здесь важна последовательность.Хотя в вашем примере сеттер «более интересен», я не думаю, что это происходит в большинстве случаев.Действительно, одна из причин, по которой автоматические свойства так полезны, заключается в частоте, с которой код get и set просто читает / записывает в приватное поле без какой-либо другой обработки, и в этом случае ни один из них не «более интересен».

В ваших собственных проектах вы, конечно, можете свободно размещать их в любом порядке, который вам нравится, и если вы решите, что сеттеры должны стоять первыми, исходя из «важности» или по какой-то другой причине, вы совершенно свободныСделай так.Однако, учитывая широко распространенный характер соглашения «получатель перед установщиком», если вы планируете делиться своим кодом, имеет смысл следовать соглашению ради тех, кому, возможно, потребуется его прочитать или изменить в будущем.

...