Xung đột Enum và Xung đột đặt tên thuộc tính

Question

Có một số câu hỏi liên quan here và here, nhưng chúng không thực sự mang lại cho tôi câu trả lời thỏa đáng. Vấn đề là các enums lồng trong một lớp trong C# không thể có cùng tên như một thuộc tính của lớp. Ví dụ của tôi:

public class Card 
{ 
    public enum Suit 
    { 
     Clubs, 
     Diamonds, 
     Spades, 
     Hearts 
    } 

    public enum Rank 
    { 
     Two, 
     Three, 
     ... 
     King, 
     Ace 
    } 

    public Suit Suit { get; private set; } 
    public Rank Rank { get; private set; } 
    ... 
} 

Có một vài tùy chọn để giải quyết vấn đề này, nhưng có vẻ như không phù hợp với tôi.

Tôi có thể di chuyển các enums ra ngoài lớp học, nhưng sau đó bạn chỉ cần nói Suit thay vì Card.Suit, điều này có vẻ sai với tôi. Suit nằm ngoài ngữ cảnh của Card là gì?

Tôi có thể di chuyển chúng ra ngoài lớp và thay đổi chúng thành một thứ như CardSuit và CardRank, nhưng sau đó tôi cảm thấy như tôi đang nướng thông tin ngữ cảnh vào tên của enum, khi điều đó phải được xử lý bởi một lớp hoặc tên không gian tên.

Tôi có thể thay đổi tên của các enums thành Suits và Ranks, nhưng điều này vi phạm Microsoft's naming guidelines. Và nó không cảm thấy đúng.

Tôi có thể thay đổi tên thuộc tính. Nhưng với cái gì? Nó cảm thấy trực giác với tôi muốn nói Suit = Card.Suit.Spades.

Tôi có thể di chuyển các enums vào một lớp tĩnh riêng biệt được gọi là CardInfo chỉ chứa các enums này. Nếu tôi không thể nghĩ ra điều gì khác, tôi nghĩ đây là lựa chọn tốt nhất.

Vì vậy, tôi tự hỏi những gì người khác đã làm trong các tình huống tương tự. Nó cũng sẽ được tốt đẹp để biết lý do tại sao điều này là không được phép. Có lẽ Eric Lippert hay ai đó có thể kêu gọi quyết định cấm nó? Dường như nó chỉ tạo ra sự mơ hồ trong lớp học và điều này có thể được giải quyết bằng cách buộc sử dụng this.Suit cho tên thuộc tính. (Tương tự như định hướng giữa người dân địa phương và các thành viên.) Tôi cho rằng điều này đã bị bỏ sót do điều "every feature starts with -100 points", nhưng tôi sẽ tò mò về các cuộc thảo luận xung quanh vấn đề này.

Answer 1

Nó cũng sẽ được tốt đẹp để biết tại sao điều này là không được phép. Có lẽ Eric Lippert hay ai đó có thể kêu gọi quyết định cấm nó?

Điểm của quy tắc là để đảm bảo rằng không có sự mơ hồ trong lớp khi tra cứu tên. Một số vùng mã được chỉ định là xác định 'không gian khai báo'. Nguyên tắc cơ bản của không gian khai là không có hai điều tuyên bố trong không gian khai cùng có cùng tên (trừ phương pháp, trong đó phải khác nhau bởi chữ ký, không tên.)

Làm ngoại lệ cho quy tắc này chỉ làm cho mọi thứ trở nên khó hiểu hơn, không ít gây nhầm lẫn. Tôi đồng ý rằng nó là vexing rằng bạn không thể có một tài sản và enum của cùng một tên tuyên bố trong cùng một không gian khai báo, nhưng một khi bạn bắt đầu thực hiện trường hợp ngoại lệ sau đó nó chỉ được một mess. Nó thường là một tài sản tốt đẹp mà một tên duy nhất xác định một nhóm phương pháp, loại tham số, tài sản, và như vậy.

Lưu ý rằng quy tắc này áp dụng cho mọi thứ được khai báo trong không gian khai báo, không phải mọi thứ được sử dụng trong không gian khai báo. Hoàn toàn hợp pháp để nói "Suit Suit công cộng {get; set;}" với điều kiện là loại Suit không được khai báo trong cùng một không gian khai báo như thuộc tính. Khi ai đó nói "Suit.X", tìm hiểu xem X có thuộc loại (tức là, X là một thành viên tĩnh) hay thuộc tính (tức là X là một thành viên thể hiện) là một chút khó khăn. Xem bài viết của tôi về cách chúng tôi làm điều đó để biết chi tiết:

http://blogs.msdn.com/ericlippert/archive/2009/07/06/color-color.aspx

Answer 2

Tôi thích đặt tên cho enums bằng danh từ, sau đó là Tùy chọn. Trong trường hợp của bạn:

SuitOptions 
RankOptions 

Sau khi tất cả, enum chỉ là một tập hợp các tùy chọn có thể, phải không?

Bạn sẽ có sau đó:

myCard.Suit = Card.SuitOptions.Clubs; 

Mà theo ý kiến ​​của tôi có ý nghĩa và bạn vẫn có thể biết khi xem văn bản cho dù là sau đó enum hoặc bất động sản.

Answer 3

Tôi sẽ di chuyển các liệt kê bên ngoài định nghĩa lớp và sử dụng không gian tên để chỉ ra rằng chúng liên quan đến thẻ. Tôi thường không thích enums lồng trong lớp học. Bạn đang đúng về đa số, mặc dù: số ít cho enums thường xuyên, số nhiều cho lá cờ enums.

Answer 4

Enums của bạn về cơ bản là các kiểu dữ liệu mà bạn đã xác định. Bạn sẽ không sử dụng 'int' hoặc 'string' làm tên thành viên, vì vậy tôi nghĩ rằng đó là một ý tưởng không kém khi sử dụng tên enum và tên thành viên trong trường hợp của bạn.

Answer 5

Tôi đồng ý di chuyển định nghĩa enum sang một địa điểm riêng biệt.Hiện nay, sự đếm chỉ hiển thị thông qua thẻ, vì vậy nếu bạn muốn kiểm tra một ace, bạn sẽ phải làm

if (card.CardSuit == Card.Suit.Ace) { } //need different name for Suit field 

đâu nếu bạn di chuyển nó đến một định nghĩa riêng biệt, bạn có thể làm điều này nếu bạn đã thực hiện nó toàn cầu:

if (card.Suit == Suit.Ace) { } //no naming clashes, easier to read 

Answer 6

It't thú vị để thấy rằng trong khi Microsoft Naming Guidelines nói rằng bạn nên sử dụng một tên đặc biệt đối với hầu hết enums và tên số nhiều cho các lĩnh vực bit, the code sample for the enum keywordlàm sử dụng tên số nhiều!

enum Days { Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, Saturday };