Làm cách nào để tránh sử dụng cùng một số nhận dạng cho Tên lớp và Tên thuộc tính?

Question

Dưới đây là một vài ví dụ về các lớp học và các tính chất chia sẻ cùng một định danh:

public Coordinates Coordinates { get; set; } 
public Country Country { get; set; } 
public Article Article { get; set; } 
public Color Color { get; set; } 
public Address Address { get; set; } 
public Category Category { get; set; } 

Vấn đề này xảy ra thường xuyên hơn khi sử dụng POCO với khung Entity như khung Entity sử dụng tên tài sản cho các mối quan hệ.

Vậy phải làm gì? Sử dụng tên lớp không chuẩn?

public ClsCoordinates Coordinates { get; set; } 
public ClsCountry Country { get; set; } 
public ClsArticle Article { get; set; } 
public ClsColor Color { get; set; } 
public ClsAddress Address { get; set; } 
public ClsCategory Category { get; set; } 

Yuk

Hoặc sử dụng tính mô tả hơn Tên tài sản?

public Coordinates GeographicCoordinates { get; set; } 
public Country GeographicCountry { get; set; } 
public Article WebArticle { get; set; } 
public Color BackgroundColor { get; set; } 
public Address HomeAddress { get; set; } 
public Category ProductCategory { get; set; } 

Ít hơn lý tưởng, nhưng có thể sống với nó.

Hoặc CHỈ SỐNG VỚI CNTT?

Các phương pháp hay nhất của bạn là gì?

Answer 1

Điều này đôi khi được gọi là vấn đề "Màu sắc" - và lời khuyên của tôi chỉ là để sống với nó.

Đặc tả ngôn ngữ C# đã được thiết kế để không phải là vấn đề. Từ phần 7.5.4.1 của C# 3 spec:

Trong một truy cập thành viên của các hình thức EI, nếu E là một định danh duy nhất, và nếu nghĩa của E là một đơn giản-name (§7.5. 2) là hằng số, trường, thuộc tính, biến số cục bộ hoặc tham số có cùng loại như ý nghĩa của E dưới dạng loại tên (§3.8), thì cả hai có thể là ý nghĩa của E. Hai ý nghĩa có thể có của E.I không bao giờ là không rõ ràng, vì tôi nhất thiết phải là một thành viên của loại E trong cả hai trường hợp. Nói cách khác, quy tắc đơn giản là cho phép truy cập vào các thành viên tĩnh và các loại lồng nhau của E, trong đó lỗi biên dịch nếu không sẽ xảy ra.

(Tiếp theo là một ví dụ.)

Rõ ràng khi bạn thể cung cấp một tên thuộc tính mô tả nhiều hơn, đó là tuyệt vời - nhưng khá thường xuyên tên tốt nhất thực sự là giống như tài sản.

này xảy ra trong khuôn khổ bản thân - ví dụ, HttpWebRequest.CookieContainer là loại CookieContainer, và có nhiều loại khác nhau với một loại tài sản của EvidenceEvidence.

Answer 2

Tôi cố gắng sử dụng nhiều tên thuộc tính mô tả hơn.

Thay đổi tên lớp có vẻ như đang đánh bại mục đích, vì hầu hết các nhà phát triển có xu hướng nhấn mạnh việc sử dụng các tên biến/thuộc tính tốt và mô tả.

Như trong ví dụ của bạn, ví dụ một địa chỉ acan được

public Address HomeAddress { get; set; } 
public Address PostalAddress { get; set; } 
public Address CompanyAddress { get; set; } 

vv Bạn có thể nhìn thấy nơi im đi với điều này.

Answer 3

Cá nhân tôi không ngại về việc có tên lớp và tên thuộc tính khớp với nhau nếu tên thực sự được áp dụng. Ví dụ, trên một lớp địa chỉ, có một tài sản được gọi là Country được gõ là một lớp có tên là Country có ý nghĩa và thực sự không có bất kỳ tên nào cho thuộc tính không thừa. Tôi cố gắng tránh va chạm bằng cách sử dụng tên thuộc tính mô tả, nhưng đôi khi tên cho thuộc tính và loại của nó là tên tốt nhất để sử dụng và sử dụng bất kỳ điều gì khác làm giảm sự rõ ràng hơn là cải thiện nó.

Tôi thực sự khuyên bạn nên sử dụng tiền tố giống như tiếng Hungary trên lớp học. Đó là chỉ đơn giản fugly.

Answer 4

Tôi nghĩ tên của một tài sản chỉ nên giải thích nó là gì. Khi nó là một Apple, chỉ cần đặt tên nó là một Apple.

Tại sao mọi người, chỉ để có thể đọc thuộc tính, hãy sử dụng tên người Hungary ở tên lớp. Nó làm giảm khả năng đọc tên lớp.

Khi truy cập vào các tài sản, bạn có thể sử dụng từ khóa này để ngăn ngừa chính mình để vô tình hiểu sai các tài sản như là một lớp:

class Food 
{ 
    public Apple Apple 
    { 
     get; 
     set; 
    } 

    public void DoIt() 
    { 
     this.Apple = new Apple(); 
    } 
} 

class Apple 
{ 
} 

Xem SA1101 của StyleCop "thẩm tra mà các cuộc gọi cho các thành viên địa phương được bắt đầu với 'điều này.' ký hiệu. "