Tại sao chúng ta không có tiền tố Enums, lớp trừu tượng và cấu trúc?

Cộng đồng C # đã sử dụng rất phổ biến tiền tố "I" để biểu thị một giao diện mà ngay cả những lập trình viên thiếu kinh nghiệm nhất cũng biết sử dụng nó.

Tại sao sau đó chúng ta không có tiền tố enums, lớp trừu tượng hoặc cấu trúc (có thể với "E", "A" và "S" tương ứng)?

Ví dụ, nếu chúng ta đã đánh dấu tất cả các lớp trừu tượng bằng "A", nó sẽ cung cấp thông tin có giá trị về loại đó, trong khi nó có thể được suy ra, không rõ ràng ngay lập tức.

Xin lưu ý rằng tôi không ủng hộ sự thay đổi này, tôi chỉ đang cố gắng để hiểu tại sao chúng ta không làm mọi thứ theo cách này.

Chủ đề này trả lời tại sao chúng ta sử dụng tiền tố "I" nhưng không trả lời tại sao chúng ta không sử dụng các tiền tố khác.

Điểm của quy ước đặt tên cho các giao diện là đưa ra quyết định nhanh chóng, không có trí tuệ về việc gọi giao diện mà lớp của bạn thực hiện. Nếu bạn có một Frobnicator, nhưng phải khai báo một giao diện để tách rời hoặc bất kỳ lý do gì, thì quyết định gọi nó IFrobnicatorkhông đòi hỏi phải suy nghĩ có ý thức, và điều này là tốt.

Vấn đề tương tự không áp dụng cho các cấu trúc khác mà bạn đặt tên. Enums và structs là hữu ích, nhưng không cần thiết phải tìm một tên thứ hai , ngắn, minh bạch, rõ ràng liên quan ngoài tên của chính nó. Do đó, không có áp lực nào để đặt 'E' vào tên của enum hoặc struct.

(Các lớp trừu tượng có phần giống với giao diện, vì bạn phải cung cấp lớp cụ thể thứ hai để hoàn thành mọi thứ, vì vậy chúng có thể có được quy ước bắt đầu bằng 'A', nhưng vì lý do gì, chúng không làm. Tôi được phép suy đoán, tôi nghĩ rằng 'Tôi' là một lá thư đặc biệt hẹp có thể có liên quan đến điều đó.)

Tôi nghĩ nó không được sử dụng nhiều vì:

• hầu hết thời gian nó không ảnh hưởng nhiều nếu nó là một enum, hoặc một lớp trừu tượng hoặc một cấu trúc
• Nếu nó có vấn đề, tôi có thể thấy nó từ việc sử dụng và tìm ra khá nhanh
• nếu tôi thay đổi nó là một enum, lớp trừu tượng hoặc struct, tôi cũng phải đổi tên nó
• Đối với những người không biết quy ước thì đó là tiếng ồn thuần túy.
• mọi người có thể bỏ qua toàn bộ ý tưởng vì họ đã được dạy không sử dụng ký hiệu Hungary. Đã có và vẫn có những người nói rằng bạn không nên sử dụng ký hiệu Hungarion, mà không tạo ra sự khác biệt giữa Ứng dụng Hungary và Hệ thống Hungary. Một cuộc thảo luận tốt đẹp có thể được tìm thấy trong câu hỏi SO này . Không chỉ câu trả lời đầu tiên là thú vị mà còn có những câu trả lời và bình luận tuyệt vời. Từ câu hỏi tương tự đến bài viết này của Joel Spolsky (cuộn đến đoạn "Tôi là Hungary")

Tóm lại: Nói chung, giá trị gia tăng không cộng vào chi phí.

Từ điểm đạn cuối cùng và một số giải thích bạn có thể kết luận. Hệ thống Hungary (loại tiền tố) là xấu và không nên được sử dụng. Ứng dụng Hungary (loại tiền tố) có sử dụng.

Lấy lại câu hỏi của bạn Tôi nghĩ rằng ký hiệu được đề xuất của bạn là một dạng Ứng dụng Hungary và nếu bạn cảm thấy rằng giá trị gia tăng cộng với chi phí và bạn thực hiện nó một cách nhất quán trong cơ sở mã của mình thì nó vẫn ổn. Nhưng vì bạn phải xem xét nó trên cơ sở từng dự án nên nó không phải là một quy tắc chung.

Tôi đoán mọi người nhận thấy rằng nó đã tạo ra các giao diện thường xuyên hơn và đó là lý do tại sao nó trở thành một quy tắc chung cho các giao diện.

Chỉ cần một suy nghĩ (hy vọng có thể áp dụng):

Có một xu hướng rõ ràng về "mã hóa giao diện" hơn là các lớp cụ thể. "Ngày nay" dường như có lợi hơn khi có một quy ước đặt tên cho các lớp, như bắt đầu chúng bằng 'C', thay vì có chữ 'I' cho giao diện.

Tôi vừa kết thúc một dự án Java trong đó tất cả các Giao diện thực sự được gọi là Model .. Đúng, quy ước tên giao diện là kết thúc tên bằng 'Model' ... sau đó có một số loại 'DataTransferObject / DTO' thực hiện giao diện như :

public interface SomethingModel{
}

public class Something implements SomethingModel{
    //lets not line up braces and make it hard to read
    //at least it saves one line
}

trong khi ở C #

public interface ISomething{}

public class SomethingModel : ISomething
{
   //i can read this
}

Thưởng cho bộ não của tôi để giữ cho tổn thương thẳng, nhưng tôi có thể thấy làm thế nào nó có thể giúp nghĩ về các điều khoản lập trình cho giao diện.