Не объявлять изменяемые ссылочные типы только для чтения - почему нет?
Я читал этот вопрос и несколько других ответов и пока я получаю различие между изменением ссылки и изменением состояния текущего экземпляра, я не уверен, почему это означает, что я не должен отмечать его только для чтения. Это вызвано тем, что маркировка чего-то как только для чтения говорит компилятору что-то специальное об экземпляре и таким образом, это может затем рассматривать его как ориентированный на многопотоковое исполнение, когда это на самом деле не могло бы быть?
По-видимому, существуют ситуации, где я не хочу, чтобы экземпляр смог быть измененным, но не возражаю, если состояние экземпляра изменяется (одиночный элемент, возможно. / меня готовит к провокационным сообщениям), Каковы последствия для маркировки экземпляра, только для чтения, если я хочу это?
4 ответа
Нет никаких последствий (на основе времени выполнения / среды). Компилятор не испугается, ваша среда выполнения не взорвется, и в целом все будет хорошо.
Только FxCop (инструмент статического анализа, которым пользуются некоторые) имеет предупреждение об этом. Причины предупреждения объясняются в потоке, с которым вы связались (семантически может быть неясно, что объект на самом деле не «только для чтения», а только то, что переменная не может быть «переназначена»).
Лично я не согласен с правилом, поэтому я бы просто отключил его (если вы используете FxCop и это вас беспокоит).
Интересный связанный с этим момент: изменяемые структуры readonly - плохая идея из-за ситуаций, подобных этой:
http: // ericlippert.com/2008/05/14/mutating-readonly-structs/
Большинство людей, которым я показал этот код, не могут правильно предсказать его результат.
Изменяемые структуры только для чтения имеют проблему, заключающуюся в том, что люди думают, что они изменяют их, но на самом деле они мутируют копию.
Изменяемые ссылочные типы только для чтения имеют противоположную проблему. Люди думают, что они глубоко неизменны, но на самом деле неизменны лишь поверхностно.
Думаю, дело в том, что это может ввести в заблуждение - невнимательный читатель может предположить, что переменная, доступная для чтения, является константой, а это не так.
Я бы отнесся к этому как к предложению, а не как к правилу - безусловно, есть случаи, когда это может быть разумно, но использовать это следует с осторожностью. (В частности, я бы нервничал, если бы изменяемое состояние было открыто для внешнего мира)
.Эти два объявления типов являются правильными и полезными, хотя они означают разные вещи:
- постоянная ссылка на изменяемый объект.
- изменяемая ссылка на постоянный объект.
Если вам действительно нужна постоянная ссылка на изменяемый объект, кажется нежелательным, чтобы вам приходилось обходиться изменяемой ссылкой по любой причине, не говоря уже о плохой. В многопоточном программировании постоянная ссылка может избавить вас от необходимости синхронизировать объект-владелец (вам все еще нужно синхронизировать изменяемый объект через ссылку, но это более тонкая блокировка).
Неосторожные читатели, вероятно, тоже неосторожные писатели — мало что могут с ними поделать, за исключением:
const SourceRepository cvs = new ReadOnlyRepository(...);
В C++ есть средства принудительного указания постоянного указателя на постоянный объект (ссылки в C++ немного отличаются):
Object const* const constantPointerToConstantObject = ...;
Это одна из немногих возможностей C++, которых мне не хватает в C#/Java.
В языке D есть еще лучшее ключевое слово (неизменяемый), обеспечивающее транзитивную неизменность. Неизменяемость в D позволяет компилятору делать те оптимизации, о которых вы беспокоитесь, и гарантировать безопасность. D также имеет const для нетранзитивной константности, что подразумевает, что как транзитивные, так и нетранзитивные формы полезны независимо друг от друга.