Bạn có nên giữ tất cả các enums ở một nơi không?

Question

Khi tôi xây dựng một thư viện lớp, tôi thường tạo một tệp Enums.cs để giữ tất cả các enums được sử dụng trong assembly. Dưới đây là ví dụ:

namespace MyNamespace 
{ 
    public enum Colors 
    { 
     Red, 
     Green, 
     Blue 
    } 
    public enum Shapes 
    { 
     Circle, 
     Square, 
     Triangle 
    } 
} 

Điều này làm cho tất cả các enums của tôi dễ tìm, được tổ chức tốt và dễ truy cập trong mã.

Tôi tự hỏi liệu có lý do nào khiến điều này không phải là một ý tưởng hay không?

Answer 1

Nói chung tốt hơn là sắp xếp các định nghĩa theo mô đun, thay vì bằng hiện vật.

Answer 2

Chúng tôi thường có toàn bộ dự án, lắp ráp chứa tất cả các hằng số hằng số, Enums và phương thức trợ giúp của chúng tôi.

Vì vậy, CÓ, tôi sẽ khuyên bạn nên đặt chúng ở vị trí trung tâm, dễ truy cập.

Điều này sẽ cho phép bạn dễ dàng truy cập vào hội đồng từ các hội đồng khác, cố gắng tránh tham chiếu vòng tròn.

Answer 3

Cá nhân tôi nghĩ đây không phải là một ý tưởng hay. Tôi thích để giữ enums trong tập tin riêng của họ (một tập tin cho mỗi enum được xác định), giống như một lớp học. Điều này làm cho nó rõ ràng hơn (với tôi) nơi để đi nếu tôi đang tìm kiếm một loại, theo tên. Tôi đối xử với enums giống như một lớp hoặc cấu trúc, hoặc bất kỳ kiểu không gian tên nào khác, mà đối với tôi có nghĩa là một kiểu cho mỗi tệp.

Nhược điểm chính của cách tiếp cận phát sinh nếu bạn có nhiều Enums được xác định trong dự án của bạn - rằng "một tệp" có thể nhận được khá lớn.

Tuy nhiên, không có sự khác biệt về mặt kỹ thuật trong IL được biên dịch. Đây thực sự là một chiến lược cá nhân, tổ chức.

Answer 4

Tôi nghĩ điều đó tùy thuộc vào lĩnh vực mã họ áp dụng. Nếu tôi nhìn vào một hàm trong một lớp cụ thể, tôi sẽ mong đợi các enums liên quan ở gần đó.

Answer 5

Vâng, bạn có thể áp dụng cùng một lý do cho tất cả các loại đại biểu của bạn, tất cả các lớp học của bạn, tất cả các cấu trúc của bạn.

Bằng cách nhóm mọi thứ theo ý nghĩa của chúng đối với trình biên dịch, bạn sẽ mất cơ hội nhóm chúng theo cách có ý nghĩa với bạn. Trình biên dịch đã biết cách xử lý chúng theo ý nghĩa của chúng trong ngôn ngữ.

Cá nhân khi tôi muốn tìm các khai báo có liên quan đến "Trình phân tích cú pháp" trái ngược với "Hộp thoại cấu hình", tôi chuyển đến vị trí mã của tính năng đó được lưu giữ. Tôi không phải nhìn vào năm địa điểm khác nhau tùy thuộc vào các tính năng ngôn ngữ tôi đang sử dụng.

Answer 6

Tôi tìm hiểu thêm về tổ chức Không gian tên. Visual Studio làm cho nó quá dễ dàng để điều hướng đến một tuyên bố của đối tượng. Nó có ý nghĩa hơn với tôi để có một enum liên quan đến cơ sở dữ liệu/truy cập dữ liệu trong không gian tên MyData của tôi chứ không phải là một số không gian tên chung enum, tôi có thể quan tâm ít hơn về tên tập tin.

Answer 7

Có một số tên tệp mã nhất định ngay lập tức tăng cờ đỏ cho tôi. Cùng với utils.cpp, helpers.vb (hoặc tương tự) nếu tôi thấy một số enums.cs tôi ngay lập tức đặt câu hỏi liệu một phần của phần mềm có trở nên kết hợp với liệt kê hay không.

Các số đếm phải được sử dụng một cách tiết kiệm và được khai báo gần các loại lá (kiểu ít nhất được ghép đôi) mà chúng được liên kết với.

Thông thường, tôi đã thấy các hệ thống lớn bị kết hợp với nhau do các điều khoản chia sẻ. Trước khi quá lâu, ai đó sẽ có ý tưởng sáng sủa để liệt kê tất cả các khóa cơ sở dữ liệu chính.

Answer 8

Tôi là một người phát triển java nhưng tôi nghĩ tôi có thể trả lời ở đây ...

Đối với tôi, đó không phải là một ý kiến ​​hay. Giống như Daniel Earwicker cho biết bạn có thể làm tương tự cho các lớp ... bạn có thể xử lý toàn bộ ứng dụng của bạn trong một tệp duy nhất với nhiều lớp bên trong (tôi giả sử trong C# như trong Java bạn có thể có các lớp bên trong ...), nhưng bạn don ' t làm điều đó anyway ...

Và một enum đôi khi có thể là một cấu trúc phức tạp hơn, nó có thể có các thuộc tính ...

A (rất) dụ đơn giản trong Java:

public enum JobPriority { 
    HIGH(5), 
    MEDIUM_HIGH(4), 
    MEDIUM(3), 
    MEDIUM_LOW(2), 
    LOW(1) 
    ; 
    private int level; 
    JobPriority(int level) { 
     this.level = level; 
    } 
    public int getLevel() { 
     return level; 
    } 
} 

tôi làm việc trên một trang web tiếng Pháp rất lớn và chúng tôi có cấu trúc enum phức tạp hơn rất nhiều ... nếu chúng tôi có tất cả các enums của chúng tôi trong một tập tin duy nhất tập tin này sẽ làm cho hàng trăm dòng ...

Vì vậy, nếu ứng dụng của bạn là cấu trúc nhỏ và enum không phức tạp, bạn có thể đặt tất cả chúng trong một tệp.

Nhưng bạn muốn đặt các enums phức tạp vào các tệp đơn lẻ trên một không gian tên enum (gói trong java) và tạo một không gian tên enum khi cần thiết cho từng phần chức năng của ứng dụng của bạn. Đối với các enums đơn giản, tại sao không thêm vào sau đó trong một tệp enum chung cho một không gian tên đã cho (bạn có thể có nhiều tệp enums chung). Dunno nếu đó là một thực hành tốt.

Có thực sự quan trọng đối với bạn khi có nhiều tệp enum không? Nếu bạn cần phải tìm một enum, IDE của bạn có lẽ cung cấp cho bạn tìm kiếm lớp học nhanh chóng cho việc tìm kiếm một cách dễ dàng enums không? Bạn cũng có thể hậu tố tất cả các enums của bạn bằng xxxEnum.cs để phân biệt chúng (và cũng tìm chúng nhanh chóng bằng tên lớp * Enum).

Trong java webapp tôi đang làm việc (~ 2 triệu dòng mã, hàng trăm enums), chúng ta có thể dễ dàng tìm thấy enums trong IDE Eclipse với các phím tắt như ctrl + shift + R + * Enum. Nó nhanh hơn rất nhiều so với các tập tin enum thông thường :)