Đây có phải là thay đổi đột phá làm thay đổi công cụ sửa đổi quyền truy cập của thuộc tính công cộng không?

Question

Nếu tôi thay đổi công cụ sửa đổi truy cập của người đặt công khai từ tư nhân thành công khai, có phải là nguyên nhân gây ra bất kỳ thay đổi đột phá nào trong các hội đồng khác tham chiếu không?

Answer 1

CẬP NHẬT: This question was the topic of my blog in January 2012. Cảm ơn vì câu hỏi tuyệt vời của bạn!

---

Tôi giả định rằng bằng "thay đổi đột ngột" nghĩa là "khi tôi biên dịch lại mã phụ thuộc vào hội đồng này, mã nào được sử dụng để biên dịch vẫn biên dịch?"

Theo định nghĩa đó, nghiêm túc nói, vâng, làm cho một công ty thiết lập thuộc tính được sử dụng là riêng tư là một sự thay đổi đột phá. Giả sử bạn có mã này:

// Assembly Alpha 
public class Charlie 
{ 
    public int P { get; private set; } 
} 
public class Delta 
{ 
    public int P { get; set; } 
} 

Và sau đó trong lắp ráp khác tham chiếu Alpha:

// Assembly Echo 
class Foxtrot 
{ 
    static void M(Action<Charlie> f) {} 
    static void M(Action<Delta> f) {} 
    static void Golf() 
    { 
     M(y=>{y.P = 123;}); 
    } 
} 

Bạn biên dịch assembly Echo. Lớp Foxtrot có một phương pháp Golf mà quá tải độ phân giải trên M. M có hai quá tải; một trong đó có một hành động trên Charlie và một trong đó có một hành động trên Delta. Nếu tham số lambda y là kiểu Charlie thì thân lambda tạo ra một lỗi khả năng truy cập, và do đó tình trạng quá tải của M không phải là một ứng cử viên áp dụng. Độ phân giải quá tải chọn quá tải và biên dịch thứ hai thành công.

Bây giờ bạn thay đổi lắp ráp Alpha để thiết lập của Charlie.P là công khai. Bạn biên dịch lại Echo. Bây giờ bạn nhận được một lỗi độ phân giải quá tải bởi vì cả hai tình trạng quá tải của M đều có giá trị như nhau và không tốt hơn cái kia. Biên dịch Echo không thành công do sự thay đổi trong Alpha. Thay đổi của bạn đối với Alpha là một thay đổi đột phá.

Câu hỏi không phải là "đây có phải là thay đổi đột ngột không?" Rõ ràng là; hầu hết mọi thay đổi là một loại thay đổi đột phá. Câu hỏi đặt ra là liệu sự thay đổi đột phá trên thực tế có thực sự phá vỡ bất kỳ ai hay không, và nếu vậy, chi phí sửa chữa điểm ngắt so với lợi ích của tính năng mới là gì?

Answer 2

Điều này tùy thuộc vào mức độ nghiêm ngặt mà bạn muốn trở thành "phá vỡ thay đổi".

Một định nghĩa là: nó có phá vỡ việc xây dựng hoặc thực hiện mã giới thiệu hay không.

Khác là, mã khác có thể xác định rằng bạn đã thực hiện thay đổi hay không.

Theo định nghĩa đầu tiên, đây không phải là thay đổi đột phá. Theo định nghĩa thứ hai, đó là một thay đổi phá vỡ.

Answer 3

tôi không nghĩ nhưng bạn nên biết sự khôn ngoan đằng sau để làm cho thiết lập riêng này là gì. các công cụ sửa đổi truy cập rất quan trọng đối với người tiêu dùng thư viện và trong việc đóng gói.

Answer 4

Nó có thể là, nếu những hội đồng khác sử dụng sự phản chiếu để kiểm tra sự hiện diện của setter.

Nhưng mã bị ràng buộc sớm sẽ không bị hỏng.

Một điều cần xem xét là liệu đây có phải là thay đổi về ngữ nghĩa hay không. Nếu thuộc tính trước đây chỉ được đặt trong khi xây dựng và giờ đây có thể được sửa đổi bất kỳ lúc nào, điều đó chắc chắn có thể phá vỡ người tiêu dùng đã lưu trữ giá trị, sử dụng nó làm khóa Từ điển, v.v.

Answer 5

Do khả năng hiển thị của thuộc tính được tăng lên bây giờ không nên có bất kỳ vấn đề với hội đồng liên kết tĩnh và tài liệu tham khảo tĩnh - những hội đồng chỉ xử lý tài sản của bạn như là chỉ đọc cho đến bây giờ và họ tiếp tục làm như vậy.

Vấn đề duy nhất có khả năng xảy ra ở đây là nếu một số hội đồng sử dụng phản chiếu để nhận thông tin về thuộc tính của bạn và thực hiện một số hành động.

Ví dụ, nếu đây là một tài sản của một đối tượng kinh doanh và bạn sử dụng dữ liệu ràng buộc để hiển thị dữ liệu của bạn trong một số kiểm soát, như GridView hoặc ListView (độc lập với khuôn khổ thực tế), nó có thể là rằng đây tài sản sẽ được công nhận là "updateable" bây giờ và người dùng có thể thay đổi một số giá trị bạn (và một số hội đồng khác) được coi là bất biến cho đến nay.

Answer 6

Đó là một thay đổi đột phá, ở chỗ nó có thể khiến mã hiện tại không còn biên dịch.

Một số ngôn ngữ không cho phép bạn ghi đè thuộc tính mà không ghi đè tất cả người truy cập hiển thị. VB là một ngôn ngữ như vậy.

Giả sử bạn có các lớp học C# sau:

namespace TestLibrary 
    public class A { 
     public virtual int X { 
      get { return 0; } 
      private set { Console.WriteLine("A.set_X called."); } 
     } 
    } 
} 

Trong một dự án VB tham chiếu đến thư viện của bạn, bạn có một định nghĩa lớp:

Class B : Inherits TestLibrary.A 
    Public Overrides ReadOnly Property X As Integer 
     Get 
      Return MyBase.X 
     End Get 
    End Property 
End Class 

Thông báo các ReadOnly sửa đổi trên tài sản. Điều này là bắt buộc trong VB, bởi vì bạn chỉ xác định getter.Nếu bạn để nó ra, bạn nhận được một lỗi thời gian biên dịch:

Property without a 'ReadOnly' or 'WriteOnly' specifier must provide both a 'Get' and a 'Set'.

Bây giờ, loại bỏ các private modifier từ setter trong C# lớp:

namespace TestLibrary 
    public class A { 
     public virtual int X { 
      get { return 0; } 
      set { Console.WriteLine("A.set_X called."); } 
     } 
    } 
} 

Bây giờ bạn sẽ có được một thời gian biên dịch lỗi trong mã VB của bạn:

'Public Overrides ReadOnly Property X As Integer' cannot override 'Public Overridable Property X As Integer' because they differ by 'ReadOnly' or 'WriteOnly'.

Mã tương tự tham chiếu đến thư viện của bạn không biên dịch sau khi bạn thực hiện thay đổi, do đó thay đổi đột ngột.