Наилучшая практика местного использования частной собственности Field x

StackOverflow https://stackoverflow.com/questions/833047

Вопрос

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

Ниже приведен пример того, что я пытаюсь выяснить.Следует ли манипулировать Частным полем _Counter или Счетчиком свойств?

Тест публичного класса

Private _Counter As Integer

Public Property Counter() As Integer
    Get
        Return _Counter
    End Get
    Set(ByVal value As Integer)
        _Counter = value
    End Set
End Property

Private Sub Dosomething()

    'What is the best practice?
    'Direct access to private field or property?

    'On SET
    _Counter += 1
    'OR
    Me.Counter += 1

    'On Get
    Console.WriteLine(_Counter)
    Console.WriteLine(Me.Counter)

End Sub

Конечный класс

Заранее благодарю за помощь.Эду

Это было полезно?

Решение

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

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

Также обратите внимание, что большинство современных IDE (например, Eclipse) позволяют сразу видеть все ссылки на приватное поле и реорганизовать код для использования функции вместо прямого доступа.

Другие советы

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

Хороший пример того, где это происходит, приведен в коде Linq DataContext.

проверить это ... 

[Column(Storage="_ReviewType", DbType="TinyInt NOT NULL")]
public byte ReviewType
{
    get
    {
        return this._ReviewType;
    }
    set
    {
        if ((this._ReviewType != value))
        {
            this.OnReviewTypeChanging(value);
            this.SendPropertyChanging();
            this._ReviewType = value;
            this.SendPropertyChanged("ReviewType");
            this.OnReviewTypeChanged();
        }
    }
}

Заметили всю эту логику в «сеттере»?

Вот почему важно начать практиковать вызов своих свойств вместо полей, IMO.

Спасибо вам всем за ответы и предложения.

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

Это сказало;мое личное правило склоняется к этому:

  1. Получите прямой доступ к вашим личным полям.

  2. При обращении к средствам доступа используйте ключевое слово ME.для улучшения читабельности

  3. Используйте средство доступа только в том случае, если оно реализует логику vital logic, которая также применима к частному доступу.Таким образом, вы знаете, что если вы используете средство доступа, то это потому, что в нем есть "что-то еще".

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

Дай мне знать, что ты думаешь.

Побочное примечание:

После этого я думаю, что нам не хватает новой области для полей уровня класса.Ключевое слово типа “Restricted”, где к этому полю можно получить доступ только из его средства получения / установки.Таким образом, вы всегда получаете прямой доступ к закрытым полям, но если вам нужно убедиться, что к определенному полю может получить доступ только его администратор, измените значение Private на Restricted.(как насчет "Restricted, RestrictedRead и RestrictedWrite"?)

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

Используйте личное поле, потому что вы не делаете что-то конкретное в установщике.

Я бы также порекомендовал удалить установщик свойств, таким образом вы принудительно устанавливаете состояние счетчика заданным методом DoSomething ()

В зависимости от ситуации может быть предпочтительным разрешить прямое изменение поля в классе только для частного использования или с помощью какого-либо метода, который связывает семантику с изменением. Таким образом, становится легче рассуждать об этом классе и об этом конкретном значении, поскольку вы можете быть уверены, что он изменен только определенным образом. Более того, в какой-то момент такие действия, как increment и int, могут иметь дополнительные обязательные последствия, и в этом случае имеет больше смысла предоставлять доступ к ним с помощью методов.

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

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

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

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

Оригинальный плакат АБСОЛЮТНО правильный.

1) Получите прямой доступ к своим личным полям.

  • Упрощает рефакторинг.

2) При обращении к средствам доступа используйте ключевое слово ME.для улучшения читабельности

  • явное перечисление области применения требует от читателя меньше размышлений

3) Используйте средство доступа только в том случае, если оно реализует логику vital logic, которая также применима к частному доступу.Таким образом, вы знаете, что если вы используете средство доступа, то это потому, что в нем есть “что-то еще”.

  • это единственная причина нарушать правило №1.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top