Khi nào sử dụng [Pure] trên hàm tạo?

Tôi đang tìm hiểu về các hợp đồng mã trong .NET và tôi đang cố gắng hiểu ý tưởng của các nhà xây dựng thuần túy. Các tài liệu hợp đồng mã quy định:

Tất cả các phương thức được gọi trong hợp đồng phải thuần túy; nghĩa là, họ không được cập nhật bất kỳ trạng thái có sẵn nào. Một phương thức thuần túy được phép sửa đổi các đối tượng đã được tạo sau khi nhập vào phương thức thuần túy.

Và các PureAttributetài liệu nêu:

Chỉ ra rằng một loại hoặc phương thức là thuần túy, nghĩa là nó không thực hiện bất kỳ thay đổi trạng thái có thể nhìn thấy nào.

Tôi hiểu các câu lệnh này khi nói đến các phương thức, nhưng các hàm tạo thì sao? Giả sử bạn có một lớp học như thế này:

public class Foo
{
    public int Value { get; set; }

    public Foo(int value) {
        this.Value = value;
    }
}

Hàm tạo này rõ ràng không ảnh hưởng đến trạng thái của Foođối tượng mới , nhưng nó không có tác dụng phụ nào khác (ví dụ: nó không thao tác bất kỳ tham số nào hoặc gọi bất kỳ phương thức không thuần túy nào). Đây có phải là một ứng cử viên cho [Pure]hay không? Tầm quan trọng của việc đặt một [Pure]thuộc tính trên một hàm tạo và khi nào tôi nên làm điều này trong mã của riêng mình?

Bạn trang trí một phương pháp với [Pure]:

• Nếu phương pháp không có tác dụng phụ. Ví dụ: nếu phương thức truy cập cơ sở dữ liệu và sửa đổi nó hoặc kết quả của nó phụ thuộc vào cơ sở dữ liệu, thì nó không thuần túy.

• Và nếu bạn muốn sử dụng nó trong các hợp đồng mã. Ví dụ: nếu phương thức này là thuần túy , nhưng bạn không có ý định sử dụng nó trong các hợp đồng mã, việc thêm [Pure]sẽ không có lợi ích và sẽ không làm cho mã của bạn nhanh hơn.

Theo như nó liên quan đến các nhà xây dựng, có vẻ như chúng được coi là thuần túy trong .NET và không cần một thuộc tính rõ ràng. Tôi đã xem xét một số hàm tạo trong nguồn .NET Framework, chẳng hạn như DateTime, và chúng không có [Pure]thuộc tính.

Tôi cho rằng điều này được thực hiện vì nhiều lý do:

• Có thể quá không thực tế khi phải viết một hàm tạo không tham số với [Pure]thuộc tính chỉ để có thể sử dụng lớp / struct trong hợp đồng.

• Một số, chẳng hạn như String, không có nhà xây dựng rõ ràng.

• Các nhà xây dựng được đối xử đặc biệt ngay cả các hợp đồng mã bên ngoài; ví dụ, bạn sẽ không ném ngoại lệ vào chúng .

• [Pure]chỉ là một quy ước ở đây để đơn giản hóa cuộc sống của bạn, nhưng không có kiểm tra tĩnh thực tế để đảm bảo rằng phương thức được trang trí với thuộc tính này là thuần túy. void DestroyDatabase()có thể được trang trí là thuần túy và các hợp đồng mã sẽ không nhận thấy điều gì sai.

  Hiện tại không có thành phần nào của Hợp đồng mã kiểm tra xem các phương thức được khai báo là thuần túy thực sự. Do đó, nếu một lập trình viên trang trí một phương thức bằng [Pure], thì nó chỉ được tin.

  ^{Từ hợp đồng mã số 5: Độ tinh khiết của phương pháp}

• Bản thân .NET Framework chứa các hàm tạo không thuần túy. Ví dụ, List<T>(IEnumerable<T> collection)thực sự không tinh khiết nếu việc lặp qua bộ sưu tập có tác dụng phụ.

• Hợp đồng hét được giữ đơn giản. Tôi có thể dễ dàng tưởng tượng một hợp đồng như vậy Contract.Requires(!string.IsNullOrEmpty(name)), vì vậy có những lý do chính đáng để tuyên bố tĩnh string.IsNullOrEmptythuần.

  Mặt khác, nếu bạn cần một StringBuilderchuỗi để xây dựng chuỗi, bạn sẽ kiểm tra một cái gì đó bằng cách gọi một phương thức cá thể của lớp doanh nghiệp của bạn, có lẽ bạn đang sử dụng sai các hợp đồng. Đó cũng StringBuilder.ToStringlà lý do tại sao không được đánh dấu là thuần túy, ngay cả khi nó có thể (phải không?)

Đối tượng không thể được sử dụng cho đến khi nó được xây dựng trong trường hợp này. Do đó, các nhà xây dựng là tinh khiết. Nếu hàm tạo gọi mã khác hoặc gọi một đại biểu và mã khác đã sửa đổi thuộc tính có thể thay đổi, thì nó sẽ không thuần túy. Để an toàn hơn, tốt hơn là làm cho tài sản bất biến.