Jak unikać namespace'ów nazywających się tak samo, jak klasy?

O ile mi wiadomo, w C# jest bardzo niezalecane, by klasa nazywała się tak samo, jak namespace. Ale czasami trudno mi tego uniknąć.

Przykład:

Program liczący pi z dużą dokładnością. W dotnecie jest od razu BigInteger, ale przydałby mi się BigDouble. Zatem piszę go.

Ale czy mam zmieścić całą implementację BigDouble w jednej klasie? Mogę, ale wtedy ta klasa zrobi się długa. Więc podzieliłem na klasę BigDouble i pomocnicze klasy Addition, Normalization, Substraction itp.

namespace BigDouble
|- public class BigDouble
|- internal class Addition
|- internal class Substraction
|- internal class Normalization
|- ...
|- ...

I to jest źle, bo typ jest w NS, która się nazywa tak samo, jak typ. Ale co zamiast tego?

Tak samo testy. Czy wszystkie testy do BigDouble zmieścić w jednej klasie? Znowu: Mogę, ale wtedy ta klasa zrobi się długa. Może więc lepiej podzielić testy na parę plików: Construction, Addition, Normalization, Substraction, ..., ..., ... W namespace BigDouble? Znowu źle.

Jak się zazwyczaj postępuje w takich wypadkach, jak się unika namespace'ów nazywających się tak samo, jak klasy?

Cóż, zawsze mogę zmienić namespace BigDouble na namespace BigDoubleNS, ale to już chyba głupie.

Zmien nazwę namespace na sensowną i problem solved, BigInteger jest w System.Numerics to zrób sobie jakieś Yetanotherone.Numerics.

Swoją drogą kompletnie nie czaję wydzielenia dodawania czy odejmowania do innej klasy, ale może to moje braki w OOP. Testy to co innego, jak by się rozciągały to bym podzielił suite po use case. Poza tym klasy z testami powinny być niezależne, więc nie ma tam raczej mowy o jakiejś klasie nadrzędnej.

Poza tym https://docs.microsoft.com/pl-pl/previous-versions/visualstudio/visual-studio-2015/code-quality/ca1020-avoid-namespaces-with-few-types?view=vs-2015&redirectedfrom=MSDN powinno zniechęcać do rozdrabniania namespace. Popatrz na wykorzystanie biblioteki - ja nie lubie się zastanawiać co jest w jakimś namespace. Wrzucam System.Collections.Generic i mam kolekcje. Z Twoim podejściem mielibyśmy System.Collections.Generic.List itp. Strasznie słabe.

Saalin napisał(a):

Zmien nazwę namespace na sensowną i problem solved, BigInteger jest w System.Numerics to zrób sobie jakieś Yetanotherone.Numerics.

Jasne. Ale co, jeżeli w tym Yetanotherone.Numerics będzie coś więcej, niż tylko BigDouble?

Swoją drogą kompletnie nie czaję wydzielenia dodawania czy odejmowania do innej klasy, ale może to moje braki w OOP.

Zakładam, że idealnie by było, gdyby jeden plik nie miał wieluset linii kodu?

Jeśli public static BigDouble operator + (BigDouble a, BigDouble b) wykorzystuje ze 3 metody pomocnicze, public static BigDouble operator - (BigDouble a, BigDouble b) wykorzystuje kolejnych 5, i tak dla każdej operacji, przy czym metody te są rozłączne, operator + nie wykorzystuje metod, które wykorzystuje operator -, i tak dla każdego działania, to chyba zrobi się bajzel, jeśli wszystko to się wrzuci do jednego pliku? Czy zwykły porządek nie wskazywałby na potrzebę podzielenia tego tematycznie na kilka plików?

Poza tym https://docs.microsoft.com/pl-pl/previous-versions/visualstudio/visual-studio-2015/code-quality/ca1020-avoid-namespaces-with-few-types?view=vs-2015&redirectedfrom=MSDN powinno zniechęcać do rozdrabniania namespace. Popatrz na wykorzystanie biblioteki - ja nie lubie się zastanawiać co jest w jakimś namespace. Wrzucam System.Collections.Generic i mam kolekcje. Z Twoim podejściem mielibyśmy System.Collections.Generic.List itp. Strasznie słabe.

Chyba masz rację. Ale czy nie powinno być tak, że klasy i namespace'y powinny odpowiadać strukturze plików i folderów w projekcie? Folder <--> namespace, plik .cs <--> jedna klasa.

A więc jeśli chcę umieścić jakieś pliki w danym folderze, to muszę stworzyć namespace nazywającą się tak samo, jak ten folder i wszystkie klasy zdefiniowane przez pliki w tym folderze umieścić w tej namespace?

Kompilatorowi wszystko jedno, ale czy postępowanie w ten sposób nie jest powszechnie przyjęte?

W Yetanotherone.Numerics może być zarówno BigDouble jak i, nie wiem, NewtonMethod. Załóżmy, że BigDouble zajmuje coś koło 10 plików, NewtonMethod zajmuje kolejne 5. Czy nie należałoby tych plików dla porządku podzielić na foldery? Pliki związane z BigDouble do jednego folderu, a pliki związane z NewtonMethod do osobnego. Ale to natychmiast wymusza dodanie dwóch nowych namespace'ów...?

Hmm, sprawdziłem, jak to robi dotnet.

Mają internal static partial class BigIntegerCalculator porozrzucaną po 7 plikach, m.in. BigIntegerCalculator.AddSub.cs czy BigIntegerCalculator.DivRem.cs.

Może można zerżnąć taką organizację kodu?

Chociaż dziwi mnie to, używanie partial class wydaje mi się być strasznie brzydkie. Wydawało mi się, że partiali należy raczej unikać?

YetAnohterone napisał(a):

Jasne. Ale co, jeżeli w tym Yetanotherone.Numerics będzie coś więcej, niż tylko BigDouble?

no do tego służą namespace'y. Nie po to żeby trzymać w nich jedną klasę. Możesz nawet (choć lintery będą się pluć i nie polecam) dodać swoją klasę do cudzego namespace'a jak System.Numerics

YetAnohterone napisał(a):

Chyba masz rację. Ale czy nie powinno być tak, że klasy i namespace'y powinny odpowiadać strukturze plików i folderów w projekcie? Folder <--> namespace, plik .cs <--> jedna klasa.

A więc jeśli chcę umieścić jakieś pliki w danym folderze, to muszę stworzyć namespace nazywającą się tak samo, jak ten folder i wszystkie klasy zdefiniowane przez pliki w tym folderze umieścić w tej namespace?

no tak, ale tworzenie folderu i namespace'a na każdą klasę stworzy jeszcze większy bałagan

YetAnohterone napisał(a):

Chociaż dziwi mnie to, używanie partial class wydaje mi się być strasznie brzydkie. Wydawało mi się, że partiali należy raczej unikać?

należy unikać, ale w obiektach domenowych. W takim utility class która ma wiele konstruktorów i po prostu ma skomplikowaną implementację żeby obsłużyć wszystkie przypadki jest to moim zdaniem uzasadnione. Inaczej używanie tej klasy byłoby prawdopodobnie utrudnione. Przykładowo nie da się wydzielić operatorów do osobnych klas. Samemu mi się zdarzyło ze 2 razy w życiu podzielić klasę na partial classy, gdy inne rozwiązania były zbyt skomplikowane.

Swoją drogą mam trochę wątpliwości co do jakości tego Twojego BigDouble. W jaki sposób działa od wewnątrz i do czego ci to potrzebne? 128 bitowy Decimal nie wystarczy?

obscurity napisał(a):

należy unikać, ale w obiektach domenowych. W takim utility class która ma wiele konstruktorów i po prostu ma skomplikowaną implementację żeby obsłużyć wszystkie przypadki jest to moim zdaniem uzasadnione. Inaczej używanie tej klasy byłoby prawdopodobnie utrudnione. Przykładowo nie da się wydzielić operatorów do osobnych klas. Samemu mi się zdarzyło ze 2 razy w życiu podzielić klasę na partial classy, gdy inne rozwiązania były zbyt skomplikowane.

Niby nie da się wydzielić operatorów do osobnych klas, ale można zrobić z nich public static BigDouble operator + (BigDouble a, BigDouble b) => Addition.Add(a, b); Być może to jest przekomplikowane bez żadnych zysków.

Swoją drogą mam trochę wątpliwości co do jakości tego Twojego BigDouble. W jaki sposób działa od wewnątrz i do czego ci to potrzebne? 128 bitowy Decimal nie wystarczy?

128 bitów to ile byłoby cyfr znaczących w zapisie dziesiętnym? Coś koło 38 bodajże? A ja chcę iść do oporu :)

Jak działa od wewnątrz? Mantysa to BigInteger o dlugości równej zadanej precyzji, cecha to long. Zakładamy, że np. dodawanie liczb o tym samym znaku traci jedną cyfrę znaczącą w zapisie binarnym, więc mantysę wyniku skracamy odpowiednio.

YetAnohterone napisał(a):

Tak samo testy. Czy wszystkie testy do BigDouble zmieścić w jednej klasie? Znowu: Mogę, ale wtedy ta klasa zrobi się długa. Może więc lepiej podzielić testy na parę plików: Construction, Addition, Normalization, Substraction, ..., ..., ... W namespace BigDouble? Znowu źle.

No ja bym raczej miał namespace BigDoubleTests i tam już klasa testowa per testowana metoda. A jeśli testy są skomplikowane, to i wiele klas testowych dla jednej metody.

Cóż, zawsze mogę zmienić namespace BigDouble na namespace BigDoubleNS, ale to już chyba głupie.

Jeszcze jak. :D

YetAnohterone napisał(a):

W Yetanotherone.Numerics może być zarówno BigDouble jak i, nie wiem, NewtonMethod. Załóżmy, że BigDouble zajmuje coś koło 10 plików, NewtonMethod zajmuje kolejne 5. Czy nie należałoby tych plików dla porządku podzielić na foldery? Pliki związane z BigDouble do jednego folderu, a pliki związane z NewtonMethod do osobnego. Ale to natychmiast wymusza dodanie dwóch nowych namespace'ów...?

Ja bym zrobił tak:

namespace MyLib
|- public class BigDouble
|- BigDoubleInternals
|  |- internal class Addition
|  |- internal class Substraction
|  |- internal class Normalization
|- public class NewtonMethod
|- NewtonMethodInternals
   |- internal class N1
   |- internal class N2

Może można zerżnąć taką organizację kodu?

Też można - dopóki klas jest mało.

Chociaż dziwi mnie to, używanie partial class wydaje mi się być strasznie brzydkie. Wydawało mi się, że partiali należy raczej unikać?

Ja nie widzę dla partial zastosowania w samodzielnie pisanym kodzie. Może gdybym pisał jakiś superwydajny kod, ale nie wiem.

PS Ta reguła stylecopa czy co to jest to niezbyt przydatna jest, bo nie definiuje ile to jest mało.

Jeśli chcesz by te klasy pomocnicze internal stały się klasami prywatnymi dostępnymi tylko wewnątrz projektowanej klasy, albo podkreślić ich powiązanie z projektowaną klasą, to jak najbardziej jest to modelowy przykład zastosowania partial. Natomiast jeśli nie potrzebujemy ich ukrywać przed innymi elementami w naszym module, ani podkreślać powiązania przez udostępnianie ich po przez projektowaną klasę, to bym poszedł w hierarchię zaproponowaną przez @somekind.

somekind napisał(a):

No ja bym raczej miał namespace BigDoubleTests i tam już klasa testowa per testowana metoda. A jeśli testy są skomplikowane, to i wiele klas testowych dla jednej metody.

Ciekawe. Wydawało mi się, że konwencja jest taka, by klasa testująca była w namespace, w którym jest klasa testowana, z dodatkiem .Tests

Nie słyszałem o takiej konwencji. Nazwa projektu z sufkisem .Tests.csproj jest dość powszechna, ale namespace bywają różne. Zazwyczaj widziałem takie same jak w testowanym kodzie, żeby mieć lustrzaną hierarchię.