Những lợi ích để đánh dấu một trường là `readonly` trong C # là gì?

Những lợi ích của việc có một biến thành viên được khai báo là chỉ đọc là gì? Có phải nó chỉ bảo vệ chống lại ai đó thay đổi giá trị của nó trong vòng đời của lớp hoặc sử dụng từ khóa này dẫn đến bất kỳ cải thiện tốc độ hoặc hiệu quả nào?

Các readonlytừ khóa được sử dụng để khai báo một biến thành viên một hằng số, nhưng cho phép các giá trị được tính tại thời gian chạy. Điều này khác với một hằng số được khai báo với bộ constsửa đổi, phải đặt giá trị của nó tại thời gian biên dịch. Sử dụng readonlybạn có thể đặt giá trị của trường trong khai báo hoặc trong hàm tạo của đối tượng mà trường là thành viên của.

Cũng sử dụng nó nếu bạn không muốn phải biên dịch lại các DLL bên ngoài tham chiếu hằng số (vì nó được thay thế tại thời gian biên dịch).

Tôi không tin có bất kỳ hiệu suất nào đạt được từ việc sử dụng trường chỉ đọc. Nó chỉ đơn giản là một kiểm tra để đảm bảo rằng một khi đối tượng được xây dựng đầy đủ, trường đó không thể được trỏ đến một giá trị mới.

Tuy nhiên "chỉ đọc" rất khác so với các loại ngữ nghĩa chỉ đọc khác bởi vì nó được thi hành trong thời gian chạy bởi CLR. Từ khóa chỉ đọc biên dịch thành .initonly có thể kiểm chứng bằng CLR.

Ưu điểm thực sự của từ khóa này là tạo ra các cấu trúc dữ liệu bất biến. Cấu trúc dữ liệu bất biến theo định nghĩa không thể thay đổi một khi được xây dựng. Điều này làm cho nó rất dễ dàng để lý giải về hành vi của một cấu trúc trong thời gian chạy. Chẳng hạn, không có nguy cơ chuyển một cấu trúc bất biến sang một phần mã ngẫu nhiên khác. Họ không thể thay đổi nó bao giờ để bạn có thể lập trình đáng tin cậy theo cấu trúc đó.

Đây là một mục tốt về một trong những lợi ích của tính bất biến: Threading

Không có lợi ích hiệu suất rõ ràng khi sử dụng readonly, ít nhất là không có lợi ích nào tôi từng thấy được đề cập ở bất cứ đâu. Nó chỉ để thực hiện chính xác như bạn đề xuất, để ngăn chặn sửa đổi một khi nó đã được khởi tạo.

Vì vậy, nó có lợi ở chỗ nó giúp bạn viết mã mạnh mẽ hơn, dễ đọc hơn. Lợi ích thực sự của những thứ như thế này đến khi bạn làm việc trong nhóm hoặc để bảo trì. Tuyên bố một cái gì đó readonlygiống như đặt một hợp đồng cho việc sử dụng biến đó trong mã. Hãy nghĩ về nó như thêm tài liệu theo cách tương tự như các từ khóa khác như internalhoặc private, bạn đang nói "biến này không nên được sửa đổi sau khi khởi tạo", và hơn nữa bạn đang thực thi nó.

Vì vậy, nếu bạn tạo một lớp và đánh dấu một số biến thành viên readonlytheo thiết kế, thì bạn sẽ ngăn mình hoặc một thành viên khác trong nhóm mắc lỗi sau này khi họ mở rộng hoặc sửa đổi lớp của bạn. Theo tôi, đó là một lợi ích đáng có (với chi phí nhỏ của sự phức tạp ngôn ngữ thêm như doofledorfer đề cập trong các bình luận).

Nói một cách rất thực tế:

Nếu bạn sử dụng const trong dll A và dll B tham chiếu const, giá trị của const đó sẽ được biên dịch thành dll B. Nếu bạn triển khai lại dll A với giá trị mới cho const đó, dll B sẽ vẫn sử dụng giá trị ban đầu.

Nếu bạn sử dụng chỉ đọc trong các tham chiếu dll A và dll B chỉ đọc, thì chỉ đọc đó sẽ luôn được tra cứu trong thời gian chạy. Điều này có nghĩa là nếu bạn triển khai lại dll A với giá trị mới cho chỉ đọc đó, dll B sẽ sử dụng giá trị mới đó.

Có một trường hợp tiềm năng trong đó trình biên dịch có thể thực hiện tối ưu hóa hiệu suất dựa trên sự hiện diện của từ khóa chỉ đọc.

Điều này chỉ áp dụng nếu trường chỉ đọc cũng được đánh dấu là tĩnh . Trong trường hợp đó, trình biên dịch JIT có thể cho rằng trường tĩnh này sẽ không bao giờ thay đổi. Trình biên dịch JIT có thể tính đến điều này khi biên dịch các phương thức của lớp.

Ví dụ điển hình: lớp của bạn có thể có trường IsDebugLoggingEnables chỉ đọc tĩnh được khởi tạo trong hàm tạo (ví dụ: dựa trên tệp cấu hình). Khi các phương thức thực tế được biên dịch JIT, trình biên dịch có thể bao gồm toàn bộ các phần của mã khi ghi nhật ký gỡ lỗi không được bật.

Tôi chưa kiểm tra xem việc tối ưu hóa này có thực sự được thực hiện trong phiên bản hiện tại của trình biên dịch JIT hay không, vì vậy đây chỉ là suy đoán.

Hãy nhớ rằng chỉ đọc áp dụng cho chính giá trị, vì vậy nếu bạn đang sử dụng loại tham chiếu chỉ đọc để bảo vệ tham chiếu khỏi bị thay đổi. Trạng thái của cá thể không được bảo vệ bởi chỉ đọc.

Đừng quên có một cách giải quyết để có được các readonlytrường được đặt bên ngoài bất kỳ hàm tạo nào bằng tham số out.

Một chút lộn xộn nhưng:

private readonly int _someNumber;
private readonly string _someText;

public MyClass(int someNumber) : this(data, null)
{ }

public MyClass(int someNumber, string someText)
{
    Initialise(out _someNumber, someNumber, out _someText, someText);
}

private void Initialise(out int _someNumber, int someNumber, out string _someText, string someText)
{
    //some logic
}

Thảo luận thêm tại đây: http://www.adamjamesnaylor.com/2013/01/23/Setting-Readonly-Fields-From-Chained-Constructor.aspx

Đáng ngạc nhiên, chỉ đọc thực sự có thể dẫn đến mã chậm hơn, như Jon Skeet tìm thấy khi thử nghiệm thư viện Noda Time của mình. Trong trường hợp này, một bài kiểm tra chạy trong 20 giây chỉ mất 4 giây sau khi xóa chỉ đọc.

https://codeblog.jonskeet.uk/2014/07/16/micro-optimization-the-surprising-ineffic-of-readonly-fields/

Nếu bạn có một giá trị được xác định trước hoặc được tính toán trước cần duy trì giống nhau trong suốt chương trình thì bạn nên sử dụng hằng số nhưng nếu bạn có một giá trị cần được cung cấp trong thời gian chạy nhưng một khi được gán sẽ giữ nguyên trong suốt chương trình bạn nên sử dụng chỉ đọc. ví dụ: nếu bạn phải gán thời gian bắt đầu chương trình hoặc bạn phải lưu trữ giá trị do người dùng cung cấp khi khởi tạo đối tượng và bạn phải hạn chế nó khỏi những thay đổi tiếp theo, bạn nên sử dụng chỉ đọc.

Thêm một khía cạnh cơ bản để trả lời câu hỏi này:

Các thuộc tính có thể được thể hiện dưới dạng chỉ đọc bằng cách bỏ settoán tử. Vì vậy, trong hầu hết các trường hợp, bạn sẽ không cần thêm readonlytừ khóa vào thuộc tính:

public int Foo { get; }  // a readonly property

Ngược lại với điều đó: Các trường cần readonlytừ khóa để đạt được hiệu quả tương tự:

public readonly int Foo; // a readonly field

Vì vậy, một lợi ích của việc đánh dấu một trường là readonlycó thể đạt được mức bảo vệ ghi tương tự như một thuộc tính mà không cần settoán tử - mà không phải thay đổi trường thành thuộc tính, nếu vì bất kỳ lý do gì, điều đó là mong muốn.

Hãy cẩn thận với các mảng chỉ đọc riêng tư. Nếu chúng được hiển thị một máy khách dưới dạng một đối tượng (bạn có thể thực hiện điều này cho COM xen kẽ như tôi đã làm) thì máy khách có thể thao tác các giá trị mảng. Sử dụng phương thức Clone () khi trả về một mảng dưới dạng đối tượng.

Có thể có một lợi ích hiệu suất trong WPF, vì nó loại bỏ nhu cầu về DependencyProperies đắt tiền. Điều này có thể đặc biệt hữu ích với các bộ sưu tập

Một phần thú vị khác của việc sử dụng đánh dấu chỉ đọc có thể là bảo vệ trường khỏi khởi tạo trong singleton.

ví dụ trong mã từ csharpindepth :

public sealed class Singleton
{
    private static readonly Lazy<Singleton> lazy =
        new Lazy<Singleton>(() => new Singleton());

    public static Singleton Instance { get { return lazy.Value; } }

    private Singleton()
    {
    }
}

chỉ đọc đóng vai trò nhỏ trong việc bảo vệ trường Singleton khỏi bị khởi tạo hai lần. Một chi tiết khác là đối với kịch bản được đề cập, bạn không thể sử dụng const vì const bắt buộc tạo trong thời gian biên dịch, nhưng singleton tạo ra khi chạy.

readonlycó thể được khởi tạo khi khai báo hoặc chỉ lấy giá trị của nó từ hàm tạo. Không giống như constnó phải được khởi tạo và khai báo cùng một lúc. readonly có tất cả mọi thứ const có, cộng với khởi tạo constructor

mã https://repl.it/HvRU/1

using System;

class MainClass {
    public static void Main (string[] args) {

        Console.WriteLine(new Test().c);
        Console.WriteLine(new Test("Constructor").c);
        Console.WriteLine(new Test().ChangeC()); //Error A readonly field 
        // `MainClass.Test.c' cannot be assigned to (except in a constructor or a 
        // variable initializer)
    }


    public class Test {
        public readonly string c = "Hello World";
        public Test() {

        }

        public Test(string val) {
          c = val;
        }

        public string ChangeC() {
            c = "Method";
            return c ;
        }
    }
}