Có phải hằng số công cộng là xấu Bad?


38

Co phải đây la:

public MyClass
{
    public const string SomeString = "SomeValue";
}

tệ hơn thế này:

public MyClass
{
    public static string SomeString { get{ return "SomeValue";}}
}

Cả hai có thể được tham chiếu theo cùng một cách:

if (someString == MyClass.SomeString)
     ...

Thứ hai, tuy nhiên, có sự bảo vệ là một tài sản. Nhưng thực sự điều này tốt hơn bao nhiêu so với một const?

Tôi đã học được nhiều lần về những nguy hiểm của việc có các lĩnh vực công cộng. Vì vậy, khi tôi thấy một số mã sử dụng các hằng số này trên các trường công khai, tôi lập tức thiết lập về việc tái cấu trúc chúng thành các thuộc tính. Nhưng được nửa đường, tôi đã tự hỏi nó có lợi gì khi có các thuộc tính tĩnh so với các hằng số.

Có ý kiến ​​gì không?


1
Hằng số công cộng được sử dụng theo cách này là tốt. Sử dụng các thuộc tính theo cách này là quá mức cần thiết.
Bernard

2
Bạn đã cân nhắc sử dụng từ khóa chỉ đọc chưa? ReadOnly cung cấp cho bạn bản tổng hợp sạch hơn của một const mà không có vấn đề được đề cập trong nhiều bài viết.
Matt Raffel

Cũng có thể làm ... kiểu công khai chỉ đọc tĩnh ConstantName = 0;
Snoop

Câu trả lời:


56

Trong C #, nó rất tệ vì không có lý do nào được đề cập trong chủ đề này.

Các hằng số công cộng trong C # được đưa vào các cụm tham chiếu. Có nghĩa là, nếu bạn có một sốOOtherClass trong một cụm lắp ráp riêng tham chiếu đến một sốStStSt trong MyClass, CIL được tạo cho someOtherClass sẽ chứa một chuỗi "someValue" được mã hóa cứng.

Nếu bạn đi triển khai lại dll chứa MyClass chứ không phải someOtherClass và thay đổi const, thì AnotherOtherClass sẽ không chứa những gì bạn nghĩ - nó sẽ chứa giá trị ban đầu.

Nếu bạn tích cực 100% thì đó là hằng số phổ quát như Pi, phát điên; Nếu không thì cẩn thận.

Đây là một lời giải thích tốt hơn: https://stackoverflow.com/questions/55984/what-is-the-difference-b between-const-and-readonly


3
@Oded, nhưng sự khác biệt giống nhau là giữa constvà thuộc tính chỉ đọc. constđược đưa vào hội nghị gọi, thuộc tính chỉ đọc không.
Svick

1
Đây là điều mà tôi không biết. Nó là bằng chứng nữa rằng các lĩnh vực công cộng là xấu. Tôi nghĩ ngay cả ví dụ "an toàn" của Pi cũng là một ý tưởng tồi (Thế còn khi nhà phát triển muốn có nhiều hoặc ít chữ số chính xác hơn trên Pi? giải pháp và tôi có thể thấy điều này thực sự cắn chúng tôi nếu chúng tôi không cẩn thận.
Núi lửa

2
"Sao chép" này có xảy ra trong bất kỳ phần nào khác của C # không? (tức là enums)
Vaccano

2
Vâng, bản sao không xảy ra. Đây thường không phải là một vấn đề, nhưng nếu mã của bạn sử dụng giá trị số của Enum và nó được thay đổi theo cách được nêu trong câu hỏi này, thì điều đó có thể gây ra vấn đề.
Vaccano

1
Đây là một trong những lý do chính tại sao consttrong C # bị câm. Chúng tôi cần hỗ trợ tốt hơn cho bất biến ...
KChaloux

22

Thay đổi một lĩnh vực thành một tài sản là một sự thay đổi đột phá. Bạn mất khả năng tương thích nhị phân, nguồn và phản xạ.

Ngoài ra:

  • Có nhiều kiểm soát truy cập chi tiết hơn với các thuộc tính. Cần nó để được công khai nhưng thực sự chỉ muốn nó được thiết lập với quyền truy cập được bảo vệ? Không có vấn đề gì (từ C # 2 trở đi, ít nhất).
  • Bạn muốn đột nhập vào trình gỡ lỗi bất cứ khi nào giá trị thay đổi? Chỉ cần thêm một điểm dừng trong setter.
  • Bạn muốn đăng nhập tất cả quyền truy cập? Chỉ cần thêm đăng nhập vào getter.
  • Các thuộc tính được sử dụng để liên kết dữ liệu; lĩnh vực không.

http://csharpindepth.com/articles/ch CHƯƠNG8 / productsmatter.aspx

Tất cả những gì đã nói, tôi không thấy các hằng số thực sự bị ảnh hưởng như thế nào (đặc biệt là nếu bạn không cần bất kỳ tính năng nào ở trên), trừ khi API của bạn thay đổi theo cách chúng không còn là hằng số.


11

Sự nguy hiểm của các lĩnh vực công cộng trong thực tế là chúng có thể thay đổi và việc thực hiện bên dưới chúng có thể thay đổi.

Khi nói đến constđiều này thường không phải là một vấn đề (tương tự như bảng liệt kê công khai) - trừ khi bạn nghĩ rằng ý constchí cuối cùng có thể thay đổi và bạn sẽ yêu cầu đóng gói xung quanh người truy cập vào một lúc nào đó (nói để đăng nhập bao nhiêu lần nó đã được xem lên), bạn cũng có thể giữ nó như một công khai const.


1

Một hằng số là dữ liệu. Thuộc tính ngụ ý khả năng của hành vi khi bạn "nhìn" vào giá trị.

Hành vi đi kèm (hoặc khả năng trong tương lai) với dữ liệu không đổi là hoàn toàn sai. Đối với hầu hết các hệ thống, nó sẽ không thực sự quan trọng, nhưng nó có thể.

Hãy nói rằng giá trị là "PI" và được sử dụng rộng rãi trong các tính toán của hệ thống. Đặt nó phía sau các thuộc tính sẽ buộc các lập trình viên khách hàng lập trình phòng thủ. Họ phải gán giá trị thành một hằng số trùng lặp. Nếu họ không lừa đảo, phiên bản tiếp theo thư viện có thể có một số "hành vi" không mong muốn được giới thiệu đằng sau tài sản. Hành vi của tài sản (nếu nó trong một thư viện được biên dịch) là không xác định. Có thể nó hoạt động tốt trong thử nghiệm, nhưng có thể có mã ẩn thực thi nếu một điều kiện đặc biệt được đáp ứng. Đây không phải là một tối ưu hóa trước khi trưởng thành. Đặc biệt đối với một hệ thống thời gian thực, cuộc sống của mọi người phụ thuộc vào.

Các lập trình viên khách hàng thậm chí có thể mất sự an toàn của hằng số vì ngôn ngữ có thể không cho phép họ gán giá trị thuộc tính vào hằng số trùng lặp của họ.

Ngoài ra, khi các lập trình viên buộc phải gán giá trị tài sản của bạn vào hằng số riêng của họ, họ sẽ vô hiệu hóa bất kỳ hành vi nào bạn muốn thực hiện với tài sản của mình.

Dữ liệu không đổi thực sự không cần hoặc không muốn đóng gói.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.