Một lớp cho mỗi quy tắc tập tin trong .NET? [đóng cửa]

Tôi tuân theo quy tắc này nhưng một số đồng nghiệp của tôi không đồng ý với nó và lập luận rằng nếu một lớp nhỏ hơn thì có thể để lại trong cùng một tệp với các lớp khác.

Một lập luận khác mà tôi nghe thấy mọi lúc là "Ngay cả Microsoft cũng không làm điều này, vậy tại sao chúng ta phải làm thế?"

Sự đồng thuận chung về điều này là gì? Có những trường hợp nên tránh điều này?

Một lớp cho mỗi tệp cũng cung cấp cho bạn ý tưởng tốt hơn về những gì mỗi lần đăng ký đang thay đổi mà không cần nhìn vào sự khác biệt của tệp.

Tôi ghét nó khi mọi người nghĩ tuyệt đối và nói rằng bạn không bao giờ nên làm điều này hoặc điều đó với một cái gì đó chủ quan và kén chọn như thế này, như thể tất cả chúng ta cần phải tuân theo ý tưởng ngu ngốc của ai đó về đúng và sai. Điểm mấu chốt: có nhiều hơn một lớp cho mỗi tệp là hoàn toàn tốt nếu nó có ý nghĩa. Ý nghĩa của tôi là những thứ như:

1. Làm cho mã dễ tiêu hóa và duy trì hơn
2. Làm cho giải pháp bớt khó chịu hơn (cuộn qua vô số tệp không cần thiết) và chậm hơn
3. Nhóm phát triển ổn với nó như là một thực hành mã hóa địa phương

Một ví dụ thực sự tốt về lý do tại sao tôi có thể muốn nhiều lớp cho mỗi tệp:

Giả sử tôi có vài chục lớp ngoại lệ tùy chỉnh, mỗi lớp là 4 lớp, tôi có thể có một tệp riêng cho từng lớp hoặc tôi có thể nhóm các ngoại lệ và có một tệp cho mỗi nhóm. Đối với tôi, cách tiếp cận hợp lý / thực dụng nhất là nhóm chúng lại và chỉ cần một vài tệp, vì đó là thời gian / mã hóa hiệu quả hơn (tôi không phải nhấp chuột phải -> Thêm lớp, đổi tên, 50 lần) , nó giữ cho giải pháp ít lộn xộn hơn và thực hiện tốt hơn.

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Đôi khi tôi nhóm nhiều hơn một lớp trong một tệp nếu chúng được liên kết chặt chẽ và ít nhất một trong số chúng rất nhỏ.

"Thực hành tốt nhất" là có một tệp cho mỗi lớp.

Thay vì các đối số giả thuyết và thay vào đó tập trung vào Windows .NET với Visual Studio IDE và các dự án phần mềm đang phát triển, thật hợp lý khi có một lớp cho mỗi tệp.

Nói chung, để tham khảo trực quan, không có gì vượt qua một lớp trên mỗi tệp. Có thật không.

Tôi không biết Microsoft có làm hay không làm như vậy, tuy nhiên họ đã tạo partialtừ khóa để chia một lớp trên nhiều tệp (điều này thậm chí còn nghiêm trọng hơn). Nó thường được sử dụng để phân tách mã thiết kế được tạo tự động khỏi mã tùy chỉnh của bạn trong cùng một lớp (nhưng đôi khi được sử dụng để cho phép các nhà phát triển khác nhau làm việc trên lớp cùng một lúc thông qua các tệp khác nhau). Vì vậy, Microsoft thấy lợi ích của nhiều tệp và mọi người đều có ý nghĩ tổ chức nhiều tệp với .NET.

Đối với các lớp lồng nhau, bạn không có lựa chọn nào khác ngoài sử dụng một tệp hoặc ít nhất là các phần đầu tiên của các lớp trong chúng. Một tập tin là cần thiết và tốt trong trường hợp này:

class BicycleWheel {
    class WheelSpoke {
    }
}

Nếu không, tại sao bạn sẽ giữ nhiều lớp trong một tệp? Đối số "vì chúng nhỏ" hoặc liên kết với nhau không giữ được nhiều nước vì cuối cùng các lớp của bạn sẽ được liên kết với các lớp khác. Cuối cùng, bạn không thể dễ dàng suy ra việc tổ chức các đối tượng trong tệp dựa trên việc sử dụng chúng, đặc biệt là khi phần mềm tiếp tục phát triển.

Ngoài ra, nếu bạn sử dụng các thư mục cho không gian tên thì bạn sẽ không bao giờ có xung đột tên tệp lớp. Thật thuận tiện để định vị một lớp bằng tên tệp trên hệ thống tệp khi không ở trong môi trường phát triển như Visual Studio (ví dụ: nếu bạn muốn nhanh chóng chỉnh sửa một lớp bằng Notepad hoặc một cái gì đó nhanh / nhẹ ).

Rất nhiều lý do chính đáng ...

Trong phần lớn các trường hợp, tôi tuân theo quy tắc một lớp cho mỗi tệp. Ngoại lệ duy nhất tôi thường xuyên đưa ra là định nghĩa về một enum được liên kết chặt chẽ với một lớp cụ thể. Trong trường hợp đó, tôi sẽ thường xuyên đưa định nghĩa của enum vào tệp của lớp đó.

Tôi cũng tin rằng nên có một loại trong một tệp duy nhất.

Có một ngoại lệ cho quy tắc này phải được đề cập: Có hai lớp chỉ khác nhau bởi một đối số chung chung như:

RelayCommand     

và

RelayCommand<T>

Thực sự, điều này sôi theo sở thích cá nhân. Mọi người sẽ nói "một lớp cho mỗi tệp", nhưng tất cả chúng ta đều có lý do để tránh điều đó trong một số trường hợp nhất định. Tôi đã từng có một dự án lớn có khoảng 300 enum khác nhau. Tôi sẽ không có 300 tập tin riêng biệt, mỗi tập tin cho mỗi lớp, khi một số enum chỉ là ba trạng thái.

Ngoài ra, đối với những người không thể tìm thấy các lớp nhất định nếu họ không có tất cả trong các tệp được đặt tên theo họ, có lý do gì bạn không sử dụng Tìm kiếm trong toàn bộ giải pháp không? Sử dụng Tìm giúp tôi tiết kiệm thời gian di chuyển qua Solution Explorer.

Cho dù nội dung có nhẹ đến đâu, tôi nghĩ một lớp / giao diện / vv cho mỗi tệp là điều cần thiết.

Nếu tôi đang làm việc với một giải pháp lớn trong Visual Studio, tôi muốn có thể xem các tệp và không phải đi sâu vào bên trong để xem. Ngay cả với các công cụ điều hướng như ReSharper, tôi muốn ánh xạ 1: 1.

Nếu bạn tìm thấy rất nhiều tệp nguồn có ít hoặc không có nội dung (có thể mở rộng một lớp nhưng không thêm gì vào đó) thì có lẽ bạn nên suy nghĩ lại về thiết kế của mình.

Tôi thấy rằng việc nhóm một lớp với lớp nhà máy tiêu chuẩn trong cùng một tệp là rất hữu ích.

Tôi thường sẽ có một lớp cho mỗi tệp nhưng thông thường bạn sẽ phải sử dụng ý của mình để xem liệu tệp có thể chứa các lớp liên quan hay không, ví dụ như nhóm các trường hợp ngoại lệ của bạn và các nhà phát triển khác có thể sử dụng lại. Trong trường hợp này, người dùng chỉ cần một tệp được bao gồm chứ không phải nhiều tệp.

Vì vậy, vấn đề là: nên sử dụng tùy ý !!!

Trong các giải pháp lớn hơn tôi nghĩ rằng rất có giá trị khi có một lớp cho mỗi tệp và tệp đó được đặt tên giống như lớp. Nó làm cho nó dễ dàng hơn nhiều để xác định mã bạn cần làm việc.

Công cụ StyleCop cho C # có các quy tắc tiêu chuẩn yêu cầu không quá một lớp cấp cao nhất trong một không gian tên (cộng với bất kỳ số lượng giao diện, đại biểu và enum nào trong không gian tên đó).

Trong trường hợp có hai hoặc nhiều lớp trong đó lớp thứ hai và lớp tiếp theo chỉ được sử dụng bởi lớp thứ nhất, những lớp đó có thể và nên là lớp bên trong, chỉ hiển thị cho lớp tiêu thụ.

Thỉnh thoảng một lớp cho mỗi tệp, nhưng ...

Khi nhiều lớp có liên quan chặt chẽ với nhau, nhiều hơn một lớp trong cùng một tệp nguồn là IMHO, TỐT HƠN so với việc dành một tệp nguồn ngắn cho mỗi lớp. Nguồn dễ đọc và gọn hơn (và sử dụng #region, cùng một nguồn có thể được cấu trúc nhiều hơn trước).

Ngoài ra, hãy xem xét rằng đôi khi CẦN PHẢI trải cùng một lớp trên các tệp khác nhau (sử dụng một phần ), vì có tệp nguồn 20000+ không tiện dụng ngay cả với RAM tôi có sẵn (nhưng đây là một câu hỏi khác).

Thỉnh thoảng tôi sẽ rời một lớp nhỏ với một lớp lớn hơn nhưng chỉ khi chúng có liên quan rất chặt chẽ như một đối tượng và đó là lớp sưu tập hoặc nhà máy.

Có một vấn đề với điều này mặc dù. Cuối cùng, lớp nhỏ phát triển đến điểm mà nó sẽ nằm trong tệp riêng của nó, nếu bạn di chuyển nó sang tệp mới, bạn sẽ dễ dàng truy cập vào lịch sử sửa đổi của mình.

I E.

• vào thứ hai, tôi thay đổi các lớp x và y trong tệp y.css
• vào thứ ba, tôi tách lớp x vào tập tin x.css của riêng mình vì nó đã phát triển lớn
• vào thứ tư, sếp của tôi muốn xem những gì tôi đã thay đổi trong lớp x vào thứ hai để anh ấy nhìn vào lịch sử của x.css, chỉ x.css không hiển thị lịch sử trước khi thay đổi thứ ba.

Đó có thực sự là một vấn đề không? :) Các
lớp học thực sự nhỏ, giống như enums, có thể được đặt cùng với những người khác. Có một quy tắc phải tuân theo: chỉ tập hợp các lớp có điểm chung.

Như một sự lạc quan - trong một trong các dự án của tôi, tôi có một tệp có 150 lớp bên trong. Các tập tin có 10000 dòng mã. Nhưng nó được tạo tự động nên hoàn toàn chấp nhận được :)

Một lý do để đưa nhiều lớp liên quan vào một tệp là để kẻ khốn nghèo sử dụng API của bạn không phải mất nửa ngày để nhập bản khai báo nhập khẩu và tên khốn tội nghiệp phải duy trì mã không phải mất một nửa một ngày cuộn qua bản kê khai nhập khẩu. Nguyên tắc nhỏ của tôi là nhiều lớp thuộc cùng một tệp nếu bạn hầu như luôn luôn sử dụng một tập hợp con lớn của chúng cùng một lúc thay vì chỉ một lớp một lần.

Tôi làm điều này, nhưng chỉ khi các lớp có liên quan theo kiểu cha mẹ con và các lớp con CHỈ được sử dụng bởi cha mẹ.

Tôi thường gắn bó với một lớp cho mỗi tập tin. Nhưng tôi sẽ tạo ra ngoại lệ cho các nhóm cấu trúc tương tự được sử dụng trên toàn dự án. Ví dụ:

• Một EventArss.cs có chứa bất kỳ EventArgslớp con nào , vì chúng thường chỉ có 5-10 dòng mã, nhưng chúng thường được sử dụng bởi một số lớp khác nhau. Ngoài ra, tôi có thể đặtEventArgs lớp trong cùng một tệp với lớp khai báo các sự kiện.
• Một Delegates.cs có chứa các Đại biểu được sử dụng trong toàn dự án, vì chúng thường chỉ có 1 dòng. Một lần nữa, cách khác là đặt chúng vào cùng một tệp với lớp phơi bày / tiêu thụ chúng.
• Một Enums.cs có chứa enums được sử dụng trong suốt dự án. (Nếu có một enumthứ chỉ được sử dụng bởi một lớp, tôi thường sẽ sử dụng nó privatecho lớp đó.)

Một phiếu bầu khác cho một lớp cho mỗi tệp với tệp được đặt tên giống như lớp. Đối với tôi, nó giúp duy trì lâu dài. Tôi có thể dễ dàng xem qua kho lưu trữ và xem các lớp nào là một phần của giải pháp mà không cần phải mở dự án hoặc bất kỳ tệp nào.

Tôi theo nó 99% thời gian. Thực hiện theo các tiêu chuẩn là tốt, nhưng tôi cũng tin rằng sự linh hoạt có chỗ đứng của nó. Đôi khi nó chỉ có vẻ như một sự lãng phí thời gian ngớ ngẩn để phá vỡ mọi thứ. Trong những lúc đó, tôi vượt qua chính mình và chỉ viết mã của mình.

Các câu trả lời cho đến nay dường như xoay quanh các ngoại lệ của mọi người đối với quy tắc, vì vậy đây là của tôi: Tôi giữ các lớp và các lớp 'bạn thân' siêu dữ liệu của họ cùng nhau khi sử dụng gói DataAnnotations trong .NET3.5 SP1. Mặt khác, chúng luôn nằm trong các tệp riêng biệt. Bạn biết đấy, hầu hết thời gian. Ngoại trừ khi họ không.

Tôi chỉ làm điều này hiếm khi. Ví dụ, nếu có một phép liệt kê hoặc cấu trúc có liên quan chặt chẽ với lớp nhưng quá tầm thường để tự tách ra.

Hoặc một lớp riêng để chứa một số phương thức mở rộng cho lớp chính đó.

One case could be:khi các lớp của bạn cùng nhau tạo thành một module / unitlớp phục vụ một số lớp chính như helper classes, khôn ngoan khác không .

hãy xem mã nguồn dự án ASP.NET MVC 2.0 . Nó tuân thủ nghiêm ngặt quy tắc này

Tôi thích ý tưởng tạo ra các lớp nhỏ hơn và đảm bảo rằng lớp đó chỉ làm những gì nó phải làm. Nếu bạn có nhiều lớp đang góp phần giải quyết một vấn đề thì không có hại gì khi đặt chúng cùng một tệp.

Tôi sẽ không tuân theo các thực hành MS vì chúng không phải là THỰC HÀNH TỐT NHẤT!

Một điểm khác tôi chưa thấy ai khác đề cập đến là khi bạn phát triển bằng cách sử dụng một lớp cho mỗi quy tắc tệp, bạn có thể dễ dàng thấy lớp cụ thể đó đang sử dụng cái gì.

Ví dụ: bạn có thể có hai lớp trong đó một lớp sử dụng Linq và lớp kia thì không.

Nếu các lớp này nằm trong cùng một tệp, bạn sẽ không thể biết được nếu không xem qua mã mà lớp sử dụng cái gì. Khi nó là một lớp cho mỗi tệp, tất cả những gì bạn phải làm là nhìn vào đầu tệp để xem chính xác những gì đang được sử dụng trong lớp đó. Giúp nếu bạn đã từng chuyển sang một lib mới, v.v.

Một lý do khác cho một tệp mỗi lớp chưa được đề cập trong các câu trả lời được đăng cho đến nay là vì một tệp cho mỗi tệp giúp dễ hiểu hơn về tác động của PR trong quá trình đánh giá mã. Nó cũng làm giảm xung đột hợp nhất.

Khi ai đó đăng PR cho phản hồi, tôi có thể xem danh sách các tệp đã thay đổi và ngay lập tức thấy bất kỳ sự trùng lặp nào với những gì tôi có thể đang làm việc. Tùy thuộc vào sự chồng chéo, tôi có thể muốn xem mã của họ sâu hơn hoặc cho nó ổn vì tôi khá tự tin rằng nó sẽ không ảnh hưởng đến những thay đổi của chính tôi.

Khi hai người đang làm việc trong một tệp nhiều lớp và cả hai thêm một phụ thuộc, rất có thể bạn sẽ gặp xung đột hợp nhất trong using khối ở trên cùng. Việc tách các lớp thành các tệp sẽ tách các phần phụ thuộc để bạn có thể thấy mỗi lớp đang sử dụng và bạn không gặp phải xung đột như thế này.

Có các trường hợp ngoại lệ cho quy tắc này (giao diện + triển khai, enums, ...) nhưng đó là nơi khởi đầu tốt hơn so với điều ngược lại thường cho phép các nhà phát triển cơ sở bó tất cả các loại lớp không liên quan vào cùng một tệp.

Một lớp cho mỗi tệp là một quy tắc rõ ràng rõ ràng không chịu sự giải thích.

Các lớp liên quan trong tệp có thể tùy theo sở thích và giải thích cá nhân (như bạn có thể thấy từ tất cả các câu trả lời khác ở đây về việc sử dụng nó có ổn không) và do đó là một quy tắc kém.

Việc quay lại rất thú vị và dường như không có kết luận, mặc dù ấn tượng chung của tôi là ánh xạ 1-1 giữa các lớp và các tệp là ý kiến ​​đa số, mặc dù với một số trường hợp ngoại lệ.

Tôi tò mò liệu bất kỳ câu trả lời nào của bạn khác nhau tùy thuộc vào việc bạn có: (1) phát triển ứng dụng Windows Forms, ứng dụng Web, Thư viện hay bất cứ điều gì; hoặc (2) có sử dụng Visual Studio hay không. Khi sử dụng VS, có vẻ như một quy tắc một lớp cho mỗi tệp cũng sẽ ngụ ý một lớp cho mỗi dự án VS vì sự đồng thuận trong các luồng khác dường như là các giải pháp / dự án của VS nên được nhân đôi trong cấu trúc và tên của thư mục / tệp. Thật vậy, ấn tượng của tôi là sự đồng thuận là có tên không gian tên của tên dự án = tên tập hợp = (lồng nhau), tất cả sau đó sẽ được nhân đôi trong tên và cấu trúc thư mục / tệp. Nếu đó là những hướng dẫn (hoặc quy tắc) phù hợp, thì tất cả các cơ chế tổ chức dường như trực giao này sẽ vẫn được giữ đồng bộ.

Có để dễ đọc, chúng ta nên có một tệp cho mỗi lớp!. Chỉ cần nhảy vào một dự án. Tôi thấy nhiều lớp trong một tập tin. nó chỉ làm cho một người mới khó hiểu nó. chúng ta không nên nghĩ đến bảo trì? Khi chúng ta phát triển một phần mềm? nhiều lần phát triển sẽ tiếp tục bởi các nhà phát triển khác. Chúng tôi có không gian tên để sắp xếp công cụ của chúng tôi, chúng tôi không cần tệp để làm điều đó!.

Một mục mã cho mỗi tệp, có.

Mọi thứ khác là một sơ suất - và, thật lòng mà nói, một dấu hiệu của nạn nhân RAD.

Ngay khi một người bắt đầu phát triển phần mềm thích hợp (IoC, các mẫu thiết kế, DDD, TDD, v.v.) và để lại "omg hãy thực hiện điều này, tôi không biết làm thế nào, nhưng tôi được trả tiền", tôi sẽ thấy rằng quy tắc này thực sự, thực sự, vấn đề.