Czy wskazane jest utworzenie wielu klas w pliku .cs czy każdy plik .cs powinien mieć osobną klasę?
Na przykład:
public class Items
{
public class Animal
{
}
public class Person
{
}
public class Object
{
}
}
Pomijając fakt, że jest to kiepski przykład dobrej architektury, czy więcej niż jedna klasa w pliku .cs ma zapach kodu?
Odpowiedzi:
Podany przez Ciebie przykład jest moim zdaniem w porządku. Deklarujesz klasy wewnętrzne , więc rozsądnie jest trzymać je w tym samym pliku . Jedynym sposobem na obejście tego byłoby uczynienie z Itemsklasy częściowej klasy i podzielenie jej na wiele plików. Rozważę tę złą praktykę. Moja ogólna zasada dotycząca klas zagnieżdżonych polega na tym, że powinny one być małe i prywatne. Istnieją dwa wyjątki od tego:
Jeśli sformułujesz pytanie nieco inaczej i zapytasz o: „Czy powinienem umieścić każdą klasę poziomu przestrzeni nazw we własnym pliku”, wtedy moja odpowiedź brzmiałaby „tak”.
Projektując klasy, przestrzegamy zasady pojedynczej odpowiedzialności. Czytanie kodu staje się o wiele łatwiejsze, jeśli jego kształt jest zgodny z semantyką, dlatego dzielenie plików według klas jest rozsądne.
Z mechanicznego punktu widzenia posiadanie pliku według klasy ma kilka zalet. Możesz otworzyć wiele klas jednocześnie w różnych oknach. Jest to szczególnie ważne, ponieważ żaden poważny programista nie pracuje z mniej niż dwoma ekranami. Będąc w stanie mieć więcej kontekstu przed moją głową, mogę zachować większy kontekst w mojej głowie. (Większość IDE pozwoli ci dwukrotnie otworzyć ten sam plik, ale wydaje mi się to niezręczne).
Kolejnym ważnym aspektem jest kontrola źródła i łączenie. Trzymając osobne klasy, unikniesz wielu kłopotów, gdy wprowadzane są zmiany w tym samym pliku, ponieważ należy zmienić osobne klasy.
Mówiąc brutalnie, nie dodawaj do pliku więcej niż jednej klasy root. W moim ostatnim zadaniu były pliki z nie tylko wieloma klasami, ale wieloma przestrzeniami nazw, a to rozciągało się na wiele tysięcy wierszy kodu. Bardzo trudny do naśladowania.
Jeśli istnieją klasy blisko ze sobą powiązane, nazwij ich pliki podobnie lub umieść je w podfolderze.
Fizyczna separacja plików klas pomaga (zauważ, że nie koniec), prowadzi do rozdzielenia obaw i luźniejszego łączenia.
Z drugiej strony, twój przykład nie pokazuje więcej niż jednej klasy root. Istnieje kilka klas zagnieżdżonych (uwaga: staraj się nie tworzyć żadnych klas zagnieżdżonych, ale privatejeśli możesz to zaprojektować) i doskonale jest mieć to w jednym pliku.
Jeśli pliki są bardzo spójne, na przykład gdy jest to alternatywa dla kilku bardzo krótkich plików o podobnych nazwach, może to być dobry pomysł.
Na przykład uważam, że przy użyciu Fluent NHibernate łatwiej gdybym zachować Entityi EntityMapw jednym pliku, mimo tego, co moje narzędzia może mieć do powiedzenia na ten temat.
W większości przypadków trudniej jest znaleźć klasy. Używaj oszczędnie i ostrożnie.
Po prostu tak, nie jest to dobra forma, aby to zrobić, a powiem ci dlaczego, nieco później, gdy twoje rozwiązanie stanie się duże, zapomnisz, gdzie są klasy, ponieważ nazwa pliku nie będzie już reprezentować zawartości, jaka jest nazwa pliku AnimalPersonObject.cs to po prostu niemożliwe.
Jasne, że możesz obejść ten problem, używając funkcji w narzędziach takich jak resharper do przeskakiwania do typów, ale 1 klasa na plik (w tym interfejsy) jest naprawdę podstawą każdego standardu kodu, jaki kiedykolwiek widziałem, nie tylko w .net, ale w Javie i c ++ i wiele innych języków, tych, które często nie mają problemów z utrzymaniem, a młodszym programistom trudno będzie zrozumieć kod.
Prawie wszystkie narzędzia do optymalizacji kodu podpowiedzą, aby przenieść klasy do osobnego pliku, więc dla mnie tak, to jest zapach kodu i trzeba go trochę zneutralizować :)
Inną kwestią jest to, że przy bardzo dużych i podobnych klasach w tym samym pliku - gdy deklaracja klasy nie jest widoczna przez cały czas - możesz w końcu umieścić punkty przerwania w niewłaściwej klasie i zastanawiać się, dlaczego nie zostały trafione ... grrr! :)