Czy foldery w rozwiązaniu powinny pasować do przestrzeni nazw?

Czy foldery w rozwiązaniu powinny pasować do przestrzeni nazw?

W jednym z moich projektów zespołowych mamy bibliotekę klas, która ma wiele podfolderów w projekcie.

Nazwa projektu i Przestrzeń nazw MyCompany.Project.Section.

W ramach tego projektu istnieje kilka folderów pasujących do sekcji przestrzeni nazw:

• Folder Vehicleszawiera klasy w MyCompany.Project.Section.Vehiclesprzestrzeni nazw
• Folder Clothingzawiera klasy w MyCompany.Project.Section.Clothingprzestrzeni nazw
• itp.

Wewnątrz tego samego projektu znajduje się kolejny fałszywy folder

• Folder BusinessObjectszawiera klasy w MyCompany.Project.Sectionprzestrzeni nazw

W kilku takich przypadkach foldery są tworzone dla „wygody organizacyjnej”.

Moje pytanie brzmi: jaki jest standard? Czy w bibliotekach klas foldery zwykle pasują do struktury przestrzeni nazw, czy też jest to zbiór mieszany?

Należy również pamiętać, że jeśli używasz wbudowanych szablonów do dodawania klas do folderu, zostanie on domyślnie umieszczony w przestrzeni nazw, która odzwierciedla hierarchię folderów.

Zajęcia będą łatwiejsze do znalezienia i już samo to powinno być wystarczającym powodem.

Zasady, którymi się kierujemy to:

• Nazwa projektu / zespołu jest taka sama, jak główna przestrzeń nazw, z wyjątkiem zakończenia .dll
• Jedynym wyjątkiem od powyższej reguły jest projekt z zakończeniem .Core, element .Core jest usuwany
• Foldery to przestrzenie nazw
• Jeden typ na plik (klasa, struktura, wyliczenie, delegat itp.) Ułatwia znalezienie odpowiedniego pliku

Nie.

Wypróbowałem obie metody na małych i dużych projektach, zarówno z jednym (mną), jak i zespołem programistów.

Odkryłem, że najprostszą i najbardziej produktywną drogą jest posiadanie jednej przestrzeni nazw na projekt i wszystkie klasy trafiają do tej przestrzeni nazw. Możesz wtedy umieścić pliki klas w dowolnych folderach projektu. Nie ma problemu z dodawaniem instrukcji using na początku plików przez cały czas, ponieważ istnieje tylko jedna przestrzeń nazw.

Ważne jest, aby organizować pliki źródłowe w folderach i moim zdaniem do tego należy używać wszystkich folderów. Wymaganie, aby te foldery były również mapowane na przestrzenie nazw, jest niepotrzebne, powoduje więcej pracy, a okazało się, że jest to w rzeczywistości szkodliwe dla organizacji, ponieważ dodatkowe obciążenie sprzyja dezorganizacji.

Weźmy na przykład to ostrzeżenie FxCop:

CA1020: Unikaj przestrzeni nazw z kilkoma typami
Przyczyna: Przestrzeń nazw inna niż globalna przestrzeń nazw zawiera mniej niż pięć typów https://msdn.microsoft.com/en-gb/library/ms182130.aspx

To ostrzeżenie zachęca do zrzucania nowych plików do ogólnego folderu Project.General, a nawet do katalogu głównego projektu, dopóki nie będziesz mieć czterech podobnych klas uzasadniających utworzenie nowego folderu. Czy to się kiedykolwiek stanie?

Znajdowanie plików

Przyjęta odpowiedź brzmi: „Zajęcia będą łatwiejsze do znalezienia i już samo to powinno być wystarczającym powodem”.

Podejrzewam, że odpowiedź odnosi się do posiadania wielu przestrzeni nazw w projekcie, które nie są mapowane na strukturę folderów, a nie do tego, co sugeruję, czyli do projektu z pojedynczą przestrzenią nazw.

W każdym przypadku, gdy nie możesz określić, w którym folderze znajduje się plik klasy z przestrzeni nazw, możesz go znaleźć za pomocą opcji Przejdź do definicji lub pola eksploratora rozwiązań wyszukiwania w programie Visual Studio. Moim zdaniem nie jest to duży problem. Nie poświęcam nawet 0,1% mojego czasu pracy na problem ze znalezieniem plików uzasadniających ich optymalizację.

Zderzenia nazw

Oczywiście utworzenie wielu przestrzeni nazw pozwala projektowi mieć dwie klasy o tej samej nazwie. Ale czy to naprawdę dobra rzecz? Czy może łatwiej jest po prostu tego zabronić? Zezwolenie na dwie klasy o tej samej nazwie stwarza bardziej złożoną sytuację, w której 90% czasu wszystko działa w określony sposób, a potem nagle okazuje się, że masz specjalny przypadek. Załóżmy, że masz dwie klasy Rectangle zdefiniowane w oddzielnych przestrzeniach nazw:

• klasa Project1.Image.Rectangle
• klasa Project1.Window.Rectangle

Możliwe jest napotkanie problemu, który wymaga, aby plik źródłowy zawierał obie przestrzenie nazw. Teraz musisz wypisać pełną przestrzeń nazw wszędzie w tym pliku:

var rectangle = new Project1.Window.Rectangle();

Lub zamieszaj z jakimś nieprzyjemnym stwierdzeniem using:

using Rectangle = Project1.Window.Rectangle;

Mając jedną przestrzeń nazw w swoim projekcie, jesteś zmuszony wymyślić różne, i uważam, że bardziej opisowe nazwy, takie jak ta:

• klasa Project1.ImageRectangle
• klasa Project1.WindowRectangle

Użycie jest wszędzie takie samo, nie musisz zajmować się specjalnym przypadkiem, gdy plik używa obu typów.

używając instrukcji

using Project1.General;  
using Project1.Image;  
using Project1.Window;  
using Project1.Window.Controls;  
using Project1.Shapes;  
using Project1.Input;  
using Project1.Data;  

vs

using Project1;

Łatwość braku ciągłego dodawania przestrzeni nazw podczas pisania kodu. To nie jest tak naprawdę czas, to przerwa w przepływie konieczności robienia tego i wypełniania plików dużą ilością instrukcji użycia - po co? Czy warto?

Zmiana struktury folderów projektu

Jeśli foldery są mapowane na przestrzenie nazw, ścieżka folderu projektu jest skutecznie zakodowana na stałe w każdym pliku źródłowym. Oznacza to, że każda zmiana nazwy lub przeniesienie pliku lub folderu w projekcie wymaga zmiany rzeczywistej zawartości pliku. Zarówno deklaracja przestrzeni nazw plików w tym folderze, jak i używanie instrukcji w całej grupie innych plików, które odwołują się do klas w tym folderze. Chociaż same zmiany są trywialne w przypadku narzędzi, zwykle skutkują dużym zatwierdzeniem składającym się z wielu plików, których klasy nawet się nie zmieniły.

Dzięki pojedynczej przestrzeni nazw w projekcie możesz dowolnie zmieniać strukturę folderów projektu, bez modyfikowania samych plików źródłowych.

Program Visual Studio automatycznie mapuje przestrzeń nazw nowego pliku do folderu projektu, w którym jest utworzony

Niefortunne, ale uważam, że kłopot z poprawieniem przestrzeni nazw jest mniejszy niż kłopot z radzeniem sobie z nimi. Mam również zwyczaj kopiowania i wklejania istniejącego pliku zamiast używania Dodaj-> Nowy.

Intellisense i przeglądarka obiektów

Moim zdaniem największą zaletą używania wielu przestrzeni nazw w dużych projektach jest dodatkowa organizacja podczas przeglądania klas w dowolnym narzędziu, które wyświetla klasy w hierarchii przestrzeni nazw. Nawet dokumentacja. Oczywiście posiadanie tylko jednej przestrzeni nazw w projekcie powoduje, że wszystkie klasy są wyświetlane na jednej liście, a nie podzielone na kategorie. Jednak osobiście nigdy nie byłem zaskoczony ani opóźniony z powodu braku tego, więc nie uważam, że jest to wystarczająco duża korzyść, aby uzasadnić wiele przestrzeni nazw.

Chociaż gdybym pisał dużą publiczną bibliotekę klas , prawdopodobnie użyłbym wielu przestrzeni nazw w projekcie, aby zestaw wyglądał schludnie w narzędziach i dokumentacji.

Myślę, że standardem w .NET jest próba zrobienia tego, kiedy jest to możliwe, ale nie tworzenie niepotrzebnie głębokich struktur, tylko po to, aby stosować się do niego jako twardą regułę. Żaden z moich projektów nie jest zgodny z regułą namespace == structure w 100% przypadków, czasami po prostu lepiej / lepiej wyrwać się z takich reguł.

W Javie nie masz wyboru. Nazwałbym to klasycznym przypadkiem tego, co działa w teorii, a co w praktyce.

@lassevk: Zgadzam się z tymi zasadami i mam jeszcze jedno do dodania.

Kiedy mam klasy zagnieżdżone, nadal dzielę je, po jednej na plik. Lubię to:

// ----- Foo.cs
partial class Foo
{
    // Foo implementation here
}

i

// ----- Foo.Bar.cs
partial class Foo
{
    class Bar
    {
        // Foo.Bar implementation here
    }
}

Powiedziałbym tak.

Po pierwsze, łatwiej będzie znaleźć właściwe pliki kodu, podążając za przestrzeniami nazw (powiedzmy, gdy ktoś wyśle ​​Ci e-mail z nagim stosem wywołań wyjątków). Jeśli stracisz synchronizację folderów z przestrzeniami nazw, znajdowanie plików w dużych bazach kodu stanie się męczące.

Po drugie, VS wygeneruje nowe klasy, które utworzysz w folderach o tej samej przestrzeni nazw, co jego struktura folderów nadrzędnych. Jeśli zdecydujesz się płynąć pod prąd, będzie to tylko jedna dodatkowa praca hydrauliczna do codziennego wykonywania podczas dodawania nowych plików.

Oczywiście jest to oczywiste, że należy zachować ostrożność w kwestii tego, jak głęboka jest hierarchia folderów / przestrzeni nazw xis.

Tak, powinny, inaczej tylko prowadzi do zamieszania.

Jaki jest standard?

Nie ma oficjalnego standardu, ale zwykle najczęściej stosowany jest wzorzec odwzorowania folderu na przestrzeń nazw.

Czy w bibliotekach klas foldery zwykle pasują do struktury przestrzeni nazw, czy też jest to zbiór mieszany?

Tak, w większości bibliotek klas foldery są zgodne z przestrzenią nazw, co ułatwia organizację.