Czy powinniśmy umieszczać klasy, wyliczenia i inne jednostki w swoich własnych plikach?

Question

Miałem dyskusję z naszą firmą teamlead \ architect na ten temat.

Twierdzi, że łatwiej jest zrozumieć projekt na dużą skalę, jeśli "podmioty połączone logiką" są umieszczone w jednym pliku cs.

cytuję:

1. „Cała struktura logiki i interfejsu i klasy można zobaczyć w jednym miejscu, to jest argument, którego nie można obalić Aby zobaczyć to samo. ale z kilkoma plikami musisz użyć narzędzi, diagramu klas, R # do nawigacji itp. "

2. „Po słabe teorię mogę krzyczeć, że armia plików rozdzielonych jest fajne, ale jeśli chodzi o wprowadzenie zmian do istniejącego kodu, zwłaszcza jeśli nie były pisarzem tego kodu, to jest bardzo trudne zrozumieć mnóstwo plików rozproszonych. Więc na forach, można napisać, że „jeden enum- jeden plik”, ale w praktyce takie podejście powinno nigdy być używane „

3. ” ... Jak do oddzielania kodu podstawa pomiędzy programistami, obecnie nie ma problemu, edytuj jednocześnie ten sam plik. Scalanie nie jest problemem. "

usłyszałem i przeczytałem wiele razy, że musimy stworzyć jeden .cs plik za enum, klasy i tak dalej i to jest najlepsza praktyka.

Ale nie mogę go przekonać. Mówi, że nie ufa żadnym znanym programistom, takim jak Jon Skeet. Przy okazji jest opinia Skeeta na ten temat: Where is the best place to locate enum types?

Co sądzisz? Czy jest prawdziwy problem? Czy jest to kwestia gustu i powinna być regulowana standardem kodowania organizacji?

Answer 1

Moim zdaniem:

Małe teksty stałe i klas, które są potrzebne wewnątrz większego klasy logicznej może pozostać w swoim pliku.
Ale jeśli mniejsze klasy i wyliczenia są używane poza tym zakresem, powinieneś je mieć oddzielnie (chociaż jeśli są logicznie powiązane, same mogą znajdować się w tym samym pliku).
Więc zgadzam się z nim na temat logicznego sprzężenia.

Mówiąc, muszę powiedzieć, że istnieją inne alternatywy, możesz tworzyć logiczne foldery wewnątrz projektu, aby przechowywać klasy z tego samego środowiska logicznego lub połączeń.
Dzisiejsze IDE zapewniają łatwy dostęp i mobilność w całym rozwiązaniu dzięki funkcji Go-To, więc znalezienie kodu nie stanowi problemu.

Utrzymywanie logicznych komponentów razem (o ile są one naprawdę blisko sprzężone) ma dużą zaletę podczas skalowania. Wraz z rozwojem projektu pojawia się więcej bałaganu i właśnie tego próbuje uniknąć.

BTW, jeśli czytasz opinię Skeet jest ściśle zauważysz:

i zakładając, że zamierzamy być używany w innych klasach, uczynić ich rodzaje najwyższego poziomu we własnych plików.

Answer 2

Uważam, że twoja opinia "teamlead \ architect" w dużej mierze opiera się na słabym wykorzystaniu przestrzeni nazw. za każdym razem, gdy usłyszałem ten argument od programisty, jest to spowodowane prawie całkowitym brakiem użycia przestrzeni nazw (a potem staje się naprawdę niechlujne, jeśli dodasz dużo plików)

Answer 3

To jest bardzo ważne, więc byłoby lepiej napisali tutaj:

https://codereview.stackexchange.com/

jednak zwykle należy umieścić wszystkie definicje typów w swoich plikach, z pewnymi wyjątkami:

• Klasa kontrakty kodowe stosowane do umów na abstrakcyjna klasa bazowa lub interfejs logicznie należy do tej klasy.

• wyliczenia co tylko jako parametru, własności lub wartości powrotnego w obrębie klasy należą również z tej klasy (nie zagnieżdżone w sobie).

Prawdopodobnie istnieje kilka innych wyjątków, ale ogólnie każdy typ powinien przejść do osobnego pliku.

Answer 4

Nie zgadzam się z wieloma punktami przedstawionymi przez "teamlead/architect" tutaj.

Podobnie jak wiele rzeczy związanych z kodem, jest to kwestia opinii.

Osobiście uważam, że najlepiej jest utworzyć jeden plik .cs na enum, klasę i tak dalej. Zwykle, jeśli istnieje jedna klasa, która jest najbliżej związana z enumem i umieszczam je w tym samym pliku.

Przyjmuję, że firmy mogą mieć własny standard kodowania, ale sugerowany tutaj jest po prostu błędny, ponieważ jest sprzeczny z wieloma dobrymi praktykami.

Answer 5

Ty i on możecie przyjrzeć się wielu złożonym projektom open source w Internecie. Spójrz na github, codeplex i podobne miejsca.

Na przykład spójrz na kod źródłowy MVC. Jeśli class-per-file jest wystarczająco dobry dla Microsoftu i tak złożony jak MVC, myślę, że jest duża szansa, że ​​byłby wystarczająco dobry dla was.

Osobiście używam klasy/interfejsu dla każdego podejścia do pliku (z wyjątkiem szczególnych przypadków, takich jak małe wyliczenie, ale to subiektywne) i nie widzę z tym żadnych problemów.

Answer 6

Interesujące pytanie, to jest moje zdanie na ten temat.

Należy dokonać rozróżnienia między logicznym grupowaniem (przestrzenią nazw) a fizycznym grupowaniem (plik/projekt).

W każdym przypadku wyliczanie należy umieścić w logicznej przestrzeni nazw, do której należy firma, a nie w przestrzeni nazw zawierającej tylko wyliczenia lub nawet nie podawać wyliczenia w nazwie przestrzeni nazw. Nie ma sensu posiadanie przestrzeni nazw "Wylicza", ponieważ będziesz wtedy zaśmiecać koncepcje i nie określisz domeny, do której należy.

Jeśli wyliczenie jest używane tylko przez jeden typ klasy, można go również umieścić w samej klasie. W ten sposób jest oczywiste, że należy on do tej konkretnej klasy i jako taki znajduje się w tym samym pliku kodu. Jeśli wyliczenie jest bardziej podobne do wyliczenia ogólnego celu, używanego w wielu klasach, a następnie umieść je osobno w swoim własnym pliku kodu.

Tak więc nie zgadzam się z kierownictwem zespołu: jeśli umieścisz go w tym samym pliku, uczyń go częścią samej klasy, ponieważ tak właśnie mówisz, jeśli umieścisz go w tym samym pliku, w przeciwnym razie umieść go w swoim własnym plik kodu. Myślę, że i tak jest to w pewnym sensie bardziej konsekwentne.