Разве это не побеждает целую цель наличия свойств только для чтения?

1. Нет, это не отменяет назначение свойств только для чтения.
2. Можно использовать свойства только для чтения, которые не позволяют пользователю изменять базовые данные. Например, ваше свойство может возвращать System.Collections.ObjectModel.ReadOnlyCollection , даже если базовым типом является List . Это, конечно, не помешает пользователю изменять свойства элементов в коллекции.

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

Некоторые классы (например, объект String в Java, и я также верю в C #) полностью неизменяемы, тогда как другие могут изменяться только частично. Рассмотрим стиль объекта ActiveRecord, для которого большинство полей являются изменяемыми, но идентификатор неизменен. Если ваш класс содержит ActiveRecord в свойстве только для чтения, внешние классы не могут поменять его на другой объект ActiveRecord и, таким образом, изменить идентификатор, что может нарушить предположения внутри вашего класса.

В качестве второстепенного момента вам не нужно писать (ab ) .i = 100; но просто

a.b.i = 100;

Возвращаясь к вашему вопросу, я не думаю, что это противоречит цели. Вы по-прежнему не можете делать следующее:

a.b = new B();

, потому что нет общедоступного set (). Если вы хотите, чтобы член i класса B был доступен только для чтения, вы можете сделать то же самое, что и для члена _b класса A, сделав его закрытым и предоставив общедоступный get (), но не set (). Совершенно очевидно, что выполнение того, что вы предлагаете, может привести ко многим неожиданным сбоям (я уверен, что разработчики языка не упустили этого из виду).

Другой вариант использования:

interface INamedPerson
{
    String Name { get; }
}

class Bob : INamedPerson
{
    public String Name { get; set; }
}

class Office
{
    // initialisation code....

    public INamedPerson TheBoss { get; }

    public IEnumerable<INamedPerson> Minions { get; }
}

Теперь, если у вас есть экземпляр Office, если вы не обманываете приведения типов, у вас есть доступ только для чтения ко всем именам, но вы не можете изменить ни одно из их.

Неизменяемость ссылок - это популярный запрос функции. Жаль, что это так резко несовместимо с CLS. Очень немногие языки имеют это понятие, я знаю только C ++ (но не очень много).

Ключевая проблема в том, что это должно выполняться средой CLR. C ++ не требует принудительного выполнения этого во время выполнения, требуется только компилятор C ++, чтобы гарантировать соблюдение константных контрактов. У него вообще нет поддержки языкового взаимодействия, за исключением такого, как COM.

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

Неизменяемость не является транзитивной; нельзя ожидать, что изменяемые объекты в неизменяемом аксессоре будут неизменяемыми.

Ваша ссылка доступна только для чтения, а не ваш объект.

Конечно, вы можете получить доступ к B.i; это public. Вы думаете, что поскольку _b является приватным, все методы должны быть приватными при получении через A? В таком случае это довольно бесполезно, поскольку вы не сможете использовать B ни для чего.

Вы спросите:

Разве это не разрушает всю цель иметь свойства только для чтения?

Но посмотрите: ваш член B.i является публичным полем.

Тогда я спрашиваю вас: какова цель иметь публичное поле? Это имеет смысл, только если вы хотите, чтобы пользователи вашего кода могли изменять значение этого поля. Если вы не хотите этого, то это должно быть приватное поле или (если вы хотите обеспечить доступ на чтение, но не на запись) свойство с приватным аксессором set.

Вот ваш ответ. private B _b служит своей цели в приведенном вами коде достаточно хорошо (_b не может быть установлен извне во что-то новое), так же как public int i служит своей цели столь же хорошо (i может быть изменен извне).

А. При инкапсуляции инстанцированный класс наследует уровень доступа содержащего класса. Выставление типа B как публичного свойства типа A. 'B.i' является публичным, поэтому он должен быть доступен извне так же, как 'A.b' является публичным.

A.b возвращает ссылку на закрытый тип B, однако у типа B есть общедоступное поле i. Насколько я понимаю, вы можете установить поле i у B, но не можете установить свойство b у A извне. Свойство B типа A является доступным для чтения, однако ссылка на тип B не определяет такой же доступ для чтения к его полям.

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

Я не согласен. Ваше свойство предназначено для класса B, а не для членов класса B. Это означает, что вы не можете назначить новый объект для b. Это не означает, что публичные члены B внезапно становятся приватными.

readonly применяется к свойству класса, а не к объекту, на который ссылается свойство. Это мешает вам написать a.b = new B (); , и это все, что он делает. Он не накладывает ограничений на то, что вы можете делать с объектом после получения ссылки на него. Я думаю, вы обнаружите, что readonly имеет наибольший смысл при применении к типам значений или неизменяемым типам классов.