Лучшая практика по местному использованию частного поля х собственности

Question

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

Ниже приведен пример того, что я пытаюсь выяснить. Следует ли манипулировать частным полем _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

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

Заранее спасибо за помощь. Edu

Answer 1

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

Хорошим примером того, где это происходит, является код в 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.

Answer 2

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

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

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

1. Доступ к вашим личным полям напрямую.

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

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

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

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

Sidenote:

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

Answer 3

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

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

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

Answer 4

Оригинальный постер ТОЧНО правильный.

1) Доступ к вашим личным полям напрямую.

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

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

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

Answer 9

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