.NET. Когда я должен использовать функцию свойство vs. variable + accessor?

Question

Есть ли когда-нибудь ситуация, когда я должен сделать следующее в .NET вместо использования свойства с возможностью чтения/записи?

private S as string 

public function GetS() as string 
    return S 
end function 

public sub SetS(byval NewS as string) 
    S = NewS 
end function 

Действительно ли свойства обеспечивают более эффективный способ выполнения одной и той же вещи?

Будут ли свойства более медленными, чем перечисленные выше функции доступа в высокопроизводительном приложении?

Answer 1

Свойства, внутренние, представляют собой не что иное, как пару методов. Они в основном оценивают метод get и set accessor.

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

Подробнее, предлагаю прочитать Property Usage Guidelines on MSDN. В частности, используйте метод, когда:

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

В противном случае я бы воспользовался недвижимостью. Brad Abram's blogged some other details, включая веские причины, по которым некоторые функции API используют методы (главным образом потому, что они могут вызывать межкомпьютерную связь, которая попадает в категорию «побочный эффект»).

Answer 2

Свойства на самом деле являются синтаксическим сахаром для методов под названием get_MyProperty и set_MyProperty, поэтому нет разницы в производительности.

Answer 3

Да, по крайней мере, в своем опыте я стараюсь избегать свойств и использовать функции и подпрограммы на месте. Вот мои причины:

1. Нельзя использовать свойства с делегатами. Я считаю, вы можете в C#, но на
2. Свойства обманчивы, они выглядят как члены, но ведут себя как функции. Поэтому, хотя вы можете подумать, что вы просто смотрите на значение члена, вы могли бы фактически снова инициализировать всю систему, потому что разработчик-разработчик злоупотреблял ленивым экземпляром.

3. Меньше кода, в то время как это не ОГРОМНАЯ сумма, определение свойств в VB требует не менее 2 дополнительных строк кода для получения или установки. Накладные расходы удваивают строки фактического кода для одной операции присваивания или возврата. Несмотря на то, что это немного затрудняет чтение кода, VB уже является навязчиво многословным языком.

   Private ReadOnly Property Foo As String 
       Get 
        Return Bar 
       End Get 
   End Property 
   

   против

   Private Function Foo As String 
       Return Bar 
   End Function 
   

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

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

Answer 4

Другое решение о том, следует ли использовать свойства или функции, является создание экземпляра родительского объекта. У VB есть удивительно удобный синтаксис, например.

Dim MyStudent as Student With {.Name = "Bobby", .Age = 10} 

Только объекты доступны в разделе С.

Я поддерживаю приложение, в котором есть много сохраненных объектов в базе данных, в которых много связей между объектами. например у ученика есть учитель, а учитель - в БД.

Обычно я использую свойство WriteOnly для установки Учителя, поскольку это операция с подсветкой, но при наличии потенциально дорогого доступа к БД для извлечения Учителя я использую функцию для извлечения. Другими слова:

Public Writeonly Property Teacher() as Teacher 
Public Function GetTeacher() as Teacher 

Это позволяет мне экземпляр Student в виде With {.Teacher = SomeTeacherObject} но GetTeacher поощряет кэширование объекта учителя в коде пользователя, а не просто использовать его как свойство, которое может или не может привести к множественному доступу с БД звонки.

Если у кого-то есть комментарии по этому подходу, я бы с удовольствием их услышал.

Answer 5

С конструкциями N-Tier, в моем BO, я храню значения свойств с неустановленным значением, а затем устанавливаю его при первом доступе.

Private _aValue As integer =-1 
    Private ReadOnly Property aValue As integer 
    Get 
     If _aValue = -1 Then 
      _aValue = DA.General.GetaValue() 
     End If 
     Return _aValue 
    End Get 
End Property 

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