Jedna klasa na regułę pliku w .NET? [Zamknięte]

Stosuję się do tej zasady, ale niektórzy z moich kolegów nie zgadzają się z nią i twierdzą, że jeśli klasa jest mniejsza, można ją zostawić w tym samym pliku z innymi klasami.

Kolejny argument, który słyszę przez cały czas, brzmi: „Nawet Microsoft tego nie robi, więc dlaczego mielibyśmy?”

Jaki jest ogólny konsensus w tej sprawie? Czy istnieją przypadki, w których należy tego unikać?

Jedna klasa na plik daje także lepszy obraz tego, co zmienia się przy każdym zameldowaniu, bez patrzenia na różnice w pliku.

Nienawidzę tego, gdy ludzie myślą absolutnie i mówią, że nigdy nie powinieneś tego robić z czymś subiektywnym i wybrednym jak ten, tak jakbyśmy wszyscy musieli dostosować się do czyichś głupich pomysłów na dobro i zło. Podsumowując: posiadanie więcej niż jednej klasy na plik jest całkowicie w porządku, jeśli ma to sens. Przez sens rozumiem takie rzeczy jak:

1. Ułatwia trawienie i utrzymanie kodu
2. Sprawia, że ​​rozwiązanie jest mniej denerwujące (przewijanie niepotrzebnych plików) i mniej powolne
3. Zespół programistów jest w porządku jako lokalna praktyka kodowania

Naprawdę dobry przykład, dlaczego mogę chcieć wielu klas na plik:

Powiedzmy, że mam kilkadziesiąt niestandardowych klas wyjątków, każda z nich jest czterowarstwowa, mógłbym mieć osobny plik dla każdej z nich lub mógłbym grupować wyjątki i mieć plik na grupę. Dla mnie najbardziej racjonalnym / pragmatycznym podejściem jest grupowanie ich i posiadanie tylko kilku plików, ponieważ jest to bardziej efektywne pod względem czasu / kodowania (nie muszę klikać prawym przyciskiem myszy -> Dodaj klasę, zmieniaj nazwę, 50 razy) , dzięki temu rozwiązanie jest mniej zagracone i ma lepszą wydajność.

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

Czasami grupuję więcej niż jedną klasę w pliku, jeśli są one ściśle powiązane, a przynajmniej jedna z nich jest bardzo mała.

Ogólną „najlepszą praktyką” jest posiadanie jednego pliku na klasę.

Oprócz hipotetycznych argumentów i skupiania się zamiast tego na Windows .NET z Visual Studio IDE i rozwijającymi się projektami oprogramowania, w tym kontekście po prostu sensowne jest posiadanie jednej klasy na plik.

Ogólnie rzecz biorąc, dla odniesienia wizualnego nic nie przebije jednej klasy na plik. Naprawdę.

Nie wiem, czy Microsoft robi to samo, czy nie, jednak utworzyli partialsłowo kluczowe, aby podzielić jedną klasę na wiele plików (jest to nawet bardziej dotkliwe). Często służy do dzielenia automatycznie generowanego kodu projektanta z kodu niestandardowego w tej samej klasie (ale czasami jest używana, aby umożliwić różnym programistom pracę nad klasą w tym samym czasie za pomocą różnych plików). Tak więc Microsoft dostrzega zalety wielu plików i wszyscy mają na myśli wiele przemyśleń dotyczących organizacji plików z .NET.

W przypadku klas zagnieżdżonych nie masz innego wyboru, jak użyć jednego pliku lub przynajmniej pierwszych części klas w nich zawartych. W tym przypadku konieczny jest jeden plik:

class BicycleWheel {
    class WheelSpoke {
    }
}

W przeciwnym razie dlaczego miałbyś przechowywać wiele klas w jednym pliku? Argument „ponieważ są małe” lub powiązane ze sobą , nie zawiera dużej ilości wody, ponieważ ostatecznie twoje klasy zostaną powiązane z innymi klasami. Ostatecznie nie można łatwo wywnioskować organizacji obiektów w pliku na podstawie ich użycia, zwłaszcza w miarę rozwoju oprogramowania.

Dodatkowo, jeśli używasz folderów dla przestrzeni nazw , nigdy nie będziesz mieć konfliktu nazw plików klas. Wygodne jest także zlokalizowanie klasy według nazwy pliku w systemie plików, gdy nie znajduje się ona w środowisku programistycznym, takim jak Visual Studio (np. Jeśli chcesz szybko edytować klasę za pomocą Notatnika lub czegoś szybkiego / lekkiego ).

Tyle dobrych powodów ...

W zdecydowanej większości przypadków stosuję regułę jednej klasy na plik. Jedynym wyjątkiem, który regularnie robię, jest definicja wyliczenia ściśle powiązanego z określoną klasą. W takim przypadku często dołączam definicję wyliczenia do pliku tej klasy.

Ja również uważam, że w jednym pliku powinien znajdować się jeden typ.

Jest jeden wyjątek od tej reguły, o którym należy wspomnieć: Posiadanie dwóch klas, które różnią się jedynie ogólnym argumentem, takim jak:

RelayCommand     

i

RelayCommand<T>

Naprawdę sprowadza się to do osobistych preferencji. Wszyscy powiedzą „jedna klasa na plik”, ale wszyscy mamy powody, aby tego uniknąć w pewnych okolicznościach. Kiedyś miałem duży projekt, który miał około 300 różnych wyliczeń. Nie ma mowy, żebym miał 300 osobnych plików, po jednym dla każdej klasy, gdy niektóre wyliczenia były tylko trójstanowe.

Również dla osób, które nie mogą znaleźć określonych klas, jeśli nie wszystkie znajdują się w plikach nazwanych tak, jakimi są, czy istnieje powód, dla którego nie używasz Znajdź szukając w całym rozwiązaniu? Korzystanie z funkcji Znajdź oszczędza cenny czas na przewijaniu Eksploratora rozwiązań.

Bez względu na to, jak lekka jest zawartość, uważam, że jedna klasa / interfejs / itd. Na plik jest niezbędna.

Jeśli pracuję nad dużym rozwiązaniem w Visual Studio, chcę widzieć pliki i nie muszę zaglądać do środka, aby je zobaczyć. Nawet z narzędziami do nawigacji, takimi jak ReSharper, chcę mapowania 1: 1.

Jeśli znajdziesz wiele plików źródłowych z niewielką ilością lub bez zawartości (być może rozszerzenie klasy, ale nic do niej nie dodając), być może powinieneś przemyśleć swój projekt.

Uważam, że grupowanie klasy ze standardową klasą fabryczną w tym samym pliku jest bardzo przydatne.

Zwykle miałbym jedną klasę na plik, ale normalnie musiałbyś użyć własnego uznania, aby sprawdzić, czy plik może zawierać powiązane klasy, np. Grupując wyjątki, które mogą być ponownie wykorzystane przez ciebie i innych programistów. W takim przypadku użytkownik potrzebuje tylko jednego pliku, a nie wielu plików.

Chodzi o to, że należy stosować dyskrecję !!!

W większych rozwiązaniach uważam, że bardzo cenne jest posiadanie jednej klasy na plik i nadawanie temu plikowi tej samej nazwy co klasie. Znacznie ułatwia zlokalizowanie kodu, w którym musisz pracować.

Narzędzie StyleCop dla języka C # ma standardowe reguły, które wymagają nie więcej niż jednej klasy najwyższego poziomu w jednej przestrzeni nazw (plus dowolna liczba interfejsów, delegatów i wyliczeń w tej przestrzeni nazw).

W przypadkach dwóch lub więcej klas, w których druga i kolejne klasy są używane tylko przez pierwszą, te mogą i powinny być klasami wewnętrznymi, widocznymi tylko dla klasy konsumującej.

Kiedyś jedna klasa na plik, ale ...

Gdy wiele klas jest ściśle powiązanych, więcej niż jedna klasa w tym samym pliku źródłowym to IMHO, LEPSZE niż poświęcenie krótkiego pliku źródłowego dla każdej klasy. Źródło jest bardziej czytelne i zwarte (a przy użyciu #region to samo źródło może być bardziej uporządkowane niż wcześniej).

Weź również pod uwagę, że czasami NIEZBĘDNE jest rozkładanie tej samej klasy na różne pliki (przy użyciu częściowego ), ponieważ posiadanie pliku źródłowego linii o wielkości 20000+ nie jest przydatne nawet przy dostępnej pamięci RAM (ale to jest inne pytanie).

Czasami zostawiam małą klasę z większą klasą, ale tylko wtedy, gdy są bardzo ściśle powiązane jak przedmiot i jego klasa kolekcji lub fabryka.

Jest z tym jednak jeden problem. W końcu mała klasa rośnie do punktu, w którym powinna znajdować się we własnym pliku, jeśli przeniesiesz ją do nowego pliku, stracisz łatwy dostęp do historii zmian.

to znaczy.

• w poniedziałek wprowadzam zmiany do moich klas x i y w pliku y.css
• we wtorek dzielę klasę x na własny plik x.css, ponieważ urósł do dużej wielkości
• w środę mój szef chce zobaczyć, co zmieniłem w klasie x w poniedziałek, więc przegląda historię x.css, tylko x.css nie pokazuje historii przed zmianami we wtorek.

Czy to naprawdę problem? :)
Naprawdę małe klasy, podobnie jak wyliczenia, można łączyć z innymi. Należy przestrzegać jednej zasady: łączyć tylko klasy, które mają coś wspólnego.

Jako dygresja - w jednym z moich projektów mam plik zawierający 150 klas. Plik zawiera 10000 linii kodu. Ale jest generowany automatycznie, więc jest w pełni akceptowalny :)

Jednym z powodów umieszczenia wielu pokrewnych klas w jednym pliku jest to, że biedny drań korzystający z interfejsu API nie musi spędzać pół dnia na wpisywaniu deklaracji importu, a biedny drań, który musi utrzymywać kod, nie musi wydawać połowy dzień przewijany przez szablon deklaracji importowej. Moja ogólna zasada polega na tym, że wiele klas należy do tego samego pliku, jeśli prawie zawsze używasz ich dużego podzbioru w tym samym czasie zamiast tylko jednej.

Robię to, ale tylko wtedy, gdy klasy są powiązane w sposób potomek-rodzic, a klasy potomne są używane TYLKO przez rodzica.

Zwykle trzymam się jednej klasy na plik. Ale zrobię wyjątki dla grup podobnych konstrukcji, które są używane w całym projekcie. Na przykład:

• EventArgs.cs, który zawiera dowolne EventArgspodklasy, ponieważ zwykle są to tylko 5-10 wierszy kodu, ale zwykle są używane przez kilka różnych klas. Alternatywnie, mogę umieścićEventArgs klasy w tym samym pliku, co klasa, która deklaruje zdarzenia.
• Plik Delegates.cs, który zawiera Delegatów używanych w całym projekcie, ponieważ zazwyczaj są to tylko 1 linia. Ponownie, alternatywą jest umieszczenie ich w tym samym pliku z klasą, która je udostępnia / zużywa.
• Enums.cs, który zawiera enums używane w całym projekcie. (Jeśli jest taki, enumktóry jest używany tylko przez jedną klasę, zwykle udam się privatedo tej klasy).

Kolejny głos na jedną klasę na plik o nazwie pliku takiej samej jak klasa. Dla mnie pomaga to w długoterminowej konserwacji. Mogę łatwo przejrzeć repozytorium i zobaczyć, które klasy są częścią rozwiązania, bez konieczności otwierania projektu lub dowolnego pliku.

Śledzę to w 99% przypadków. Dobrze jest przestrzegać standardów, ale uważam również, że elastyczność ma swoje miejsce. Czasami po prostu wydaje się głupią stratą czasu, aby wszystko rozdzielić. W tych czasach przełamuję się i po prostu piszę swój kod.

Dotychczasowe odpowiedzi wydają się obracać wokół wyjątków ludzi od reguły, więc oto moje: trzymam klasy i ich metadane jako „koleżeńskie” klasy razem podczas korzystania z pakietu DataAnnotations w .NET3.5 SP1. W przeciwnym razie są zawsze w osobnych plikach. Wiesz, przez większość czasu. Z wyjątkiem sytuacji, gdy nie są.

Robię to rzadko. Na przykład, jeśli istnieje wyliczenie lub struktura, która jest ściśle powiązana z klasą, a jednocześnie zbyt trywialna, aby można ją było samodzielnie rozdzielić.

Lub osobna klasa zawierająca pewne metody rozszerzenia dla tej klasy głównej.

One case could be:kiedy wasze klasy razem tworzą taki, module / unitktóry służy niektórym głównym klasom, jak helper classesinne mądre nie .

spójrz na kod źródłowy projektu ASP.NET MVC 2.0 . Ściśle przestrzega tej zasady

Podoba mi się pomysł tworzenia mniejszych klas i upewnienia się, że klasa robi tylko to, co powinna. Jeśli masz wiele klas, które przyczyniają się do rozwiązania jednego problemu, połączenie ich w tym samym pliku nie jest szkodliwe.

Nie przestrzegałbym praktyk stwardnienia rozsianego, ponieważ nie są NAJLEPSZYMI PRAKTYKAMI!

Inną kwestią, o której nikt inny nie wspomniał, jest to, że kiedy tworzysz regułę jednej klasy na plik, możesz łatwo zobaczyć, czego używa ta konkretna klasa.

Na przykład: możesz mieć dwie klasy, w których jedna klasa używa Linq, a druga nie.

Gdyby te klasy znajdowały się w tym samym pliku, nie byłbyś w stanie stwierdzić bez przejrzenia kodu, która klasa używa czego. Gdy jest to jedna klasa na plik, wystarczy spojrzeć na górę pliku, aby zobaczyć dokładnie, co jest używane w tej klasie. Pomaga, jeśli kiedykolwiek przeprowadzasz migrację do nowej biblioteki itp.

Innym powodem, dla którego jedna klasa na plik nie została wymieniona w opublikowanych odpowiedziach jest to, że jedna klasa na plik ułatwia zrozumienie wpływu PR podczas przeglądu kodu. Zmniejsza to także konflikty scalania.

Kiedy ktoś publikuje PR w celu uzyskania opinii, mogę spojrzeć na listę zmienionych plików i od razu zobaczyć, czy nakładają się na to, nad czym mogę pracować. W zależności od nakładania się, mogę chcieć głębiej przyjrzeć się ich kodowi lub dać mu OK, ponieważ jestem pewien, że nie wpłynie to na moje własne zmiany.

Gdy dwie osoby pracują w pliku wieloklasowym i obie dodają zależność, istnieje duża szansa, że ​​wystąpi konflikt scalania w using w górnej bloku . Rozdzielenie klas na pliki oddziela zależności, dzięki czemu można zobaczyć, z czego korzysta każda klasa, i nie ma takich konfliktów.

Istnieją wyjątki od tej reguły (interfejs + implementacja, wyliczenia, ...), ale jest to lepsze miejsce początkowe niż na odwrót, które zazwyczaj pozwala młodym programistom pakować wszystkie niepowiązane klasy w ten sam plik.

Jedna klasa na plik to wyraźna, jednoznaczna zasada niepodlegająca interpretacji.

Powiązane klasy w pliku podlegają osobistym preferencjom i interpretacji (jak widać z wszystkich innych odpowiedzi tutaj, kiedy można używać), a zatem jest to zła zasada.

W przód i w tył było bardzo interesujące i pozornie niejednoznaczne, chociaż mam ogólne wrażenie, że mapowanie 1-1 między klasami i plikami jest większością opinii, choć z pewnymi wyjątkami osobiście.

Jestem ciekawy, czy którakolwiek z twoich odpowiedzi różni się w zależności od tego, czy: (1) tworzysz aplikację Windows Forms, aplikację sieci Web, bibliotekę lub cokolwiek innego; lub (2) przy użyciu programu Visual Studio lub nie. Przy użyciu VS wydaje się, że reguła jednej klasy na plik oznaczałaby również jedną klasę na projekt VS, ponieważ wydaje się, że w innych wątkach koncentracja rozwiązań / projektów VS powinna być dublowana w nazwie i strukturze katalogu / pliku. Rzeczywiście, mam wrażenie, że concensus ma mieć nazwę projektu = nazwa zestawu = (zagnieżdżona) nazwa przestrzeni nazw, z których wszystkie byłyby następnie dublowane w nazwie i strukturze katalogu / pliku. Jeśli są to właściwe wytyczne (lub reguły), wówczas wszystkie te pozornie ortogonalne mechanizmy organizacyjne byłyby jednak zsynchronizowane.

Tak, ze względu na czytelność powinniśmy mieć jeden plik na klasę! Właśnie wskoczyłem do projektu. Widzę wiele klas w jednym pliku. po prostu sprawia, że ​​tak trudno jest nowemu facetowi to zrozumieć. nie powinniśmy myśleć o łatwości konserwacji? kiedy opracowujemy oprogramowanie? wiele razy rozwój będzie kontynuowany przez innych programistów. Mamy przestrzenie nazw, aby uporządkować nasze rzeczy, nie potrzebujemy do tego plików!

Tak, jeden element kodu na plik.

Wszystko inne jest nadużyciem - i, szczerze mówiąc, oznaką ofiary RAD.

Jak tylko rozpocznie się właściwe tworzenie oprogramowania (IoC, wzorce projektowe, DDD, TDD itp.) I pozostawi „omg pozwala to zrobić, nie mam pojęcia jak, ale dostaję wynagrodzenie”, zobaczysz, że ta zasada naprawdę ma znaczenie.