Як реалізувати властивість лише для читання

Question 1

Мені потрібно реалізувати властивість лише для читання для мого типу. Більше того, значення цієї властивості буде встановлено в конструкторі, і воно не буде змінено (я пишу клас, який виставляє власні маршрутизовані команди інтерфейсу для WPF, але це не має значення).

Я бачу два способи зробити це:

class MyClass
{
    public readonly object MyProperty = new object();
}

class MyClass
{
    private readonly object my_property = new object();
    public object MyProperty { get { return my_property; } }
}

З урахуванням усіх цих помилок FxCop, які кажуть, що я не повинен мати відкритих змінних-членів, здається, що другий варіант - це правильний спосіб це зробити. Правильно?

Чи є в цьому випадку якась різниця між властивістю get only та членом лише для читання?

Буду вдячний за будь-які коментарі / поради / тощо.

Question 2

Версія:
Я думаю, це не має великого значення, якщо вас цікавить лише сумісність джерел.
Використання властивості краще для двійкової сумісності, оскільки ви можете замінити його властивістю, яка має сеттер, не порушуючи скомпільований код залежно від вашої бібліотеки.

Конвенція:
Ви дотримуєтесь конвенції. У таких випадках, коли відмінності між двома можливостями порівняно незначні, дотримуючись конвенції, краще. Одним з випадків, коли це може повернутися до вас, вас може вкусити - це код на основі рефлексії. Він може приймати лише властивості, а не поля, наприклад редактор властивостей / переглядач.

Серіалізація
Перехід від поля до властивості, ймовірно, призведе до поломки багатьох серіалізаторів. А AFAIK XmlSerializerробить лише серіалізацію державного майна, а не загальнодоступних полів.

Використання автовластивості
Ще однією поширеною варіацією є використання автовластивості з приватним установщиком. Незважаючи на те, що це коротко і властивість, воно не гарантує лише готовність до читання. Тому я віддаю перевагу іншим.

Поле для читання - це самодокументування.
Однак є одна перевага поля:
воно дає зрозуміти з першого погляду на загальнодоступний інтерфейс, що воно насправді незмінне (заборона відображення). Тоді як у випадку з властивістю ви можете бачити лише те, що не можете змінити його, тому вам доведеться звернутися до документації або реалізації.

Але чесно кажучи, я досить часто використовую перший у коді програми, оскільки я лінивий. У бібліотеках я, як правило, більш ретельний і дотримуюсь домовленостей.

C # 6.0 додає автоматичні властивості лише для читання

public object MyProperty { get; }

Отже, коли вам не потрібно підтримувати старі компілятори, ви можете мати справді властивість лише для читання з кодом, який такий же лаконічний, як поле для читання.

Question 3

Другий спосіб - кращий варіант.

private readonly int MyVal = 5;

public int MyProp { get { return MyVal;}  }

Це забезпечить MyValприсвоєння лише при ініціалізації (його також можна встановити в конструкторі).

Як ви вже зазначали - таким чином ви не викриваєте внутрішнього члена, дозволяючи змінити внутрішню реалізацію в майбутньому.

Question 4

З введенням C # 6 (у VS 2015), тепер ви можете мати лише getавтоматичні властивості, в яких є неявне поле резервного копіювання readonly(тобто значення можуть бути призначені в конструкторі, але не в інших місцях):

public string Name { get; }

public Customer(string name)  // Constructor
{
    Name = name;
}

private void SomeFunction()
{
    Name = "Something Else";  // Compile-time error
}

І тепер ви також можете ініціалізувати властивості (із або без встановлення) вбудовано:

public string Name { get; } = "Boris";

Повертаючись до питання, це дає вам переваги варіанту 2 (публічний член є власністю, а не полем) із стислістю варіанту 1.

На жаль, це не забезпечує гарантії незмінності на рівні загальнодоступного інтерфейсу (як у пункті @ CodesInChaos про самодокументування), оскільки для споживача класу відсутність сетера не відрізняється від приватного сеттера.

Question 5

Ви можете зробити це:

public int Property { get { ... } private set { ... } }

Question 6

Я згоден, що другий шлях є кращим. Єдиною реальною причиною такої переваги є загальна перевага щодо того, що класи .NET не мають загальнодоступних полів. Однак, якщо це поле читається лише для читання, я не бачу, як би існували реальні заперечення, крім відсутності узгодженості з іншими властивостями. Справжня різниця між полем тільки для читання та властивістю "тільки для отримання" полягає в тому, що поле "лише для читання" забезпечує гарантію того, що його значення не зміниться протягом життя об'єкта, а властивість "лише для читання" - ні.

Question 7

Другий спосіб є кращим через інкапсуляцію. Звичайно, поле readonly може бути загальнодоступним, але це суперечить ідіомам C #, у яких доступ до даних відбувається через властивості, а не поля.

Причиною цього є те, що властивість визначає загальнодоступний інтерфейс, і якщо реалізація резервної копії до цієї властивості змінюється, ви не закінчите розбивати решту коду, оскільки реалізація прихована за інтерфейсом.

Question 8

ще один спосіб (мій улюблений), починаючи з C # 6

private readonly int MyVal = 5;

public int MyProp => MyVal;

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties#expression-body-definitions

Question 9

У C # 9 Microsoft представить новий спосіб встановлення властивостей лише під час ініціалізації за допомогою init;методу приблизно так:

public class Person
{
  public string firstName { get; init; }
  public string lastName { get; init; }
}

Таким чином, ви можете призначити значення при ініціалізації нового об’єкта:

var person = new Person
{
  firstname = "John",
  lastName = "Doe"
}

Але пізніше ви не зможете змінити це:

person.lastName = "Denver"; // throws a compiler error